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

[Heinrich Schuchardt]

On 21.04.25 13:30, Mark Kettenis wrote:
>> 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

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