Most of this is just the basic workflow for building haiku. This article is complete except for the qemu section which is out of date…
If you’ve dealt with arm, here are our fundamentals…
-
I’m moving our bootloader from a native u-boot loader (haiku_loader.ub) to an EFI binary (haiku_loader.efi). The reasoning is the EFI BIOS services allow us to not pack a bunch of kernel drivers and fdt parsing code within our bootloader. The status here is our bootloader runs under QEMU + Tianocore EFI, but jumping into our kernel isn’t working. see https://twitter.com/kallisti5/status/1291038304633335811 if you want to help out
-
Rune is a tool I wrote to “post-process” our generic arm images for various target boards. The post-processing is mostly grabbing pre-compiled u-boot binaries + SoC blobs and injecting them into our sd card in various places. GitHub - haiku/rune: Haiku MMC image writer for ARM,ARM64
Essentially on ARM:
- Native EFI bios? (not many platforms outside of qemu + tianocore)
- qemu-system-arm -m 1024 -M virt -bios /usr/share/edk2/arm/QEMU_EFI.fd -device virtio-gpu -hda haiku-mmc.image -hdb haiku-minimum.mmc
- two disks because our root filesystem isn’t getting appended within haiku-mmc.image by the build system like it’s supposed to be… known issue.
- haiku-mmc.image boots without any additional modification. (doesn’t need rune tool)
- qemu → tianocore → /EFI/BOOT/BOOTARM.EFI
- qemu-system-arm -m 1024 -M virt -bios /usr/share/edk2/arm/QEMU_EFI.fd -device virtio-gpu -hda haiku-mmc.image -hdb haiku-minimum.mmc
- Raspberry Pi, Rockchip. Allwinner, etc, etc?
- End user uses rune to provision the generic arm image for their own personal hardware.
- u-boot has a built-in FDT our bootloader will need to get and pass to the kernel. Details need more investigation
- SoC → u-boot → bootefi /EFI/BOOT/BOOTARM.EFI
I threw together a diagram of the various processes used to boot Haiku here: