[U-Boot-Custodians] SPL / TPL

[Simon Glass]

Hi Wolfgang,

On Tue, 15 Oct 2019 at 00:51, Wolfgang Denk <wd at denx.de> wrote:
>
> Dear Simon,
>
> In message <CAPnjgZ38MkhSMnTVuk1+WC2WW-UNuBCyRp7mx14J+gUXnaoTiQ at mail.gmail.com> you wrote:
> >
> > > > - Secondary PL loads primary (U-Boot)
> > > > - Tertiary PL loads secondary (SPL)
> > >
> > > Oh, and *this* makes sense to you?
> >
> > Yes it makes sense to me, but the ordering is backwards from what you
> > have, So it is:
>
> Yyes, you are right, your ordering is backwards :0(
>
> > Primary - U-Boot
> > Secondary - SPL
> > Tertiary - TPL
>
> Sorry, but this makes even less sense than anything that has been
> suggested so far.  What have you been smoking lately? ;-)

Not enough...

>
> > then that might make some sense, but the problem is that many
> > platforms don't have TPL, so there is no 'first'.
>
> Well, you can try and define anything, but does it really make
> sense?
>
> To me, the only logical approach is looking at the actual sequence
> how a system starts:
>
> Out of reset we may see:
>
> - RBL (ROM Boot Loader)
>   Note: not present / visible on all systems; there are
>   architectures that appear to start execution at some address in
>   memory space where they expect to find some ROM (say, classic
>   Power Architecture processors)
>
> - SPL (Second Program Loader)
>   Note: not present on all systems - only when the RBL cannot load
>   U-Boot proper directly.   In the past these was usually the case
>   when booting from NAND flash, where the RBL would read only one
>   block, usually something between 4 and 128 kB.  Other size
>   restirctions might result from size of available on chip memory /
>   cache etc.
>
> - TPL (Third Program Loader)
>   Note: not present on all systems - only when the SPL cannot load
>   U-Boot proper directly.  This was for example the case on systems
>   where the RBL would just load a very small (4 or 16 kB) SPL and
>   not all needed drivers would fit, so a third stage was needed.

>From my understanding it is more common that we can't load SPL
directly. E.g. Rockchip uses TPL because the boot ROM cannot load SPL,
as I understand it.

>
> - U-Boot proper (U-Boot)
>   Note: not present on all systems - can be skipped for example when
>   using Falcon Mode for optimized boot times.
>
> - OS (Linux)
>
>
> You can give any names to these stages, but this is the real
> sequence, and counting backwards is ... ummm... backwards.

Let's agree to disagree on this one. I think I've explained how I
understand it. To me it is it more consistent to down from U-Boot
backwacks than from the boot rom forwards. U-Boot is always last but
there are 0, 1, 2 or 3 things before it.

Maybe my misunderstanding comes from seeing that SPL was used a lot
but TPL not much. Also when I see TPL it is very small, not even
having Kconfig options for most features.

>
>
> I am well aware that even the originally intended naming has
> problems, as we now may use a SPL on systems without ROB, so the SPL
> actually executes first - for example this has been done on Power
> Architecture systems with parallel NOR flash to implement Falcom
> Mode for sub-second booting into user space.
>
> > It seems better to me therefore to have:
> >
> > Primary - U-Boot
> > Secondary - SPL
> > Tertiary - TPL
> >
> > and then platforms can choose as many levels as they need to make boot
> > work. God forbid if we needed quaternary we could add it and
> > everything would stay consistent.
>
> This is totally unacceptable to me, and if you are honest, you are
> aware of the ... restrictions of such an approach yourself.

I don't see the problem yet, but OK.

>
> What we should have learned from history is, that names associate a
> configuration/image with a specific step in the boot sequence
> (first, 2nd, 3rd,...) are inherently broken as it will only take
> some time and need arises to reorder these parts for some reason or
> another.
>
> So what can we actually do?
>
> * We don't care about the meaning of the names and accept that their
>   historical meaning may have changed over time.  Then this should
>   be documented, so we can point to that part of the documentation
>   when the next such discussion starts.
>
> * We try to invent new names for the existing ones and document
>   these. In this case I strongly oppose any names that suggest some
>   sort of sequence - no matter if you count in the right or in the
>   wrong direction ;-)
>
>   We could, for example, redefine SPL as "Small Program Loader" and
>   TPL as "Tiny Program Loader", as this is apparently what most
>   people in this discussion expect.  [Note that I am not sure that
>   sizeof(SPL) > sizeof(TPL) for all boards that use both, but this
>   is probably acceptable for relative terms like "tiny" and
>   "small".]  If we do this, such re-interpretation needs to be
>   documented and explained.

That seems OK to me, and it is at least explainable.

>
> * We invent completely new names and abbreviations.  Again, this
>   needs to be documented and explained.

Regards,
Simon