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

[Andre Przywara]

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?

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