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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220930/0e931784/attachment.sig>