I managed to build and run haiku_loader.efi on QEMU for 32 bit ARM. I used clang and lld-link with arm-unknown-mingw32 target. Unlike current crt0-efi-arm.S that don’t work at all, it allows to produce native PE executables. I don’t know how to integrate clang/lld to Haiku build system, so I copied parts of Haiku sources and build it with shell script. I made some modifications to fix clang build and 32 bit support (currently haiku_loader.efi is only working on 64 bit platforms). I also stubbed vsnprintf, because it crashes with unknown reason.
Currently menu is working, but partition detection and kernel loading is not working.
I fixed printf issues (it was caused by problems with locale tables that is needed to functions like isdigit) and now Haiku boot loader is displayed without glitches:
We aren’t huge fans of the GPL around here so getting rid of gcc is a long term goal of the project. For now gcc is required for BeOS app support and while possibly we could move Haiku only apps over to llvm/clang we haven’t done so as it would make working with gcc2 harder. But in the R2 timeframe gcc will probably get ripped out and replaced by clang and glibc by musl.
GCC is only required for 32 bit GCC2 applications and only it ancient version. GCC4+ ABI (Itanium ABI) applications can be compiled with LLVM/clang preserving binary compatibility. GCC4+ can be replaced with clang/lld without problems.
Haiku built with Clang (on x86_64) currently does not work (you have to use binutils ld to avoid boot-loader death, and then it gets to the kernel but cannot start any userland apps for some unknown reason.) So we definitely need to fix GCC for ARM EFI builds.
Yes, Haiku builds with -march=armv7-a -mfloat-abi=hard, so an appropriate CPU needs to be selected in QEMU probably.
I wrote a guide a while back but looking at it now, it’s clearly outdated, as it doesn’t even mention the linker hacks that are needed to use binutils ld from our crosstools with Clang. You also need a pretty new Clang (>= 8, IIRC) as earlier versions crash and/or miscompile various kernel source files (./configure and ArchitectureRules should validate you are on a new enough Clang though.)
If you really want to attempt it and look into the problems, see me on IRC and I can probably walk you through it.
I managed to make haiku_loader.efi to recognize boot BFS partition and now it can attempt to load kernel (but kernel loading fails). I enabled software FPU build to fix illegal instruction crash.
As for clients, you can use Vision (native Haiku IRC client), IRCCloud.com (allows you to “idle” if you have paid version; free version just makes it possible to log in on any browser or device to the same IRC session), and Freenode has its own webchat too.
The arch_start_kernel looks like it is missing some newer args that x86_64 arch_start_kernel has.
The ARM kernel arch code probably does not know how to write to serial, yes. Does Onscreen Debug Output, which should use the framebuffer to print the syslog, work? (Or does the kernel not start at all?)
Again, it would be easier to work through this on IRC…
I already fixed arch_start_kernel, but not jam doesn’t build boot ARM volume image some unknown reason. There are no compiler errors, but image is not produced, it was produced before. I didn’t change jamfiles.