[U-Boot-Custodians] SPL / TPL

Tue Oct 29 02:52:41 UTC 2019

On Mon, Oct 28, 2019 at 11:22:56AM +0800, Bin Meng wrote:
> 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?

We need to document names which I think will end up being inconsistent
between architectures (PowerPC is where I believe all of
SPL->TPL->U-Boot is) but are and should remain consistent within
architectures.  So as long as ApolloLake does what Broadwell does for
"SPL" and "TPL" ordering, that should be good enough for today.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot-custodians/attachments/20191028/c77ebf38/attachment.sig>