[U-Boot-Custodians] SPL / TPL

[Bin Meng]

Hi,

On Thu, Oct 17, 2019 at 1:19 AM Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Oct 16, 2019 at 09:03:50AM -0600, Simon Glass wrote:
> > 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.
>
> At this point in the thread I think the important thing to do is focus
> on clarifying what things mean as the history of how we got what we've
> got has been explained.
>
> I'm in favor of something along the lines of calling "SPL" "SPL and
> "TPL" "TPL" and doing whatever documentation we can that won't also make
> people that are on the (typically PowerPC) platforms that have
> SPL->TPL->U-Boot suddenly start breaking as they write the wrong binary
> to the wrong place or read external documents and see a very big
> mis-match.

I am going to look at Simon's ApolloLake series, and TPL in that
series refers to the first stage.

So did we agree on something?

Regards,
Bin