Hi Simon,
On 8/30/24 3:06 AM, Simon Glass wrote:
Hi Tom,
On Tue, 27 Aug 2024 at 15:43, Tom Rini <tr...@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 <tr...@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
I thought about this already, one of the issues being that it is not
guaranteed that the dependencies for a symbol for xPL will be the same
for yPL nor for proper, so we still need a way to override those from a
redefinition of the symbol (or any other mechanism). I may misremember
but I think one of the most straightforward issue was that most (all)
proper have DM support while xPL do not necessarily have to (and there
usually is the xPL loaded by BootROM, limited by SRAM size, that does
not have DM support).
But this has been a big pain of mine, with proper symbols usually being
properly configured wrt dependencies and Makefile, but a lot of corner
cases missed for xPL, especially wrt Make rules.
FWIW, I've always been confused by CONFIG_SPL_BUILD not being for SPL
but anything !proper (to the point I always have to check whenever I see
this symbol).
Cheers,
Quentin
