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

[Andre Przywara <andre.przywara@arm.com>]

On Fri, 15 Nov 2024 07:21:53 -0700
Simon Glass <sjg@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@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@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.

Cheers,
Andre