I managed to get some serial output for kernel on ARM32:
Calling ExitBootServices. So long, EFI!
VirtioNetExitBoot: Context=0x4DECB110
VirtioBlkExitBoot: Context=0x4EF74190
VirtioBlkExitBoot: Context=0x4EF7D710
SetUefiImageMemoryAttributes - 0x000000004F928000 - 0x0000000000006000 (0x0000000000000000)
SetUefiImageMemoryAttributes - 0x000000004F922000 - 0x0000000000006000 (0x0000000000000000)
SetUefiImageMemoryAttributes - 0x000000004F91C000 - 0x0000000000006000 (0x0000000000000000)
SetUefiImageMemoryAttributes - 0x000000004F915000 - 0x0000000000007000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000004F90C000 - 0x0000000000009000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000004F900000 - 0x000000000000C000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000004F8FA000 - 0x0000000000006000 (0x0000000000000000)
SetUefiImageMemoryAttributes - 0x000000004F8F4000 - 0x0000000000006000 (0x0000000000000000)
Kernel entry point
Welcome to kernel debugger output!
Haiku revision: hrev55144+82+dirty, debug level: 2
INIT: init CPU
INIT: init interrupts
INIT: init VM
PANIC: vm_allocate_early: could not allocate virtual address
Welcome to Kernel Debugging Land...
Running on CPU 0
Current thread pointer is 0x4c23c848, which is an address we can't read from.
frame caller <image>:function + offset
0 4c1f15c4 (+ 0) 00000021
kdebug>
I enabled -fpic, -shared like in riscv64, used riscv64 linker script keeping ARM part at beginning, and identity mapping (set vaddr to addr in platform_allocate_region()).
I think that riscv64 version will be fine until some issues will be found (random crashes in unrelated places etc.).
It will be nice to write page table setup code like this. It will allow to use existing ARM kernel VMTranslationMap code. Otherwise kernel-user address range swapping (declared here) and kernel page table code adjustments will be needed.
That will require ARM versions of LookupPte() and Map() functions. riscv64 version:
I’lm interested on the progress of this port to ARM. Planning on getting a Pinebook Pro, which uses an ARM Hexa-Core Rockchip RK3399, 4GB RAM, and with option to add an NVMe drive, to do some tinkering.
It would be nice to test ARM Port on such device once it becomes available again.
I have a Pinebook Pro, myself. I’d also like to see Haiku on it. The only point of disagreement with me is that the NVMe adapter draws more power than the current model of PBP can source with its battery pack when used. I’d rather see a small FPGA board to accelerate legacy graphics cores like the AGA chipset from my Commodore Amiga 1200 via the MiniMig core. Building up something modern using an Intel Cyclone 10 series could start using drivers for that. Its core is fully reverse engineered already, though dated.
Actually, the Mali Bifrost driver is open source now also. A 3D booster might be better based on its design.
Same here except my 64-bit ARM is a PineBook Pro, as mentioned, with a RockChip Rk3399. I have several ARM7 32 bit machines as well: ODroid XU4, Cubox i4p and Raspberry Pi 2.
I was able to compile for ARM! I ran qemu with qemu-system-arm -bios /usr/lib/u-boot/qemu_arm/u-boot.bin -M virt -cpu cortex-a15 -m 1024 -hda esp.image -hdb haiku-minimum.image -device ramfb -usb -device qemu-xhci,id=xhci -device usb-mouse -device usb-kbd -serial stdio and was able to see the Haiku boot menu in the console! It was a very exciting moment. However, it couldn’t find any boot volumes. Did I miss something?