xPL terminology

[Simon Glass]

Hi Tom,

On Tue, 27 Aug 2024 at 15:43, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Aug 27, 2024 at 01:24:59PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 27 Aug 2024 at 10:50, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sun, Aug 25, 2024 at 07:07:23AM -0600, Simon Glass wrote:
> > >
> > > > Hi,
> > > >
> > > > We have the term 'SPL', which has a dual meaning. It is both a
> > > > particular phase of U-Boot (the one that loads U-Boot proper) and a
> > > > generic name for any pre-proper phase.
> > > >
> > > > You can see that in a few areas, but for example CONFIG_SPL_BUILD is
> > > > enabled for TPL and VPL builds, not just SPL.
> > > >
> > > > I propose to rename the generic term from SPL to xPL (meaning any PL
> > > > phase), leaving SPL to just refer to the phase before U-Boot proper.
> > > >
> > > > The symbol would be CONFIG_XPL but in documentation we would talk of
> > > > xPL, with a lower-case X, so it is more obvious that it refers to any
> > > > phase.
> > > >
> > > > What do you think?
> > >
> > > I still worry this is just another part of the long symptom of needing
> > > to re-work how we configure / build as we have 1 case of "build things
> > > this way" (full U-Boot) and N cases of "build things another way" (SPL,
> > > TPL, VPL, UPL?). And really we need a way to short-hand
> > > "fooboard_defconfig" means "fooboard_spl_defconfig +
> > > fooboard_tpl_defconfig + fooboard_SOMETHING_defconfig".
> >
> > IMO my XPL series does this, at least for some definition of this. I'd
> > really like to get that in as it would make all of this much easier.
>
> Yeah, what I recall of your XPL series was that it made a lot of changes
> I didn't like and highlighted what I thought was that yes, really
> Yamada-san was right all along and we need a different way of
> configuring + building.
>
> I had even today thought that we could possibly
> get away with some shorthand where if for "fooboard_defconfig" we _also_
> had "fooboard_spl_defconfig" we knew to build in ${O}/spl/ the spl
> variant. It would be harder for cases where we have "fooboard_defconfig"
> and "fooboard_hs_defconfig" that both need "fooboard_spl_defconfig", but
> it would cover many cases at least. Anyhow...

We should discuss this sometime as it has come up once or twice
before. Given the dependencies between XPL and proper and don't think
we can sensible split into separate files, let alone separate the
Kconfig. In fact I still believe that we need a small Kconfig-language
addition to support this sort of thing and avoid duplicating the rules
everywhere*. I believe I might have even done a patch for it. We got
very close to sorting all this out a year or two ago and then it all
died.

We are really stuck on making progress on 'generic XPL' (or whatever
it is called) until we can figure this out.

>
> I think a series that replaces CONFIG_SPL_BUILD with CONFIG_XPL_BUILD
> (and the required logic to make that work...) would be fine.

OK.

>
> > > But on the flip side, I also suppose replacing CONFIG_SPL_BUILD with
> > > CONFIG_XPL_BUILD would be less confusing.
> >
> > Yes. What do you think of E's idea of renaming all the options? I
> > quite liked it when I read it, but now I am thinking that having
> > everything be xPL is quite a nice convention. If we have SETUP_... and
> > TINY_... it is less clear that they are related.
>
> Yes, I think we need better descriptive documentation for what we have
> and then only maybe renaming a few things that might be too cryptic.

OK. Well I can look at splitting CONFIG_SPL_BUILD into two:

- CONFIG_XPL_BUILD means that it is not building U-Boot proper (i.e.
the current meaning of CONFIG_SPL_BUILD
- CONFIG_SPL_BUILD means it is building SPL (and not TPL or VPL)

Regards,
Simon

* Yes, Linux will never accept a Kconfig addition; this is the same
Linux that refused FIT for 10 years so IMO that issue is not relevant
to the discussion or what is best for U-Boot