 So, thank you for being here. I'll try to talk to you about the non-intel platforms support with Haiku. So, for those who don't know Haiku, you can go downstairs at our booth and have a live demo, and you can even buy DVDs. Yes, they're still like this. We actually sold like 60 of them yesterday or more. So, yeah, it's a free software operating system. It's inspired by the BOS. Who ever used BOS in here? Yeah, cool. So, we use our own kernel, our own GUI. And yeah, BOS already had a tradition of moving platforms because their first prototype of the B-box used the Hobbit CPU, and it was discontinued before they actually shipped the machine. So, they had to move to PowerPC. So, they made the B-box with two PowerPC processors, and then they stopped making hardware. So, they ported to the Macintosh of the time. Then, with the G3, Steve came back to Apple and said, oh no, you won't get the space for the G3. So, then they ported it to the PC. And then they failed because, well, basically Microsoft owns the PC. So, in case you thought Microsoft's controlling which OS is installed with secure boots, well, it started way before. Just look at this article. So, yeah, Jean-Luc Gasset, the founder of B, was quoted saying this, I once fridgeed peaceful coexistence with Windows. You may laugh at my expense, I deserve it. So, what's happening with Haiku when you boot on a regular PC? Well, you have the BIOS usually. You have the MBR, either our own MBR which is called Bootman or Grub, maybe, and Chain Loading. And then the MBR loads the first sector of the partition. So, we call it stage one. And then this one should locate Haiku loader. So, it needs the partition offset from the sort of the disk. We have a tool to edit this, the first sector to write it. It actually shouldn't be required now with the latest biases. So, maybe we should fix this. And then Haiku loader actually loads the kernel and passes control. So, it's not unlike NetBSD or FreeBSD if you know it. It just has a visual menu with the boot options. So, Haiku loader, which is now its own package because Haiku now uses packages. But this one is a bit special because the first sector doesn't know how to decompress so it's not compressed. Haiku loader sets the graphic mode because we want to be nice to the user and show a nice splash screen. It loads the kernel, the modules from BFS, which is our own file system. And eventually, it can load from a floppy so we can fake an init.rd thingy. It sets up the MMU, the FPU, and some other things. So, it's just not just a chain loader. And it calls the BIOS for many things like loading sectors. And then it calls the kernel with some structures which include actually platform-specific stuff and architecture-specific stuff. And we currently have a problem with this because on most architectures, we actually support many platforms now. So, on PPC, for example, we have OpenFirmware and Uboot. So, which one is it? So, we actually have to fake the OpenFirmware stuff in the Uboot struct, and it's quite early for now. So, there are some challenges when you want to port haiku to another architecture. First, since the latest beta, which is our first beta, we do support packaging, which is nice because we can almost have reproducible builds because we use a shrewd to build stuff. But it also means that dependencies are stricter so you can just screw things out just to bootstrap stuff. And haiku needs basically haiku to build itself, which is quite easy on X86, but not really on PPC or ARM. And so, yeah, bootstrap builds are not usually run by many people, so it's easy to break. And we also use C++, which can be a bit of a pain sometimes. So, PowerPC, that one was started long ago. It's the first non-X86 port. It started with the Pegasus one and some years passed, and I started porting to the SAM board and other MiGaOS compatible computers, which run Uboot. QMU knows how to emulate Macintosh, but there are always some issues. And then there's the Bbox. OpenFirmware, well, it's nicer than the BIOS. Actually, it's cleaner. Except for interactive things, like shutting down the computer. How do you do it without ACP? Well, you have to call OpenFirmware, which means you have to keep the older mappings. So actually, OpenFirmware still runs. Maybe we should use an emulator. We do this for the VISA BIOS on X86. Also, there are standardized writing, except for the frame buffer, for example. You can actually draw it through the screen, but you can't know where it is in memory. So it's not that useful. Well, this one is quite weird. I ended up writing stuff for nothing, but yeah. The SAM board, it's an embedded board. It's also used for AmigaOS fans. Well, it's a book-e CPU, so for those who don't know, it's not like the G3, G4 line of CPUs. It's very different. Basically, it's a very limited MMU. You just have the TLBs, so you have to actually fill the TLBs manually. It's quite painful. Even the Linux guys actually tried, like, three times to get it right. So, yeah. And their fork of viewboots is very old, and they basically rewrote most of the graphic stuff, and they also have things we can't even use. So, well. But I did write a target for QMU, which a nice guy cleaned up my patches and upstreamed them. So, yeah. Well, it kind of worked at some point. PPC McIntosh, as I said, there are always some issues like, oh, wait, we forgot to declare the PCI bus virtual translations in the open-firmware tree, so we put our kernel there. Oops. The bee box, yeah, so it's not the target, but it's still a blue box. I started the product recently. I mainly just wrote the device tree because it's so old nobody even cared. The boot ROM is quite dumb. It just loads a path file. But, yeah, LD claims to know how to write a path file, but it doesn't, so I have to fix this. So that's my personal to-do for PPC. ARM, well, it started long ago, and we thought, oh, cool, there's an API in U-boot. We can call it. And then we spent a week trying to find it. Oh, yeah, actually we wrote it for NetBSD or FreeBSD, but, well, nobody cares about them, so nobody can pass it in. Okay, well, then we managed to load the kernel and then some people wrote stuff for A-satistic that broke the build. So we fixed it, then it breaks. So, well, okay. So, yeah, basically U-boot, there's no usable API. There's some nice stuff, at least you thought it was nice. If you're lucky and you have a recent enough U-boot, at least U-boot fixes the FDT with the memory size. Yeah, U-boot doesn't know about BFS, of course. And where's the frame buffer? Well, nobody cares on embedded, so, yeah. So let's look at the global data. Okay, so it's a nice structure with architecture-dependent stuff. Yeah. Yeah, well, at least we get the frame buffer base, but what's the geometry of it? We don't know. Yeah, MK-image, there's an option. Let's add IQ. Yeah, but the existing boards, they use the previous U-boot, so it won't work. Let's fake NetBSD. Yeah, this board doesn't support NetBSD. Okay, let's boot. Yeah, but there are some issues with that. Okay, let's fake Linux. But which one? Because the old stuff is attack stuff, and then tools to actually fill this in, so the rest of the code is cleaner because it's currently a mess. Yeah, this one is really just for fun. M68k is nice. The X86k also earlier in the previous talk. If anyone has the next box to donate, yeah. There are still people making hardware which are compatible with those things. Basically, the Firebee, yeah, it's a cold fire stuff, and the Vamper, it's an FPGA emulation. They both have MMUs, but a bit different like the book ECPU, so it's just a TLB, and you fill it manually. Yeah, I don't think I have time for a demo. Yeah, so just come and see me. It looks like this on Atari and Amiga. Well, nobody really looked into it. I didn't really try UFI yet. It should work, but it's not yet officially supported, so it won't update the loader in the fat partition. And yeah, Race 5, we just started, so if you have a demo board to send, please send it. And of course, if you want to help, there you go. So I think we have maybe one minute for a question. Oh, wow. You were talking about U-Boot, and the U-Boot you have, enough of UE 80s that you should be able to start your operating system. So is BU us not correctly supporting U80 on ARM, or what is missing? Well, so U-Boot supports UFI now, well, which is now, because back then it didn't support it, and so yeah, why not use UFI with U-Boot? Well, because back then it didn't support UFI, and now we just have ARM supports for the UFI code. So yeah, for the newer boards, we will use it, yes. So you get a DVD. Thank you. Okay. Do we have more time? Okay. I see it's really quite a lot of work to get anything working on any platform. Which platform to do work now? Well, basically x86 and 64-bit PC, because it's quite well maintained, that's about it, and we are currently working to fix the ARM port, because there is bootstrapping issues, so yeah, so help welcome. Thanks, and you get a DVD. Thank you.