[PATCH 0/6] bootstd: sunxi: Migrate to standard boot

[Simon Glass]

Hi Andre,

On Tue, 13 Aug 2024 at 06:35, Andre Przywara <andre.przywara at arm.com> wrote:
>
> On Tue, 13 Aug 2024 06:17:17 -0600
> Simon Glass <sjg at chromium.org> wrote:
>
> Hi Simon,
>
> I had a bit deeper look yesterday.

Thanks for digging into this.

>
> > Hi Andre,
> >
> > On Mon, 12 Aug 2024 at 10:00, Andre Przywara <andre.przywara at arm.com> wrote:
> > >
> > > On Wed,  7 Aug 2024 14:50:26 -0600
> > > Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hey Simon,
> > >
> > > > This series attempts to migrate all sunxi boards to use standard boot,
> > > > along with a text environment.
> > >
> > > Ah, many thanks for that! I figured that we need a bootmeth for FEL, but
> > > never got around to have a closer look.
> > > On a coarse glance, this looks roughly OK, and doing a super quick boot
> > > test on one board, it seems to still work(TM), though the priority of the
> > > FEL boot is not right?
> >
> > Does it need to be the top priority, perhaps?
>
> Yes, please. It should only trigger when you a) do FEL booting and b)
> upload a boot script via FEL, in which case you surely want to execute
> that before anything else. From what I see the global EFI bootmeth is first
> in the list, but I couldn't find an easy way to fix this in the source
> file. Would that go through a platform specific bootmeths env variable?

We can just rename the bootmeth to be before the EFI mgr one.

>
> > > And I guess ditching the old kernel support might be a bit controversial.
> > > I think this is about the vendor kernels, which some people still rely on?
> >
> > OK, perhaps it is. It might be a little tricky to handle it, but I
> > suspect another bootmeth might be enough.
>
> Well, I had a look, and it looks like CONFIG_OLD_SUNXI_KERNEL_COMPAT
> covers multiple things:
> - it sets up some clocks slightly differently
> - it enters the kernel (stays?) in secure mode
> - it provides a custom boot script
>
> I think the latter can be replaced quite easily with something custom, and
> I guess it's the only one biting you? So I am OK with that going, but I
> think we should keep the first two features (and thus the Kconfig symbol).

Yes the script is the only issue and actually it doesn't affect
standard boot. So I can just convert it. I was just hoping to remove
some old code!

>
>
> Another thing I discovered: we lose USB support with patch 3/6. The reason
> is that USB support is enabled by having DISTRO_DEFAULTS. Just replacing
> that with BOOTSTD_DEFAULTS didn't work, though, I get a (ridiculous) splat
> about a circular Kconfig dependency. My hunch is that's something else not
> right in Kconfig, but I need to have a closer look.

Oh yes that is nasty. The problem goes back to BLK being selected by
various things, while BOOTSTD depends on it. I eventually found a
solution so will include that in v2.

Regards,
Simon