Can you replace “-hda esp.image -hdb haiku-minimum.image” with
-device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 \
-device virtio-blk-device,drive=x1,bus=virtio-mmio-bus.1 \
-drive file="esp.image",if=none,format=raw,id=x0 \
-drive file="haiku-minimum.image",if=none,format=raw,id=x1 \
?
I ran:
qemu-system-arm -bios /usr/lib/u-boot/qemu_arm/u-boot.bin -M virt -cpu cortex-a15 \
-m 1024 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 \
-device virtio-blk-device,drive=x1,bus=virtio-mmio-bus.1 \
-drive file="esp.image",if=none,format=raw,id=x0 \
-drive file="haiku-minimum.image",if=none,format=raw,id=x1 -device ramfb -usb -device qemu-xhci,id=xhci -device usb-mouse -device usb-kbd -serial stdio
Same result, no boot volume.
Can you try EDK2 instead of u-boot?
I’m not sure how to do that.
$ find /usr -name *edk2*
/usr/share/qemu/firmware/50-edk2-x86_64-secure.json
/usr/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json
/usr/share/qemu/firmware/60-edk2-arm.json
/usr/share/qemu/firmware/60-edk2-aarch64.json
/usr/share/qemu/firmware/60-edk2-x86_64.json
Using “edk2-arm” for the -bios argument resulted in “Could not find ROM image ‘edk2-arm.json’”, and opening the JSON file had:
"mapping": {
"device": "flash",
"executable": {
"filename": "/usr/share/AAVMF/AAVMF32_CODE.fd",
"format": "raw"
},
"nvram-template": {
"filename": "/usr/share/AAVMF/AAVMF32_VARS.fd",
"format": "raw"
}
},
Should the JSON file work, or would I use one (both?) of these .fd files? There wasn’t anything with edk2 in my distribution’s repository.
I used this (but different version): https://opensuse.pkgs.org/15.3/opensuse-oss-aarch64/qemu-uefi-aarch32-202008-8.1.noarch.rpm.html.
Only “qemu-uefi-aarch32.bin” file is needed.
I was able to extract “qemu-uefi-aarch32.bin” from the RPM, and I get an image which looks unaligned or somehow corrupted.
The console has (which I assume is the transition from the firmware image to Haiku):
Calling ExitBootServices. So long, EFI!
SetUefiImageMemoryAttributes - 0x000000007F95A000 - 0x0000000000006000 (0x0000000000000000)
SetUefiImageMemoryAttributes - 0x000000007F953000 - 0x0000000000007000 (0x0000000000000000)
SetUefiImageMemoryAttributes - 0x000000007F94C000 - 0x0000000000007000 (0x0000000000000000)
SetUefiImageMemoryAttributes - 0x000000007F945000 - 0x0000000000007000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007F93C000 - 0x0000000000009000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007F92F000 - 0x000000000000D000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007F929000 - 0x0000000000006000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007F923000 - 0x0000000000006000 (0x0000000000000008)Maybe selecting other video mode in boot loader may help?
It didn’t get that far. I didn’t see anything in the boot loader menu.
Looking further up the qemu output, there is this: Could not open option rom 'vgabios-ramfb.bin': No such file or directory. I’ll look for that file. My distro’s vgabios package doesn’t have it. I’ll check that rpm repo you mentioned.
You did. This is the splash screen. The menu was skipped because the boot partition was found this time. To access the menu you need to press space repeatedly.
I have this issue with running Windows in QEMU too. It looks like QEMU does not like when the running code tries to change the display resolution and will keep its old window size. I have not fully investigated this yet, usually rebooting the virtual machine ends up with the correct resolution on the second try for me…
Days passed, with rencent updates, I couldn’t got haiku cross compiled for arm. it shows that libsover headers is missing. 
and I start trying bootstrap compile, but it also failed when building gcc_bootstrap for HaikuPortsCross no matter with 2019 or 2021 verions, issues as the same:
/home/kurain/build/haiku/generated.arm/cross-tools-arm/lib64/gcc/arm-unknown-haiku/8.3.0/../../../../arm-unknown-haiku/bin/ld: error: /home/kurain/build/haiku/generated.arm/objects/haiku/arm/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2021_02_27/boot/cross-sysroot/arm/boot/system/develop/lib/init_term_dyn.o uses VFP register arguments, ./libgcc_s.so.1.tmp does not
/home/kurain/build/haiku/generated.arm/cross-tools-arm/lib64/gcc/arm-unknown-haiku/8.3.0/../../../../arm-unknown-haiku/bin/ld: failed to merge target specific data of file /home/kurain/build/haiku/generated.arm/objects/haiku/arm/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2021_02_27/boot/cross-sysroot/arm/boot/system/develop/lib/init_term_dyn.o
collect2: error: ld returned 1 exit status
make: *** [Makefile:985: libgcc_s.so] ErrorI have got the reason, it’s caused by the gcc-bootstrap recipe for bootloader from Haikuports.cross:
## BOOTLOADER libgcc + libsupc++
local bootCcFlags
if [ $effectiveTargetArchitecture == arm ]; then
# EFI arm (32-bit) requires software fp
#bootCcFlags+="-mfloat-abi=soft";
fi
# build bootloader version of libgcc and libgcc_eh.a (no threads, TLS)
cd $objectsDir/$effectiveTargetMachineTriple/libgcc
mkdir -p saved
mv libgcc.a libgcc_eh.a libgcc_s* libgcov* libgcc-kernel.a libgcc_eh-kernel.a saved/
make clean
ln -sfn "$sourceDir/libgcc/gthr-single.h" gthr-default.h
make CFLAGS="-O2 $bootCcFlags" CXXFLAGS="-O2 $bootCcFlags"
mv libgcc.a libgcc-boot.a
mv libgcc_eh.a libgcc_eh-boot.a
mv saved/* .
rmdir saved
I will try to figure out how to rebuild these files(init_term_dyn.c, and referring needed for bootloader version of libgcc) for arm platform 
This is where I ended arm work, when I found out I needed to recompile all boot dependencies for soft-float. It was recommended to switch to ARM64 as it is more uniform hardware wise. So UEFI on Arm states FPU should not be used at boot so you need softfpu. On ARM64 says FPU can be used at boot.
I can try to answer any questions along the way here, so keep up the good work.
with jam, could we built the files(init_term_dyn, crti, crto etc) twice with different float-abi required by libgcc & libgcc_eh for uboot and kernel ?
and then we link the final static libs when building gcc-bootstrap.
You can do anything you want
Currently these are built in src/system/glue with a single call to MergeObject. Two different invocations of MergeObject would be needed, making sure the second one uses bootloader compile flags. Conveniently, we have a BootMergeObject rule that will do exactly this.
So, it would be something like this:
MergeObject <$(architecture)>glue_common.o : $(sources) ;
BootMergeObject <boot>glue_common.o : $(sources) ;
This gets you the required variant of glue_common. Now you need to use it.
The glue code to use is defined in various places, mainly build/jam/ArchitecturesRules where we set variables like HAIKU_LIBRARY_BEGIN_GLUE_CODE and HAIKU_LIBRARY_END_GLUE_CODE.
The code is split in a “begin” part (executed when loading the executable or library) and an “end” part (when unloading it). There are various types, currently I see LIBRARY, EXECUTABLE, and KERNEL_ADDON. You would need to define a new type BOOT, I guess, and use that when linking your bootloader files?
However, I don’t see these files currently used for any boot thing. When creating bootloader executables, there is no standard init code that is put before the “main” entry point of the program, instead, the similar initializations are done manually in a piece of assembler code specific to the bootloader. I’m not sure if trying to use these standard init_term_dyn.c files in the bootloader makes sense?
When running the last command line, I’m getting this error (after I installed jam using apt):
You can only build Haiku with Haiku’s Jam, not Perforce Jam or some other variant (you are using 2.6.1).
So I guess installing it was a bad idea 
How am I supposed to use Haiku’s Jam?
Found how to build haiku’s jam, now I’m getting this error when running jam:
Starting build of type minimum …
Building Haiku Minimum Target
AddHaikuImagePackages: package openssl not available!
build-feature packages unavailable on arm: giflib glu mesa ffmpeg fluidlite libvorbis fontconfig gutenprint webkit libpng libicns jasper jpeg libedit qrencode_kdl tiff openexr libdvdread libdvdnav libwebp live555 zstd
AddHaikuImagePackages: package bc not available!
AddHaikuImagePackages: package icu66 not available!
ERROR: AddBootModuleSymlinksToContainer: Can’t create a symlink to target “fdt”.
ERROR: Add*ToContainer has not been invoked for it yet.
Hello everyone,
How’s it going with the ARM porting effort?
I tried the current source code from haiku repo and I was able to get it to progress to the 4th icon on the splash screen… had to do a bit of hacking on the MMU setup and the ELF loader though 
Any suggestion what I could try as a next step?
From the look of it, try to figure out how to get pci module for ARM working. It seems to want pci x86 module.
No, that’s just AHCI looking for the x86 module to configure MSIs. We need to get rid of that code anyway as ARM and RISCV have MSIs, too, but for now it can just be ignored.
Wow, that’s awesome! Can you submit your changes for review?
The next step would probably be to just use virtio storage in QEMU to get the boot process further; we can revisit that later when we need to.
(Also, feel free to find us on IRC/Matrix/etc., or join the open meeting room for the sprint.)