On 21.04.25 13:30, Mark Kettenis wrote:
From: Heinrich Schuchardt <heinrich.schucha...@canonical.com>
Date: Mon, 21 Apr 2025 11:43:10 +0200
Hi Heinrich,
Distros expect the EFI boot manager to run. It falls back to launching
EFI\BOOT\BOOT<ARCH>.EFI from the ESP.
BOOTMETH_EFILOADER is obsolete.
I don't think this is true yet. For one thing, on my Apple systems I
still get:
** Booting bootflow 'n...@34bcc0000.blk#1.bootdev.part_4' with efi
There is also a bug in the EFI boot manager:
[RFC 1/8] boot: EFI boot manager does not depend on BootOrder
https://lore.kernel.org/u-boot/20250421162555.1200687-2-heinrich.schucha...@canonical.com/T/#u
even though
CONFIG_BOOTMETH_EFI_BOOTMGR=y
Not sure what's going on here yet. Maybe this is related to:
Cannot persist EFI variables without system partition
(There definitely is an EFI system partition on this system).
It seems that the block device is not scanned at that point.
To me this points out that something is broken again.
But I also think that there are other ways in which the integration of
the EFI boot manager code in U-Boot is flawed, and frankly I don't
think the idea of having a self-coontained EFI boot manager is
compatibe with what some users expect from U-Boot. And I think
keeping something like BOOTMETH_EFILOADER is part of the answer.
I meant to explain my thoughts in a reply to earlier messages, but
could find the time until now.
From eralier discussions I have composed the following (incomplete)
list of requirements:
1. Some users want to contiue booting using "legacy" boot methods.
2. Some users care about booting as fast as possible.
This is why we need to move the boot manager after booting from block
devices.
And we should not try to run EFI/BOOT/BOOT<ARCH>.EFI before running the
boot manager.
That is why I am working on this series:
https://lore.kernel.org/u-boot/20250421162555.1200687-2-heinrich.schucha...@canonical.com/T/#m9bc0236cffe70ee06df4c482a958303faff3a32c
where I have included the current patch.
Best regards
Heinrich
3. Some users want to be able to boot from a specific device but don't
really care about the boot method (EFI or "legacy").
4. Some boards have sepcific boot methods (FEL on sunxi, maskrom on
rockchip) that need to to be tried first.
The biggest issue is requirement #2. The related issues in the EFI
subsystem and EFI boot manager are:
a. Scanning for ESPs to find the file that contains EFI variables when
EFI_VARIABLE_FILE_STORE is selected takes time. Unfortunately this
is the only way we can support EFI variables on many boards.
b. Scanning for ESPs to boot from takes time as well.
Of course the way bootstd looks for additional boot methods by
scanning filesystems as similar issue.
Originally the EFI boot manager only handled the case where the user
explicitly configured EFI boot options. The "fallback"
EFI\BOOT\BOOT<ARCH>.EFI loading was handled later when the distro boot
scripts looped over the list of configured boot targets.
Later code was added to the EFI boot manager to do that. I believe
that was done as part of supporting an EFI boot menu, which to this
date isn't really used by any board, at least not in the default
configuration. And the way that code works is by creating "default"
boot options for all devices with an ESP.
I think the way to fix this is splitting the EFI boot manager into
different phases. The first phase should only look at the boot
options configured by the user (either explicitly or automatically by
an OS installer). That still requires us to read the EFI variables.
So I think we should restrict EFI_VARIABLE_FILE_STORE to only scanning
the device from which we booted U-Boot.
The "fallback" EFI\BOOT\BOOT<ARCH>.EFI should then be done in a later
phase, after some of the other boot methods have been explored taking
into account preferences set by the user. But that pretty much is
what BOOTMETH_EFILOADER already does.
Cheers,
Mark
Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com>
---
boot/Kconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/boot/Kconfig b/boot/Kconfig
index fb37d912bc9..89076220adb 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -597,6 +597,9 @@ config BOOTMETH_EFILOADER
imply CMD_TFTPBOOT if CMD_NET
default y
help
+ This bootmeth is obsolete. BOOTMETH_EFI_BOOTMGR takes care of
+ launching EFI\BOOT\BOOT<ARCH>.EFI if no boot option matches.
+
Enables support for EFI boot using bootdevs. This makes the
bootdevs look for a 'boot<arch>.efi' on each filesystem
they scan. The resulting file is booted after enabling U-Boot's
@@ -648,7 +651,7 @@ config BOOTMETH_DISTRO
select BOOTMETH_SCRIPT if CMDLINE # E.g. Armbian uses scripts
select BOOTMETH_EXTLINUX # E.g. Debian uses these
select BOOTMETH_EXTLINUX_PXE if CMD_PXE && CMD_NET && DM_ETH
- select BOOTMETH_EFILOADER if EFI_BINARY_EXEC # E.g. Ubuntu uses this
+ select BOOTMETH_EFI_BOOTMGR if EFI_BINARY_EXEC # E.g. Ubuntu uses this
config SPL_BOOTMETH_VBE
bool "Bootdev support for Verified Boot for Embedded (SPL)"
--
2.48.1
