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 didn’t know he qemu was going to Haiku.
X512 BRAVO !!!
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:
Of course Haiku development should be done on Haiku
I also managed to link module with debugging information, so source code position can be identified from address by
As far as i know main goal is GCC not Clang or LLVM.
If I understand correctly, Port ARM should work on the HAiku x86 compilation infrastructure. This is what developers strive for.
At the moment, the best compiler is LLVM, it compiles concurrently, just like a Java virtual machine
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.
I tried to enable Intel and GPT partition systems, BFS file system and put BFS volume. Then it failed with
Undefined OpCode Exception at https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/partitioning_systems/gpt/gpt.cpp#n96. It seems that QEMU have no FPU support. Does it require some flags or compilation options to enable FVP or Neon instructions?
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.
Is there instructions how to build Haiku with clang? I tried it some time ago, but it didn’t link anything, only compile.
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 use clang from HaikuPorts (version 9.0.1).
I am not familiar with IRC, can you write instructions here or on development guides?
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.
What occurs, precisely?
There’s a page about what IRC channels we have here: https://www.haiku-os.org/community/irc/
Here’s a good introduction to IRC in general: https://yakking.branchable.com/posts/irc/
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.
I added 32 bit kernel support and used
arch_start_kernel from https://git.haiku-os.org/haiku/tree/src/system/boot/arch/arm/arch_start_kernel.S and now it freeze after calling kernel:
It is also suspicious that many boot drivers can’t be loaded, they may be miscompiled. I used boot volume generated by
jam -q @minimal-mmc.
Currently ARM kernel started by EFI loader can’t do debug output. Only easy way to do debug output is framebuffer.
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.
I will continue attempts next day.