[PATCH v4 5/8] sunxi: Move to bootstd

[Mark Kettenis]

> Date: Sun, 3 Nov 2024 10:36:26 +0000
> From: Andre Przywara <andre.przywara at arm.com>

Hi Andre,

> On Sat, 2 Nov 2024 11:35:31 -0600
> Simon Glass <sjg at chromium.org> wrote:
> 
> Hi Simon,
> 
> > On Thu, 17 Oct 2024 at 17:25, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Drop support for distroboot and move to using bootstd instead.
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > ---
> > >
> > > (no changes since v2)
> > >
> > > Changes in v2:
> > > - Convert the other DISTRO_DEFAULTS in the Kconfig too
> > >
> > >  arch/arm/Kconfig | 10 +++++-----
> > >  1 file changed, 5 insertions(+), 5 deletions(-)  
> > 
> > Could this series be applied, please?
> 
> So I played with that a bit:
> - The FEL script boot method works: it has the highest priority, which
>   is what we want, because the script would be deliberately injected by
>   the user to be executed. So thanks for the changes!
> - However the other global boot method (efimgr) takes precedence over
>   other, *higher* priority methods (extlinux.conf/boot.scr). This
>   leads to behavioural regressions, I think, like:
>   - Say there is a bootaa64.efi on some ESP on the eMMC. If you now
>     boot from SD card, with boot.scr or extlinux.conf on there, U-Boot
>     will still find the EFI app first and execute that. I don't think
>     that's what we want?
>   - Similar, if you have a boot script on the eMMC, and boot from
>     there, but with a USB stick carrying a bootaa64.efi plugged in.
>     Then EFI would win as well. This might be intended, but maybe not,
>     and I don't see how one would influence that?
> 
> Is there a way to change the bootflow to look for any boot payload on
> the *boot* media first? So when I boot from SD, it checks this first for
> EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when
> booting from eMMC, check there first before considering SD and USB.
> Maybe I am missing something obvious here?

The issue here is that the EFI bootmanager by its very nature
considers all possible devices for which boot options have been
included in the BootOptions EFI variable.  So if you have enabled
bootmeth_efi_mgr (and you probably should), and you have an active
boot option (that is a boot option that is included in the BootOptions
EFI variable) that points at eMMC or USB, it will try too boot using
that boot option.  So you'd think things would be fine as long as you
don't add boot options for eMMC or USB to the BootOrder variable.

Unfortunately the EFI_LOADER code will automatically generate media
device boot options for all the block devices that get added and adds
those to the BootOrder variables in an attempt to implement the
requirement to boot from removable media if everything else fails.
But I think that's a mistake.  I can't find a requirement to add boot
options for these in the spec, let alone a requirement to add those to
BootOrder.  I suppose this fallback could be implemented as a separate
bootmeth that can be low priority.

> So while I am personally happy with EFI being a prominent citizen, I
> think many sunxi users would still expect more traditional boot methods
> to at least work - at the moment they might be permanently "shadowed" by
> some bootaa64.efi sitting *somewhere*. That actually bites me at the
> moment when working on a new SoC port, where I use an extlinux.conf as
> an override, to load a custom dev kernel and DTB, but bootstd still
> finds that grub on that SD card and uses that first :-(
> 
> So I feel like EFI should still be the preferred boot method, but the
> more custom ways should be allowed to override that.
> 
> Do you have any ideas how to solve that, or am I holding it wrong?
> 
> Cheers,
> Andre
>