Qemu does support 32 bit UEFI on x86 if you give it correct UEFI firmware.
4 Likes
ok it’s definitely not impossible.
first attempt:
i was able to get the 32-bit EFI loader to compile.
it prints “Welcome to the Haiku boot loader!” and then we get a qemu internal error.
if there’s demand for this 32-bit x86 EFI loader, I can try to put some more effort into it. (please let me know by hitting that like button etc.)
Edit: based on the reactions I created a separate topic.
23 Likes
Not so much going on in the ARM port recently, but there’s some good news:
my patches for UART initialization based on FDT have been merged in upstream repo. (thanks to the reviewers!)
I was also able to do a bootstrap build earlier this week (with a workaround for dirent in make_bootstrap recipe), next I’d like to run the unbootstrap script.
12 Likes
New patches available for detecting interrupt controller type and address from FDT, similarly to UART.
e.g.
Chosen UART:
kind: pl011
regs: 0x9000000, 0x1000
irq: 1
clock: 24000000
Chosen INTC:
kind: gicv2
regs: 0x8000000, 0x10000
0x8010000, 0x10000
I also did an un-bootstrap, resulting in a bunch of hpkg files… @PulkoMandy @kallisti5 can you advise me on the next steps please?
5 Likes
You need to run this on them https://github.com/haiku/haiku/blob/master/3rdparty/pulkomandy/unbootstrap.sh I put it in a dir in a Haiku install and edited the paths in the script and it ran fine.
2 Likes
Yes I ran unbootstrap.sh already. I gave it the *_bootstrap packages and I got similar packages with the _bootstrap tag removed.
If I understand the build process right, these packages could be used then for regular (non-bootstrap) builds… but how? e.g. I’d like the regular build to pick up the new gcc_syslibs package so that the softfloat libs are available.
@kallisti5 setup a place to upload them, and then after some magic from him, they will be downloaded and used as part of the build process. So I think you need his skills now…
3 Likes
Correct. It’s not automated, but is a good secure place to upload bootstrap packages so we can shuffle them around and get them in the correct places.
@davidkaroly, Prerequirements:
- i’ll need your gerrit id to set this up.
- You’ll need you make sure your account has SSH keys configured / setup.
Once these are in place, you’ll have sftp (ssh ftp) access to submit@limerick.ams3.haiku-os.org:1099 to upload these packages.
2 Likes
Seems soon should add a secondary Arm page to nightly builds …
EDIT : fixed typo.
2 Likes
I tried the SFTP server today. I’m able to log in but I get permission error for root folder.
Can you double-check?
Oops, that’s my fault. Fixed.
Thank you, now it works fine.
I’ve uploaded the unbootstrapped packages to /build-packages/arm
3 Likes
Anyone tried a bootstrap build recently (for any architecture) i.e. since the switch to gcc-11?
I get failed configure scripts because of an ICE
arm-unknown-haiku-gcc: internal compiler error: in do_spec_1, at gcc.c:5971
reproducible from the command line, it happens if I don’t give any output file name to gcc with -o flag.
This works:
[david@fedora gcc_bootstrap-8.3.0_2019_05_24-obj]$ arm-unknown-haiku-gcc -c test.c
[david@fedora gcc_bootstrap-8.3.0_2019_05_24-obj]$ arm-unknown-haiku-gcc -o test test.o
But these given an error:
[david@fedora gcc_bootstrap-8.3.0_2019_05_24-obj]$ arm-unknown-haiku-gcc test.c
arm-unknown-haiku-gcc: internal compiler error: in do_spec_1, at gcc.c:5971
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[david@fedora gcc_bootstrap-8.3.0_2019_05_24-obj]$ arm-unknown-haiku-gcc test.o
arm-unknown-haiku-gcc: internal compiler error: in do_spec_1, at gcc.c:5971
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[david@fedora gcc_bootstrap-8.3.0_2019_05_24-obj]$Maybe this is not entirely right?
#define LINK_SPEC "%{!o*:-o %b} -m armelf_haiku %{!r:-shared} %{nostart:-e 0} %{shared:-e 0} %{!shared: %{!nostart: -no-undefined}}\
%{mbig-endian:-EB} %{mlittle-endian:-EL} -X"
The part with %{!o*:-o %b} in particular is really suspicious to me.
As I was able to decode it, it instructs gcc to invoke ld with “-o output_file_basename” if -o flag is NOT specified.
However, there’s the following comment in gcc.c near the line where we got the ICE:
case 'b':
/* Don't use %b in the linker command. */
gcc_assert (suffixed_basename_length);
Also this %{!o*:-o %b} is not present on the i386. (not sure about RISC-V though, as it has this suspicious clause in LINK_SPEC but maybe no one tried yet RISC-V bootstrap on gcc-11?)
Edit: the clause in question was removed from i386 in 2009 in commit #beaf9299f
If I remove it from gcc/config/arm/haiku.h, the bootstrap get going again, at least it won’t stop with ICE in the configure script. It will take a bit more time to see if it can finish successfully…
1 Like
The patch for -o was for the case where you do “gcc somefile.cpp”. In gcc2 this gives you an executable named “somefile”. In modern gcc this gives you “a.out” instead.
It is not really needed, and indeed our gcc8 (and I assume our gcc11) for x86 does not have this patch anymore. So you can remove it if it doesn’t work correctly.
1 Like
I haven’t updated this topic recently, but meanwhile there was some progress in the background… combatting some regressions, then re-doing the bootstrap build and the “unbootstrapping” with help from Kallisti5.
Now it’s possible to build ARM images from git master, with up to date packages.
The bootloader is still a mess: most of the memory is identity-mapped, the page tables are full of temporary stuff, so that’s a quite straightforward next step to clean it up…
7 Likes
On RISC-V I identity map boot loader memory. Unused parts are freed by kernel later.
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/arch/riscv64/arch_mmu.cpp#n391
2 Likes
Yes I’ve seen it, in fact I used it as a starting point for the ARM memory map 
It’s a bit different on 32-bit arch though, as we don’t have so much virtual address space. The kernel starts at 0x80000000 so basically we can use half of the address space.
e.g. on qemu the physical memory starts at 0x40000000 so even with >1G the memory ranges start to overlap if I use identity mapping.
2 Likes
One more problematic area is the EFI runtime services.
I guess they should be mapped in somehow but I really don’t know what are the requirements.
e.g. do we want to call EFI runtime from the kernel at all.
We want, for example to control boot menu, but it is currently not implemented (x86_64 too).