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?
Regards, Simon
Hi Simon,
On Sun, Aug 25, 2024 at 6:07 AM Simon Glass sjg@chromium.org 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.
ZBL or ZSBL: Zeroth Stage Boot Loader (usually in MaskROM)
SPL: Secondary Program Loader is what gets loaded by ZSBL and jump code execution to next
Everything after SPL seems like an invention of naming, and yes it is confusing!
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?
Regards, Simon
Secondary / Tertiary / Verifying / U-Boot from documentation:
https://docs.u-boot.org/en/latest/usage/spl_boot.html
... does not add much clarity to what these programs do, excepting "verifying" which is at least saying what it does.
When code execution is transferred to U-Boot (as SPL from ZSBL) then it is simply U-Boot Program if you need a short acronym: UP UBP UPRG UPGM UBPG
Add to this the descriptive short word name modifier of what that U-Boot Program does:
TINY VERIFY SETUP MAIN
Taking for example UP and TINY we would have UP_TINY UP_VERIFY UP_SETUP UP_MAIN
Any of these would be the SPL if they are loaded by the ZSBL, simple enough. Also keeping the same mnemonic first letter to what it is already now for making it less disruptive.
My comment then is that if you want it to be less confusing we should get away from "SPL" (x)PL naming so it looks nothing like ZSBL or SPL acronym. Also I observe that U-Boot code base norms are unnecessarily cryptic and weirdly abbreviated descriptions in the guise of "reducing code size" at the expense of readability... and it is welcome to me if you can improve this with _less_ cryptic naming and descriptions. Sorry "xPL" is more cryptic than it is now and keeps the overloading of the "SPL" terminology which is the cause of confusion.
-E
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".
But on the flip side, I also suppose replacing CONFIG_SPL_BUILD with CONFIG_XPL_BUILD would be less confusing.
Hi Tom,
On Tue, 27 Aug 2024 at 10:50, Tom Rini trini@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.
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.
Regards, Simon
Hi
On Tue, Aug 27, 2024 at 9:25 PM Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Tue, 27 Aug 2024 at 10:50, Tom Rini trini@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.
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.
+1 I just prefer CONFIG_XPL_BUILD change, or people need to change slides ;)
MIchael
Regards, Simon
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@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...
I think a series that replaces CONFIG_SPL_BUILD with CONFIG_XPL_BUILD (and the required logic to make that work...) would be fine.
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.
Hi Tom,
On Tue, 27 Aug 2024 at 15:43, Tom Rini trini@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@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
Hi Simon,
On 8/30/24 3:06 AM, Simon Glass wrote:
Hi Tom,
On Tue, 27 Aug 2024 at 15:43, Tom Rini trini@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@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
HI Quentin,
On Mon, 2 Sept 2024 at 10:57, Quentin Schulz quentin.schulz@cherry.de wrote:
Hi Simon,
On 8/30/24 3:06 AM, Simon Glass wrote:
Hi Tom,
On Tue, 27 Aug 2024 at 15:43, Tom Rini trini@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@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).
Indeed, they can have different values in TPL and SPL, for example.
My idea for the Kconfig-language addition was [1]
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.
Yes...well, my series actually simplified all the rules and got rid of $(SPL_TPL) etc.
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).
Yes, it is really not what you would expect.
I added an issue at [2]
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/patch/20230219145453.1.Idaaf79c3e... [2] https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/26
On 8/25/24 3:07 PM, Simon Glass wrote:
Hi,
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 wasn't aware of this.
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?
Works for me, thanks.
participants (6)
-
E Shattow -
Marek Vasut -
Michael Nazzareno Trimarchi -
Quentin Schulz -
Simon Glass -
Tom Rini