UEFI Haiku boot loader for x86 (32-bit)

You can try building from my github dev branch: (if you’re familiar with Haiku build process)
https://github.com/davidkaroly/haiku/tree/efi-x86

2 Likes

short update:
most of my patches have been merged, so the nightly builds starting from hrev55835 now contain the 32-bit haiku_loader.efi

no SMP yet
also not much testing done so far

14 Likes

Is it supposed to present in x86_64 images too? Doesn’t look like it’s there yet. I’m on hrev55835.

~> ls file /boot/system/data/platform_loaders/haiku_loader.efi
/boot/system/data/platform_loaders/haiku_loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
~> ls -1 /system/data/platform_loaders
haiku_loader.bios_ia32
haiku_loader.efi
haiku_loader.pxe_ia32

it should be there in the 32-bit x86 image.

2 Likes

Just had a look at booting this on my 32 bit EFI laptop and it’s currently intel partitioned, so I need to backup and wipe it… which means I need to put some more time aside for it

Hey,
what would be the correct way to create a boot medium for 64bit and 32bit efi?
Do they for example have different fallback paths to be used?

Would like to figure thus out for #17107 (Installer: add "whole drive" (anyboot like) install mode) – Haiku

Edit: the efi spec also sais mobile boot has to support fat16, and can support fat32.

Should we use fat16 for thumb drives? What is the bootloader support actually like?

Actually, If your EFI partition is small, it will be formatted in FAT16 by default. It doesn’t matter but you don’t need a huge EFI partition either.

Uhh, what do you mean by that? There is no automatism in partitioning, these are seperate partition types. (and we don’t neccesarilly want to make it small at all, the esp may hold multiple bootloaders (maybe other OS, or severall from us))

In fact, when you chose a FAT partition type you really chose between very old (before LBA addressing) and recent. It is when you format that tools usually default to the right one depending of your media size.
FAT16 limit is 32Mo and the files there are mainly loaders so rather small files. I.e. grub loader is about 160ko and all different linux kernels are in /boot on linux root partition.
Otherwise, you can have an EFI partition almost as large as you want.
EFI partition type is a special type accepting FAT12, FAT16 and FAT32.
So the only problem is to know if FAT32 support is implemented in the EFI BIOS the user have. UEFI BIOS should, older EFI not always.

Is it possible to use a 64 bit Haiku on a Baytrail system (it’s also 64 bit but with 32 bit UEFI)?

Since the haiku efi loader on x64 haiku image is 64 bit only, if it works then it’s certainly a 64 bit UEFI BIOS.

I’m asking because I have a Baytrail tablet I’d like to use for Haiku. Before I delete Android, I’d like to know if it’s going to work.

To run the 64 bit version of Haiku on a 64 bit tablet but with a 32 bit EFI, Haiku would need to support that. From your answer, I conclude that’s not the case?

No. Actually Haiku 64 bit efi loader boots only 64 bit Haiku. The new 32 bit efi loader only boots 32 bit Haiku.
Anyway, if you can boot from an external device, it would be preferable to make tests before any attempt.

GPT partition types have nothing to do with partitioning schemes. You can use whatever you want as your esp aslong as the firmware can read it.
The efi spec sais fat16 has to be supported for usb boot while 32bit /can/ be supported.

I didn’t talk about partitioning schemes, only partition formats.
Note that UEFI is not GPT only and you can use either Intel partitioning scheme or GPT. The only thing is that in Intel partitioning scheme ESP has to be a primary partition.
According to wikipedia on removable media, it has to be one of these. On fixed drive FAT32 is expected. Though, as always, Apple has done and is still doing differently.

The bootloader doesn’t care. It is loaded by EFI and then it never needs to access the EFI partition.

All our drives so far have shipped with FAT32 and I see no reason to change that.

For me the process would be:

  • Create a GPT partition table
  • Add an EFI system partition and format it to FAT32
  • Copy the bootloader file (BOOTX64.EFI to the right place). That file is available in /system/data/boot I think
  • Create and format a BFS partition
  • Run the installer process as usual

There are already various steps in Installer to run makebootable on a partition and things like that. Probably another one can be added to format and mount the target drive before starting the install process.

Maybe as an intermediate step, allow Installer to work on an unformatted partition and automatically format and mount it before starting the file copy?

2 Likes

Sorry, I ment the firmware with “bootloader” here, maybe that was worded a bit unclear.

