[prev in list] [next in list] [prev in thread] [next in thread]
List: haiku-development
Subject: [haiku-development] ARM Interest / Changes
From: "Alexander von Gluck IV" <kallisti5 () unixzen ! com>
Date: 2018-08-09 17:00:42
Message-ID: b3d6459a8b8e190b89184b2e00fd8b77 () unixzen ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8" /></head><body><div data-html-editor-font-wrapper="true" \
style="font-family: arial, sans-serif; font-size: 13px;">Good morning! <br><br>Given \
the recent ARM interest, I thought I would chime in with the current state of \
things...<br><br>qemu arm emulation works somewhat with Haiku:<br> qemu-system-arm \
-kernel haiku_loader.ub -initrd haiku-floppyboot.tgz -M raspi2 -m 2G -dtb \
rpi2.dtb<br><br>Output (and our loader menu) is visible on the serial \
tab.<br><br>Currently, the .tgz is failing to load.<br>It used to work, and a few \
people are digging into the cause.<br><br>You can "debug" the qemu virtual machine by \
adding "-s -S" to the command line of qemu.<br>This lets you define breakpoints and \
step through our OS boot via gdb (neat!)<br>I might write an article on how to do \
this if I find the time.<br><br><br>ARM images are now "generic" for any ARMv7 \
device.<br><br>There is a tool to "write" the haiku-arm.mmc image to an sd card for \
using on physical<br>hardware called "rune". You give it the board and it will grab \
the needed u-boot blob and<br>point haiku's loader to the correct FDT blob about the \
board.<br><br><a href="https://github.com/haiku/rune">https://github.com/haiku/rune</a><br><br>Rune's \
only really needed when you want to run Haiku on real ARM hardware.<br>(rpi2 is the \
"best" supported device at the moment... which is why we even use it in \
qemu)<br><br><br>Bootloader woes:<br><br>*NOW* we currently use a "native u-boot" \
haiku_loader.ub. There are a *lot* of limitations<br>around this method given the \
looong history of u-boot and it's interactions with *.ub files.<br>Mainly though \
u-boot doesn't pass much information to haiku_loader.ub beyond the minimal<br>memory \
information. This means we have to "redo everything u-boot did" in our \
haiku_loader.ub<br>(before the kernel even loads)<br><br><u-boot> --> \
boot.scr --> <haiku_loader.ub> -> Haiku<br><br>What this means is we \
start collecting a large number of drivers for things like framebuffers<br>and serial \
ports in our haiku_loader.ub. For \
example:<br><br>https://git.haiku-os.org/haiku/tree/src/system/boot/arch/arm/arch_framebuffer*<br> \
and<br>https://git.haiku-os.org/haiku/tree/src/system/kernel/arch/arm \
/arch_uart*<br><br><br>The solution? uefi! (maybe?)<br><br>Modern u-boot's also \
support "bootefi" to boot .efi binaries. (FreeBSD just moved to this on \
arm)<br><br>The interface for what is passed to uefi binaries is a *LOT* better \
defined. We could theoretically<br>get the framebuffer address, width, height, size, \
and bpp to "use" u-boot's screen setup to sustain<br>us until we can get into the \
kernel... then "real" arm drivers could take over. This would also<br>theoretically \
give us "generic" efi platform code which would work on \
x86,arm,ppc,etc<br><br><u-boot> --> /EFI/BOOT/bootarm.efi (haiku_loader.efi) \
--> Haiku<br><br>So in summary: We use a "u-boot" platform on arm and powerpc \
today. In the future we might<br>transition to efi since it would reduce a lot of \
duplicate code and let us remove a *bunch*<br>of hacks in our loader and kernel to \
support a bunch of essential devices we need early-on in<br>the boot \
process.<br><br>The transition to ARM uefi will take some time (if it happens).. so \
feel free to keep hacking on<br>Haiku ARM using the existing u-boot platform (we can \
work on both in parallel) :-)<br><br> -- Alex<br><signature></signature> \
</div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic