| Message ID | 20250421094310.764765-1-heinrich.schuchardt@canonical.com |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [1/1] boot: BOOTMETH_DISTRO should select BOOTMETH_EFI_BOOTMGR | expand |
> From: Heinrich Schuchardt <heinrich.schuchardt@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@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@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 > >
On 21.04.25 13:30, Mark Kettenis wrote: >> From: Heinrich Schuchardt <heinrich.schuchardt@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@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@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 >> >>
Hi Heinrich, On Mon, 21 Apr 2025 at 03:43, Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > 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. > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@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 > I don't want to make this bootmeth obsolete. What is the motivation for that? Regards, Simon
On 23.04.25 14:28, Simon Glass wrote: > Hi Heinrich, > > On Mon, 21 Apr 2025 at 03:43, Heinrich Schuchardt > <heinrich.schuchardt@canonical.com> wrote: >> >> 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. >> >> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@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 >> > > I don't want to make this bootmeth obsolete. What is the motivation for that? This method was written in a way that per se violates the UEFI specification as it does not set up required UEFI variables. You must never run this before the boot manager as booting EFI/BOOT/BOOT<ARCH>.EFI if there is a boot option violates the UEFI specification- The boot manager covers the functionality of this bootmeth. Best regards Heinrich
Hi Heinrich, On Wed, 23 Apr 2025 at 14:02, Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > On 23.04.25 14:28, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 21 Apr 2025 at 03:43, Heinrich Schuchardt > > <heinrich.schuchardt@canonical.com> wrote: > >> > >> 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. > >> > >> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@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 > >> > > > > I don't want to make this bootmeth obsolete. What is the motivation for that? > > This method was written in a way that per se violates the UEFI > specification as it does not set up required UEFI variables. > > You must never run this before the boot manager as booting > EFI/BOOT/BOOT<ARCH>.EFI if there is a boot option violates the UEFI > specification- > > The boot manager covers the functionality of this bootmeth. I'm OK with the workaround we discussed, but this seems to go beyond that. Can you do this without disabling this bootmeth? Or is there some other clever way to keep things working as they do today? I know we've discussed this before, but is there really no way to know whether a board is using bootmgr? That would make things much easier. Perhaps we should just disable the default for bootmgr and then let boards enable it as needed? I think we discussed that too, but it seemed it caused other issues? Perhaps we could add an environment variable that gets checked? Regards, Simon
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)"
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. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> --- boot/Kconfig | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)