Some hardware (like intel atom based) have UEFI32 firmware but can start 64-bit kernel, would like to be able to boot from such systems.
For code base it means we need to provide multiboot2 trampoline for 32-bit code, which is not that hard; we still only load the 64-bit kernels. The interesting part is later on, when we are implementing access to EFI Runtime Services from kernel - then we need to switch to 32-bit mode and back. EFI System table accesses are also to be done using native (32-bit) pointers.
As a visible change, we will build following binaries:
/boot/boot1.efi will be replaced by two new files:
/boot/loader.efi will also be replaced, by:
For users of the current
boot1.efi, this change is a flag day because we have no automated ESP update and boot code in ESP will need to be updated manually.
Updated by Joshua M. Clulow over 2 years ago
Note that in addition to there being no automated update of the EFI System Partition (ESP) where the
*.efi files are installed, there is also no automated installation at all: this flag day is not likely to affect many (any?) people, because EFI boot support still requires manual installation of files and only works with serial consoles today.
Updated by Electric Monk over 2 years ago
- Status changed from In Progress to Closed
commit 83b4671e6262c5aa6b4f9fb5a384b1946dfc2e7f Author: Toomas Soome <email@example.com> Date: 2018-10-13T15:08:10.000Z 9664 loader: need UEFI32 support Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Reviewed by: Andrew Stormont <email@example.com> Approved by: Gordon Ross <firstname.lastname@example.org>