[U-Boot-Custodians] SPL / TPL

[Tom Rini]

On Thu, Oct 10, 2019 at 09:40:13AM +0200, Wolfgang Denk wrote:
> Dear Masahiro,
> 
> In message <CAK7LNAR45-6SEAeGyjT8o5jP=6iNcSP=A4pW2rQV9V_JfGTi0w at mail.gmail.com> you wrote:
> >
> > This discussion started from this patch:
> > https://patchwork.ozlabs.org/patch/662396/
> >
> > It happened before the rockchip stuff.
> 
> Yes, thanks for the link. Apparently I missed that discussion then :-(
> 
> I still cannot see where this thinking that "SPL is big and has all
> features" and "TPL is small" is coming from.  If someone has
> implemented it in this way, then he did a major mistake.
> 
> The SPL ('S' as in second) is by definition that code which gets
> started by the ROM Boot loader.  THis can be small or large, have
> minimal features or many - this depends on the project requitements
> and the platform capabilities.  On some platforms we may see sizes
> close to 128 kB, on others just 4 kB.  This size limitation
> determines which features can be included into the SPL; for small
> sizes there may be restrictions - in a 4 kB SPL there will be no
> support for DM or DT, most likely not for a serial console.
> 
> If the available size is big enough to include all features we need
> to load U-Boot proper (or, in case of Falcon boot, the Linux kernel
> + DT), that that's it.  If it is too small, then we need a third
> boot stage: TPL (with 'T' as in third).
> 
> 
> I have hard times to understand how the idea could come up to do it
> differently.

Where much of this comes from I think is the use cases where we're not
as heavily constrained on initial resources but also can't / won't jump
directly to full U-Boot from ROM.  When we went from "U-Boot resides in
some XIP space" as the common case to "U-Boot resides in some non-XIP
space we must load from and in to memory" we also moved to platforms
where the what ROM would load was put in to 4KiB to maybe 64KiB.  U-Boot
wasn't generally going to fit there, even then and so yes, there came
"Secondary Program Loader" that was at different times either originally
in (Freescale PowerPC stuff) or later folded back in (TI OMAP X-loader
fork) to U-Boot proper.

Then came the push to silo things less and generalize and abstract
things more.  That leads to size growth.  That's more controllable in
the 64KiB case than the 4KiB case.  The way things stand today we have
available both "SPL uses common framework" and "SPL does its own one-off
thing".  This is most visible in the case of PowerPC boards where boards
don't select the common framework but do have SPL.

Then came further new architectures and designs and desires.  We now end
up with cases where we need a Tiny loader again, to load enough of the
world (and other blobs) to then load either U-Boot, or "SPL" to finish
settings things up such that we can then load U-Boot.  In some cases,
the tiny loader is closed (along with all of the other blobs) until it
gets to "SPL" and in other cases the "Tiny" part get put in U-Boot along
with the rest of the board port.

And all of this sets aside still the question of should we have "make
foo_defconfig configures *PLs+U-Boot" vs "make foo_TPL_defconfig, make
foo_SPL_defconfig, make foo_defconfig" which was part of Scott's
proposal at the time and I believe Yamada-san preferred.

-- 
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/20191010/1d4e84cb/attachment.sig>