Skip to content
GitLab
Closed
Issue created by nl6720@nl6720Developer

Support IA32 UEFI

From https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_firmware_bitness:

Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a EFI application corresponding to the UEFI firmware bitness/architecture.

The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 UEFI firmware. The only known devices that use IA32 (32-bit) UEFI are older (pre 2008) Apple Macs, Intel Atom System-on-Chip systems as on 2 November 2013 and some older Intel server boards that are known to operate on Intel EFI 1.10 firmware.

An x86_64 UEFI firmware does not include support for launching 32-bit EFI applications (unlike x86_64 Linux and Windows versions which include such support). Therefore the EFI application must be compiled for that specific firmware processor bitness/architecture.

Until Linux 5.7 the only way to boot a x86_64 kernel on IA32 UEFI was to use a boot loader that didn't rely on the kernel's EFI stub. Those would be GRUB and syslinux. As was discovered in FS#53182, syslinux does not work on real IA32 UEFI, so the only real option was GRUB.

Linux 5.7 EFI stub added support for booting a x86_64 kernel on IA32 UEFI. This new booting method needs to be supported by the boot loader/manager and the initrd must be specified in a UEFI variable, not using the initrd= in kernel's command line. This new method has been implemented in EDK2 OVMF (starting from version 202005 when built with LOAD_X64_ON_IA32_ENABLE, commit & bug), so it can be tested using OVMF's builtin UEFI shell.

So the options for archiso are:

  1. Use GRUB.
  2. Ship a IA32 UEFI shell and let users specify the kernel cmdline manually, or provide a startup.nsh like 6caa5bcb did in the past 😄 .
  3. Waiting until systemd-boot implements support for mixed mode boot: https://github.com/systemd/systemd/issues/17056 .

1 is not an option since we all dislike GRUB. 2 is not optimal because UEFI shell's initrd command support sspecifying only one file, but we have at least 3 (the main one and two microcode images). That only leaves us with 3, so we'll just need to wait on systemd.

See https://bugs.archlinux.org/task/53182 for previous discussion.

Edited by nl6720
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information