Good morning!
Given the recent ARM interest, I thought I would chime in with the current
state of things...
qemu arm emulation works somewhat with Haiku:
qemu-system-arm -kernel haiku_loader.ub -initrd haiku-floppyboot.tgz -M raspi2
-m 2G -dtb rpi2.dtb
Output (and our loader menu) is visible on the serial tab.
Currently, the .tgz is failing to load.
It used to work, and a few people are digging into the cause.
You can "debug" the qemu virtual machine by adding "-s -S" to the command line
of qemu.
This lets you define breakpoints and step through our OS boot via gdb (neat!)
I might write an article on how to do this if I find the time.
ARM images are now "generic" for any ARMv7 device.
There is a tool to "write" the haiku-arm.mmc image to an sd card for using on
physical
hardware called "rune". You give it the board and it will grab the needed
u-boot blob and
point haiku's loader to the correct FDT blob about the board.
https://github.com/haiku/rune ;(https://github.com/haiku/rune)
Rune's only really needed when you want to run Haiku on real ARM hardware.
(rpi2 is the "best" supported device at the moment... which is why we even use
it in qemu)
Bootloader woes:
*NOW* we currently use a "native u-boot" haiku_loader.ub. There are a *lot* of
limitations
around this method given the looong history of u-boot and it's interactions
with *.ub files.
Mainly though u-boot doesn't pass much information to haiku_loader.ub beyond
the minimal
memory information. This means we have to "redo everything u-boot did" in our
haiku_loader.ub
(before the kernel even loads)
<u-boot> --> boot.scr --> <haiku_loader.ub> -> Haiku
What this means is we start collecting a large number of drivers for things
like framebuffers
and serial ports in our haiku_loader.ub. For example:
https://git.haiku-os.org/haiku/tree/src/system/boot/arch/arm/arch_framebuffer*
and
https://git.haiku-os.org/haiku/tree/src/system/kernel/arch/arm /arch_uart*
The solution? uefi! (maybe?)
Modern u-boot's also support "bootefi" to boot .efi binaries. (FreeBSD just
moved to this on arm)
The interface for what is passed to uefi binaries is a *LOT* better defined. We
could theoretically
get the framebuffer address, width, height, size, and bpp to "use" u-boot's
screen setup to sustain
us until we can get into the kernel... then "real" arm drivers could take over.
This would also
theoretically give us "generic" efi platform code which would work on
x86,arm,ppc,etc
<u-boot> --> /EFI/BOOT/bootarm.efi (haiku_loader.efi) --> Haiku
So in summary: We use a "u-boot" platform on arm and powerpc today. In the
future we might
transition to efi since it would reduce a lot of duplicate code and let us
remove a *bunch*
of hacks in our loader and kernel to support a bunch of essential devices we
need early-on in
the boot process.
The transition to ARM uefi will take some time (if it happens).. so feel free
to keep hacking on
Haiku ARM using the existing u-boot platform (we can work on both in parallel)
:-)
-- Alex
