Based on the reactions in the topic for the ARM port, I’m creating this new topic for tracking the status of UEFI boot for 32-bit Haiku x86.
8 Likes
After some tweaking, the bootloader builds.
Root partition is not recognized so we land on the boot menu.
12 Likes
Steps for rebuilding in case anybody wants to test or join in:
mkdir generated.x86 && cd generated.x86
../configure -j8 --cross-tools-source ../../buildtools --build-cross-tools x86_gcc2 --build-cross-tools x86
jam -j8 -q @minimum-raw esp.image haiku-minimum.image
Testing in qemu:
qemu-system-i386 -enable-kvm -m 2048 -bios /usr/share/edk2/ovmf-ia32/OVMF_CODE.fd \
-hda esp.image -hdb haiku-minimum.image -serial stdio
32-bit edk2 firmware can be found in package edk2-ovmf-ia32 on Fedora Linux.
Edit: as pointed out by tqh the original post contained a wrong file name for hdb
Edit 2: we can add -vga cirrus to the command line above to get a splash screen. (and a smaller default screen resolution which is convenient for me because the qemu screen won’t occlude my terminal. but if anyone more familiar with qemu cli can suggest a better vga setting: please let me know in the comments)
2 Likes
Code changes so far:
- introduce ldscript for EFI x86 - ready for review
- introduce stub functions for arch - ready for review
- fix compilation issue in crt0 - ready for review
- fix compile issues for 32-bit EFI loader - merged
- add build rules for EFI x86 - mostly merged, remaining parts are still a bit messy
- sort out when to enable 32-bit resp 64-bit ELF loading and relocation - cleanup needed
- sort out when to use 32-bit resp 64-bit kernel load address - cleanup needed
I’m using topic efi-x86 on gerrit for now.
Edit: keeping status up to date, as of Dec.02
6 Likes
Nice progress!
1 Like
It seems you are using a 64 bit disk image as hdb. Probably want a 32 bit kernel.
2 Likes
Great work! Would love to try it on my 32 bit x86 EFI sony vaio.
Following this with interest. I have an old Toshiba laptop with a Centrino CPU that is 32 bit. I’m running Linux Mint 19.3 - the last 32-bit Mint version - and will be looking for suitable OS when Mint 19.3 is no longer updated. I like this old Toshiba because it has a real keyboard instead of those gummy “Chiclet” keys.
I’m presently running Haiku Beta 3 and a nightly on another 64-bit laptop.
good observation.
in fact i was trying different images as hdb, and I ended up copying the wrong command line here 
I’m also very interested in this.
I have a Trekstor Wintron 7 tablet which has a 64bit CPU but only a 32bit UEFI so that I can’t boot Haiku.
With only 1GB of RAM (not upgradeable) Linux already hangs when trying to start Xorg so Haiku is probably the last chance to do something with this device.
I’ll definitely be one of the first testers (and I’ll test if 32bit UEFI + 64bit kernel works).
1 Like
I’ve uploaded some more reviews to gerrit - some of them still needs to be cleaned up.
Meanwhile, I did not have much time to investigate the disk read issue.
FYI I get blockIo errors e.g.:
0x7caac648 Partition::Scan(): scan child 0x7caac9d0 (start = 278951286272, size = 557763661824, parent = 0x7caac648)!
0x7caac9d0 Partition::Scan()
check for partitioning_system: GUID Partition Map
ReadAt: blockIo error reading from device!
ReadAt: blockIo error reading from device!
check for partitioning_system: Intel Partition Map
ReadAt: blockIo error reading from device!
check for partitioning_system: Intel Extended Partition
ReadAt: blockIo error reading from device!
ReadAt: blockIo error reading from device!
0x7caac648 Partition::Scan(): scan child 0x7caaca90 (start = 1043241631744, size = 939707131392, parent = 0x7caac648)!
0x7caaca90 Partition::Scan()
Next I’ll try enabling verbose tracing in efi/devices.cpp
2 Likes
A big potential for Haiku is use with older systems with limited RAM and slow CPU’s. I’m running Beta 3 64-bit on a laptop with the AMD E1 CPU, which is a slug like the Intel Atom. With an SSD Haiku runs very well.
1 Like
Haiku runs amazingly fast nearly everywhere.
I once thought Linux was fast,well,compared to Windows it actually is,but I was really impressed by how much faster Haiku is compared to Linux.
Anyway,it’s also fun on a 8-core i7 and 32GB of RAM (my Haiku desktop) 
1 Like
If linux is the best thing you have experienced, because it is the best thing you have seen so far, it doesn’ tells anything about linux, but only about you,
The question was alwas: do you want to live with this boundary conditions or not.
From this point this is a decision, a subjective one which have influence on the future.
Do you want your child to work with unixen or not.
Make an educated decision.
I multiboot Win 10 and Linux Mint 20.3 on my desk top. The only reason I use Window$ is to run my income tax program once a year and occasionally some other apps that don’t have Linux equivalents.
Multiboot capability turns “or” into “and” and that is what I like about Linux.
That said, the return of BeOS in its Haiku reincarnation is much welcomed. I’m going to contribute because I see Haiku as a promising alternative to bloatware.
1 Like
Can we get a separate thread for the anti-*nix campaign?
Anyway, I am looking forward to have Haiku on my RPi 3.
2 Likes
I think we should avoid this anti-*nix comments altogether. In fact please stop anti comments altogether, it makes me and probably some other devs tired. I know you can do better than that.
13 Likes
Getting back to the original topic… the disk IO issue seems to be related to alignment in EFI block IO protocol structure.
If I re-align it, the bootloader is able to find kernel_x86.
I also added some very basic start code for “jumping to the kernel”
Results are not so beautiful yet:
the kernel corrupts the splash screen and then throws us in a repeated reboot.
Of course the MMU is not initialized so that might be a next step.
Some logs:
load kernel kernel_x86...
ucode_load: system/data/firmware/intel-ucode/06-06-03
ucode_load: couldn't find microcode
maximum boot loader heap usage: 332168, currently used: 323672
kernel:
text: 0x7c8ae000, 0x1a5000
data: 0x7ca53000, 0x59000
entry: 0x7c909f50
Kernel stack at 0x7c3bd000
System provided memory map:
(... a lot of memory areas are listed here...)
Calling ExitBootServices. So long, EFI!
ABabxycCD
Y^
Y^
Y^[david@fedora generated.x86]$
The ABabxycCD logs are generated with out8(x, 0x3f8); at various points in the kernel code e.g. init_serial_port() etc. so we can see that at least the kernel entry point is actually invoked.
15 Likes
Some more fun with the build environment and the Jam files:
the legacy and non-legacy toolchain seems to be mixed together in the bootloader build process.
.cpp files are compiled with non-legacy
.S files are compiled with legacy
BootMergeObject uses legacy
not sure about linking and objcopy
There are also linker crashes.
Trying to untangle this…
4 Likes
Once I add some very basic page table initialization code, the kernel can at least print out some debug messages.
arch_enter_kernel(cr3: 0x7c135000, kernelArgs: 0x7ebccd60, kernelEntry: 0x7c9c7d60, sp: 0x7c43a000)
Welcome to kernel debugger output!
Haiku revision: hrev55709+12+dirty, debug level: 2
CPU: no microcode provided
reserve_io_interrupt_vectors: reserved 2 vectors starting from 98
CPU 0: type 0 family 6 extended_family 0 model 6 extended_model 0 stepping 3, string 'GenuineIntel'
CPU 0: vendor 'Intel' model name 'QEMU Virtual CPU version 2.5+'
No CPU topology information available.
CPU 0: apic id 0, package 0, core 0, smt 0
CPU 0: features: fpu de pse tsc msr pae mce cx8 apic sep pge cmov pat mmx fxsr sse sse2 sse3 x2apic hypervisor
CPU 0: patch_level 0
reserve_io_interrupt_vectors: reserved 16 vectors starting from 0
using 32 bit paging (PAE not needed)
PANIC: page fault, but interrupts were disabled. Touching address 0x80800000 from ip 0x8015637c
Welcome to Kernel Debugging Land...
16 Likes