[PATCH 1/1] boot: BOOTMETH_DISTRO should select BOOTMETH_EFI_BOOTMGR

[Mark Kettenis]

> From: Heinrich Schuchardt <heinrich.schuchardt at 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 'nvme at 34bcc0000.blk#1.bootdev.part_4' with efi

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).

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.

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.schuchardt at 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
> 
>