[PATCH v5 3/8] efi_loader: bootstd: Drop bootmgr for sunxi

[Andre Przywara]

On Sat, 23 Nov 2024 05:06:49 +0100
Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:

Hi,

> Am 23. November 2024 03:08:02 MEZ schrieb Andre Przywara <andre.przywara at arm.com>:
> >On Fri, 15 Nov 2024 07:21:53 -0700
> >Simon Glass <sjg at chromium.org> wrote:
> >
> >Hi Simon, Tom, Heinrich,
> >
> >sorry for the delay, I was away.
> >  
> >> On Wed, 13 Nov 2024 at 10:50, Tom Rini <trini at konsulko.com> wrote:  
> >> >
> >> > On Wed, Nov 13, 2024 at 08:09:33AM -0700, Simon Glass wrote:
> >> >    
> >> > > This causes problems with the boot order, so drop it until we can figure
> >> > > out a better way to know when bootmgr should be used.
> >> > >
> >> > > Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.arm.com/
> >> > >
> >> > > Signed-off-by: Simon Glass <sjg at chromium.org>    
> >> >
> >> > I would really prefer a short summary of the contents of the link in the
> >> > commit message. I'm not NAK'ing the patch as-is, but it would be helpful
> >> > when revisiting this if there was a short explanation of the problem to
> >> > solve here and not just "problems with the boot order". Thanks.    
> >> 
> >> The summary is that sunxi supports FEL (USB boot) but bootmgr is not
> >> aware of it, so boots the OS instead.  
> >
> >So that's not the problem: FEL is working fine, since it's marked as
> >global, same as efi_bootmgr, but with a lower order number. The problem
> >is that the higher priority non-global methods (scripts) are "ignored".
> >
> >So this is the list without this patch:
> >Order  Seq  Name                Description
> >-----  ---  ------------------  ------------------
> >    0    0  extlinux            extlinux
> > glob    1  fel                 FEL
> >    2    2  script              script
> > glob    3  efi_mgr             EFI bootmgr flow
> >    4    4  efi                 EFI
> >    5    5  pxe                 PXE
> > glob    6  vbe_simple          vbe-simple
> >-----  ---  ------------------  ------------------
> >
> >The sequence looks roughly alright, only that it's not the actual
> >order, since "glob" takes precedence. So the actual order is:
> >fel -> efi_mgr -> vbe_simple -> extlinux -> script -> efi -> pxe
> >And that puts efi_mgr before extlinux and script, which is not what we
> >want, because efi_mgr finds bootaa64.efi *somewhere* (eMMC or SD card or
> >USB stick) and uses that, even when there is a tailored boot.scr or
> >extlinux.conf on the *boot media* which should be higher priority.
> >"fel" being first is fine, since it's *only* triggered if someone
> >deliberately uploaded a boot script via USB: in this case they surely
> >want to execute exactly that.
> >
> >So I think the underlying problem is the "glob" tag for efi_mgr PLUS
> >the fact that it scans all media for bootaa64.efi files. I think it
> >would be fine if efi_mgr would just consider EFI boot order variables,
> >and would ignore any "removable media" default files (bootaa64.efi).
> >The "efi" bootmeth does the scanning as well, and it's fine there,
> >since it's lower priority, so we can still boot EFI systems.
> >
> >I guess it would make sense if an installer on an USB stick should boot
> >even if there is something on the eMMC, for instance. But we want to
> >control that, and we can't, because the order is ignored due to the
> >"glob" flag.
> >
> >So while I agree that disabling efi_bootmgr sounds like a hack, it
> >solves the problem quite elegantly: We keep the (current) boot order,
> >which prioritises scripts over EFI, but still retain EFI. If people
> >want EFI first, they can change the order in the environment (I think?).
> >
> >Without that patch there is quite a regression for users, because
> >suddenly any bootaa64.efi files *somewhere* would be booted first, and
> >there is no way to turn that off.
> >
> >This has bitten me actually: for development I put a custom boot.scr on
> >an SD card which loads a kernel+DTB via TFTP from my box. And I want
> >that to be first, despite there being a proper EFI setup on the eMMC or
> >USB drive.
> >
> >So I hope that clears that up. I am not a big fan of that patch, but I
> >would like sunxi to be converted, and Simon seemed to be eager to do
> >this as well, so in the interest of not blocking this, I am fine with
> >that.  
> 
> Disabling EFI will break booting for users that rely on it (like me).

So are you using the UEFI BootOrder variables? How do you set them?
Manually on the U-Boot shell, or via some Linux tool manipulating the
U-Boot environment file? IIUC those are the only two methods that work
for sunxi, since the UEFI variable runtime services are not implemented.

In reality I am using UEFI booting as well, but entirely rely on
bootaa64.efi, hence bootmeth_efi is totally sufficient for me.

> Yes, the introduction of boot standard changed the boot order and specifically deprioritizing scripts is unexpected.
> 
> The priority sequence used to be
> 
> scripts
> extlinux
> efi
> pxe
>
> bootmeth_efimgr always running before scripts be fixed.

I agree, but with bootmeth_efimgr marked as global this is not gonna work
easily, at least that's my understanding.

> bootmeth_efi should be removed from the code base as redundant.

I wonder if a solution is to split this up: bootmeth_efimgr is only
looking at variables - then "glob" would be correct. Then people
can place bootmeth_efi at the position they want, either before the
scripts (allowing USB boot) or after. I think this would also solve the
case where bootaa64.efi is both on an eMMC and an SD card, as it would
pick the boot media first.

A lot of sunxi use cases are embedded, and people mostly don't
want to boot from USB on for instance their TV box, just because the
stick with the movies and some bootaa64.efi was still in the slot when
they turned the box on. Even more so for truly embedded devices. And
that's also the default setting for PCs, I think, where USB booting
would need to be explicitly enabled in the BIOS.

Cheers,
Andre