[U-Boot-Custodians] SPL / TPL

Wolfgang Denk wd at denx.de
Tue Oct 15 06:50:58 UTC 2019


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? ;-)

> 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.

- 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.


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.

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.

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



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We want to create puppets that pull their own strings.   - Ann Marion


More information about the U-Boot-Custodians mailing list