[PATCH 31/45] spl: Allow multiple loaders of the same type

[Simon Glass]

Hi Tom,

On Fri, 30 Sept 2022 at 10:51, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Sep 30, 2022 at 10:45:01AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 30 Sept 2022 at 10:39, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Fri, Sep 30, 2022 at 10:37:26AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 30 Sept 2022 at 10:28, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Sun, Sep 25, 2022 at 09:02:34AM -0600, Simon Glass wrote:
> > > > >
> > > > > > At present we only support a single loader of each time. Extra ones are
> > > > >
> > > > > Of each type not time, I assume.
> > > > >
> > > > > > ignored. This means that only one BOOT_DEVICE_BOARD can be used in the SPL
> > > > > > image.
> > > > > >
> > > > > > This is inconvenient since we sometimes want to provide several
> > > > > > board-specific drivers, albeit at different priorties. Add support for
> > > > > > this.
> > > > > >
> > > > > > This should have no functional change for existing boards.
> > > > >
> > > > > To be clearer here. Today I can build am335x_evm_defconfig, and it will
> > > > > have support for (among others) X/Y-MODEM and SD/MMC booting, and if SPL
> > > > > loads via SD card, it will look at that same slot and find U-Boot, or
> > > > > fail.
> > > > >
> > > > > This patch doesn't change that, yes?
> > > > >
> > > > > A later part of this series makes it possible, but not default?
> > > >
> > > > That's right, there is no change for existing boards, since they only
> > > > have only loader of each type. But it allows boards to change that and
> > > > have two loaders for a single type. This is done later for sandbox,
> > > > but it would actually be useful for a few other boards too, e.g. where
> > > > there are two board-specific ways of booting and we want to try both.
> > >
> > > I'm not following now, sorry. Can you elaborate on the example you're
> > > talking about please, either for sandbox or what it would look like on a
> > > hardware platform?
> >
> > For sandbox we want to boot with VBE if available, but if not then we
> > want to use the existing loader, which just runs the next executable
> > (e.g. spl/u-boot-spl). Both of these are board-specific methods. The
> > current enum of boot methods is a bit of a pain, e.g. we have things
> > like this in ARM's spl.h because we cannot have more than one loader
> > of a certain type:
> >
> > BOOT_DEVICE_MMC1,
> > BOOT_DEVICE_MMC2,
> > BOOT_DEVICE_MMC2_2,
> >
> > BTW the loaders already have a priority which we can use to choose
> > which is more desirable.
>
> OK, so it's so that we could do VBE, but fall back if not possible? Is
> that really advisable? The historical reasoning behind that enum is that
> we want to know if we came from $X we want to use-or-fail the next stage
> also being $X. We do have a few cases I believe where the board knows
> "if $X then $Y" instead for some specific use cases.

Yes, but that is implemented using the firmware handoff thing.

https://patchwork.ozlabs.org/project/uboot/patch/20220925150248.2524421-43-sjg@chromium.org/

We can of course enforce this, such that when VBE is active it has to
be used. At present errors from spl_load_image() are ignored, so it
has to be done in the loader itself. But we could change that.

Regards,
Simon