[U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader

[Scott Wood]

On Mon, 24 Jan 2011 13:49:19 +0100
Wolfgang Denk <wd at denx.de> wrote:

> > > > +		CONFIG_TPL_U_BOOT
> > > > +
> > > > +		Builds a U-Boot image that contains a loader stub (tertiary
> > > > +		program loader -- TPL) that boots out of some type of RAM,
> > > > +		after being loaded by an SPL or similar platform-specific
> > > > +		mechanism.  This symbol will be set in all build phases.
> > > > +
> > > > +		CONFIG_TPL_BOOT
> > > > +
> > > > +		This is set by the build system when compiling code to go into
> > > > +		the TPL.  It is not set when building the code that the TPL
> > > > +		loads, or when building the SPL.
> > > 
> > > Can we not do with a single variable definition?
> > 
> > I did not get it. Could you please give a recommendation?
> 
> Well, I see a pollution with such CONFIG_ settings.  I don;t have a
> solution ready to recommend, but if you can find a way not to define
> so many different settings for a single purpose that wouldbe great.

They mean different things.  We can't "do with a single variable
definition" in the current NAND SPL.  Why would TPL be any different?

Now, the naming could be clearer.  Changing CONFIG_TPL_BOOT into
CONFIG_TPL would make it look more like the existing SPL names.  Or we
could do something like:

CONFIG_HAS_SPL  /* set in all of U-Boot when an SPL is used */
CONFIG_IN_SPL   /* set only when building the SPL */
CONFIG_HAS_TPL  /* set in all of U-Boot when a TPL is used */
CONFIG_IN_TPL   /* set only when building the TPL */

-Scott