The reason I mentioned above was that the EFI spec mandates FAT16 but not FAT32 for usb sticks for booting, that is why I want to know what support by hw is like. To see whether this is a problem in practice.

In this thread someone mentioned the 32bit efi loader can only load 32bit haiku, i guess we then just need to add efi to the 32bit image aswell untill it can load a 64bit haiku too? (I guess that case would be more complex)

The Apple M1 Mac Studio comes with an Intel-based GPT SSD setup. The issue today is most distros don’t have the GPU driver.

The open-source aarch64 workstations (using Nvidia or AMD graphic cards) may help as a more preferred dev platform.

someone mentioned the ‘hybrid boot’ in an other topic, i.e. booting kernel_x86_64 from 32-bit EFI so I thought I give it a try.

first attempt:

  • load 64-bit kernel from the 32-bit EFI loader
  • set up initial page tables
  • switch to long mode
  • jump to kernel :sunglasses:

at least I can get some debug output:

Calling ExitBootServices. So long, EFI!
Switched to legacy serial output
long_enter_kernel(pageDirectory: 0x7bdc6000, kernelArgs: 0x8270e000, kernelEntry: 0x800644c0, sp: 0x8270e000, gBootGDTDescriptor: 0x7e6dc0e4)
ABCDEFGHWelcome to kernel debugger output!
Haiku revision: hrev56443+4+dirty, debug level: 2
CPU: no microcode provided
CPU 0: type 0 family 15 extended_family 0 model 11 extended_model 6 stepping 1, 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 mtrr pge mca cmov pat pse36 clfsh mmx fxsr sse sse2 sse3 cx16 x2apic hypervisor syscall nx long 
CPU 0: patch_level 0
reserve_io_interrupt_vectors: reserved 16 vectors starting from 0
PANIC: error allocating early page!

Welcome to Kernel Debugging Land...
Thread 0 "" running on CPU 0
stack trace for thread 0 ""
    kernel stack: 0x0000000000000000 to 0x0000000000000000
frame                       caller             <image>:function + offset
 0 ffffffff8270d988 (+  24) ffffffff8014524c   
 1 ffffffff8270d9a0 (+  80) ffffffff800aeab8   
 2 ffffffff8270d9f0 (+  96) ffffffff800b00d3   
 3 ffffffff8270da50 (+  80) ffffffff800b046e   
 4 ffffffff8270daa0 (+ 240) ffffffff800b07c7   
 5 ffffffff8270db90 (+  96) ffffffff80128745   
 6 ffffffff8270dbf0 (+  96) ffffffff801172f6   
 7 ffffffff8270dc50 (+ 176) ffffffff801177ef   
 8 ffffffff8270dd00 (+ 176) ffffffff80118858   
 9 ffffffff8270ddb0 (+  48) ffffffff80114790   
10 ffffffff8270dde0 (+  96) ffffffff8011cff2   
11 ffffffff8270de40 (+  80) ffffffff8011c281   
12 ffffffff8270de90 (+ 128) ffffffff8011485c   
13 ffffffff8270df10 (+ 176) ffffffff8012a21b   
14 ffffffff8270dfc0 (+  48) ffffffff8006463c   
15 ffffffff8270dff0 (+2106531856) 000000000000a090   
kdebug> [david@fedora generated.x86]$ 

command line:

qemu-system-x86_64 -enable-kvm -m 2048 \
  -bios /usr/share/edk2/ovmf-ia32/OVMF_CODE.fd \
  -hda objects/haiku/x86_gcc2/release/efi/system/boot/esp.image \
  -hdb ../generated.x86_64/haiku-minimum.image -serial stdio -vga cirrus

my dev branch on github - not for the faint-hearted as the code is rather ugly at this point:
https://github.com/davidkaroly/haiku/tree/hybrid-boot

so as a first impression it’s probably not very difficult to get this mixed mode boot working

edit: after applying a few more hacks, I was able to get a successful boot to desktop in qemu. (no SMP, no error checking yet)
Still, it will be a good question how to integrate this mixed-mode boot in upstream Haiku sources.

18 Likes

I tried the other way round on various MacBooks to no avail. It would be great to let both Haiku 32 and 64bit boot with a 64bit EFI loader. Would it be possible?
PS: all MacBooks have 64bit EFI except some early models produced in 2006 (maybe 2007) when Apple switched from PPC to Intel. AFAIK all models from 2008 onwards support 64bit EFI only

1 Like