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

[Mark Kettenis]

> From: Simon Glass <sjg at chromium.org>
> Date: Sun, 3 Nov 2024 07:46:44 -0700

Hi Simon,

> Hi Andre,
> 
> On Sun, 3 Nov 2024 at 03:36, Andre Przywara <andre.przywara at arm.com> wrote:
> >
> > 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?
> 
> Given that we are past rc1 the easiest thing might be to revert this:
> 
> f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
> 
> until we can figure this out.
> 
> Can you try that?

That will break setups that use the EFI bootmanager on platforms
already converted to bootstd (such as various Rockchip boards and the
Apple machines).  I don't think that is acceptable as we've been
shipping releases with working EFI bootmanager support on those
platforms for several years already.