xPL Proposal

xPL Proposal

[Simon Glass]

Hi,

I just wanted to send a note to (re-)introduce my ideas[1] for the
next iteration of xPL.

A recent series introduced 'xPL' as the name for the various
pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
still use filenames and function naming which uses 'spl', but could
potentially adjust that.

The major remaining problem IMO is that it is quite tricky and
expensive (in terms of time) to add a new phase. We also have some
medium-sized problems:

a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
can be confusing, particularly when combined with ifdef and ifneq

b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
different things. For any given option, some code uses one and some
the other, depending on what problems people have met along the way.

c. An option like CONFIG_FOO is ambiguous, in that it could mean that
the option is enabled in one or more xPL phases, or just in U-Boot
proper. The only way to know is to look for $(PHASE_) etc. in the
Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
and has not scaled well.

d. We need to retain an important feature: options from different
phases can depend on each other. As an example, we might want to
enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
may also want to share values between phases, such as TEXT_BASE. We
can do this easily today, just by adding Kconfig rules.

Proposal

1. Adjust kconf to generate separate autoconf.h files for each phase.
These contain the values for each Kconfig option for that phase. For
example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.

2. Add a file to resolve the ambiguity in (c) above, listing the
Kconfig options which should not be enabled/valid in any xPL build.
There are around 200 of these.

3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
useful in rare cases. This indicates that the option applies only to
U-Boot proper and is not defined in any xPL build. It is analogous to
CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
needed at present, basically to allow access to the value for another
phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
the address to which U-Boot should be loaded.

4. There is no change to the existing defconfig files, or 'make
menuconfig', which works just as today, including dependencies between
options across all phases.

5. (next) Expand the Kconfig language[2] to support declaring phases
(SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
declared once for any/all phases. We can then drop the file in 2
above.

With this, maintaining Kconfig options, Makefiles and adding a new
phase should be considerably easier.

Regards,
Simon

[1] https://lore.kernel.org/u-boot/20230131152702.249197-1-sjg@chromium.org/
[2] https://lore.kernel.org/u-boot/CAK7LNARQ-PgxiCh+gm2efpfXmNBkdTp18OTk3sHtqNsk6by5-Q@mail.gmail.com/

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4824 bytes --]

On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> Hi,
> 
> I just wanted to send a note to (re-)introduce my ideas[1] for the
> next iteration of xPL.
> 
> A recent series introduced 'xPL' as the name for the various
> pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> still use filenames and function naming which uses 'spl', but could
> potentially adjust that.
> 
> The major remaining problem IMO is that it is quite tricky and
> expensive (in terms of time) to add a new phase. We also have some
> medium-sized problems:
> 
> a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> can be confusing, particularly when combined with ifdef and ifneq
> 
> b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> different things. For any given option, some code uses one and some
> the other, depending on what problems people have met along the way.
> 
> c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> the option is enabled in one or more xPL phases, or just in U-Boot
> proper. The only way to know is to look for $(PHASE_) etc. in the
> Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> and has not scaled well.
> 
> d. We need to retain an important feature: options from different
> phases can depend on each other. As an example, we might want to
> enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> may also want to share values between phases, such as TEXT_BASE. We
> can do this easily today, just by adding Kconfig rules.

I agree with a through c and for d there are likely some cases even if
I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
important as the other ones.

> Proposal
> 
> 1. Adjust kconf to generate separate autoconf.h files for each phase.
> These contain the values for each Kconfig option for that phase. For
> example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> 
> 2. Add a file to resolve the ambiguity in (c) above, listing the
> Kconfig options which should not be enabled/valid in any xPL build.
> There are around 200 of these.
> 
> 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> useful in rare cases. This indicates that the option applies only to
> U-Boot proper and is not defined in any xPL build. It is analogous to
> CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> needed at present, basically to allow access to the value for another
> phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> the address to which U-Boot should be loaded.
> 
> 4. There is no change to the existing defconfig files, or 'make
> menuconfig', which works just as today, including dependencies between
> options across all phases.
> 
> 5. (next) Expand the Kconfig language[2] to support declaring phases
> (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> declared once for any/all phases. We can then drop the file in 2
> above.
> 
> With this, maintaining Kconfig options, Makefiles and adding a new
> phase should be considerably easier.

I think this will not make our life easier, it will make things harder.

I think what we've reached now shows that Yamada-san was correct at the
time in saying that we were going down the wrong path with how we
handled SPL/TPL.

My request instead is:
- Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
  DM_MMC) as a prefix.
- Likely need to introduce a PPL symbol as you suggest.
- Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
- Split something like rockpro64-rk3399_defconfig in to
  rockpro64-rk3399_ppl_defconfig
  rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
  and add Makefile logic such that for X_defconfig as a build target but
  not configs/X_defconfig not existing, we see if any of
  configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
  subdirectories of our object directory, and then using binman combine
  as needed.
  - Maybe instead the Makefile logic above we would parse X_defconfig
    and see if it's a different format of say PHASE:file to make it
    easier to say share a single TPL config with all rk3399, have a few
    common SPL configs and then just a board specific PPL.

This solves (a) by removing them entirely. This solves (b) by removing
the ambiguity entirely (it will be enabled or not). As a bonus for (b)
we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
Linux Kernel again. This solves (c) again by removing it entirely.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > Hi,
> >
> > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > next iteration of xPL.
> >
> > A recent series introduced 'xPL' as the name for the various
> > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > still use filenames and function naming which uses 'spl', but could
> > potentially adjust that.
> >
> > The major remaining problem IMO is that it is quite tricky and
> > expensive (in terms of time) to add a new phase. We also have some
> > medium-sized problems:
> >
> > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > can be confusing, particularly when combined with ifdef and ifneq
> >
> > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > different things. For any given option, some code uses one and some
> > the other, depending on what problems people have met along the way.
> >
> > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > the option is enabled in one or more xPL phases, or just in U-Boot
> > proper. The only way to know is to look for $(PHASE_) etc. in the
> > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > and has not scaled well.
> >
> > d. We need to retain an important feature: options from different
> > phases can depend on each other. As an example, we might want to
> > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > may also want to share values between phases, such as TEXT_BASE. We
> > can do this easily today, just by adding Kconfig rules.
>
> I agree with a through c and for d there are likely some cases even if
> I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> important as the other ones.

OK. No, TEXT_BASE is not a great example in my book either. But it is
true that SPL needs to know U-Boot's text base.

Here's another:

config SPL_SYS_MALLOC_F_LEN
   default SYS_MALLOC_F_LEN

config TPL_SYS_MALLOC_F
   default y if SPL_SYS_MALLOC_F

config TPL_SYS_MALLOC_F_LEN
   depends on TPL_SYS_MALLOC_F
   default SPL_SYS_MALLOC_F_LEN

>
> > Proposal
> >
> > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > These contain the values for each Kconfig option for that phase. For
> > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> >
> > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > Kconfig options which should not be enabled/valid in any xPL build.
> > There are around 200 of these.
> >
> > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > useful in rare cases. This indicates that the option applies only to
> > U-Boot proper and is not defined in any xPL build. It is analogous to
> > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > needed at present, basically to allow access to the value for another
> > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > the address to which U-Boot should be loaded.
> >
> > 4. There is no change to the existing defconfig files, or 'make
> > menuconfig', which works just as today, including dependencies between
> > options across all phases.
> >
> > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > declared once for any/all phases. We can then drop the file in 2
> > above.
> >
> > With this, maintaining Kconfig options, Makefiles and adding a new
> > phase should be considerably easier.
>
> I think this will not make our life easier, it will make things harder.
>
> I think what we've reached now shows that Yamada-san was correct at the
> time in saying that we were going down the wrong path with how we
> handled SPL/TPL.

You've mentioned this quite a few times over the years. Is there a
reference to what he suggested we should do? Or perhaps it is what you
have below.

>
> My request instead is:
> - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
>   DM_MMC) as a prefix.
> - Likely need to introduce a PPL symbol as you suggest.
> - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.

Good idea.

> - Split something like rockpro64-rk3399_defconfig in to
>   rockpro64-rk3399_ppl_defconfig
>   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
>   and add Makefile logic such that for X_defconfig as a build target but
>   not configs/X_defconfig not existing, we see if any of
>   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
>   subdirectories of our object directory, and then using binman combine
>   as needed.

This means splitting the existing file into a separate one for each
phase. I believe that will be hard to manage.

>   - Maybe instead the Makefile logic above we would parse X_defconfig
>     and see if it's a different format of say PHASE:file to make it
>     easier to say share a single TPL config with all rk3399, have a few
>     common SPL configs and then just a board specific PPL.
>
> This solves (a) by removing them entirely. This solves (b) by removing
> the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> Linux Kernel again. This solves (c) again by removing it entirely.

The scheme I propose removes a-c also. I should have made that clear.

There is not a huge difference between your scheme and mine. My
question is, how do you handle (d)?

The way I see it, both schemes remove the ambiguity. Mine retains a
single deconfig file and a single 'make menuconfig' for each board.
Yours feels more like building independent U-Boot images.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7737 bytes --]

On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > Hi,
> > >
> > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > next iteration of xPL.
> > >
> > > A recent series introduced 'xPL' as the name for the various
> > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > still use filenames and function naming which uses 'spl', but could
> > > potentially adjust that.
> > >
> > > The major remaining problem IMO is that it is quite tricky and
> > > expensive (in terms of time) to add a new phase. We also have some
> > > medium-sized problems:
> > >
> > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > can be confusing, particularly when combined with ifdef and ifneq
> > >
> > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > different things. For any given option, some code uses one and some
> > > the other, depending on what problems people have met along the way.
> > >
> > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > and has not scaled well.
> > >
> > > d. We need to retain an important feature: options from different
> > > phases can depend on each other. As an example, we might want to
> > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > may also want to share values between phases, such as TEXT_BASE. We
> > > can do this easily today, just by adding Kconfig rules.
> >
> > I agree with a through c and for d there are likely some cases even if
> > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > important as the other ones.
> 
> OK. No, TEXT_BASE is not a great example in my book either. But it is
> true that SPL needs to know U-Boot's text base.
> 
> Here's another:
> 
> config SPL_SYS_MALLOC_F_LEN
>    default SYS_MALLOC_F_LEN
> 
> config TPL_SYS_MALLOC_F
>    default y if SPL_SYS_MALLOC_F
> 
> config TPL_SYS_MALLOC_F_LEN
>    depends on TPL_SYS_MALLOC_F
>    default SPL_SYS_MALLOC_F_LEN

Alternatively:
config SYS_MALLOC_LEN
   ... current default X if Y
   default 0x2800 if RCAR_GEN3 && !PPL
   default 0x2000 if IMX8MQ && !PPL

> > > Proposal
> > >
> > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > These contain the values for each Kconfig option for that phase. For
> > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > >
> > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > Kconfig options which should not be enabled/valid in any xPL build.
> > > There are around 200 of these.
> > >
> > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > useful in rare cases. This indicates that the option applies only to
> > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > needed at present, basically to allow access to the value for another
> > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > the address to which U-Boot should be loaded.
> > >
> > > 4. There is no change to the existing defconfig files, or 'make
> > > menuconfig', which works just as today, including dependencies between
> > > options across all phases.
> > >
> > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > declared once for any/all phases. We can then drop the file in 2
> > > above.
> > >
> > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > phase should be considerably easier.
> >
> > I think this will not make our life easier, it will make things harder.
> >
> > I think what we've reached now shows that Yamada-san was correct at the
> > time in saying that we were going down the wrong path with how we
> > handled SPL/TPL.
> 
> You've mentioned this quite a few times over the years. Is there a
> reference to what he suggested we should do? Or perhaps it is what you
> have below.

I don't recall what he proposed instead, just that when it became clear
that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
handled to how we're doing it today, he thought that was the wrong
direction.

> > My request instead is:
> > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> >   DM_MMC) as a prefix.
> > - Likely need to introduce a PPL symbol as you suggest.
> > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> 
> Good idea.
> 
> > - Split something like rockpro64-rk3399_defconfig in to
> >   rockpro64-rk3399_ppl_defconfig
> >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> >   and add Makefile logic such that for X_defconfig as a build target but
> >   not configs/X_defconfig not existing, we see if any of
> >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> >   subdirectories of our object directory, and then using binman combine
> >   as needed.
> 
> This means splitting the existing file into a separate one for each
> phase. I believe that will be hard to manage.

Do you mean initially, or long term? Initially, it should be a bit of
shell scripting. The consolidation (ie most/all rk3399 having an
identical _spl_defconfig) can't be automated. Long term I'm not sure it
would be any different. Most of the maintenance is on resync'ing which
is automated.

> >   - Maybe instead the Makefile logic above we would parse X_defconfig
> >     and see if it's a different format of say PHASE:file to make it
> >     easier to say share a single TPL config with all rk3399, have a few
> >     common SPL configs and then just a board specific PPL.
> >
> > This solves (a) by removing them entirely. This solves (b) by removing
> > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > Linux Kernel again. This solves (c) again by removing it entirely.
> 
> The scheme I propose removes a-c also. I should have made that clear.

Er, ok. That's not how it looked before, but I guess I'm just mistaken.

> There is not a huge difference between your scheme and mine. My
> question is, how do you handle (d)?

Well, either (d) isn't important as for example MMC wasn't a good choice
in your proposal as virtually everyone "select MMC" today or it's
handled more easily as my example above in SYS_MALLOC_LEN.

> The way I see it, both schemes remove the ambiguity. Mine retains a
> single deconfig file and a single 'make menuconfig' for each board.
> Yours feels more like building independent U-Boot images.

It is explicitly building independent U-Boot images, yes. With a wrapper
around "make all of the images for a given platform". So much of our
confusing and messy code is because we aren't doing that. And since most
modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
we really could have fewer overall build configurations.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > next iteration of xPL.
> > > >
> > > > A recent series introduced 'xPL' as the name for the various
> > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > still use filenames and function naming which uses 'spl', but could
> > > > potentially adjust that.
> > > >
> > > > The major remaining problem IMO is that it is quite tricky and
> > > > expensive (in terms of time) to add a new phase. We also have some
> > > > medium-sized problems:
> > > >
> > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > can be confusing, particularly when combined with ifdef and ifneq
> > > >
> > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > different things. For any given option, some code uses one and some
> > > > the other, depending on what problems people have met along the way.
> > > >
> > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > and has not scaled well.
> > > >
> > > > d. We need to retain an important feature: options from different
> > > > phases can depend on each other. As an example, we might want to
> > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > can do this easily today, just by adding Kconfig rules.
> > >
> > > I agree with a through c and for d there are likely some cases even if
> > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > important as the other ones.
> >
> > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > true that SPL needs to know U-Boot's text base.
> >
> > Here's another:
> >
> > config SPL_SYS_MALLOC_F_LEN
> >    default SYS_MALLOC_F_LEN
> >
> > config TPL_SYS_MALLOC_F
> >    default y if SPL_SYS_MALLOC_F
> >
> > config TPL_SYS_MALLOC_F_LEN
> >    depends on TPL_SYS_MALLOC_F
> >    default SPL_SYS_MALLOC_F_LEN
>
> Alternatively:
> config SYS_MALLOC_LEN
>    ... current default X if Y
>    default 0x2800 if RCAR_GEN3 && !PPL
>    default 0x2000 if IMX8MQ && !PPL

PPL means (in my book) that we have a PPL, i.e. it is always true. It
is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
which build it is. If you are suggesting that SPL means that this is
the SPL build, then which thing tells us whether or not we have an SPL
build? I'm just a bit confused by this.

But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
SPL one, with your scheme?

So I'm still not understanding how you handle Kconfig dependencies
between phases with your scheme. Are you saying you don't and they are
not important?

Also, is there a single Kconfig tree for U-Boot, or are you saying you
want a different set of Kconfig files for each phase?

>
> > > > Proposal
> > > >
> > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > These contain the values for each Kconfig option for that phase. For
> > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > >
> > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > There are around 200 of these.
> > > >
> > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > useful in rare cases. This indicates that the option applies only to
> > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > needed at present, basically to allow access to the value for another
> > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > the address to which U-Boot should be loaded.
> > > >
> > > > 4. There is no change to the existing defconfig files, or 'make
> > > > menuconfig', which works just as today, including dependencies between
> > > > options across all phases.
> > > >
> > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > declared once for any/all phases. We can then drop the file in 2
> > > > above.
> > > >
> > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > phase should be considerably easier.
> > >
> > > I think this will not make our life easier, it will make things harder.
> > >
> > > I think what we've reached now shows that Yamada-san was correct at the
> > > time in saying that we were going down the wrong path with how we
> > > handled SPL/TPL.
> >
> > You've mentioned this quite a few times over the years. Is there a
> > reference to what he suggested we should do? Or perhaps it is what you
> > have below.
>
> I don't recall what he proposed instead, just that when it became clear
> that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> handled to how we're doing it today, he thought that was the wrong
> direction.

Yes, IMO he was right about that.

>
> > > My request instead is:
> > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > >   DM_MMC) as a prefix.
> > > - Likely need to introduce a PPL symbol as you suggest.
> > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> >
> > Good idea.
> >
> > > - Split something like rockpro64-rk3399_defconfig in to
> > >   rockpro64-rk3399_ppl_defconfig
> > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > >   and add Makefile logic such that for X_defconfig as a build target but
> > >   not configs/X_defconfig not existing, we see if any of
> > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > >   subdirectories of our object directory, and then using binman combine
> > >   as needed.
> >
> > This means splitting the existing file into a separate one for each
> > phase. I believe that will be hard to manage.
>
> Do you mean initially, or long term? Initially, it should be a bit of
> shell scripting. The consolidation (ie most/all rk3399 having an
> identical _spl_defconfig) can't be automated. Long term I'm not sure it
> would be any different. Most of the maintenance is on resync'ing which
> is automated.

Long term. How does 'make menuconfig' work in this case? Won't you
have to run it three times for SPL, TPL and PPL?

>
> > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > >     and see if it's a different format of say PHASE:file to make it
> > >     easier to say share a single TPL config with all rk3399, have a few
> > >     common SPL configs and then just a board specific PPL.
> > >
> > > This solves (a) by removing them entirely. This solves (b) by removing
> > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > Linux Kernel again. This solves (c) again by removing it entirely.
> >
> > The scheme I propose removes a-c also. I should have made that clear.
>
> Er, ok. That's not how it looked before, but I guess I'm just mistaken.

Yes I think so...it was a major goal to remove this stuff. [1] [2]

>
> > There is not a huge difference between your scheme and mine. My
> > question is, how do you handle (d)?
>
> Well, either (d) isn't important as for example MMC wasn't a good choice
> in your proposal as virtually everyone "select MMC" today or it's
> handled more easily as my example above in SYS_MALLOC_LEN.
>
> > The way I see it, both schemes remove the ambiguity. Mine retains a
> > single deconfig file and a single 'make menuconfig' for each board.
> > Yours feels more like building independent U-Boot images.
>
> It is explicitly building independent U-Boot images, yes. With a wrapper
> around "make all of the images for a given platform". So much of our
> confusing and messy code is because we aren't doing that. And since most
> modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> we really could have fewer overall build configurations.

I'd really like to see a generic aarch64 U-Boot for PPL, although it
would be quite large with all the drivers. Perhaps we could start by
having a generic Rockchip one, for example.

Still I don't see this being strongly related to the discussion about
these two different schemes.

Regards,
Simon

>
> --
> Tom

[1] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-96-sjg@chromium.org/
[2] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-89-sjg@chromium.org/

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 12410 bytes --]

On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > next iteration of xPL.
> > > > >
> > > > > A recent series introduced 'xPL' as the name for the various
> > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > still use filenames and function naming which uses 'spl', but could
> > > > > potentially adjust that.
> > > > >
> > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > medium-sized problems:
> > > > >
> > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > >
> > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > different things. For any given option, some code uses one and some
> > > > > the other, depending on what problems people have met along the way.
> > > > >
> > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > and has not scaled well.
> > > > >
> > > > > d. We need to retain an important feature: options from different
> > > > > phases can depend on each other. As an example, we might want to
> > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > can do this easily today, just by adding Kconfig rules.
> > > >
> > > > I agree with a through c and for d there are likely some cases even if
> > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > important as the other ones.
> > >
> > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > true that SPL needs to know U-Boot's text base.
> > >
> > > Here's another:
> > >
> > > config SPL_SYS_MALLOC_F_LEN
> > >    default SYS_MALLOC_F_LEN
> > >
> > > config TPL_SYS_MALLOC_F
> > >    default y if SPL_SYS_MALLOC_F
> > >
> > > config TPL_SYS_MALLOC_F_LEN
> > >    depends on TPL_SYS_MALLOC_F
> > >    default SPL_SYS_MALLOC_F_LEN
> >
> > Alternatively:
> > config SYS_MALLOC_LEN
> >    ... current default X if Y
> >    default 0x2800 if RCAR_GEN3 && !PPL
> >    default 0x2000 if IMX8MQ && !PPL
> 
> PPL means (in my book) that we have a PPL, i.e. it is always true. It

And in my proposal you're choosing between PPL, SPL, TPL, VPL.

> is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> which build it is. If you are suggesting that SPL means that this is
> the SPL build, then which thing tells us whether or not we have an SPL
> build? I'm just a bit confused by this.

And we wouldn't have CONFIG_SPL_BUILD because we would either be
configuring for SPL=y or SPL=n, there's no confusion anymore.

> But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> SPL one, with your scheme?

If your question is "how do I set an arbitrary but consistent value in
SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
and we should have sane defaults set in Kconfig, regardless of either
proposal. While I'm trying to not get lost in the details today we have
80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
encourage someone to verify those are needed. My initial recollection is
that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
the commonly used default and had the few platforms that didn't use the
new default previously switch to the old one.

In other words, I don't think there's a problem here that isn't solved
today, outside of either proposal.

> So I'm still not understanding how you handle Kconfig dependencies
> between phases with your scheme. Are you saying you don't and they are
> not important?

Basically. The majority of the cases of:
config SPL_FOO
   default y if FOO

config TPL_FOO
   default y if SPL_FOO

Just go away because FOO is already default y or select/imply'd by
TARGET_BAR or ARCH_BAZ.

> Also, is there a single Kconfig tree for U-Boot, or are you saying you
> want a different set of Kconfig files for each phase?

Just the Kconfig files we have today. Likely with less overall lines
since for example we could drop:
config SPL_FS_EXT4
        bool "Support EXT filesystems"
        select SPL_CRC16 if EXT4_WRITE

Since we already have fs/ext4/Kconfig.

> > > > > Proposal
> > > > >
> > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > These contain the values for each Kconfig option for that phase. For
> > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > >
> > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > There are around 200 of these.
> > > > >
> > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > useful in rare cases. This indicates that the option applies only to
> > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > needed at present, basically to allow access to the value for another
> > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > the address to which U-Boot should be loaded.
> > > > >
> > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > menuconfig', which works just as today, including dependencies between
> > > > > options across all phases.
> > > > >
> > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > above.
> > > > >
> > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > phase should be considerably easier.
> > > >
> > > > I think this will not make our life easier, it will make things harder.
> > > >
> > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > time in saying that we were going down the wrong path with how we
> > > > handled SPL/TPL.
> > >
> > > You've mentioned this quite a few times over the years. Is there a
> > > reference to what he suggested we should do? Or perhaps it is what you
> > > have below.
> >
> > I don't recall what he proposed instead, just that when it became clear
> > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > handled to how we're doing it today, he thought that was the wrong
> > direction.
> 
> Yes, IMO he was right about that.
> 
> >
> > > > My request instead is:
> > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > >   DM_MMC) as a prefix.
> > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > >
> > > Good idea.
> > >
> > > > - Split something like rockpro64-rk3399_defconfig in to
> > > >   rockpro64-rk3399_ppl_defconfig
> > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > >   not configs/X_defconfig not existing, we see if any of
> > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > >   subdirectories of our object directory, and then using binman combine
> > > >   as needed.
> > >
> > > This means splitting the existing file into a separate one for each
> > > phase. I believe that will be hard to manage.
> >
> > Do you mean initially, or long term? Initially, it should be a bit of
> > shell scripting. The consolidation (ie most/all rk3399 having an
> > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > would be any different. Most of the maintenance is on resync'ing which
> > is automated.
> 
> Long term. How does 'make menuconfig' work in this case? Won't you
> have to run it three times for SPL, TPL and PPL?

Yes, you would run configure for what you're building. This is a good
thing as it will no longer be so confusing to hunt down where SPL or TPL
or VPL options for a specific thing reside.

> > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > >     and see if it's a different format of say PHASE:file to make it
> > > >     easier to say share a single TPL config with all rk3399, have a few
> > > >     common SPL configs and then just a board specific PPL.
> > > >
> > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > >
> > > The scheme I propose removes a-c also. I should have made that clear.
> >
> > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> 
> Yes I think so...it was a major goal to remove this stuff. [1] [2]

Thanks.

> > > There is not a huge difference between your scheme and mine. My
> > > question is, how do you handle (d)?
> >
> > Well, either (d) isn't important as for example MMC wasn't a good choice
> > in your proposal as virtually everyone "select MMC" today or it's
> > handled more easily as my example above in SYS_MALLOC_LEN.
> >
> > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > single deconfig file and a single 'make menuconfig' for each board.
> > > Yours feels more like building independent U-Boot images.
> >
> > It is explicitly building independent U-Boot images, yes. With a wrapper
> > around "make all of the images for a given platform". So much of our
> > confusing and messy code is because we aren't doing that. And since most
> > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > we really could have fewer overall build configurations.
> 
> I'd really like to see a generic aarch64 U-Boot for PPL, although it
> would be quite large with all the drivers. Perhaps we could start by
> having a generic Rockchip one, for example.
> 
> Still I don't see this being strongly related to the discussion about
> these two different schemes.

Well, in your scheme how do we have say generic-aarch64_defconfig
function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
since everything is a separate build, generic-aarch64_defconfig has
PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
instead of am62x_beagleplay_a53_defconfig and
am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
that would say to use the appropriate SPL/PPL for R5, and appropriate
SPL/PPL for A53.

But the one big huge caveat I want to make here is that "generic" images
are useful in some use cases (I'm sure all of the regular F/OSS
distributions would love a single actually common PPL if they can fit
it) will strip things down. Whatever the IoT edge device closest to you
now really won't want to ship with all the platforms enabled. Image size
still matters.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > next iteration of xPL.
> > > > > >
> > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > potentially adjust that.
> > > > > >
> > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > medium-sized problems:
> > > > > >
> > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > >
> > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > different things. For any given option, some code uses one and some
> > > > > > the other, depending on what problems people have met along the way.
> > > > > >
> > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > and has not scaled well.
> > > > > >
> > > > > > d. We need to retain an important feature: options from different
> > > > > > phases can depend on each other. As an example, we might want to
> > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > can do this easily today, just by adding Kconfig rules.
> > > > >
> > > > > I agree with a through c and for d there are likely some cases even if
> > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > important as the other ones.
> > > >
> > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > true that SPL needs to know U-Boot's text base.
> > > >
> > > > Here's another:
> > > >
> > > > config SPL_SYS_MALLOC_F_LEN
> > > >    default SYS_MALLOC_F_LEN
> > > >
> > > > config TPL_SYS_MALLOC_F
> > > >    default y if SPL_SYS_MALLOC_F
> > > >
> > > > config TPL_SYS_MALLOC_F_LEN
> > > >    depends on TPL_SYS_MALLOC_F
> > > >    default SPL_SYS_MALLOC_F_LEN
> > >
> > > Alternatively:
> > > config SYS_MALLOC_LEN
> > >    ... current default X if Y
> > >    default 0x2800 if RCAR_GEN3 && !PPL
> > >    default 0x2000 if IMX8MQ && !PPL
> >
> > PPL means (in my book) that we have a PPL, i.e. it is always true. It
>
> And in my proposal you're choosing between PPL, SPL, TPL, VPL.
>
> > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > which build it is. If you are suggesting that SPL means that this is
> > the SPL build, then which thing tells us whether or not we have an SPL
> > build? I'm just a bit confused by this.
>
> And we wouldn't have CONFIG_SPL_BUILD because we would either be
> configuring for SPL=y or SPL=n, there's no confusion anymore.
>
> > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > SPL one, with your scheme?
>
> If your question is "how do I set an arbitrary but consistent value in
> SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> and we should have sane defaults set in Kconfig, regardless of either
> proposal. While I'm trying to not get lost in the details today we have
> 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> encourage someone to verify those are needed. My initial recollection is
> that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> the commonly used default and had the few platforms that didn't use the
> new default previously switch to the old one.
>
> In other words, I don't think there's a problem here that isn't solved
> today, outside of either proposal.
>
> > So I'm still not understanding how you handle Kconfig dependencies
> > between phases with your scheme. Are you saying you don't and they are
> > not important?
>
> Basically. The majority of the cases of:
> config SPL_FOO
>    default y if FOO
>
> config TPL_FOO
>    default y if SPL_FOO
>
> Just go away because FOO is already default y or select/imply'd by
> TARGET_BAR or ARCH_BAZ.
>
> > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > want a different set of Kconfig files for each phase?
>
> Just the Kconfig files we have today. Likely with less overall lines
> since for example we could drop:
> config SPL_FS_EXT4
>         bool "Support EXT filesystems"
>         select SPL_CRC16 if EXT4_WRITE
>
> Since we already have fs/ext4/Kconfig.
>
> > > > > > Proposal
> > > > > >
> > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > >
> > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > There are around 200 of these.
> > > > > >
> > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > needed at present, basically to allow access to the value for another
> > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > the address to which U-Boot should be loaded.
> > > > > >
> > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > options across all phases.
> > > > > >
> > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > above.
> > > > > >
> > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > phase should be considerably easier.
> > > > >
> > > > > I think this will not make our life easier, it will make things harder.
> > > > >
> > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > time in saying that we were going down the wrong path with how we
> > > > > handled SPL/TPL.
> > > >
> > > > You've mentioned this quite a few times over the years. Is there a
> > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > have below.
> > >
> > > I don't recall what he proposed instead, just that when it became clear
> > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > handled to how we're doing it today, he thought that was the wrong
> > > direction.
> >
> > Yes, IMO he was right about that.
> >
> > >
> > > > > My request instead is:
> > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > >   DM_MMC) as a prefix.
> > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > >
> > > > Good idea.
> > > >
> > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > >   rockpro64-rk3399_ppl_defconfig
> > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > >   not configs/X_defconfig not existing, we see if any of
> > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > >   subdirectories of our object directory, and then using binman combine
> > > > >   as needed.
> > > >
> > > > This means splitting the existing file into a separate one for each
> > > > phase. I believe that will be hard to manage.
> > >
> > > Do you mean initially, or long term? Initially, it should be a bit of
> > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > would be any different. Most of the maintenance is on resync'ing which
> > > is automated.
> >
> > Long term. How does 'make menuconfig' work in this case? Won't you
> > have to run it three times for SPL, TPL and PPL?
>
> Yes, you would run configure for what you're building. This is a good
> thing as it will no longer be so confusing to hunt down where SPL or TPL
> or VPL options for a specific thing reside.
>
> > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > >     and see if it's a different format of say PHASE:file to make it
> > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > >     common SPL configs and then just a board specific PPL.
> > > > >
> > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > >
> > > > The scheme I propose removes a-c also. I should have made that clear.
> > >
> > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> >
> > Yes I think so...it was a major goal to remove this stuff. [1] [2]
>
> Thanks.
>
> > > > There is not a huge difference between your scheme and mine. My
> > > > question is, how do you handle (d)?
> > >
> > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > in your proposal as virtually everyone "select MMC" today or it's
> > > handled more easily as my example above in SYS_MALLOC_LEN.
> > >
> > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > Yours feels more like building independent U-Boot images.
> > >
> > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > around "make all of the images for a given platform". So much of our
> > > confusing and messy code is because we aren't doing that. And since most
> > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > we really could have fewer overall build configurations.
> >
> > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > would be quite large with all the drivers. Perhaps we could start by
> > having a generic Rockchip one, for example.
> >
> > Still I don't see this being strongly related to the discussion about
> > these two different schemes.
>
> Well, in your scheme how do we have say generic-aarch64_defconfig
> function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> since everything is a separate build, generic-aarch64_defconfig has
> PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> instead of am62x_beagleplay_a53_defconfig and
> am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> that would say to use the appropriate SPL/PPL for R5, and appropriate
> SPL/PPL for A53.
>
> But the one big huge caveat I want to make here is that "generic" images
> are useful in some use cases (I'm sure all of the regular F/OSS
> distributions would love a single actually common PPL if they can fit
> it) will strip things down. Whatever the IoT edge device closest to you
> now really won't want to ship with all the platforms enabled. Image size
> still matters.

OK thanks for the details. I think I have a reasonable idea of what
you are proposing, now. It would work, but is quite radical, IMO.
That's not necessarily a bad thing, but in my mind I see a sequencing
possibility.

A few points from my side:

1. I would love to see the defconfig files reduce in size, with more
and better defaults. One way to do this would be to enforce a maximum
length. I added a feature to qconfig to allow finding common options
among boards (the -i flag), but I'm not sure if many people use it.

2. Generic boards is something I have been pushing for years (in fact
it is why I originally introduced devicetree), but I'm not seeing a
lot of traction.

3. Iit seems that you want to remove all the 'if SPL' pieces and just
rely on the current PPL configuration. But how will that work? There
are tons of features which don't work in SPL, or are not relevant, or
have special 'small' versions. That is a *lot* of Kconfig refactoring
just to get something working, isn't it? With my scheme there is no
Kconfig change needed initially - it can be done later as needed /
desirable.

4. My scheme splits the config into separate files. Yours makes the
split earlier, at the Kconfig level. So it seems that we could go with
my scheme to get us to a split config, then, after that, decide
whether to move that split earlier to Kconfig itself. The choices
would then be to use your scheme (Kconfig refactoring, splitting
defconfigs and some rework), or to do my scheme (which would require
enhancing the Kconfig language a bit just for U-Boot and some optional
rework over time). Both schemes would need a small amount of
build-logic changes, but I'm not sure yet what that would look like.

Does that sound right?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 17604 bytes --]

On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > next iteration of xPL.
> > > > > > >
> > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > potentially adjust that.
> > > > > > >
> > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > medium-sized problems:
> > > > > > >
> > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > >
> > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > different things. For any given option, some code uses one and some
> > > > > > > the other, depending on what problems people have met along the way.
> > > > > > >
> > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > and has not scaled well.
> > > > > > >
> > > > > > > d. We need to retain an important feature: options from different
> > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > >
> > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > important as the other ones.
> > > > >
> > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > true that SPL needs to know U-Boot's text base.
> > > > >
> > > > > Here's another:
> > > > >
> > > > > config SPL_SYS_MALLOC_F_LEN
> > > > >    default SYS_MALLOC_F_LEN
> > > > >
> > > > > config TPL_SYS_MALLOC_F
> > > > >    default y if SPL_SYS_MALLOC_F
> > > > >
> > > > > config TPL_SYS_MALLOC_F_LEN
> > > > >    depends on TPL_SYS_MALLOC_F
> > > > >    default SPL_SYS_MALLOC_F_LEN
> > > >
> > > > Alternatively:
> > > > config SYS_MALLOC_LEN
> > > >    ... current default X if Y
> > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > >    default 0x2000 if IMX8MQ && !PPL
> > >
> > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> >
> > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> >
> > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > which build it is. If you are suggesting that SPL means that this is
> > > the SPL build, then which thing tells us whether or not we have an SPL
> > > build? I'm just a bit confused by this.
> >
> > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > configuring for SPL=y or SPL=n, there's no confusion anymore.
> >
> > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > SPL one, with your scheme?
> >
> > If your question is "how do I set an arbitrary but consistent value in
> > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > and we should have sane defaults set in Kconfig, regardless of either
> > proposal. While I'm trying to not get lost in the details today we have
> > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > encourage someone to verify those are needed. My initial recollection is
> > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > the commonly used default and had the few platforms that didn't use the
> > new default previously switch to the old one.
> >
> > In other words, I don't think there's a problem here that isn't solved
> > today, outside of either proposal.
> >
> > > So I'm still not understanding how you handle Kconfig dependencies
> > > between phases with your scheme. Are you saying you don't and they are
> > > not important?
> >
> > Basically. The majority of the cases of:
> > config SPL_FOO
> >    default y if FOO
> >
> > config TPL_FOO
> >    default y if SPL_FOO
> >
> > Just go away because FOO is already default y or select/imply'd by
> > TARGET_BAR or ARCH_BAZ.
> >
> > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > want a different set of Kconfig files for each phase?
> >
> > Just the Kconfig files we have today. Likely with less overall lines
> > since for example we could drop:
> > config SPL_FS_EXT4
> >         bool "Support EXT filesystems"
> >         select SPL_CRC16 if EXT4_WRITE
> >
> > Since we already have fs/ext4/Kconfig.
> >
> > > > > > > Proposal
> > > > > > >
> > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > >
> > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > There are around 200 of these.
> > > > > > >
> > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > the address to which U-Boot should be loaded.
> > > > > > >
> > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > options across all phases.
> > > > > > >
> > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > above.
> > > > > > >
> > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > phase should be considerably easier.
> > > > > >
> > > > > > I think this will not make our life easier, it will make things harder.
> > > > > >
> > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > time in saying that we were going down the wrong path with how we
> > > > > > handled SPL/TPL.
> > > > >
> > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > have below.
> > > >
> > > > I don't recall what he proposed instead, just that when it became clear
> > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > handled to how we're doing it today, he thought that was the wrong
> > > > direction.
> > >
> > > Yes, IMO he was right about that.
> > >
> > > >
> > > > > > My request instead is:
> > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > >   DM_MMC) as a prefix.
> > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > >
> > > > > Good idea.
> > > > >
> > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > >   as needed.
> > > > >
> > > > > This means splitting the existing file into a separate one for each
> > > > > phase. I believe that will be hard to manage.
> > > >
> > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > would be any different. Most of the maintenance is on resync'ing which
> > > > is automated.
> > >
> > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > have to run it three times for SPL, TPL and PPL?
> >
> > Yes, you would run configure for what you're building. This is a good
> > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > or VPL options for a specific thing reside.
> >
> > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > >     common SPL configs and then just a board specific PPL.
> > > > > >
> > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > >
> > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > >
> > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > >
> > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> >
> > Thanks.
> >
> > > > > There is not a huge difference between your scheme and mine. My
> > > > > question is, how do you handle (d)?
> > > >
> > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > >
> > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > Yours feels more like building independent U-Boot images.
> > > >
> > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > around "make all of the images for a given platform". So much of our
> > > > confusing and messy code is because we aren't doing that. And since most
> > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > we really could have fewer overall build configurations.
> > >
> > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > would be quite large with all the drivers. Perhaps we could start by
> > > having a generic Rockchip one, for example.
> > >
> > > Still I don't see this being strongly related to the discussion about
> > > these two different schemes.
> >
> > Well, in your scheme how do we have say generic-aarch64_defconfig
> > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > since everything is a separate build, generic-aarch64_defconfig has
> > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > instead of am62x_beagleplay_a53_defconfig and
> > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > SPL/PPL for A53.
> >
> > But the one big huge caveat I want to make here is that "generic" images
> > are useful in some use cases (I'm sure all of the regular F/OSS
> > distributions would love a single actually common PPL if they can fit
> > it) will strip things down. Whatever the IoT edge device closest to you
> > now really won't want to ship with all the platforms enabled. Image size
> > still matters.
> 
> OK thanks for the details. I think I have a reasonable idea of what
> you are proposing, now. It would work, but is quite radical, IMO.
> That's not necessarily a bad thing, but in my mind I see a sequencing
> possibility.
> 
> A few points from my side:
> 
> 1. I would love to see the defconfig files reduce in size, with more
> and better defaults. One way to do this would be to enforce a maximum
> length. I added a feature to qconfig to allow finding common options
> among boards (the -i flag), but I'm not sure if many people use it.

I don't see reducing defconfig size as important honestly. Should we
have more and better defaults? Yes. But almost everything is under 200
lines with the biggest (non-sandbox) ones being the generic zynqmp
platform(s?).

> 2. Generic boards is something I have been pushing for years (in fact
> it is why I originally introduced devicetree), but I'm not seeing a
> lot of traction.

I don't think generic boards are universally helpful. Even if what I'm
proposing would allow for more of it, below the PPL stage I'm not sure
it's both feasible enough and useful enough for production. At the PPL
stage it still has to be small enough and not overly burdensome. What we
talked about on the call yesterday about using more multi-dtb images is
a step in the right direction, yes.

> 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> rely on the current PPL configuration. But how will that work? There
> are tons of features which don't work in SPL, or are not relevant, or
> have special 'small' versions. That is a *lot* of Kconfig refactoring
> just to get something working, isn't it? With my scheme there is no
> Kconfig change needed initially - it can be done later as needed /
> desirable.

I don't think we would remove most "if SPL" cases. Taking part of the
current stanza for ROCKCHIP_RK3399 as an example:
config ROCKCHIP_RK3399
        bool "Support Rockchip RK3399"
        select ARM64
        select SUPPORT_SPL
        select SUPPORT_TPL
        select SPL
        select SPL_ATF
        select SPL_BOARD_INIT if SPL
	...
        select SPL_CLK if SPL
	...
        select CLK
	...
	imply TPL_CLK


This would become:
config ROCKCHIP_RK3399
        bool "Support Rockchip RK3399"
        select ARM64
        select SUPPORT_SPL
        select SUPPORT_TPL
        select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
        select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
        select CLK # imply was likely wrong before? Would need to check
	...

> 4. My scheme splits the config into separate files. Yours makes the

I don't see yours as splitting the configs in to separate files, I see
it as generating some intermediate objects. The configs don't change and
that's one of our problem areas.

> split earlier, at the Kconfig level. So it seems that we could go with
> my scheme to get us to a split config, then, after that, decide
> whether to move that split earlier to Kconfig itself. The choices

I don't think so. Yours makes things complicated by making the build do
even more (and from the RFC, the implementation tooling diverges from
upstream). Mine makes things differently complicated by doing less for
most things, but needing some thought on how to know that say
chromebook_bob needs chromebook_bob_tpl_defconfig,
chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
built, before asking binman to go put things together.

> would then be to use your scheme (Kconfig refactoring, splitting
> defconfigs and some rework), or to do my scheme (which would require
> enhancing the Kconfig language a bit just for U-Boot and some optional
> rework over time). Both schemes would need a small amount of
> build-logic changes, but I'm not sure yet what that would look like.
> 
> Does that sound right?

With what I said above, yes I think we're closer at least to
understanding each other.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > next iteration of xPL.
> > > > > > > >
> > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > potentially adjust that.
> > > > > > > >
> > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > medium-sized problems:
> > > > > > > >
> > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > >
> > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > >
> > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > and has not scaled well.
> > > > > > > >
> > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > >
> > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > important as the other ones.
> > > > > >
> > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > true that SPL needs to know U-Boot's text base.
> > > > > >
> > > > > > Here's another:
> > > > > >
> > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > >    default SYS_MALLOC_F_LEN
> > > > > >
> > > > > > config TPL_SYS_MALLOC_F
> > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > >
> > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > >
> > > > > Alternatively:
> > > > > config SYS_MALLOC_LEN
> > > > >    ... current default X if Y
> > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > >    default 0x2000 if IMX8MQ && !PPL
> > > >
> > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > >
> > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > >
> > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > which build it is. If you are suggesting that SPL means that this is
> > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > build? I'm just a bit confused by this.
> > >
> > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > >
> > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > SPL one, with your scheme?
> > >
> > > If your question is "how do I set an arbitrary but consistent value in
> > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > and we should have sane defaults set in Kconfig, regardless of either
> > > proposal. While I'm trying to not get lost in the details today we have
> > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > encourage someone to verify those are needed. My initial recollection is
> > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > the commonly used default and had the few platforms that didn't use the
> > > new default previously switch to the old one.
> > >
> > > In other words, I don't think there's a problem here that isn't solved
> > > today, outside of either proposal.
> > >
> > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > between phases with your scheme. Are you saying you don't and they are
> > > > not important?
> > >
> > > Basically. The majority of the cases of:
> > > config SPL_FOO
> > >    default y if FOO
> > >
> > > config TPL_FOO
> > >    default y if SPL_FOO
> > >
> > > Just go away because FOO is already default y or select/imply'd by
> > > TARGET_BAR or ARCH_BAZ.
> > >
> > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > want a different set of Kconfig files for each phase?
> > >
> > > Just the Kconfig files we have today. Likely with less overall lines
> > > since for example we could drop:
> > > config SPL_FS_EXT4
> > >         bool "Support EXT filesystems"
> > >         select SPL_CRC16 if EXT4_WRITE
> > >
> > > Since we already have fs/ext4/Kconfig.
> > >
> > > > > > > > Proposal
> > > > > > > >
> > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > >
> > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > There are around 200 of these.
> > > > > > > >
> > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > >
> > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > options across all phases.
> > > > > > > >
> > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > above.
> > > > > > > >
> > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > phase should be considerably easier.
> > > > > > >
> > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > >
> > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > handled SPL/TPL.
> > > > > >
> > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > have below.
> > > > >
> > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > direction.
> > > >
> > > > Yes, IMO he was right about that.
> > > >
> > > > >
> > > > > > > My request instead is:
> > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > >   DM_MMC) as a prefix.
> > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > >
> > > > > > Good idea.
> > > > > >
> > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > >   as needed.
> > > > > >
> > > > > > This means splitting the existing file into a separate one for each
> > > > > > phase. I believe that will be hard to manage.
> > > > >
> > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > is automated.
> > > >
> > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > have to run it three times for SPL, TPL and PPL?
> > >
> > > Yes, you would run configure for what you're building. This is a good
> > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > or VPL options for a specific thing reside.
> > >
> > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > >
> > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > >
> > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > >
> > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > >
> > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > >
> > > Thanks.
> > >
> > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > question is, how do you handle (d)?
> > > > >
> > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > >
> > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > Yours feels more like building independent U-Boot images.
> > > > >
> > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > around "make all of the images for a given platform". So much of our
> > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > we really could have fewer overall build configurations.
> > > >
> > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > would be quite large with all the drivers. Perhaps we could start by
> > > > having a generic Rockchip one, for example.
> > > >
> > > > Still I don't see this being strongly related to the discussion about
> > > > these two different schemes.
> > >
> > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > since everything is a separate build, generic-aarch64_defconfig has
> > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > instead of am62x_beagleplay_a53_defconfig and
> > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > SPL/PPL for A53.
> > >
> > > But the one big huge caveat I want to make here is that "generic" images
> > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > distributions would love a single actually common PPL if they can fit
> > > it) will strip things down. Whatever the IoT edge device closest to you
> > > now really won't want to ship with all the platforms enabled. Image size
> > > still matters.
> >
> > OK thanks for the details. I think I have a reasonable idea of what
> > you are proposing, now. It would work, but is quite radical, IMO.
> > That's not necessarily a bad thing, but in my mind I see a sequencing
> > possibility.
> >
> > A few points from my side:
> >
> > 1. I would love to see the defconfig files reduce in size, with more
> > and better defaults. One way to do this would be to enforce a maximum
> > length. I added a feature to qconfig to allow finding common options
> > among boards (the -i flag), but I'm not sure if many people use it.
>
> I don't see reducing defconfig size as important honestly. Should we
> have more and better defaults? Yes. But almost everything is under 200
> lines with the biggest (non-sandbox) ones being the generic zynqmp
> platform(s?).

Agreed.

>
> > 2. Generic boards is something I have been pushing for years (in fact
> > it is why I originally introduced devicetree), but I'm not seeing a
> > lot of traction.
>
> I don't think generic boards are universally helpful. Even if what I'm
> proposing would allow for more of it, below the PPL stage I'm not sure
> it's both feasible enough and useful enough for production. At the PPL
> stage it still has to be small enough and not overly burdensome. What we
> talked about on the call yesterday about using more multi-dtb images is
> a step in the right direction, yes.

Agreed. Anway, we can create separate targets for generic boards if we want to.

>
> > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > rely on the current PPL configuration. But how will that work? There
> > are tons of features which don't work in SPL, or are not relevant, or
> > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > just to get something working, isn't it? With my scheme there is no
> > Kconfig change needed initially - it can be done later as needed /
> > desirable.
>
> I don't think we would remove most "if SPL" cases. Taking part of the
> current stanza for ROCKCHIP_RK3399 as an example:
> config ROCKCHIP_RK3399
>         bool "Support Rockchip RK3399"
>         select ARM64
>         select SUPPORT_SPL
>         select SUPPORT_TPL
>         select SPL
>         select SPL_ATF
>         select SPL_BOARD_INIT if SPL
>         ...
>         select SPL_CLK if SPL
>         ...
>         select CLK
>         ...
>         imply TPL_CLK
>
>
> This would become:
> config ROCKCHIP_RK3399
>         bool "Support Rockchip RK3399"
>         select ARM64
>         select SUPPORT_SPL
>         select SUPPORT_TPL
>         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
>         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
>         select CLK # imply was likely wrong before? Would need to check
>         ...

I was more talking about the large blocks of 'if SPL' - e.g. we have
common/spl/Kconfig and common/spl/Kconfig.tpl

But just the level of thought required in your small example above
suggests it is a large effort.

>
> > 4. My scheme splits the config into separate files. Yours makes the
>
> I don't see yours as splitting the configs in to separate files, I see
> it as generating some intermediate objects. The configs don't change and
> that's one of our problem areas.

So you mean a big problem area is the current Kconfig?  Mind generates
out to an include/generated/autoconf_xxx for each phase. Yes they are
intermediate files and auto-generated, but each 100% controls its
phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
rules anymore.

>
> > split earlier, at the Kconfig level. So it seems that we could go with
> > my scheme to get us to a split config, then, after that, decide
> > whether to move that split earlier to Kconfig itself. The choices
>
> I don't think so. Yours makes things complicated by making the build do
> even more (and from the RFC, the implementation tooling diverges from
> upstream).

Yes it makes the kconf tool generate those separate files for each phase [3]

> Mine makes things differently complicated by doing less for
> most things, but needing some thought on how to know that say
> chromebook_bob needs chromebook_bob_tpl_defconfig,
> chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> built, before asking binman to go put things together.

Yours seems feasible in a fully Binman world, but given the difficulty
we (or I) have completing a migration, I honestly don't believe this
is feasible in today's U-Boot. The other problem is that it all has to
be done at once. We need to rewrite the Kconfig and flip over the
board. Will we carry people with us? That is a huge risk to the
project IMO.

Anyway, yes my schema makes the build do even more (with 400 lines of
kconf additions and a patch that can likely be upstreamed). But
otherwise, it is a one-off improvement, without any changes to the
existing Kconfig.

So my point is that we could go with the first part of my scheme to
resolve the 'medium' problems then decide which way to continue after
that. From your side you won't have lost anything towards where you
want to head. The two options would then be:

- exhance kconfig language to build in the notion of phases
- split the defconfigs for each board, redo the Kconfig rules and
teach the build to combine images

>
> > would then be to use your scheme (Kconfig refactoring, splitting
> > defconfigs and some rework), or to do my scheme (which would require
> > enhancing the Kconfig language a bit just for U-Boot and some optional
> > rework over time). Both schemes would need a small amount of
> > build-logic changes, but I'm not sure yet what that would look like.
> >
> > Does that sound right?
>
> With what I said above, yes I think we're closer at least to
> understanding each other.

Yes.

Regards,
Simon

>
> --
> Tom

[3] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-62-sjg@chromium.org/

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 23099 bytes --]

On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > next iteration of xPL.
> > > > > > > > >
> > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > potentially adjust that.
> > > > > > > > >
> > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > medium-sized problems:
> > > > > > > > >
> > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > >
> > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > >
> > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > and has not scaled well.
> > > > > > > > >
> > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > >
> > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > important as the other ones.
> > > > > > >
> > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > >
> > > > > > > Here's another:
> > > > > > >
> > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > >
> > > > > > > config TPL_SYS_MALLOC_F
> > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > >
> > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > >
> > > > > > Alternatively:
> > > > > > config SYS_MALLOC_LEN
> > > > > >    ... current default X if Y
> > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > >
> > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > >
> > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > >
> > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > build? I'm just a bit confused by this.
> > > >
> > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > >
> > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > SPL one, with your scheme?
> > > >
> > > > If your question is "how do I set an arbitrary but consistent value in
> > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > proposal. While I'm trying to not get lost in the details today we have
> > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > encourage someone to verify those are needed. My initial recollection is
> > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > the commonly used default and had the few platforms that didn't use the
> > > > new default previously switch to the old one.
> > > >
> > > > In other words, I don't think there's a problem here that isn't solved
> > > > today, outside of either proposal.
> > > >
> > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > not important?
> > > >
> > > > Basically. The majority of the cases of:
> > > > config SPL_FOO
> > > >    default y if FOO
> > > >
> > > > config TPL_FOO
> > > >    default y if SPL_FOO
> > > >
> > > > Just go away because FOO is already default y or select/imply'd by
> > > > TARGET_BAR or ARCH_BAZ.
> > > >
> > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > want a different set of Kconfig files for each phase?
> > > >
> > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > since for example we could drop:
> > > > config SPL_FS_EXT4
> > > >         bool "Support EXT filesystems"
> > > >         select SPL_CRC16 if EXT4_WRITE
> > > >
> > > > Since we already have fs/ext4/Kconfig.
> > > >
> > > > > > > > > Proposal
> > > > > > > > >
> > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > >
> > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > There are around 200 of these.
> > > > > > > > >
> > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > >
> > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > options across all phases.
> > > > > > > > >
> > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > above.
> > > > > > > > >
> > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > phase should be considerably easier.
> > > > > > > >
> > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > >
> > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > handled SPL/TPL.
> > > > > > >
> > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > have below.
> > > > > >
> > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > direction.
> > > > >
> > > > > Yes, IMO he was right about that.
> > > > >
> > > > > >
> > > > > > > > My request instead is:
> > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > >
> > > > > > > Good idea.
> > > > > > >
> > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > >   as needed.
> > > > > > >
> > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > phase. I believe that will be hard to manage.
> > > > > >
> > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > is automated.
> > > > >
> > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > have to run it three times for SPL, TPL and PPL?
> > > >
> > > > Yes, you would run configure for what you're building. This is a good
> > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > or VPL options for a specific thing reside.
> > > >
> > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > >
> > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > >
> > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > >
> > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > >
> > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > >
> > > > Thanks.
> > > >
> > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > question is, how do you handle (d)?
> > > > > >
> > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > >
> > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > Yours feels more like building independent U-Boot images.
> > > > > >
> > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > around "make all of the images for a given platform". So much of our
> > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > we really could have fewer overall build configurations.
> > > > >
> > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > having a generic Rockchip one, for example.
> > > > >
> > > > > Still I don't see this being strongly related to the discussion about
> > > > > these two different schemes.
> > > >
> > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > instead of am62x_beagleplay_a53_defconfig and
> > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > SPL/PPL for A53.
> > > >
> > > > But the one big huge caveat I want to make here is that "generic" images
> > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > distributions would love a single actually common PPL if they can fit
> > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > now really won't want to ship with all the platforms enabled. Image size
> > > > still matters.
> > >
> > > OK thanks for the details. I think I have a reasonable idea of what
> > > you are proposing, now. It would work, but is quite radical, IMO.
> > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > possibility.
> > >
> > > A few points from my side:
> > >
> > > 1. I would love to see the defconfig files reduce in size, with more
> > > and better defaults. One way to do this would be to enforce a maximum
> > > length. I added a feature to qconfig to allow finding common options
> > > among boards (the -i flag), but I'm not sure if many people use it.
> >
> > I don't see reducing defconfig size as important honestly. Should we
> > have more and better defaults? Yes. But almost everything is under 200
> > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > platform(s?).
> 
> Agreed.
> 
> >
> > > 2. Generic boards is something I have been pushing for years (in fact
> > > it is why I originally introduced devicetree), but I'm not seeing a
> > > lot of traction.
> >
> > I don't think generic boards are universally helpful. Even if what I'm
> > proposing would allow for more of it, below the PPL stage I'm not sure
> > it's both feasible enough and useful enough for production. At the PPL
> > stage it still has to be small enough and not overly burdensome. What we
> > talked about on the call yesterday about using more multi-dtb images is
> > a step in the right direction, yes.
> 
> Agreed. Anway, we can create separate targets for generic boards if we want to.
> 
> >
> > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > rely on the current PPL configuration. But how will that work? There
> > > are tons of features which don't work in SPL, or are not relevant, or
> > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > just to get something working, isn't it? With my scheme there is no
> > > Kconfig change needed initially - it can be done later as needed /
> > > desirable.
> >
> > I don't think we would remove most "if SPL" cases. Taking part of the
> > current stanza for ROCKCHIP_RK3399 as an example:
> > config ROCKCHIP_RK3399
> >         bool "Support Rockchip RK3399"
> >         select ARM64
> >         select SUPPORT_SPL
> >         select SUPPORT_TPL
> >         select SPL
> >         select SPL_ATF
> >         select SPL_BOARD_INIT if SPL
> >         ...
> >         select SPL_CLK if SPL
> >         ...
> >         select CLK
> >         ...
> >         imply TPL_CLK
> >
> >
> > This would become:
> > config ROCKCHIP_RK3399
> >         bool "Support Rockchip RK3399"
> >         select ARM64
> >         select SUPPORT_SPL
> >         select SUPPORT_TPL
> >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> >         select CLK # imply was likely wrong before? Would need to check
> >         ...
> 
> I was more talking about the large blocks of 'if SPL' - e.g. we have
> common/spl/Kconfig and common/spl/Kconfig.tpl

I would vastly reduce the contents within those 'if' blocks, but there
are still options that are xPL-centric without a PPL counterpart, such
as SPL_ATF (I suspect, but if not I'm sure others).

> But just the level of thought required in your small example above
> suggests it is a large effort.

Yes, restructuring our Kconfig logic and then removing our xPL logic is
some work. So was, I suspect, all of what you did already.

> > > 4. My scheme splits the config into separate files. Yours makes the
> >
> > I don't see yours as splitting the configs in to separate files, I see
> > it as generating some intermediate objects. The configs don't change and
> > that's one of our problem areas.
> 
> So you mean a big problem area is the current Kconfig?

I mean it's a problem for users a board developers to make valid
configurations and update them as needed. Filesystems are in the
filesystem menu, unless they're SPL and then it's all under the big SPL
menu.

> Mind generates
> out to an include/generated/autoconf_xxx for each phase. Yes they are
> intermediate files and auto-generated, but each 100% controls its
> phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> rules anymore.

Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
good. But the intermediate files aren't going to help (nor hurt) any of
the problems themselves. If you're reading those to figure out a
problem, it's like when you're reading a .i file to figure out a
problem, it means you're already in a complex troublesome spot.

But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
CONFIG_FS_FAT=y does.

> > > split earlier, at the Kconfig level. So it seems that we could go with
> > > my scheme to get us to a split config, then, after that, decide
> > > whether to move that split earlier to Kconfig itself. The choices
> >
> > I don't think so. Yours makes things complicated by making the build do
> > even more (and from the RFC, the implementation tooling diverges from
> > upstream).
> 
> Yes it makes the kconf tool generate those separate files for each phase [3]
> 
> > Mine makes things differently complicated by doing less for
> > most things, but needing some thought on how to know that say
> > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > built, before asking binman to go put things together.
> 
> Yours seems feasible in a fully Binman world, but given the difficulty
> we (or I) have completing a migration, I honestly don't believe this
> is feasible in today's U-Boot. The other problem is that it all has to

I'm not 100% sure it's everything needs binman actually. Or even if we
do take this as a reason to push for more binman, it's just some trivial
types already handled in the Makefile that's missing.

> be done at once. We need to rewrite the Kconfig and flip over the
> board. Will we carry people with us? That is a huge risk to the
> project IMO.

I'm not sure, actually, that it couldn't be done in stages. We might
need a little bit of fakery around being able to just build SPL without
PPL in the interim.

> Anyway, yes my schema makes the build do even more (with 400 lines of
> kconf additions and a patch that can likely be upstreamed). But
> otherwise, it is a one-off improvement, without any changes to the
> existing Kconfig.

I thought Yamada-san rejected changes going in this direction before?
But either way, no it's not likely the final overburden in terms of
divergence.

> So my point is that we could go with the first part of my scheme to
> resolve the 'medium' problems then decide which way to continue after
> that. From your side you won't have lost anything towards where you
> want to head. The two options would then be:
> 
> - exhance kconfig language to build in the notion of phases
> - split the defconfigs for each board, redo the Kconfig rules and
> teach the build to combine images

If things go down your proposed path instead, no, I don't see that as
making it meaningfully easier to go the way I proposed later. The only
commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
IS_ENABLED. And (almost) all of that is a script'able change.

> > > would then be to use your scheme (Kconfig refactoring, splitting
> > > defconfigs and some rework), or to do my scheme (which would require
> > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > rework over time). Both schemes would need a small amount of
> > > build-logic changes, but I'm not sure yet what that would look like.
> > >
> > > Does that sound right?
> >
> > With what I said above, yes I think we're closer at least to
> > understanding each other.
> 
> Yes.

Well, with that, what now?

What makes the current situation untenable is VPL. And I gather I
haven't convinced you to put that on hold long enough to instead rework
how we build things, have I?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > next iteration of xPL.
> > > > > > > > > >
> > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > potentially adjust that.
> > > > > > > > > >
> > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > medium-sized problems:
> > > > > > > > > >
> > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > >
> > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > >
> > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > and has not scaled well.
> > > > > > > > > >
> > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > >
> > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > important as the other ones.
> > > > > > > >
> > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > >
> > > > > > > > Here's another:
> > > > > > > >
> > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > >
> > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > >
> > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > >
> > > > > > > Alternatively:
> > > > > > > config SYS_MALLOC_LEN
> > > > > > >    ... current default X if Y
> > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > >
> > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > >
> > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > >
> > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > build? I'm just a bit confused by this.
> > > > >
> > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > >
> > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > SPL one, with your scheme?
> > > > >
> > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > the commonly used default and had the few platforms that didn't use the
> > > > > new default previously switch to the old one.
> > > > >
> > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > today, outside of either proposal.
> > > > >
> > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > not important?
> > > > >
> > > > > Basically. The majority of the cases of:
> > > > > config SPL_FOO
> > > > >    default y if FOO
> > > > >
> > > > > config TPL_FOO
> > > > >    default y if SPL_FOO
> > > > >
> > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > TARGET_BAR or ARCH_BAZ.
> > > > >
> > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > want a different set of Kconfig files for each phase?
> > > > >
> > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > since for example we could drop:
> > > > > config SPL_FS_EXT4
> > > > >         bool "Support EXT filesystems"
> > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > >
> > > > > Since we already have fs/ext4/Kconfig.
> > > > >
> > > > > > > > > > Proposal
> > > > > > > > > >
> > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > >
> > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > There are around 200 of these.
> > > > > > > > > >
> > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > >
> > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > options across all phases.
> > > > > > > > > >
> > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > above.
> > > > > > > > > >
> > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > phase should be considerably easier.
> > > > > > > > >
> > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > >
> > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > handled SPL/TPL.
> > > > > > > >
> > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > have below.
> > > > > > >
> > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > direction.
> > > > > >
> > > > > > Yes, IMO he was right about that.
> > > > > >
> > > > > > >
> > > > > > > > > My request instead is:
> > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > >
> > > > > > > > Good idea.
> > > > > > > >
> > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > >   as needed.
> > > > > > > >
> > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > phase. I believe that will be hard to manage.
> > > > > > >
> > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > is automated.
> > > > > >
> > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > have to run it three times for SPL, TPL and PPL?
> > > > >
> > > > > Yes, you would run configure for what you're building. This is a good
> > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > or VPL options for a specific thing reside.
> > > > >
> > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > >
> > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > >
> > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > >
> > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > >
> > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > >
> > > > > Thanks.
> > > > >
> > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > question is, how do you handle (d)?
> > > > > > >
> > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > >
> > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > >
> > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > we really could have fewer overall build configurations.
> > > > > >
> > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > having a generic Rockchip one, for example.
> > > > > >
> > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > these two different schemes.
> > > > >
> > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > SPL/PPL for A53.
> > > > >
> > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > distributions would love a single actually common PPL if they can fit
> > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > still matters.
> > > >
> > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > possibility.
> > > >
> > > > A few points from my side:
> > > >
> > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > and better defaults. One way to do this would be to enforce a maximum
> > > > length. I added a feature to qconfig to allow finding common options
> > > > among boards (the -i flag), but I'm not sure if many people use it.
> > >
> > > I don't see reducing defconfig size as important honestly. Should we
> > > have more and better defaults? Yes. But almost everything is under 200
> > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > platform(s?).
> >
> > Agreed.
> >
> > >
> > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > lot of traction.
> > >
> > > I don't think generic boards are universally helpful. Even if what I'm
> > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > it's both feasible enough and useful enough for production. At the PPL
> > > stage it still has to be small enough and not overly burdensome. What we
> > > talked about on the call yesterday about using more multi-dtb images is
> > > a step in the right direction, yes.
> >
> > Agreed. Anway, we can create separate targets for generic boards if we want to.
> >
> > >
> > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > rely on the current PPL configuration. But how will that work? There
> > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > just to get something working, isn't it? With my scheme there is no
> > > > Kconfig change needed initially - it can be done later as needed /
> > > > desirable.
> > >
> > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > current stanza for ROCKCHIP_RK3399 as an example:
> > > config ROCKCHIP_RK3399
> > >         bool "Support Rockchip RK3399"
> > >         select ARM64
> > >         select SUPPORT_SPL
> > >         select SUPPORT_TPL
> > >         select SPL
> > >         select SPL_ATF
> > >         select SPL_BOARD_INIT if SPL
> > >         ...
> > >         select SPL_CLK if SPL
> > >         ...
> > >         select CLK
> > >         ...
> > >         imply TPL_CLK
> > >
> > >
> > > This would become:
> > > config ROCKCHIP_RK3399
> > >         bool "Support Rockchip RK3399"
> > >         select ARM64
> > >         select SUPPORT_SPL
> > >         select SUPPORT_TPL
> > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > >         select CLK # imply was likely wrong before? Would need to check
> > >         ...
> >
> > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > common/spl/Kconfig and common/spl/Kconfig.tpl
>
> I would vastly reduce the contents within those 'if' blocks, but there
> are still options that are xPL-centric without a PPL counterpart, such
> as SPL_ATF (I suspect, but if not I'm sure others).
>
> > But just the level of thought required in your small example above
> > suggests it is a large effort.
>
> Yes, restructuring our Kconfig logic and then removing our xPL logic is
> some work. So was, I suspect, all of what you did already.
>
> > > > 4. My scheme splits the config into separate files. Yours makes the
> > >
> > > I don't see yours as splitting the configs in to separate files, I see
> > > it as generating some intermediate objects. The configs don't change and
> > > that's one of our problem areas.
> >
> > So you mean a big problem area is the current Kconfig?
>
> I mean it's a problem for users a board developers to make valid
> configurations and update them as needed. Filesystems are in the
> filesystem menu, unless they're SPL and then it's all under the big SPL
> menu.
>
> > Mind generates
> > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > intermediate files and auto-generated, but each 100% controls its
> > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > rules anymore.
>
> Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> good. But the intermediate files aren't going to help (nor hurt) any of
> the problems themselves. If you're reading those to figure out a
> problem, it's like when you're reading a .i file to figure out a
> problem, it means you're already in a complex troublesome spot.
>
> But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> CONFIG_FS_FAT=y does.
>
> > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > my scheme to get us to a split config, then, after that, decide
> > > > whether to move that split earlier to Kconfig itself. The choices
> > >
> > > I don't think so. Yours makes things complicated by making the build do
> > > even more (and from the RFC, the implementation tooling diverges from
> > > upstream).
> >
> > Yes it makes the kconf tool generate those separate files for each phase [3]
> >
> > > Mine makes things differently complicated by doing less for
> > > most things, but needing some thought on how to know that say
> > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > built, before asking binman to go put things together.
> >
> > Yours seems feasible in a fully Binman world, but given the difficulty
> > we (or I) have completing a migration, I honestly don't believe this
> > is feasible in today's U-Boot. The other problem is that it all has to
>
> I'm not 100% sure it's everything needs binman actually. Or even if we
> do take this as a reason to push for more binman, it's just some trivial
> types already handled in the Makefile that's missing.
>
> > be done at once. We need to rewrite the Kconfig and flip over the
> > board. Will we carry people with us? That is a huge risk to the
> > project IMO.
>
> I'm not sure, actually, that it couldn't be done in stages. We might
> need a little bit of fakery around being able to just build SPL without
> PPL in the interim.
>
> > Anyway, yes my schema makes the build do even more (with 400 lines of
> > kconf additions and a patch that can likely be upstreamed). But
> > otherwise, it is a one-off improvement, without any changes to the
> > existing Kconfig.
>
> I thought Yamada-san rejected changes going in this direction before?
> But either way, no it's not likely the final overburden in terms of
> divergence.


Yes. Masahiro will make his own decisions and I am confident he will
reject any future changes I send

>
> > So my point is that we could go with the first part of my scheme to
> > resolve the 'medium' problems then decide which way to continue after
> > that. From your side you won't have lost anything towards where you
> > want to head. The two options would then be:
> >
> > - exhance kconfig language to build in the notion of phases
> > - split the defconfigs for each board, redo the Kconfig rules and
> > teach the build to combine images
>
> If things go down your proposed path instead, no, I don't see that as
> making it meaningfully easier to go the way I proposed later. The only
> commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> IS_ENABLED. And (almost) all of that is a script'able change.

To be frank, the difference is that I have actually put in the work to
try this. It is more than 50 and perhaps as many as 100 patches. Quite
difficult work. Honestly, compared to that, the logic changes are not
that large.

That is why I believe this work is a prerequisite for both schemes

>
> > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > defconfigs and some rework), or to do my scheme (which would require
> > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > rework over time). Both schemes would need a small amount of
> > > > build-logic changes, but I'm not sure yet what that would look like.
> > > >
> > > > Does that sound right?
> > >
> > > With what I said above, yes I think we're closer at least to
> > > understanding each other.
> >
> > Yes.
>
> Well, with that, what now?
>
> What makes the current situation untenable is VPL. And I gather I
> haven't convinced you to put that on hold long enough to instead rework
> how we build things, have I?

Which VPL thing?

You have convinced me that you have a solution. It makes a lot more
sense to me than previously and it may be that it is better in the
end. For example, with VBE it I would make a lot of sense to build 20
boards as just TPL and use a generic rock chip board for everything
else. That would be a lot tidier with your scheme. It is very hard to
predict the future and VBE is still not finished, some two years in.

I don't want to be tied to your scheme today though.

So if you can accept my going ahead with 1-4 and helping me with that,
then we can stop and discuss which way to go, perhaps by prototyping
the two options?

Regards,
Simon

>
> --
> Tom

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 28566 bytes --]

On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > >
> > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > potentially adjust that.
> > > > > > > > > > >
> > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > medium-sized problems:
> > > > > > > > > > >
> > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > >
> > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > >
> > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > and has not scaled well.
> > > > > > > > > > >
> > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > >
> > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > important as the other ones.
> > > > > > > > >
> > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > >
> > > > > > > > > Here's another:
> > > > > > > > >
> > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > >
> > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > >
> > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > >
> > > > > > > > Alternatively:
> > > > > > > > config SYS_MALLOC_LEN
> > > > > > > >    ... current default X if Y
> > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > >
> > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > >
> > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > >
> > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > build? I'm just a bit confused by this.
> > > > > >
> > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > >
> > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > SPL one, with your scheme?
> > > > > >
> > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > new default previously switch to the old one.
> > > > > >
> > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > today, outside of either proposal.
> > > > > >
> > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > not important?
> > > > > >
> > > > > > Basically. The majority of the cases of:
> > > > > > config SPL_FOO
> > > > > >    default y if FOO
> > > > > >
> > > > > > config TPL_FOO
> > > > > >    default y if SPL_FOO
> > > > > >
> > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > >
> > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > want a different set of Kconfig files for each phase?
> > > > > >
> > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > since for example we could drop:
> > > > > > config SPL_FS_EXT4
> > > > > >         bool "Support EXT filesystems"
> > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > >
> > > > > > Since we already have fs/ext4/Kconfig.
> > > > > >
> > > > > > > > > > > Proposal
> > > > > > > > > > >
> > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > >
> > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > >
> > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > >
> > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > options across all phases.
> > > > > > > > > > >
> > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > above.
> > > > > > > > > > >
> > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > >
> > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > >
> > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > handled SPL/TPL.
> > > > > > > > >
> > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > have below.
> > > > > > > >
> > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > direction.
> > > > > > >
> > > > > > > Yes, IMO he was right about that.
> > > > > > >
> > > > > > > >
> > > > > > > > > > My request instead is:
> > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > >
> > > > > > > > > Good idea.
> > > > > > > > >
> > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > >   as needed.
> > > > > > > > >
> > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > >
> > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > is automated.
> > > > > > >
> > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > >
> > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > or VPL options for a specific thing reside.
> > > > > >
> > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > >
> > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > >
> > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > >
> > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > >
> > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > question is, how do you handle (d)?
> > > > > > > >
> > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > >
> > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > >
> > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > we really could have fewer overall build configurations.
> > > > > > >
> > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > having a generic Rockchip one, for example.
> > > > > > >
> > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > these two different schemes.
> > > > > >
> > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > SPL/PPL for A53.
> > > > > >
> > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > still matters.
> > > > >
> > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > possibility.
> > > > >
> > > > > A few points from my side:
> > > > >
> > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > length. I added a feature to qconfig to allow finding common options
> > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > >
> > > > I don't see reducing defconfig size as important honestly. Should we
> > > > have more and better defaults? Yes. But almost everything is under 200
> > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > platform(s?).
> > >
> > > Agreed.
> > >
> > > >
> > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > lot of traction.
> > > >
> > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > it's both feasible enough and useful enough for production. At the PPL
> > > > stage it still has to be small enough and not overly burdensome. What we
> > > > talked about on the call yesterday about using more multi-dtb images is
> > > > a step in the right direction, yes.
> > >
> > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > >
> > > >
> > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > rely on the current PPL configuration. But how will that work? There
> > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > just to get something working, isn't it? With my scheme there is no
> > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > desirable.
> > > >
> > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > config ROCKCHIP_RK3399
> > > >         bool "Support Rockchip RK3399"
> > > >         select ARM64
> > > >         select SUPPORT_SPL
> > > >         select SUPPORT_TPL
> > > >         select SPL
> > > >         select SPL_ATF
> > > >         select SPL_BOARD_INIT if SPL
> > > >         ...
> > > >         select SPL_CLK if SPL
> > > >         ...
> > > >         select CLK
> > > >         ...
> > > >         imply TPL_CLK
> > > >
> > > >
> > > > This would become:
> > > > config ROCKCHIP_RK3399
> > > >         bool "Support Rockchip RK3399"
> > > >         select ARM64
> > > >         select SUPPORT_SPL
> > > >         select SUPPORT_TPL
> > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > >         select CLK # imply was likely wrong before? Would need to check
> > > >         ...
> > >
> > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > common/spl/Kconfig and common/spl/Kconfig.tpl
> >
> > I would vastly reduce the contents within those 'if' blocks, but there
> > are still options that are xPL-centric without a PPL counterpart, such
> > as SPL_ATF (I suspect, but if not I'm sure others).
> >
> > > But just the level of thought required in your small example above
> > > suggests it is a large effort.
> >
> > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > some work. So was, I suspect, all of what you did already.
> >
> > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > >
> > > > I don't see yours as splitting the configs in to separate files, I see
> > > > it as generating some intermediate objects. The configs don't change and
> > > > that's one of our problem areas.
> > >
> > > So you mean a big problem area is the current Kconfig?
> >
> > I mean it's a problem for users a board developers to make valid
> > configurations and update them as needed. Filesystems are in the
> > filesystem menu, unless they're SPL and then it's all under the big SPL
> > menu.
> >
> > > Mind generates
> > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > intermediate files and auto-generated, but each 100% controls its
> > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > rules anymore.
> >
> > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > good. But the intermediate files aren't going to help (nor hurt) any of
> > the problems themselves. If you're reading those to figure out a
> > problem, it's like when you're reading a .i file to figure out a
> > problem, it means you're already in a complex troublesome spot.
> >
> > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > CONFIG_FS_FAT=y does.
> >
> > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > my scheme to get us to a split config, then, after that, decide
> > > > > whether to move that split earlier to Kconfig itself. The choices
> > > >
> > > > I don't think so. Yours makes things complicated by making the build do
> > > > even more (and from the RFC, the implementation tooling diverges from
> > > > upstream).
> > >
> > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > >
> > > > Mine makes things differently complicated by doing less for
> > > > most things, but needing some thought on how to know that say
> > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > built, before asking binman to go put things together.
> > >
> > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > we (or I) have completing a migration, I honestly don't believe this
> > > is feasible in today's U-Boot. The other problem is that it all has to
> >
> > I'm not 100% sure it's everything needs binman actually. Or even if we
> > do take this as a reason to push for more binman, it's just some trivial
> > types already handled in the Makefile that's missing.
> >
> > > be done at once. We need to rewrite the Kconfig and flip over the
> > > board. Will we carry people with us? That is a huge risk to the
> > > project IMO.
> >
> > I'm not sure, actually, that it couldn't be done in stages. We might
> > need a little bit of fakery around being able to just build SPL without
> > PPL in the interim.
> >
> > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > kconf additions and a patch that can likely be upstreamed). But
> > > otherwise, it is a one-off improvement, without any changes to the
> > > existing Kconfig.
> >
> > I thought Yamada-san rejected changes going in this direction before?
> > But either way, no it's not likely the final overburden in terms of
> > divergence.
> 
> 
> Yes. Masahiro will make his own decisions and I am confident he will
> reject any future changes I send
> 
> >
> > > So my point is that we could go with the first part of my scheme to
> > > resolve the 'medium' problems then decide which way to continue after
> > > that. From your side you won't have lost anything towards where you
> > > want to head. The two options would then be:
> > >
> > > - exhance kconfig language to build in the notion of phases
> > > - split the defconfigs for each board, redo the Kconfig rules and
> > > teach the build to combine images
> >
> > If things go down your proposed path instead, no, I don't see that as
> > making it meaningfully easier to go the way I proposed later. The only
> > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > IS_ENABLED. And (almost) all of that is a script'able change.
> 
> To be frank, the difference is that I have actually put in the work to
> try this. It is more than 50 and perhaps as many as 100 patches. Quite
> difficult work. Honestly, compared to that, the logic changes are not
> that large.
> 
> That is why I believe this work is a prerequisite for both schemes
> 
> >
> > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > rework over time). Both schemes would need a small amount of
> > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > >
> > > > > Does that sound right?
> > > >
> > > > With what I said above, yes I think we're closer at least to
> > > > understanding each other.
> > >
> > > Yes.
> >
> > Well, with that, what now?
> >
> > What makes the current situation untenable is VPL. And I gather I
> > haven't convinced you to put that on hold long enough to instead rework
> > how we build things, have I?
> 
> Which VPL thing?

That it exists. When it was just SPL, it's manageable. With TPL, well,
it was supposed to be tiny and so just a few more things. And with VPL,
that makes 4. It's too much. Something needs to be done. Four times is
too many. If solving Marek's desire for PSCI-from-U-Boot means we need
number 5 that becomes even worse (and I also suspect that's a case of
one build covers the SoC or family of SoCs depending on hardware
changes).

> You have convinced me that you have a solution. It makes a lot more
> sense to me than previously and it may be that it is better in the
> end. For example, with VBE it I would make a lot of sense to build 20
> boards as just TPL and use a generic rock chip board for everything
> else. That would be a lot tidier with your scheme. It is very hard to
> predict the future and VBE is still not finished, some two years in.
> 
> I don't want to be tied to your scheme today though.
> 
> So if you can accept my going ahead with 1-4 and helping me with that,
> then we can stop and discuss which way to go, perhaps by prototyping
> the two options?

I want to start by saying I do appreciate you put in a lot of work in
this direction already, and I do see some of the end goals it achieves
as being important, and I'm glad you see my idea has some good parts
too.

I want to figure out how to move forward on this problem. My other part
of this thread, this morning, was also part of me looking harder, again,
at the RFC series you posted before. And that's where I still have large
reservations. There are *so* *many* symbols we need to now have 4
variants of, instead of 1 variant of. Take:
https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
files built in TPL (and likely VPL) so aren't we going to need that
every time? And with a quick size-check on pinebook-pro-rk3399 it looks
like it's not working as intended either? I checked and part_get_info
shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
#ifdef CONFIG_PARTITION_TYPE_GUID
                info->type_guid[0] = 0;
#endif
is not true and checked. And I can't see why. And there's other size
reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
in to more, but wasn't that symbol:
               tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
                 function                                   old     new   delta
                 dev_get_uclass_plat                         12       -     -12
                 simple_bus_post_bind                        92       -     -92
                 _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
                 _u_boot_list_2_driver_2_simple_bus         120       -    -120

And I'm not bringing this up to badger you about bugs in an RFC series
(it's RFC, there's bugs) but rather because I think it highlights some
core issues with the approach as implemented.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > >
> > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > >
> > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > >
> > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > >
> > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > >
> > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > >
> > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > >
> > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > important as the other ones.
> > > > > > > > > >
> > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > >
> > > > > > > > > > Here's another:
> > > > > > > > > >
> > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > >
> > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > >
> > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > >
> > > > > > > > > Alternatively:
> > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > >    ... current default X if Y
> > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > >
> > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > >
> > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > >
> > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > build? I'm just a bit confused by this.
> > > > > > >
> > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > >
> > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > SPL one, with your scheme?
> > > > > > >
> > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > new default previously switch to the old one.
> > > > > > >
> > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > today, outside of either proposal.
> > > > > > >
> > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > not important?
> > > > > > >
> > > > > > > Basically. The majority of the cases of:
> > > > > > > config SPL_FOO
> > > > > > >    default y if FOO
> > > > > > >
> > > > > > > config TPL_FOO
> > > > > > >    default y if SPL_FOO
> > > > > > >
> > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > >
> > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > >
> > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > since for example we could drop:
> > > > > > > config SPL_FS_EXT4
> > > > > > >         bool "Support EXT filesystems"
> > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > >
> > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > >
> > > > > > > > > > > > Proposal
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > >
> > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > >
> > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > >
> > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > options across all phases.
> > > > > > > > > > > >
> > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > above.
> > > > > > > > > > > >
> > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > >
> > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > >
> > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > >
> > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > have below.
> > > > > > > > >
> > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > direction.
> > > > > > > >
> > > > > > > > Yes, IMO he was right about that.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > My request instead is:
> > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > >
> > > > > > > > > > Good idea.
> > > > > > > > > >
> > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > >   as needed.
> > > > > > > > > >
> > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > >
> > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > is automated.
> > > > > > > >
> > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > >
> > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > or VPL options for a specific thing reside.
> > > > > > >
> > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > >
> > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > >
> > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > >
> > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > >
> > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > >
> > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > >
> > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > >
> > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > >
> > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > having a generic Rockchip one, for example.
> > > > > > > >
> > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > these two different schemes.
> > > > > > >
> > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > SPL/PPL for A53.
> > > > > > >
> > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > still matters.
> > > > > >
> > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > possibility.
> > > > > >
> > > > > > A few points from my side:
> > > > > >
> > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > >
> > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > platform(s?).
> > > >
> > > > Agreed.
> > > >
> > > > >
> > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > lot of traction.
> > > > >
> > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > a step in the right direction, yes.
> > > >
> > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > >
> > > > >
> > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > desirable.
> > > > >
> > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > config ROCKCHIP_RK3399
> > > > >         bool "Support Rockchip RK3399"
> > > > >         select ARM64
> > > > >         select SUPPORT_SPL
> > > > >         select SUPPORT_TPL
> > > > >         select SPL
> > > > >         select SPL_ATF
> > > > >         select SPL_BOARD_INIT if SPL
> > > > >         ...
> > > > >         select SPL_CLK if SPL
> > > > >         ...
> > > > >         select CLK
> > > > >         ...
> > > > >         imply TPL_CLK
> > > > >
> > > > >
> > > > > This would become:
> > > > > config ROCKCHIP_RK3399
> > > > >         bool "Support Rockchip RK3399"
> > > > >         select ARM64
> > > > >         select SUPPORT_SPL
> > > > >         select SUPPORT_TPL
> > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > >         ...
> > > >
> > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > >
> > > I would vastly reduce the contents within those 'if' blocks, but there
> > > are still options that are xPL-centric without a PPL counterpart, such
> > > as SPL_ATF (I suspect, but if not I'm sure others).
> > >
> > > > But just the level of thought required in your small example above
> > > > suggests it is a large effort.
> > >
> > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > some work. So was, I suspect, all of what you did already.
> > >
> > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > >
> > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > it as generating some intermediate objects. The configs don't change and
> > > > > that's one of our problem areas.
> > > >
> > > > So you mean a big problem area is the current Kconfig?
> > >
> > > I mean it's a problem for users a board developers to make valid
> > > configurations and update them as needed. Filesystems are in the
> > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > menu.
> > >
> > > > Mind generates
> > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > intermediate files and auto-generated, but each 100% controls its
> > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > rules anymore.
> > >
> > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > the problems themselves. If you're reading those to figure out a
> > > problem, it's like when you're reading a .i file to figure out a
> > > problem, it means you're already in a complex troublesome spot.
> > >
> > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > CONFIG_FS_FAT=y does.
> > >
> > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > >
> > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > upstream).
> > > >
> > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > >
> > > > > Mine makes things differently complicated by doing less for
> > > > > most things, but needing some thought on how to know that say
> > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > built, before asking binman to go put things together.
> > > >
> > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > we (or I) have completing a migration, I honestly don't believe this
> > > > is feasible in today's U-Boot. The other problem is that it all has to
> > >
> > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > do take this as a reason to push for more binman, it's just some trivial
> > > types already handled in the Makefile that's missing.
> > >
> > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > board. Will we carry people with us? That is a huge risk to the
> > > > project IMO.
> > >
> > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > need a little bit of fakery around being able to just build SPL without
> > > PPL in the interim.
> > >
> > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > kconf additions and a patch that can likely be upstreamed). But
> > > > otherwise, it is a one-off improvement, without any changes to the
> > > > existing Kconfig.
> > >
> > > I thought Yamada-san rejected changes going in this direction before?
> > > But either way, no it's not likely the final overburden in terms of
> > > divergence.
> >
> >
> > Yes. Masahiro will make his own decisions and I am confident he will
> > reject any future changes I send
> >
> > >
> > > > So my point is that we could go with the first part of my scheme to
> > > > resolve the 'medium' problems then decide which way to continue after
> > > > that. From your side you won't have lost anything towards where you
> > > > want to head. The two options would then be:
> > > >
> > > > - exhance kconfig language to build in the notion of phases
> > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > teach the build to combine images
> > >
> > > If things go down your proposed path instead, no, I don't see that as
> > > making it meaningfully easier to go the way I proposed later. The only
> > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > IS_ENABLED. And (almost) all of that is a script'able change.
> >
> > To be frank, the difference is that I have actually put in the work to
> > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > difficult work. Honestly, compared to that, the logic changes are not
> > that large.
> >
> > That is why I believe this work is a prerequisite for both schemes
> >
> > >
> > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > rework over time). Both schemes would need a small amount of
> > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > >
> > > > > > Does that sound right?
> > > > >
> > > > > With what I said above, yes I think we're closer at least to
> > > > > understanding each other.
> > > >
> > > > Yes.
> > >
> > > Well, with that, what now?
> > >
> > > What makes the current situation untenable is VPL. And I gather I
> > > haven't convinced you to put that on hold long enough to instead rework
> > > how we build things, have I?
> >
> > Which VPL thing?
>
> That it exists. When it was just SPL, it's manageable. With TPL, well,
> it was supposed to be tiny and so just a few more things. And with VPL,
> that makes 4. It's too much. Something needs to be done. Four times is
> too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> number 5 that becomes even worse (and I also suspect that's a case of
> one build covers the SoC or family of SoCs depending on hardware
> changes).

Yes, that's why I took on this effort a few years back.

>
> > You have convinced me that you have a solution. It makes a lot more
> > sense to me than previously and it may be that it is better in the
> > end. For example, with VBE it I would make a lot of sense to build 20
> > boards as just TPL and use a generic rock chip board for everything
> > else. That would be a lot tidier with your scheme. It is very hard to
> > predict the future and VBE is still not finished, some two years in.
> >
> > I don't want to be tied to your scheme today though.
> >
> > So if you can accept my going ahead with 1-4 and helping me with that,
> > then we can stop and discuss which way to go, perhaps by prototyping
> > the two options?
>
> I want to start by saying I do appreciate you put in a lot of work in
> this direction already, and I do see some of the end goals it achieves
> as being important, and I'm glad you see my idea has some good parts
> too.
>
> I want to figure out how to move forward on this problem. My other part
> of this thread, this morning, was also part of me looking harder, again,
> at the RFC series you posted before. And that's where I still have large
> reservations. There are *so* *many* symbols we need to now have 4
> variants of, instead of 1 variant of. Take:
> https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> files built in TPL (and likely VPL) so aren't we going to need that
> every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> like it's not working as intended either? I checked and part_get_info
> shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> #ifdef CONFIG_PARTITION_TYPE_GUID
>                 info->type_guid[0] = 0;
> #endif
> is not true and checked. And I can't see why. And there's other size
> reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> in to more, but wasn't that symbol:
>                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
>                  function                                   old     new   delta
>                  dev_get_uclass_plat                         12       -     -12
>                  simple_bus_post_bind                        92       -     -92
>                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
>                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
>
> And I'm not bringing this up to badger you about bugs in an RFC series
> (it's RFC, there's bugs) but rather because I think it highlights some
> core issues with the approach as implemented.

But surely you can see that both schemes have exactly the same issues?
My point is that the work to tidy up things and then get to a 'clean'
source tree and Makefiles is the hard bit here and has to be done with
both schemes.

Just let me know which way you want to go. I don't have anything ready
to send, but I could probably drag it over the line before too long,
if you are keen.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 33148 bytes --]

On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > >
> > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > >
> > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > >
> > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > >
> > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > >
> > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > important as the other ones.
> > > > > > > > > > >
> > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > >
> > > > > > > > > > > Here's another:
> > > > > > > > > > >
> > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > >
> > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > >
> > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > >
> > > > > > > > > > Alternatively:
> > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > >    ... current default X if Y
> > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > >
> > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > >
> > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > >
> > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > >
> > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > >
> > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > SPL one, with your scheme?
> > > > > > > >
> > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > new default previously switch to the old one.
> > > > > > > >
> > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > today, outside of either proposal.
> > > > > > > >
> > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > not important?
> > > > > > > >
> > > > > > > > Basically. The majority of the cases of:
> > > > > > > > config SPL_FOO
> > > > > > > >    default y if FOO
> > > > > > > >
> > > > > > > > config TPL_FOO
> > > > > > > >    default y if SPL_FOO
> > > > > > > >
> > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > >
> > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > >
> > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > since for example we could drop:
> > > > > > > > config SPL_FS_EXT4
> > > > > > > >         bool "Support EXT filesystems"
> > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > >
> > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > >
> > > > > > > > > > > > > Proposal
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > above.
> > > > > > > > > > > > >
> > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > >
> > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > >
> > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > >
> > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > have below.
> > > > > > > > > >
> > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > direction.
> > > > > > > > >
> > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > >
> > > > > > > > > > > Good idea.
> > > > > > > > > > >
> > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > >   as needed.
> > > > > > > > > > >
> > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > >
> > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > is automated.
> > > > > > > > >
> > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > >
> > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > or VPL options for a specific thing reside.
> > > > > > > >
> > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > >
> > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > >
> > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > >
> > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > >
> > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > >
> > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > >
> > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > >
> > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > >
> > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > >
> > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > these two different schemes.
> > > > > > > >
> > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > SPL/PPL for A53.
> > > > > > > >
> > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > still matters.
> > > > > > >
> > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > possibility.
> > > > > > >
> > > > > > > A few points from my side:
> > > > > > >
> > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > >
> > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > platform(s?).
> > > > >
> > > > > Agreed.
> > > > >
> > > > > >
> > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > lot of traction.
> > > > > >
> > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > a step in the right direction, yes.
> > > > >
> > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > >
> > > > > >
> > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > desirable.
> > > > > >
> > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > config ROCKCHIP_RK3399
> > > > > >         bool "Support Rockchip RK3399"
> > > > > >         select ARM64
> > > > > >         select SUPPORT_SPL
> > > > > >         select SUPPORT_TPL
> > > > > >         select SPL
> > > > > >         select SPL_ATF
> > > > > >         select SPL_BOARD_INIT if SPL
> > > > > >         ...
> > > > > >         select SPL_CLK if SPL
> > > > > >         ...
> > > > > >         select CLK
> > > > > >         ...
> > > > > >         imply TPL_CLK
> > > > > >
> > > > > >
> > > > > > This would become:
> > > > > > config ROCKCHIP_RK3399
> > > > > >         bool "Support Rockchip RK3399"
> > > > > >         select ARM64
> > > > > >         select SUPPORT_SPL
> > > > > >         select SUPPORT_TPL
> > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > >         ...
> > > > >
> > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > >
> > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > >
> > > > > But just the level of thought required in your small example above
> > > > > suggests it is a large effort.
> > > >
> > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > some work. So was, I suspect, all of what you did already.
> > > >
> > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > >
> > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > that's one of our problem areas.
> > > > >
> > > > > So you mean a big problem area is the current Kconfig?
> > > >
> > > > I mean it's a problem for users a board developers to make valid
> > > > configurations and update them as needed. Filesystems are in the
> > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > menu.
> > > >
> > > > > Mind generates
> > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > rules anymore.
> > > >
> > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > the problems themselves. If you're reading those to figure out a
> > > > problem, it's like when you're reading a .i file to figure out a
> > > > problem, it means you're already in a complex troublesome spot.
> > > >
> > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > CONFIG_FS_FAT=y does.
> > > >
> > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > >
> > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > upstream).
> > > > >
> > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > >
> > > > > > Mine makes things differently complicated by doing less for
> > > > > > most things, but needing some thought on how to know that say
> > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > built, before asking binman to go put things together.
> > > > >
> > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > >
> > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > do take this as a reason to push for more binman, it's just some trivial
> > > > types already handled in the Makefile that's missing.
> > > >
> > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > project IMO.
> > > >
> > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > need a little bit of fakery around being able to just build SPL without
> > > > PPL in the interim.
> > > >
> > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > existing Kconfig.
> > > >
> > > > I thought Yamada-san rejected changes going in this direction before?
> > > > But either way, no it's not likely the final overburden in terms of
> > > > divergence.
> > >
> > >
> > > Yes. Masahiro will make his own decisions and I am confident he will
> > > reject any future changes I send
> > >
> > > >
> > > > > So my point is that we could go with the first part of my scheme to
> > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > that. From your side you won't have lost anything towards where you
> > > > > want to head. The two options would then be:
> > > > >
> > > > > - exhance kconfig language to build in the notion of phases
> > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > teach the build to combine images
> > > >
> > > > If things go down your proposed path instead, no, I don't see that as
> > > > making it meaningfully easier to go the way I proposed later. The only
> > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > >
> > > To be frank, the difference is that I have actually put in the work to
> > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > difficult work. Honestly, compared to that, the logic changes are not
> > > that large.
> > >
> > > That is why I believe this work is a prerequisite for both schemes
> > >
> > > >
> > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > >
> > > > > > > Does that sound right?
> > > > > >
> > > > > > With what I said above, yes I think we're closer at least to
> > > > > > understanding each other.
> > > > >
> > > > > Yes.
> > > >
> > > > Well, with that, what now?
> > > >
> > > > What makes the current situation untenable is VPL. And I gather I
> > > > haven't convinced you to put that on hold long enough to instead rework
> > > > how we build things, have I?
> > >
> > > Which VPL thing?
> >
> > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > it was supposed to be tiny and so just a few more things. And with VPL,
> > that makes 4. It's too much. Something needs to be done. Four times is
> > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > number 5 that becomes even worse (and I also suspect that's a case of
> > one build covers the SoC or family of SoCs depending on hardware
> > changes).
> 
> Yes, that's why I took on this effort a few years back.
> 
> >
> > > You have convinced me that you have a solution. It makes a lot more
> > > sense to me than previously and it may be that it is better in the
> > > end. For example, with VBE it I would make a lot of sense to build 20
> > > boards as just TPL and use a generic rock chip board for everything
> > > else. That would be a lot tidier with your scheme. It is very hard to
> > > predict the future and VBE is still not finished, some two years in.
> > >
> > > I don't want to be tied to your scheme today though.
> > >
> > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > then we can stop and discuss which way to go, perhaps by prototyping
> > > the two options?
> >
> > I want to start by saying I do appreciate you put in a lot of work in
> > this direction already, and I do see some of the end goals it achieves
> > as being important, and I'm glad you see my idea has some good parts
> > too.
> >
> > I want to figure out how to move forward on this problem. My other part
> > of this thread, this morning, was also part of me looking harder, again,
> > at the RFC series you posted before. And that's where I still have large
> > reservations. There are *so* *many* symbols we need to now have 4
> > variants of, instead of 1 variant of. Take:
> > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > files built in TPL (and likely VPL) so aren't we going to need that
> > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > like it's not working as intended either? I checked and part_get_info
> > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > #ifdef CONFIG_PARTITION_TYPE_GUID
> >                 info->type_guid[0] = 0;
> > #endif

Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
thing I see what happened. And now I see my problem from yesterday
morning was similar but different.

> > is not true and checked. And I can't see why. And there's other size
> > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > in to more, but wasn't that symbol:
> >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> >                  function                                   old     new   delta
> >                  dev_get_uclass_plat                         12       -     -12
> >                  simple_bus_post_bind                        92       -     -92
> >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> >
> > And I'm not bringing this up to badger you about bugs in an RFC series
> > (it's RFC, there's bugs) but rather because I think it highlights some
> > core issues with the approach as implemented.
> 
> But surely you can see that both schemes have exactly the same issues?
>
> My point is that the work to tidy up things and then get to a 'clean'
> source tree and Makefiles is the hard bit here and has to be done with
> both schemes.
>
> Just let me know which way you want to go. I don't have anything ready
> to send, but I could probably drag it over the line before too long,
> if you are keen.

Once I figured out what was the cause of the problems I saw in the RFC,
I had to rewrite this a few times. Your approach needs even more symbols
added than were in the RFC, and the newly added symbols need further
auditing to make sure we have the same behavior as today at least by
default. On the one hand, this is at least a well defined technical
problem and if you do the language extension *first* the code changes
aren't so bad. But for the user running menuconfig / etc? That's not
going to be pretty. And we still won't have fixed the problems like "why
is TPL even trying to build DWC3?" without reworking more symbols.

So I don't think this is the right approach as it doesn't reduce
confusion and may increase it (why do I need to set
CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
CONFIG_PARTITION_TYPE_GUID? But why is CONFIG_SPL_FRAMEWORK still there?
Oh..). The main thing it does is drop $(PHASE_) and I honestly think
that's more confusing. We still have one build where we need to do or
not do different things for FOO && PPL, FOO && SPL, etc but the code
just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
.config / defconfig.

I really think we need to literally split the config files up such that
for the most part we do (in psuedo code):
%_full_config:
  make -C $(srctree) O=$(obj)/ppl %_ppl_defconfig
  make -C $(srctree) O=$(obj)/spl %_spl_defconfig
  ...

all:
  [ -d $(obj)/ppl ] && make -C $(srctree) O=$(obj)/ppl all
  [ -d $(obj)/spl ] && make -C $(srctree) O=$(obj)/spl all
  ...

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > >
> > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > >
> > > > > > > > > > > > Here's another:
> > > > > > > > > > > >
> > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > >
> > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > >
> > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > >
> > > > > > > > > > > Alternatively:
> > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > >
> > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > >
> > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > >
> > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > >
> > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > >
> > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > SPL one, with your scheme?
> > > > > > > > >
> > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > new default previously switch to the old one.
> > > > > > > > >
> > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > today, outside of either proposal.
> > > > > > > > >
> > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > not important?
> > > > > > > > >
> > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > config SPL_FOO
> > > > > > > > >    default y if FOO
> > > > > > > > >
> > > > > > > > > config TPL_FOO
> > > > > > > > >    default y if SPL_FOO
> > > > > > > > >
> > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > >
> > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > >
> > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > since for example we could drop:
> > > > > > > > > config SPL_FS_EXT4
> > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > >
> > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > >
> > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > above.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > >
> > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > have below.
> > > > > > > > > > >
> > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > direction.
> > > > > > > > > >
> > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > >
> > > > > > > > > > > > Good idea.
> > > > > > > > > > > >
> > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > >   as needed.
> > > > > > > > > > > >
> > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > >
> > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > is automated.
> > > > > > > > > >
> > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > >
> > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > >
> > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > >
> > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > >
> > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > >
> > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > > >
> > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > >
> > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > >
> > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > >
> > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > >
> > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > >
> > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > these two different schemes.
> > > > > > > > >
> > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > SPL/PPL for A53.
> > > > > > > > >
> > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > still matters.
> > > > > > > >
> > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > possibility.
> > > > > > > >
> > > > > > > > A few points from my side:
> > > > > > > >
> > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > >
> > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > platform(s?).
> > > > > >
> > > > > > Agreed.
> > > > > >
> > > > > > >
> > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > lot of traction.
> > > > > > >
> > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > a step in the right direction, yes.
> > > > > >
> > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > >
> > > > > > >
> > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > desirable.
> > > > > > >
> > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > config ROCKCHIP_RK3399
> > > > > > >         bool "Support Rockchip RK3399"
> > > > > > >         select ARM64
> > > > > > >         select SUPPORT_SPL
> > > > > > >         select SUPPORT_TPL
> > > > > > >         select SPL
> > > > > > >         select SPL_ATF
> > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > >         ...
> > > > > > >         select SPL_CLK if SPL
> > > > > > >         ...
> > > > > > >         select CLK
> > > > > > >         ...
> > > > > > >         imply TPL_CLK
> > > > > > >
> > > > > > >
> > > > > > > This would become:
> > > > > > > config ROCKCHIP_RK3399
> > > > > > >         bool "Support Rockchip RK3399"
> > > > > > >         select ARM64
> > > > > > >         select SUPPORT_SPL
> > > > > > >         select SUPPORT_TPL
> > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > >         ...
> > > > > >
> > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > >
> > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > >
> > > > > > But just the level of thought required in your small example above
> > > > > > suggests it is a large effort.
> > > > >
> > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > some work. So was, I suspect, all of what you did already.
> > > > >
> > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > >
> > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > that's one of our problem areas.
> > > > > >
> > > > > > So you mean a big problem area is the current Kconfig?
> > > > >
> > > > > I mean it's a problem for users a board developers to make valid
> > > > > configurations and update them as needed. Filesystems are in the
> > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > menu.
> > > > >
> > > > > > Mind generates
> > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > rules anymore.
> > > > >
> > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > the problems themselves. If you're reading those to figure out a
> > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > problem, it means you're already in a complex troublesome spot.
> > > > >
> > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > CONFIG_FS_FAT=y does.
> > > > >
> > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > >
> > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > upstream).
> > > > > >
> > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > >
> > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > most things, but needing some thought on how to know that say
> > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > built, before asking binman to go put things together.
> > > > > >
> > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > >
> > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > types already handled in the Makefile that's missing.
> > > > >
> > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > project IMO.
> > > > >
> > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > need a little bit of fakery around being able to just build SPL without
> > > > > PPL in the interim.
> > > > >
> > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > existing Kconfig.
> > > > >
> > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > But either way, no it's not likely the final overburden in terms of
> > > > > divergence.
> > > >
> > > >
> > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > reject any future changes I send
> > > >
> > > > >
> > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > that. From your side you won't have lost anything towards where you
> > > > > > want to head. The two options would then be:
> > > > > >
> > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > teach the build to combine images
> > > > >
> > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > >
> > > > To be frank, the difference is that I have actually put in the work to
> > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > that large.
> > > >
> > > > That is why I believe this work is a prerequisite for both schemes
> > > >
> > > > >
> > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > >
> > > > > > > > Does that sound right?
> > > > > > >
> > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > understanding each other.
> > > > > >
> > > > > > Yes.
> > > > >
> > > > > Well, with that, what now?
> > > > >
> > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > how we build things, have I?
> > > >
> > > > Which VPL thing?
> > >
> > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > that makes 4. It's too much. Something needs to be done. Four times is
> > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > number 5 that becomes even worse (and I also suspect that's a case of
> > > one build covers the SoC or family of SoCs depending on hardware
> > > changes).
> >
> > Yes, that's why I took on this effort a few years back.
> >
> > >
> > > > You have convinced me that you have a solution. It makes a lot more
> > > > sense to me than previously and it may be that it is better in the
> > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > boards as just TPL and use a generic rock chip board for everything
> > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > predict the future and VBE is still not finished, some two years in.
> > > >
> > > > I don't want to be tied to your scheme today though.
> > > >
> > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > the two options?
> > >
> > > I want to start by saying I do appreciate you put in a lot of work in
> > > this direction already, and I do see some of the end goals it achieves
> > > as being important, and I'm glad you see my idea has some good parts
> > > too.
> > >
> > > I want to figure out how to move forward on this problem. My other part
> > > of this thread, this morning, was also part of me looking harder, again,
> > > at the RFC series you posted before. And that's where I still have large
> > > reservations. There are *so* *many* symbols we need to now have 4
> > > variants of, instead of 1 variant of. Take:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > files built in TPL (and likely VPL) so aren't we going to need that
> > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > like it's not working as intended either? I checked and part_get_info
> > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > >                 info->type_guid[0] = 0;
> > > #endif
>
> Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> thing I see what happened. And now I see my problem from yesterday
> morning was similar but different.
>
> > > is not true and checked. And I can't see why. And there's other size
> > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > in to more, but wasn't that symbol:
> > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > >                  function                                   old     new   delta
> > >                  dev_get_uclass_plat                         12       -     -12
> > >                  simple_bus_post_bind                        92       -     -92
> > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > >
> > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > core issues with the approach as implemented.
> >
> > But surely you can see that both schemes have exactly the same issues?
> >
> > My point is that the work to tidy up things and then get to a 'clean'
> > source tree and Makefiles is the hard bit here and has to be done with
> > both schemes.
> >
> > Just let me know which way you want to go. I don't have anything ready
> > to send, but I could probably drag it over the line before too long,
> > if you are keen.
>
> Once I figured out what was the cause of the problems I saw in the RFC,
> I had to rewrite this a few times. Your approach needs even more symbols
> added than were in the RFC, and the newly added symbols need further
> auditing to make sure we have the same behavior as today at least by
> default.

This is the idea that we need to clean up a, b and c. Your scheme is
the same in this respect. If we have CONFIG_FOO today, then your
scheme may need that duplicated to each defconfig file. Either you
resolve the ambiguity or don't. But if you do, then you have to add
symbols, with both schemes.

> On the one hand, this is at least a well defined technical
> problem and if you do the language extension *first* the code changes
> aren't so bad.

There are no significant Kconfig changes in my scheme, other than the
conf_nospl file. The language extension is quite separate.

> But for the user running menuconfig / etc? That's not
> going to be pretty. And we still won't have fixed the problems like "why
> is TPL even trying to build DWC3?" without reworking more symbols.
>
> So I don't think this is the right approach as it doesn't reduce
> confusion and may increase it (why do I need to set
> CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> CONFIG_PARTITION_TYPE_GUID?

Because it is an SPL build...I actually think that makes a lot of
sense. You just need to understand that CONFIG_SPL_ means the SPL
build, which in fact is what we have been using for years.

> But why is CONFIG_SPL_FRAMEWORK still there?

Not relevant to the discussion, IMO.

> Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> that's more confusing. We still have one build where we need to do or
> not do different things for FOO && PPL, FOO && SPL, etc but the code
> just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> .config / defconfig.

Yes, that's the conf_nospl file which I have dealt with.

>
> I really think we need to literally split the config files up such that
> for the most part we do (in psuedo code):
> %_full_config:
>   make -C $(srctree) O=$(obj)/ppl %_ppl_defconfig
>   make -C $(srctree) O=$(obj)/spl %_spl_defconfig
>   ...
>
> all:
>   [ -d $(obj)/ppl ] && make -C $(srctree) O=$(obj)/ppl all
>   [ -d $(obj)/spl ] && make -C $(srctree) O=$(obj)/spl all
>   ...
>

Perhaps you should take a look at this and come up with an RFC series
for your scheme? I think that would help us gain a better shared
understanding of the problem.

Failing that, I am willing and able to do another version of my
scheme, if it suits.

Regards,
Simon

> --
> Tom

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 38576 bytes --]

On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > >
> > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > >
> > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > >
> > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > >
> > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > >
> > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > >
> > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > >
> > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > >
> > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > >
> > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > >
> > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > >
> > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > today, outside of either proposal.
> > > > > > > > > >
> > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > not important?
> > > > > > > > > >
> > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > config SPL_FOO
> > > > > > > > > >    default y if FOO
> > > > > > > > > >
> > > > > > > > > > config TPL_FOO
> > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > >
> > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > >
> > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > >
> > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > since for example we could drop:
> > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > >
> > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > >
> > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > have below.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > direction.
> > > > > > > > > > >
> > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > >
> > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > is automated.
> > > > > > > > > > >
> > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > >
> > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > >
> > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > >
> > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > >
> > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > >
> > > > > > > > > > Thanks.
> > > > > > > > > >
> > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > >
> > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > >
> > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > >
> > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > >
> > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > >
> > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > these two different schemes.
> > > > > > > > > >
> > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > >
> > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > still matters.
> > > > > > > > >
> > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > possibility.
> > > > > > > > >
> > > > > > > > > A few points from my side:
> > > > > > > > >
> > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > >
> > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > platform(s?).
> > > > > > >
> > > > > > > Agreed.
> > > > > > >
> > > > > > > >
> > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > lot of traction.
> > > > > > > >
> > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > a step in the right direction, yes.
> > > > > > >
> > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > >
> > > > > > > >
> > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > desirable.
> > > > > > > >
> > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > config ROCKCHIP_RK3399
> > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > >         select ARM64
> > > > > > > >         select SUPPORT_SPL
> > > > > > > >         select SUPPORT_TPL
> > > > > > > >         select SPL
> > > > > > > >         select SPL_ATF
> > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > >         ...
> > > > > > > >         select SPL_CLK if SPL
> > > > > > > >         ...
> > > > > > > >         select CLK
> > > > > > > >         ...
> > > > > > > >         imply TPL_CLK
> > > > > > > >
> > > > > > > >
> > > > > > > > This would become:
> > > > > > > > config ROCKCHIP_RK3399
> > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > >         select ARM64
> > > > > > > >         select SUPPORT_SPL
> > > > > > > >         select SUPPORT_TPL
> > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > >         ...
> > > > > > >
> > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > >
> > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > >
> > > > > > > But just the level of thought required in your small example above
> > > > > > > suggests it is a large effort.
> > > > > >
> > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > some work. So was, I suspect, all of what you did already.
> > > > > >
> > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > >
> > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > that's one of our problem areas.
> > > > > > >
> > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > >
> > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > menu.
> > > > > >
> > > > > > > Mind generates
> > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > rules anymore.
> > > > > >
> > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > >
> > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > CONFIG_FS_FAT=y does.
> > > > > >
> > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > >
> > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > upstream).
> > > > > > >
> > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > >
> > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > built, before asking binman to go put things together.
> > > > > > >
> > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > >
> > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > types already handled in the Makefile that's missing.
> > > > > >
> > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > project IMO.
> > > > > >
> > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > PPL in the interim.
> > > > > >
> > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > existing Kconfig.
> > > > > >
> > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > divergence.
> > > > >
> > > > >
> > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > reject any future changes I send
> > > > >
> > > > > >
> > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > want to head. The two options would then be:
> > > > > > >
> > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > teach the build to combine images
> > > > > >
> > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > >
> > > > > To be frank, the difference is that I have actually put in the work to
> > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > that large.
> > > > >
> > > > > That is why I believe this work is a prerequisite for both schemes
> > > > >
> > > > > >
> > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > >
> > > > > > > > > Does that sound right?
> > > > > > > >
> > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > understanding each other.
> > > > > > >
> > > > > > > Yes.
> > > > > >
> > > > > > Well, with that, what now?
> > > > > >
> > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > how we build things, have I?
> > > > >
> > > > > Which VPL thing?
> > > >
> > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > one build covers the SoC or family of SoCs depending on hardware
> > > > changes).
> > >
> > > Yes, that's why I took on this effort a few years back.
> > >
> > > >
> > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > sense to me than previously and it may be that it is better in the
> > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > predict the future and VBE is still not finished, some two years in.
> > > > >
> > > > > I don't want to be tied to your scheme today though.
> > > > >
> > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > the two options?
> > > >
> > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > this direction already, and I do see some of the end goals it achieves
> > > > as being important, and I'm glad you see my idea has some good parts
> > > > too.
> > > >
> > > > I want to figure out how to move forward on this problem. My other part
> > > > of this thread, this morning, was also part of me looking harder, again,
> > > > at the RFC series you posted before. And that's where I still have large
> > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > variants of, instead of 1 variant of. Take:
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > like it's not working as intended either? I checked and part_get_info
> > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > >                 info->type_guid[0] = 0;
> > > > #endif
> >
> > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > thing I see what happened. And now I see my problem from yesterday
> > morning was similar but different.
> >
> > > > is not true and checked. And I can't see why. And there's other size
> > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > in to more, but wasn't that symbol:
> > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > >                  function                                   old     new   delta
> > > >                  dev_get_uclass_plat                         12       -     -12
> > > >                  simple_bus_post_bind                        92       -     -92
> > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > >
> > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > core issues with the approach as implemented.
> > >
> > > But surely you can see that both schemes have exactly the same issues?
> > >
> > > My point is that the work to tidy up things and then get to a 'clean'
> > > source tree and Makefiles is the hard bit here and has to be done with
> > > both schemes.
> > >
> > > Just let me know which way you want to go. I don't have anything ready
> > > to send, but I could probably drag it over the line before too long,
> > > if you are keen.
> >
> > Once I figured out what was the cause of the problems I saw in the RFC,
> > I had to rewrite this a few times. Your approach needs even more symbols
> > added than were in the RFC, and the newly added symbols need further
> > auditing to make sure we have the same behavior as today at least by
> > default.
> 
> This is the idea that we need to clean up a, b and c. Your scheme is
> the same in this respect. If we have CONFIG_FOO today, then your
> scheme may need that duplicated to each defconfig file. Either you
> resolve the ambiguity or don't. But if you do, then you have to add
> symbols, with both schemes.

There is minimal pain in saying a defconfig needs to list CONFIG_FOO
there is pain in saying that we need to list
config PARTITION_TYPE_GUID
...
config SPL_PARTITION_TYPE_GUID
...
config TPL_PARTITION_TYPE_GUID
...
config VPL_PARTITION_TYPE_GUID
...

In what I'm saying it's not generally an issue because:
$ git grep -l PARTITION_TYPE_GUID configs | wc -l
21

And we don't have to do additional upkeep on having N symbols.

> > On the one hand, this is at least a well defined technical
> > problem and if you do the language extension *first* the code changes
> > aren't so bad.
> 
> There are no significant Kconfig changes in my scheme, other than the
> conf_nospl file. The language extension is quite separate.

$ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
\
	| filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
 25 files changed, 316 insertions(+), 3 deletions(-)

And that is largely duplication of existing symbols. And again, it
wasn't enough duplication.

> > But for the user running menuconfig / etc? That's not
> > going to be pretty. And we still won't have fixed the problems like "why
> > is TPL even trying to build DWC3?" without reworking more symbols.
> >
> > So I don't think this is the right approach as it doesn't reduce
> > confusion and may increase it (why do I need to set
> > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > CONFIG_PARTITION_TYPE_GUID?
> 
> Because it is an SPL build...I actually think that makes a lot of
> sense. You just need to understand that CONFIG_SPL_ means the SPL
> build, which in fact is what we have been using for years.

And it's no longer clear in the code, is the problem.

> 
> > But why is CONFIG_SPL_FRAMEWORK still there?
> 
> Not relevant to the discussion, IMO.

It's an example symbol. Why does the code have:

#ifdef CONFIG_PARTITION_TYPE_GUID
...
#endif

And that's true for SPL builds. But the code also still has:
#ifdef CONFIG_SPL_FRAMEWORK
...
#endif

Which is only true for CONFIG_SPL_FRAMEWORK being set.

> > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > that's more confusing. We still have one build where we need to do or
> > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > .config / defconfig.
> 
> Yes, that's the conf_nospl file which I have dealt with.

OK? My point is that the code is now more confusing, not less confusing.
Because the code says CONFIG_PARTITION_TYPE_GUID. Not
CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
which is at least a hint that one needs to look harder, and oh,
CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.

> > I really think we need to literally split the config files up such that
> > for the most part we do (in psuedo code):
> > %_full_config:
> >   make -C $(srctree) O=$(obj)/ppl %_ppl_defconfig
> >   make -C $(srctree) O=$(obj)/spl %_spl_defconfig
> >   ...
> >
> > all:
> >   [ -d $(obj)/ppl ] && make -C $(srctree) O=$(obj)/ppl all
> >   [ -d $(obj)/spl ] && make -C $(srctree) O=$(obj)/spl all
> >   ...
> >
> 
> Perhaps you should take a look at this and come up with an RFC series
> for your scheme? I think that would help us gain a better shared
> understanding of the problem.
> 
> Failing that, I am willing and able to do another version of my
> scheme, if it suits.

And how about instead you come up with an RFC of what I suggested, in
order to further your VPL proposal?

Or, have we finally come to it. I can either merge your proposal, which
I have grave reservations about, or you'll just do this all in your
downstream fork? Because no, I don't have time to work on reworking this
for VPL. I don't have the interest in reworking this for VPL.  Or should
we come up with some method for the community to vote on what to do
here?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > >
> > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > >
> > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > >
> > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > >
> > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > >
> > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > >
> > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > >
> > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > >
> > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > >
> > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > not important?
> > > > > > > > > > >
> > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > config SPL_FOO
> > > > > > > > > > >    default y if FOO
> > > > > > > > > > >
> > > > > > > > > > > config TPL_FOO
> > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > >
> > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > >
> > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > >
> > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > >
> > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > >
> > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > have below.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > direction.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > is automated.
> > > > > > > > > > > >
> > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > >
> > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > >
> > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > >
> > > > > > > > > > > Thanks.
> > > > > > > > > > >
> > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > >
> > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > >
> > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > these two different schemes.
> > > > > > > > > > >
> > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > >
> > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > still matters.
> > > > > > > > > >
> > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > possibility.
> > > > > > > > > >
> > > > > > > > > > A few points from my side:
> > > > > > > > > >
> > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > >
> > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > platform(s?).
> > > > > > > >
> > > > > > > > Agreed.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > lot of traction.
> > > > > > > > >
> > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > a step in the right direction, yes.
> > > > > > > >
> > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > desirable.
> > > > > > > > >
> > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > >         select ARM64
> > > > > > > > >         select SUPPORT_SPL
> > > > > > > > >         select SUPPORT_TPL
> > > > > > > > >         select SPL
> > > > > > > > >         select SPL_ATF
> > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > >         ...
> > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > >         ...
> > > > > > > > >         select CLK
> > > > > > > > >         ...
> > > > > > > > >         imply TPL_CLK
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > This would become:
> > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > >         select ARM64
> > > > > > > > >         select SUPPORT_SPL
> > > > > > > > >         select SUPPORT_TPL
> > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > >         ...
> > > > > > > >
> > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > >
> > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > >
> > > > > > > > But just the level of thought required in your small example above
> > > > > > > > suggests it is a large effort.
> > > > > > >
> > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > >
> > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > >
> > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > that's one of our problem areas.
> > > > > > > >
> > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > >
> > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > menu.
> > > > > > >
> > > > > > > > Mind generates
> > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > rules anymore.
> > > > > > >
> > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > >
> > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > CONFIG_FS_FAT=y does.
> > > > > > >
> > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > >
> > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > upstream).
> > > > > > > >
> > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > >
> > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > built, before asking binman to go put things together.
> > > > > > > >
> > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > >
> > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > types already handled in the Makefile that's missing.
> > > > > > >
> > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > project IMO.
> > > > > > >
> > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > PPL in the interim.
> > > > > > >
> > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > existing Kconfig.
> > > > > > >
> > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > divergence.
> > > > > >
> > > > > >
> > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > reject any future changes I send
> > > > > >
> > > > > > >
> > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > want to head. The two options would then be:
> > > > > > > >
> > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > teach the build to combine images
> > > > > > >
> > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > >
> > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > that large.
> > > > > >
> > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > >
> > > > > > >
> > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > >
> > > > > > > > > > Does that sound right?
> > > > > > > > >
> > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > understanding each other.
> > > > > > > >
> > > > > > > > Yes.
> > > > > > >
> > > > > > > Well, with that, what now?
> > > > > > >
> > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > how we build things, have I?
> > > > > >
> > > > > > Which VPL thing?
> > > > >
> > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > changes).
> > > >
> > > > Yes, that's why I took on this effort a few years back.
> > > >
> > > > >
> > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > sense to me than previously and it may be that it is better in the
> > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > >
> > > > > > I don't want to be tied to your scheme today though.
> > > > > >
> > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > the two options?
> > > > >
> > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > this direction already, and I do see some of the end goals it achieves
> > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > too.
> > > > >
> > > > > I want to figure out how to move forward on this problem. My other part
> > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > at the RFC series you posted before. And that's where I still have large
> > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > variants of, instead of 1 variant of. Take:
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > like it's not working as intended either? I checked and part_get_info
> > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > >                 info->type_guid[0] = 0;
> > > > > #endif
> > >
> > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > thing I see what happened. And now I see my problem from yesterday
> > > morning was similar but different.
> > >
> > > > > is not true and checked. And I can't see why. And there's other size
> > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > in to more, but wasn't that symbol:
> > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > >                  function                                   old     new   delta
> > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > >                  simple_bus_post_bind                        92       -     -92
> > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > >
> > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > core issues with the approach as implemented.
> > > >
> > > > But surely you can see that both schemes have exactly the same issues?
> > > >
> > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > both schemes.
> > > >
> > > > Just let me know which way you want to go. I don't have anything ready
> > > > to send, but I could probably drag it over the line before too long,
> > > > if you are keen.
> > >
> > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > I had to rewrite this a few times. Your approach needs even more symbols
> > > added than were in the RFC, and the newly added symbols need further
> > > auditing to make sure we have the same behavior as today at least by
> > > default.
> >
> > This is the idea that we need to clean up a, b and c. Your scheme is
> > the same in this respect. If we have CONFIG_FOO today, then your
> > scheme may need that duplicated to each defconfig file. Either you
> > resolve the ambiguity or don't. But if you do, then you have to add
> > symbols, with both schemes.
>
> There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> there is pain in saying that we need to list
> config PARTITION_TYPE_GUID
> ...
> config SPL_PARTITION_TYPE_GUID
> ...
> config TPL_PARTITION_TYPE_GUID
> ...
> config VPL_PARTITION_TYPE_GUID
> ...
>
> In what I'm saying it's not generally an issue because:
> $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> 21
>
> And we don't have to do additional upkeep on having N symbols.

Well we only need to add those extra symbols if 1) we want that
feature in a particular xPL, *and* 2) we don't want it everywhere.
There is nothing in my scheme which requires us to add options that
don't currently exist...but there is a problem if some code uses
CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
conf_nospl file helps with that and avoids changing Kconfig. But
again, if we are using both, then who knows what it means today, and
I'd like to clean it up.

>
> > > On the one hand, this is at least a well defined technical
> > > problem and if you do the language extension *first* the code changes
> > > aren't so bad.
> >
> > There are no significant Kconfig changes in my scheme, other than the
> > conf_nospl file. The language extension is quite separate.
>
> $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> \
>         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
>  25 files changed, 316 insertions(+), 3 deletions(-)
>
> And that is largely duplication of existing symbols. And again, it
> wasn't enough duplication.

I wonder if that is stuff that was already applied? Here is what I have today.

$ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
 0 files changed

You can use the u-boot-dm/splg-working tree to see the original
version. From memory, the splc tree is very old and was mostly applied
or dropped.

>
> > > But for the user running menuconfig / etc? That's not
> > > going to be pretty. And we still won't have fixed the problems like "why
> > > is TPL even trying to build DWC3?" without reworking more symbols.
> > >
> > > So I don't think this is the right approach as it doesn't reduce
> > > confusion and may increase it (why do I need to set
> > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > CONFIG_PARTITION_TYPE_GUID?
> >
> > Because it is an SPL build...I actually think that makes a lot of
> > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > build, which in fact is what we have been using for years.
>
> And it's no longer clear in the code, is the problem.
>
> >
> > > But why is CONFIG_SPL_FRAMEWORK still there?
> >
> > Not relevant to the discussion, IMO.
>
> It's an example symbol. Why does the code have:
>
> #ifdef CONFIG_PARTITION_TYPE_GUID
> ...
> #endif
>
> And that's true for SPL builds. But the code also still has:
> #ifdef CONFIG_SPL_FRAMEWORK
> ...
> #endif
>
> Which is only true for CONFIG_SPL_FRAMEWORK being set.

OK I think I understand your question. The tools work by identifying
options which are in PPL and may or not be in other builds. There is
no CONFIG_FRAMEWORK so all of this migration doesn't apply.

If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
then the discussion would be different.

BTW, I wonder if we could drop that symbol, or switch it around so
that boards which don't use it have to set CONFIG_SPL_STRANGE or
similar.

>
> > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > that's more confusing. We still have one build where we need to do or
> > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > .config / defconfig.
> >
> > Yes, that's the conf_nospl file which I have dealt with.
>
> OK? My point is that the code is now more confusing, not less confusing.
> Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> which is at least a hint that one needs to look harder, and oh,
> CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.

If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
agree, sorry. That is problems a-c in my original proposal and my
understanding is that both our approaches resolve this problem.

Otherwise, you've just lost me and we should probably give up on this point.

>
> > > I really think we need to literally split the config files up such that
> > > for the most part we do (in psuedo code):
> > > %_full_config:
> > >   make -C $(srctree) O=$(obj)/ppl %_ppl_defconfig
> > >   make -C $(srctree) O=$(obj)/spl %_spl_defconfig
> > >   ...
> > >
> > > all:
> > >   [ -d $(obj)/ppl ] && make -C $(srctree) O=$(obj)/ppl all
> > >   [ -d $(obj)/spl ] && make -C $(srctree) O=$(obj)/spl all
> > >   ...
> > >
> >
> > Perhaps you should take a look at this and come up with an RFC series
> > for your scheme? I think that would help us gain a better shared
> > understanding of the problem.
> >
> > Failing that, I am willing and able to do another version of my
> > scheme, if it suits.
>
> And how about instead you come up with an RFC of what I suggested, in
> order to further your VPL proposal?

That's unlikely, for two reasons:

i. We can start with my scheme, get that applied and then still
continue on to your scheme, so we haven't lost anything by doing mine
first

ii. I still believe my scheme could be the right one, although I have
to admit I would rather look at it again when we get to that point, as
I do have quite a few concerns about the Kconfig complexity of 4),
with my scheme, particularly after this discussion

>
> Or, have we finally come to it. I can either merge your proposal, which
> I have grave reservations about, or you'll just do this all in your
> downstream fork? Because no, I don't have time to work on reworking this
> for VPL. I don't have the interest in reworking this for VPL.  Or should
> we come up with some method for the community to vote on what to do
> here?
>
> --
> Tom

Or, if you don't want to make time to work on it, why get in the way
of those who are willing to do so?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 45395 bytes --]

On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > >
> > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > >
> > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > >
> > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > >
> > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > >
> > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > >
> > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > >
> > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > >
> > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > not important?
> > > > > > > > > > > >
> > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > >
> > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > >
> > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > >
> > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > >
> > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > >
> > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > direction.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > >
> > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks.
> > > > > > > > > > > >
> > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > >
> > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > >
> > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > still matters.
> > > > > > > > > > >
> > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > possibility.
> > > > > > > > > > >
> > > > > > > > > > > A few points from my side:
> > > > > > > > > > >
> > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > >
> > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > platform(s?).
> > > > > > > > >
> > > > > > > > > Agreed.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > lot of traction.
> > > > > > > > > >
> > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > a step in the right direction, yes.
> > > > > > > > >
> > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > desirable.
> > > > > > > > > >
> > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > >         select ARM64
> > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > >         select SPL
> > > > > > > > > >         select SPL_ATF
> > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > >         ...
> > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > >         ...
> > > > > > > > > >         select CLK
> > > > > > > > > >         ...
> > > > > > > > > >         imply TPL_CLK
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This would become:
> > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > >         select ARM64
> > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > >         ...
> > > > > > > > >
> > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > >
> > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > >
> > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > suggests it is a large effort.
> > > > > > > >
> > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > >
> > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > >
> > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > that's one of our problem areas.
> > > > > > > > >
> > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > >
> > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > menu.
> > > > > > > >
> > > > > > > > > Mind generates
> > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > rules anymore.
> > > > > > > >
> > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > >
> > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > >
> > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > >
> > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > upstream).
> > > > > > > > >
> > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > >
> > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > >
> > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > >
> > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > >
> > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > project IMO.
> > > > > > > >
> > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > PPL in the interim.
> > > > > > > >
> > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > existing Kconfig.
> > > > > > > >
> > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > divergence.
> > > > > > >
> > > > > > >
> > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > reject any future changes I send
> > > > > > >
> > > > > > > >
> > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > want to head. The two options would then be:
> > > > > > > > >
> > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > teach the build to combine images
> > > > > > > >
> > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > >
> > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > that large.
> > > > > > >
> > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > >
> > > > > > > >
> > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > >
> > > > > > > > > > > Does that sound right?
> > > > > > > > > >
> > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > understanding each other.
> > > > > > > > >
> > > > > > > > > Yes.
> > > > > > > >
> > > > > > > > Well, with that, what now?
> > > > > > > >
> > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > how we build things, have I?
> > > > > > >
> > > > > > > Which VPL thing?
> > > > > >
> > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > changes).
> > > > >
> > > > > Yes, that's why I took on this effort a few years back.
> > > > >
> > > > > >
> > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > >
> > > > > > > I don't want to be tied to your scheme today though.
> > > > > > >
> > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > the two options?
> > > > > >
> > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > too.
> > > > > >
> > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > variants of, instead of 1 variant of. Take:
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > >                 info->type_guid[0] = 0;
> > > > > > #endif
> > > >
> > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > thing I see what happened. And now I see my problem from yesterday
> > > > morning was similar but different.
> > > >
> > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > in to more, but wasn't that symbol:
> > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > >                  function                                   old     new   delta
> > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > >
> > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > core issues with the approach as implemented.
> > > > >
> > > > > But surely you can see that both schemes have exactly the same issues?
> > > > >
> > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > both schemes.
> > > > >
> > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > to send, but I could probably drag it over the line before too long,
> > > > > if you are keen.
> > > >
> > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > added than were in the RFC, and the newly added symbols need further
> > > > auditing to make sure we have the same behavior as today at least by
> > > > default.
> > >
> > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > the same in this respect. If we have CONFIG_FOO today, then your
> > > scheme may need that duplicated to each defconfig file. Either you
> > > resolve the ambiguity or don't. But if you do, then you have to add
> > > symbols, with both schemes.
> >
> > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > there is pain in saying that we need to list
> > config PARTITION_TYPE_GUID
> > ...
> > config SPL_PARTITION_TYPE_GUID
> > ...
> > config TPL_PARTITION_TYPE_GUID
> > ...
> > config VPL_PARTITION_TYPE_GUID
> > ...
> >
> > In what I'm saying it's not generally an issue because:
> > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > 21
> >
> > And we don't have to do additional upkeep on having N symbols.
> 
> Well we only need to add those extra symbols if 1) we want that
> feature in a particular xPL, *and* 2) we don't want it everywhere.

Yes, and the problem is adding more of them. Again, we would need to
duplicate drivers/usb/gadget/Kconfig with your scheme.

> There is nothing in my scheme which requires us to add options that
> don't currently exist...but there is a problem if some code uses
> CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My

That's good because that wasn't (how it seemed?) previously.

> conf_nospl file helps with that and avoids changing Kconfig. But
> again, if we are using both, then who knows what it means today, and
> I'd like to clean it up.

What we have today, with respect to CONFIG_IS_ENABLED(...) /
IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
It's easy to get *wrong* yes, but it's also clear. You're checking for
what it says.

> > > > On the one hand, this is at least a well defined technical
> > > > problem and if you do the language extension *first* the code changes
> > > > aren't so bad.
> > >
> > > There are no significant Kconfig changes in my scheme, other than the
> > > conf_nospl file. The language extension is quite separate.
> >
> > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > \
> >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> >  25 files changed, 316 insertions(+), 3 deletions(-)
> >
> > And that is largely duplication of existing symbols. And again, it
> > wasn't enough duplication.
> 
> I wonder if that is stuff that was already applied? Here is what I have today.
> 
> $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
>  0 files changed
> 
> You can use the u-boot-dm/splg-working tree to see the original
> version. From memory, the splc tree is very old and was mostly applied
> or dropped.

The splc-working tree is the RFC you pointed at earlier and so yes, what
I was comparing with. If you were able to drop some of the problems,
that's good.

> > > > But for the user running menuconfig / etc? That's not
> > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > >
> > > > So I don't think this is the right approach as it doesn't reduce
> > > > confusion and may increase it (why do I need to set
> > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > CONFIG_PARTITION_TYPE_GUID?
> > >
> > > Because it is an SPL build...I actually think that makes a lot of
> > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > build, which in fact is what we have been using for years.
> >
> > And it's no longer clear in the code, is the problem.
> >
> > >
> > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > >
> > > Not relevant to the discussion, IMO.
> >
> > It's an example symbol. Why does the code have:
> >
> > #ifdef CONFIG_PARTITION_TYPE_GUID
> > ...
> > #endif
> >
> > And that's true for SPL builds. But the code also still has:
> > #ifdef CONFIG_SPL_FRAMEWORK
> > ...
> > #endif
> >
> > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> 
> OK I think I understand your question. The tools work by identifying
> options which are in PPL and may or not be in other builds. There is
> no CONFIG_FRAMEWORK so all of this migration doesn't apply.

No, you entirely misunderstand me. I am not talking about the tool. I am
talking about the developer.

> If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> then the discussion would be different.
> 
> BTW, I wonder if we could drop that symbol, or switch it around so
> that boards which don't use it have to set CONFIG_SPL_STRANGE or
> similar.

Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
you want to file an issue for it, please do. But that (roughly) is why
there's SPL_FRAMEWORK.

> > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > that's more confusing. We still have one build where we need to do or
> > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > .config / defconfig.
> > >
> > > Yes, that's the conf_nospl file which I have dealt with.
> >
> > OK? My point is that the code is now more confusing, not less confusing.
> > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > which is at least a hint that one needs to look harder, and oh,
> > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> 
> If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> agree, sorry. That is problems a-c in my original proposal and my
> understanding is that both our approaches resolve this problem.
> 
> Otherwise, you've just lost me and we should probably give up on this point.

Yes, I am saying that what we have today is less confusing than what you
are proposing. Because with your proposal:

obj-$(CONFIG_FS_FAT) += fat/

Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
is not good for humans.

> > > > I really think we need to literally split the config files up such that
> > > > for the most part we do (in psuedo code):
> > > > %_full_config:
> > > >   make -C $(srctree) O=$(obj)/ppl %_ppl_defconfig
> > > >   make -C $(srctree) O=$(obj)/spl %_spl_defconfig
> > > >   ...
> > > >
> > > > all:
> > > >   [ -d $(obj)/ppl ] && make -C $(srctree) O=$(obj)/ppl all
> > > >   [ -d $(obj)/spl ] && make -C $(srctree) O=$(obj)/spl all
> > > >   ...
> > > >
> > >
> > > Perhaps you should take a look at this and come up with an RFC series
> > > for your scheme? I think that would help us gain a better shared
> > > understanding of the problem.
> > >
> > > Failing that, I am willing and able to do another version of my
> > > scheme, if it suits.
> >
> > And how about instead you come up with an RFC of what I suggested, in
> > order to further your VPL proposal?
> 
> That's unlikely, for two reasons:
> 
> i. We can start with my scheme, get that applied and then still
> continue on to your scheme, so we haven't lost anything by doing mine
> first
> 
> ii. I still believe my scheme could be the right one, although I have
> to admit I would rather look at it again when we get to that point, as
> I do have quite a few concerns about the Kconfig complexity of 4),
> with my scheme, particularly after this discussion
> 
> >
> > Or, have we finally come to it. I can either merge your proposal, which
> > I have grave reservations about, or you'll just do this all in your
> > downstream fork? Because no, I don't have time to work on reworking this
> > for VPL. I don't have the interest in reworking this for VPL.  Or should
> > we come up with some method for the community to vote on what to do
> > here?
> 
> Or, if you don't want to make time to work on it, why get in the way
> of those who are willing to do so?

Because I'm reviewing your code and see grave problems? Problems that
could be worse than doing nothing? That's why. I will take a look at
"splg-working". However, I disagree with your point (i) above in that
the reusable work is the script'able work. For example, we've already
had feedback that when using $(PHASE_) vs $(XPL_) is confusing. Now
we're going to replace that confusion with "why does CONFIG_SPL_FOO
sometimes also mean CONFIG_FOO but not others?".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > >
> > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > >
> > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > >
> > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > not important?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > >
> > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > >
> > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > still matters.
> > > > > > > > > > > >
> > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > possibility.
> > > > > > > > > > > >
> > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > >
> > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > platform(s?).
> > > > > > > > > >
> > > > > > > > > > Agreed.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > lot of traction.
> > > > > > > > > > >
> > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > >
> > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > desirable.
> > > > > > > > > > >
> > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > >         select ARM64
> > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > >         select SPL
> > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > >         ...
> > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > >         ...
> > > > > > > > > > >         select CLK
> > > > > > > > > > >         ...
> > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > This would become:
> > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > >         select ARM64
> > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > >         ...
> > > > > > > > > >
> > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > >
> > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > >
> > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > suggests it is a large effort.
> > > > > > > > >
> > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > >
> > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > >
> > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > >
> > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > >
> > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > menu.
> > > > > > > > >
> > > > > > > > > > Mind generates
> > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > rules anymore.
> > > > > > > > >
> > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > >
> > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > >
> > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > >
> > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > upstream).
> > > > > > > > > >
> > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > >
> > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > >
> > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > >
> > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > >
> > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > project IMO.
> > > > > > > > >
> > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > PPL in the interim.
> > > > > > > > >
> > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > existing Kconfig.
> > > > > > > > >
> > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > divergence.
> > > > > > > >
> > > > > > > >
> > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > reject any future changes I send
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > >
> > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > teach the build to combine images
> > > > > > > > >
> > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > >
> > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > that large.
> > > > > > > >
> > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > >
> > > > > > > > > > > > Does that sound right?
> > > > > > > > > > >
> > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > understanding each other.
> > > > > > > > > >
> > > > > > > > > > Yes.
> > > > > > > > >
> > > > > > > > > Well, with that, what now?
> > > > > > > > >
> > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > how we build things, have I?
> > > > > > > >
> > > > > > > > Which VPL thing?
> > > > > > >
> > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > changes).
> > > > > >
> > > > > > Yes, that's why I took on this effort a few years back.
> > > > > >
> > > > > > >
> > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > >
> > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > >
> > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > the two options?
> > > > > > >
> > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > too.
> > > > > > >
> > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > >                 info->type_guid[0] = 0;
> > > > > > > #endif
> > > > >
> > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > morning was similar but different.
> > > > >
> > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > in to more, but wasn't that symbol:
> > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > >                  function                                   old     new   delta
> > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > >
> > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > core issues with the approach as implemented.
> > > > > >
> > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > >
> > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > both schemes.
> > > > > >
> > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > if you are keen.
> > > > >
> > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > added than were in the RFC, and the newly added symbols need further
> > > > > auditing to make sure we have the same behavior as today at least by
> > > > > default.
> > > >
> > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > scheme may need that duplicated to each defconfig file. Either you
> > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > symbols, with both schemes.
> > >
> > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > there is pain in saying that we need to list
> > > config PARTITION_TYPE_GUID
> > > ...
> > > config SPL_PARTITION_TYPE_GUID
> > > ...
> > > config TPL_PARTITION_TYPE_GUID
> > > ...
> > > config VPL_PARTITION_TYPE_GUID
> > > ...
> > >
> > > In what I'm saying it's not generally an issue because:
> > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > 21
> > >
> > > And we don't have to do additional upkeep on having N symbols.
> >
> > Well we only need to add those extra symbols if 1) we want that
> > feature in a particular xPL, *and* 2) we don't want it everywhere.
>
> Yes, and the problem is adding more of them. Again, we would need to
> duplicate drivers/usb/gadget/Kconfig with your scheme.
>
> > There is nothing in my scheme which requires us to add options that
> > don't currently exist...but there is a problem if some code uses
> > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
>
> That's good because that wasn't (how it seemed?) previously.
>
> > conf_nospl file helps with that and avoids changing Kconfig. But
> > again, if we are using both, then who knows what it means today, and
> > I'd like to clean it up.
>
> What we have today, with respect to CONFIG_IS_ENABLED(...) /
> IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> It's easy to get *wrong* yes, but it's also clear. You're checking for
> what it says.
>
> > > > > On the one hand, this is at least a well defined technical
> > > > > problem and if you do the language extension *first* the code changes
> > > > > aren't so bad.
> > > >
> > > > There are no significant Kconfig changes in my scheme, other than the
> > > > conf_nospl file. The language extension is quite separate.
> > >
> > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > \
> > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > >
> > > And that is largely duplication of existing symbols. And again, it
> > > wasn't enough duplication.
> >
> > I wonder if that is stuff that was already applied? Here is what I have today.
> >
> > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> >  0 files changed
> >
> > You can use the u-boot-dm/splg-working tree to see the original
> > version. From memory, the splc tree is very old and was mostly applied
> > or dropped.
>
> The splc-working tree is the RFC you pointed at earlier and so yes, what
> I was comparing with. If you were able to drop some of the problems,
> that's good.
>
> > > > > But for the user running menuconfig / etc? That's not
> > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > >
> > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > confusion and may increase it (why do I need to set
> > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > CONFIG_PARTITION_TYPE_GUID?
> > > >
> > > > Because it is an SPL build...I actually think that makes a lot of
> > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > build, which in fact is what we have been using for years.
> > >
> > > And it's no longer clear in the code, is the problem.
> > >
> > > >
> > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > >
> > > > Not relevant to the discussion, IMO.
> > >
> > > It's an example symbol. Why does the code have:
> > >
> > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > ...
> > > #endif
> > >
> > > And that's true for SPL builds. But the code also still has:
> > > #ifdef CONFIG_SPL_FRAMEWORK
> > > ...
> > > #endif
> > >
> > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> >
> > OK I think I understand your question. The tools work by identifying
> > options which are in PPL and may or not be in other builds. There is
> > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
>
> No, you entirely misunderstand me. I am not talking about the tool. I am
> talking about the developer.
>
> > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > then the discussion would be different.
> >
> > BTW, I wonder if we could drop that symbol, or switch it around so
> > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > similar.
>
> Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> you want to file an issue for it, please do. But that (roughly) is why
> there's SPL_FRAMEWORK.
>
> > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > that's more confusing. We still have one build where we need to do or
> > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > .config / defconfig.
> > > >
> > > > Yes, that's the conf_nospl file which I have dealt with.
> > >
> > > OK? My point is that the code is now more confusing, not less confusing.
> > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > which is at least a hint that one needs to look harder, and oh,
> > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> >
> > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > agree, sorry. That is problems a-c in my original proposal and my
> > understanding is that both our approaches resolve this problem.
> >
> > Otherwise, you've just lost me and we should probably give up on this point.
>
> Yes, I am saying that what we have today is less confusing than what you
> are proposing. Because with your proposal:
>
> obj-$(CONFIG_FS_FAT) += fat/
>
> Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> is not good for humans.

Let's just stop on this point. We seem to be going backwards. Now you
are saying that you *want* to keep:

a. The $(PHASE_) stuff in Makefiles
b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split

and you believe that

c. the ambiguity I mentioned with CONFIG_FOO

are all actually a good thing?

Your first response was "I agree with a through c and for d there are
likely some cases even if I'm not sure TEXT_BASE is a good example"
which I took to mean that you saw these as problems just like I do.

But if you believe we are better off with a-c as they are today, then
none of my work has any relevance to what you are looking for.

>
> > > > > I really think we need to literally split the config files up such that
> > > > > for the most part we do (in psuedo code):
> > > > > %_full_config:
> > > > >   make -C $(srctree) O=$(obj)/ppl %_ppl_defconfig
> > > > >   make -C $(srctree) O=$(obj)/spl %_spl_defconfig
> > > > >   ...
> > > > >
> > > > > all:
> > > > >   [ -d $(obj)/ppl ] && make -C $(srctree) O=$(obj)/ppl all
> > > > >   [ -d $(obj)/spl ] && make -C $(srctree) O=$(obj)/spl all
> > > > >   ...
> > > > >
> > > >
> > > > Perhaps you should take a look at this and come up with an RFC series
> > > > for your scheme? I think that would help us gain a better shared
> > > > understanding of the problem.
> > > >
> > > > Failing that, I am willing and able to do another version of my
> > > > scheme, if it suits.
> > >
> > > And how about instead you come up with an RFC of what I suggested, in
> > > order to further your VPL proposal?
> >
> > That's unlikely, for two reasons:
> >
> > i. We can start with my scheme, get that applied and then still
> > continue on to your scheme, so we haven't lost anything by doing mine
> > first
> >
> > ii. I still believe my scheme could be the right one, although I have
> > to admit I would rather look at it again when we get to that point, as
> > I do have quite a few concerns about the Kconfig complexity of 4),
> > with my scheme, particularly after this discussion
> >
> > >
> > > Or, have we finally come to it. I can either merge your proposal, which
> > > I have grave reservations about, or you'll just do this all in your
> > > downstream fork? Because no, I don't have time to work on reworking this
> > > for VPL. I don't have the interest in reworking this for VPL.  Or should
> > > we come up with some method for the community to vote on what to do
> > > here?
> >
> > Or, if you don't want to make time to work on it, why get in the way
> > of those who are willing to do so?
>
> Because I'm reviewing your code and see grave problems? Problems that
> could be worse than doing nothing? That's why. I will take a look at
> "splg-working". However, I disagree with your point (i) above in that
> the reusable work is the script'able work. For example, we've already
> had feedback that when using $(PHASE_) vs $(XPL_) is confusing. Now
> we're going to replace that confusion with "why does CONFIG_SPL_FOO
> sometimes also mean CONFIG_FOO but not others?".

How much feedback and how many people?

Anyway, please see above. Let's just start this whole thread again
once we can figure out what you do and don't want from the end result.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 47114 bytes --]

On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > possibility.
> > > > > > > > > > > > >
> > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > platform(s?).
> > > > > > > > > > >
> > > > > > > > > > > Agreed.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > >
> > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > desirable.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > >         select ARM64
> > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > >         select SPL
> > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > >         ...
> > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > >         ...
> > > > > > > > > > > >         select CLK
> > > > > > > > > > > >         ...
> > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > This would become:
> > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > >         select ARM64
> > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > >         ...
> > > > > > > > > > >
> > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > >
> > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > >
> > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > >
> > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > >
> > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > >
> > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > >
> > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > >
> > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > menu.
> > > > > > > > > >
> > > > > > > > > > > Mind generates
> > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > rules anymore.
> > > > > > > > > >
> > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > >
> > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > >
> > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > >
> > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > upstream).
> > > > > > > > > > >
> > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > >
> > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > >
> > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > >
> > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > >
> > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > project IMO.
> > > > > > > > > >
> > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > PPL in the interim.
> > > > > > > > > >
> > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > existing Kconfig.
> > > > > > > > > >
> > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > divergence.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > reject any future changes I send
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > >
> > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > teach the build to combine images
> > > > > > > > > >
> > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > >
> > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > that large.
> > > > > > > > >
> > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > >
> > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > understanding each other.
> > > > > > > > > > >
> > > > > > > > > > > Yes.
> > > > > > > > > >
> > > > > > > > > > Well, with that, what now?
> > > > > > > > > >
> > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > how we build things, have I?
> > > > > > > > >
> > > > > > > > > Which VPL thing?
> > > > > > > >
> > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > changes).
> > > > > > >
> > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > >
> > > > > > > >
> > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > >
> > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > >
> > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > the two options?
> > > > > > > >
> > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > too.
> > > > > > > >
> > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > #endif
> > > > > >
> > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > morning was similar but different.
> > > > > >
> > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > in to more, but wasn't that symbol:
> > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > >                  function                                   old     new   delta
> > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > >
> > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > core issues with the approach as implemented.
> > > > > > >
> > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > >
> > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > both schemes.
> > > > > > >
> > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > if you are keen.
> > > > > >
> > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > default.
> > > > >
> > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > symbols, with both schemes.
> > > >
> > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > there is pain in saying that we need to list
> > > > config PARTITION_TYPE_GUID
> > > > ...
> > > > config SPL_PARTITION_TYPE_GUID
> > > > ...
> > > > config TPL_PARTITION_TYPE_GUID
> > > > ...
> > > > config VPL_PARTITION_TYPE_GUID
> > > > ...
> > > >
> > > > In what I'm saying it's not generally an issue because:
> > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > 21
> > > >
> > > > And we don't have to do additional upkeep on having N symbols.
> > >
> > > Well we only need to add those extra symbols if 1) we want that
> > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> >
> > Yes, and the problem is adding more of them. Again, we would need to
> > duplicate drivers/usb/gadget/Kconfig with your scheme.
> >
> > > There is nothing in my scheme which requires us to add options that
> > > don't currently exist...but there is a problem if some code uses
> > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> >
> > That's good because that wasn't (how it seemed?) previously.
> >
> > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > again, if we are using both, then who knows what it means today, and
> > > I'd like to clean it up.
> >
> > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > what it says.
> >
> > > > > > On the one hand, this is at least a well defined technical
> > > > > > problem and if you do the language extension *first* the code changes
> > > > > > aren't so bad.
> > > > >
> > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > conf_nospl file. The language extension is quite separate.
> > > >
> > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > \
> > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > >
> > > > And that is largely duplication of existing symbols. And again, it
> > > > wasn't enough duplication.
> > >
> > > I wonder if that is stuff that was already applied? Here is what I have today.
> > >
> > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > >  0 files changed
> > >
> > > You can use the u-boot-dm/splg-working tree to see the original
> > > version. From memory, the splc tree is very old and was mostly applied
> > > or dropped.
> >
> > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > I was comparing with. If you were able to drop some of the problems,
> > that's good.
> >
> > > > > > But for the user running menuconfig / etc? That's not
> > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > >
> > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > confusion and may increase it (why do I need to set
> > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > >
> > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > build, which in fact is what we have been using for years.
> > > >
> > > > And it's no longer clear in the code, is the problem.
> > > >
> > > > >
> > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > >
> > > > > Not relevant to the discussion, IMO.
> > > >
> > > > It's an example symbol. Why does the code have:
> > > >
> > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > ...
> > > > #endif
> > > >
> > > > And that's true for SPL builds. But the code also still has:
> > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > ...
> > > > #endif
> > > >
> > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > >
> > > OK I think I understand your question. The tools work by identifying
> > > options which are in PPL and may or not be in other builds. There is
> > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> >
> > No, you entirely misunderstand me. I am not talking about the tool. I am
> > talking about the developer.
> >
> > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > then the discussion would be different.
> > >
> > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > similar.
> >
> > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > you want to file an issue for it, please do. But that (roughly) is why
> > there's SPL_FRAMEWORK.
> >
> > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > .config / defconfig.
> > > > >
> > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > >
> > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > which is at least a hint that one needs to look harder, and oh,
> > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > >
> > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > agree, sorry. That is problems a-c in my original proposal and my
> > > understanding is that both our approaches resolve this problem.
> > >
> > > Otherwise, you've just lost me and we should probably give up on this point.
> >
> > Yes, I am saying that what we have today is less confusing than what you
> > are proposing. Because with your proposal:
> >
> > obj-$(CONFIG_FS_FAT) += fat/
> >
> > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > is not good for humans.
> 
> Let's just stop on this point. We seem to be going backwards. Now you
> are saying that you *want* to keep:
> 
> a. The $(PHASE_) stuff in Makefiles
> b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> 
> and you believe that
> 
> c. the ambiguity I mentioned with CONFIG_FOO
> 
> are all actually a good thing?

No. I'm saying that what we have today is LESS confusing than your
proposal in splc-working. I can't evaluate splg-working because it
doesn't work enough to be clear if it does or doesn't still solve all
the problems that splc-working does. Various things don't build anymore
in splg-working and T2080RDB_NAND as a first example (as the powerpc
part of the world build failed first) has massive size changes.

I do not like splc-working, but splc-working is a few bugs away from 1:1
functional binaries from before your changes.

I do not like what we have today because it's tricky to get things
right. But the macros are visible in the code / Makefiles so humans
still find things.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 14 Feb 2025 at 18:14, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > > possibility.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > > platform(s?).
> > > > > > > > > > > >
> > > > > > > > > > > > Agreed.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > > >
> > > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > > desirable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > >         select SPL
> > > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > > >         ...
> > > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > > >         ...
> > > > > > > > > > > > >         select CLK
> > > > > > > > > > > > >         ...
> > > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > This would become:
> > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > > >         ...
> > > > > > > > > > > >
> > > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > > >
> > > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > > >
> > > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > > >
> > > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > > >
> > > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > > >
> > > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > > >
> > > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > > menu.
> > > > > > > > > > >
> > > > > > > > > > > > Mind generates
> > > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > > rules anymore.
> > > > > > > > > > >
> > > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > > >
> > > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > > >
> > > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > > upstream).
> > > > > > > > > > > >
> > > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > > >
> > > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > > >
> > > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > > >
> > > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > > >
> > > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > > project IMO.
> > > > > > > > > > >
> > > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > > PPL in the interim.
> > > > > > > > > > >
> > > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > > existing Kconfig.
> > > > > > > > > > >
> > > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > > divergence.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > > reject any future changes I send
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > > >
> > > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > > teach the build to combine images
> > > > > > > > > > >
> > > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > > >
> > > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > > that large.
> > > > > > > > > >
> > > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > > >
> > > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > > understanding each other.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes.
> > > > > > > > > > >
> > > > > > > > > > > Well, with that, what now?
> > > > > > > > > > >
> > > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > > how we build things, have I?
> > > > > > > > > >
> > > > > > > > > > Which VPL thing?
> > > > > > > > >
> > > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > > changes).
> > > > > > > >
> > > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > > >
> > > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > > >
> > > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > > the two options?
> > > > > > > > >
> > > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > > too.
> > > > > > > > >
> > > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > > #endif
> > > > > > >
> > > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > > morning was similar but different.
> > > > > > >
> > > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > > in to more, but wasn't that symbol:
> > > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > > >                  function                                   old     new   delta
> > > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > > >
> > > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > > core issues with the approach as implemented.
> > > > > > > >
> > > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > > >
> > > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > > both schemes.
> > > > > > > >
> > > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > > if you are keen.
> > > > > > >
> > > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > > default.
> > > > > >
> > > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > > symbols, with both schemes.
> > > > >
> > > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > > there is pain in saying that we need to list
> > > > > config PARTITION_TYPE_GUID
> > > > > ...
> > > > > config SPL_PARTITION_TYPE_GUID
> > > > > ...
> > > > > config TPL_PARTITION_TYPE_GUID
> > > > > ...
> > > > > config VPL_PARTITION_TYPE_GUID
> > > > > ...
> > > > >
> > > > > In what I'm saying it's not generally an issue because:
> > > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > > 21
> > > > >
> > > > > And we don't have to do additional upkeep on having N symbols.
> > > >
> > > > Well we only need to add those extra symbols if 1) we want that
> > > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> > >
> > > Yes, and the problem is adding more of them. Again, we would need to
> > > duplicate drivers/usb/gadget/Kconfig with your scheme.
> > >
> > > > There is nothing in my scheme which requires us to add options that
> > > > don't currently exist...but there is a problem if some code uses
> > > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> > >
> > > That's good because that wasn't (how it seemed?) previously.
> > >
> > > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > > again, if we are using both, then who knows what it means today, and
> > > > I'd like to clean it up.
> > >
> > > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > > what it says.
> > >
> > > > > > > On the one hand, this is at least a well defined technical
> > > > > > > problem and if you do the language extension *first* the code changes
> > > > > > > aren't so bad.
> > > > > >
> > > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > > conf_nospl file. The language extension is quite separate.
> > > > >
> > > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > > \
> > > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > > >
> > > > > And that is largely duplication of existing symbols. And again, it
> > > > > wasn't enough duplication.
> > > >
> > > > I wonder if that is stuff that was already applied? Here is what I have today.
> > > >
> > > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > >  0 files changed
> > > >
> > > > You can use the u-boot-dm/splg-working tree to see the original
> > > > version. From memory, the splc tree is very old and was mostly applied
> > > > or dropped.
> > >
> > > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > > I was comparing with. If you were able to drop some of the problems,
> > > that's good.
> > >
> > > > > > > But for the user running menuconfig / etc? That's not
> > > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > > >
> > > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > > confusion and may increase it (why do I need to set
> > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > > >
> > > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > > build, which in fact is what we have been using for years.
> > > > >
> > > > > And it's no longer clear in the code, is the problem.
> > > > >
> > > > > >
> > > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > > >
> > > > > > Not relevant to the discussion, IMO.
> > > > >
> > > > > It's an example symbol. Why does the code have:
> > > > >
> > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > ...
> > > > > #endif
> > > > >
> > > > > And that's true for SPL builds. But the code also still has:
> > > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > > ...
> > > > > #endif
> > > > >
> > > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > > >
> > > > OK I think I understand your question. The tools work by identifying
> > > > options which are in PPL and may or not be in other builds. There is
> > > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> > >
> > > No, you entirely misunderstand me. I am not talking about the tool. I am
> > > talking about the developer.
> > >
> > > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > > then the discussion would be different.
> > > >
> > > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > > similar.
> > >
> > > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > > you want to file an issue for it, please do. But that (roughly) is why
> > > there's SPL_FRAMEWORK.
> > >
> > > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > > .config / defconfig.
> > > > > >
> > > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > > >
> > > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > > which is at least a hint that one needs to look harder, and oh,
> > > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > > >
> > > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > > agree, sorry. That is problems a-c in my original proposal and my
> > > > understanding is that both our approaches resolve this problem.
> > > >
> > > > Otherwise, you've just lost me and we should probably give up on this point.
> > >
> > > Yes, I am saying that what we have today is less confusing than what you
> > > are proposing. Because with your proposal:
> > >
> > > obj-$(CONFIG_FS_FAT) += fat/
> > >
> > > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > > is not good for humans.
> >
> > Let's just stop on this point. We seem to be going backwards. Now you
> > are saying that you *want* to keep:
> >
> > a. The $(PHASE_) stuff in Makefiles
> > b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> >
> > and you believe that
> >
> > c. the ambiguity I mentioned with CONFIG_FOO
> >
> > are all actually a good thing?
>
> No. I'm saying that what we have today is LESS confusing than your
> proposal in splc-working. I can't evaluate splg-working because it
> doesn't work enough to be clear if it does or doesn't still solve all
> the problems that splc-working does. Various things don't build anymore
> in splg-working and T2080RDB_NAND as a first example (as the powerpc
> part of the world build failed first) has massive size changes.
>
> I do not like splc-working, but splc-working is a few bugs away from 1:1
> functional binaries from before your changes.
>
> I do not like what we have today because it's tricky to get things
> right. But the macros are visible in the code / Makefiles so humans
> still find things.

OK, well I am still lost, sorry.

We are trying to discuss a change to how CONFIG options are handled in
the source tree. It sounds like you are saying that you cannot review
it until it fully works. But you already did that two years ago and
rejected it. So I don't see any way forward here. Do you?

Regards,
Simon

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 14 Feb 2025 at 18:43, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Fri, 14 Feb 2025 at 18:14, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > > > possibility.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > > > platform(s?).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > > > desirable.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > >         select SPL
> > > > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > >         select CLK
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This would become:
> > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > > > >
> > > > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > > > >
> > > > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > > > >
> > > > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > > > >
> > > > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > > > menu.
> > > > > > > > > > > >
> > > > > > > > > > > > > Mind generates
> > > > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > > > rules anymore.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > > > >
> > > > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > > > >
> > > > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > > > upstream).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > > > >
> > > > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > > > project IMO.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > > > PPL in the interim.
> > > > > > > > > > > >
> > > > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > > > existing Kconfig.
> > > > > > > > > > > >
> > > > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > > > divergence.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > > > reject any future changes I send
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > > > >
> > > > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > > > teach the build to combine images
> > > > > > > > > > > >
> > > > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > > > >
> > > > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > > > that large.
> > > > > > > > > > >
> > > > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > > > understanding each other.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes.
> > > > > > > > > > > >
> > > > > > > > > > > > Well, with that, what now?
> > > > > > > > > > > >
> > > > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > > > how we build things, have I?
> > > > > > > > > > >
> > > > > > > > > > > Which VPL thing?
> > > > > > > > > >
> > > > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > > > changes).
> > > > > > > > >
> > > > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > > > >
> > > > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > > > >
> > > > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > > > the two options?
> > > > > > > > > >
> > > > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > > > too.
> > > > > > > > > >
> > > > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > > > #endif
> > > > > > > >
> > > > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > > > morning was similar but different.
> > > > > > > >
> > > > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > > > in to more, but wasn't that symbol:
> > > > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > > > >                  function                                   old     new   delta
> > > > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > > > >
> > > > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > > > core issues with the approach as implemented.
> > > > > > > > >
> > > > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > > > >
> > > > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > > > both schemes.
> > > > > > > > >
> > > > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > > > if you are keen.
> > > > > > > >
> > > > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > > > default.
> > > > > > >
> > > > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > > > symbols, with both schemes.
> > > > > >
> > > > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > > > there is pain in saying that we need to list
> > > > > > config PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > config SPL_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > config TPL_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > config VPL_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > >
> > > > > > In what I'm saying it's not generally an issue because:
> > > > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > > > 21
> > > > > >
> > > > > > And we don't have to do additional upkeep on having N symbols.
> > > > >
> > > > > Well we only need to add those extra symbols if 1) we want that
> > > > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> > > >
> > > > Yes, and the problem is adding more of them. Again, we would need to
> > > > duplicate drivers/usb/gadget/Kconfig with your scheme.
> > > >
> > > > > There is nothing in my scheme which requires us to add options that
> > > > > don't currently exist...but there is a problem if some code uses
> > > > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> > > >
> > > > That's good because that wasn't (how it seemed?) previously.
> > > >
> > > > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > > > again, if we are using both, then who knows what it means today, and
> > > > > I'd like to clean it up.
> > > >
> > > > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > > > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > > > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > > > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > > > what it says.
> > > >
> > > > > > > > On the one hand, this is at least a well defined technical
> > > > > > > > problem and if you do the language extension *first* the code changes
> > > > > > > > aren't so bad.
> > > > > > >
> > > > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > > > conf_nospl file. The language extension is quite separate.
> > > > > >
> > > > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > > > \
> > > > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > And that is largely duplication of existing symbols. And again, it
> > > > > > wasn't enough duplication.
> > > > >
> > > > > I wonder if that is stuff that was already applied? Here is what I have today.
> > > > >
> > > > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > >  0 files changed
> > > > >
> > > > > You can use the u-boot-dm/splg-working tree to see the original
> > > > > version. From memory, the splc tree is very old and was mostly applied
> > > > > or dropped.
> > > >
> > > > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > > > I was comparing with. If you were able to drop some of the problems,
> > > > that's good.
> > > >
> > > > > > > > But for the user running menuconfig / etc? That's not
> > > > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > > > >
> > > > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > > > confusion and may increase it (why do I need to set
> > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > > > >
> > > > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > > > build, which in fact is what we have been using for years.
> > > > > >
> > > > > > And it's no longer clear in the code, is the problem.
> > > > > >
> > > > > > >
> > > > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > > > >
> > > > > > > Not relevant to the discussion, IMO.
> > > > > >
> > > > > > It's an example symbol. Why does the code have:
> > > > > >
> > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > #endif
> > > > > >
> > > > > > And that's true for SPL builds. But the code also still has:
> > > > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > > > ...
> > > > > > #endif
> > > > > >
> > > > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > > > >
> > > > > OK I think I understand your question. The tools work by identifying
> > > > > options which are in PPL and may or not be in other builds. There is
> > > > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> > > >
> > > > No, you entirely misunderstand me. I am not talking about the tool. I am
> > > > talking about the developer.
> > > >
> > > > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > > > then the discussion would be different.
> > > > >
> > > > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > > > similar.
> > > >
> > > > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > > > you want to file an issue for it, please do. But that (roughly) is why
> > > > there's SPL_FRAMEWORK.
> > > >
> > > > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > > > .config / defconfig.
> > > > > > >
> > > > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > > > >
> > > > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > > > which is at least a hint that one needs to look harder, and oh,
> > > > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > > > >
> > > > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > > > agree, sorry. That is problems a-c in my original proposal and my
> > > > > understanding is that both our approaches resolve this problem.
> > > > >
> > > > > Otherwise, you've just lost me and we should probably give up on this point.
> > > >
> > > > Yes, I am saying that what we have today is less confusing than what you
> > > > are proposing. Because with your proposal:
> > > >
> > > > obj-$(CONFIG_FS_FAT) += fat/
> > > >
> > > > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > > > is not good for humans.
> > >
> > > Let's just stop on this point. We seem to be going backwards. Now you
> > > are saying that you *want* to keep:
> > >
> > > a. The $(PHASE_) stuff in Makefiles
> > > b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> > >
> > > and you believe that
> > >
> > > c. the ambiguity I mentioned with CONFIG_FOO
> > >
> > > are all actually a good thing?
> >
> > No. I'm saying that what we have today is LESS confusing than your
> > proposal in splc-working. I can't evaluate splg-working because it
> > doesn't work enough to be clear if it does or doesn't still solve all
> > the problems that splc-working does. Various things don't build anymore
> > in splg-working and T2080RDB_NAND as a first example (as the powerpc
> > part of the world build failed first) has massive size changes.
> >
> > I do not like splc-working, but splc-working is a few bugs away from 1:1
> > functional binaries from before your changes.
> >
> > I do not like what we have today because it's tricky to get things
> > right. But the macros are visible in the code / Makefiles so humans
> > still find things.
>
> OK, well I am still lost, sorry.
>
> We are trying to discuss a change to how CONFIG options are handled in
> the source tree. It sounds like you are saying that you cannot review
> it until it fully works. But you already did that two years ago and
> rejected it. So I don't see any way forward here. Do you?

It would help me if you could go back to the original proposal I sent
and say which things you want / don't want.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 51301 bytes --]

On Fri, Feb 14, 2025 at 06:43:30PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 14 Feb 2025 at 18:14, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > > > possibility.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > > > platform(s?).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > > > desirable.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > >         select SPL
> > > > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > >         select CLK
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This would become:
> > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > > > >         ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > > > >
> > > > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > > > >
> > > > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > > > >
> > > > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > > > >
> > > > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > > > menu.
> > > > > > > > > > > >
> > > > > > > > > > > > > Mind generates
> > > > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > > > rules anymore.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > > > >
> > > > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > > > >
> > > > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > > > upstream).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > > > >
> > > > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > > > project IMO.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > > > PPL in the interim.
> > > > > > > > > > > >
> > > > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > > > existing Kconfig.
> > > > > > > > > > > >
> > > > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > > > divergence.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > > > reject any future changes I send
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > > > >
> > > > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > > > teach the build to combine images
> > > > > > > > > > > >
> > > > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > > > >
> > > > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > > > that large.
> > > > > > > > > > >
> > > > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > > > understanding each other.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes.
> > > > > > > > > > > >
> > > > > > > > > > > > Well, with that, what now?
> > > > > > > > > > > >
> > > > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > > > how we build things, have I?
> > > > > > > > > > >
> > > > > > > > > > > Which VPL thing?
> > > > > > > > > >
> > > > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > > > changes).
> > > > > > > > >
> > > > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > > > >
> > > > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > > > >
> > > > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > > > the two options?
> > > > > > > > > >
> > > > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > > > too.
> > > > > > > > > >
> > > > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > > > #endif
> > > > > > > >
> > > > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > > > morning was similar but different.
> > > > > > > >
> > > > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > > > in to more, but wasn't that symbol:
> > > > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > > > >                  function                                   old     new   delta
> > > > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > > > >
> > > > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > > > core issues with the approach as implemented.
> > > > > > > > >
> > > > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > > > >
> > > > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > > > both schemes.
> > > > > > > > >
> > > > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > > > if you are keen.
> > > > > > > >
> > > > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > > > default.
> > > > > > >
> > > > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > > > symbols, with both schemes.
> > > > > >
> > > > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > > > there is pain in saying that we need to list
> > > > > > config PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > config SPL_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > config TPL_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > config VPL_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > >
> > > > > > In what I'm saying it's not generally an issue because:
> > > > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > > > 21
> > > > > >
> > > > > > And we don't have to do additional upkeep on having N symbols.
> > > > >
> > > > > Well we only need to add those extra symbols if 1) we want that
> > > > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> > > >
> > > > Yes, and the problem is adding more of them. Again, we would need to
> > > > duplicate drivers/usb/gadget/Kconfig with your scheme.
> > > >
> > > > > There is nothing in my scheme which requires us to add options that
> > > > > don't currently exist...but there is a problem if some code uses
> > > > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> > > >
> > > > That's good because that wasn't (how it seemed?) previously.
> > > >
> > > > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > > > again, if we are using both, then who knows what it means today, and
> > > > > I'd like to clean it up.
> > > >
> > > > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > > > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > > > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > > > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > > > what it says.
> > > >
> > > > > > > > On the one hand, this is at least a well defined technical
> > > > > > > > problem and if you do the language extension *first* the code changes
> > > > > > > > aren't so bad.
> > > > > > >
> > > > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > > > conf_nospl file. The language extension is quite separate.
> > > > > >
> > > > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > > > \
> > > > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > And that is largely duplication of existing symbols. And again, it
> > > > > > wasn't enough duplication.
> > > > >
> > > > > I wonder if that is stuff that was already applied? Here is what I have today.
> > > > >
> > > > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > >  0 files changed
> > > > >
> > > > > You can use the u-boot-dm/splg-working tree to see the original
> > > > > version. From memory, the splc tree is very old and was mostly applied
> > > > > or dropped.
> > > >
> > > > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > > > I was comparing with. If you were able to drop some of the problems,
> > > > that's good.
> > > >
> > > > > > > > But for the user running menuconfig / etc? That's not
> > > > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > > > >
> > > > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > > > confusion and may increase it (why do I need to set
> > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > > > >
> > > > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > > > build, which in fact is what we have been using for years.
> > > > > >
> > > > > > And it's no longer clear in the code, is the problem.
> > > > > >
> > > > > > >
> > > > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > > > >
> > > > > > > Not relevant to the discussion, IMO.
> > > > > >
> > > > > > It's an example symbol. Why does the code have:
> > > > > >
> > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > ...
> > > > > > #endif
> > > > > >
> > > > > > And that's true for SPL builds. But the code also still has:
> > > > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > > > ...
> > > > > > #endif
> > > > > >
> > > > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > > > >
> > > > > OK I think I understand your question. The tools work by identifying
> > > > > options which are in PPL and may or not be in other builds. There is
> > > > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> > > >
> > > > No, you entirely misunderstand me. I am not talking about the tool. I am
> > > > talking about the developer.
> > > >
> > > > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > > > then the discussion would be different.
> > > > >
> > > > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > > > similar.
> > > >
> > > > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > > > you want to file an issue for it, please do. But that (roughly) is why
> > > > there's SPL_FRAMEWORK.
> > > >
> > > > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > > > .config / defconfig.
> > > > > > >
> > > > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > > > >
> > > > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > > > which is at least a hint that one needs to look harder, and oh,
> > > > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > > > >
> > > > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > > > agree, sorry. That is problems a-c in my original proposal and my
> > > > > understanding is that both our approaches resolve this problem.
> > > > >
> > > > > Otherwise, you've just lost me and we should probably give up on this point.
> > > >
> > > > Yes, I am saying that what we have today is less confusing than what you
> > > > are proposing. Because with your proposal:
> > > >
> > > > obj-$(CONFIG_FS_FAT) += fat/
> > > >
> > > > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > > > is not good for humans.
> > >
> > > Let's just stop on this point. We seem to be going backwards. Now you
> > > are saying that you *want* to keep:
> > >
> > > a. The $(PHASE_) stuff in Makefiles
> > > b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> > >
> > > and you believe that
> > >
> > > c. the ambiguity I mentioned with CONFIG_FOO
> > >
> > > are all actually a good thing?
> >
> > No. I'm saying that what we have today is LESS confusing than your
> > proposal in splc-working. I can't evaluate splg-working because it
> > doesn't work enough to be clear if it does or doesn't still solve all
> > the problems that splc-working does. Various things don't build anymore
> > in splg-working and T2080RDB_NAND as a first example (as the powerpc
> > part of the world build failed first) has massive size changes.
> >
> > I do not like splc-working, but splc-working is a few bugs away from 1:1
> > functional binaries from before your changes.
> >
> > I do not like what we have today because it's tricky to get things
> > right. But the macros are visible in the code / Makefiles so humans
> > still find things.
> 
> OK, well I am still lost, sorry.

OK, in splc-working what is untenable to me is that the following line
in a Makefile:
obj-$(CONFIG_FS_FAT) += fat/

Is unclear if it refers to PPL or some xPL. This is worse for humans
than what we have today.

> We are trying to discuss a change to how CONFIG options are handled in
> the source tree. It sounds like you are saying that you cannot review
> it until it fully works. But you already did that two years ago and

I cannot comment on what's in splg-working, which is also about two
years old, because while it has the same problem I object to above with
splc-working, it looks like you just dropped adding Kconfig symbols from
splc-working and showing that well actually some number of those symbols
were needed afterall.

> rejected it. So I don't see any way forward here. Do you?

Well, I'm once again back to wondering if you ever plan to stop having
your own downstream fork and so how much effort I should even put in
again.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Mon, 17 Feb 2025 at 07:20, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 14, 2025 at 06:43:30PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 14 Feb 2025 at 18:14, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > > > > possibility.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > > > > platform(s?).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > > > > desirable.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > >         select SPL
> > > > > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > >         select CLK
> > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This would become:
> > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > > > > >
> > > > > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > > > > >
> > > > > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > > > > menu.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Mind generates
> > > > > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > > > > rules anymore.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > > > > upstream).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > > > > project IMO.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > > > > PPL in the interim.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > > > > existing Kconfig.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > > > > divergence.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > > > > reject any future changes I send
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > > > > teach the build to combine images
> > > > > > > > > > > > >
> > > > > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > > > > >
> > > > > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > > > > that large.
> > > > > > > > > > > >
> > > > > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > > > > understanding each other.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Well, with that, what now?
> > > > > > > > > > > > >
> > > > > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > > > > how we build things, have I?
> > > > > > > > > > > >
> > > > > > > > > > > > Which VPL thing?
> > > > > > > > > > >
> > > > > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > > > > changes).
> > > > > > > > > >
> > > > > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > > > > >
> > > > > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > > > > the two options?
> > > > > > > > > > >
> > > > > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > > > > too.
> > > > > > > > > > >
> > > > > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > > > > #endif
> > > > > > > > >
> > > > > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > > > > morning was similar but different.
> > > > > > > > >
> > > > > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > > > > in to more, but wasn't that symbol:
> > > > > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > > > > >                  function                                   old     new   delta
> > > > > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > > > > >
> > > > > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > > > > core issues with the approach as implemented.
> > > > > > > > > >
> > > > > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > > > > >
> > > > > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > > > > both schemes.
> > > > > > > > > >
> > > > > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > > > > if you are keen.
> > > > > > > > >
> > > > > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > > > > default.
> > > > > > > >
> > > > > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > > > > symbols, with both schemes.
> > > > > > >
> > > > > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > > > > there is pain in saying that we need to list
> > > > > > > config PARTITION_TYPE_GUID
> > > > > > > ...
> > > > > > > config SPL_PARTITION_TYPE_GUID
> > > > > > > ...
> > > > > > > config TPL_PARTITION_TYPE_GUID
> > > > > > > ...
> > > > > > > config VPL_PARTITION_TYPE_GUID
> > > > > > > ...
> > > > > > >
> > > > > > > In what I'm saying it's not generally an issue because:
> > > > > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > > > > 21
> > > > > > >
> > > > > > > And we don't have to do additional upkeep on having N symbols.
> > > > > >
> > > > > > Well we only need to add those extra symbols if 1) we want that
> > > > > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> > > > >
> > > > > Yes, and the problem is adding more of them. Again, we would need to
> > > > > duplicate drivers/usb/gadget/Kconfig with your scheme.
> > > > >
> > > > > > There is nothing in my scheme which requires us to add options that
> > > > > > don't currently exist...but there is a problem if some code uses
> > > > > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> > > > >
> > > > > That's good because that wasn't (how it seemed?) previously.
> > > > >
> > > > > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > > > > again, if we are using both, then who knows what it means today, and
> > > > > > I'd like to clean it up.
> > > > >
> > > > > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > > > > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > > > > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > > > > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > > > > what it says.
> > > > >
> > > > > > > > > On the one hand, this is at least a well defined technical
> > > > > > > > > problem and if you do the language extension *first* the code changes
> > > > > > > > > aren't so bad.
> > > > > > > >
> > > > > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > > > > conf_nospl file. The language extension is quite separate.
> > > > > > >
> > > > > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > > > > \
> > > > > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > And that is largely duplication of existing symbols. And again, it
> > > > > > > wasn't enough duplication.
> > > > > >
> > > > > > I wonder if that is stuff that was already applied? Here is what I have today.
> > > > > >
> > > > > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > >  0 files changed
> > > > > >
> > > > > > You can use the u-boot-dm/splg-working tree to see the original
> > > > > > version. From memory, the splc tree is very old and was mostly applied
> > > > > > or dropped.
> > > > >
> > > > > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > > > > I was comparing with. If you were able to drop some of the problems,
> > > > > that's good.
> > > > >
> > > > > > > > > But for the user running menuconfig / etc? That's not
> > > > > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > > > > >
> > > > > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > > > > confusion and may increase it (why do I need to set
> > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > > > > >
> > > > > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > > > > build, which in fact is what we have been using for years.
> > > > > > >
> > > > > > > And it's no longer clear in the code, is the problem.
> > > > > > >
> > > > > > > >
> > > > > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > > > > >
> > > > > > > > Not relevant to the discussion, IMO.
> > > > > > >
> > > > > > > It's an example symbol. Why does the code have:
> > > > > > >
> > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > ...
> > > > > > > #endif
> > > > > > >
> > > > > > > And that's true for SPL builds. But the code also still has:
> > > > > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > > > > ...
> > > > > > > #endif
> > > > > > >
> > > > > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > > > > >
> > > > > > OK I think I understand your question. The tools work by identifying
> > > > > > options which are in PPL and may or not be in other builds. There is
> > > > > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> > > > >
> > > > > No, you entirely misunderstand me. I am not talking about the tool. I am
> > > > > talking about the developer.
> > > > >
> > > > > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > > > > then the discussion would be different.
> > > > > >
> > > > > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > > > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > > > > similar.
> > > > >
> > > > > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > > > > you want to file an issue for it, please do. But that (roughly) is why
> > > > > there's SPL_FRAMEWORK.
> > > > >
> > > > > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > > > > .config / defconfig.
> > > > > > > >
> > > > > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > > > > >
> > > > > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > > > > which is at least a hint that one needs to look harder, and oh,
> > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > > > > >
> > > > > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > > > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > > > > agree, sorry. That is problems a-c in my original proposal and my
> > > > > > understanding is that both our approaches resolve this problem.
> > > > > >
> > > > > > Otherwise, you've just lost me and we should probably give up on this point.
> > > > >
> > > > > Yes, I am saying that what we have today is less confusing than what you
> > > > > are proposing. Because with your proposal:
> > > > >
> > > > > obj-$(CONFIG_FS_FAT) += fat/
> > > > >
> > > > > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > > > > is not good for humans.
> > > >
> > > > Let's just stop on this point. We seem to be going backwards. Now you
> > > > are saying that you *want* to keep:
> > > >
> > > > a. The $(PHASE_) stuff in Makefiles
> > > > b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> > > >
> > > > and you believe that
> > > >
> > > > c. the ambiguity I mentioned with CONFIG_FOO
> > > >
> > > > are all actually a good thing?
> > >
> > > No. I'm saying that what we have today is LESS confusing than your
> > > proposal in splc-working. I can't evaluate splg-working because it
> > > doesn't work enough to be clear if it does or doesn't still solve all
> > > the problems that splc-working does. Various things don't build anymore
> > > in splg-working and T2080RDB_NAND as a first example (as the powerpc
> > > part of the world build failed first) has massive size changes.
> > >
> > > I do not like splc-working, but splc-working is a few bugs away from 1:1
> > > functional binaries from before your changes.
> > >
> > > I do not like what we have today because it's tricky to get things
> > > right. But the macros are visible in the code / Makefiles so humans
> > > still find things.
> >
> > OK, well I am still lost, sorry.
>
> OK, in splc-working what is untenable to me is that the following line
> in a Makefile:
> obj-$(CONFIG_FS_FAT) += fat/
>
> Is unclear if it refers to PPL or some xPL. This is worse for humans
> than what we have today.

We're really heading in completely different directions then.

At the moment, if we have:

obj-$(CONFIG_FOO) += foo/

we know this is used in all builds. If we have:

obj-$(CONFIG_$(PHASE_)FOO) += foo/

then we have to look at Kconfig to figure that out.

My change makes it entirely dependent on Kconfig, in both cases.

For source code, we can have both CONFIG_FOO and
CONFIG_IS_ENABLED(FOO), so again Kconfig does not control things. It
is merely a hint.

To my mind, $(PHASE_) and CONFIG_IS_ENABLED() are hacks, to work
around the unified config, which I want to split.

>
> > We are trying to discuss a change to how CONFIG options are handled in
> > the source tree. It sounds like you are saying that you cannot review
> > it until it fully works. But you already did that two years ago and
>
> I cannot comment on what's in splg-working, which is also about two
> years old, because while it has the same problem I object to above with
> splc-working, it looks like you just dropped adding Kconfig symbols from
> splc-working and showing that well actually some number of those symbols
> were needed afterall.

That could well be true.

>
> > rejected it. So I don't see any way forward here. Do you?
>
> Well, I'm once again back to wondering if you ever plan to stop having
> your own downstream fork and so how much effort I should even put in
> again.

My plan is to run it for a year and then review it.  The more effort
we put in, the less the delta, which is why I am sending patches out
and responding to feedback.

Regards,
SImon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 56155 bytes --]

On Mon, Feb 17, 2025 at 08:08:58AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 17 Feb 2025 at 07:20, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 14, 2025 at 06:43:30PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 14 Feb 2025 at 18:14, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > > > > > possibility.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > > > > > platform(s?).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > > > > > desirable.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > > >         select SPL
> > > > > > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > >         select CLK
> > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This would become:
> > > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > > > > > menu.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Mind generates
> > > > > > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > > > > > rules anymore.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > > > > > upstream).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > > > > > project IMO.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > > > > > PPL in the interim.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > > > > > existing Kconfig.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > > > > > divergence.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > > > > > reject any future changes I send
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > > > > > teach the build to combine images
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > > > > > >
> > > > > > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > > > > > that large.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > > > > > understanding each other.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Well, with that, what now?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > > > > > how we build things, have I?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Which VPL thing?
> > > > > > > > > > > >
> > > > > > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > > > > > changes).
> > > > > > > > > > >
> > > > > > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > > > > > the two options?
> > > > > > > > > > > >
> > > > > > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > > > > > too.
> > > > > > > > > > > >
> > > > > > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > > > > > #endif
> > > > > > > > > >
> > > > > > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > > > > > morning was similar but different.
> > > > > > > > > >
> > > > > > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > > > > > in to more, but wasn't that symbol:
> > > > > > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > > > > > >                  function                                   old     new   delta
> > > > > > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > > > > > >
> > > > > > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > > > > > core issues with the approach as implemented.
> > > > > > > > > > >
> > > > > > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > > > > > >
> > > > > > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > > > > > both schemes.
> > > > > > > > > > >
> > > > > > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > > > > > if you are keen.
> > > > > > > > > >
> > > > > > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > > > > > default.
> > > > > > > > >
> > > > > > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > > > > > symbols, with both schemes.
> > > > > > > >
> > > > > > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > > > > > there is pain in saying that we need to list
> > > > > > > > config PARTITION_TYPE_GUID
> > > > > > > > ...
> > > > > > > > config SPL_PARTITION_TYPE_GUID
> > > > > > > > ...
> > > > > > > > config TPL_PARTITION_TYPE_GUID
> > > > > > > > ...
> > > > > > > > config VPL_PARTITION_TYPE_GUID
> > > > > > > > ...
> > > > > > > >
> > > > > > > > In what I'm saying it's not generally an issue because:
> > > > > > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > > > > > 21
> > > > > > > >
> > > > > > > > And we don't have to do additional upkeep on having N symbols.
> > > > > > >
> > > > > > > Well we only need to add those extra symbols if 1) we want that
> > > > > > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> > > > > >
> > > > > > Yes, and the problem is adding more of them. Again, we would need to
> > > > > > duplicate drivers/usb/gadget/Kconfig with your scheme.
> > > > > >
> > > > > > > There is nothing in my scheme which requires us to add options that
> > > > > > > don't currently exist...but there is a problem if some code uses
> > > > > > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> > > > > >
> > > > > > That's good because that wasn't (how it seemed?) previously.
> > > > > >
> > > > > > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > > > > > again, if we are using both, then who knows what it means today, and
> > > > > > > I'd like to clean it up.
> > > > > >
> > > > > > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > > > > > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > > > > > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > > > > > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > > > > > what it says.
> > > > > >
> > > > > > > > > > On the one hand, this is at least a well defined technical
> > > > > > > > > > problem and if you do the language extension *first* the code changes
> > > > > > > > > > aren't so bad.
> > > > > > > > >
> > > > > > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > > > > > conf_nospl file. The language extension is quite separate.
> > > > > > > >
> > > > > > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > > > > > \
> > > > > > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > And that is largely duplication of existing symbols. And again, it
> > > > > > > > wasn't enough duplication.
> > > > > > >
> > > > > > > I wonder if that is stuff that was already applied? Here is what I have today.
> > > > > > >
> > > > > > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > > >  0 files changed
> > > > > > >
> > > > > > > You can use the u-boot-dm/splg-working tree to see the original
> > > > > > > version. From memory, the splc tree is very old and was mostly applied
> > > > > > > or dropped.
> > > > > >
> > > > > > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > > > > > I was comparing with. If you were able to drop some of the problems,
> > > > > > that's good.
> > > > > >
> > > > > > > > > > But for the user running menuconfig / etc? That's not
> > > > > > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > > > > > >
> > > > > > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > > > > > confusion and may increase it (why do I need to set
> > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > > > > > >
> > > > > > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > > > > > build, which in fact is what we have been using for years.
> > > > > > > >
> > > > > > > > And it's no longer clear in the code, is the problem.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > > > > > >
> > > > > > > > > Not relevant to the discussion, IMO.
> > > > > > > >
> > > > > > > > It's an example symbol. Why does the code have:
> > > > > > > >
> > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > ...
> > > > > > > > #endif
> > > > > > > >
> > > > > > > > And that's true for SPL builds. But the code also still has:
> > > > > > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > > > > > ...
> > > > > > > > #endif
> > > > > > > >
> > > > > > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > > > > > >
> > > > > > > OK I think I understand your question. The tools work by identifying
> > > > > > > options which are in PPL and may or not be in other builds. There is
> > > > > > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> > > > > >
> > > > > > No, you entirely misunderstand me. I am not talking about the tool. I am
> > > > > > talking about the developer.
> > > > > >
> > > > > > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > > > > > then the discussion would be different.
> > > > > > >
> > > > > > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > > > > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > > > > > similar.
> > > > > >
> > > > > > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > > > > > you want to file an issue for it, please do. But that (roughly) is why
> > > > > > there's SPL_FRAMEWORK.
> > > > > >
> > > > > > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > > > > > .config / defconfig.
> > > > > > > > >
> > > > > > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > > > > > >
> > > > > > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > > > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > > > > > which is at least a hint that one needs to look harder, and oh,
> > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > > > > > >
> > > > > > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > > > > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > > > > > agree, sorry. That is problems a-c in my original proposal and my
> > > > > > > understanding is that both our approaches resolve this problem.
> > > > > > >
> > > > > > > Otherwise, you've just lost me and we should probably give up on this point.
> > > > > >
> > > > > > Yes, I am saying that what we have today is less confusing than what you
> > > > > > are proposing. Because with your proposal:
> > > > > >
> > > > > > obj-$(CONFIG_FS_FAT) += fat/
> > > > > >
> > > > > > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > > > > > is not good for humans.
> > > > >
> > > > > Let's just stop on this point. We seem to be going backwards. Now you
> > > > > are saying that you *want* to keep:
> > > > >
> > > > > a. The $(PHASE_) stuff in Makefiles
> > > > > b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> > > > >
> > > > > and you believe that
> > > > >
> > > > > c. the ambiguity I mentioned with CONFIG_FOO
> > > > >
> > > > > are all actually a good thing?
> > > >
> > > > No. I'm saying that what we have today is LESS confusing than your
> > > > proposal in splc-working. I can't evaluate splg-working because it
> > > > doesn't work enough to be clear if it does or doesn't still solve all
> > > > the problems that splc-working does. Various things don't build anymore
> > > > in splg-working and T2080RDB_NAND as a first example (as the powerpc
> > > > part of the world build failed first) has massive size changes.
> > > >
> > > > I do not like splc-working, but splc-working is a few bugs away from 1:1
> > > > functional binaries from before your changes.
> > > >
> > > > I do not like what we have today because it's tricky to get things
> > > > right. But the macros are visible in the code / Makefiles so humans
> > > > still find things.
> > >
> > > OK, well I am still lost, sorry.
> >
> > OK, in splc-working what is untenable to me is that the following line
> > in a Makefile:
> > obj-$(CONFIG_FS_FAT) += fat/
> >
> > Is unclear if it refers to PPL or some xPL. This is worse for humans
> > than what we have today.
> 
> We're really heading in completely different directions then.
> 
> At the moment, if we have:
> 
> obj-$(CONFIG_FOO) += foo/
> 
> we know this is used in all builds. If we have:
> 
> obj-$(CONFIG_$(PHASE_)FOO) += foo/
> 
> then we have to look at Kconfig to figure that out.
> 
> My change makes it entirely dependent on Kconfig, in both cases.
> 
> For source code, we can have both CONFIG_FOO and
> CONFIG_IS_ENABLED(FOO), so again Kconfig does not control things. It
> is merely a hint.
> 
> To my mind, $(PHASE_) and CONFIG_IS_ENABLED() are hacks, to work
> around the unified config, which I want to split.

This is why we need a TSC. I think $(PHASE_) and CONFIG_IS_ENABLED() are
better than having to remember that CONFIG_SPL_FOO is no longer a
meaningful value (CONFIG_SPL_FS_FAT), except when it is a meaningful
value (CONFIG_SPL_TEXT_BASE). You disagree. We've both presented our
technical reasoning and neither of us seems swayed to go another
direction instead. You are also unwilling to accept my No as the head of
the project.

> > > We are trying to discuss a change to how CONFIG options are handled in
> > > the source tree. It sounds like you are saying that you cannot review
> > > it until it fully works. But you already did that two years ago and
> >
> > I cannot comment on what's in splg-working, which is also about two
> > years old, because while it has the same problem I object to above with
> > splc-working, it looks like you just dropped adding Kconfig symbols from
> > splc-working and showing that well actually some number of those symbols
> > were needed afterall.
> 
> That could well be true.
> 
> >
> > > rejected it. So I don't see any way forward here. Do you?
> >
> > Well, I'm once again back to wondering if you ever plan to stop having
> > your own downstream fork and so how much effort I should even put in
> > again.
> 
> My plan is to run it for a year and then review it.  The more effort
> we put in, the less the delta, which is why I am sending patches out
> and responding to feedback.

So you want to run a downstream fork for a year, and then what? How can
I get you to stop? Or convince you to just hard fork and give the domain
to the project? As I do not see how this gets better in a year unless
you expect your tree to just become mainline.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Mon, 17 Feb 2025 at 08:59, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Feb 17, 2025 at 08:08:58AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 17 Feb 2025 at 07:20, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 14, 2025 at 06:43:30PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 14 Feb 2025 at 18:14, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > > > > > > possibility.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > > > > > > platform(s?).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > > > > > > desirable.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > > > >         select SPL
> > > > > > > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > > >         select CLK
> > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This would become:
> > > > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > > > > > > menu.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Mind generates
> > > > > > > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > > > > > > rules anymore.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > > > > > > upstream).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > > > > > > project IMO.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > > > > > > PPL in the interim.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > > > > > > existing Kconfig.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > > > > > > divergence.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > > > > > > reject any future changes I send
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > > > > > > teach the build to combine images
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > > > > > > that large.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > > > > > > understanding each other.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Well, with that, what now?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > > > > > > how we build things, have I?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Which VPL thing?
> > > > > > > > > > > > >
> > > > > > > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > > > > > > changes).
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > > > > > > the two options?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > > > > > > too.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > > > > > > #endif
> > > > > > > > > > >
> > > > > > > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > > > > > > morning was similar but different.
> > > > > > > > > > >
> > > > > > > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > > > > > > in to more, but wasn't that symbol:
> > > > > > > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > > > > > > >                  function                                   old     new   delta
> > > > > > > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > > > > > > >
> > > > > > > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > > > > > > core issues with the approach as implemented.
> > > > > > > > > > > >
> > > > > > > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > > > > > > >
> > > > > > > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > > > > > > both schemes.
> > > > > > > > > > > >
> > > > > > > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > > > > > > if you are keen.
> > > > > > > > > > >
> > > > > > > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > > > > > > default.
> > > > > > > > > >
> > > > > > > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > > > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > > > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > > > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > > > > > > symbols, with both schemes.
> > > > > > > > >
> > > > > > > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > > > > > > there is pain in saying that we need to list
> > > > > > > > > config PARTITION_TYPE_GUID
> > > > > > > > > ...
> > > > > > > > > config SPL_PARTITION_TYPE_GUID
> > > > > > > > > ...
> > > > > > > > > config TPL_PARTITION_TYPE_GUID
> > > > > > > > > ...
> > > > > > > > > config VPL_PARTITION_TYPE_GUID
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > In what I'm saying it's not generally an issue because:
> > > > > > > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > > > > > > 21
> > > > > > > > >
> > > > > > > > > And we don't have to do additional upkeep on having N symbols.
> > > > > > > >
> > > > > > > > Well we only need to add those extra symbols if 1) we want that
> > > > > > > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> > > > > > >
> > > > > > > Yes, and the problem is adding more of them. Again, we would need to
> > > > > > > duplicate drivers/usb/gadget/Kconfig with your scheme.
> > > > > > >
> > > > > > > > There is nothing in my scheme which requires us to add options that
> > > > > > > > don't currently exist...but there is a problem if some code uses
> > > > > > > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> > > > > > >
> > > > > > > That's good because that wasn't (how it seemed?) previously.
> > > > > > >
> > > > > > > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > > > > > > again, if we are using both, then who knows what it means today, and
> > > > > > > > I'd like to clean it up.
> > > > > > >
> > > > > > > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > > > > > > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > > > > > > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > > > > > > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > > > > > > what it says.
> > > > > > >
> > > > > > > > > > > On the one hand, this is at least a well defined technical
> > > > > > > > > > > problem and if you do the language extension *first* the code changes
> > > > > > > > > > > aren't so bad.
> > > > > > > > > >
> > > > > > > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > > > > > > conf_nospl file. The language extension is quite separate.
> > > > > > > > >
> > > > > > > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > > > > > > \
> > > > > > > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > > > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > > > > > > >
> > > > > > > > > And that is largely duplication of existing symbols. And again, it
> > > > > > > > > wasn't enough duplication.
> > > > > > > >
> > > > > > > > I wonder if that is stuff that was already applied? Here is what I have today.
> > > > > > > >
> > > > > > > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > > > >  0 files changed
> > > > > > > >
> > > > > > > > You can use the u-boot-dm/splg-working tree to see the original
> > > > > > > > version. From memory, the splc tree is very old and was mostly applied
> > > > > > > > or dropped.
> > > > > > >
> > > > > > > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > > > > > > I was comparing with. If you were able to drop some of the problems,
> > > > > > > that's good.
> > > > > > >
> > > > > > > > > > > But for the user running menuconfig / etc? That's not
> > > > > > > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > > > > > > >
> > > > > > > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > > > > > > confusion and may increase it (why do I need to set
> > > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > > > > > > >
> > > > > > > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > > > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > > > > > > build, which in fact is what we have been using for years.
> > > > > > > > >
> > > > > > > > > And it's no longer clear in the code, is the problem.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > > > > > > >
> > > > > > > > > > Not relevant to the discussion, IMO.
> > > > > > > > >
> > > > > > > > > It's an example symbol. Why does the code have:
> > > > > > > > >
> > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > ...
> > > > > > > > > #endif
> > > > > > > > >
> > > > > > > > > And that's true for SPL builds. But the code also still has:
> > > > > > > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > > > > > > ...
> > > > > > > > > #endif
> > > > > > > > >
> > > > > > > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > > > > > > >
> > > > > > > > OK I think I understand your question. The tools work by identifying
> > > > > > > > options which are in PPL and may or not be in other builds. There is
> > > > > > > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> > > > > > >
> > > > > > > No, you entirely misunderstand me. I am not talking about the tool. I am
> > > > > > > talking about the developer.
> > > > > > >
> > > > > > > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > > > > > > then the discussion would be different.
> > > > > > > >
> > > > > > > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > > > > > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > > > > > > similar.
> > > > > > >
> > > > > > > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > > > > > > you want to file an issue for it, please do. But that (roughly) is why
> > > > > > > there's SPL_FRAMEWORK.
> > > > > > >
> > > > > > > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > > > > > > .config / defconfig.
> > > > > > > > > >
> > > > > > > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > > > > > > >
> > > > > > > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > > > > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > > > > > > which is at least a hint that one needs to look harder, and oh,
> > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > > > > > > >
> > > > > > > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > > > > > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > > > > > > agree, sorry. That is problems a-c in my original proposal and my
> > > > > > > > understanding is that both our approaches resolve this problem.
> > > > > > > >
> > > > > > > > Otherwise, you've just lost me and we should probably give up on this point.
> > > > > > >
> > > > > > > Yes, I am saying that what we have today is less confusing than what you
> > > > > > > are proposing. Because with your proposal:
> > > > > > >
> > > > > > > obj-$(CONFIG_FS_FAT) += fat/
> > > > > > >
> > > > > > > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > > > > > > is not good for humans.
> > > > > >
> > > > > > Let's just stop on this point. We seem to be going backwards. Now you
> > > > > > are saying that you *want* to keep:
> > > > > >
> > > > > > a. The $(PHASE_) stuff in Makefiles
> > > > > > b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> > > > > >
> > > > > > and you believe that
> > > > > >
> > > > > > c. the ambiguity I mentioned with CONFIG_FOO
> > > > > >
> > > > > > are all actually a good thing?
> > > > >
> > > > > No. I'm saying that what we have today is LESS confusing than your
> > > > > proposal in splc-working. I can't evaluate splg-working because it
> > > > > doesn't work enough to be clear if it does or doesn't still solve all
> > > > > the problems that splc-working does. Various things don't build anymore
> > > > > in splg-working and T2080RDB_NAND as a first example (as the powerpc
> > > > > part of the world build failed first) has massive size changes.
> > > > >
> > > > > I do not like splc-working, but splc-working is a few bugs away from 1:1
> > > > > functional binaries from before your changes.
> > > > >
> > > > > I do not like what we have today because it's tricky to get things
> > > > > right. But the macros are visible in the code / Makefiles so humans
> > > > > still find things.
> > > >
> > > > OK, well I am still lost, sorry.
> > >
> > > OK, in splc-working what is untenable to me is that the following line
> > > in a Makefile:
> > > obj-$(CONFIG_FS_FAT) += fat/
> > >
> > > Is unclear if it refers to PPL or some xPL. This is worse for humans
> > > than what we have today.
> >
> > We're really heading in completely different directions then.
> >
> > At the moment, if we have:
> >
> > obj-$(CONFIG_FOO) += foo/
> >
> > we know this is used in all builds. If we have:
> >
> > obj-$(CONFIG_$(PHASE_)FOO) += foo/
> >
> > then we have to look at Kconfig to figure that out.
> >
> > My change makes it entirely dependent on Kconfig, in both cases.
> >
> > For source code, we can have both CONFIG_FOO and
> > CONFIG_IS_ENABLED(FOO), so again Kconfig does not control things. It
> > is merely a hint.
> >
> > To my mind, $(PHASE_) and CONFIG_IS_ENABLED() are hacks, to work
> > around the unified config, which I want to split.
>
> This is why we need a TSC. I think $(PHASE_) and CONFIG_IS_ENABLED() are
> better than having to remember that CONFIG_SPL_FOO is no longer a
> meaningful value (CONFIG_SPL_FS_FAT), except when it is a meaningful
> value (CONFIG_SPL_TEXT_BASE). You disagree. We've both presented our
> technical reasoning and neither of us seems swayed to go another
> direction instead. You are also unwilling to accept my No as the head of
> the project.

But I still don't really understand what you want here. You say that
you want completly separate defconfig files for each phase, with kconf
running once for each. So I assumed that the .config files so produced
would just have CONFIG_FOO in them, not CONFIG_SPL_FOO (for example).
Is that right?

Or are you saying that the .config.spl file will have CONFIG_SPL_FOO,
i.e. insert an SPL_ into every option?

Or, perhaps, are you saying that the $(PHASE_) does nothing
(programmatically) with your scheme, just indicating to the user that
this is an option that might have different values for each phase?

Before giving up, I should at least try to understand what you are
actually getting at.

I accepted your No over two years ago and no one has come up with an
alternative series in the interim, so we have lost that time (and also
that work, since it took at lot of of effort to avoid behaviour
changes and much of it will need to be redone). I'd *really* like to
be able to add a new phase with just a few lines of Kconfig.

>
> > > > We are trying to discuss a change to how CONFIG options are handled in
> > > > the source tree. It sounds like you are saying that you cannot review
> > > > it until it fully works. But you already did that two years ago and
> > >
> > > I cannot comment on what's in splg-working, which is also about two
> > > years old, because while it has the same problem I object to above with
> > > splc-working, it looks like you just dropped adding Kconfig symbols from
> > > splc-working and showing that well actually some number of those symbols
> > > were needed afterall.
> >
> > That could well be true.
> >
> > >
> > > > rejected it. So I don't see any way forward here. Do you?
> > >
> > > Well, I'm once again back to wondering if you ever plan to stop having
> > > your own downstream fork and so how much effort I should even put in
> > > again.
> >
> > My plan is to run it for a year and then review it.  The more effort
> > we put in, the less the delta, which is why I am sending patches out
> > and responding to feedback.
>
> So you want to run a downstream fork for a year, and then what? How can
> I get you to stop? Or convince you to just hard fork and give the domain
> to the project? As I do not see how this gets better in a year unless
> you expect your tree to just become mainline.

So far I've been working with you and others on everything I've sent.
If that continues for this year, I won't need my tree.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 61934 bytes --]

On Mon, Feb 17, 2025 at 11:03:28AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 17 Feb 2025 at 08:59, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Feb 17, 2025 at 08:08:58AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 17 Feb 2025 at 07:20, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 14, 2025 at 06:43:30PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 14 Feb 2025 at 18:14, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 14 Feb 2025 at 16:43, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 14 Feb 2025 at 14:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 14, 2025, 07:39 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 13 Feb 2025 at 15:59, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Feb 13, 2025, 11:03 Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, Feb 13, 2025 at 05:50:13AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 01:05:11PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 10:41:45AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Tue, 11 Feb 2025 at 14:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > OK. No, TEXT_BASE is not a great example in my book either. But it is
> > > > > > > > > > > > > > > > > > > > > > > true that SPL needs to know U-Boot's text base.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Here's another:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > config SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > > > >    default SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > > > >    default y if SPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > config TPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > > > >    depends on TPL_SYS_MALLOC_F
> > > > > > > > > > > > > > > > > > > > > > >    default SPL_SYS_MALLOC_F_LEN
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Alternatively:
> > > > > > > > > > > > > > > > > > > > > > config SYS_MALLOC_LEN
> > > > > > > > > > > > > > > > > > > > > >    ... current default X if Y
> > > > > > > > > > > > > > > > > > > > > >    default 0x2800 if RCAR_GEN3 && !PPL
> > > > > > > > > > > > > > > > > > > > > >    default 0x2000 if IMX8MQ && !PPL
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > PPL means (in my book) that we have a PPL, i.e. it is always true. It
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > And in my proposal you're choosing between PPL, SPL, TPL, VPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > is the same today, with SPL. We have CONFIG_SPL_BUILD which indicates
> > > > > > > > > > > > > > > > > > > > > which build it is. If you are suggesting that SPL means that this is
> > > > > > > > > > > > > > > > > > > > > the SPL build, then which thing tells us whether or not we have an SPL
> > > > > > > > > > > > > > > > > > > > > build? I'm just a bit confused by this.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > And we wouldn't have CONFIG_SPL_BUILD because we would either be
> > > > > > > > > > > > > > > > > > > > configuring for SPL=y or SPL=n, there's no confusion anymore.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > But how can I make the TPL value of SYS_MALLOC_F_LEN the same as the
> > > > > > > > > > > > > > > > > > > > > SPL one, with your scheme?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If your question is "how do I set an arbitrary but consistent value in
> > > > > > > > > > > > > > > > > > > > SPL and SPL" that's not enforced. But they also shouldn't be arbitrary
> > > > > > > > > > > > > > > > > > > > and we should have sane defaults set in Kconfig, regardless of either
> > > > > > > > > > > > > > > > > > > > proposal. While I'm trying to not get lost in the details today we have
> > > > > > > > > > > > > > > > > > > > 80 matches on "git grep SPL_.*_LEN= configs/" and 2 for TPL and I would
> > > > > > > > > > > > > > > > > > > > encourage someone to verify those are needed. My initial recollection is
> > > > > > > > > > > > > > > > > > > > that most of these are from when we bumped SYS_MALLOC_F_LEN or so up to
> > > > > > > > > > > > > > > > > > > > the commonly used default and had the few platforms that didn't use the
> > > > > > > > > > > > > > > > > > > > new default previously switch to the old one.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > In other words, I don't think there's a problem here that isn't solved
> > > > > > > > > > > > > > > > > > > > today, outside of either proposal.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > So I'm still not understanding how you handle Kconfig dependencies
> > > > > > > > > > > > > > > > > > > > > between phases with your scheme. Are you saying you don't and they are
> > > > > > > > > > > > > > > > > > > > > not important?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Basically. The majority of the cases of:
> > > > > > > > > > > > > > > > > > > > config SPL_FOO
> > > > > > > > > > > > > > > > > > > >    default y if FOO
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > config TPL_FOO
> > > > > > > > > > > > > > > > > > > >    default y if SPL_FOO
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Just go away because FOO is already default y or select/imply'd by
> > > > > > > > > > > > > > > > > > > > TARGET_BAR or ARCH_BAZ.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Also, is there a single Kconfig tree for U-Boot, or are you saying you
> > > > > > > > > > > > > > > > > > > > > want a different set of Kconfig files for each phase?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Just the Kconfig files we have today. Likely with less overall lines
> > > > > > > > > > > > > > > > > > > > since for example we could drop:
> > > > > > > > > > > > > > > > > > > > config SPL_FS_EXT4
> > > > > > > > > > > > > > > > > > > >         bool "Support EXT filesystems"
> > > > > > > > > > > > > > > > > > > >         select SPL_CRC16 if EXT4_WRITE
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Since we already have fs/ext4/Kconfig.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > You've mentioned this quite a few times over the years. Is there a
> > > > > > > > > > > > > > > > > > > > > > > reference to what he suggested we should do? Or perhaps it is what you
> > > > > > > > > > > > > > > > > > > > > > > have below.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I don't recall what he proposed instead, just that when it became clear
> > > > > > > > > > > > > > > > > > > > > > that I wanted to move from the "S:CONFIG_FOO.." syntax for how SPL was
> > > > > > > > > > > > > > > > > > > > > > handled to how we're doing it today, he thought that was the wrong
> > > > > > > > > > > > > > > > > > > > > > direction.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Yes, IMO he was right about that.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Good idea.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > This means splitting the existing file into a separate one for each
> > > > > > > > > > > > > > > > > > > > > > > phase. I believe that will be hard to manage.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Do you mean initially, or long term? Initially, it should be a bit of
> > > > > > > > > > > > > > > > > > > > > > shell scripting. The consolidation (ie most/all rk3399 having an
> > > > > > > > > > > > > > > > > > > > > > identical _spl_defconfig) can't be automated. Long term I'm not sure it
> > > > > > > > > > > > > > > > > > > > > > would be any different. Most of the maintenance is on resync'ing which
> > > > > > > > > > > > > > > > > > > > > > is automated.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Long term. How does 'make menuconfig' work in this case? Won't you
> > > > > > > > > > > > > > > > > > > > > have to run it three times for SPL, TPL and PPL?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Yes, you would run configure for what you're building. This is a good
> > > > > > > > > > > > > > > > > > > > thing as it will no longer be so confusing to hunt down where SPL or TPL
> > > > > > > > > > > > > > > > > > > > or VPL options for a specific thing reside.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The scheme I propose removes a-c also. I should have made that clear.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Er, ok. That's not how it looked before, but I guess I'm just mistaken.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Yes I think so...it was a major goal to remove this stuff. [1] [2]
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > There is not a huge difference between your scheme and mine. My
> > > > > > > > > > > > > > > > > > > > > > > question is, how do you handle (d)?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Well, either (d) isn't important as for example MMC wasn't a good choice
> > > > > > > > > > > > > > > > > > > > > > in your proposal as virtually everyone "select MMC" today or it's
> > > > > > > > > > > > > > > > > > > > > > handled more easily as my example above in SYS_MALLOC_LEN.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > > > > > > > > > > > > > > > > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > > > > > > > > > > > > > > > > > > > Yours feels more like building independent U-Boot images.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > > > > > > > > > > > > > > > > > > > around "make all of the images for a given platform". So much of our
> > > > > > > > > > > > > > > > > > > > > > confusing and messy code is because we aren't doing that. And since most
> > > > > > > > > > > > > > > > > > > > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > > > > > > > > > > > > > > > > > > > we really could have fewer overall build configurations.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > > > > > > > > > > > > > > > > > > > would be quite large with all the drivers. Perhaps we could start by
> > > > > > > > > > > > > > > > > > > > > having a generic Rockchip one, for example.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Still I don't see this being strongly related to the discussion about
> > > > > > > > > > > > > > > > > > > > > these two different schemes.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Well, in your scheme how do we have say generic-aarch64_defconfig
> > > > > > > > > > > > > > > > > > > > function on either chromebook_bob or am62x_beagleplay_a53 ? In mine,
> > > > > > > > > > > > > > > > > > > > since everything is a separate build, generic-aarch64_defconfig has
> > > > > > > > > > > > > > > > > > > > PPL=y, ARCH_K3=y and ROCKCHIP_RK3399=y. And then
> > > > > > > > > > > > > > > > > > > > chromebook_bob_defconfig would say to use chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > > > > > generic-rk3399_spl_defconfig and generic-aarch64_defconfig. As a bonus
> > > > > > > > > > > > > > > > > > > > instead of am62x_beagleplay_a53_defconfig and
> > > > > > > > > > > > > > > > > > > > am62x_beagleplay_r5_defconfig we would have am62x_beagleplay_defconfig
> > > > > > > > > > > > > > > > > > > > that would say to use the appropriate SPL/PPL for R5, and appropriate
> > > > > > > > > > > > > > > > > > > > SPL/PPL for A53.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > But the one big huge caveat I want to make here is that "generic" images
> > > > > > > > > > > > > > > > > > > > are useful in some use cases (I'm sure all of the regular F/OSS
> > > > > > > > > > > > > > > > > > > > distributions would love a single actually common PPL if they can fit
> > > > > > > > > > > > > > > > > > > > it) will strip things down. Whatever the IoT edge device closest to you
> > > > > > > > > > > > > > > > > > > > now really won't want to ship with all the platforms enabled. Image size
> > > > > > > > > > > > > > > > > > > > still matters.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > OK thanks for the details. I think I have a reasonable idea of what
> > > > > > > > > > > > > > > > > > > you are proposing, now. It would work, but is quite radical, IMO.
> > > > > > > > > > > > > > > > > > > That's not necessarily a bad thing, but in my mind I see a sequencing
> > > > > > > > > > > > > > > > > > > possibility.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > A few points from my side:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. I would love to see the defconfig files reduce in size, with more
> > > > > > > > > > > > > > > > > > > and better defaults. One way to do this would be to enforce a maximum
> > > > > > > > > > > > > > > > > > > length. I added a feature to qconfig to allow finding common options
> > > > > > > > > > > > > > > > > > > among boards (the -i flag), but I'm not sure if many people use it.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't see reducing defconfig size as important honestly. Should we
> > > > > > > > > > > > > > > > > > have more and better defaults? Yes. But almost everything is under 200
> > > > > > > > > > > > > > > > > > lines with the biggest (non-sandbox) ones being the generic zynqmp
> > > > > > > > > > > > > > > > > > platform(s?).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 2. Generic boards is something I have been pushing for years (in fact
> > > > > > > > > > > > > > > > > > > it is why I originally introduced devicetree), but I'm not seeing a
> > > > > > > > > > > > > > > > > > > lot of traction.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't think generic boards are universally helpful. Even if what I'm
> > > > > > > > > > > > > > > > > > proposing would allow for more of it, below the PPL stage I'm not sure
> > > > > > > > > > > > > > > > > > it's both feasible enough and useful enough for production. At the PPL
> > > > > > > > > > > > > > > > > > stage it still has to be small enough and not overly burdensome. What we
> > > > > > > > > > > > > > > > > > talked about on the call yesterday about using more multi-dtb images is
> > > > > > > > > > > > > > > > > > a step in the right direction, yes.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Agreed. Anway, we can create separate targets for generic boards if we want to.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 3. Iit seems that you want to remove all the 'if SPL' pieces and just
> > > > > > > > > > > > > > > > > > > rely on the current PPL configuration. But how will that work? There
> > > > > > > > > > > > > > > > > > > are tons of features which don't work in SPL, or are not relevant, or
> > > > > > > > > > > > > > > > > > > have special 'small' versions. That is a *lot* of Kconfig refactoring
> > > > > > > > > > > > > > > > > > > just to get something working, isn't it? With my scheme there is no
> > > > > > > > > > > > > > > > > > > Kconfig change needed initially - it can be done later as needed /
> > > > > > > > > > > > > > > > > > > desirable.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't think we would remove most "if SPL" cases. Taking part of the
> > > > > > > > > > > > > > > > > > current stanza for ROCKCHIP_RK3399 as an example:
> > > > > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > > > > >         select SPL
> > > > > > > > > > > > > > > > > >         select SPL_ATF
> > > > > > > > > > > > > > > > > >         select SPL_BOARD_INIT if SPL
> > > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > > > >         select SPL_CLK if SPL
> > > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > > > >         select CLK
> > > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > > > >         imply TPL_CLK
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This would become:
> > > > > > > > > > > > > > > > > > config ROCKCHIP_RK3399
> > > > > > > > > > > > > > > > > >         bool "Support Rockchip RK3399"
> > > > > > > > > > > > > > > > > >         select ARM64
> > > > > > > > > > > > > > > > > >         select SUPPORT_SPL
> > > > > > > > > > > > > > > > > >         select SUPPORT_TPL
> > > > > > > > > > > > > > > > > >         select SPL_ATF if SPL # TBD: Does 'ATF' make sense outside of SPL?
> > > > > > > > > > > > > > > > > >         select BOARD_INIT if SPL # Not TPL_BOARD_INIT here
> > > > > > > > > > > > > > > > > >         select CLK # imply was likely wrong before? Would need to check
> > > > > > > > > > > > > > > > > >         ...
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I was more talking about the large blocks of 'if SPL' - e.g. we have
> > > > > > > > > > > > > > > > > common/spl/Kconfig and common/spl/Kconfig.tpl
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I would vastly reduce the contents within those 'if' blocks, but there
> > > > > > > > > > > > > > > > are still options that are xPL-centric without a PPL counterpart, such
> > > > > > > > > > > > > > > > as SPL_ATF (I suspect, but if not I'm sure others).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But just the level of thought required in your small example above
> > > > > > > > > > > > > > > > > suggests it is a large effort.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, restructuring our Kconfig logic and then removing our xPL logic is
> > > > > > > > > > > > > > > > some work. So was, I suspect, all of what you did already.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 4. My scheme splits the config into separate files. Yours makes the
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't see yours as splitting the configs in to separate files, I see
> > > > > > > > > > > > > > > > > > it as generating some intermediate objects. The configs don't change and
> > > > > > > > > > > > > > > > > > that's one of our problem areas.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So you mean a big problem area is the current Kconfig?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I mean it's a problem for users a board developers to make valid
> > > > > > > > > > > > > > > > configurations and update them as needed. Filesystems are in the
> > > > > > > > > > > > > > > > filesystem menu, unless they're SPL and then it's all under the big SPL
> > > > > > > > > > > > > > > > menu.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Mind generates
> > > > > > > > > > > > > > > > > out to an include/generated/autoconf_xxx for each phase. Yes they are
> > > > > > > > > > > > > > > > > intermediate files and auto-generated, but each 100% controls its
> > > > > > > > > > > > > > > > > phase, so there is no confusion and CONFIG_IS_ENABLED() / odd Makefile
> > > > > > > > > > > > > > > > > rules anymore.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, removing CONFIG_IS_ENABLED and $(PHASE_)/$(XPL_) from Makefiles is
> > > > > > > > > > > > > > > > good. But the intermediate files aren't going to help (nor hurt) any of
> > > > > > > > > > > > > > > > the problems themselves. If you're reading those to figure out a
> > > > > > > > > > > > > > > > problem, it's like when you're reading a .i file to figure out a
> > > > > > > > > > > > > > > > problem, it means you're already in a complex troublesome spot.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But I don't know that CONFIG_SPL_FS_FAT=y means that CONFIG_FS_FAT=y for
> > > > > > > > > > > > > > > > SPL builds leads to "no confusion". But I do think that CONFIG_SPL=y and
> > > > > > > > > > > > > > > > CONFIG_FS_FAT=y does.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > split earlier, at the Kconfig level. So it seems that we could go with
> > > > > > > > > > > > > > > > > > > my scheme to get us to a split config, then, after that, decide
> > > > > > > > > > > > > > > > > > > whether to move that split earlier to Kconfig itself. The choices
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't think so. Yours makes things complicated by making the build do
> > > > > > > > > > > > > > > > > > even more (and from the RFC, the implementation tooling diverges from
> > > > > > > > > > > > > > > > > > upstream).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes it makes the kconf tool generate those separate files for each phase [3]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Mine makes things differently complicated by doing less for
> > > > > > > > > > > > > > > > > > most things, but needing some thought on how to know that say
> > > > > > > > > > > > > > > > > > chromebook_bob needs chromebook_bob_tpl_defconfig,
> > > > > > > > > > > > > > > > > > chromebook_bob_spl_defconfig and chromebook_bob_ppl_defconfig to be
> > > > > > > > > > > > > > > > > > built, before asking binman to go put things together.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yours seems feasible in a fully Binman world, but given the difficulty
> > > > > > > > > > > > > > > > > we (or I) have completing a migration, I honestly don't believe this
> > > > > > > > > > > > > > > > > is feasible in today's U-Boot. The other problem is that it all has to
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm not 100% sure it's everything needs binman actually. Or even if we
> > > > > > > > > > > > > > > > do take this as a reason to push for more binman, it's just some trivial
> > > > > > > > > > > > > > > > types already handled in the Makefile that's missing.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > be done at once. We need to rewrite the Kconfig and flip over the
> > > > > > > > > > > > > > > > > board. Will we carry people with us? That is a huge risk to the
> > > > > > > > > > > > > > > > > project IMO.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm not sure, actually, that it couldn't be done in stages. We might
> > > > > > > > > > > > > > > > need a little bit of fakery around being able to just build SPL without
> > > > > > > > > > > > > > > > PPL in the interim.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Anyway, yes my schema makes the build do even more (with 400 lines of
> > > > > > > > > > > > > > > > > kconf additions and a patch that can likely be upstreamed). But
> > > > > > > > > > > > > > > > > otherwise, it is a one-off improvement, without any changes to the
> > > > > > > > > > > > > > > > > existing Kconfig.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I thought Yamada-san rejected changes going in this direction before?
> > > > > > > > > > > > > > > > But either way, no it's not likely the final overburden in terms of
> > > > > > > > > > > > > > > > divergence.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes. Masahiro will make his own decisions and I am confident he will
> > > > > > > > > > > > > > > reject any future changes I send
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So my point is that we could go with the first part of my scheme to
> > > > > > > > > > > > > > > > > resolve the 'medium' problems then decide which way to continue after
> > > > > > > > > > > > > > > > > that. From your side you won't have lost anything towards where you
> > > > > > > > > > > > > > > > > want to head. The two options would then be:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > - exhance kconfig language to build in the notion of phases
> > > > > > > > > > > > > > > > > - split the defconfigs for each board, redo the Kconfig rules and
> > > > > > > > > > > > > > > > > teach the build to combine images
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If things go down your proposed path instead, no, I don't see that as
> > > > > > > > > > > > > > > > making it meaningfully easier to go the way I proposed later. The only
> > > > > > > > > > > > > > > > commonality is dropping $(PHASE_)/$(XPL_)/etc and CONFIG_IS_ENABLED ->
> > > > > > > > > > > > > > > > IS_ENABLED. And (almost) all of that is a script'able change.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To be frank, the difference is that I have actually put in the work to
> > > > > > > > > > > > > > > try this. It is more than 50 and perhaps as many as 100 patches. Quite
> > > > > > > > > > > > > > > difficult work. Honestly, compared to that, the logic changes are not
> > > > > > > > > > > > > > > that large.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > That is why I believe this work is a prerequisite for both schemes
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > would then be to use your scheme (Kconfig refactoring, splitting
> > > > > > > > > > > > > > > > > > > defconfigs and some rework), or to do my scheme (which would require
> > > > > > > > > > > > > > > > > > > enhancing the Kconfig language a bit just for U-Boot and some optional
> > > > > > > > > > > > > > > > > > > rework over time). Both schemes would need a small amount of
> > > > > > > > > > > > > > > > > > > build-logic changes, but I'm not sure yet what that would look like.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Does that sound right?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > With what I said above, yes I think we're closer at least to
> > > > > > > > > > > > > > > > > > understanding each other.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Well, with that, what now?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > What makes the current situation untenable is VPL. And I gather I
> > > > > > > > > > > > > > > > haven't convinced you to put that on hold long enough to instead rework
> > > > > > > > > > > > > > > > how we build things, have I?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Which VPL thing?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > That it exists. When it was just SPL, it's manageable. With TPL, well,
> > > > > > > > > > > > > > it was supposed to be tiny and so just a few more things. And with VPL,
> > > > > > > > > > > > > > that makes 4. It's too much. Something needs to be done. Four times is
> > > > > > > > > > > > > > too many. If solving Marek's desire for PSCI-from-U-Boot means we need
> > > > > > > > > > > > > > number 5 that becomes even worse (and I also suspect that's a case of
> > > > > > > > > > > > > > one build covers the SoC or family of SoCs depending on hardware
> > > > > > > > > > > > > > changes).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, that's why I took on this effort a few years back.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > You have convinced me that you have a solution. It makes a lot more
> > > > > > > > > > > > > > > sense to me than previously and it may be that it is better in the
> > > > > > > > > > > > > > > end. For example, with VBE it I would make a lot of sense to build 20
> > > > > > > > > > > > > > > boards as just TPL and use a generic rock chip board for everything
> > > > > > > > > > > > > > > else. That would be a lot tidier with your scheme. It is very hard to
> > > > > > > > > > > > > > > predict the future and VBE is still not finished, some two years in.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't want to be tied to your scheme today though.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So if you can accept my going ahead with 1-4 and helping me with that,
> > > > > > > > > > > > > > > then we can stop and discuss which way to go, perhaps by prototyping
> > > > > > > > > > > > > > > the two options?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I want to start by saying I do appreciate you put in a lot of work in
> > > > > > > > > > > > > > this direction already, and I do see some of the end goals it achieves
> > > > > > > > > > > > > > as being important, and I'm glad you see my idea has some good parts
> > > > > > > > > > > > > > too.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I want to figure out how to move forward on this problem. My other part
> > > > > > > > > > > > > > of this thread, this morning, was also part of me looking harder, again,
> > > > > > > > > > > > > > at the RFC series you posted before. And that's where I still have large
> > > > > > > > > > > > > > reservations. There are *so* *many* symbols we need to now have 4
> > > > > > > > > > > > > > variants of, instead of 1 variant of. Take:
> > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-58-sjg@chromium.org/
> > > > > > > > > > > > > > for example. It adds SPL_PARTITION_TYPE_GUID but we include <part.h> in
> > > > > > > > > > > > > > files built in TPL (and likely VPL) so aren't we going to need that
> > > > > > > > > > > > > > every time? And with a quick size-check on pinebook-pro-rk3399 it looks
> > > > > > > > > > > > > > like it's not working as intended either? I checked and part_get_info
> > > > > > > > > > > > > > shrinks because CONFIG_PARTITION_TYPE_GUID is not set, or rather:
> > > > > > > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > > > > > >                 info->type_guid[0] = 0;
> > > > > > > > > > > > > > #endif
> > > > > > > > > > > >
> > > > > > > > > > > > Oh, I get it now. Previously CONFIG_PARTITION_TYPE_GUID=y but now
> > > > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID=n and while I'm not sure that's a good
> > > > > > > > > > > > thing I see what happened. And now I see my problem from yesterday
> > > > > > > > > > > > morning was similar but different.
> > > > > > > > > > > >
> > > > > > > > > > > > > > is not true and checked. And I can't see why. And there's other size
> > > > > > > > > > > > > > reductions (this time in tpl) on pinebook-pro-rk3399 that I didn't dig
> > > > > > > > > > > > > > in to more, but wasn't that symbol:
> > > > > > > > > > > > > >                tpl-u-boot-tpl: add: 0/-4, grow: 0/0 bytes: 0/-344 (-344)
> > > > > > > > > > > > > >                  function                                   old     new   delta
> > > > > > > > > > > > > >                  dev_get_uclass_plat                         12       -     -12
> > > > > > > > > > > > > >                  simple_bus_post_bind                        92       -     -92
> > > > > > > > > > > > > >                  _u_boot_list_2_uclass_driver_2_simple_bus     120       -    -120
> > > > > > > > > > > > > >                  _u_boot_list_2_driver_2_simple_bus         120       -    -120
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And I'm not bringing this up to badger you about bugs in an RFC series
> > > > > > > > > > > > > > (it's RFC, there's bugs) but rather because I think it highlights some
> > > > > > > > > > > > > > core issues with the approach as implemented.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But surely you can see that both schemes have exactly the same issues?
> > > > > > > > > > > > >
> > > > > > > > > > > > > My point is that the work to tidy up things and then get to a 'clean'
> > > > > > > > > > > > > source tree and Makefiles is the hard bit here and has to be done with
> > > > > > > > > > > > > both schemes.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just let me know which way you want to go. I don't have anything ready
> > > > > > > > > > > > > to send, but I could probably drag it over the line before too long,
> > > > > > > > > > > > > if you are keen.
> > > > > > > > > > > >
> > > > > > > > > > > > Once I figured out what was the cause of the problems I saw in the RFC,
> > > > > > > > > > > > I had to rewrite this a few times. Your approach needs even more symbols
> > > > > > > > > > > > added than were in the RFC, and the newly added symbols need further
> > > > > > > > > > > > auditing to make sure we have the same behavior as today at least by
> > > > > > > > > > > > default.
> > > > > > > > > > >
> > > > > > > > > > > This is the idea that we need to clean up a, b and c. Your scheme is
> > > > > > > > > > > the same in this respect. If we have CONFIG_FOO today, then your
> > > > > > > > > > > scheme may need that duplicated to each defconfig file. Either you
> > > > > > > > > > > resolve the ambiguity or don't. But if you do, then you have to add
> > > > > > > > > > > symbols, with both schemes.
> > > > > > > > > >
> > > > > > > > > > There is minimal pain in saying a defconfig needs to list CONFIG_FOO
> > > > > > > > > > there is pain in saying that we need to list
> > > > > > > > > > config PARTITION_TYPE_GUID
> > > > > > > > > > ...
> > > > > > > > > > config SPL_PARTITION_TYPE_GUID
> > > > > > > > > > ...
> > > > > > > > > > config TPL_PARTITION_TYPE_GUID
> > > > > > > > > > ...
> > > > > > > > > > config VPL_PARTITION_TYPE_GUID
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > In what I'm saying it's not generally an issue because:
> > > > > > > > > > $ git grep -l PARTITION_TYPE_GUID configs | wc -l
> > > > > > > > > > 21
> > > > > > > > > >
> > > > > > > > > > And we don't have to do additional upkeep on having N symbols.
> > > > > > > > >
> > > > > > > > > Well we only need to add those extra symbols if 1) we want that
> > > > > > > > > feature in a particular xPL, *and* 2) we don't want it everywhere.
> > > > > > > >
> > > > > > > > Yes, and the problem is adding more of them. Again, we would need to
> > > > > > > > duplicate drivers/usb/gadget/Kconfig with your scheme.
> > > > > > > >
> > > > > > > > > There is nothing in my scheme which requires us to add options that
> > > > > > > > > don't currently exist...but there is a problem if some code uses
> > > > > > > > > CONFIG_IS_ENABLED(FOO) today and some code uses IS_ENABLED(FOO). My
> > > > > > > >
> > > > > > > > That's good because that wasn't (how it seemed?) previously.
> > > > > > > >
> > > > > > > > > conf_nospl file helps with that and avoids changing Kconfig. But
> > > > > > > > > again, if we are using both, then who knows what it means today, and
> > > > > > > > > I'd like to clean it up.
> > > > > > > >
> > > > > > > > What we have today, with respect to CONFIG_IS_ENABLED(...) /
> > > > > > > > IS_ENABLED(...) is clearer than IS_ENABLED(CONFIG_FOO) that is really
> > > > > > > > checking for CONFIG_SPL_FOO or CONFIG_VPL_FOO if it's in SPL or VPL.
> > > > > > > > It's easy to get *wrong* yes, but it's also clear. You're checking for
> > > > > > > > what it says.
> > > > > > > >
> > > > > > > > > > > > On the one hand, this is at least a well defined technical
> > > > > > > > > > > > problem and if you do the language extension *first* the code changes
> > > > > > > > > > > > aren't so bad.
> > > > > > > > > > >
> > > > > > > > > > > There are no significant Kconfig changes in my scheme, other than the
> > > > > > > > > > > conf_nospl file. The language extension is quite separate.
> > > > > > > > > >
> > > > > > > > > > $ git diff pre-RFC-migrate-to-split-config..RFC-migrate-to-split-config
> > > > > > > > > > \
> > > > > > > > > >         | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > > > > > >  25 files changed, 316 insertions(+), 3 deletions(-)
> > > > > > > > > >
> > > > > > > > > > And that is largely duplication of existing symbols. And again, it
> > > > > > > > > > wasn't enough duplication.
> > > > > > > > >
> > > > > > > > > I wonder if that is stuff that was already applied? Here is what I have today.
> > > > > > > > >
> > > > > > > > > $ glo ci/master..splg4  | filterdiff -i "a/*/Kconfig" | diffstat -p1 | tail -n 1
> > > > > > > > >  0 files changed
> > > > > > > > >
> > > > > > > > > You can use the u-boot-dm/splg-working tree to see the original
> > > > > > > > > version. From memory, the splc tree is very old and was mostly applied
> > > > > > > > > or dropped.
> > > > > > > >
> > > > > > > > The splc-working tree is the RFC you pointed at earlier and so yes, what
> > > > > > > > I was comparing with. If you were able to drop some of the problems,
> > > > > > > > that's good.
> > > > > > > >
> > > > > > > > > > > > But for the user running menuconfig / etc? That's not
> > > > > > > > > > > > going to be pretty. And we still won't have fixed the problems like "why
> > > > > > > > > > > > is TPL even trying to build DWC3?" without reworking more symbols.
> > > > > > > > > > > >
> > > > > > > > > > > > So I don't think this is the right approach as it doesn't reduce
> > > > > > > > > > > > confusion and may increase it (why do I need to set
> > > > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID when the code checks for
> > > > > > > > > > > > CONFIG_PARTITION_TYPE_GUID?
> > > > > > > > > > >
> > > > > > > > > > > Because it is an SPL build...I actually think that makes a lot of
> > > > > > > > > > > sense. You just need to understand that CONFIG_SPL_ means the SPL
> > > > > > > > > > > build, which in fact is what we have been using for years.
> > > > > > > > > >
> > > > > > > > > > And it's no longer clear in the code, is the problem.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > But why is CONFIG_SPL_FRAMEWORK still there?
> > > > > > > > > > >
> > > > > > > > > > > Not relevant to the discussion, IMO.
> > > > > > > > > >
> > > > > > > > > > It's an example symbol. Why does the code have:
> > > > > > > > > >
> > > > > > > > > > #ifdef CONFIG_PARTITION_TYPE_GUID
> > > > > > > > > > ...
> > > > > > > > > > #endif
> > > > > > > > > >
> > > > > > > > > > And that's true for SPL builds. But the code also still has:
> > > > > > > > > > #ifdef CONFIG_SPL_FRAMEWORK
> > > > > > > > > > ...
> > > > > > > > > > #endif
> > > > > > > > > >
> > > > > > > > > > Which is only true for CONFIG_SPL_FRAMEWORK being set.
> > > > > > > > >
> > > > > > > > > OK I think I understand your question. The tools work by identifying
> > > > > > > > > options which are in PPL and may or not be in other builds. There is
> > > > > > > > > no CONFIG_FRAMEWORK so all of this migration doesn't apply.
> > > > > > > >
> > > > > > > > No, you entirely misunderstand me. I am not talking about the tool. I am
> > > > > > > > talking about the developer.
> > > > > > > >
> > > > > > > > > If there were a CONFIG_IS_ENABLED(FRAMEWORK) or a CONFIG_FRAMEWORK
> > > > > > > > > then the discussion would be different.
> > > > > > > > >
> > > > > > > > > BTW, I wonder if we could drop that symbol, or switch it around so
> > > > > > > > > that boards which don't use it have to set CONFIG_SPL_STRANGE or
> > > > > > > > > similar.
> > > > > > > >
> > > > > > > > Touching the PowerPC TPL/SPL stuff is very low on the priority list. If
> > > > > > > > you want to file an issue for it, please do. But that (roughly) is why
> > > > > > > > there's SPL_FRAMEWORK.
> > > > > > > >
> > > > > > > > > > > > Oh..). The main thing it does is drop $(PHASE_) and I honestly think
> > > > > > > > > > > > that's more confusing. We still have one build where we need to do or
> > > > > > > > > > > > not do different things for FOO && PPL, FOO && SPL, etc but the code
> > > > > > > > > > > > just references CONFIG_FOO but doesn't always mean CONFIG_FOO=y/n in the
> > > > > > > > > > > > .config / defconfig.
> > > > > > > > > > >
> > > > > > > > > > > Yes, that's the conf_nospl file which I have dealt with.
> > > > > > > > > >
> > > > > > > > > > OK? My point is that the code is now more confusing, not less confusing.
> > > > > > > > > > Because the code says CONFIG_PARTITION_TYPE_GUID. Not
> > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID. And not IS_ENABLED(PARTITION_TYPE_GUID)
> > > > > > > > > > which is at least a hint that one needs to look harder, and oh,
> > > > > > > > > > CONFIG_SPL_PARTITION_TYPE_GUID maybe matches somehow.
> > > > > > > > >
> > > > > > > > > If you are saying that it is better to have CONFIG_IS_ENABLED(FOO),
> > > > > > > > > IS_ENABLED(CONFIG_FOO), obj-$(CONFIG_$(PHASE_)FOO) etc., then I don't
> > > > > > > > > agree, sorry. That is problems a-c in my original proposal and my
> > > > > > > > > understanding is that both our approaches resolve this problem.
> > > > > > > > >
> > > > > > > > > Otherwise, you've just lost me and we should probably give up on this point.
> > > > > > > >
> > > > > > > > Yes, I am saying that what we have today is less confusing than what you
> > > > > > > > are proposing. Because with your proposal:
> > > > > > > >
> > > > > > > > obj-$(CONFIG_FS_FAT) += fat/
> > > > > > > >
> > > > > > > > Can refer to CONFIG_SPL_FS_FAT, CONFIG_FS_FAT or CONFIG_VPL_FS_FAT. That
> > > > > > > > is not good for humans.
> > > > > > >
> > > > > > > Let's just stop on this point. We seem to be going backwards. Now you
> > > > > > > are saying that you *want* to keep:
> > > > > > >
> > > > > > > a. The $(PHASE_) stuff in Makefiles
> > > > > > > b. The CONFIG_xxx / CONFIG_IS_ENABLED(xxx) split
> > > > > > >
> > > > > > > and you believe that
> > > > > > >
> > > > > > > c. the ambiguity I mentioned with CONFIG_FOO
> > > > > > >
> > > > > > > are all actually a good thing?
> > > > > >
> > > > > > No. I'm saying that what we have today is LESS confusing than your
> > > > > > proposal in splc-working. I can't evaluate splg-working because it
> > > > > > doesn't work enough to be clear if it does or doesn't still solve all
> > > > > > the problems that splc-working does. Various things don't build anymore
> > > > > > in splg-working and T2080RDB_NAND as a first example (as the powerpc
> > > > > > part of the world build failed first) has massive size changes.
> > > > > >
> > > > > > I do not like splc-working, but splc-working is a few bugs away from 1:1
> > > > > > functional binaries from before your changes.
> > > > > >
> > > > > > I do not like what we have today because it's tricky to get things
> > > > > > right. But the macros are visible in the code / Makefiles so humans
> > > > > > still find things.
> > > > >
> > > > > OK, well I am still lost, sorry.
> > > >
> > > > OK, in splc-working what is untenable to me is that the following line
> > > > in a Makefile:
> > > > obj-$(CONFIG_FS_FAT) += fat/
> > > >
> > > > Is unclear if it refers to PPL or some xPL. This is worse for humans
> > > > than what we have today.
> > >
> > > We're really heading in completely different directions then.
> > >
> > > At the moment, if we have:
> > >
> > > obj-$(CONFIG_FOO) += foo/
> > >
> > > we know this is used in all builds. If we have:
> > >
> > > obj-$(CONFIG_$(PHASE_)FOO) += foo/
> > >
> > > then we have to look at Kconfig to figure that out.
> > >
> > > My change makes it entirely dependent on Kconfig, in both cases.
> > >
> > > For source code, we can have both CONFIG_FOO and
> > > CONFIG_IS_ENABLED(FOO), so again Kconfig does not control things. It
> > > is merely a hint.
> > >
> > > To my mind, $(PHASE_) and CONFIG_IS_ENABLED() are hacks, to work
> > > around the unified config, which I want to split.
> >
> > This is why we need a TSC. I think $(PHASE_) and CONFIG_IS_ENABLED() are
> > better than having to remember that CONFIG_SPL_FOO is no longer a
> > meaningful value (CONFIG_SPL_FS_FAT), except when it is a meaningful
> > value (CONFIG_SPL_TEXT_BASE). You disagree. We've both presented our
> > technical reasoning and neither of us seems swayed to go another
> > direction instead. You are also unwilling to accept my No as the head of
> > the project.
> 
> But I still don't really understand what you want here. You say that
> you want completly separate defconfig files for each phase, with kconf
> running once for each. So I assumed that the .config files so produced
> would just have CONFIG_FOO in them, not CONFIG_SPL_FOO (for example).
> Is that right?
> 
> Or are you saying that the .config.spl file will have CONFIG_SPL_FOO,
> i.e. insert an SPL_ into every option?
> 
> Or, perhaps, are you saying that the $(PHASE_) does nothing
> (programmatically) with your scheme, just indicating to the user that
> this is an option that might have different values for each phase?
> 
> Before giving up, I should at least try to understand what you are
> actually getting at.

I have replied in detail now earlier in the thread.

> I accepted your No over two years ago and no one has come up with an
> alternative series in the interim, so we have lost that time (and also
> that work, since it took at lot of of effort to avoid behaviour
> changes and much of it will need to be redone). I'd *really* like to
> be able to add a new phase with just a few lines of Kconfig.

I not only said No two years ago, I said we should instead do what I
proposed as an alternate. And I said several times over the prior years
that Yamada-san was right and we should have had one .config builds one
phase.

And then more recently I applied your xPL series may or may not have
made things more confusing to other people (I don't have a good search
engine for looking for examples in the archives, nor the public IRC
logs) as olive branch towards "maybe this will be enough to appease
Simon".

> > > > > We are trying to discuss a change to how CONFIG options are handled in
> > > > > the source tree. It sounds like you are saying that you cannot review
> > > > > it until it fully works. But you already did that two years ago and
> > > >
> > > > I cannot comment on what's in splg-working, which is also about two
> > > > years old, because while it has the same problem I object to above with
> > > > splc-working, it looks like you just dropped adding Kconfig symbols from
> > > > splc-working and showing that well actually some number of those symbols
> > > > were needed afterall.
> > >
> > > That could well be true.
> > >
> > > >
> > > > > rejected it. So I don't see any way forward here. Do you?
> > > >
> > > > Well, I'm once again back to wondering if you ever plan to stop having
> > > > your own downstream fork and so how much effort I should even put in
> > > > again.
> > >
> > > My plan is to run it for a year and then review it.  The more effort
> > > we put in, the less the delta, which is why I am sending patches out
> > > and responding to feedback.
> >
> > So you want to run a downstream fork for a year, and then what? How can
> > I get you to stop? Or convince you to just hard fork and give the domain
> > to the project? As I do not see how this gets better in a year unless
> > you expect your tree to just become mainline.
> 
> So far I've been working with you and others on everything I've sent.
> If that continues for this year, I won't need my tree.

So in a year you'll go and start unwinding all of your work, so it can
be rebased and then re-tested and applied? We've already now hit the
point where most things you post can't be applied to mainline. This is
one of the points I've been trying to make for a while now. And it would
be one thing if you were doing that your personal domain or your
personal github/whatever. But you're doing it with u-boot.org. And I
cannot seem to convince you to stop and make that point to the official
tree.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Generic U-Boot (was: Re: xPL Proposal)

[Caleb Connolly]

Hi all,

On 2/12/25 17:41, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
>>
>> On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
>>>
>>> The way I see it, both schemes remove the ambiguity. Mine retains a
>>> single deconfig file and a single 'make menuconfig' for each board.
>>> Yours feels more like building independent U-Boot images.
>>
>> It is explicitly building independent U-Boot images, yes. With a wrapper
>> around "make all of the images for a given platform". So much of our
>> confusing and messy code is because we aren't doing that. And since most
>> modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
>> we really could have fewer overall build configurations.

Big +1 for this. Most Qualcomm platforms in the wild today that would 
benefit from chainloading U-Boot will NEVER be able to run any stage 
except PPL due to codesigning. For these I would ideally never like to 
even think about non-PPL stages since they only added confusion.

At the same time, it would be great to eventually have U-Boot SPL for 
Qualcomm platforms that can replace Qualcomm's proprietary sbl1, and 
maybe event some even smaller/earlier secure TPL(?) stage that replaces 
their xbl_sec.

I would very much prefer that these be distinct, since they vary in how 
board specific they need to be (see below).

Folks who are just contributing support for their device/soc (a few 
quirks or simple driver ports from Linux in most cases) are going to 
have the best experience when the learning curve from Linux to U-Boot is 
minimal. Mixing up various boot stages into a single defconfig and 
having custom kbuild infrastructure is the opposite of that, and seems 
unnecessary.

> 
> I'd really like to see a generic aarch64 U-Boot for PPL, although it
> would be quite large with all the drivers. Perhaps we could start by
> having a generic Rockchip one, for example.

We already have this for Qualcomm. Some small QoL things still need to 
go upstream but you can build a single U-Boot binary and boot it on a 
bunch of differences devices just by using the right DTB. See this build 
script for example which builds for just a few devices:

https://gitlab.com/sdm845-mainline/validation/-/blob/main/build_uboot.sh

I think a bunch of things in mach-snapdragon could be moved to a generic 
mach-aarch64 that could also target other SoCs like Rockchip or 
Mediatek. I'd be super interested in helping to make this happen.

Probably would even want to put more things into common code so other 
architectures can adopt it (and make themselves smaller), then 
mach-aarch64 can just be a stub for devices that are fully generic.

The other potential concern with a generic aarch64 target is that we 
then lose track of what devices are actually supported. It would be nice 
to have something like a list of DTBs either in U-Boot or in some 
associated infrastructure we use to build reference images.

Which all ties back to the goal of providing distro-agnostic U-Boot 
images to make Qualcomm (and other?) Android phones capable of running 
more Linux distros.

Sorry for the big thought-dump, this has been on my mind for a while and 
since it seems like something you're both also interested in I just 
wanted to offer my perspective as a device and distro maintainer as well.

Kind regards,

> 
> Regards,
> Simon
> 
>>
>> --
>> Tom


-- 
Caleb (they/them)

Re: Generic U-Boot

[Caleb Connolly]

On 2/13/25 15:03, Caleb Connolly wrote:
> Hi all,
> 
> On 2/12/25 17:41, Simon Glass wrote:
>> Hi Tom,
>>
>> On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
>>>
>>> On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
>>>>
>>>> The way I see it, both schemes remove the ambiguity. Mine retains a
>>>> single deconfig file and a single 'make menuconfig' for each board.
>>>> Yours feels more like building independent U-Boot images.
>>>
>>> It is explicitly building independent U-Boot images, yes. With a wrapper
>>> around "make all of the images for a given platform". So much of our
>>> confusing and messy code is because we aren't doing that. And since most
>>> modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
>>> we really could have fewer overall build configurations.
> 
> Big +1 for this. Most Qualcomm platforms in the wild today that would 
> benefit from chainloading U-Boot will NEVER be able to run any stage 
> except PPL due to codesigning. For these I would ideally never like to 
> even think about non-PPL stages since they only added confusion.
> 
> At the same time, it would be great to eventually have U-Boot SPL for 
> Qualcomm platforms that can replace Qualcomm's proprietary sbl1, and 
> maybe event some even smaller/earlier secure TPL(?) stage that replaces 
> their xbl_sec.
> 
> I would very much prefer that these be distinct, since they vary in how 
> board specific they need to be (see below).
> 
> Folks who are just contributing support for their device/soc (a few 
> quirks or simple driver ports from Linux in most cases) are going to 
> have the best experience when the learning curve from Linux to U-Boot is 
> minimal. Mixing up various boot stages into a single defconfig and 
> having custom kbuild infrastructure is the opposite of that, and seems 
> unnecessary.
> 
>>
>> I'd really like to see a generic aarch64 U-Boot for PPL, although it
>> would be quite large with all the drivers. Perhaps we could start by
>> having a generic Rockchip one, for example.
> 
> We already have this for Qualcomm. Some small QoL things still need to 
> go upstream but you can build a single U-Boot binary and boot it on a 
> bunch of differences devices just by using the right DTB. See this build 
> script for example which builds for just a few devices:
> 
> https://gitlab.com/sdm845-mainline/validation/-/blob/main/build_uboot.sh
> 
> I think a bunch of things in mach-snapdragon could be moved to a generic 
> mach-aarch64 that could also target other SoCs like Rockchip or 
> Mediatek. I'd be super interested in helping to make this happen.
> 
> Probably would even want to put more things into common code so other 
> architectures can adopt it (and make themselves smaller), then mach- 
> aarch64 can just be a stub for devices that are fully generic.
> 
> The other potential concern with a generic aarch64 target is that we 
> then lose track of what devices are actually supported. It would be nice 
> to have something like a list of DTBs either in U-Boot or in some 
> associated infrastructure we use to build reference images.
> 
> Which all ties back to the goal of providing distro-agnostic U-Boot 
> images to make Qualcomm (and other?) Android phones capable of running 
> more Linux distros.

This has been very successful for older Qualcomm SoC's using lk2nd which 
supports a frankly ridiculous number of phones

https://github.com/msm8916-mainline/lk2nd/blob/main/Documentation/devices.md

notably with just a binary per soc: 
https://github.com/msm8916-mainline/lk2nd/releases/tag/20.0

They also do some fun things with DT that we might find some inspiration in.
> 
> Sorry for the big thought-dump, this has been on my mind for a while and 
> since it seems like something you're both also interested in I just 
> wanted to offer my perspective as a device and distro maintainer as well.
> 
> Kind regards,
> 
>>
>> Regards,
>> Simon
>>
>>>
>>> -- 
>>> Tom
> 
> 

-- 
Caleb (they/them)

Re: Generic U-Boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4220 bytes --]

On Thu, Feb 13, 2025 at 03:10:36PM +0000, Caleb Connolly wrote:
> 
> 
> On 2/13/25 15:03, Caleb Connolly wrote:
> > Hi all,
> > 
> > On 2/12/25 17:41, Simon Glass wrote:
> > > Hi Tom,
> > > 
> > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > > 
> > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > > 
> > > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > > Yours feels more like building independent U-Boot images.
> > > > 
> > > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > > around "make all of the images for a given platform". So much of our
> > > > confusing and messy code is because we aren't doing that. And since most
> > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > > we really could have fewer overall build configurations.
> > 
> > Big +1 for this. Most Qualcomm platforms in the wild today that would
> > benefit from chainloading U-Boot will NEVER be able to run any stage
> > except PPL due to codesigning. For these I would ideally never like to
> > even think about non-PPL stages since they only added confusion.
> > 
> > At the same time, it would be great to eventually have U-Boot SPL for
> > Qualcomm platforms that can replace Qualcomm's proprietary sbl1, and
> > maybe event some even smaller/earlier secure TPL(?) stage that replaces
> > their xbl_sec.
> > 
> > I would very much prefer that these be distinct, since they vary in how
> > board specific they need to be (see below).
> > 
> > Folks who are just contributing support for their device/soc (a few
> > quirks or simple driver ports from Linux in most cases) are going to
> > have the best experience when the learning curve from Linux to U-Boot is
> > minimal. Mixing up various boot stages into a single defconfig and
> > having custom kbuild infrastructure is the opposite of that, and seems
> > unnecessary.
> > 
> > > 
> > > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > > would be quite large with all the drivers. Perhaps we could start by
> > > having a generic Rockchip one, for example.
> > 
> > We already have this for Qualcomm. Some small QoL things still need to
> > go upstream but you can build a single U-Boot binary and boot it on a
> > bunch of differences devices just by using the right DTB. See this build
> > script for example which builds for just a few devices:
> > 
> > https://gitlab.com/sdm845-mainline/validation/-/blob/main/build_uboot.sh
> > 
> > I think a bunch of things in mach-snapdragon could be moved to a generic
> > mach-aarch64 that could also target other SoCs like Rockchip or
> > Mediatek. I'd be super interested in helping to make this happen.
> > 
> > Probably would even want to put more things into common code so other
> > architectures can adopt it (and make themselves smaller), then mach-
> > aarch64 can just be a stub for devices that are fully generic.
> > 
> > The other potential concern with a generic aarch64 target is that we
> > then lose track of what devices are actually supported. It would be nice
> > to have something like a list of DTBs either in U-Boot or in some
> > associated infrastructure we use to build reference images.
> > 
> > Which all ties back to the goal of providing distro-agnostic U-Boot
> > images to make Qualcomm (and other?) Android phones capable of running
> > more Linux distros.
> 
> This has been very successful for older Qualcomm SoC's using lk2nd which
> supports a frankly ridiculous number of phones
> 
> https://github.com/msm8916-mainline/lk2nd/blob/main/Documentation/devices.md
> 
> notably with just a binary per soc:
> https://github.com/msm8916-mainline/lk2nd/releases/tag/20.0
> 
> They also do some fun things with DT that we might find some inspiration in.

There's certainly a lot that can be done with "generic enough for a
single family" as the goal. And there's cases where that's indeed both
enough and the goal, and we should support that as much as we can.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Generic U-Boot (was: Re: xPL Proposal)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7599 bytes --]

On Thu, Feb 13, 2025 at 03:03:29PM +0000, Caleb Connolly wrote:
> Hi all,
> 
> On 2/12/25 17:41, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote:
> > > > 
> > > > The way I see it, both schemes remove the ambiguity. Mine retains a
> > > > single deconfig file and a single 'make menuconfig' for each board.
> > > > Yours feels more like building independent U-Boot images.
> > > 
> > > It is explicitly building independent U-Boot images, yes. With a wrapper
> > > around "make all of the images for a given platform". So much of our
> > > confusing and messy code is because we aren't doing that. And since most
> > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL
> > > we really could have fewer overall build configurations.
> 
> Big +1 for this. Most Qualcomm platforms in the wild today that would
> benefit from chainloading U-Boot will NEVER be able to run any stage except
> PPL due to codesigning. For these I would ideally never like to even think
> about non-PPL stages since they only added confusion.
> 
> At the same time, it would be great to eventually have U-Boot SPL for
> Qualcomm platforms that can replace Qualcomm's proprietary sbl1, and maybe
> event some even smaller/earlier secure TPL(?) stage that replaces their
> xbl_sec.
> 
> I would very much prefer that these be distinct, since they vary in how
> board specific they need to be (see below).
> 
> Folks who are just contributing support for their device/soc (a few quirks
> or simple driver ports from Linux in most cases) are going to have the best
> experience when the learning curve from Linux to U-Boot is minimal. Mixing
> up various boot stages into a single defconfig and having custom kbuild
> infrastructure is the opposite of that, and seems unnecessary.
> 
> > 
> > I'd really like to see a generic aarch64 U-Boot for PPL, although it
> > would be quite large with all the drivers. Perhaps we could start by
> > having a generic Rockchip one, for example.
> 
> We already have this for Qualcomm. Some small QoL things still need to go
> upstream but you can build a single U-Boot binary and boot it on a bunch of
> differences devices just by using the right DTB. See this build script for
> example which builds for just a few devices:
> 
> https://gitlab.com/sdm845-mainline/validation/-/blob/main/build_uboot.sh
> 
> I think a bunch of things in mach-snapdragon could be moved to a generic
> mach-aarch64 that could also target other SoCs like Rockchip or Mediatek.
> I'd be super interested in helping to make this happen.
> 
> Probably would even want to put more things into common code so other
> architectures can adopt it (and make themselves smaller), then mach-aarch64
> can just be a stub for devices that are fully generic.

I'm not sure how this works, exactly. Setting aside "U-Boot as EFI
application" (which could use EFI API calls for device specific
implementation of things like reading storage devices), there's still
the case of someone somewhere needs to do the device details. What I
had in mind is later in the email.

> The other potential concern with a generic aarch64 target is that we then
> lose track of what devices are actually supported. It would be nice to have
> something like a list of DTBs either in U-Boot or in some associated
> infrastructure we use to build reference images.
> 
> Which all ties back to the goal of providing distro-agnostic U-Boot images
> to make Qualcomm (and other?) Android phones capable of running more Linux
> distros.
> 
> Sorry for the big thought-dump, this has been on my mind for a while and
> since it seems like something you're both also interested in I just wanted
> to offer my perspective as a device and distro maintainer as well.

It's good to have more thoughts about all of this, especially from
someone that worries about that from more than just the bootloader
itself use case. Implementation wise, we could in theory start with
something like:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index da6f11749343..111e3c4b6059 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -600,6 +600,10 @@ choice
 	prompt "Target select"
 	default TARGET_HIKEY
 
+config ARCH_MULTI_V8
+	bool "Multiple Aarch64 SoC support"
+	select ARCH_SNAPDRAGON
+
 config ARCH_AT91
 	bool "Atmel AT91"
 	select GPIO_EXTRA_HEADER
@@ -1099,27 +1103,6 @@ config ARCH_RENESAS
 	imply SYS_THUMB_BUILD
 	imply ARCH_MISC_INIT if DISPLAY_CPUINFO
 
-config ARCH_SNAPDRAGON
-	bool "Qualcomm Snapdragon SoCs"
-	select ARM64
-	select DM
-	select DM_GPIO
-	select DM_SERIAL
-	select DM_RESET
-	select POWER_DOMAIN
-	select GPIO_EXTRA_HEADER
-	select MSM_SMEM
-	select OF_CONTROL
-	select OF_SEPARATE
-	select SMEM
-	select SPMI
-	select BOARD_LATE_INIT
-	select OF_BOARD
-	select SAVE_PREV_BL_FDT_ADDR
-	select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
-	imply OF_UPSTREAM
-	imply CMD_DM
-
 config ARCH_SOCFPGA
 	bool "Altera SOCFPGA family"
 	select ARCH_EARLY_INIT_R
@@ -1977,19 +1960,6 @@ config ARCH_UNIPHIER
 	  Support for UniPhier SoC family developed by Socionext Inc.
 	  (formerly, System LSI Business Division of Panasonic Corporation)
 
-config ARCH_SYNQUACER
-	bool "Socionext SynQuacer SoCs"
-	select ARM64
-	select DM
-	select GIC_V3
-	select PSCI_RESET
-	select SYSRESET
-	select SYSRESET_PSCI
-	select OF_CONTROL
-	help
-	  Support for SynQuacer SoC family developed by Socionext Inc.
-	  This SoC is used on 96boards EE DeveloperBox.
-
 config ARCH_STM32
 	bool "Support STMicroelectronics STM32 MCU with cortex M"
 	select CPU_V7M
@@ -2169,6 +2139,45 @@ config ARCH_GXP
 
 endchoice
 
+menu "Aarch64 Multiple Platform SoC options"
+	depends on ARCH_MULTI_V8
+
+config ARCH_SNAPDRAGON
+	bool "Qualcomm Snapdragon SoCs"
+	select ARM64
+	select DM
+	select DM_GPIO
+	select DM_SERIAL
+	select DM_RESET
+	select POWER_DOMAIN
+	select GPIO_EXTRA_HEADER
+	select MSM_SMEM
+	select OF_CONTROL
+	select OF_SEPARATE
+	select SMEM
+	select SPMI
+	select BOARD_LATE_INIT
+	select OF_BOARD
+	select SAVE_PREV_BL_FDT_ADDR
+	select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
+	imply OF_UPSTREAM
+	imply CMD_DM
+
+config ARCH_SYNQUACER
+	bool "Socionext SynQuacer SoCs"
+	select ARM64
+	select DM
+	select GIC_V3
+	select PSCI_RESET
+	select SYSRESET
+	select SYSRESET_PSCI
+	select OF_CONTROL
+	help
+	  Support for SynQuacer SoC family developed by Socionext Inc.
+	  This SoC is used on 96boards EE DeveloperBox.
+
+endmenu
+
 config SUPPORT_PASSING_ATAGS
 	bool "Support pre-devicetree ATAG-based booting"
 	depends on !ARM64


Which for qcom_defconfig (and now ARCH_MULTI_V8=y) and ARCH_SYNQUACER=y
only fails to build because our cpu reset drivers aren't quite namespace
clean enough. But that's an easy fix. However, I picked ARCH_SYNQUACER
because it's one of the platforms that doesn't have a lot of additional
code (there is no arch directory) for conflicts to arise in, and there's
no "now, SPL?" to worry about too.

But the above is where I'd start implementing, along with documenting
the run time entry requirements and some other important details. We
likely need to do some splitting up symbols so that a platform can
opt-out of ARCH_MULTI_V8, which might be required for "do care about
SPL", at least for some period of time.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 8417 bytes --]

On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > Hi,
> > 
> > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > next iteration of xPL.
> > 
> > A recent series introduced 'xPL' as the name for the various
> > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > still use filenames and function naming which uses 'spl', but could
> > potentially adjust that.
> > 
> > The major remaining problem IMO is that it is quite tricky and
> > expensive (in terms of time) to add a new phase. We also have some
> > medium-sized problems:
> > 
> > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > can be confusing, particularly when combined with ifdef and ifneq
> > 
> > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > different things. For any given option, some code uses one and some
> > the other, depending on what problems people have met along the way.
> > 
> > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > the option is enabled in one or more xPL phases, or just in U-Boot
> > proper. The only way to know is to look for $(PHASE_) etc. in the
> > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > and has not scaled well.
> > 
> > d. We need to retain an important feature: options from different
> > phases can depend on each other. As an example, we might want to
> > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > may also want to share values between phases, such as TEXT_BASE. We
> > can do this easily today, just by adding Kconfig rules.
> 
> I agree with a through c and for d there are likely some cases even if
> I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> important as the other ones.
> 
> > Proposal
> > 
> > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > These contain the values for each Kconfig option for that phase. For
> > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > 
> > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > Kconfig options which should not be enabled/valid in any xPL build.
> > There are around 200 of these.
> > 
> > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > useful in rare cases. This indicates that the option applies only to
> > U-Boot proper and is not defined in any xPL build. It is analogous to
> > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > needed at present, basically to allow access to the value for another
> > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > the address to which U-Boot should be loaded.
> > 
> > 4. There is no change to the existing defconfig files, or 'make
> > menuconfig', which works just as today, including dependencies between
> > options across all phases.
> > 
> > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > declared once for any/all phases. We can then drop the file in 2
> > above.
> > 
> > With this, maintaining Kconfig options, Makefiles and adding a new
> > phase should be considerably easier.
> 
> I think this will not make our life easier, it will make things harder.
> 
> I think what we've reached now shows that Yamada-san was correct at the
> time in saying that we were going down the wrong path with how we
> handled SPL/TPL.
> 
> My request instead is:
> - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
>   DM_MMC) as a prefix.
> - Likely need to introduce a PPL symbol as you suggest.
> - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> - Split something like rockpro64-rk3399_defconfig in to
>   rockpro64-rk3399_ppl_defconfig
>   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
>   and add Makefile logic such that for X_defconfig as a build target but
>   not configs/X_defconfig not existing, we see if any of
>   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
>   subdirectories of our object directory, and then using binman combine
>   as needed.
>   - Maybe instead the Makefile logic above we would parse X_defconfig
>     and see if it's a different format of say PHASE:file to make it
>     easier to say share a single TPL config with all rk3399, have a few
>     common SPL configs and then just a board specific PPL.
> 
> This solves (a) by removing them entirely. This solves (b) by removing
> the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> Linux Kernel again. This solves (c) again by removing it entirely.

Lets come back up here, to my proposal, since parts of it seem to have
not been clear enough. While what I'm proposing should work for any
platform and xPL -> xPL -> ... -> PPL, for this example let us assume
rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
compare with today, it will be helpful to run "make
O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
resulting .config file available.

There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
lines such as:
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_ROCKCHIP_RK3399=y
CONFIG_TPL=y

When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
the resulting .config file will contain lines such as:
# CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
as this only makes sense in the context of building something that will
be TPL.

A more complex example is that it will also contain:
CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y

Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
be able to be simplified (and spl_common.c should be renamed to
xpl_common.c) to:
obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o

The .config file here will also contain:
CONFIG_DM_SERIAL=y

What it will not contain is:
CONFIG_TPL_DM_SERIAL=y

This is because there is no 'config TPL_DM_SERIAL' option in
drivers/serial/Kconfig anymore.

When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
/tmp/rockpro64-rk3399_tpl would be similar to the results as under
"/tmp/rockpro64-rk3399/tpl/" when building today.

The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
to the tpl one, except with SPL-only-ever-valid options such as
CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
would only get similar results to what is under the spl/ directory
today.

Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
important difference is what you do not have. You do not have:
CONFIG_SPL=y
CONFIG_TPL=y

Because we are not building SPL nor TPL. We're just making full U-Boot
itself. This is where in more full examples and with additional
restructure a "generic-arm64_ppl_defconfig" makes sense and be used
instead.

This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
little unsure which of the things I mentioned above is best. It's
either:
a) Does not exist, top-level Makefile says roughly:
%_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
  make O=$(objdir)/tpl %_tpl_defconfig all
  make O=$(objdir)/spl %_spl_defconfig all
  make O=$(objdir)/ppl %_ppl_defconfig all

But this might be too rigid.
b) It contains:
PHASE:VPL:rockpro64-rk3399_vpl_defconfig
PHASE:TPL:rockpro64-rk3399_tpl_defconfig
PHASE:SPL:rockpro64-rk3399_spl_defconfig
PHASE:PPL:rockpro64-rk3399_ppl_defconfig
And the top-level Makefile looks like:
%_defconfig:
  grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
  foreach line in $@
    make O=$(objdir)/$PHASE $CONFIGFILE all

It could also be some other suggestion.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > Hi,
> > >
> > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > next iteration of xPL.
> > >
> > > A recent series introduced 'xPL' as the name for the various
> > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > still use filenames and function naming which uses 'spl', but could
> > > potentially adjust that.
> > >
> > > The major remaining problem IMO is that it is quite tricky and
> > > expensive (in terms of time) to add a new phase. We also have some
> > > medium-sized problems:
> > >
> > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > can be confusing, particularly when combined with ifdef and ifneq
> > >
> > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > different things. For any given option, some code uses one and some
> > > the other, depending on what problems people have met along the way.
> > >
> > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > and has not scaled well.
> > >
> > > d. We need to retain an important feature: options from different
> > > phases can depend on each other. As an example, we might want to
> > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > may also want to share values between phases, such as TEXT_BASE. We
> > > can do this easily today, just by adding Kconfig rules.
> >
> > I agree with a through c and for d there are likely some cases even if
> > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > important as the other ones.
> >
> > > Proposal
> > >
> > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > These contain the values for each Kconfig option for that phase. For
> > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > >
> > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > Kconfig options which should not be enabled/valid in any xPL build.
> > > There are around 200 of these.
> > >
> > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > useful in rare cases. This indicates that the option applies only to
> > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > needed at present, basically to allow access to the value for another
> > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > the address to which U-Boot should be loaded.
> > >
> > > 4. There is no change to the existing defconfig files, or 'make
> > > menuconfig', which works just as today, including dependencies between
> > > options across all phases.
> > >
> > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > declared once for any/all phases. We can then drop the file in 2
> > > above.
> > >
> > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > phase should be considerably easier.
> >
> > I think this will not make our life easier, it will make things harder.
> >
> > I think what we've reached now shows that Yamada-san was correct at the
> > time in saying that we were going down the wrong path with how we
> > handled SPL/TPL.
> >
> > My request instead is:
> > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> >   DM_MMC) as a prefix.
> > - Likely need to introduce a PPL symbol as you suggest.
> > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > - Split something like rockpro64-rk3399_defconfig in to
> >   rockpro64-rk3399_ppl_defconfig
> >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> >   and add Makefile logic such that for X_defconfig as a build target but
> >   not configs/X_defconfig not existing, we see if any of
> >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> >   subdirectories of our object directory, and then using binman combine
> >   as needed.
> >   - Maybe instead the Makefile logic above we would parse X_defconfig
> >     and see if it's a different format of say PHASE:file to make it
> >     easier to say share a single TPL config with all rk3399, have a few
> >     common SPL configs and then just a board specific PPL.
> >
> > This solves (a) by removing them entirely. This solves (b) by removing
> > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > Linux Kernel again. This solves (c) again by removing it entirely.
>
> Lets come back up here, to my proposal, since parts of it seem to have
> not been clear enough. While what I'm proposing should work for any
> platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> compare with today, it will be helpful to run "make
> O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> resulting .config file available.
>
> There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> lines such as:
> CONFIG_ARM=y
> CONFIG_ARCH_ROCKCHIP=y
> CONFIG_ROCKCHIP_RK3399=y
> CONFIG_TPL=y
>
> When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> the resulting .config file will contain lines such as:
> # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> as this only makes sense in the context of building something that will
> be TPL.
>
> A more complex example is that it will also contain:
> CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
>
> Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> be able to be simplified (and spl_common.c should be renamed to
> xpl_common.c) to:
> obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
>
> The .config file here will also contain:
> CONFIG_DM_SERIAL=y
>
> What it will not contain is:
> CONFIG_TPL_DM_SERIAL=y
>
> This is because there is no 'config TPL_DM_SERIAL' option in
> drivers/serial/Kconfig anymore.
>
> When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> "/tmp/rockpro64-rk3399/tpl/" when building today.
>
> The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> to the tpl one, except with SPL-only-ever-valid options such as
> CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> would only get similar results to what is under the spl/ directory
> today.
>
> Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> important difference is what you do not have. You do not have:
> CONFIG_SPL=y
> CONFIG_TPL=y
>
> Because we are not building SPL nor TPL. We're just making full U-Boot
> itself. This is where in more full examples and with additional
> restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> instead.
>
> This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> little unsure which of the things I mentioned above is best. It's
> either:
> a) Does not exist, top-level Makefile says roughly:
> %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
>   make O=$(objdir)/tpl %_tpl_defconfig all
>   make O=$(objdir)/spl %_spl_defconfig all
>   make O=$(objdir)/ppl %_ppl_defconfig all
>
> But this might be too rigid.
> b) It contains:
> PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> PHASE:SPL:rockpro64-rk3399_spl_defconfig
> PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> And the top-level Makefile looks like:
> %_defconfig:
>   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
>   foreach line in $@
>     make O=$(objdir)/$PHASE $CONFIGFILE all
>
> It could also be some other suggestion.

Thanks for writing that up. It is somewhat clearer.

What happens to the Makefiles? Do they still have $(PHASE_) in them?
If so, what change is caused by having/not having it on any particular
line, with your proposed build system?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 9723 bytes --]

On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > next iteration of xPL.
> > > >
> > > > A recent series introduced 'xPL' as the name for the various
> > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > still use filenames and function naming which uses 'spl', but could
> > > > potentially adjust that.
> > > >
> > > > The major remaining problem IMO is that it is quite tricky and
> > > > expensive (in terms of time) to add a new phase. We also have some
> > > > medium-sized problems:
> > > >
> > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > can be confusing, particularly when combined with ifdef and ifneq
> > > >
> > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > different things. For any given option, some code uses one and some
> > > > the other, depending on what problems people have met along the way.
> > > >
> > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > and has not scaled well.
> > > >
> > > > d. We need to retain an important feature: options from different
> > > > phases can depend on each other. As an example, we might want to
> > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > can do this easily today, just by adding Kconfig rules.
> > >
> > > I agree with a through c and for d there are likely some cases even if
> > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > important as the other ones.
> > >
> > > > Proposal
> > > >
> > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > These contain the values for each Kconfig option for that phase. For
> > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > >
> > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > There are around 200 of these.
> > > >
> > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > useful in rare cases. This indicates that the option applies only to
> > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > needed at present, basically to allow access to the value for another
> > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > the address to which U-Boot should be loaded.
> > > >
> > > > 4. There is no change to the existing defconfig files, or 'make
> > > > menuconfig', which works just as today, including dependencies between
> > > > options across all phases.
> > > >
> > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > declared once for any/all phases. We can then drop the file in 2
> > > > above.
> > > >
> > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > phase should be considerably easier.
> > >
> > > I think this will not make our life easier, it will make things harder.
> > >
> > > I think what we've reached now shows that Yamada-san was correct at the
> > > time in saying that we were going down the wrong path with how we
> > > handled SPL/TPL.
> > >
> > > My request instead is:
> > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > >   DM_MMC) as a prefix.
> > > - Likely need to introduce a PPL symbol as you suggest.
> > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > - Split something like rockpro64-rk3399_defconfig in to
> > >   rockpro64-rk3399_ppl_defconfig
> > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > >   and add Makefile logic such that for X_defconfig as a build target but
> > >   not configs/X_defconfig not existing, we see if any of
> > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > >   subdirectories of our object directory, and then using binman combine
> > >   as needed.
> > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > >     and see if it's a different format of say PHASE:file to make it
> > >     easier to say share a single TPL config with all rk3399, have a few
> > >     common SPL configs and then just a board specific PPL.
> > >
> > > This solves (a) by removing them entirely. This solves (b) by removing
> > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > Linux Kernel again. This solves (c) again by removing it entirely.
> >
> > Lets come back up here, to my proposal, since parts of it seem to have
> > not been clear enough. While what I'm proposing should work for any
> > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > compare with today, it will be helpful to run "make
> > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > resulting .config file available.
> >
> > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > lines such as:
> > CONFIG_ARM=y
> > CONFIG_ARCH_ROCKCHIP=y
> > CONFIG_ROCKCHIP_RK3399=y
> > CONFIG_TPL=y
> >
> > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > the resulting .config file will contain lines such as:
> > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > as this only makes sense in the context of building something that will
> > be TPL.
> >
> > A more complex example is that it will also contain:
> > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> >
> > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > be able to be simplified (and spl_common.c should be renamed to
> > xpl_common.c) to:
> > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> >
> > The .config file here will also contain:
> > CONFIG_DM_SERIAL=y
> >
> > What it will not contain is:
> > CONFIG_TPL_DM_SERIAL=y
> >
> > This is because there is no 'config TPL_DM_SERIAL' option in
> > drivers/serial/Kconfig anymore.
> >
> > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > "/tmp/rockpro64-rk3399/tpl/" when building today.
> >
> > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > to the tpl one, except with SPL-only-ever-valid options such as
> > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > would only get similar results to what is under the spl/ directory
> > today.
> >
> > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > important difference is what you do not have. You do not have:
> > CONFIG_SPL=y
> > CONFIG_TPL=y
> >
> > Because we are not building SPL nor TPL. We're just making full U-Boot
> > itself. This is where in more full examples and with additional
> > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > instead.
> >
> > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > little unsure which of the things I mentioned above is best. It's
> > either:
> > a) Does not exist, top-level Makefile says roughly:
> > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> >   make O=$(objdir)/tpl %_tpl_defconfig all
> >   make O=$(objdir)/spl %_spl_defconfig all
> >   make O=$(objdir)/ppl %_ppl_defconfig all
> >
> > But this might be too rigid.
> > b) It contains:
> > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > And the top-level Makefile looks like:
> > %_defconfig:
> >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> >   foreach line in $@
> >     make O=$(objdir)/$PHASE $CONFIGFILE all
> >
> > It could also be some other suggestion.
> 
> Thanks for writing that up. It is somewhat clearer.
> 
> What happens to the Makefiles? Do they still have $(PHASE_) in them?

No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
CONFIG_FIT=y (or more likely, only the resulting .config would say
CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > next iteration of xPL.
> > > > >
> > > > > A recent series introduced 'xPL' as the name for the various
> > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > still use filenames and function naming which uses 'spl', but could
> > > > > potentially adjust that.
> > > > >
> > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > medium-sized problems:
> > > > >
> > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > >
> > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > different things. For any given option, some code uses one and some
> > > > > the other, depending on what problems people have met along the way.
> > > > >
> > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > and has not scaled well.
> > > > >
> > > > > d. We need to retain an important feature: options from different
> > > > > phases can depend on each other. As an example, we might want to
> > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > can do this easily today, just by adding Kconfig rules.
> > > >
> > > > I agree with a through c and for d there are likely some cases even if
> > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > important as the other ones.
> > > >
> > > > > Proposal
> > > > >
> > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > These contain the values for each Kconfig option for that phase. For
> > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > >
> > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > There are around 200 of these.
> > > > >
> > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > useful in rare cases. This indicates that the option applies only to
> > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > needed at present, basically to allow access to the value for another
> > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > the address to which U-Boot should be loaded.
> > > > >
> > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > menuconfig', which works just as today, including dependencies between
> > > > > options across all phases.
> > > > >
> > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > above.
> > > > >
> > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > phase should be considerably easier.
> > > >
> > > > I think this will not make our life easier, it will make things harder.
> > > >
> > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > time in saying that we were going down the wrong path with how we
> > > > handled SPL/TPL.
> > > >
> > > > My request instead is:
> > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > >   DM_MMC) as a prefix.
> > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > - Split something like rockpro64-rk3399_defconfig in to
> > > >   rockpro64-rk3399_ppl_defconfig
> > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > >   not configs/X_defconfig not existing, we see if any of
> > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > >   subdirectories of our object directory, and then using binman combine
> > > >   as needed.
> > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > >     and see if it's a different format of say PHASE:file to make it
> > > >     easier to say share a single TPL config with all rk3399, have a few
> > > >     common SPL configs and then just a board specific PPL.
> > > >
> > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > >
> > > Lets come back up here, to my proposal, since parts of it seem to have
> > > not been clear enough. While what I'm proposing should work for any
> > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > compare with today, it will be helpful to run "make
> > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > resulting .config file available.
> > >
> > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > lines such as:
> > > CONFIG_ARM=y
> > > CONFIG_ARCH_ROCKCHIP=y
> > > CONFIG_ROCKCHIP_RK3399=y
> > > CONFIG_TPL=y
> > >
> > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > the resulting .config file will contain lines such as:
> > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > as this only makes sense in the context of building something that will
> > > be TPL.
> > >
> > > A more complex example is that it will also contain:
> > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > >
> > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > be able to be simplified (and spl_common.c should be renamed to
> > > xpl_common.c) to:
> > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > >
> > > The .config file here will also contain:
> > > CONFIG_DM_SERIAL=y
> > >
> > > What it will not contain is:
> > > CONFIG_TPL_DM_SERIAL=y
> > >
> > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > drivers/serial/Kconfig anymore.
> > >
> > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > >
> > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > to the tpl one, except with SPL-only-ever-valid options such as
> > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > would only get similar results to what is under the spl/ directory
> > > today.
> > >
> > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > important difference is what you do not have. You do not have:
> > > CONFIG_SPL=y
> > > CONFIG_TPL=y
> > >
> > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > itself. This is where in more full examples and with additional
> > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > instead.
> > >
> > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > little unsure which of the things I mentioned above is best. It's
> > > either:
> > > a) Does not exist, top-level Makefile says roughly:
> > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > >   make O=$(objdir)/spl %_spl_defconfig all
> > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > >
> > > But this might be too rigid.
> > > b) It contains:
> > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > And the top-level Makefile looks like:
> > > %_defconfig:
> > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > >   foreach line in $@
> > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > >
> > > It could also be some other suggestion.
> >
> > Thanks for writing that up. It is somewhat clearer.
> >
> > What happens to the Makefiles? Do they still have $(PHASE_) in them?
>
> No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> CONFIG_FIT=y (or more likely, only the resulting .config would say
> CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).

But just above you said:

> I believe this proposal will lead to the code and Makefiles being less
> clear than they are today. The line:
> drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> will become:
> drivers/Makefile:obj-$(CONFIG_BLK) += block/
> without being clear that it could reference either full U-Boot (PPL) or
> some xPL phase. While the same Makefile will continue to have (comments
> my own):
> obj-y += mtd/ # Subdirectory Makefiles control build contents
> obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
>
> And so the situation for humans will be worse off than today because
> while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> what can and cannot be enabled in PPL vs xPL.
>
> Doing "something" is not better than doing nothing in this case.

So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 12141 bytes --]

On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > next iteration of xPL.
> > > > > >
> > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > potentially adjust that.
> > > > > >
> > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > medium-sized problems:
> > > > > >
> > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > >
> > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > different things. For any given option, some code uses one and some
> > > > > > the other, depending on what problems people have met along the way.
> > > > > >
> > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > and has not scaled well.
> > > > > >
> > > > > > d. We need to retain an important feature: options from different
> > > > > > phases can depend on each other. As an example, we might want to
> > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > can do this easily today, just by adding Kconfig rules.
> > > > >
> > > > > I agree with a through c and for d there are likely some cases even if
> > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > important as the other ones.
> > > > >
> > > > > > Proposal
> > > > > >
> > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > >
> > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > There are around 200 of these.
> > > > > >
> > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > needed at present, basically to allow access to the value for another
> > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > the address to which U-Boot should be loaded.
> > > > > >
> > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > options across all phases.
> > > > > >
> > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > above.
> > > > > >
> > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > phase should be considerably easier.
> > > > >
> > > > > I think this will not make our life easier, it will make things harder.
> > > > >
> > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > time in saying that we were going down the wrong path with how we
> > > > > handled SPL/TPL.
> > > > >
> > > > > My request instead is:
> > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > >   DM_MMC) as a prefix.
> > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > >   rockpro64-rk3399_ppl_defconfig
> > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > >   not configs/X_defconfig not existing, we see if any of
> > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > >   subdirectories of our object directory, and then using binman combine
> > > > >   as needed.
> > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > >     and see if it's a different format of say PHASE:file to make it
> > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > >     common SPL configs and then just a board specific PPL.
> > > > >
> > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > >
> > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > not been clear enough. While what I'm proposing should work for any
> > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > compare with today, it will be helpful to run "make
> > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > resulting .config file available.
> > > >
> > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > lines such as:
> > > > CONFIG_ARM=y
> > > > CONFIG_ARCH_ROCKCHIP=y
> > > > CONFIG_ROCKCHIP_RK3399=y
> > > > CONFIG_TPL=y
> > > >
> > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > the resulting .config file will contain lines such as:
> > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > as this only makes sense in the context of building something that will
> > > > be TPL.
> > > >
> > > > A more complex example is that it will also contain:
> > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > >
> > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > be able to be simplified (and spl_common.c should be renamed to
> > > > xpl_common.c) to:
> > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > >
> > > > The .config file here will also contain:
> > > > CONFIG_DM_SERIAL=y
> > > >
> > > > What it will not contain is:
> > > > CONFIG_TPL_DM_SERIAL=y
> > > >
> > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > drivers/serial/Kconfig anymore.
> > > >
> > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > >
> > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > would only get similar results to what is under the spl/ directory
> > > > today.
> > > >
> > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > important difference is what you do not have. You do not have:
> > > > CONFIG_SPL=y
> > > > CONFIG_TPL=y
> > > >
> > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > itself. This is where in more full examples and with additional
> > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > instead.
> > > >
> > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > little unsure which of the things I mentioned above is best. It's
> > > > either:
> > > > a) Does not exist, top-level Makefile says roughly:
> > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > >
> > > > But this might be too rigid.
> > > > b) It contains:
> > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > And the top-level Makefile looks like:
> > > > %_defconfig:
> > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > >   foreach line in $@
> > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > >
> > > > It could also be some other suggestion.
> > >
> > > Thanks for writing that up. It is somewhat clearer.
> > >
> > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> >
> > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> 
> But just above you said:
> 
> > I believe this proposal will lead to the code and Makefiles being less
> > clear than they are today. The line:
> > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > will become:
> > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > without being clear that it could reference either full U-Boot (PPL) or
> > some xPL phase. While the same Makefile will continue to have (comments
> > my own):
> > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> >
> > And so the situation for humans will be worse off than today because
> > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > what can and cannot be enabled in PPL vs xPL.
> >
> > Doing "something" is not better than doing nothing in this case.
> 
> So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?

Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.

Or to try and explain differently, with your proposal "I have a problem,
and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
proposal "I have a problem, and I want to see what my SPL build has with
CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
symbol I set, I can solve my problem."

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 13217 bytes --]

On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > next iteration of xPL.
> > > > > > >
> > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > potentially adjust that.
> > > > > > >
> > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > medium-sized problems:
> > > > > > >
> > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > >
> > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > different things. For any given option, some code uses one and some
> > > > > > > the other, depending on what problems people have met along the way.
> > > > > > >
> > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > and has not scaled well.
> > > > > > >
> > > > > > > d. We need to retain an important feature: options from different
> > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > >
> > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > important as the other ones.
> > > > > >
> > > > > > > Proposal
> > > > > > >
> > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > >
> > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > There are around 200 of these.
> > > > > > >
> > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > the address to which U-Boot should be loaded.
> > > > > > >
> > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > options across all phases.
> > > > > > >
> > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > above.
> > > > > > >
> > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > phase should be considerably easier.
> > > > > >
> > > > > > I think this will not make our life easier, it will make things harder.
> > > > > >
> > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > time in saying that we were going down the wrong path with how we
> > > > > > handled SPL/TPL.
> > > > > >
> > > > > > My request instead is:
> > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > >   DM_MMC) as a prefix.
> > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > >   as needed.
> > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > >     common SPL configs and then just a board specific PPL.
> > > > > >
> > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > >
> > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > not been clear enough. While what I'm proposing should work for any
> > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > compare with today, it will be helpful to run "make
> > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > resulting .config file available.
> > > > >
> > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > lines such as:
> > > > > CONFIG_ARM=y
> > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > CONFIG_TPL=y
> > > > >
> > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > the resulting .config file will contain lines such as:
> > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > as this only makes sense in the context of building something that will
> > > > > be TPL.
> > > > >
> > > > > A more complex example is that it will also contain:
> > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > >
> > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > xpl_common.c) to:
> > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > >
> > > > > The .config file here will also contain:
> > > > > CONFIG_DM_SERIAL=y
> > > > >
> > > > > What it will not contain is:
> > > > > CONFIG_TPL_DM_SERIAL=y
> > > > >
> > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > drivers/serial/Kconfig anymore.
> > > > >
> > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > >
> > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > would only get similar results to what is under the spl/ directory
> > > > > today.
> > > > >
> > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > important difference is what you do not have. You do not have:
> > > > > CONFIG_SPL=y
> > > > > CONFIG_TPL=y
> > > > >
> > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > itself. This is where in more full examples and with additional
> > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > instead.
> > > > >
> > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > little unsure which of the things I mentioned above is best. It's
> > > > > either:
> > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > >
> > > > > But this might be too rigid.
> > > > > b) It contains:
> > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > And the top-level Makefile looks like:
> > > > > %_defconfig:
> > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > >   foreach line in $@
> > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > >
> > > > > It could also be some other suggestion.
> > > >
> > > > Thanks for writing that up. It is somewhat clearer.
> > > >
> > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > >
> > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > 
> > But just above you said:
> > 
> > > I believe this proposal will lead to the code and Makefiles being less
> > > clear than they are today. The line:
> > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > will become:
> > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > without being clear that it could reference either full U-Boot (PPL) or
> > > some xPL phase. While the same Makefile will continue to have (comments
> > > my own):
> > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > >
> > > And so the situation for humans will be worse off than today because
> > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > what can and cannot be enabled in PPL vs xPL.
> > >
> > > Doing "something" is not better than doing nothing in this case.
> > 
> > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> 
> Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> 
> Or to try and explain differently, with your proposal "I have a problem,
> and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> proposal "I have a problem, and I want to see what my SPL build has with
> CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> symbol I set, I can solve my problem."

My other try here was a bit unclear actually because of the confusion
state your proposal gives us. Try try again directly, the problem is
that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
This will be true for many but not all SPL symbols as
CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
I think can just be replaced with $(PHASE_) but I haven't confirmed (I
think it does show that the old way was confusing however).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > next iteration of xPL.
> > > > > > > >
> > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > potentially adjust that.
> > > > > > > >
> > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > medium-sized problems:
> > > > > > > >
> > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > >
> > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > >
> > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > and has not scaled well.
> > > > > > > >
> > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > >
> > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > important as the other ones.
> > > > > > >
> > > > > > > > Proposal
> > > > > > > >
> > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > >
> > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > There are around 200 of these.
> > > > > > > >
> > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > >
> > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > options across all phases.
> > > > > > > >
> > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > above.
> > > > > > > >
> > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > phase should be considerably easier.
> > > > > > >
> > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > >
> > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > handled SPL/TPL.
> > > > > > >
> > > > > > > My request instead is:
> > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > >   DM_MMC) as a prefix.
> > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > >   as needed.
> > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > >
> > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > >
> > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > compare with today, it will be helpful to run "make
> > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > resulting .config file available.
> > > > > >
> > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > lines such as:
> > > > > > CONFIG_ARM=y
> > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > CONFIG_TPL=y
> > > > > >
> > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > the resulting .config file will contain lines such as:
> > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > as this only makes sense in the context of building something that will
> > > > > > be TPL.
> > > > > >
> > > > > > A more complex example is that it will also contain:
> > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > >
> > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > xpl_common.c) to:
> > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > >
> > > > > > The .config file here will also contain:
> > > > > > CONFIG_DM_SERIAL=y
> > > > > >
> > > > > > What it will not contain is:
> > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > >
> > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > drivers/serial/Kconfig anymore.
> > > > > >
> > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > >
> > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > would only get similar results to what is under the spl/ directory
> > > > > > today.
> > > > > >
> > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > important difference is what you do not have. You do not have:
> > > > > > CONFIG_SPL=y
> > > > > > CONFIG_TPL=y
> > > > > >
> > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > itself. This is where in more full examples and with additional
> > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > instead.
> > > > > >
> > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > either:
> > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > >
> > > > > > But this might be too rigid.
> > > > > > b) It contains:
> > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > And the top-level Makefile looks like:
> > > > > > %_defconfig:
> > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > >   foreach line in $@
> > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > >
> > > > > > It could also be some other suggestion.
> > > > >
> > > > > Thanks for writing that up. It is somewhat clearer.
> > > > >
> > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > >
> > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > >
> > > But just above you said:
> > >
> > > > I believe this proposal will lead to the code and Makefiles being less
> > > > clear than they are today. The line:
> > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > will become:
> > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > my own):
> > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > >
> > > > And so the situation for humans will be worse off than today because
> > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > what can and cannot be enabled in PPL vs xPL.
> > > >
> > > > Doing "something" is not better than doing nothing in this case.
> > >
> > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> >
> > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> >

> With my
> proposal "I have a problem, and I want to see what my SPL build has with
> CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> symbol I set, I can solve my problem."

There will be at least some matches, e.g. CONFIG_SPL_BLK in the
defconfig files and 'config SPL_BLK' in the source tree.

> > Or to try and explain differently, with your proposal "I have a problem,
> > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > proposal "I have a problem, and I want to see what my SPL build has with
> > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > symbol I set, I can solve my problem."

Well, CONFIG_BLK will be in the source tree; it just means different
things for different phases.

It sounds like you want to get rid of the xPL prefixes for Kconfig
options, and that overrides all other considerations?

>
> My other try here was a bit unclear actually because of the confusion
> state your proposal gives us. Try try again directly, the problem is
> that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> This will be true for many but not all SPL symbols as
> CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> think it does show that the old way was confusing however).

OK, I think I see. You don't want people to have to 'know' that
CONFIG_xPL_xxx is used to control feature xxx in each xPL build?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 18644 bytes --]

On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > next iteration of xPL.
> > > > > > > > >
> > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > potentially adjust that.
> > > > > > > > >
> > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > medium-sized problems:
> > > > > > > > >
> > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > >
> > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > >
> > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > and has not scaled well.
> > > > > > > > >
> > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > >
> > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > important as the other ones.
> > > > > > > >
> > > > > > > > > Proposal
> > > > > > > > >
> > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > >
> > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > There are around 200 of these.
> > > > > > > > >
> > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > >
> > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > options across all phases.
> > > > > > > > >
> > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > above.
> > > > > > > > >
> > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > phase should be considerably easier.
> > > > > > > >
> > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > >
> > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > handled SPL/TPL.
> > > > > > > >
> > > > > > > > My request instead is:
> > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > >   as needed.
> > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > >
> > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > >
> > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > compare with today, it will be helpful to run "make
> > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > resulting .config file available.
> > > > > > >
> > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > lines such as:
> > > > > > > CONFIG_ARM=y
> > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > CONFIG_TPL=y
> > > > > > >
> > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > the resulting .config file will contain lines such as:
> > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > as this only makes sense in the context of building something that will
> > > > > > > be TPL.
> > > > > > >
> > > > > > > A more complex example is that it will also contain:
> > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > >
> > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > xpl_common.c) to:
> > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > >
> > > > > > > The .config file here will also contain:
> > > > > > > CONFIG_DM_SERIAL=y
> > > > > > >
> > > > > > > What it will not contain is:
> > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > >
> > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > drivers/serial/Kconfig anymore.
> > > > > > >
> > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > >
> > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > today.
> > > > > > >
> > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > important difference is what you do not have. You do not have:
> > > > > > > CONFIG_SPL=y
> > > > > > > CONFIG_TPL=y
> > > > > > >
> > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > itself. This is where in more full examples and with additional
> > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > instead.
> > > > > > >
> > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > either:
> > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > >
> > > > > > > But this might be too rigid.
> > > > > > > b) It contains:
> > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > And the top-level Makefile looks like:
> > > > > > > %_defconfig:
> > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > >   foreach line in $@
> > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > >
> > > > > > > It could also be some other suggestion.
> > > > > >
> > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > >
> > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > >
> > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > >
> > > > But just above you said:
> > > >
> > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > clear than they are today. The line:
> > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > will become:
> > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > my own):
> > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > >
> > > > > And so the situation for humans will be worse off than today because
> > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > what can and cannot be enabled in PPL vs xPL.
> > > > >
> > > > > Doing "something" is not better than doing nothing in this case.
> > > >
> > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > >
> > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > >
> 
> > With my
> > proposal "I have a problem, and I want to see what my SPL build has with
> > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > symbol I set, I can solve my problem."
> 
> There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> defconfig files and 'config SPL_BLK' in the source tree.

Yes, and that's confusing. I am arguing that your statement is more
confusing than $(PHASE_)BLK is.

> > > Or to try and explain differently, with your proposal "I have a problem,
> > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > proposal "I have a problem, and I want to see what my SPL build has with
> > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > symbol I set, I can solve my problem."
> 
> Well, CONFIG_BLK will be in the source tree; it just means different
> things for different phases.

And it will be, with your proposal, controlled by BLK or SPL_BLK or
TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
and code.

> It sounds like you want to get rid of the xPL prefixes for Kconfig
> options, and that overrides all other considerations?

It's one of the big problems we have today, and splc-working shows how
much further the duplication must go. It's why I suggested the language
modification before.

> > My other try here was a bit unclear actually because of the confusion
> > state your proposal gives us. Try try again directly, the problem is
> > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > This will be true for many but not all SPL symbols as
> > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > think it does show that the old way was confusing however).
> 
> OK, I think I see. You don't want people to have to 'know' that
> CONFIG_xPL_xxx is used to control feature xxx in each xPL build?

I'm saying they have to know that, and also know which symbols that's
not true for. And that is more confusing than today. I'm saying that
compared with today's arch/arm/mach-rockchip/Makefile the following is
worse:
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5e7edc99cdc4..3b176966f75b 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
 obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
 endif
 
-obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
+obj-$(CONFIG_RAM) += sdram.o
 
 obj-$(CONFIG_ROCKCHIP_PX30) += px30/
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/

(And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).

And this is better:

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5e7edc99cdc4..23c30f68f878 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -7,15 +7,13 @@
 # this may have entered from ATF with the stack-pointer pointing to
 # inaccessible/protected memory (and the bootrom-helper assumes that
 # the stack-pointer is valid before switching to the U-Boot stack).
-obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
-obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
-obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
-obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
-obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
+obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
+obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
+obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
+obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
+obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
 
-obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
-
-ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
+obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
 
 # Always include boot_mode.o, as we bypass it (i.e. turn it off)
 # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
@@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
 # meaning "turn it off".
 obj-y += boot_mode.o
 obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
-endif
 
-ifeq ($(CONFIG_TPL_BUILD),)
 obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
-endif
 
-obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
+obj-$(CONFIG_RAM) += sdram.o
 
+ifdef CONFIG_PPL
+# TODO: Audit these Makefiles see if they really must be PPL only
 obj-$(CONFIG_ROCKCHIP_PX30) += px30/
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
 obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
@@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
 obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
 obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
 obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
-
-# Clear out SPL objects, in case this is a TPL build
-obj-spl-$(CONFIG_TPL_BUILD) =
-
-# Now add SPL/TPL objects back into the main build
-obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
-obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
+endif
(CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > next iteration of xPL.
> > > > > > > > > >
> > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > potentially adjust that.
> > > > > > > > > >
> > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > medium-sized problems:
> > > > > > > > > >
> > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > >
> > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > >
> > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > and has not scaled well.
> > > > > > > > > >
> > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > >
> > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > important as the other ones.
> > > > > > > > >
> > > > > > > > > > Proposal
> > > > > > > > > >
> > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > >
> > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > There are around 200 of these.
> > > > > > > > > >
> > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > >
> > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > options across all phases.
> > > > > > > > > >
> > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > above.
> > > > > > > > > >
> > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > phase should be considerably easier.
> > > > > > > > >
> > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > >
> > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > handled SPL/TPL.
> > > > > > > > >
> > > > > > > > > My request instead is:
> > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > >   as needed.
> > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > >
> > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > >
> > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > resulting .config file available.
> > > > > > > >
> > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > lines such as:
> > > > > > > > CONFIG_ARM=y
> > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > CONFIG_TPL=y
> > > > > > > >
> > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > be TPL.
> > > > > > > >
> > > > > > > > A more complex example is that it will also contain:
> > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > >
> > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > xpl_common.c) to:
> > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > >
> > > > > > > > The .config file here will also contain:
> > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > >
> > > > > > > > What it will not contain is:
> > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > >
> > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > >
> > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > >
> > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > today.
> > > > > > > >
> > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > CONFIG_SPL=y
> > > > > > > > CONFIG_TPL=y
> > > > > > > >
> > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > instead.
> > > > > > > >
> > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > either:
> > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > >
> > > > > > > > But this might be too rigid.
> > > > > > > > b) It contains:
> > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > And the top-level Makefile looks like:
> > > > > > > > %_defconfig:
> > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > >   foreach line in $@
> > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > >
> > > > > > > > It could also be some other suggestion.
> > > > > > >
> > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > >
> > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > >
> > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > >
> > > > > But just above you said:
> > > > >
> > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > clear than they are today. The line:
> > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > will become:
> > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > my own):
> > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > >
> > > > > > And so the situation for humans will be worse off than today because
> > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > >
> > > > > > Doing "something" is not better than doing nothing in this case.
> > > > >
> > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > >
> > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > >
> >
> > > With my
> > > proposal "I have a problem, and I want to see what my SPL build has with
> > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > symbol I set, I can solve my problem."
> >
> > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > defconfig files and 'config SPL_BLK' in the source tree.
>
> Yes, and that's confusing. I am arguing that your statement is more
> confusing than $(PHASE_)BLK is.

OK

>
> > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > symbol I set, I can solve my problem."
> >
> > Well, CONFIG_BLK will be in the source tree; it just means different
> > things for different phases.
>
> And it will be, with your proposal, controlled by BLK or SPL_BLK or
> TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> and code.
>
> > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > options, and that overrides all other considerations?
>
> It's one of the big problems we have today, and splc-working shows how
> much further the duplication must go. It's why I suggested the language
> modification before.
>
> > > My other try here was a bit unclear actually because of the confusion
> > > state your proposal gives us. Try try again directly, the problem is
> > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > This will be true for many but not all SPL symbols as
> > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > think it does show that the old way was confusing however).
> >
> > OK, I think I see. You don't want people to have to 'know' that
> > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
>
> I'm saying they have to know that, and also know which symbols that's
> not true for. And that is more confusing than today. I'm saying that
> compared with today's arch/arm/mach-rockchip/Makefile the following is
> worse:
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 5e7edc99cdc4..3b176966f75b 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
>  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
>  endif
>
> -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> +obj-$(CONFIG_RAM) += sdram.o
>
>  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
>  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
>
> (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
>
> And this is better:
>
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 5e7edc99cdc4..23c30f68f878 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -7,15 +7,13 @@
>  # this may have entered from ATF with the stack-pointer pointing to
>  # inaccessible/protected memory (and the bootrom-helper assumes that
>  # the stack-pointer is valid before switching to the U-Boot stack).
> -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
>
> -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> -
> -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
>
>  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
>  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
>  # meaning "turn it off".
>  obj-y += boot_mode.o
>  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> -endif
>
> -ifeq ($(CONFIG_TPL_BUILD),)
>  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> -endif
>
> -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> +obj-$(CONFIG_RAM) += sdram.o
>
> +ifdef CONFIG_PPL
> +# TODO: Audit these Makefiles see if they really must be PPL only
>  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
>  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
>  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
>  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
>  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
>  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> -
> -# Clear out SPL objects, in case this is a TPL build
> -obj-spl-$(CONFIG_TPL_BUILD) =
> -
> -# Now add SPL/TPL objects back into the main build
> -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> +endif
> (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
>

This Makefile is a very strange example. I've thought about cleaning
it up a few times, but then I know someone will say it needs to be in
its own series, etc. so I've never got around to it. Even with the
current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
needlessly complex.

Anyway, with my scheme, you can still use
CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
of symbols to autoconf_spl.h for this reason. There are also places in
the code where people directly check CONFIG_SPL_xxx and these need to
work.

This surprised me:

obj-$(CONFIG_RAM) += sdram.o

Are you saying you are OK with this one, instead of, for example:

obj-$(CONFIG_TPL_RAM) += sdram.o
obj-$(CONFIG_SPL_RAM) += sdram.o
obj-$(CONFIG_RAM) += sdram.o

If so, why are you OK with that and not the others?

For this one:

> +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o

I don't understand how it can work with your scheme, since you don't
want to have any CONFIG_SPL_ things?

Also, while we are talking about Makefiles, your scheme requires a lot
of rework to get right. It won't 'just work' with existing Makefiles.
My scheme does, but for a handle of tweaks,
e.g.drivers/phy/cadence/Makefile . It even allows the $(PHASE_) things
to be kept. It also works (so far as I can tell) with your changes
above.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 23865 bytes --]

On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > >
> > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > potentially adjust that.
> > > > > > > > > > >
> > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > medium-sized problems:
> > > > > > > > > > >
> > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > >
> > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > >
> > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > and has not scaled well.
> > > > > > > > > > >
> > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > >
> > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > important as the other ones.
> > > > > > > > > >
> > > > > > > > > > > Proposal
> > > > > > > > > > >
> > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > >
> > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > >
> > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > >
> > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > options across all phases.
> > > > > > > > > > >
> > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > above.
> > > > > > > > > > >
> > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > >
> > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > >
> > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > handled SPL/TPL.
> > > > > > > > > >
> > > > > > > > > > My request instead is:
> > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > >   as needed.
> > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > >
> > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > >
> > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > resulting .config file available.
> > > > > > > > >
> > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > lines such as:
> > > > > > > > > CONFIG_ARM=y
> > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > CONFIG_TPL=y
> > > > > > > > >
> > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > be TPL.
> > > > > > > > >
> > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > >
> > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > xpl_common.c) to:
> > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > >
> > > > > > > > > The .config file here will also contain:
> > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > >
> > > > > > > > > What it will not contain is:
> > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > >
> > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > >
> > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > >
> > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > today.
> > > > > > > > >
> > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > CONFIG_SPL=y
> > > > > > > > > CONFIG_TPL=y
> > > > > > > > >
> > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > instead.
> > > > > > > > >
> > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > either:
> > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > >
> > > > > > > > > But this might be too rigid.
> > > > > > > > > b) It contains:
> > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > %_defconfig:
> > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > >   foreach line in $@
> > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > >
> > > > > > > > > It could also be some other suggestion.
> > > > > > > >
> > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > >
> > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > >
> > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > >
> > > > > > But just above you said:
> > > > > >
> > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > clear than they are today. The line:
> > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > will become:
> > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > my own):
> > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > >
> > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > >
> > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > >
> > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > >
> > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > >
> > >
> > > > With my
> > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > symbol I set, I can solve my problem."
> > >
> > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > defconfig files and 'config SPL_BLK' in the source tree.
> >
> > Yes, and that's confusing. I am arguing that your statement is more
> > confusing than $(PHASE_)BLK is.
> 
> OK
> 
> >
> > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > symbol I set, I can solve my problem."
> > >
> > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > things for different phases.
> >
> > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > and code.
> >
> > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > options, and that overrides all other considerations?
> >
> > It's one of the big problems we have today, and splc-working shows how
> > much further the duplication must go. It's why I suggested the language
> > modification before.
> >
> > > > My other try here was a bit unclear actually because of the confusion
> > > > state your proposal gives us. Try try again directly, the problem is
> > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > This will be true for many but not all SPL symbols as
> > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > think it does show that the old way was confusing however).
> > >
> > > OK, I think I see. You don't want people to have to 'know' that
> > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> >
> > I'm saying they have to know that, and also know which symbols that's
> > not true for. And that is more confusing than today. I'm saying that
> > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > worse:
> > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > index 5e7edc99cdc4..3b176966f75b 100644
> > --- a/arch/arm/mach-rockchip/Makefile
> > +++ b/arch/arm/mach-rockchip/Makefile
> > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> >  endif
> >
> > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > +obj-$(CONFIG_RAM) += sdram.o
> >
> >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> >
> > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> >
> > And this is better:
> >
> > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > index 5e7edc99cdc4..23c30f68f878 100644
> > --- a/arch/arm/mach-rockchip/Makefile
> > +++ b/arch/arm/mach-rockchip/Makefile
> > @@ -7,15 +7,13 @@
> >  # this may have entered from ATF with the stack-pointer pointing to
> >  # inaccessible/protected memory (and the bootrom-helper assumes that
> >  # the stack-pointer is valid before switching to the U-Boot stack).
> > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> >
> > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > -
> > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> >
> >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> >  # meaning "turn it off".
> >  obj-y += boot_mode.o
> >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > -endif
> >
> > -ifeq ($(CONFIG_TPL_BUILD),)
> >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > -endif
> >
> > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > +obj-$(CONFIG_RAM) += sdram.o
> >
> > +ifdef CONFIG_PPL
> > +# TODO: Audit these Makefiles see if they really must be PPL only
> >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > -
> > -# Clear out SPL objects, in case this is a TPL build
> > -obj-spl-$(CONFIG_TPL_BUILD) =
> > -
> > -# Now add SPL/TPL objects back into the main build
> > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > +endif
> > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> >
> 
> This Makefile is a very strange example. I've thought about cleaning
> it up a few times, but then I know someone will say it needs to be in
> its own series, etc. so I've never got around to it. Even with the
> current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> needlessly complex.

There's some complexity that can be removed here today, maybe. But not a
lot of it, because it's complex to build three different things when
configuring once.

> Anyway, with my scheme, you can still use
> CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions

No. You have to use it still, with yours. Because
"ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
"TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
code" but different files at TPL, SPL and PPL. And you still have to
with mine, because for the same reason. With mine, the Kconfig is:
config SPL_ROCKCHIP_COMMON_BOARD
  bool "SPL rockchip common board file"
  depends on SPL

config TPL_ROCKCHIP_COMMON_BOARD
  bool "TPL rockchip common board file"
  depends on TPL

And since you are only ever configuring for TPL or SPL or PPL (or VPL or
...) the resulting config only ever asks for the appropriate one.

> of symbols to autoconf_spl.h for this reason. There are also places in
> the code where people directly check CONFIG_SPL_xxx and these need to
> work.

Yes, this is part of the confusion I keep noting with your proposal as
it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
in code as CONFIG_SPL_xxx or as CONFIG_xxx.

> This surprised me:
> 
> obj-$(CONFIG_RAM) += sdram.o
> 
> Are you saying you are OK with this one, instead of, for example:
> 
> obj-$(CONFIG_TPL_RAM) += sdram.o
> obj-$(CONFIG_SPL_RAM) += sdram.o
> obj-$(CONFIG_RAM) += sdram.o
> 
> If so, why are you OK with that and not the others?

Because there is no:
config TPL_RAM
  bool "RAM driver in TPL"

in what I am proposing. That's why. There's one symbol because there's
the same files being built.

> For this one:
> 
> > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> 
> I don't understand how it can work with your scheme, since you don't
> want to have any CONFIG_SPL_ things?

No, that's not what I've been saying and trying to make clear with my
examples. I keep saying that there are explicitly SPL (or TPL or VPL)
only options. And these need to be named as such. And so that's the
confusion your proposal introduces (inconsistency about referring to a
symbol that has been enabled) and mine removes entirely (we only ever
refer to symbols based on their name).

> Also, while we are talking about Makefiles, your scheme requires a lot
> of rework to get right. It won't 'just work' with existing Makefiles.

In that we change from "one config, multiple passes through the entire
source tree" to "one config, one pass through the entire source tree",
yes, in the end it would.

> My scheme does, but for a handle of tweaks,
> e.g.drivers/phy/cadence/Makefile . It even allows the $(PHASE_) things
> to be kept.

As part of iterative implementation of it, what I'm proposing could
likely fake defining CONFIG_SPL_BUILD, etc so that Makefiles don't have
to be cleaned up right away. And $(PHASE_) could also be removed over
time (since it would be an empty string) if we wanted to go that route.

> It also works (so far as I can tell) with your changes
> above.

I continue to not see how that's possible. The only commonality is that
we would both remove $(PHASE_) / $(XPL_) from the Makefiles.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > >
> > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > >
> > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > >
> > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > >
> > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > >
> > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > >
> > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > >
> > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > important as the other ones.
> > > > > > > > > > >
> > > > > > > > > > > > Proposal
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > >
> > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > >
> > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > >
> > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > options across all phases.
> > > > > > > > > > > >
> > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > above.
> > > > > > > > > > > >
> > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > >
> > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > >
> > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > >
> > > > > > > > > > > My request instead is:
> > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > >   as needed.
> > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > >
> > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > >
> > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > resulting .config file available.
> > > > > > > > > >
> > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > lines such as:
> > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > >
> > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > be TPL.
> > > > > > > > > >
> > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > >
> > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > >
> > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > >
> > > > > > > > > > What it will not contain is:
> > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > >
> > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > >
> > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > >
> > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > today.
> > > > > > > > > >
> > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > >
> > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > instead.
> > > > > > > > > >
> > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > either:
> > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > >
> > > > > > > > > > But this might be too rigid.
> > > > > > > > > > b) It contains:
> > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > %_defconfig:
> > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > >   foreach line in $@
> > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > >
> > > > > > > > > > It could also be some other suggestion.
> > > > > > > > >
> > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > >
> > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > >
> > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > >
> > > > > > > But just above you said:
> > > > > > >
> > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > clear than they are today. The line:
> > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > will become:
> > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > my own):
> > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > >
> > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > >
> > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > >
> > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > >
> > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > >
> > > >
> > > > > With my
> > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > symbol I set, I can solve my problem."
> > > >
> > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > defconfig files and 'config SPL_BLK' in the source tree.
> > >
> > > Yes, and that's confusing. I am arguing that your statement is more
> > > confusing than $(PHASE_)BLK is.
> >
> > OK
> >
> > >
> > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > symbol I set, I can solve my problem."
> > > >
> > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > things for different phases.
> > >
> > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > and code.
> > >
> > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > options, and that overrides all other considerations?
> > >
> > > It's one of the big problems we have today, and splc-working shows how
> > > much further the duplication must go. It's why I suggested the language
> > > modification before.
> > >
> > > > > My other try here was a bit unclear actually because of the confusion
> > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > This will be true for many but not all SPL symbols as
> > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > think it does show that the old way was confusing however).
> > > >
> > > > OK, I think I see. You don't want people to have to 'know' that
> > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > >
> > > I'm saying they have to know that, and also know which symbols that's
> > > not true for. And that is more confusing than today. I'm saying that
> > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > worse:
> > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > index 5e7edc99cdc4..3b176966f75b 100644
> > > --- a/arch/arm/mach-rockchip/Makefile
> > > +++ b/arch/arm/mach-rockchip/Makefile
> > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > >  endif
> > >
> > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > +obj-$(CONFIG_RAM) += sdram.o
> > >
> > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > >
> > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > >
> > > And this is better:
> > >
> > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > index 5e7edc99cdc4..23c30f68f878 100644
> > > --- a/arch/arm/mach-rockchip/Makefile
> > > +++ b/arch/arm/mach-rockchip/Makefile
> > > @@ -7,15 +7,13 @@
> > >  # this may have entered from ATF with the stack-pointer pointing to
> > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > >
> > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > -
> > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > >
> > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > >  # meaning "turn it off".
> > >  obj-y += boot_mode.o
> > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > -endif
> > >
> > > -ifeq ($(CONFIG_TPL_BUILD),)
> > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > -endif
> > >
> > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > +obj-$(CONFIG_RAM) += sdram.o
> > >
> > > +ifdef CONFIG_PPL
> > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > -
> > > -# Clear out SPL objects, in case this is a TPL build
> > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > -
> > > -# Now add SPL/TPL objects back into the main build
> > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > +endif
> > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > >
> >
> > This Makefile is a very strange example. I've thought about cleaning
> > it up a few times, but then I know someone will say it needs to be in
> > its own series, etc. so I've never got around to it. Even with the
> > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > needlessly complex.
>
> There's some complexity that can be removed here today, maybe. But not a
> lot of it, because it's complex to build three different things when
> configuring once.
>
> > Anyway, with my scheme, you can still use
> > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
>
> No. You have to use it still, with yours. Because
> "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> code" but different files at TPL, SPL and PPL. And you still have to
> with mine, because for the same reason. With mine, the Kconfig is:
> config SPL_ROCKCHIP_COMMON_BOARD
>   bool "SPL rockchip common board file"
>   depends on SPL
>
> config TPL_ROCKCHIP_COMMON_BOARD
>   bool "TPL rockchip common board file"
>   depends on TPL
>
> And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> ...) the resulting config only ever asks for the appropriate one.
>
> > of symbols to autoconf_spl.h for this reason. There are also places in
> > the code where people directly check CONFIG_SPL_xxx and these need to
> > work.
>
> Yes, this is part of the confusion I keep noting with your proposal as
> it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> in code as CONFIG_SPL_xxx or as CONFIG_xxx.

If it is confusing, we can change all of them to CONFIG_xxx in a
follow-up. There is no need to mention SPL_, it just allows the
existing code to work without a wholesale change.

>
> > This surprised me:
> >
> > obj-$(CONFIG_RAM) += sdram.o
> >
> > Are you saying you are OK with this one, instead of, for example:
> >
> > obj-$(CONFIG_TPL_RAM) += sdram.o
> > obj-$(CONFIG_SPL_RAM) += sdram.o
> > obj-$(CONFIG_RAM) += sdram.o
> >
> > If so, why are you OK with that and not the others?
>
> Because there is no:
> config TPL_RAM
>   bool "RAM driver in TPL"
>
> in what I am proposing. That's why. There's one symbol because there's
> the same files being built.

OK, well that works the same for my scheme too. Either will do.

>
> > For this one:
> >
> > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> >
> > I don't understand how it can work with your scheme, since you don't
> > want to have any CONFIG_SPL_ things?
>
> No, that's not what I've been saying and trying to make clear with my
> examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> only options. And these need to be named as such. And so that's the
> confusion your proposal introduces (inconsistency about referring to a
> symbol that has been enabled) and mine removes entirely (we only ever
> refer to symbols based on their name).

Right, but you still have 'config SPL_RAM', right? Would you keep
CONFIG_IS_ENABLED() with your scheme? What goes in the autoconf_spl.h
file? Is it CONFIG_RAM or CONFIG_SPL_RAM ? If the former then your
'obj-$(CONFIG_RAM)' is confusing because you said you want to know if
something is multi-phase or not. If the latter, then yours has the
same 'confusion' as mine.

Or are you talking about a wholesale rework of Kconfig, changing
everything to work in a new way?

>
> > Also, while we are talking about Makefiles, your scheme requires a lot
> > of rework to get right. It won't 'just work' with existing Makefiles.
>
> In that we change from "one config, multiple passes through the entire
> source tree" to "one config, one pass through the entire source tree",
> yes, in the end it would.

OK

>
> > My scheme does, but for a handle of tweaks,
> > e.g.drivers/phy/cadence/Makefile . It even allows the $(PHASE_) things
> > to be kept.
>
> As part of iterative implementation of it, what I'm proposing could
> likely fake defining CONFIG_SPL_BUILD, etc so that Makefiles don't have
> to be cleaned up right away. And $(PHASE_) could also be removed over
> time (since it would be an empty string) if we wanted to go that route.
>
> > It also works (so far as I can tell) with your changes
> > above.
>
> I continue to not see how that's possible. The only commonality is that
> we would both remove $(PHASE_) / $(XPL_) from the Makefiles.

It's possible because my scheme produces essentially the same
autoconf.h files as yours, just by a different means.

IMO there is not a huge difference between our schemes and I can
clearly see that mine can come before yours and that yours is a
possible next step along the path after that.

I still don't understand if what you don't like about my scheme is
based on a misunderstanding of what it does, or a genuine flaw in my
scheme.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 25464 bytes --]

On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > >
> > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > >
> > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > >
> > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > >
> > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > >
> > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > >
> > > > > > > > > > > > > Proposal
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > above.
> > > > > > > > > > > > >
> > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > >
> > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > >
> > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > >
> > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > >   as needed.
> > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > >
> > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > >
> > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > resulting .config file available.
> > > > > > > > > > >
> > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > lines such as:
> > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > >
> > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > be TPL.
> > > > > > > > > > >
> > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > >
> > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > >
> > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > >
> > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > >
> > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > >
> > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > >
> > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > today.
> > > > > > > > > > >
> > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > >
> > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > instead.
> > > > > > > > > > >
> > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > either:
> > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > >
> > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > b) It contains:
> > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > %_defconfig:
> > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > >   foreach line in $@
> > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > >
> > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > >
> > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > >
> > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > >
> > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > >
> > > > > > > > But just above you said:
> > > > > > > >
> > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > clear than they are today. The line:
> > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > will become:
> > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > my own):
> > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > >
> > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > >
> > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > >
> > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > >
> > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > >
> > > > >
> > > > > > With my
> > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > symbol I set, I can solve my problem."
> > > > >
> > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > >
> > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > confusing than $(PHASE_)BLK is.
> > >
> > > OK
> > >
> > > >
> > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > symbol I set, I can solve my problem."
> > > > >
> > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > things for different phases.
> > > >
> > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > and code.
> > > >
> > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > options, and that overrides all other considerations?
> > > >
> > > > It's one of the big problems we have today, and splc-working shows how
> > > > much further the duplication must go. It's why I suggested the language
> > > > modification before.
> > > >
> > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > This will be true for many but not all SPL symbols as
> > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > think it does show that the old way was confusing however).
> > > > >
> > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > >
> > > > I'm saying they have to know that, and also know which symbols that's
> > > > not true for. And that is more confusing than today. I'm saying that
> > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > worse:
> > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > >  endif
> > > >
> > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > +obj-$(CONFIG_RAM) += sdram.o
> > > >
> > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > >
> > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > >
> > > > And this is better:
> > > >
> > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > @@ -7,15 +7,13 @@
> > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > >
> > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > -
> > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > >
> > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > >  # meaning "turn it off".
> > > >  obj-y += boot_mode.o
> > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > -endif
> > > >
> > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > -endif
> > > >
> > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > +obj-$(CONFIG_RAM) += sdram.o
> > > >
> > > > +ifdef CONFIG_PPL
> > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > -
> > > > -# Clear out SPL objects, in case this is a TPL build
> > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > -
> > > > -# Now add SPL/TPL objects back into the main build
> > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > +endif
> > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > >
> > >
> > > This Makefile is a very strange example. I've thought about cleaning
> > > it up a few times, but then I know someone will say it needs to be in
> > > its own series, etc. so I've never got around to it. Even with the
> > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > needlessly complex.
> >
> > There's some complexity that can be removed here today, maybe. But not a
> > lot of it, because it's complex to build three different things when
> > configuring once.
> >
> > > Anyway, with my scheme, you can still use
> > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> >
> > No. You have to use it still, with yours. Because
> > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > code" but different files at TPL, SPL and PPL. And you still have to
> > with mine, because for the same reason. With mine, the Kconfig is:
> > config SPL_ROCKCHIP_COMMON_BOARD
> >   bool "SPL rockchip common board file"
> >   depends on SPL
> >
> > config TPL_ROCKCHIP_COMMON_BOARD
> >   bool "TPL rockchip common board file"
> >   depends on TPL
> >
> > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > ...) the resulting config only ever asks for the appropriate one.
> >
> > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > work.
> >
> > Yes, this is part of the confusion I keep noting with your proposal as
> > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> 
> If it is confusing, we can change all of them to CONFIG_xxx in a
> follow-up. There is no need to mention SPL_, it just allows the
> existing code to work without a wholesale change.

No, that's not correct. Please look again at what I've written
explaining why.

> > > This surprised me:
> > >
> > > obj-$(CONFIG_RAM) += sdram.o
> > >
> > > Are you saying you are OK with this one, instead of, for example:
> > >
> > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > obj-$(CONFIG_RAM) += sdram.o
> > >
> > > If so, why are you OK with that and not the others?
> >
> > Because there is no:
> > config TPL_RAM
> >   bool "RAM driver in TPL"
> >
> > in what I am proposing. That's why. There's one symbol because there's
> > the same files being built.
> 
> OK, well that works the same for my scheme too. Either will do.

I don't see how that can work in your scheme.

> > > For this one:
> > >
> > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > >
> > > I don't understand how it can work with your scheme, since you don't
> > > want to have any CONFIG_SPL_ things?
> >
> > No, that's not what I've been saying and trying to make clear with my
> > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > only options. And these need to be named as such. And so that's the
> > confusion your proposal introduces (inconsistency about referring to a
> > symbol that has been enabled) and mine removes entirely (we only ever
> > refer to symbols based on their name).
> 
> Right, but you still have 'config SPL_RAM', right? Would you keep

No, again, I do not. Please re-read my proposal as you seem to keep
making the same incorrect assumptions about it, and then saying that
your scheme would also do that. They are very much not at all the same.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > above.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > >
> > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > >
> > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > lines such as:
> > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > >
> > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > be TPL.
> > > > > > > > > > > >
> > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > >
> > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > >
> > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > >
> > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > >
> > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > >
> > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > >
> > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > today.
> > > > > > > > > > > >
> > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > >
> > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > instead.
> > > > > > > > > > > >
> > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > either:
> > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > >
> > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > >
> > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > >
> > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > >
> > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > >
> > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > >
> > > > > > > > > But just above you said:
> > > > > > > > >
> > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > will become:
> > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > my own):
> > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > >
> > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > >
> > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > >
> > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > >
> > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > >
> > > > > >
> > > > > > > With my
> > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > symbol I set, I can solve my problem."
> > > > > >
> > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > >
> > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > confusing than $(PHASE_)BLK is.
> > > >
> > > > OK
> > > >
> > > > >
> > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > symbol I set, I can solve my problem."
> > > > > >
> > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > things for different phases.
> > > > >
> > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > and code.
> > > > >
> > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > options, and that overrides all other considerations?
> > > > >
> > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > much further the duplication must go. It's why I suggested the language
> > > > > modification before.
> > > > >
> > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > think it does show that the old way was confusing however).
> > > > > >
> > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > >
> > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > worse:
> > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > >  endif
> > > > >
> > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > >
> > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > >
> > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > >
> > > > > And this is better:
> > > > >
> > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > @@ -7,15 +7,13 @@
> > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > >
> > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > -
> > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > >
> > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > >  # meaning "turn it off".
> > > > >  obj-y += boot_mode.o
> > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > -endif
> > > > >
> > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > -endif
> > > > >
> > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > >
> > > > > +ifdef CONFIG_PPL
> > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > -
> > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > -
> > > > > -# Now add SPL/TPL objects back into the main build
> > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > +endif
> > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > >
> > > >
> > > > This Makefile is a very strange example. I've thought about cleaning
> > > > it up a few times, but then I know someone will say it needs to be in
> > > > its own series, etc. so I've never got around to it. Even with the
> > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > needlessly complex.
> > >
> > > There's some complexity that can be removed here today, maybe. But not a
> > > lot of it, because it's complex to build three different things when
> > > configuring once.
> > >
> > > > Anyway, with my scheme, you can still use
> > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > >
> > > No. You have to use it still, with yours. Because
> > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > code" but different files at TPL, SPL and PPL. And you still have to
> > > with mine, because for the same reason. With mine, the Kconfig is:
> > > config SPL_ROCKCHIP_COMMON_BOARD
> > >   bool "SPL rockchip common board file"
> > >   depends on SPL
> > >
> > > config TPL_ROCKCHIP_COMMON_BOARD
> > >   bool "TPL rockchip common board file"
> > >   depends on TPL
> > >
> > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > ...) the resulting config only ever asks for the appropriate one.
> > >
> > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > work.
> > >
> > > Yes, this is part of the confusion I keep noting with your proposal as
> > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> >
> > If it is confusing, we can change all of them to CONFIG_xxx in a
> > follow-up. There is no need to mention SPL_, it just allows the
> > existing code to work without a wholesale change.
>
> No, that's not correct. Please look again at what I've written
> explaining why.

See below.

>
> > > > This surprised me:
> > > >
> > > > obj-$(CONFIG_RAM) += sdram.o
> > > >
> > > > Are you saying you are OK with this one, instead of, for example:
> > > >
> > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > obj-$(CONFIG_RAM) += sdram.o
> > > >
> > > > If so, why are you OK with that and not the others?
> > >
> > > Because there is no:
> > > config TPL_RAM
> > >   bool "RAM driver in TPL"
> > >
> > > in what I am proposing. That's why. There's one symbol because there's
> > > the same files being built.
> >
> > OK, well that works the same for my scheme too. Either will do.
>
> I don't see how that can work in your scheme.

Here is the full Kconfig for that file, with my scheme:

>>>>
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (c) 2014 Google, Inc
# Copyright (c) 2019 Rockchip Electronics Co., Ltd.

# We don't want the bootrom-helper present in a full U-Boot build, as
# this may have entered from ATF with the stack-pointer pointing to
# inaccessible/protected memory (and the bootrom-helper assumes that
# the stack-pointer is valid before switching to the U-Boot stack).
obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
spl_common.o
obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o

obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o

ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)

# Always include boot_mode.o, as we bypass it (i.e. turn it off)
# inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
# we can have the preprocessor correctly recognise both 0x0 and 0
# meaning "turn it off".
obj-y += boot_mode.o
obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
endif

ifeq ($(CONFIG_TPL_BUILD),)
obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
endif

obj-$(CONFIG_RAM) += sdram.o

obj-$(CONFIG_ROCKCHIP_PX30) += px30/
obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/

# Clear out SPL objects, in case this is a TPL build
obj-spl-$(CONFIG_TPL_BUILD) =

# Now add SPL/TPL objects back into the main build
obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
<<<<

The only change is the line that was:
obj-$(CONFIG_$(PHASE_)RAM) += sdram.o

>
> > > > For this one:
> > > >
> > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > >
> > > > I don't understand how it can work with your scheme, since you don't
> > > > want to have any CONFIG_SPL_ things?
> > >
> > > No, that's not what I've been saying and trying to make clear with my
> > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > only options. And these need to be named as such. And so that's the
> > > confusion your proposal introduces (inconsistency about referring to a
> > > symbol that has been enabled) and mine removes entirely (we only ever
> > > refer to symbols based on their name).
> >
> > Right, but you still have 'config SPL_RAM', right? Would you keep
>
> No, again, I do not. Please re-read my proposal as you seem to keep
> making the same incorrect assumptions about it, and then saying that
> your scheme would also do that. They are very much not at all the same.

Maybe we have reached the limits of email on this one, but I am quite
confused about your scheme. I suggested that you don't have
CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
still have SPL_RAM and you said you don't. Let me try this:

Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
do you not?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 30991 bytes --]

On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > >
> > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > >
> > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > >
> > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > >
> > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > today.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > >
> > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > instead.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > either:
> > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > >
> > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > >
> > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > >
> > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > >
> > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > >
> > > > > > > > > > But just above you said:
> > > > > > > > > >
> > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > will become:
> > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > my own):
> > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > >
> > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > >
> > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > >
> > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > >
> > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > >
> > > > > > >
> > > > > > > > With my
> > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > symbol I set, I can solve my problem."
> > > > > > >
> > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > >
> > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > confusing than $(PHASE_)BLK is.
> > > > >
> > > > > OK
> > > > >
> > > > > >
> > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > symbol I set, I can solve my problem."
> > > > > > >
> > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > things for different phases.
> > > > > >
> > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > and code.
> > > > > >
> > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > options, and that overrides all other considerations?
> > > > > >
> > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > modification before.
> > > > > >
> > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > think it does show that the old way was confusing however).
> > > > > > >
> > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > >
> > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > worse:
> > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > >  endif
> > > > > >
> > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > >
> > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > >
> > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > >
> > > > > > And this is better:
> > > > > >
> > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > @@ -7,15 +7,13 @@
> > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > >
> > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > -
> > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > >
> > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > >  # meaning "turn it off".
> > > > > >  obj-y += boot_mode.o
> > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > -endif
> > > > > >
> > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > -endif
> > > > > >
> > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > >
> > > > > > +ifdef CONFIG_PPL
> > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > -
> > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > -
> > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > +endif
> > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > >
> > > > >
> > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > needlessly complex.
> > > >
> > > > There's some complexity that can be removed here today, maybe. But not a
> > > > lot of it, because it's complex to build three different things when
> > > > configuring once.
> > > >
> > > > > Anyway, with my scheme, you can still use
> > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > >
> > > > No. You have to use it still, with yours. Because
> > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > >   bool "SPL rockchip common board file"
> > > >   depends on SPL
> > > >
> > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > >   bool "TPL rockchip common board file"
> > > >   depends on TPL
> > > >
> > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > ...) the resulting config only ever asks for the appropriate one.
> > > >
> > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > work.
> > > >
> > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > >
> > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > follow-up. There is no need to mention SPL_, it just allows the
> > > existing code to work without a wholesale change.
> >
> > No, that's not correct. Please look again at what I've written
> > explaining why.
> 
> See below.
> 
> >
> > > > > This surprised me:
> > > > >
> > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > >
> > > > > Are you saying you are OK with this one, instead of, for example:
> > > > >
> > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > >
> > > > > If so, why are you OK with that and not the others?
> > > >
> > > > Because there is no:
> > > > config TPL_RAM
> > > >   bool "RAM driver in TPL"
> > > >
> > > > in what I am proposing. That's why. There's one symbol because there's
> > > > the same files being built.
> > >
> > > OK, well that works the same for my scheme too. Either will do.
> >
> > I don't see how that can work in your scheme.
> 
> Here is the full Kconfig for that file, with my scheme:
> 
> >>>>
> # SPDX-License-Identifier: GPL-2.0+
> #
> # Copyright (c) 2014 Google, Inc
> # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> 
> # We don't want the bootrom-helper present in a full U-Boot build, as
> # this may have entered from ATF with the stack-pointer pointing to
> # inaccessible/protected memory (and the bootrom-helper assumes that
> # the stack-pointer is valid before switching to the U-Boot stack).
> obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> spl_common.o
> obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> 
> obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> 
> ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> 
> # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> # we can have the preprocessor correctly recognise both 0x0 and 0
> # meaning "turn it off".
> obj-y += boot_mode.o
> obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> endif
> 
> ifeq ($(CONFIG_TPL_BUILD),)
> obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> endif
> 
> obj-$(CONFIG_RAM) += sdram.o
> 
> obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> 
> # Clear out SPL objects, in case this is a TPL build
> obj-spl-$(CONFIG_TPL_BUILD) =
> 
> # Now add SPL/TPL objects back into the main build
> obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> <<<<
> 
> The only change is the line that was:
> obj-$(CONFIG_$(PHASE_)RAM) += sdram.o

Yes, that's also what I showed via unified diff format earlier, and so I
agree.

> > > > > For this one:
> > > > >
> > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > >
> > > > > I don't understand how it can work with your scheme, since you don't
> > > > > want to have any CONFIG_SPL_ things?
> > > >
> > > > No, that's not what I've been saying and trying to make clear with my
> > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > only options. And these need to be named as such. And so that's the
> > > > confusion your proposal introduces (inconsistency about referring to a
> > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > refer to symbols based on their name).
> > >
> > > Right, but you still have 'config SPL_RAM', right? Would you keep
> >
> > No, again, I do not. Please re-read my proposal as you seem to keep
> > making the same incorrect assumptions about it, and then saying that
> > your scheme would also do that. They are very much not at all the same.
> 
> Maybe we have reached the limits of email on this one, but I am quite
> confused about your scheme. I suggested that you don't have
> CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> still have SPL_RAM and you said you don't. Let me try this:
> 
> Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> do you not?

In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
are never configuring and building for more than one phase.

In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
(and again for TPL_...). They control different code. While technically
possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
having the Makefile have to do some two part check like we have today,
as those are one of the pain points of adding new code.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > today.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > >
> > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > >
> > > > > > > > > > > But just above you said:
> > > > > > > > > > >
> > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > will become:
> > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > my own):
> > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > >
> > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > >
> > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > >
> > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > >
> > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > >
> > > > > > > >
> > > > > > > > > With my
> > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > >
> > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > >
> > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > confusing than $(PHASE_)BLK is.
> > > > > >
> > > > > > OK
> > > > > >
> > > > > > >
> > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > >
> > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > things for different phases.
> > > > > > >
> > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > and code.
> > > > > > >
> > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > options, and that overrides all other considerations?
> > > > > > >
> > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > modification before.
> > > > > > >
> > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > >
> > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > >
> > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > worse:
> > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > >  endif
> > > > > > >
> > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > >
> > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > >
> > > > > > > And this is better:
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > @@ -7,15 +7,13 @@
> > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > >
> > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > -
> > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > >
> > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > >  # meaning "turn it off".
> > > > > > >  obj-y += boot_mode.o
> > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > -endif
> > > > > > >
> > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > -endif
> > > > > > >
> > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > +ifdef CONFIG_PPL
> > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > -
> > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > -
> > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > +endif
> > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > >
> > > > > >
> > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > needlessly complex.
> > > > >
> > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > lot of it, because it's complex to build three different things when
> > > > > configuring once.
> > > > >
> > > > > > Anyway, with my scheme, you can still use
> > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > >
> > > > > No. You have to use it still, with yours. Because
> > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > >   bool "SPL rockchip common board file"
> > > > >   depends on SPL
> > > > >
> > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > >   bool "TPL rockchip common board file"
> > > > >   depends on TPL
> > > > >
> > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > >
> > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > work.
> > > > >
> > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > >
> > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > existing code to work without a wholesale change.
> > >
> > > No, that's not correct. Please look again at what I've written
> > > explaining why.
> >
> > See below.
> >
> > >
> > > > > > This surprised me:
> > > > > >
> > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > >
> > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > >
> > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > >
> > > > > > If so, why are you OK with that and not the others?
> > > > >
> > > > > Because there is no:
> > > > > config TPL_RAM
> > > > >   bool "RAM driver in TPL"
> > > > >
> > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > the same files being built.
> > > >
> > > > OK, well that works the same for my scheme too. Either will do.
> > >
> > > I don't see how that can work in your scheme.
> >
> > Here is the full Kconfig for that file, with my scheme:
> >
> > >>>>
> > # SPDX-License-Identifier: GPL-2.0+
> > #
> > # Copyright (c) 2014 Google, Inc
> > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> >
> > # We don't want the bootrom-helper present in a full U-Boot build, as
> > # this may have entered from ATF with the stack-pointer pointing to
> > # inaccessible/protected memory (and the bootrom-helper assumes that
> > # the stack-pointer is valid before switching to the U-Boot stack).
> > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > spl_common.o
> > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> >
> > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> >
> > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> >
> > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > # we can have the preprocessor correctly recognise both 0x0 and 0
> > # meaning "turn it off".
> > obj-y += boot_mode.o
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > endif
> >
> > ifeq ($(CONFIG_TPL_BUILD),)
> > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > endif
> >
> > obj-$(CONFIG_RAM) += sdram.o
> >
> > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> >
> > # Clear out SPL objects, in case this is a TPL build
> > obj-spl-$(CONFIG_TPL_BUILD) =
> >
> > # Now add SPL/TPL objects back into the main build
> > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > <<<<
> >
> > The only change is the line that was:
> > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
>
> Yes, that's also what I showed via unified diff format earlier, and so I
> agree.

OK good.

>
> > > > > > For this one:
> > > > > >
> > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > >
> > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > want to have any CONFIG_SPL_ things?
> > > > >
> > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > only options. And these need to be named as such. And so that's the
> > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > refer to symbols based on their name).
> > > >
> > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > >
> > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > making the same incorrect assumptions about it, and then saying that
> > > your scheme would also do that. They are very much not at all the same.
> >
> > Maybe we have reached the limits of email on this one, but I am quite
> > confused about your scheme. I suggested that you don't have
> > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > still have SPL_RAM and you said you don't. Let me try this:
> >
> > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > do you not?
>
> In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> are never configuring and building for more than one phase.
>
> In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> (and again for TPL_...). They control different code. While technically
> possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> having the Makefile have to do some two part check like we have today,
> as those are one of the pain points of adding new code.

OK I think I have some sort of understanding now.

Here is the patch that works for me (on top of your patch above). Note
that we don't have to make those changes, but they show how my scheme
is different in what it expects:

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 23c30f68f87..0593e028de4 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -7,27 +7,35 @@
 # this may have entered from ATF with the stack-pointer pointing to
 # inaccessible/protected memory (and the bootrom-helper assumes that
 # the stack-pointer is valid before switching to the U-Boot stack).
+ifdef CONFIG_XPL_BUILD
 obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
+endif
+ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
-obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
+endif
+ifdef CONFIG_TPL_BUILD
 obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
+endif
 obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o

 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o

+ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
+
 # Always include boot_mode.o, as we bypass it (i.e. turn it off)
 # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
 # we can have the preprocessor correctly recognise both 0x0 and 0
 # meaning "turn it off".
 obj-y += boot_mode.o
 obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
+endif

+ifeq ($(CONFIG_TPL_BUILD),)
 obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
+endif

 obj-$(CONFIG_RAM) += sdram.o

-ifdef CONFIG_PPL
-# TODO: Audit these Makefiles see if they really must be PPL only
 obj-$(CONFIG_ROCKCHIP_PX30) += px30/
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
 obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
@@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
 obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
 obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
 obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
-endif
-- 
2.43.0


Here's the full file:

# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (c) 2014 Google, Inc
# Copyright (c) 2019 Rockchip Electronics Co., Ltd.

# We don't want the bootrom-helper present in a full U-Boot build, as
# this may have entered from ATF with the stack-pointer pointing to
# inaccessible/protected memory (and the bootrom-helper assumes that
# the stack-pointer is valid before switching to the U-Boot stack).
ifdef CONFIG_XPL_BUILD
obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
endif
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
endif
ifdef CONFIG_TPL_BUILD
obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
endif
obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o

obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o

ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)

# Always include boot_mode.o, as we bypass it (i.e. turn it off)
# inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
# we can have the preprocessor correctly recognise both 0x0 and 0
# meaning "turn it off".
obj-y += boot_mode.o
obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
endif

ifeq ($(CONFIG_TPL_BUILD),)
obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
endif

obj-$(CONFIG_RAM) += sdram.o

obj-$(CONFIG_ROCKCHIP_PX30) += px30/
obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/

So we need CONFIG_SPL_BUILD when using a
CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.

We can't do this with my scheme:

obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o

since that will compile both targets into whatever phases are enabled.

To me, the ifdef I have above is less confusing than that, but I would
actually prefer this:

ifdef CONFIG_ROCKCHIP_COMMON_BOARD
obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
endif

Anyway, this is a strange case and I don't think it is a huge deal. In
general, when you enable an option for some phases you get that code
in those phases. When you actually *don't* want the code in a
particular phase, either don't set the option, or add another
condition.

After all, the current Makefile code is actually a bit of a
workaround. Any scheme is going to have drawbacks.

With my scheme, I want to have the options for all phases in each
autoconf_xpl.h so that you can check an option for one phase in
another. That is part of my intent to (as now) have a single Kconfig
which covers every option in every phase. The down-side of that is
that you have to be aware of it.

This did get me thinking though, whether with my scheme we could
(later) change Kconfig so that there is an SPL symbol, which is only
true when building SPL. Basically we would change the existing SPL to
HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
Kconfig, so you can depend on it, etc. Lots of options have 'depends
on SPL' which would mean 'depends on HAVE_SPL', but we could just
leave them as they are.

So then you could use

config SPL_ROCKCHIP_COMMON_BOARD
    depends on SPL

config TPL_ROCKCHIP_COMMON_BOARD
    depends on TPL

and this would work:

obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o

But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
enabled in the TPL build, TPL will not have visibility into that
option. We have effectively moved closer to your scheme: still with a
unified Kconfig, but completely split in the source code. Still, we
can control that, by having (for example) SPL_TEXT_BASE depend on the
new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
appear in all builds.

We also have to run the 'conf' tool multiple times.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 41526 bytes --]

On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > >
> > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > >
> > > > > > > > > > > > But just above you said:
> > > > > > > > > > > >
> > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > will become:
> > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > my own):
> > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > >
> > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > >
> > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > > > With my
> > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > >
> > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > >
> > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > >
> > > > > > > OK
> > > > > > >
> > > > > > > >
> > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > >
> > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > things for different phases.
> > > > > > > >
> > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > and code.
> > > > > > > >
> > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > options, and that overrides all other considerations?
> > > > > > > >
> > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > modification before.
> > > > > > > >
> > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > >
> > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > >
> > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > worse:
> > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > >  endif
> > > > > > > >
> > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > >
> > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > >
> > > > > > > > And this is better:
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > >
> > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > -
> > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > >
> > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > >  # meaning "turn it off".
> > > > > > > >  obj-y += boot_mode.o
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > -endif
> > > > > > > >
> > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > -endif
> > > > > > > >
> > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > -
> > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > -
> > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > +endif
> > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > >
> > > > > > >
> > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > needlessly complex.
> > > > > >
> > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > lot of it, because it's complex to build three different things when
> > > > > > configuring once.
> > > > > >
> > > > > > > Anyway, with my scheme, you can still use
> > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > >
> > > > > > No. You have to use it still, with yours. Because
> > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > >   bool "SPL rockchip common board file"
> > > > > >   depends on SPL
> > > > > >
> > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > >   bool "TPL rockchip common board file"
> > > > > >   depends on TPL
> > > > > >
> > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > >
> > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > work.
> > > > > >
> > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > >
> > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > existing code to work without a wholesale change.
> > > >
> > > > No, that's not correct. Please look again at what I've written
> > > > explaining why.
> > >
> > > See below.
> > >
> > > >
> > > > > > > This surprised me:
> > > > > > >
> > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > >
> > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > If so, why are you OK with that and not the others?
> > > > > >
> > > > > > Because there is no:
> > > > > > config TPL_RAM
> > > > > >   bool "RAM driver in TPL"
> > > > > >
> > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > the same files being built.
> > > > >
> > > > > OK, well that works the same for my scheme too. Either will do.
> > > >
> > > > I don't see how that can work in your scheme.
> > >
> > > Here is the full Kconfig for that file, with my scheme:
> > >
> > > >>>>
> > > # SPDX-License-Identifier: GPL-2.0+
> > > #
> > > # Copyright (c) 2014 Google, Inc
> > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > >
> > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > # this may have entered from ATF with the stack-pointer pointing to
> > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > spl_common.o
> > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > >
> > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > >
> > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > >
> > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > # meaning "turn it off".
> > > obj-y += boot_mode.o
> > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > endif
> > >
> > > ifeq ($(CONFIG_TPL_BUILD),)
> > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > endif
> > >
> > > obj-$(CONFIG_RAM) += sdram.o
> > >
> > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > >
> > > # Clear out SPL objects, in case this is a TPL build
> > > obj-spl-$(CONFIG_TPL_BUILD) =
> > >
> > > # Now add SPL/TPL objects back into the main build
> > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > <<<<
> > >
> > > The only change is the line that was:
> > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> >
> > Yes, that's also what I showed via unified diff format earlier, and so I
> > agree.
> 
> OK good.
> 
> >
> > > > > > > For this one:
> > > > > > >
> > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > >
> > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > want to have any CONFIG_SPL_ things?
> > > > > >
> > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > only options. And these need to be named as such. And so that's the
> > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > refer to symbols based on their name).
> > > > >
> > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > >
> > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > making the same incorrect assumptions about it, and then saying that
> > > > your scheme would also do that. They are very much not at all the same.
> > >
> > > Maybe we have reached the limits of email on this one, but I am quite
> > > confused about your scheme. I suggested that you don't have
> > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > still have SPL_RAM and you said you don't. Let me try this:
> > >
> > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > do you not?
> >
> > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > are never configuring and building for more than one phase.
> >
> > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > (and again for TPL_...). They control different code. While technically
> > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > having the Makefile have to do some two part check like we have today,
> > as those are one of the pain points of adding new code.
> 
> OK I think I have some sort of understanding now.
> 
> Here is the patch that works for me (on top of your patch above). Note
> that we don't have to make those changes, but they show how my scheme
> is different in what it expects:
> 
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 23c30f68f87..0593e028de4 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -7,27 +7,35 @@
>  # this may have entered from ATF with the stack-pointer pointing to
>  # inaccessible/protected memory (and the bootrom-helper assumes that
>  # the stack-pointer is valid before switching to the U-Boot stack).
> +ifdef CONFIG_XPL_BUILD
>  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> +endif
> +ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> +endif
> +ifdef CONFIG_TPL_BUILD
>  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> +endif
>  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> 
>  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> 
> +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> +
>  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
>  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
>  # we can have the preprocessor correctly recognise both 0x0 and 0
>  # meaning "turn it off".
>  obj-y += boot_mode.o
>  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> +endif
> 
> +ifeq ($(CONFIG_TPL_BUILD),)
>  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> +endif
> 
>  obj-$(CONFIG_RAM) += sdram.o
> 
> -ifdef CONFIG_PPL
> -# TODO: Audit these Makefiles see if they really must be PPL only
>  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
>  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
>  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
>  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
>  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
>  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> -endif
> -- 
> 2.43.0
> 
> 
> Here's the full file:
> 
> # SPDX-License-Identifier: GPL-2.0+
> #
> # Copyright (c) 2014 Google, Inc
> # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> 
> # We don't want the bootrom-helper present in a full U-Boot build, as
> # this may have entered from ATF with the stack-pointer pointing to
> # inaccessible/protected memory (and the bootrom-helper assumes that
> # the stack-pointer is valid before switching to the U-Boot stack).
> ifdef CONFIG_XPL_BUILD
> obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> endif
> ifdef CONFIG_SPL_BUILD
> obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> endif
> ifdef CONFIG_TPL_BUILD
> obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> endif
> obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> 
> obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> 
> ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> 
> # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> # we can have the preprocessor correctly recognise both 0x0 and 0
> # meaning "turn it off".
> obj-y += boot_mode.o
> obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> endif
> 
> ifeq ($(CONFIG_TPL_BUILD),)
> obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> endif
> 
> obj-$(CONFIG_RAM) += sdram.o
> 
> obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> 
> So we need CONFIG_SPL_BUILD when using a
> CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> 
> We can't do this with my scheme:
> 
> obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o

You can't do that with any scheme, to be clear. I don't know why you're
mentioning it.

> since that will compile both targets into whatever phases are enabled.
> 
> To me, the ifdef I have above is less confusing than that, but I would
> actually prefer this:
> 
> ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> endif

That would be less bad than what you've had earlier, yes. But I think
mine is still clearer.

> Anyway, this is a strange case and I don't think it is a huge deal. In

Yes, but it's not the only case like this, it's just the first one that
came to mind.

> general, when you enable an option for some phases you get that code
> in those phases. When you actually *don't* want the code in a
> particular phase, either don't set the option, or add another
> condition.

And your proposal doesn't solve that problem, still. Go back up in the
thread and see the DWC3 example I wanted to see if was still broken, and
is still broken.

> After all, the current Makefile code is actually a bit of a
> workaround. Any scheme is going to have drawbacks.

Yes, there's lots of workarounds. My scheme removes all of those
workarounds once complete. What phase is being configured and built is a
strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.

> With my scheme, I want to have the options for all phases in each
> autoconf_xpl.h so that you can check an option for one phase in
> another. That is part of my intent to (as now) have a single Kconfig
> which covers every option in every phase. The down-side of that is
> that you have to be aware of it.

Yes, and we're going to violate a whole lot of  "least surprise" rules
by changing how something we've borrowed from a much larger and more
popular project works (and also how other projects which borrow it
work).

> This did get me thinking though, whether with my scheme we could
> (later) change Kconfig so that there is an SPL symbol, which is only
> true when building SPL. Basically we would change the existing SPL to
> HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> Kconfig, so you can depend on it, etc. Lots of options have 'depends
> on SPL' which would mean 'depends on HAVE_SPL', but we could just
> leave them as they are.
> 
> So then you could use
> 
> config SPL_ROCKCHIP_COMMON_BOARD
>     depends on SPL
> 
> config TPL_ROCKCHIP_COMMON_BOARD
>     depends on TPL
> 
> and this would work:
> 
> obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> 
> But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> enabled in the TPL build, TPL will not have visibility into that
> option. We have effectively moved closer to your scheme: still with a
> unified Kconfig, but completely split in the source code. Still, we
> can control that, by having (for example) SPL_TEXT_BASE depend on the
> new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> appear in all builds.

Yes, that sounds like it will make some of the existing complex logic
even more complex, and I'm not sure of the benefit.

> We also have to run the 'conf' tool multiple times.

And to be clear, with my scheme that's a requirement since we're only
building and configuring a single phase. The files I've described with
"PHASE:XPL:file" are a nice-to-have on top bit, and not required
especially if it leads to confusion while discussing things.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > >
> > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > >
> > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > With my
> > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > >
> > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > >
> > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > >
> > > > > > > > OK
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > >
> > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > things for different phases.
> > > > > > > > >
> > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > and code.
> > > > > > > > >
> > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > >
> > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > modification before.
> > > > > > > > >
> > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > >
> > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > >
> > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > worse:
> > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > >  endif
> > > > > > > > >
> > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > >
> > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > >
> > > > > > > > > And this is better:
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > >
> > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > -
> > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > >
> > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > >  # meaning "turn it off".
> > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > -endif
> > > > > > > > >
> > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > -endif
> > > > > > > > >
> > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > -
> > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > -
> > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > +endif
> > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > >
> > > > > > > >
> > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > needlessly complex.
> > > > > > >
> > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > configuring once.
> > > > > > >
> > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > >
> > > > > > > No. You have to use it still, with yours. Because
> > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > >   bool "SPL rockchip common board file"
> > > > > > >   depends on SPL
> > > > > > >
> > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > >   bool "TPL rockchip common board file"
> > > > > > >   depends on TPL
> > > > > > >
> > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > >
> > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > work.
> > > > > > >
> > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > >
> > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > existing code to work without a wholesale change.
> > > > >
> > > > > No, that's not correct. Please look again at what I've written
> > > > > explaining why.
> > > >
> > > > See below.
> > > >
> > > > >
> > > > > > > > This surprised me:
> > > > > > > >
> > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > >
> > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > If so, why are you OK with that and not the others?
> > > > > > >
> > > > > > > Because there is no:
> > > > > > > config TPL_RAM
> > > > > > >   bool "RAM driver in TPL"
> > > > > > >
> > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > the same files being built.
> > > > > >
> > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > >
> > > > > I don't see how that can work in your scheme.
> > > >
> > > > Here is the full Kconfig for that file, with my scheme:
> > > >
> > > > >>>>
> > > > # SPDX-License-Identifier: GPL-2.0+
> > > > #
> > > > # Copyright (c) 2014 Google, Inc
> > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > >
> > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > spl_common.o
> > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > >
> > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > >
> > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > >
> > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > # meaning "turn it off".
> > > > obj-y += boot_mode.o
> > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > endif
> > > >
> > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > endif
> > > >
> > > > obj-$(CONFIG_RAM) += sdram.o
> > > >
> > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > >
> > > > # Clear out SPL objects, in case this is a TPL build
> > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > >
> > > > # Now add SPL/TPL objects back into the main build
> > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > <<<<
> > > >
> > > > The only change is the line that was:
> > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > >
> > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > agree.
> >
> > OK good.
> >
> > >
> > > > > > > > For this one:
> > > > > > > >
> > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > >
> > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > >
> > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > refer to symbols based on their name).
> > > > > >
> > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > >
> > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > making the same incorrect assumptions about it, and then saying that
> > > > > your scheme would also do that. They are very much not at all the same.
> > > >
> > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > confused about your scheme. I suggested that you don't have
> > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > still have SPL_RAM and you said you don't. Let me try this:
> > > >
> > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > do you not?
> > >
> > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > are never configuring and building for more than one phase.
> > >
> > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > (and again for TPL_...). They control different code. While technically
> > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > having the Makefile have to do some two part check like we have today,
> > > as those are one of the pain points of adding new code.
> >
> > OK I think I have some sort of understanding now.
> >
> > Here is the patch that works for me (on top of your patch above). Note
> > that we don't have to make those changes, but they show how my scheme
> > is different in what it expects:
> >
> > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > index 23c30f68f87..0593e028de4 100644
> > --- a/arch/arm/mach-rockchip/Makefile
> > +++ b/arch/arm/mach-rockchip/Makefile
> > @@ -7,27 +7,35 @@
> >  # this may have entered from ATF with the stack-pointer pointing to
> >  # inaccessible/protected memory (and the bootrom-helper assumes that
> >  # the stack-pointer is valid before switching to the U-Boot stack).
> > +ifdef CONFIG_XPL_BUILD
> >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > +endif
> > +ifdef CONFIG_SPL_BUILD
> >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > +endif
> > +ifdef CONFIG_TPL_BUILD
> >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > +endif
> >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> >
> >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> >
> > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > +
> >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> >  # we can have the preprocessor correctly recognise both 0x0 and 0
> >  # meaning "turn it off".
> >  obj-y += boot_mode.o
> >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > +endif
> >
> > +ifeq ($(CONFIG_TPL_BUILD),)
> >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > +endif
> >
> >  obj-$(CONFIG_RAM) += sdram.o
> >
> > -ifdef CONFIG_PPL
> > -# TODO: Audit these Makefiles see if they really must be PPL only
> >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > -endif
> > --
> > 2.43.0
> >
> >
> > Here's the full file:
> >
> > # SPDX-License-Identifier: GPL-2.0+
> > #
> > # Copyright (c) 2014 Google, Inc
> > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> >
> > # We don't want the bootrom-helper present in a full U-Boot build, as
> > # this may have entered from ATF with the stack-pointer pointing to
> > # inaccessible/protected memory (and the bootrom-helper assumes that
> > # the stack-pointer is valid before switching to the U-Boot stack).
> > ifdef CONFIG_XPL_BUILD
> > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > endif
> > ifdef CONFIG_SPL_BUILD
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > endif
> > ifdef CONFIG_TPL_BUILD
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > endif
> > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> >
> > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> >
> > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> >
> > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > # we can have the preprocessor correctly recognise both 0x0 and 0
> > # meaning "turn it off".
> > obj-y += boot_mode.o
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > endif
> >
> > ifeq ($(CONFIG_TPL_BUILD),)
> > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > endif
> >
> > obj-$(CONFIG_RAM) += sdram.o
> >
> > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> >
> > So we need CONFIG_SPL_BUILD when using a
> > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> >
> > We can't do this with my scheme:
> >
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
>
> You can't do that with any scheme, to be clear. I don't know why you're
> mentioning it.

Just so we have a baseline.

>
> > since that will compile both targets into whatever phases are enabled.
> >
> > To me, the ifdef I have above is less confusing than that, but I would
> > actually prefer this:
> >
> > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > endif
>
> That would be less bad than what you've had earlier, yes. But I think
> mine is still clearer.

Sure.

>
> > Anyway, this is a strange case and I don't think it is a huge deal. In
>
> Yes, but it's not the only case like this, it's just the first one that
> came to mind.

I've not seen that sort of construct (spl-xxx += ...) in U-Boot
before, so I don't think it is common. I am sure there are others, but
my scheme does work with existing Makefiles.

>
> > general, when you enable an option for some phases you get that code
> > in those phases. When you actually *don't* want the code in a
> > particular phase, either don't set the option, or add another
> > condition.
>
> And your proposal doesn't solve that problem, still. Go back up in the
> thread and see the DWC3 example I wanted to see if was still broken, and
> is still broken.

What is broken about it? Are you using the old series? I don't see any
changes to the Makefile there in my new series.

>
> > After all, the current Makefile code is actually a bit of a
> > workaround. Any scheme is going to have drawbacks.
>
> Yes, there's lots of workarounds. My scheme removes all of those
> workarounds once complete. What phase is being configured and built is a
> strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.

Yes, I think that's right. For the most part my scheme will do the
same, but there will be exceptions, like the rockchip one.

>
> > With my scheme, I want to have the options for all phases in each
> > autoconf_xpl.h so that you can check an option for one phase in
> > another. That is part of my intent to (as now) have a single Kconfig
> > which covers every option in every phase. The down-side of that is
> > that you have to be aware of it.
>
> Yes, and we're going to violate a whole lot of  "least surprise" rules
> by changing how something we've borrowed from a much larger and more
> popular project works (and also how other projects which borrow it
> work).

I don't agree with that. Linux only builds a single build. We are
always going to have to do more here than Linux. Also Linux has no
interest in taking our Kbuild patches and incidentally, held out
against FIT for 10 years! Linux will do what it wants to do. This is
U-Boot.

>
> > This did get me thinking though, whether with my scheme we could
> > (later) change Kconfig so that there is an SPL symbol, which is only
> > true when building SPL. Basically we would change the existing SPL to
> > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > leave them as they are.
> >
> > So then you could use
> >
> > config SPL_ROCKCHIP_COMMON_BOARD
> >     depends on SPL
> >
> > config TPL_ROCKCHIP_COMMON_BOARD
> >     depends on TPL
> >
> > and this would work:
> >
> > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> >
> > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > enabled in the TPL build, TPL will not have visibility into that
> > option. We have effectively moved closer to your scheme: still with a
> > unified Kconfig, but completely split in the source code. Still, we
> > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > appear in all builds.
>
> Yes, that sounds like it will make some of the existing complex logic
> even more complex, and I'm not sure of the benefit.

Trying to split the difference between our schemes. I'm going to call
this 'option A' for my scheme.

>
> > We also have to run the 'conf' tool multiple times.
>
> And to be clear, with my scheme that's a requirement since we're only
> building and configuring a single phase. The files I've described with
> "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> especially if it leads to confusion while discussing things.

Yes, understood.

Basically I think both schemes work. At present I think we should go
with my scheme now, since it is pretty close to being complete and
involves minimal change to the existing Kconfig, then either do option
A, or decide to split the Kconfig completely, i.e. your scheme. It
seems that you believe my scheme is worse than the status quo, though,
right?

How much work do you think your scheme would entail?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 47462 bytes --]

On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > With my
> > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > >
> > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > >
> > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > >
> > > > > > > > > OK
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > >
> > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > things for different phases.
> > > > > > > > > >
> > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > and code.
> > > > > > > > > >
> > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > >
> > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > modification before.
> > > > > > > > > >
> > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > >
> > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > >
> > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > worse:
> > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > >  endif
> > > > > > > > > >
> > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > >
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > >
> > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > >
> > > > > > > > > > And this is better:
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > >
> > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > -
> > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > >
> > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > -endif
> > > > > > > > > >
> > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > -endif
> > > > > > > > > >
> > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > >
> > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > -
> > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > -
> > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > +endif
> > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > needlessly complex.
> > > > > > > >
> > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > configuring once.
> > > > > > > >
> > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > >
> > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > >   depends on SPL
> > > > > > > >
> > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > >   depends on TPL
> > > > > > > >
> > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > >
> > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > work.
> > > > > > > >
> > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > >
> > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > existing code to work without a wholesale change.
> > > > > >
> > > > > > No, that's not correct. Please look again at what I've written
> > > > > > explaining why.
> > > > >
> > > > > See below.
> > > > >
> > > > > >
> > > > > > > > > This surprised me:
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > >
> > > > > > > > Because there is no:
> > > > > > > > config TPL_RAM
> > > > > > > >   bool "RAM driver in TPL"
> > > > > > > >
> > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > the same files being built.
> > > > > > >
> > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > >
> > > > > > I don't see how that can work in your scheme.
> > > > >
> > > > > Here is the full Kconfig for that file, with my scheme:
> > > > >
> > > > > >>>>
> > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > #
> > > > > # Copyright (c) 2014 Google, Inc
> > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > >
> > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > spl_common.o
> > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > >
> > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > >
> > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > >
> > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > # meaning "turn it off".
> > > > > obj-y += boot_mode.o
> > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > endif
> > > > >
> > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > endif
> > > > >
> > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > >
> > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > >
> > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > >
> > > > > # Now add SPL/TPL objects back into the main build
> > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > <<<<
> > > > >
> > > > > The only change is the line that was:
> > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > >
> > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > agree.
> > >
> > > OK good.
> > >
> > > >
> > > > > > > > > For this one:
> > > > > > > > >
> > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > >
> > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > >
> > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > refer to symbols based on their name).
> > > > > > >
> > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > >
> > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > your scheme would also do that. They are very much not at all the same.
> > > > >
> > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > confused about your scheme. I suggested that you don't have
> > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > >
> > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > do you not?
> > > >
> > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > are never configuring and building for more than one phase.
> > > >
> > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > (and again for TPL_...). They control different code. While technically
> > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > having the Makefile have to do some two part check like we have today,
> > > > as those are one of the pain points of adding new code.
> > >
> > > OK I think I have some sort of understanding now.
> > >
> > > Here is the patch that works for me (on top of your patch above). Note
> > > that we don't have to make those changes, but they show how my scheme
> > > is different in what it expects:
> > >
> > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > index 23c30f68f87..0593e028de4 100644
> > > --- a/arch/arm/mach-rockchip/Makefile
> > > +++ b/arch/arm/mach-rockchip/Makefile
> > > @@ -7,27 +7,35 @@
> > >  # this may have entered from ATF with the stack-pointer pointing to
> > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > +ifdef CONFIG_XPL_BUILD
> > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > +endif
> > > +ifdef CONFIG_SPL_BUILD
> > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > +endif
> > > +ifdef CONFIG_TPL_BUILD
> > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > +endif
> > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > >
> > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > >
> > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > +
> > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > >  # meaning "turn it off".
> > >  obj-y += boot_mode.o
> > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > +endif
> > >
> > > +ifeq ($(CONFIG_TPL_BUILD),)
> > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > +endif
> > >
> > >  obj-$(CONFIG_RAM) += sdram.o
> > >
> > > -ifdef CONFIG_PPL
> > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > -endif
> > > --
> > > 2.43.0
> > >
> > >
> > > Here's the full file:
> > >
> > > # SPDX-License-Identifier: GPL-2.0+
> > > #
> > > # Copyright (c) 2014 Google, Inc
> > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > >
> > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > # this may have entered from ATF with the stack-pointer pointing to
> > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > ifdef CONFIG_XPL_BUILD
> > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > endif
> > > ifdef CONFIG_SPL_BUILD
> > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > endif
> > > ifdef CONFIG_TPL_BUILD
> > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > endif
> > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > >
> > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > >
> > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > >
> > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > # meaning "turn it off".
> > > obj-y += boot_mode.o
> > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > endif
> > >
> > > ifeq ($(CONFIG_TPL_BUILD),)
> > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > endif
> > >
> > > obj-$(CONFIG_RAM) += sdram.o
> > >
> > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > >
> > > So we need CONFIG_SPL_BUILD when using a
> > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > >
> > > We can't do this with my scheme:
> > >
> > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> >
> > You can't do that with any scheme, to be clear. I don't know why you're
> > mentioning it.
> 
> Just so we have a baseline.
> 
> >
> > > since that will compile both targets into whatever phases are enabled.
> > >
> > > To me, the ifdef I have above is less confusing than that, but I would
> > > actually prefer this:
> > >
> > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > endif
> >
> > That would be less bad than what you've had earlier, yes. But I think
> > mine is still clearer.
> 
> Sure.
> 
> >
> > > Anyway, this is a strange case and I don't think it is a huge deal. In
> >
> > Yes, but it's not the only case like this, it's just the first one that
> > came to mind.
> 
> I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> before, so I don't think it is common. I am sure there are others, but
> my scheme does work with existing Makefiles.

It's one of many examples of the workarounds needed for "do we want this
object in all phases or just some phases".

> > > general, when you enable an option for some phases you get that code
> > > in those phases. When you actually *don't* want the code in a
> > > particular phase, either don't set the option, or add another
> > > condition.
> >
> > And your proposal doesn't solve that problem, still. Go back up in the
> > thread and see the DWC3 example I wanted to see if was still broken, and
> > is still broken.
> 
> What is broken about it? Are you using the old series? I don't see any
> changes to the Makefile there in my new series.

I summarized things in the email there. And yes, your series does not
address and seemingly makes even worse, the problem of
including/excluding DWC3 from different phases.

> > > After all, the current Makefile code is actually a bit of a
> > > workaround. Any scheme is going to have drawbacks.
> >
> > Yes, there's lots of workarounds. My scheme removes all of those
> > workarounds once complete. What phase is being configured and built is a
> > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> 
> Yes, I think that's right. For the most part my scheme will do the
> same, but there will be exceptions, like the rockchip one.

If you're referring to arch/arm/mach-rockchip/Makefile that could be
rewritten, today, to be a little less cumbersome. It is still an example
of the tricky workarounds that are needed for including/excluding
objects based on phases, and is another example of how your series would
not make adding a new phase easier.

> > > With my scheme, I want to have the options for all phases in each
> > > autoconf_xpl.h so that you can check an option for one phase in
> > > another. That is part of my intent to (as now) have a single Kconfig
> > > which covers every option in every phase. The down-side of that is
> > > that you have to be aware of it.
> >
> > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > by changing how something we've borrowed from a much larger and more
> > popular project works (and also how other projects which borrow it
> > work).
> 
> I don't agree with that. Linux only builds a single build. We are
> always going to have to do more here than Linux. Also Linux has no
> interest in taking our Kbuild patches and incidentally, held out
> against FIT for 10 years! Linux will do what it wants to do. This is
> U-Boot.

Again, I am proposing we only do a single build.

And yes, this is U-Boot where one of our key attractions is "It's just
like working in the Linux Kernel, which you're likely already familiar
with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
that, badly.

> > > This did get me thinking though, whether with my scheme we could
> > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > true when building SPL. Basically we would change the existing SPL to
> > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > leave them as they are.
> > >
> > > So then you could use
> > >
> > > config SPL_ROCKCHIP_COMMON_BOARD
> > >     depends on SPL
> > >
> > > config TPL_ROCKCHIP_COMMON_BOARD
> > >     depends on TPL
> > >
> > > and this would work:
> > >
> > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > >
> > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > enabled in the TPL build, TPL will not have visibility into that
> > > option. We have effectively moved closer to your scheme: still with a
> > > unified Kconfig, but completely split in the source code. Still, we
> > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > appear in all builds.
> >
> > Yes, that sounds like it will make some of the existing complex logic
> > even more complex, and I'm not sure of the benefit.
> 
> Trying to split the difference between our schemes. I'm going to call
> this 'option A' for my scheme.
> 
> >
> > > We also have to run the 'conf' tool multiple times.
> >
> > And to be clear, with my scheme that's a requirement since we're only
> > building and configuring a single phase. The files I've described with
> > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > especially if it leads to confusion while discussing things.
> 
> Yes, understood.
> 
> Basically I think both schemes work. At present I think we should go
> with my scheme now, since it is pretty close to being complete and
> involves minimal change to the existing Kconfig, then either do option
> A, or decide to split the Kconfig completely, i.e. your scheme. It
> seems that you believe my scheme is worse than the status quo, though,
> right?

I think we need to come up with some way to get the community to vote on
your scheme or status quo. I don't think your scheme is "pretty close"
to being complete and I think it will make things worse than doing
nothing. I was hoping to get you to think about implementing what I
proposed instead, but since I still don't think you've understood it,
that's not an option either. But imagine you aren't interested in
hearing No and not doing it, again.

> How much work do you think your scheme would entail?

Not sure.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > With my
> > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > >
> > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > >
> > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > >
> > > > > > > > > > OK
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > >
> > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > things for different phases.
> > > > > > > > > > >
> > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > and code.
> > > > > > > > > > >
> > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > >
> > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > modification before.
> > > > > > > > > > >
> > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > >
> > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > >
> > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > worse:
> > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > >  endif
> > > > > > > > > > >
> > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > >
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > >
> > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > >
> > > > > > > > > > > And this is better:
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > >
> > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > -
> > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > >
> > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > -endif
> > > > > > > > > > >
> > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > -endif
> > > > > > > > > > >
> > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > >
> > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > -
> > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > -
> > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > +endif
> > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > needlessly complex.
> > > > > > > > >
> > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > configuring once.
> > > > > > > > >
> > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > >
> > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > >   depends on SPL
> > > > > > > > >
> > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > >   depends on TPL
> > > > > > > > >
> > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > >
> > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > work.
> > > > > > > > >
> > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > >
> > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > existing code to work without a wholesale change.
> > > > > > >
> > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > explaining why.
> > > > > >
> > > > > > See below.
> > > > > >
> > > > > > >
> > > > > > > > > > This surprised me:
> > > > > > > > > >
> > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > >
> > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > >
> > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > >
> > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > >
> > > > > > > > > Because there is no:
> > > > > > > > > config TPL_RAM
> > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > >
> > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > the same files being built.
> > > > > > > >
> > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > >
> > > > > > > I don't see how that can work in your scheme.
> > > > > >
> > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > >
> > > > > > >>>>
> > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > #
> > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > >
> > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > spl_common.o
> > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > >
> > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > >
> > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > >
> > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > # meaning "turn it off".
> > > > > > obj-y += boot_mode.o
> > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > endif
> > > > > >
> > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > endif
> > > > > >
> > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > >
> > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > >
> > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > >
> > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > <<<<
> > > > > >
> > > > > > The only change is the line that was:
> > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > >
> > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > agree.
> > > >
> > > > OK good.
> > > >
> > > > >
> > > > > > > > > > For this one:
> > > > > > > > > >
> > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > >
> > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > >
> > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > refer to symbols based on their name).
> > > > > > > >
> > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > >
> > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > >
> > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > confused about your scheme. I suggested that you don't have
> > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > >
> > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > do you not?
> > > > >
> > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > are never configuring and building for more than one phase.
> > > > >
> > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > (and again for TPL_...). They control different code. While technically
> > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > having the Makefile have to do some two part check like we have today,
> > > > > as those are one of the pain points of adding new code.
> > > >
> > > > OK I think I have some sort of understanding now.
> > > >
> > > > Here is the patch that works for me (on top of your patch above). Note
> > > > that we don't have to make those changes, but they show how my scheme
> > > > is different in what it expects:
> > > >
> > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > index 23c30f68f87..0593e028de4 100644
> > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > @@ -7,27 +7,35 @@
> > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > +ifdef CONFIG_XPL_BUILD
> > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > +endif
> > > > +ifdef CONFIG_SPL_BUILD
> > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > +endif
> > > > +ifdef CONFIG_TPL_BUILD
> > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > +endif
> > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > >
> > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > >
> > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > +
> > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > >  # meaning "turn it off".
> > > >  obj-y += boot_mode.o
> > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > +endif
> > > >
> > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > +endif
> > > >
> > > >  obj-$(CONFIG_RAM) += sdram.o
> > > >
> > > > -ifdef CONFIG_PPL
> > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > -endif
> > > > --
> > > > 2.43.0
> > > >
> > > >
> > > > Here's the full file:
> > > >
> > > > # SPDX-License-Identifier: GPL-2.0+
> > > > #
> > > > # Copyright (c) 2014 Google, Inc
> > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > >
> > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > ifdef CONFIG_XPL_BUILD
> > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > endif
> > > > ifdef CONFIG_SPL_BUILD
> > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > endif
> > > > ifdef CONFIG_TPL_BUILD
> > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > endif
> > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > >
> > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > >
> > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > >
> > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > # meaning "turn it off".
> > > > obj-y += boot_mode.o
> > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > endif
> > > >
> > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > endif
> > > >
> > > > obj-$(CONFIG_RAM) += sdram.o
> > > >
> > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > >
> > > > So we need CONFIG_SPL_BUILD when using a
> > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > >
> > > > We can't do this with my scheme:
> > > >
> > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > >
> > > You can't do that with any scheme, to be clear. I don't know why you're
> > > mentioning it.
> >
> > Just so we have a baseline.
> >
> > >
> > > > since that will compile both targets into whatever phases are enabled.
> > > >
> > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > actually prefer this:
> > > >
> > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > endif
> > >
> > > That would be less bad than what you've had earlier, yes. But I think
> > > mine is still clearer.
> >
> > Sure.
> >
> > >
> > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > >
> > > Yes, but it's not the only case like this, it's just the first one that
> > > came to mind.
> >
> > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > before, so I don't think it is common. I am sure there are others, but
> > my scheme does work with existing Makefiles.
>
> It's one of many examples of the workarounds needed for "do we want this
> object in all phases or just some phases".

You're being too negative IMO. Most of the time the right thing
happens. Yes there are corner cases but I believe you are
mischaracterising my scheme.

>
> > > > general, when you enable an option for some phases you get that code
> > > > in those phases. When you actually *don't* want the code in a
> > > > particular phase, either don't set the option, or add another
> > > > condition.
> > >
> > > And your proposal doesn't solve that problem, still. Go back up in the
> > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > is still broken.
> >
> > What is broken about it? Are you using the old series? I don't see any
> > changes to the Makefile there in my new series.
>
> I summarized things in the email there. And yes, your series does not
> address and seemingly makes even worse, the problem of
> including/excluding DWC3 from different phases.

But I really don't know what is wrong with DWC3, honest! When I build
pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
neither before or after my series. So can you please explain in a bit
more detail what you are getting at? The latest version is at splg4 in
my tree, although it's not finished.

>
> > > > After all, the current Makefile code is actually a bit of a
> > > > workaround. Any scheme is going to have drawbacks.
> > >
> > > Yes, there's lots of workarounds. My scheme removes all of those
> > > workarounds once complete. What phase is being configured and built is a
> > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> >
> > Yes, I think that's right. For the most part my scheme will do the
> > same, but there will be exceptions, like the rockchip one.
>
> If you're referring to arch/arm/mach-rockchip/Makefile that could be
> rewritten, today, to be a little less cumbersome. It is still an example
> of the tricky workarounds that are needed for including/excluding
> objects based on phases, and is another example of how your series would
> not make adding a new phase easier.

It makes it easier because you don't have to add loads of plumbing to
get a new phase. Also, with Kconfig changes, adding a phase could
become just a Kconfig thing, with everything else downstream of that,
There would be no need to add completely new Kconfig symbols for every
feature.

>
> > > > With my scheme, I want to have the options for all phases in each
> > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > which covers every option in every phase. The down-side of that is
> > > > that you have to be aware of it.
> > >
> > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > by changing how something we've borrowed from a much larger and more
> > > popular project works (and also how other projects which borrow it
> > > work).
> >
> > I don't agree with that. Linux only builds a single build. We are
> > always going to have to do more here than Linux. Also Linux has no
> > interest in taking our Kbuild patches and incidentally, held out
> > against FIT for 10 years! Linux will do what it wants to do. This is
> > U-Boot.
>
> Again, I am proposing we only do a single build.
>
> And yes, this is U-Boot where one of our key attractions is "It's just
> like working in the Linux Kernel, which you're likely already familiar
> with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> that, badly.

It means CONFIG_FOO for the phase being built, the same as your
scheme. From that POV all we are really talking about is the style of
plumbing.

If I could think of a way to express things differently in Kconfig, I
would do that. I did suggest at the start some possible extensions,
but you don't want those either.

>
> > > > This did get me thinking though, whether with my scheme we could
> > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > true when building SPL. Basically we would change the existing SPL to
> > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > leave them as they are.
> > > >
> > > > So then you could use
> > > >
> > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > >     depends on SPL
> > > >
> > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > >     depends on TPL
> > > >
> > > > and this would work:
> > > >
> > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > >
> > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > enabled in the TPL build, TPL will not have visibility into that
> > > > option. We have effectively moved closer to your scheme: still with a
> > > > unified Kconfig, but completely split in the source code. Still, we
> > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > appear in all builds.
> > >
> > > Yes, that sounds like it will make some of the existing complex logic
> > > even more complex, and I'm not sure of the benefit.
> >
> > Trying to split the difference between our schemes. I'm going to call
> > this 'option A' for my scheme.
> >
> > >
> > > > We also have to run the 'conf' tool multiple times.
> > >
> > > And to be clear, with my scheme that's a requirement since we're only
> > > building and configuring a single phase. The files I've described with
> > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > especially if it leads to confusion while discussing things.
> >
> > Yes, understood.
> >
> > Basically I think both schemes work. At present I think we should go
> > with my scheme now, since it is pretty close to being complete and
> > involves minimal change to the existing Kconfig, then either do option
> > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > seems that you believe my scheme is worse than the status quo, though,
> > right?
>
> I think we need to come up with some way to get the community to vote on
> your scheme or status quo. I don't think your scheme is "pretty close"
> to being complete and I think it will make things worse than doing
> nothing. I was hoping to get you to think about implementing what I
> proposed instead, but since I still don't think you've understood it,
> that's not an option either.

I just don't like splitting the defconfig into completely different
files. I know that will open up all sorts of issues. For example, how
will this code work?:

ulong spl_get_image_text_base(void)
{
#ifdef CONFIG_VPL
   if (xpl_next_phase() == PHASE_VPL)
      return CONFIG_VPL_TEXT_BASE;
#endif
   return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
      CONFIG_TEXT_BASE;
}

> But imagine you aren't interested in
> hearing No and not doing it, again.

Not particularly, but I could just do nothing on this.

>
> > How much work do you think your scheme would entail?
>
> Not sure.

I could probably take a look and try to guess.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 55955 bytes --]

On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > With my
> > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > >
> > > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > > >
> > > > > > > > > > > OK
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > >
> > > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > > things for different phases.
> > > > > > > > > > > >
> > > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > > and code.
> > > > > > > > > > > >
> > > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > > >
> > > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > > modification before.
> > > > > > > > > > > >
> > > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > > >
> > > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > > worse:
> > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > >  endif
> > > > > > > > > > > >
> > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > >
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > >
> > > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > > >
> > > > > > > > > > > > And this is better:
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > >
> > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > -
> > > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > >
> > > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > > -endif
> > > > > > > > > > > >
> > > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > -endif
> > > > > > > > > > > >
> > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > >
> > > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > > -
> > > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > > -
> > > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > > +endif
> > > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > > needlessly complex.
> > > > > > > > > >
> > > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > > configuring once.
> > > > > > > > > >
> > > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > > >
> > > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > > >   depends on SPL
> > > > > > > > > >
> > > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > > >   depends on TPL
> > > > > > > > > >
> > > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > > >
> > > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > > work.
> > > > > > > > > >
> > > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > > >
> > > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > > existing code to work without a wholesale change.
> > > > > > > >
> > > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > > explaining why.
> > > > > > >
> > > > > > > See below.
> > > > > > >
> > > > > > > >
> > > > > > > > > > > This surprised me:
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > >
> > > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > >
> > > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > > >
> > > > > > > > > > Because there is no:
> > > > > > > > > > config TPL_RAM
> > > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > > >
> > > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > > the same files being built.
> > > > > > > > >
> > > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > > >
> > > > > > > > I don't see how that can work in your scheme.
> > > > > > >
> > > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > > >
> > > > > > > >>>>
> > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > #
> > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > >
> > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > > spl_common.o
> > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > >
> > > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > >
> > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > >
> > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > # meaning "turn it off".
> > > > > > > obj-y += boot_mode.o
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > endif
> > > > > > >
> > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > endif
> > > > > > >
> > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > >
> > > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > >
> > > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > <<<<
> > > > > > >
> > > > > > > The only change is the line that was:
> > > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > >
> > > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > > agree.
> > > > >
> > > > > OK good.
> > > > >
> > > > > >
> > > > > > > > > > > For this one:
> > > > > > > > > > >
> > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > >
> > > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > > >
> > > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > > refer to symbols based on their name).
> > > > > > > > >
> > > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > > >
> > > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > > >
> > > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > > confused about your scheme. I suggested that you don't have
> > > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > > >
> > > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > > do you not?
> > > > > >
> > > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > > are never configuring and building for more than one phase.
> > > > > >
> > > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > > (and again for TPL_...). They control different code. While technically
> > > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > > having the Makefile have to do some two part check like we have today,
> > > > > > as those are one of the pain points of adding new code.
> > > > >
> > > > > OK I think I have some sort of understanding now.
> > > > >
> > > > > Here is the patch that works for me (on top of your patch above). Note
> > > > > that we don't have to make those changes, but they show how my scheme
> > > > > is different in what it expects:
> > > > >
> > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > index 23c30f68f87..0593e028de4 100644
> > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > @@ -7,27 +7,35 @@
> > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > +ifdef CONFIG_XPL_BUILD
> > > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > +endif
> > > > > +ifdef CONFIG_SPL_BUILD
> > > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > +endif
> > > > > +ifdef CONFIG_TPL_BUILD
> > > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > +endif
> > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > >
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > >
> > > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > +
> > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > >  # meaning "turn it off".
> > > > >  obj-y += boot_mode.o
> > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > +endif
> > > > >
> > > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > +endif
> > > > >
> > > > >  obj-$(CONFIG_RAM) += sdram.o
> > > > >
> > > > > -ifdef CONFIG_PPL
> > > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > -endif
> > > > > --
> > > > > 2.43.0
> > > > >
> > > > >
> > > > > Here's the full file:
> > > > >
> > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > #
> > > > > # Copyright (c) 2014 Google, Inc
> > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > >
> > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > ifdef CONFIG_XPL_BUILD
> > > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > endif
> > > > > ifdef CONFIG_SPL_BUILD
> > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > endif
> > > > > ifdef CONFIG_TPL_BUILD
> > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > endif
> > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > >
> > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > >
> > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > >
> > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > # meaning "turn it off".
> > > > > obj-y += boot_mode.o
> > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > endif
> > > > >
> > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > endif
> > > > >
> > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > >
> > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > >
> > > > > So we need CONFIG_SPL_BUILD when using a
> > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > > >
> > > > > We can't do this with my scheme:
> > > > >
> > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > >
> > > > You can't do that with any scheme, to be clear. I don't know why you're
> > > > mentioning it.
> > >
> > > Just so we have a baseline.
> > >
> > > >
> > > > > since that will compile both targets into whatever phases are enabled.
> > > > >
> > > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > > actually prefer this:
> > > > >
> > > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > > endif
> > > >
> > > > That would be less bad than what you've had earlier, yes. But I think
> > > > mine is still clearer.
> > >
> > > Sure.
> > >
> > > >
> > > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > > >
> > > > Yes, but it's not the only case like this, it's just the first one that
> > > > came to mind.
> > >
> > > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > > before, so I don't think it is common. I am sure there are others, but
> > > my scheme does work with existing Makefiles.
> >
> > It's one of many examples of the workarounds needed for "do we want this
> > object in all phases or just some phases".
> 
> You're being too negative IMO. Most of the time the right thing
> happens. Yes there are corner cases but I believe you are
> mischaracterising my scheme.

It's the problem with the way things work today, not just your scheme.
It's also one of the not infrequent pain points for what we have today
for including / excluding something from a given phase.

> > > > > general, when you enable an option for some phases you get that code
> > > > > in those phases. When you actually *don't* want the code in a
> > > > > particular phase, either don't set the option, or add another
> > > > > condition.
> > > >
> > > > And your proposal doesn't solve that problem, still. Go back up in the
> > > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > > is still broken.
> > >
> > > What is broken about it? Are you using the old series? I don't see any
> > > changes to the Makefile there in my new series.
> >
> > I summarized things in the email there. And yes, your series does not
> > address and seemingly makes even worse, the problem of
> > including/excluding DWC3 from different phases.
> 
> But I really don't know what is wrong with DWC3, honest! When I build
> pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
> neither before or after my series. So can you please explain in a bit
> more detail what you are getting at? The latest version is at splg4 in
> my tree, although it's not finished.

One of the first steps described in the problem statement is enabling
USB gadget for SPL only. This then blows up due to how we have / haven't
done workarounds for *USB_DWC3* symbols in Kconfig and also Makefile
logic.

> > > > > After all, the current Makefile code is actually a bit of a
> > > > > workaround. Any scheme is going to have drawbacks.
> > > >
> > > > Yes, there's lots of workarounds. My scheme removes all of those
> > > > workarounds once complete. What phase is being configured and built is a
> > > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> > >
> > > Yes, I think that's right. For the most part my scheme will do the
> > > same, but there will be exceptions, like the rockchip one.
> >
> > If you're referring to arch/arm/mach-rockchip/Makefile that could be
> > rewritten, today, to be a little less cumbersome. It is still an example
> > of the tricky workarounds that are needed for including/excluding
> > objects based on phases, and is another example of how your series would
> > not make adding a new phase easier.
> 
> It makes it easier because you don't have to add loads of plumbing to
> get a new phase. Also, with Kconfig changes, adding a phase could
> become just a Kconfig thing, with everything else downstream of that,
> There would be no need to add completely new Kconfig symbols for every
> feature.

I guess this is what you've put up in "splg4" now? I'll refrain from
commenting until I've had a chance to see what you've done here.

> > > > > With my scheme, I want to have the options for all phases in each
> > > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > > which covers every option in every phase. The down-side of that is
> > > > > that you have to be aware of it.
> > > >
> > > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > > by changing how something we've borrowed from a much larger and more
> > > > popular project works (and also how other projects which borrow it
> > > > work).
> > >
> > > I don't agree with that. Linux only builds a single build. We are
> > > always going to have to do more here than Linux. Also Linux has no
> > > interest in taking our Kbuild patches and incidentally, held out
> > > against FIT for 10 years! Linux will do what it wants to do. This is
> > > U-Boot.
> >
> > Again, I am proposing we only do a single build.
> >
> > And yes, this is U-Boot where one of our key attractions is "It's just
> > like working in the Linux Kernel, which you're likely already familiar
> > with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> > that, badly.
> 
> It means CONFIG_FOO for the phase being built, the same as your
> scheme. From that POV all we are really talking about is the style of
> plumbing.
> 
> If I could think of a way to express things differently in Kconfig, I
> would do that. I did suggest at the start some possible extensions,
> but you don't want those either.

Yes, I suggested language extensions to reduce the symbol increase of
"splc-working". I need to look at "splg4" now as that's apparently
entirely different before making assumptions and commenting further.

> > > > > This did get me thinking though, whether with my scheme we could
> > > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > > true when building SPL. Basically we would change the existing SPL to
> > > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > > leave them as they are.
> > > > >
> > > > > So then you could use
> > > > >
> > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > >     depends on SPL
> > > > >
> > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > >     depends on TPL
> > > > >
> > > > > and this would work:
> > > > >
> > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > >
> > > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > > enabled in the TPL build, TPL will not have visibility into that
> > > > > option. We have effectively moved closer to your scheme: still with a
> > > > > unified Kconfig, but completely split in the source code. Still, we
> > > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > > appear in all builds.
> > > >
> > > > Yes, that sounds like it will make some of the existing complex logic
> > > > even more complex, and I'm not sure of the benefit.
> > >
> > > Trying to split the difference between our schemes. I'm going to call
> > > this 'option A' for my scheme.
> > >
> > > >
> > > > > We also have to run the 'conf' tool multiple times.
> > > >
> > > > And to be clear, with my scheme that's a requirement since we're only
> > > > building and configuring a single phase. The files I've described with
> > > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > > especially if it leads to confusion while discussing things.
> > >
> > > Yes, understood.
> > >
> > > Basically I think both schemes work. At present I think we should go
> > > with my scheme now, since it is pretty close to being complete and
> > > involves minimal change to the existing Kconfig, then either do option
> > > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > > seems that you believe my scheme is worse than the status quo, though,
> > > right?
> >
> > I think we need to come up with some way to get the community to vote on
> > your scheme or status quo. I don't think your scheme is "pretty close"
> > to being complete and I think it will make things worse than doing
> > nothing. I was hoping to get you to think about implementing what I
> > proposed instead, but since I still don't think you've understood it,
> > that's not an option either.
> 
> I just don't like splitting the defconfig into completely different
> files. I know that will open up all sorts of issues. For example, how
> will this code work?:
> 
> ulong spl_get_image_text_base(void)
> {
> #ifdef CONFIG_VPL
>    if (xpl_next_phase() == PHASE_VPL)
>       return CONFIG_VPL_TEXT_BASE;
> #endif
>    return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
>       CONFIG_TEXT_BASE;
> }

Well, we start by asking why the FIT image being loaded isn't populated
with the load address being valid. And then is anyone still using
u-boot.bin and not u-boot.img and could we not just tidy away the whole
function?

But then if yes we need that function, we would do:

config PPL_TEXT_BASE
	hex "Static load address for full U-Boot, formerly TEXT_BASE"
	depends on PPL || SPL
	... current default 0xABC if BAR list for TEXT_BASE

config TPL_TEXT_BASE
	hex "Static load address for TPL phase of U-Boot"
	depends on TPL
	... default 0xABC if BAR list

config VPL_TEXT_BASE
	hex "Static load address for VPL phase of U-Boot"
	depends on (TPL && SUPPORTS_VPL) || VPL
	... default 0xABC if BAR list

config SPL_TEXT_BASE
	hex "Static load address for SPL phase of U-Boot"
	depends on ((TPL || VPL) && SUPPORTS_SPL) || SPL 
	... current set of default 0xABC if BAR list

ulong spl_get_image_text_base(void)
{
#if defined(CONFIG_TPL) && defined(CONFIG_SUPPORTS_VPL)
	return CONFIG_VPL_TEXT_BASE;
#elif (defined(CONFIG_TPL) || defined(CONFIG_VPL)) && \
		defined(CONFIG_SUPPORTS_SPL)
	return CONFIG_SPL_TEXT_BASE;
#else
	return CONFIG_PPL_TEXT_BASE;
#endif
}

And I assume one of your objections to the above is that we've removed
the macro functions that evaluate to 0 and let the optimizer discard
things (except for CC_OPTIMIZE_FOR_DEBUG related problems). But I also
see clever macros like that as a hindrance to understanding the code. We
would also change xpl_phase() to:
static inline enum xpl_phase_t xpl_phase(void)
{
#ifdef CONFIG_TPL
        return PHASE_TPL;
#elif defined(CONFIG_VPL)
        return PHASE_VPL;
#elif defined(CONFIG_SPL)
        return PHASE_SPL;
#else
        DECLARE_GLOBAL_DATA_PTR;

        if (!(gd->flags & GD_FLG_RELOC))
                return PHASE_BOARD_F;
        else
                return PHASE_BOARD_R;
#endif
}

But could not use it above because we will not globally have *TEXT_BASE
defined. And I don't worry about keeping these in sync between different
defconfig files as they are SoC dependent features. And maybe it's a
sign that my notion that we should have these defaults in the main
symbol, rather than arch/... various subdirs .../Kconfig was wrong and
has discouraged setting appropriate defaults. Because in this specific
example, FPGA-fun aside, it's not very arbitrary as to what address
space where is available to use when. Well Known Defaults should be
provided.

> > But imagine you aren't interested in
> > hearing No and not doing it, again.
> 
> Not particularly, but I could just do nothing on this.

I will look at "splg4" once it's somewhere on source.denx.de and I can
look at it, and refrain from otherwise assuming how it solves the
problems I had seen previously.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > With my
> > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > > > >
> > > > > > > > > > > > OK
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > > > things for different phases.
> > > > > > > > > > > > >
> > > > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > > > and code.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > > > >
> > > > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > > > modification before.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > > > worse:
> > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > >  endif
> > > > > > > > > > > > >
> > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > >
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > >
> > > > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > > > >
> > > > > > > > > > > > > And this is better:
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > -
> > > > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > >
> > > > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > > > -endif
> > > > > > > > > > > > >
> > > > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > -endif
> > > > > > > > > > > > >
> > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > > > -
> > > > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > > > -
> > > > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > > > +endif
> > > > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > > > needlessly complex.
> > > > > > > > > > >
> > > > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > > > configuring once.
> > > > > > > > > > >
> > > > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > > > >
> > > > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > > > >   depends on SPL
> > > > > > > > > > >
> > > > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > > > >   depends on TPL
> > > > > > > > > > >
> > > > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > > > >
> > > > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > > > work.
> > > > > > > > > > >
> > > > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > > > >
> > > > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > > > existing code to work without a wholesale change.
> > > > > > > > >
> > > > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > > > explaining why.
> > > > > > > >
> > > > > > > > See below.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > > This surprised me:
> > > > > > > > > > > >
> > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > >
> > > > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > > > >
> > > > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > >
> > > > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > > > >
> > > > > > > > > > > Because there is no:
> > > > > > > > > > > config TPL_RAM
> > > > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > > > >
> > > > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > > > the same files being built.
> > > > > > > > > >
> > > > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > > > >
> > > > > > > > > I don't see how that can work in your scheme.
> > > > > > > >
> > > > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > > > >
> > > > > > > > >>>>
> > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > #
> > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > >
> > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > > > spl_common.o
> > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > >
> > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > >
> > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > >
> > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > # meaning "turn it off".
> > > > > > > > obj-y += boot_mode.o
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > endif
> > > > > > > >
> > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > endif
> > > > > > > >
> > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > >
> > > > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > >
> > > > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > <<<<
> > > > > > > >
> > > > > > > > The only change is the line that was:
> > > > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > >
> > > > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > > > agree.
> > > > > >
> > > > > > OK good.
> > > > > >
> > > > > > >
> > > > > > > > > > > > For this one:
> > > > > > > > > > > >
> > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > >
> > > > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > > > >
> > > > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > > > refer to symbols based on their name).
> > > > > > > > > >
> > > > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > > > >
> > > > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > > > >
> > > > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > > > confused about your scheme. I suggested that you don't have
> > > > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > > > >
> > > > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > > > do you not?
> > > > > > >
> > > > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > > > are never configuring and building for more than one phase.
> > > > > > >
> > > > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > > > (and again for TPL_...). They control different code. While technically
> > > > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > > > having the Makefile have to do some two part check like we have today,
> > > > > > > as those are one of the pain points of adding new code.
> > > > > >
> > > > > > OK I think I have some sort of understanding now.
> > > > > >
> > > > > > Here is the patch that works for me (on top of your patch above). Note
> > > > > > that we don't have to make those changes, but they show how my scheme
> > > > > > is different in what it expects:
> > > > > >
> > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > index 23c30f68f87..0593e028de4 100644
> > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > @@ -7,27 +7,35 @@
> > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > +ifdef CONFIG_XPL_BUILD
> > > > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > +endif
> > > > > > +ifdef CONFIG_SPL_BUILD
> > > > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > +endif
> > > > > > +ifdef CONFIG_TPL_BUILD
> > > > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > +endif
> > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > >
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > >
> > > > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > +
> > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > >  # meaning "turn it off".
> > > > > >  obj-y += boot_mode.o
> > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > +endif
> > > > > >
> > > > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > +endif
> > > > > >
> > > > > >  obj-$(CONFIG_RAM) += sdram.o
> > > > > >
> > > > > > -ifdef CONFIG_PPL
> > > > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > -endif
> > > > > > --
> > > > > > 2.43.0
> > > > > >
> > > > > >
> > > > > > Here's the full file:
> > > > > >
> > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > #
> > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > >
> > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > ifdef CONFIG_XPL_BUILD
> > > > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > endif
> > > > > > ifdef CONFIG_SPL_BUILD
> > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > endif
> > > > > > ifdef CONFIG_TPL_BUILD
> > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > endif
> > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > >
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > >
> > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > >
> > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > # meaning "turn it off".
> > > > > > obj-y += boot_mode.o
> > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > endif
> > > > > >
> > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > endif
> > > > > >
> > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > >
> > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > >
> > > > > > So we need CONFIG_SPL_BUILD when using a
> > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > > > >
> > > > > > We can't do this with my scheme:
> > > > > >
> > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > >
> > > > > You can't do that with any scheme, to be clear. I don't know why you're
> > > > > mentioning it.
> > > >
> > > > Just so we have a baseline.
> > > >
> > > > >
> > > > > > since that will compile both targets into whatever phases are enabled.
> > > > > >
> > > > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > > > actually prefer this:
> > > > > >
> > > > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > > > endif
> > > > >
> > > > > That would be less bad than what you've had earlier, yes. But I think
> > > > > mine is still clearer.
> > > >
> > > > Sure.
> > > >
> > > > >
> > > > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > > > >
> > > > > Yes, but it's not the only case like this, it's just the first one that
> > > > > came to mind.
> > > >
> > > > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > > > before, so I don't think it is common. I am sure there are others, but
> > > > my scheme does work with existing Makefiles.
> > >
> > > It's one of many examples of the workarounds needed for "do we want this
> > > object in all phases or just some phases".
> >
> > You're being too negative IMO. Most of the time the right thing
> > happens. Yes there are corner cases but I believe you are
> > mischaracterising my scheme.
>
> It's the problem with the way things work today, not just your scheme.
> It's also one of the not infrequent pain points for what we have today
> for including / excluding something from a given phase.
>
> > > > > > general, when you enable an option for some phases you get that code
> > > > > > in those phases. When you actually *don't* want the code in a
> > > > > > particular phase, either don't set the option, or add another
> > > > > > condition.
> > > > >
> > > > > And your proposal doesn't solve that problem, still. Go back up in the
> > > > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > > > is still broken.
> > > >
> > > > What is broken about it? Are you using the old series? I don't see any
> > > > changes to the Makefile there in my new series.
> > >
> > > I summarized things in the email there. And yes, your series does not
> > > address and seemingly makes even worse, the problem of
> > > including/excluding DWC3 from different phases.
> >
> > But I really don't know what is wrong with DWC3, honest! When I build
> > pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
> > neither before or after my series. So can you please explain in a bit
> > more detail what you are getting at? The latest version is at splg4 in
> > my tree, although it's not finished.
>
> One of the first steps described in the problem statement is enabling
> USB gadget for SPL only. This then blows up due to how we have / haven't
> done workarounds for *USB_DWC3* symbols in Kconfig and also Makefile
> logic.
>
> > > > > > After all, the current Makefile code is actually a bit of a
> > > > > > workaround. Any scheme is going to have drawbacks.
> > > > >
> > > > > Yes, there's lots of workarounds. My scheme removes all of those
> > > > > workarounds once complete. What phase is being configured and built is a
> > > > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> > > >
> > > > Yes, I think that's right. For the most part my scheme will do the
> > > > same, but there will be exceptions, like the rockchip one.
> > >
> > > If you're referring to arch/arm/mach-rockchip/Makefile that could be
> > > rewritten, today, to be a little less cumbersome. It is still an example
> > > of the tricky workarounds that are needed for including/excluding
> > > objects based on phases, and is another example of how your series would
> > > not make adding a new phase easier.
> >
> > It makes it easier because you don't have to add loads of plumbing to
> > get a new phase. Also, with Kconfig changes, adding a phase could
> > become just a Kconfig thing, with everything else downstream of that,
> > There would be no need to add completely new Kconfig symbols for every
> > feature.
>
> I guess this is what you've put up in "splg4" now? I'll refrain from
> commenting until I've had a chance to see what you've done here.
>
> > > > > > With my scheme, I want to have the options for all phases in each
> > > > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > > > which covers every option in every phase. The down-side of that is
> > > > > > that you have to be aware of it.
> > > > >
> > > > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > > > by changing how something we've borrowed from a much larger and more
> > > > > popular project works (and also how other projects which borrow it
> > > > > work).
> > > >
> > > > I don't agree with that. Linux only builds a single build. We are
> > > > always going to have to do more here than Linux. Also Linux has no
> > > > interest in taking our Kbuild patches and incidentally, held out
> > > > against FIT for 10 years! Linux will do what it wants to do. This is
> > > > U-Boot.
> > >
> > > Again, I am proposing we only do a single build.
> > >
> > > And yes, this is U-Boot where one of our key attractions is "It's just
> > > like working in the Linux Kernel, which you're likely already familiar
> > > with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> > > that, badly.
> >
> > It means CONFIG_FOO for the phase being built, the same as your
> > scheme. From that POV all we are really talking about is the style of
> > plumbing.
> >
> > If I could think of a way to express things differently in Kconfig, I
> > would do that. I did suggest at the start some possible extensions,
> > but you don't want those either.
>
> Yes, I suggested language extensions to reduce the symbol increase of
> "splc-working". I need to look at "splg4" now as that's apparently
> entirely different before making assumptions and commenting further.
>
> > > > > > This did get me thinking though, whether with my scheme we could
> > > > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > > > true when building SPL. Basically we would change the existing SPL to
> > > > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > > > leave them as they are.
> > > > > >
> > > > > > So then you could use
> > > > > >
> > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > >     depends on SPL
> > > > > >
> > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > >     depends on TPL
> > > > > >
> > > > > > and this would work:
> > > > > >
> > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > >
> > > > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > > > enabled in the TPL build, TPL will not have visibility into that
> > > > > > option. We have effectively moved closer to your scheme: still with a
> > > > > > unified Kconfig, but completely split in the source code. Still, we
> > > > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > > > appear in all builds.
> > > > >
> > > > > Yes, that sounds like it will make some of the existing complex logic
> > > > > even more complex, and I'm not sure of the benefit.
> > > >
> > > > Trying to split the difference between our schemes. I'm going to call
> > > > this 'option A' for my scheme.
> > > >
> > > > >
> > > > > > We also have to run the 'conf' tool multiple times.
> > > > >
> > > > > And to be clear, with my scheme that's a requirement since we're only
> > > > > building and configuring a single phase. The files I've described with
> > > > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > > > especially if it leads to confusion while discussing things.
> > > >
> > > > Yes, understood.
> > > >
> > > > Basically I think both schemes work. At present I think we should go
> > > > with my scheme now, since it is pretty close to being complete and
> > > > involves minimal change to the existing Kconfig, then either do option
> > > > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > > > seems that you believe my scheme is worse than the status quo, though,
> > > > right?
> > >
> > > I think we need to come up with some way to get the community to vote on
> > > your scheme or status quo. I don't think your scheme is "pretty close"
> > > to being complete and I think it will make things worse than doing
> > > nothing. I was hoping to get you to think about implementing what I
> > > proposed instead, but since I still don't think you've understood it,
> > > that's not an option either.
> >
> > I just don't like splitting the defconfig into completely different
> > files. I know that will open up all sorts of issues. For example, how
> > will this code work?:
> >
> > ulong spl_get_image_text_base(void)
> > {
> > #ifdef CONFIG_VPL
> >    if (xpl_next_phase() == PHASE_VPL)
> >       return CONFIG_VPL_TEXT_BASE;
> > #endif
> >    return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
> >       CONFIG_TEXT_BASE;
> > }
>
> Well, we start by asking why the FIT image being loaded isn't populated
> with the load address being valid. And then is anyone still using
> u-boot.bin and not u-boot.img and could we not just tidy away the whole
> function?

Sure, but we can't even get sunxi bootstd or LED over the line. How do
you imagine we could retire the legacy image?

>
> But then if yes we need that function, we would do:
>
> config PPL_TEXT_BASE
>         hex "Static load address for full U-Boot, formerly TEXT_BASE"
>         depends on PPL || SPL
>         ... current default 0xABC if BAR list for TEXT_BASE
>
> config TPL_TEXT_BASE
>         hex "Static load address for TPL phase of U-Boot"
>         depends on TPL
>         ... default 0xABC if BAR list
>
> config VPL_TEXT_BASE
>         hex "Static load address for VPL phase of U-Boot"
>         depends on (TPL && SUPPORTS_VPL) || VPL
>         ... default 0xABC if BAR list
>
> config SPL_TEXT_BASE
>         hex "Static load address for SPL phase of U-Boot"
>         depends on ((TPL || VPL) && SUPPORTS_SPL) || SPL
>         ... current set of default 0xABC if BAR list
>
> ulong spl_get_image_text_base(void)
> {
> #if defined(CONFIG_TPL) && defined(CONFIG_SUPPORTS_VPL)
>         return CONFIG_VPL_TEXT_BASE;
> #elif (defined(CONFIG_TPL) || defined(CONFIG_VPL)) && \
>                 defined(CONFIG_SUPPORTS_SPL)
>         return CONFIG_SPL_TEXT_BASE;
> #else
>         return CONFIG_PPL_TEXT_BASE;
> #endif
> }
>
> And I assume one of your objections to the above is that we've removed
> the macro functions that evaluate to 0 and let the optimizer discard
> things (except for CC_OPTIMIZE_FOR_DEBUG related problems). But I also
> see clever macros like that as a hindrance to understanding the code.

Actually, my objection is that it is very confusing. Mixing TPL and
VPL and SPL. We have to do this for every symbol that depends on or
uses a default from another phase??

> We
> would also change xpl_phase() to:
> static inline enum xpl_phase_t xpl_phase(void)
> {
> #ifdef CONFIG_TPL
>         return PHASE_TPL;
> #elif defined(CONFIG_VPL)
>         return PHASE_VPL;
> #elif defined(CONFIG_SPL)
>         return PHASE_SPL;
> #else
>         DECLARE_GLOBAL_DATA_PTR;
>
>         if (!(gd->flags & GD_FLG_RELOC))
>                 return PHASE_BOARD_F;
>         else
>                 return PHASE_BOARD_R;
> #endif
> }
>
> But could not use it above because we will not globally have *TEXT_BASE
> defined. And I don't worry about keeping these in sync between different
> defconfig files as they are SoC dependent features. And maybe it's a
> sign that my notion that we should have these defaults in the main
> symbol, rather than arch/... various subdirs .../Kconfig was wrong and
> has discouraged setting appropriate defaults. Because in this specific
> example, FPGA-fun aside, it's not very arbitrary as to what address
> space where is available to use when. Well Known Defaults should be
> provided.

I'm not sure, but yes, perhaps arch/ or even board/ is a better place.

>
> > > But imagine you aren't interested in
> > > hearing No and not doing it, again.
> >
> > Not particularly, but I could just do nothing on this.
>
> I will look at "splg4" once it's somewhere on source.denx.de and I can
> look at it, and refrain from otherwise assuming how it solves the
> problems I had seen previously.

I pushed an updated version to dm/splg-working but it is not very
updated. Still needs more work.

Regards,
Simon

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 20 Feb 2025 at 18:30, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > With my
> > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > > > > things for different phases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > > > > and code.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > > > > modification before.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > > > > worse:
> > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > >  endif
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And this is better:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > -
> > > > > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > > > > -
> > > > > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > > > > -
> > > > > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > > > > +endif
> > > > > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > > > > needlessly complex.
> > > > > > > > > > > >
> > > > > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > > > > configuring once.
> > > > > > > > > > > >
> > > > > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > > > > >
> > > > > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > > > > >   depends on SPL
> > > > > > > > > > > >
> > > > > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > > > > >   depends on TPL
> > > > > > > > > > > >
> > > > > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > > > > >
> > > > > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > > > > work.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > > > > >
> > > > > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > > > > existing code to work without a wholesale change.
> > > > > > > > > >
> > > > > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > > > > explaining why.
> > > > > > > > >
> > > > > > > > > See below.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > > This surprised me:
> > > > > > > > > > > > >
> > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > > > > >
> > > > > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > > > > >
> > > > > > > > > > > > Because there is no:
> > > > > > > > > > > > config TPL_RAM
> > > > > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > > > > >
> > > > > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > > > > the same files being built.
> > > > > > > > > > >
> > > > > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > > > > >
> > > > > > > > > > I don't see how that can work in your scheme.
> > > > > > > > >
> > > > > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > > > > >
> > > > > > > > > >>>>
> > > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > #
> > > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > > >
> > > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > > > > spl_common.o
> > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > >
> > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > >
> > > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > >
> > > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > > # meaning "turn it off".
> > > > > > > > > obj-y += boot_mode.o
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > >
> > > > > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > >
> > > > > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > <<<<
> > > > > > > > >
> > > > > > > > > The only change is the line that was:
> > > > > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > >
> > > > > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > > > > agree.
> > > > > > >
> > > > > > > OK good.
> > > > > > >
> > > > > > > >
> > > > > > > > > > > > > For this one:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > > > > >
> > > > > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > > > > refer to symbols based on their name).
> > > > > > > > > > >
> > > > > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > > > > >
> > > > > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > > > > >
> > > > > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > > > > confused about your scheme. I suggested that you don't have
> > > > > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > > > > >
> > > > > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > > > > do you not?
> > > > > > > >
> > > > > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > > > > are never configuring and building for more than one phase.
> > > > > > > >
> > > > > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > > > > (and again for TPL_...). They control different code. While technically
> > > > > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > > > > having the Makefile have to do some two part check like we have today,
> > > > > > > > as those are one of the pain points of adding new code.
> > > > > > >
> > > > > > > OK I think I have some sort of understanding now.
> > > > > > >
> > > > > > > Here is the patch that works for me (on top of your patch above). Note
> > > > > > > that we don't have to make those changes, but they show how my scheme
> > > > > > > is different in what it expects:
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > index 23c30f68f87..0593e028de4 100644
> > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > @@ -7,27 +7,35 @@
> > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > +ifdef CONFIG_XPL_BUILD
> > > > > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > +endif
> > > > > > > +ifdef CONFIG_SPL_BUILD
> > > > > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > +endif
> > > > > > > +ifdef CONFIG_TPL_BUILD
> > > > > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > +endif
> > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > >
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > >
> > > > > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > +
> > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > >  # meaning "turn it off".
> > > > > > >  obj-y += boot_mode.o
> > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > +endif
> > > > > > >
> > > > > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > +endif
> > > > > > >
> > > > > > >  obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > -ifdef CONFIG_PPL
> > > > > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > -endif
> > > > > > > --
> > > > > > > 2.43.0
> > > > > > >
> > > > > > >
> > > > > > > Here's the full file:
> > > > > > >
> > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > #
> > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > >
> > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > ifdef CONFIG_XPL_BUILD
> > > > > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > endif
> > > > > > > ifdef CONFIG_SPL_BUILD
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > endif
> > > > > > > ifdef CONFIG_TPL_BUILD
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > endif
> > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > >
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > >
> > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > >
> > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > # meaning "turn it off".
> > > > > > > obj-y += boot_mode.o
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > endif
> > > > > > >
> > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > endif
> > > > > > >
> > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > >
> > > > > > > So we need CONFIG_SPL_BUILD when using a
> > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > > > > >
> > > > > > > We can't do this with my scheme:
> > > > > > >
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > >
> > > > > > You can't do that with any scheme, to be clear. I don't know why you're
> > > > > > mentioning it.
> > > > >
> > > > > Just so we have a baseline.
> > > > >
> > > > > >
> > > > > > > since that will compile both targets into whatever phases are enabled.
> > > > > > >
> > > > > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > > > > actually prefer this:
> > > > > > >
> > > > > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > > > > endif
> > > > > >
> > > > > > That would be less bad than what you've had earlier, yes. But I think
> > > > > > mine is still clearer.
> > > > >
> > > > > Sure.
> > > > >
> > > > > >
> > > > > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > > > > >
> > > > > > Yes, but it's not the only case like this, it's just the first one that
> > > > > > came to mind.
> > > > >
> > > > > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > > > > before, so I don't think it is common. I am sure there are others, but
> > > > > my scheme does work with existing Makefiles.
> > > >
> > > > It's one of many examples of the workarounds needed for "do we want this
> > > > object in all phases or just some phases".
> > >
> > > You're being too negative IMO. Most of the time the right thing
> > > happens. Yes there are corner cases but I believe you are
> > > mischaracterising my scheme.
> >
> > It's the problem with the way things work today, not just your scheme.
> > It's also one of the not infrequent pain points for what we have today
> > for including / excluding something from a given phase.
> >
> > > > > > > general, when you enable an option for some phases you get that code
> > > > > > > in those phases. When you actually *don't* want the code in a
> > > > > > > particular phase, either don't set the option, or add another
> > > > > > > condition.
> > > > > >
> > > > > > And your proposal doesn't solve that problem, still. Go back up in the
> > > > > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > > > > is still broken.
> > > > >
> > > > > What is broken about it? Are you using the old series? I don't see any
> > > > > changes to the Makefile there in my new series.
> > > >
> > > > I summarized things in the email there. And yes, your series does not
> > > > address and seemingly makes even worse, the problem of
> > > > including/excluding DWC3 from different phases.
> > >
> > > But I really don't know what is wrong with DWC3, honest! When I build
> > > pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
> > > neither before or after my series. So can you please explain in a bit
> > > more detail what you are getting at? The latest version is at splg4 in
> > > my tree, although it's not finished.
> >
> > One of the first steps described in the problem statement is enabling
> > USB gadget for SPL only. This then blows up due to how we have / haven't
> > done workarounds for *USB_DWC3* symbols in Kconfig and also Makefile
> > logic.
> >
> > > > > > > After all, the current Makefile code is actually a bit of a
> > > > > > > workaround. Any scheme is going to have drawbacks.
> > > > > >
> > > > > > Yes, there's lots of workarounds. My scheme removes all of those
> > > > > > workarounds once complete. What phase is being configured and built is a
> > > > > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > > > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> > > > >
> > > > > Yes, I think that's right. For the most part my scheme will do the
> > > > > same, but there will be exceptions, like the rockchip one.
> > > >
> > > > If you're referring to arch/arm/mach-rockchip/Makefile that could be
> > > > rewritten, today, to be a little less cumbersome. It is still an example
> > > > of the tricky workarounds that are needed for including/excluding
> > > > objects based on phases, and is another example of how your series would
> > > > not make adding a new phase easier.
> > >
> > > It makes it easier because you don't have to add loads of plumbing to
> > > get a new phase. Also, with Kconfig changes, adding a phase could
> > > become just a Kconfig thing, with everything else downstream of that,
> > > There would be no need to add completely new Kconfig symbols for every
> > > feature.
> >
> > I guess this is what you've put up in "splg4" now? I'll refrain from
> > commenting until I've had a chance to see what you've done here.
> >
> > > > > > > With my scheme, I want to have the options for all phases in each
> > > > > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > > > > which covers every option in every phase. The down-side of that is
> > > > > > > that you have to be aware of it.
> > > > > >
> > > > > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > > > > by changing how something we've borrowed from a much larger and more
> > > > > > popular project works (and also how other projects which borrow it
> > > > > > work).
> > > > >
> > > > > I don't agree with that. Linux only builds a single build. We are
> > > > > always going to have to do more here than Linux. Also Linux has no
> > > > > interest in taking our Kbuild patches and incidentally, held out
> > > > > against FIT for 10 years! Linux will do what it wants to do. This is
> > > > > U-Boot.
> > > >
> > > > Again, I am proposing we only do a single build.
> > > >
> > > > And yes, this is U-Boot where one of our key attractions is "It's just
> > > > like working in the Linux Kernel, which you're likely already familiar
> > > > with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> > > > that, badly.
> > >
> > > It means CONFIG_FOO for the phase being built, the same as your
> > > scheme. From that POV all we are really talking about is the style of
> > > plumbing.
> > >
> > > If I could think of a way to express things differently in Kconfig, I
> > > would do that. I did suggest at the start some possible extensions,
> > > but you don't want those either.
> >
> > Yes, I suggested language extensions to reduce the symbol increase of
> > "splc-working". I need to look at "splg4" now as that's apparently
> > entirely different before making assumptions and commenting further.
> >
> > > > > > > This did get me thinking though, whether with my scheme we could
> > > > > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > > > > true when building SPL. Basically we would change the existing SPL to
> > > > > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > > > > leave them as they are.
> > > > > > >
> > > > > > > So then you could use
> > > > > > >
> > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > >     depends on SPL
> > > > > > >
> > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > >     depends on TPL
> > > > > > >
> > > > > > > and this would work:
> > > > > > >
> > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > >
> > > > > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > > > > enabled in the TPL build, TPL will not have visibility into that
> > > > > > > option. We have effectively moved closer to your scheme: still with a
> > > > > > > unified Kconfig, but completely split in the source code. Still, we
> > > > > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > > > > appear in all builds.
> > > > > >
> > > > > > Yes, that sounds like it will make some of the existing complex logic
> > > > > > even more complex, and I'm not sure of the benefit.
> > > > >
> > > > > Trying to split the difference between our schemes. I'm going to call
> > > > > this 'option A' for my scheme.
> > > > >
> > > > > >
> > > > > > > We also have to run the 'conf' tool multiple times.
> > > > > >
> > > > > > And to be clear, with my scheme that's a requirement since we're only
> > > > > > building and configuring a single phase. The files I've described with
> > > > > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > > > > especially if it leads to confusion while discussing things.
> > > > >
> > > > > Yes, understood.
> > > > >
> > > > > Basically I think both schemes work. At present I think we should go
> > > > > with my scheme now, since it is pretty close to being complete and
> > > > > involves minimal change to the existing Kconfig, then either do option
> > > > > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > > > > seems that you believe my scheme is worse than the status quo, though,
> > > > > right?
> > > >
> > > > I think we need to come up with some way to get the community to vote on
> > > > your scheme or status quo. I don't think your scheme is "pretty close"
> > > > to being complete and I think it will make things worse than doing
> > > > nothing. I was hoping to get you to think about implementing what I
> > > > proposed instead, but since I still don't think you've understood it,
> > > > that's not an option either.
> > >
> > > I just don't like splitting the defconfig into completely different
> > > files. I know that will open up all sorts of issues. For example, how
> > > will this code work?:
> > >
> > > ulong spl_get_image_text_base(void)
> > > {
> > > #ifdef CONFIG_VPL
> > >    if (xpl_next_phase() == PHASE_VPL)
> > >       return CONFIG_VPL_TEXT_BASE;
> > > #endif
> > >    return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
> > >       CONFIG_TEXT_BASE;
> > > }
> >
> > Well, we start by asking why the FIT image being loaded isn't populated
> > with the load address being valid. And then is anyone still using
> > u-boot.bin and not u-boot.img and could we not just tidy away the whole
> > function?
>
> Sure, but we can't even get sunxi bootstd or LED over the line. How do
> you imagine we could retire the legacy image?
>
> >
> > But then if yes we need that function, we would do:
> >
> > config PPL_TEXT_BASE
> >         hex "Static load address for full U-Boot, formerly TEXT_BASE"
> >         depends on PPL || SPL
> >         ... current default 0xABC if BAR list for TEXT_BASE
> >
> > config TPL_TEXT_BASE
> >         hex "Static load address for TPL phase of U-Boot"
> >         depends on TPL
> >         ... default 0xABC if BAR list
> >
> > config VPL_TEXT_BASE
> >         hex "Static load address for VPL phase of U-Boot"
> >         depends on (TPL && SUPPORTS_VPL) || VPL
> >         ... default 0xABC if BAR list
> >
> > config SPL_TEXT_BASE
> >         hex "Static load address for SPL phase of U-Boot"
> >         depends on ((TPL || VPL) && SUPPORTS_SPL) || SPL
> >         ... current set of default 0xABC if BAR list
> >
> > ulong spl_get_image_text_base(void)
> > {
> > #if defined(CONFIG_TPL) && defined(CONFIG_SUPPORTS_VPL)
> >         return CONFIG_VPL_TEXT_BASE;
> > #elif (defined(CONFIG_TPL) || defined(CONFIG_VPL)) && \
> >                 defined(CONFIG_SUPPORTS_SPL)
> >         return CONFIG_SPL_TEXT_BASE;
> > #else
> >         return CONFIG_PPL_TEXT_BASE;
> > #endif
> > }
> >
> > And I assume one of your objections to the above is that we've removed
> > the macro functions that evaluate to 0 and let the optimizer discard
> > things (except for CC_OPTIMIZE_FOR_DEBUG related problems). But I also
> > see clever macros like that as a hindrance to understanding the code.
>
> Actually, my objection is that it is very confusing. Mixing TPL and
> VPL and SPL. We have to do this for every symbol that depends on or
> uses a default from another phase??

The other problem is that we have to keep these special symbols in
sync manually. Or are you proposing some tools that will check that
they match when the build is done?

I went through one file and half of another and found these which rely
on some PPL value:

SPL_SILENT_CONSOLE
SPL_LOG
SPL_LOGLEVEL
SPL_BLOBLIST
SPL_ACPI
SPL_CRC32
SPL_SHA256
SPL_SHA512

It seems like we would have to do a lot of tedious and error-prone
work to update things, but then we end up with something (in terms of
configuration) less powerful and controllable than we have today?
[..]

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 61665 bytes --]

On Fri, Feb 21, 2025 at 06:56:26AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 20 Feb 2025 at 18:30, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Tom,
> >
> > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > With my
> > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > OK
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > > > > > things for different phases.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > > > > > and code.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > > > > > modification before.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > > > > > worse:
> > > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > >  endif
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And this is better:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > > > > > +endif
> > > > > > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > > > > > needlessly complex.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > > > > > configuring once.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > > > > > >
> > > > > > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > > > > > >   depends on SPL
> > > > > > > > > > > > >
> > > > > > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > > > > > >   depends on TPL
> > > > > > > > > > > > >
> > > > > > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > > > > > work.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > > > > > >
> > > > > > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > > > > > existing code to work without a wholesale change.
> > > > > > > > > > >
> > > > > > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > > > > > explaining why.
> > > > > > > > > >
> > > > > > > > > > See below.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > > This surprised me:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Because there is no:
> > > > > > > > > > > > > config TPL_RAM
> > > > > > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > > > > > >
> > > > > > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > > > > > the same files being built.
> > > > > > > > > > > >
> > > > > > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > > > > > >
> > > > > > > > > > > I don't see how that can work in your scheme.
> > > > > > > > > >
> > > > > > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > > > > > >
> > > > > > > > > > >>>>
> > > > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > > #
> > > > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > > > >
> > > > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > > > > > spl_common.o
> > > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > >
> > > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > >
> > > > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > >
> > > > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > > > # meaning "turn it off".
> > > > > > > > > > obj-y += boot_mode.o
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > endif
> > > > > > > > > >
> > > > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > endif
> > > > > > > > > >
> > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > >
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > >
> > > > > > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > >
> > > > > > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > <<<<
> > > > > > > > > >
> > > > > > > > > > The only change is the line that was:
> > > > > > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > > > > > agree.
> > > > > > > >
> > > > > > > > OK good.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > > > > For this one:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > > > > > >
> > > > > > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > > > > > refer to symbols based on their name).
> > > > > > > > > > > >
> > > > > > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > > > > > >
> > > > > > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > > > > > >
> > > > > > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > > > > > confused about your scheme. I suggested that you don't have
> > > > > > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > > > > > >
> > > > > > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > > > > > do you not?
> > > > > > > > >
> > > > > > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > > > > > are never configuring and building for more than one phase.
> > > > > > > > >
> > > > > > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > > > > > (and again for TPL_...). They control different code. While technically
> > > > > > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > > > > > having the Makefile have to do some two part check like we have today,
> > > > > > > > > as those are one of the pain points of adding new code.
> > > > > > > >
> > > > > > > > OK I think I have some sort of understanding now.
> > > > > > > >
> > > > > > > > Here is the patch that works for me (on top of your patch above). Note
> > > > > > > > that we don't have to make those changes, but they show how my scheme
> > > > > > > > is different in what it expects:
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > index 23c30f68f87..0593e028de4 100644
> > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > @@ -7,27 +7,35 @@
> > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > +ifdef CONFIG_XPL_BUILD
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > +endif
> > > > > > > > +ifdef CONFIG_SPL_BUILD
> > > > > > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > +endif
> > > > > > > > +ifdef CONFIG_TPL_BUILD
> > > > > > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > +endif
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > >
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > >
> > > > > > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > +
> > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > >  # meaning "turn it off".
> > > > > > > >  obj-y += boot_mode.o
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > +endif
> > > > > > > >
> > > > > > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > +endif
> > > > > > > >
> > > > > > > >  obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > -ifdef CONFIG_PPL
> > > > > > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > -endif
> > > > > > > > --
> > > > > > > > 2.43.0
> > > > > > > >
> > > > > > > >
> > > > > > > > Here's the full file:
> > > > > > > >
> > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > #
> > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > >
> > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > ifdef CONFIG_XPL_BUILD
> > > > > > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > endif
> > > > > > > > ifdef CONFIG_SPL_BUILD
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > endif
> > > > > > > > ifdef CONFIG_TPL_BUILD
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > endif
> > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > >
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > >
> > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > >
> > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > # meaning "turn it off".
> > > > > > > > obj-y += boot_mode.o
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > endif
> > > > > > > >
> > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > endif
> > > > > > > >
> > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > >
> > > > > > > > So we need CONFIG_SPL_BUILD when using a
> > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > > > > > >
> > > > > > > > We can't do this with my scheme:
> > > > > > > >
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > >
> > > > > > > You can't do that with any scheme, to be clear. I don't know why you're
> > > > > > > mentioning it.
> > > > > >
> > > > > > Just so we have a baseline.
> > > > > >
> > > > > > >
> > > > > > > > since that will compile both targets into whatever phases are enabled.
> > > > > > > >
> > > > > > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > > > > > actually prefer this:
> > > > > > > >
> > > > > > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > > > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > > > > > endif
> > > > > > >
> > > > > > > That would be less bad than what you've had earlier, yes. But I think
> > > > > > > mine is still clearer.
> > > > > >
> > > > > > Sure.
> > > > > >
> > > > > > >
> > > > > > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > > > > > >
> > > > > > > Yes, but it's not the only case like this, it's just the first one that
> > > > > > > came to mind.
> > > > > >
> > > > > > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > > > > > before, so I don't think it is common. I am sure there are others, but
> > > > > > my scheme does work with existing Makefiles.
> > > > >
> > > > > It's one of many examples of the workarounds needed for "do we want this
> > > > > object in all phases or just some phases".
> > > >
> > > > You're being too negative IMO. Most of the time the right thing
> > > > happens. Yes there are corner cases but I believe you are
> > > > mischaracterising my scheme.
> > >
> > > It's the problem with the way things work today, not just your scheme.
> > > It's also one of the not infrequent pain points for what we have today
> > > for including / excluding something from a given phase.
> > >
> > > > > > > > general, when you enable an option for some phases you get that code
> > > > > > > > in those phases. When you actually *don't* want the code in a
> > > > > > > > particular phase, either don't set the option, or add another
> > > > > > > > condition.
> > > > > > >
> > > > > > > And your proposal doesn't solve that problem, still. Go back up in the
> > > > > > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > > > > > is still broken.
> > > > > >
> > > > > > What is broken about it? Are you using the old series? I don't see any
> > > > > > changes to the Makefile there in my new series.
> > > > >
> > > > > I summarized things in the email there. And yes, your series does not
> > > > > address and seemingly makes even worse, the problem of
> > > > > including/excluding DWC3 from different phases.
> > > >
> > > > But I really don't know what is wrong with DWC3, honest! When I build
> > > > pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
> > > > neither before or after my series. So can you please explain in a bit
> > > > more detail what you are getting at? The latest version is at splg4 in
> > > > my tree, although it's not finished.
> > >
> > > One of the first steps described in the problem statement is enabling
> > > USB gadget for SPL only. This then blows up due to how we have / haven't
> > > done workarounds for *USB_DWC3* symbols in Kconfig and also Makefile
> > > logic.
> > >
> > > > > > > > After all, the current Makefile code is actually a bit of a
> > > > > > > > workaround. Any scheme is going to have drawbacks.
> > > > > > >
> > > > > > > Yes, there's lots of workarounds. My scheme removes all of those
> > > > > > > workarounds once complete. What phase is being configured and built is a
> > > > > > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > > > > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> > > > > >
> > > > > > Yes, I think that's right. For the most part my scheme will do the
> > > > > > same, but there will be exceptions, like the rockchip one.
> > > > >
> > > > > If you're referring to arch/arm/mach-rockchip/Makefile that could be
> > > > > rewritten, today, to be a little less cumbersome. It is still an example
> > > > > of the tricky workarounds that are needed for including/excluding
> > > > > objects based on phases, and is another example of how your series would
> > > > > not make adding a new phase easier.
> > > >
> > > > It makes it easier because you don't have to add loads of plumbing to
> > > > get a new phase. Also, with Kconfig changes, adding a phase could
> > > > become just a Kconfig thing, with everything else downstream of that,
> > > > There would be no need to add completely new Kconfig symbols for every
> > > > feature.
> > >
> > > I guess this is what you've put up in "splg4" now? I'll refrain from
> > > commenting until I've had a chance to see what you've done here.
> > >
> > > > > > > > With my scheme, I want to have the options for all phases in each
> > > > > > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > > > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > > > > > which covers every option in every phase. The down-side of that is
> > > > > > > > that you have to be aware of it.
> > > > > > >
> > > > > > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > > > > > by changing how something we've borrowed from a much larger and more
> > > > > > > popular project works (and also how other projects which borrow it
> > > > > > > work).
> > > > > >
> > > > > > I don't agree with that. Linux only builds a single build. We are
> > > > > > always going to have to do more here than Linux. Also Linux has no
> > > > > > interest in taking our Kbuild patches and incidentally, held out
> > > > > > against FIT for 10 years! Linux will do what it wants to do. This is
> > > > > > U-Boot.
> > > > >
> > > > > Again, I am proposing we only do a single build.
> > > > >
> > > > > And yes, this is U-Boot where one of our key attractions is "It's just
> > > > > like working in the Linux Kernel, which you're likely already familiar
> > > > > with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> > > > > that, badly.
> > > >
> > > > It means CONFIG_FOO for the phase being built, the same as your
> > > > scheme. From that POV all we are really talking about is the style of
> > > > plumbing.
> > > >
> > > > If I could think of a way to express things differently in Kconfig, I
> > > > would do that. I did suggest at the start some possible extensions,
> > > > but you don't want those either.
> > >
> > > Yes, I suggested language extensions to reduce the symbol increase of
> > > "splc-working". I need to look at "splg4" now as that's apparently
> > > entirely different before making assumptions and commenting further.
> > >
> > > > > > > > This did get me thinking though, whether with my scheme we could
> > > > > > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > > > > > true when building SPL. Basically we would change the existing SPL to
> > > > > > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > > > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > > > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > > > > > leave them as they are.
> > > > > > > >
> > > > > > > > So then you could use
> > > > > > > >
> > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > >     depends on SPL
> > > > > > > >
> > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > >     depends on TPL
> > > > > > > >
> > > > > > > > and this would work:
> > > > > > > >
> > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > >
> > > > > > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > > > > > enabled in the TPL build, TPL will not have visibility into that
> > > > > > > > option. We have effectively moved closer to your scheme: still with a
> > > > > > > > unified Kconfig, but completely split in the source code. Still, we
> > > > > > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > > > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > > > > > appear in all builds.
> > > > > > >
> > > > > > > Yes, that sounds like it will make some of the existing complex logic
> > > > > > > even more complex, and I'm not sure of the benefit.
> > > > > >
> > > > > > Trying to split the difference between our schemes. I'm going to call
> > > > > > this 'option A' for my scheme.
> > > > > >
> > > > > > >
> > > > > > > > We also have to run the 'conf' tool multiple times.
> > > > > > >
> > > > > > > And to be clear, with my scheme that's a requirement since we're only
> > > > > > > building and configuring a single phase. The files I've described with
> > > > > > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > > > > > especially if it leads to confusion while discussing things.
> > > > > >
> > > > > > Yes, understood.
> > > > > >
> > > > > > Basically I think both schemes work. At present I think we should go
> > > > > > with my scheme now, since it is pretty close to being complete and
> > > > > > involves minimal change to the existing Kconfig, then either do option
> > > > > > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > > > > > seems that you believe my scheme is worse than the status quo, though,
> > > > > > right?
> > > > >
> > > > > I think we need to come up with some way to get the community to vote on
> > > > > your scheme or status quo. I don't think your scheme is "pretty close"
> > > > > to being complete and I think it will make things worse than doing
> > > > > nothing. I was hoping to get you to think about implementing what I
> > > > > proposed instead, but since I still don't think you've understood it,
> > > > > that's not an option either.
> > > >
> > > > I just don't like splitting the defconfig into completely different
> > > > files. I know that will open up all sorts of issues. For example, how
> > > > will this code work?:
> > > >
> > > > ulong spl_get_image_text_base(void)
> > > > {
> > > > #ifdef CONFIG_VPL
> > > >    if (xpl_next_phase() == PHASE_VPL)
> > > >       return CONFIG_VPL_TEXT_BASE;
> > > > #endif
> > > >    return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
> > > >       CONFIG_TEXT_BASE;
> > > > }
> > >
> > > Well, we start by asking why the FIT image being loaded isn't populated
> > > with the load address being valid. And then is anyone still using
> > > u-boot.bin and not u-boot.img and could we not just tidy away the whole
> > > function?
> >
> > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > you imagine we could retire the legacy image?
> >
> > >
> > > But then if yes we need that function, we would do:
> > >
> > > config PPL_TEXT_BASE
> > >         hex "Static load address for full U-Boot, formerly TEXT_BASE"
> > >         depends on PPL || SPL
> > >         ... current default 0xABC if BAR list for TEXT_BASE
> > >
> > > config TPL_TEXT_BASE
> > >         hex "Static load address for TPL phase of U-Boot"
> > >         depends on TPL
> > >         ... default 0xABC if BAR list
> > >
> > > config VPL_TEXT_BASE
> > >         hex "Static load address for VPL phase of U-Boot"
> > >         depends on (TPL && SUPPORTS_VPL) || VPL
> > >         ... default 0xABC if BAR list
> > >
> > > config SPL_TEXT_BASE
> > >         hex "Static load address for SPL phase of U-Boot"
> > >         depends on ((TPL || VPL) && SUPPORTS_SPL) || SPL
> > >         ... current set of default 0xABC if BAR list
> > >
> > > ulong spl_get_image_text_base(void)
> > > {
> > > #if defined(CONFIG_TPL) && defined(CONFIG_SUPPORTS_VPL)
> > >         return CONFIG_VPL_TEXT_BASE;
> > > #elif (defined(CONFIG_TPL) || defined(CONFIG_VPL)) && \
> > >                 defined(CONFIG_SUPPORTS_SPL)
> > >         return CONFIG_SPL_TEXT_BASE;
> > > #else
> > >         return CONFIG_PPL_TEXT_BASE;
> > > #endif
> > > }
> > >
> > > And I assume one of your objections to the above is that we've removed
> > > the macro functions that evaluate to 0 and let the optimizer discard
> > > things (except for CC_OPTIMIZE_FOR_DEBUG related problems). But I also
> > > see clever macros like that as a hindrance to understanding the code.
> >
> > Actually, my objection is that it is very confusing. Mixing TPL and
> > VPL and SPL. We have to do this for every symbol that depends on or
> > uses a default from another phase??
> 
> The other problem is that we have to keep these special symbols in
> sync manually. Or are you proposing some tools that will check that
> they match when the build is done?
> 
> I went through one file and half of another and found these which rely
> on some PPL value:
> 
> SPL_SILENT_CONSOLE
> SPL_LOG
> SPL_LOGLEVEL
> SPL_BLOBLIST
> SPL_ACPI
> SPL_CRC32
> SPL_SHA256
> SPL_SHA512
> 
> It seems like we would have to do a lot of tedious and error-prone
> work to update things, but then we end up with something (in terms of
> configuration) less powerful and controllable than we have today?

None of those symbols would exist with what I'm proposing, so their
normal default is fine.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 61620 bytes --]

On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > With my
> > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > > > > things for different phases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > > > > and code.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > > > > modification before.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > > > > worse:
> > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > >  endif
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And this is better:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > -
> > > > > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > > > > -
> > > > > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > > > > -
> > > > > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > > > > +endif
> > > > > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > > > > needlessly complex.
> > > > > > > > > > > >
> > > > > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > > > > configuring once.
> > > > > > > > > > > >
> > > > > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > > > > >
> > > > > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > > > > >   depends on SPL
> > > > > > > > > > > >
> > > > > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > > > > >   depends on TPL
> > > > > > > > > > > >
> > > > > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > > > > >
> > > > > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > > > > work.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > > > > >
> > > > > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > > > > existing code to work without a wholesale change.
> > > > > > > > > >
> > > > > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > > > > explaining why.
> > > > > > > > >
> > > > > > > > > See below.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > > This surprised me:
> > > > > > > > > > > > >
> > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > > > > >
> > > > > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > > > > >
> > > > > > > > > > > > Because there is no:
> > > > > > > > > > > > config TPL_RAM
> > > > > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > > > > >
> > > > > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > > > > the same files being built.
> > > > > > > > > > >
> > > > > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > > > > >
> > > > > > > > > > I don't see how that can work in your scheme.
> > > > > > > > >
> > > > > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > > > > >
> > > > > > > > > >>>>
> > > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > #
> > > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > > >
> > > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > > > > spl_common.o
> > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > >
> > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > >
> > > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > >
> > > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > > # meaning "turn it off".
> > > > > > > > > obj-y += boot_mode.o
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > >
> > > > > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > >
> > > > > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > <<<<
> > > > > > > > >
> > > > > > > > > The only change is the line that was:
> > > > > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > >
> > > > > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > > > > agree.
> > > > > > >
> > > > > > > OK good.
> > > > > > >
> > > > > > > >
> > > > > > > > > > > > > For this one:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > > > > >
> > > > > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > > > > refer to symbols based on their name).
> > > > > > > > > > >
> > > > > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > > > > >
> > > > > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > > > > >
> > > > > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > > > > confused about your scheme. I suggested that you don't have
> > > > > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > > > > >
> > > > > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > > > > do you not?
> > > > > > > >
> > > > > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > > > > are never configuring and building for more than one phase.
> > > > > > > >
> > > > > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > > > > (and again for TPL_...). They control different code. While technically
> > > > > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > > > > having the Makefile have to do some two part check like we have today,
> > > > > > > > as those are one of the pain points of adding new code.
> > > > > > >
> > > > > > > OK I think I have some sort of understanding now.
> > > > > > >
> > > > > > > Here is the patch that works for me (on top of your patch above). Note
> > > > > > > that we don't have to make those changes, but they show how my scheme
> > > > > > > is different in what it expects:
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > index 23c30f68f87..0593e028de4 100644
> > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > @@ -7,27 +7,35 @@
> > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > +ifdef CONFIG_XPL_BUILD
> > > > > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > +endif
> > > > > > > +ifdef CONFIG_SPL_BUILD
> > > > > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > +endif
> > > > > > > +ifdef CONFIG_TPL_BUILD
> > > > > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > +endif
> > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > >
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > >
> > > > > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > +
> > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > >  # meaning "turn it off".
> > > > > > >  obj-y += boot_mode.o
> > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > +endif
> > > > > > >
> > > > > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > +endif
> > > > > > >
> > > > > > >  obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > -ifdef CONFIG_PPL
> > > > > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > -endif
> > > > > > > --
> > > > > > > 2.43.0
> > > > > > >
> > > > > > >
> > > > > > > Here's the full file:
> > > > > > >
> > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > #
> > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > >
> > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > ifdef CONFIG_XPL_BUILD
> > > > > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > endif
> > > > > > > ifdef CONFIG_SPL_BUILD
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > endif
> > > > > > > ifdef CONFIG_TPL_BUILD
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > endif
> > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > >
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > >
> > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > >
> > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > # meaning "turn it off".
> > > > > > > obj-y += boot_mode.o
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > endif
> > > > > > >
> > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > endif
> > > > > > >
> > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > >
> > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > >
> > > > > > > So we need CONFIG_SPL_BUILD when using a
> > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > > > > >
> > > > > > > We can't do this with my scheme:
> > > > > > >
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > >
> > > > > > You can't do that with any scheme, to be clear. I don't know why you're
> > > > > > mentioning it.
> > > > >
> > > > > Just so we have a baseline.
> > > > >
> > > > > >
> > > > > > > since that will compile both targets into whatever phases are enabled.
> > > > > > >
> > > > > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > > > > actually prefer this:
> > > > > > >
> > > > > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > > > > endif
> > > > > >
> > > > > > That would be less bad than what you've had earlier, yes. But I think
> > > > > > mine is still clearer.
> > > > >
> > > > > Sure.
> > > > >
> > > > > >
> > > > > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > > > > >
> > > > > > Yes, but it's not the only case like this, it's just the first one that
> > > > > > came to mind.
> > > > >
> > > > > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > > > > before, so I don't think it is common. I am sure there are others, but
> > > > > my scheme does work with existing Makefiles.
> > > >
> > > > It's one of many examples of the workarounds needed for "do we want this
> > > > object in all phases or just some phases".
> > >
> > > You're being too negative IMO. Most of the time the right thing
> > > happens. Yes there are corner cases but I believe you are
> > > mischaracterising my scheme.
> >
> > It's the problem with the way things work today, not just your scheme.
> > It's also one of the not infrequent pain points for what we have today
> > for including / excluding something from a given phase.
> >
> > > > > > > general, when you enable an option for some phases you get that code
> > > > > > > in those phases. When you actually *don't* want the code in a
> > > > > > > particular phase, either don't set the option, or add another
> > > > > > > condition.
> > > > > >
> > > > > > And your proposal doesn't solve that problem, still. Go back up in the
> > > > > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > > > > is still broken.
> > > > >
> > > > > What is broken about it? Are you using the old series? I don't see any
> > > > > changes to the Makefile there in my new series.
> > > >
> > > > I summarized things in the email there. And yes, your series does not
> > > > address and seemingly makes even worse, the problem of
> > > > including/excluding DWC3 from different phases.
> > >
> > > But I really don't know what is wrong with DWC3, honest! When I build
> > > pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
> > > neither before or after my series. So can you please explain in a bit
> > > more detail what you are getting at? The latest version is at splg4 in
> > > my tree, although it's not finished.
> >
> > One of the first steps described in the problem statement is enabling
> > USB gadget for SPL only. This then blows up due to how we have / haven't
> > done workarounds for *USB_DWC3* symbols in Kconfig and also Makefile
> > logic.
> >
> > > > > > > After all, the current Makefile code is actually a bit of a
> > > > > > > workaround. Any scheme is going to have drawbacks.
> > > > > >
> > > > > > Yes, there's lots of workarounds. My scheme removes all of those
> > > > > > workarounds once complete. What phase is being configured and built is a
> > > > > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > > > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> > > > >
> > > > > Yes, I think that's right. For the most part my scheme will do the
> > > > > same, but there will be exceptions, like the rockchip one.
> > > >
> > > > If you're referring to arch/arm/mach-rockchip/Makefile that could be
> > > > rewritten, today, to be a little less cumbersome. It is still an example
> > > > of the tricky workarounds that are needed for including/excluding
> > > > objects based on phases, and is another example of how your series would
> > > > not make adding a new phase easier.
> > >
> > > It makes it easier because you don't have to add loads of plumbing to
> > > get a new phase. Also, with Kconfig changes, adding a phase could
> > > become just a Kconfig thing, with everything else downstream of that,
> > > There would be no need to add completely new Kconfig symbols for every
> > > feature.
> >
> > I guess this is what you've put up in "splg4" now? I'll refrain from
> > commenting until I've had a chance to see what you've done here.
> >
> > > > > > > With my scheme, I want to have the options for all phases in each
> > > > > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > > > > which covers every option in every phase. The down-side of that is
> > > > > > > that you have to be aware of it.
> > > > > >
> > > > > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > > > > by changing how something we've borrowed from a much larger and more
> > > > > > popular project works (and also how other projects which borrow it
> > > > > > work).
> > > > >
> > > > > I don't agree with that. Linux only builds a single build. We are
> > > > > always going to have to do more here than Linux. Also Linux has no
> > > > > interest in taking our Kbuild patches and incidentally, held out
> > > > > against FIT for 10 years! Linux will do what it wants to do. This is
> > > > > U-Boot.
> > > >
> > > > Again, I am proposing we only do a single build.
> > > >
> > > > And yes, this is U-Boot where one of our key attractions is "It's just
> > > > like working in the Linux Kernel, which you're likely already familiar
> > > > with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> > > > that, badly.
> > >
> > > It means CONFIG_FOO for the phase being built, the same as your
> > > scheme. From that POV all we are really talking about is the style of
> > > plumbing.
> > >
> > > If I could think of a way to express things differently in Kconfig, I
> > > would do that. I did suggest at the start some possible extensions,
> > > but you don't want those either.
> >
> > Yes, I suggested language extensions to reduce the symbol increase of
> > "splc-working". I need to look at "splg4" now as that's apparently
> > entirely different before making assumptions and commenting further.
> >
> > > > > > > This did get me thinking though, whether with my scheme we could
> > > > > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > > > > true when building SPL. Basically we would change the existing SPL to
> > > > > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > > > > leave them as they are.
> > > > > > >
> > > > > > > So then you could use
> > > > > > >
> > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > >     depends on SPL
> > > > > > >
> > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > >     depends on TPL
> > > > > > >
> > > > > > > and this would work:
> > > > > > >
> > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > >
> > > > > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > > > > enabled in the TPL build, TPL will not have visibility into that
> > > > > > > option. We have effectively moved closer to your scheme: still with a
> > > > > > > unified Kconfig, but completely split in the source code. Still, we
> > > > > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > > > > appear in all builds.
> > > > > >
> > > > > > Yes, that sounds like it will make some of the existing complex logic
> > > > > > even more complex, and I'm not sure of the benefit.
> > > > >
> > > > > Trying to split the difference between our schemes. I'm going to call
> > > > > this 'option A' for my scheme.
> > > > >
> > > > > >
> > > > > > > We also have to run the 'conf' tool multiple times.
> > > > > >
> > > > > > And to be clear, with my scheme that's a requirement since we're only
> > > > > > building and configuring a single phase. The files I've described with
> > > > > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > > > > especially if it leads to confusion while discussing things.
> > > > >
> > > > > Yes, understood.
> > > > >
> > > > > Basically I think both schemes work. At present I think we should go
> > > > > with my scheme now, since it is pretty close to being complete and
> > > > > involves minimal change to the existing Kconfig, then either do option
> > > > > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > > > > seems that you believe my scheme is worse than the status quo, though,
> > > > > right?
> > > >
> > > > I think we need to come up with some way to get the community to vote on
> > > > your scheme or status quo. I don't think your scheme is "pretty close"
> > > > to being complete and I think it will make things worse than doing
> > > > nothing. I was hoping to get you to think about implementing what I
> > > > proposed instead, but since I still don't think you've understood it,
> > > > that's not an option either.
> > >
> > > I just don't like splitting the defconfig into completely different
> > > files. I know that will open up all sorts of issues. For example, how
> > > will this code work?:
> > >
> > > ulong spl_get_image_text_base(void)
> > > {
> > > #ifdef CONFIG_VPL
> > >    if (xpl_next_phase() == PHASE_VPL)
> > >       return CONFIG_VPL_TEXT_BASE;
> > > #endif
> > >    return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
> > >       CONFIG_TEXT_BASE;
> > > }
> >
> > Well, we start by asking why the FIT image being loaded isn't populated
> > with the load address being valid. And then is anyone still using
> > u-boot.bin and not u-boot.img and could we not just tidy away the whole
> > function?
> 
> Sure, but we can't even get sunxi bootstd or LED over the line. How do
> you imagine we could retire the legacy image?

Partly by focusing on one thing and not 5 things at a time. bootstd is
stuck on reworking efi bootmanager integration, and LED is waiting for
someone to confirm that really, finally, we have all of the old use
cases supported in the new code.

But more importantly, do we really have anyone not using u-boot.img? I
don't know.

> > But then if yes we need that function, we would do:
> >
> > config PPL_TEXT_BASE
> >         hex "Static load address for full U-Boot, formerly TEXT_BASE"
> >         depends on PPL || SPL
> >         ... current default 0xABC if BAR list for TEXT_BASE
> >
> > config TPL_TEXT_BASE
> >         hex "Static load address for TPL phase of U-Boot"
> >         depends on TPL
> >         ... default 0xABC if BAR list
> >
> > config VPL_TEXT_BASE
> >         hex "Static load address for VPL phase of U-Boot"
> >         depends on (TPL && SUPPORTS_VPL) || VPL
> >         ... default 0xABC if BAR list
> >
> > config SPL_TEXT_BASE
> >         hex "Static load address for SPL phase of U-Boot"
> >         depends on ((TPL || VPL) && SUPPORTS_SPL) || SPL
> >         ... current set of default 0xABC if BAR list
> >
> > ulong spl_get_image_text_base(void)
> > {
> > #if defined(CONFIG_TPL) && defined(CONFIG_SUPPORTS_VPL)
> >         return CONFIG_VPL_TEXT_BASE;
> > #elif (defined(CONFIG_TPL) || defined(CONFIG_VPL)) && \
> >                 defined(CONFIG_SUPPORTS_SPL)
> >         return CONFIG_SPL_TEXT_BASE;
> > #else
> >         return CONFIG_PPL_TEXT_BASE;
> > #endif
> > }
> >
> > And I assume one of your objections to the above is that we've removed
> > the macro functions that evaluate to 0 and let the optimizer discard
> > things (except for CC_OPTIMIZE_FOR_DEBUG related problems). But I also
> > see clever macros like that as a hindrance to understanding the code.
> 
> Actually, my objection is that it is very confusing. Mixing TPL and
> VPL and SPL. We have to do this for every symbol that depends on or
> uses a default from another phase??

It shouldn't be confusing. It's less confusing than the current example
because it doesn't rely on inline macros and test ? true : false inline
"if" statements.

That said, it's also in the minority of symbols where we need some
*value* that we only indirectly use *and* it's not just the same value
and so only exists as one question at all. But finally, I was eliding
the default ... part there because none of these should be in a
defconfig and they should come from the Kconfig having the correct
default value. I would be strongly tempted to remove the prompt portion
of the entry if I could make sure the resulting failure was obvious.

> > We
> > would also change xpl_phase() to:
> > static inline enum xpl_phase_t xpl_phase(void)
> > {
> > #ifdef CONFIG_TPL
> >         return PHASE_TPL;
> > #elif defined(CONFIG_VPL)
> >         return PHASE_VPL;
> > #elif defined(CONFIG_SPL)
> >         return PHASE_SPL;
> > #else
> >         DECLARE_GLOBAL_DATA_PTR;
> >
> >         if (!(gd->flags & GD_FLG_RELOC))
> >                 return PHASE_BOARD_F;
> >         else
> >                 return PHASE_BOARD_R;
> > #endif
> > }
> >
> > But could not use it above because we will not globally have *TEXT_BASE
> > defined. And I don't worry about keeping these in sync between different
> > defconfig files as they are SoC dependent features. And maybe it's a
> > sign that my notion that we should have these defaults in the main
> > symbol, rather than arch/... various subdirs .../Kconfig was wrong and
> > has discouraged setting appropriate defaults. Because in this specific
> > example, FPGA-fun aside, it's not very arbitrary as to what address
> > space where is available to use when. Well Known Defaults should be
> > provided.
> 
> I'm not sure, but yes, perhaps arch/ or even board/ is a better place.
> 
> >
> > > > But imagine you aren't interested in
> > > > hearing No and not doing it, again.
> > >
> > > Not particularly, but I could just do nothing on this.
> >
> > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > look at it, and refrain from otherwise assuming how it solves the
> > problems I had seen previously.
> 
> I pushed an updated version to dm/splg-working but it is not very
> updated. Still needs more work.

Thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 21 Feb 2025 at 07:19, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > With my
> > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > OK
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > > > > > things for different phases.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > > > > > and code.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > > > > > modification before.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > > > > > worse:
> > > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > >  endif
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And this is better:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > > > > > +endif
> > > > > > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > > > > > needlessly complex.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > > > > > configuring once.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > > > > > >
> > > > > > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > > > > > >   depends on SPL
> > > > > > > > > > > > >
> > > > > > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > > > > > >   depends on TPL
> > > > > > > > > > > > >
> > > > > > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > > > > > work.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > > > > > >
> > > > > > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > > > > > existing code to work without a wholesale change.
> > > > > > > > > > >
> > > > > > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > > > > > explaining why.
> > > > > > > > > >
> > > > > > > > > > See below.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > > This surprised me:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Because there is no:
> > > > > > > > > > > > > config TPL_RAM
> > > > > > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > > > > > >
> > > > > > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > > > > > the same files being built.
> > > > > > > > > > > >
> > > > > > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > > > > > >
> > > > > > > > > > > I don't see how that can work in your scheme.
> > > > > > > > > >
> > > > > > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > > > > > >
> > > > > > > > > > >>>>
> > > > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > > #
> > > > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > > > >
> > > > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > > > > > spl_common.o
> > > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > >
> > > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > >
> > > > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > >
> > > > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > > > # meaning "turn it off".
> > > > > > > > > > obj-y += boot_mode.o
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > endif
> > > > > > > > > >
> > > > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > endif
> > > > > > > > > >
> > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > >
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > >
> > > > > > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > >
> > > > > > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > <<<<
> > > > > > > > > >
> > > > > > > > > > The only change is the line that was:
> > > > > > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > > > > > agree.
> > > > > > > >
> > > > > > > > OK good.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > > > > For this one:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > > > > > >
> > > > > > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > > > > > refer to symbols based on their name).
> > > > > > > > > > > >
> > > > > > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > > > > > >
> > > > > > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > > > > > >
> > > > > > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > > > > > confused about your scheme. I suggested that you don't have
> > > > > > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > > > > > >
> > > > > > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > > > > > do you not?
> > > > > > > > >
> > > > > > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > > > > > are never configuring and building for more than one phase.
> > > > > > > > >
> > > > > > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > > > > > (and again for TPL_...). They control different code. While technically
> > > > > > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > > > > > having the Makefile have to do some two part check like we have today,
> > > > > > > > > as those are one of the pain points of adding new code.
> > > > > > > >
> > > > > > > > OK I think I have some sort of understanding now.
> > > > > > > >
> > > > > > > > Here is the patch that works for me (on top of your patch above). Note
> > > > > > > > that we don't have to make those changes, but they show how my scheme
> > > > > > > > is different in what it expects:
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > index 23c30f68f87..0593e028de4 100644
> > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > @@ -7,27 +7,35 @@
> > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > +ifdef CONFIG_XPL_BUILD
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > +endif
> > > > > > > > +ifdef CONFIG_SPL_BUILD
> > > > > > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > +endif
> > > > > > > > +ifdef CONFIG_TPL_BUILD
> > > > > > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > +endif
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > >
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > >
> > > > > > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > +
> > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > >  # meaning "turn it off".
> > > > > > > >  obj-y += boot_mode.o
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > +endif
> > > > > > > >
> > > > > > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > +endif
> > > > > > > >
> > > > > > > >  obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > -ifdef CONFIG_PPL
> > > > > > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > -endif
> > > > > > > > --
> > > > > > > > 2.43.0
> > > > > > > >
> > > > > > > >
> > > > > > > > Here's the full file:
> > > > > > > >
> > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > #
> > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > >
> > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > ifdef CONFIG_XPL_BUILD
> > > > > > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > endif
> > > > > > > > ifdef CONFIG_SPL_BUILD
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > endif
> > > > > > > > ifdef CONFIG_TPL_BUILD
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > endif
> > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > >
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > >
> > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > >
> > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > # meaning "turn it off".
> > > > > > > > obj-y += boot_mode.o
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > endif
> > > > > > > >
> > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > endif
> > > > > > > >
> > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > >
> > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > >
> > > > > > > > So we need CONFIG_SPL_BUILD when using a
> > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > > > > > >
> > > > > > > > We can't do this with my scheme:
> > > > > > > >
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > >
> > > > > > > You can't do that with any scheme, to be clear. I don't know why you're
> > > > > > > mentioning it.
> > > > > >
> > > > > > Just so we have a baseline.
> > > > > >
> > > > > > >
> > > > > > > > since that will compile both targets into whatever phases are enabled.
> > > > > > > >
> > > > > > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > > > > > actually prefer this:
> > > > > > > >
> > > > > > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > > > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > > > > > endif
> > > > > > >
> > > > > > > That would be less bad than what you've had earlier, yes. But I think
> > > > > > > mine is still clearer.
> > > > > >
> > > > > > Sure.
> > > > > >
> > > > > > >
> > > > > > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > > > > > >
> > > > > > > Yes, but it's not the only case like this, it's just the first one that
> > > > > > > came to mind.
> > > > > >
> > > > > > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > > > > > before, so I don't think it is common. I am sure there are others, but
> > > > > > my scheme does work with existing Makefiles.
> > > > >
> > > > > It's one of many examples of the workarounds needed for "do we want this
> > > > > object in all phases or just some phases".
> > > >
> > > > You're being too negative IMO. Most of the time the right thing
> > > > happens. Yes there are corner cases but I believe you are
> > > > mischaracterising my scheme.
> > >
> > > It's the problem with the way things work today, not just your scheme.
> > > It's also one of the not infrequent pain points for what we have today
> > > for including / excluding something from a given phase.
> > >
> > > > > > > > general, when you enable an option for some phases you get that code
> > > > > > > > in those phases. When you actually *don't* want the code in a
> > > > > > > > particular phase, either don't set the option, or add another
> > > > > > > > condition.
> > > > > > >
> > > > > > > And your proposal doesn't solve that problem, still. Go back up in the
> > > > > > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > > > > > is still broken.
> > > > > >
> > > > > > What is broken about it? Are you using the old series? I don't see any
> > > > > > changes to the Makefile there in my new series.
> > > > >
> > > > > I summarized things in the email there. And yes, your series does not
> > > > > address and seemingly makes even worse, the problem of
> > > > > including/excluding DWC3 from different phases.
> > > >
> > > > But I really don't know what is wrong with DWC3, honest! When I build
> > > > pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
> > > > neither before or after my series. So can you please explain in a bit
> > > > more detail what you are getting at? The latest version is at splg4 in
> > > > my tree, although it's not finished.
> > >
> > > One of the first steps described in the problem statement is enabling
> > > USB gadget for SPL only. This then blows up due to how we have / haven't
> > > done workarounds for *USB_DWC3* symbols in Kconfig and also Makefile
> > > logic.
> > >
> > > > > > > > After all, the current Makefile code is actually a bit of a
> > > > > > > > workaround. Any scheme is going to have drawbacks.
> > > > > > >
> > > > > > > Yes, there's lots of workarounds. My scheme removes all of those
> > > > > > > workarounds once complete. What phase is being configured and built is a
> > > > > > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > > > > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> > > > > >
> > > > > > Yes, I think that's right. For the most part my scheme will do the
> > > > > > same, but there will be exceptions, like the rockchip one.
> > > > >
> > > > > If you're referring to arch/arm/mach-rockchip/Makefile that could be
> > > > > rewritten, today, to be a little less cumbersome. It is still an example
> > > > > of the tricky workarounds that are needed for including/excluding
> > > > > objects based on phases, and is another example of how your series would
> > > > > not make adding a new phase easier.
> > > >
> > > > It makes it easier because you don't have to add loads of plumbing to
> > > > get a new phase. Also, with Kconfig changes, adding a phase could
> > > > become just a Kconfig thing, with everything else downstream of that,
> > > > There would be no need to add completely new Kconfig symbols for every
> > > > feature.
> > >
> > > I guess this is what you've put up in "splg4" now? I'll refrain from
> > > commenting until I've had a chance to see what you've done here.
> > >
> > > > > > > > With my scheme, I want to have the options for all phases in each
> > > > > > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > > > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > > > > > which covers every option in every phase. The down-side of that is
> > > > > > > > that you have to be aware of it.
> > > > > > >
> > > > > > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > > > > > by changing how something we've borrowed from a much larger and more
> > > > > > > popular project works (and also how other projects which borrow it
> > > > > > > work).
> > > > > >
> > > > > > I don't agree with that. Linux only builds a single build. We are
> > > > > > always going to have to do more here than Linux. Also Linux has no
> > > > > > interest in taking our Kbuild patches and incidentally, held out
> > > > > > against FIT for 10 years! Linux will do what it wants to do. This is
> > > > > > U-Boot.
> > > > >
> > > > > Again, I am proposing we only do a single build.
> > > > >
> > > > > And yes, this is U-Boot where one of our key attractions is "It's just
> > > > > like working in the Linux Kernel, which you're likely already familiar
> > > > > with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> > > > > that, badly.
> > > >
> > > > It means CONFIG_FOO for the phase being built, the same as your
> > > > scheme. From that POV all we are really talking about is the style of
> > > > plumbing.
> > > >
> > > > If I could think of a way to express things differently in Kconfig, I
> > > > would do that. I did suggest at the start some possible extensions,
> > > > but you don't want those either.
> > >
> > > Yes, I suggested language extensions to reduce the symbol increase of
> > > "splc-working". I need to look at "splg4" now as that's apparently
> > > entirely different before making assumptions and commenting further.
> > >
> > > > > > > > This did get me thinking though, whether with my scheme we could
> > > > > > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > > > > > true when building SPL. Basically we would change the existing SPL to
> > > > > > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > > > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > > > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > > > > > leave them as they are.
> > > > > > > >
> > > > > > > > So then you could use
> > > > > > > >
> > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > >     depends on SPL
> > > > > > > >
> > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > >     depends on TPL
> > > > > > > >
> > > > > > > > and this would work:
> > > > > > > >
> > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > >
> > > > > > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > > > > > enabled in the TPL build, TPL will not have visibility into that
> > > > > > > > option. We have effectively moved closer to your scheme: still with a
> > > > > > > > unified Kconfig, but completely split in the source code. Still, we
> > > > > > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > > > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > > > > > appear in all builds.
> > > > > > >
> > > > > > > Yes, that sounds like it will make some of the existing complex logic
> > > > > > > even more complex, and I'm not sure of the benefit.
> > > > > >
> > > > > > Trying to split the difference between our schemes. I'm going to call
> > > > > > this 'option A' for my scheme.
> > > > > >
> > > > > > >
> > > > > > > > We also have to run the 'conf' tool multiple times.
> > > > > > >
> > > > > > > And to be clear, with my scheme that's a requirement since we're only
> > > > > > > building and configuring a single phase. The files I've described with
> > > > > > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > > > > > especially if it leads to confusion while discussing things.
> > > > > >
> > > > > > Yes, understood.
> > > > > >
> > > > > > Basically I think both schemes work. At present I think we should go
> > > > > > with my scheme now, since it is pretty close to being complete and
> > > > > > involves minimal change to the existing Kconfig, then either do option
> > > > > > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > > > > > seems that you believe my scheme is worse than the status quo, though,
> > > > > > right?
> > > > >
> > > > > I think we need to come up with some way to get the community to vote on
> > > > > your scheme or status quo. I don't think your scheme is "pretty close"
> > > > > to being complete and I think it will make things worse than doing
> > > > > nothing. I was hoping to get you to think about implementing what I
> > > > > proposed instead, but since I still don't think you've understood it,
> > > > > that's not an option either.
> > > >
> > > > I just don't like splitting the defconfig into completely different
> > > > files. I know that will open up all sorts of issues. For example, how
> > > > will this code work?:
> > > >
> > > > ulong spl_get_image_text_base(void)
> > > > {
> > > > #ifdef CONFIG_VPL
> > > >    if (xpl_next_phase() == PHASE_VPL)
> > > >       return CONFIG_VPL_TEXT_BASE;
> > > > #endif
> > > >    return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
> > > >       CONFIG_TEXT_BASE;
> > > > }
> > >
> > > Well, we start by asking why the FIT image being loaded isn't populated
> > > with the load address being valid. And then is anyone still using
> > > u-boot.bin and not u-boot.img and could we not just tidy away the whole
> > > function?
> >
> > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > you imagine we could retire the legacy image?
>
> Partly by focusing on one thing and not 5 things at a time. bootstd is
> stuck on reworking efi bootmanager integration, and LED is waiting for
> someone to confirm that really, finally, we have all of the old use
> cases supported in the new code.
>
> But more importantly, do we really have anyone not using u-boot.img? I
> don't know.

If we did one of these sorts of things at a time, we would only get
2-3 things done each year!

>
> > > But then if yes we need that function, we would do:
> > >
> > > config PPL_TEXT_BASE
> > >         hex "Static load address for full U-Boot, formerly TEXT_BASE"
> > >         depends on PPL || SPL
> > >         ... current default 0xABC if BAR list for TEXT_BASE
> > >
> > > config TPL_TEXT_BASE
> > >         hex "Static load address for TPL phase of U-Boot"
> > >         depends on TPL
> > >         ... default 0xABC if BAR list
> > >
> > > config VPL_TEXT_BASE
> > >         hex "Static load address for VPL phase of U-Boot"
> > >         depends on (TPL && SUPPORTS_VPL) || VPL
> > >         ... default 0xABC if BAR list
> > >
> > > config SPL_TEXT_BASE
> > >         hex "Static load address for SPL phase of U-Boot"
> > >         depends on ((TPL || VPL) && SUPPORTS_SPL) || SPL
> > >         ... current set of default 0xABC if BAR list
> > >
> > > ulong spl_get_image_text_base(void)
> > > {
> > > #if defined(CONFIG_TPL) && defined(CONFIG_SUPPORTS_VPL)
> > >         return CONFIG_VPL_TEXT_BASE;
> > > #elif (defined(CONFIG_TPL) || defined(CONFIG_VPL)) && \
> > >                 defined(CONFIG_SUPPORTS_SPL)
> > >         return CONFIG_SPL_TEXT_BASE;
> > > #else
> > >         return CONFIG_PPL_TEXT_BASE;
> > > #endif
> > > }
> > >
> > > And I assume one of your objections to the above is that we've removed
> > > the macro functions that evaluate to 0 and let the optimizer discard
> > > things (except for CC_OPTIMIZE_FOR_DEBUG related problems). But I also
> > > see clever macros like that as a hindrance to understanding the code.
> >
> > Actually, my objection is that it is very confusing. Mixing TPL and
> > VPL and SPL. We have to do this for every symbol that depends on or
> > uses a default from another phase??
>
> It shouldn't be confusing. It's less confusing than the current example
> because it doesn't rely on inline macros and test ? true : false inline
> "if" statements.
>
> That said, it's also in the minority of symbols where we need some
> *value* that we only indirectly use *and* it's not just the same value
> and so only exists as one question at all. But finally, I was eliding
> the default ... part there because none of these should be in a
> defconfig and they should come from the Kconfig having the correct
> default value. I would be strongly tempted to remove the prompt portion
> of the entry if I could make sure the resulting failure was obvious.

It's confusing because we have to update one phase to make a copy of
the symbol from another phase and then keep them in sync.

The current code is much more obvious:

ulong spl_get_image_text_base(void)
{
#ifdef CONFIG_VPL
        if (xpl_next_phase() == PHASE_VPL)
                return CONFIG_VPL_TEXT_BASE;
#endif
        return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
                CONFIG_TEXT_BASE;
}

and with splg, also obvious:

ulong spl_get_image_text_base(void)
{
#ifdef CONFIG_VPL
        if (xpl_next_phase() == PHASE_VPL)
                return CONFIG_VPL_TEXT_BASE;
#endif
        return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
                CONFIG_PPL_TEXT_BASE;
}

and I suspect we could avoid #ifdef with a bit of thought.

>
> > > We
> > > would also change xpl_phase() to:
> > > static inline enum xpl_phase_t xpl_phase(void)
> > > {
> > > #ifdef CONFIG_TPL
> > >         return PHASE_TPL;
> > > #elif defined(CONFIG_VPL)
> > >         return PHASE_VPL;
> > > #elif defined(CONFIG_SPL)
> > >         return PHASE_SPL;
> > > #else
> > >         DECLARE_GLOBAL_DATA_PTR;
> > >
> > >         if (!(gd->flags & GD_FLG_RELOC))
> > >                 return PHASE_BOARD_F;
> > >         else
> > >                 return PHASE_BOARD_R;
> > > #endif
> > > }
> > >
> > > But could not use it above because we will not globally have *TEXT_BASE
> > > defined. And I don't worry about keeping these in sync between different
> > > defconfig files as they are SoC dependent features. And maybe it's a
> > > sign that my notion that we should have these defaults in the main
> > > symbol, rather than arch/... various subdirs .../Kconfig was wrong and
> > > has discouraged setting appropriate defaults. Because in this specific
> > > example, FPGA-fun aside, it's not very arbitrary as to what address
> > > space where is available to use when. Well Known Defaults should be
> > > provided.
> >
> > I'm not sure, but yes, perhaps arch/ or even board/ is a better place.
> >
> > >
> > > > > But imagine you aren't interested in
> > > > > hearing No and not doing it, again.
> > > >
> > > > Not particularly, but I could just do nothing on this.
> > >
> > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > look at it, and refrain from otherwise assuming how it solves the
> > > problems I had seen previously.
> >
> > I pushed an updated version to dm/splg-working but it is not very
> > updated. Still needs more work.
>
> Thanks.

[joining threads, sorry about sending out of turn]
>
>
> > >
> > > Actually, my objection is that it is very confusing. Mixing TPL and
> > > VPL and SPL. We have to do this for every symbol that depends on or
> > > uses a default from another phase??
> >
> > The other problem is that we have to keep these special symbols in
> > sync manually. Or are you proposing some tools that will check that
> > they match when the build is done?
> >
> > I went through one file and half of another and found these which rely
> > on some PPL value:
> >
> > SPL_SILENT_CONSOLE
> > SPL_LOG
> > SPL_LOGLEVEL
> > SPL_BLOBLIST
> > SPL_ACPI
> > SPL_CRC32
> > SPL_SHA256
> > SPL_SHA512
> >
> > It seems like we would have to do a lot of tedious and error-prone
> > work to update things, but then we end up with something (in terms of
> > configuration) less powerful and controllable than we have today?

> None of those symbols would exist with what I'm proposing, so their
> normal default is fine.

Doesn't that mean that (before your scheme can land) you have to go
through all the Kconfig to remove 90% of the SPL/TPL/VPL symbols from
Kconfig?

I'm not sure if this is accurate, but it gives an idea, just for this point:

$ grep -A4 "config SPL_" `find . -name "Kconfig*"` |grep -P 'depends
on (?!SPL_)' |wc -l
229

I'm really very concerned about splitting the Kconfig entirely right
off the bat. I believe for a first step, we need to keep a 'whole'
Kconfig and allow phases to access each others options. In other
words, do the minimum we can to split the config and deal with the
fallout from that, then plan the next move.

Nothing in my scheme precludes splitting the config earlier. I do note
your serious concerns about confusion in Makefiles but in general it
will simplify the Makefiles and I don't see it as confusing as you do.

I don't think I have convinced you that my scheme is a step towards
yours, though? You are so worried about one type of confusion that you
don't even want to go there?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 80722 bytes --]

On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 21 Feb 2025 at 07:19, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 20 Feb 2025 at 10:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 20, 2025 at 09:43:10AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 20 Feb 2025 at 08:16, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 20, 2025 at 06:19:05AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Wed, 19 Feb 2025 at 13:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Feb 19, 2025 at 07:48:17AM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 18 Feb 2025 at 18:07, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Feb 18, 2025 at 05:03:08PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 18 Feb 2025 at 07:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Feb 18, 2025 at 05:08:40AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 17:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:39:37PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 13:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 01:47:32PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:34:01PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Mon, Feb 17, 2025 at 12:11:12PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Mon, 17 Feb 2025 at 11:50, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 03:22:22PM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > > > > > > > > > > > > > > > > > > > > > > > next iteration of xPL.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > A recent series introduced 'xPL' as the name for the various
> > > > > > > > > > > > > > > > > > > > > > > > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > > > > > > > > > > > > > > > > > > > > > > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > > > > > > > > > > > > > > > > > > > > > > > still use filenames and function naming which uses 'spl', but could
> > > > > > > > > > > > > > > > > > > > > > > > > potentially adjust that.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > The major remaining problem IMO is that it is quite tricky and
> > > > > > > > > > > > > > > > > > > > > > > > > expensive (in terms of time) to add a new phase. We also have some
> > > > > > > > > > > > > > > > > > > > > > > > > medium-sized problems:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > > > > > > > > > > > > > > > > > > > > > > > can be confusing, particularly when combined with ifdef and ifneq
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > > > > > > > > > > > > > > > > > > > > > > > different things. For any given option, some code uses one and some
> > > > > > > > > > > > > > > > > > > > > > > > > the other, depending on what problems people have met along the way.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > > > > > > > > > > > > > > > > > > > > > > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > > > > > > > > > > > > > > > > > > > > > > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > > > > > > > > > > > > > > > > > > > > > > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > > > > > > > > > > > > > > > > > > > > > > > and has not scaled well.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > d. We need to retain an important feature: options from different
> > > > > > > > > > > > > > > > > > > > > > > > > phases can depend on each other. As an example, we might want to
> > > > > > > > > > > > > > > > > > > > > > > > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > > > > > > > > > > > > > > > > > > > > > > > may also want to share values between phases, such as TEXT_BASE. We
> > > > > > > > > > > > > > > > > > > > > > > > > can do this easily today, just by adding Kconfig rules.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I agree with a through c and for d there are likely some cases even if
> > > > > > > > > > > > > > > > > > > > > > > > I'm not sure TEXT_BASE is a good example. But I'm not sure it's as
> > > > > > > > > > > > > > > > > > > > > > > > important as the other ones.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Proposal
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > > > > > > > > > > > > > > > > > > > > > > > These contain the values for each Kconfig option for that phase. For
> > > > > > > > > > > > > > > > > > > > > > > > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > > > > > > > > > > > > > > > > > > > > > > > Kconfig options which should not be enabled/valid in any xPL build.
> > > > > > > > > > > > > > > > > > > > > > > > > There are around 200 of these.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > > > > > > > > > > > > > > > > > > > > > > > useful in rare cases. This indicates that the option applies only to
> > > > > > > > > > > > > > > > > > > > > > > > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > > > > > > > > > > > > > > > > > > > > > > > needed at present, basically to allow access to the value for another
> > > > > > > > > > > > > > > > > > > > > > > > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > > > > > > > > > > > > > > > > > > > > > > > the address to which U-Boot should be loaded.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 4. There is no change to the existing defconfig files, or 'make
> > > > > > > > > > > > > > > > > > > > > > > > > menuconfig', which works just as today, including dependencies between
> > > > > > > > > > > > > > > > > > > > > > > > > options across all phases.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > > > > > > > > > > > > > > > > > > > > > > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > > > > > > > > > > > > > > > > > > > > > > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > > > > > > > > > > > > > > > > > > > > > > > declared once for any/all phases. We can then drop the file in 2
> > > > > > > > > > > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > > > > > > > > > > > > > > > > > > > > > > > phase should be considerably easier.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I think this will not make our life easier, it will make things harder.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I think what we've reached now shows that Yamada-san was correct at the
> > > > > > > > > > > > > > > > > > > > > > > > time in saying that we were going down the wrong path with how we
> > > > > > > > > > > > > > > > > > > > > > > > handled SPL/TPL.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > My request instead is:
> > > > > > > > > > > > > > > > > > > > > > > > - Largely drop SPL/TPL/VPL (so no DM_MMC and SPL_DM_MMC and so on, just
> > > > > > > > > > > > > > > > > > > > > > > >   DM_MMC) as a prefix.
> > > > > > > > > > > > > > > > > > > > > > > > - Likely need to introduce a PPL symbol as you suggest.
> > > > > > > > > > > > > > > > > > > > > > > > - Make PPL/SPL/TPL/VPL be a choice statement when building a defconfig.
> > > > > > > > > > > > > > > > > > > > > > > > - Split something like rockpro64-rk3399_defconfig in to
> > > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > >   rockpro64-rk3399_spl_defconfig rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > >   and add Makefile logic such that for X_defconfig as a build target but
> > > > > > > > > > > > > > > > > > > > > > > >   not configs/X_defconfig not existing, we see if any of
> > > > > > > > > > > > > > > > > > > > > > > >   configs/X_{ppl,spl,tpl,vpl}_defconfig exist and we run a builds in
> > > > > > > > > > > > > > > > > > > > > > > >   subdirectories of our object directory, and then using binman combine
> > > > > > > > > > > > > > > > > > > > > > > >   as needed.
> > > > > > > > > > > > > > > > > > > > > > > >   - Maybe instead the Makefile logic above we would parse X_defconfig
> > > > > > > > > > > > > > > > > > > > > > > >     and see if it's a different format of say PHASE:file to make it
> > > > > > > > > > > > > > > > > > > > > > > >     easier to say share a single TPL config with all rk3399, have a few
> > > > > > > > > > > > > > > > > > > > > > > >     common SPL configs and then just a board specific PPL.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > This solves (a) by removing them entirely. This solves (b) by removing
> > > > > > > > > > > > > > > > > > > > > > > > the ambiguity entirely (it will be enabled or not). As a bonus for (b)
> > > > > > > > > > > > > > > > > > > > > > > > we can switch everyone to IS_ENABLED(CONFIG_FOO) and match up with the
> > > > > > > > > > > > > > > > > > > > > > > > Linux Kernel again. This solves (c) again by removing it entirely.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Lets come back up here, to my proposal, since parts of it seem to have
> > > > > > > > > > > > > > > > > > > > > > > not been clear enough. While what I'm proposing should work for any
> > > > > > > > > > > > > > > > > > > > > > > platform and xPL -> xPL -> ... -> PPL, for this example let us assume
> > > > > > > > > > > > > > > > > > > > > > > rockpro64-rk3399 supports the flow of TPL -> SPL -> PPL. Also, to
> > > > > > > > > > > > > > > > > > > > > > > compare with today, it will be helpful to run "make
> > > > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_current rockpro64-rk3399_config" and have the
> > > > > > > > > > > > > > > > > > > > > > > resulting .config file available.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > There shall be configs/rockpro64-rk3399_tpl_defconfig. This will contain
> > > > > > > > > > > > > > > > > > > > > > > lines such as:
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_ARM=y
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_ARCH_ROCKCHIP=y
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_ROCKCHIP_RK3399=y
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > When you run "make O=/tmp/rockpro64-rk3399_tpl rockpro64-rk3399_tpl_defconfig"
> > > > > > > > > > > > > > > > > > > > > > > the resulting .config file will contain lines such as:
> > > > > > > > > > > > > > > > > > > > > > > # CONFIG_ROCKCHIP_EXTERNAL_TPL is not set
> > > > > > > > > > > > > > > > > > > > > > > as this only makes sense in the context of building something that will
> > > > > > > > > > > > > > > > > > > > > > > be TPL.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > A more complex example is that it will also contain:
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Because looking at arch/arm/mach-rockchip/Makefile a bunch of that will
> > > > > > > > > > > > > > > > > > > > > > > be able to be simplified (and spl_common.c should be renamed to
> > > > > > > > > > > > > > > > > > > > > > > xpl_common.c) to:
> > > > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o xpl_common.o
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The .config file here will also contain:
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > What it will not contain is:
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > This is because there is no 'config TPL_DM_SERIAL' option in
> > > > > > > > > > > > > > > > > > > > > > > drivers/serial/Kconfig anymore.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > When you next run "make O=/tmp/rockpro64-rk3399_tpl all" the results in
> > > > > > > > > > > > > > > > > > > > > > > /tmp/rockpro64-rk3399_tpl would be similar to the results as under
> > > > > > > > > > > > > > > > > > > > > > > "/tmp/rockpro64-rk3399/tpl/" when building today.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The contents of configs/rockpro64-rk3399_spl_defconfig would be similar
> > > > > > > > > > > > > > > > > > > > > > > to the tpl one, except with SPL-only-ever-valid options such as
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y but otherwise have CONFIG_DM_SERIAL=y
> > > > > > > > > > > > > > > > > > > > > > > and no CONFIG_SPL_DM_SERIAL=y, and when building the "all" target, you
> > > > > > > > > > > > > > > > > > > > > > > would only get similar results to what is under the spl/ directory
> > > > > > > > > > > > > > > > > > > > > > > today.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Next we have configs/rockpro64-rk3399_ppl_defconfig.  When you run "make
> > > > > > > > > > > > > > > > > > > > > > > O=/tmp/rockpro64-rk3399_ppl rockpro64-rk3399_ppl_defconfig" the
> > > > > > > > > > > > > > > > > > > > > > > important difference is what you do not have. You do not have:
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_SPL=y
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_TPL=y
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Because we are not building SPL nor TPL. We're just making full U-Boot
> > > > > > > > > > > > > > > > > > > > > > > itself. This is where in more full examples and with additional
> > > > > > > > > > > > > > > > > > > > > > > restructure a "generic-arm64_ppl_defconfig" makes sense and be used
> > > > > > > > > > > > > > > > > > > > > > > instead.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > This brings up what to do with "ockpro64-rk3399_defconfig". And I'm a
> > > > > > > > > > > > > > > > > > > > > > > little unsure which of the things I mentioned above is best. It's
> > > > > > > > > > > > > > > > > > > > > > > either:
> > > > > > > > > > > > > > > > > > > > > > > a) Does not exist, top-level Makefile says roughly:
> > > > > > > > > > > > > > > > > > > > > > > %_defconfig: %_tpl_defconfig %_spl_defconfig %_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/tpl %_tpl_defconfig all
> > > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/spl %_spl_defconfig all
> > > > > > > > > > > > > > > > > > > > > > >   make O=$(objdir)/ppl %_ppl_defconfig all
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > But this might be too rigid.
> > > > > > > > > > > > > > > > > > > > > > > b) It contains:
> > > > > > > > > > > > > > > > > > > > > > > PHASE:VPL:rockpro64-rk3399_vpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > PHASE:TPL:rockpro64-rk3399_tpl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > PHASE:SPL:rockpro64-rk3399_spl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > PHASE:PPL:rockpro64-rk3399_ppl_defconfig
> > > > > > > > > > > > > > > > > > > > > > > And the top-level Makefile looks like:
> > > > > > > > > > > > > > > > > > > > > > > %_defconfig:
> > > > > > > > > > > > > > > > > > > > > > >   grep -q ^PHASE $@ || fatal "Invalid defconfig file, please see..."
> > > > > > > > > > > > > > > > > > > > > > >   foreach line in $@
> > > > > > > > > > > > > > > > > > > > > > >     make O=$(objdir)/$PHASE $CONFIGFILE all
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > It could also be some other suggestion.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks for writing that up. It is somewhat clearer.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > What happens to the Makefiles? Do they still have $(PHASE_) in them?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > No. Because CONFIG_SPL_FIT would never exist, $(CONFIG_$(PHASE_)FIT)
> > > > > > > > > > > > > > > > > > > > > would be meaningless. Only rockpro64-rk3399_spl_defconfig would say
> > > > > > > > > > > > > > > > > > > > > CONFIG_FIT=y (or more likely, only the resulting .config would say
> > > > > > > > > > > > > > > > > > > > > CONFIG_FIT=y just like how configs/rockpro64-rk3399_defconfig doesn't
> > > > > > > > > > > > > > > > > > > > > say CONFIG_FIT=y nor CONFIG_SPL_FIT=y).
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > But just above you said:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I believe this proposal will lead to the code and Makefiles being less
> > > > > > > > > > > > > > > > > > > > > clear than they are today. The line:
> > > > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
> > > > > > > > > > > > > > > > > > > > > will become:
> > > > > > > > > > > > > > > > > > > > > drivers/Makefile:obj-$(CONFIG_BLK) += block/
> > > > > > > > > > > > > > > > > > > > > without being clear that it could reference either full U-Boot (PPL) or
> > > > > > > > > > > > > > > > > > > > > some xPL phase. While the same Makefile will continue to have (comments
> > > > > > > > > > > > > > > > > > > > > my own):
> > > > > > > > > > > > > > > > > > > > > obj-y += mtd/ # Subdirectory Makefiles control build contents
> > > > > > > > > > > > > > > > > > > > > obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > And so the situation for humans will be worse off than today because
> > > > > > > > > > > > > > > > > > > > > while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
> > > > > > > > > > > > > > > > > > > > > what can and cannot be enabled in PPL vs xPL.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Doing "something" is not better than doing nothing in this case.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > So why is OK for your proposal to drop the $(PHASE_) stuff, but not mine?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Because your proposal keeps CONFIG_SPL_BLK (and config SPL_BLK) and has
> > > > > > > > > > > > > > > > > > > a .config file which says "CONFIG_SPL_BLK=y" but mine doesn't.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > With my
> > > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > There will be at least some matches, e.g. CONFIG_SPL_BLK in the
> > > > > > > > > > > > > > > > > defconfig files and 'config SPL_BLK' in the source tree.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, and that's confusing. I am arguing that your statement is more
> > > > > > > > > > > > > > > > confusing than $(PHASE_)BLK is.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > OK
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Or to try and explain differently, with your proposal "I have a problem,
> > > > > > > > > > > > > > > > > > > and I want to see what builds with CONFIG_SPL_BLK=y. Why is there no
> > > > > > > > > > > > > > > > > > > match in the source tree for CONFIG_SPL_BLK or even SPL_BLK". With my
> > > > > > > > > > > > > > > > > > > proposal "I have a problem, and I want to see what my SPL build has with
> > > > > > > > > > > > > > > > > > > CONFIG_BLK=y. I can see hits in the source tree for CONFIG_BLK, the
> > > > > > > > > > > > > > > > > > > symbol I set, I can solve my problem."
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Well, CONFIG_BLK will be in the source tree; it just means different
> > > > > > > > > > > > > > > > > things for different phases.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And it will be, with your proposal, controlled by BLK or SPL_BLK or
> > > > > > > > > > > > > > > > TPL_BLK or VPL_BLK in the .config file but only CONFIG_BLK in Makefile
> > > > > > > > > > > > > > > > and code.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > It sounds like you want to get rid of the xPL prefixes for Kconfig
> > > > > > > > > > > > > > > > > options, and that overrides all other considerations?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It's one of the big problems we have today, and splc-working shows how
> > > > > > > > > > > > > > > > much further the duplication must go. It's why I suggested the language
> > > > > > > > > > > > > > > > modification before.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > My other try here was a bit unclear actually because of the confusion
> > > > > > > > > > > > > > > > > > state your proposal gives us. Try try again directly, the problem is
> > > > > > > > > > > > > > > > > > that CONFIG_SPL_BLK will be set (or unset) but not referenced in code.
> > > > > > > > > > > > > > > > > > This will be true for many but not all SPL symbols as
> > > > > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD for example will still exist and need
> > > > > > > > > > > > > > > > > > to be referenced. This is a more confusing state than $(PHASE_). $(XPL_)
> > > > > > > > > > > > > > > > > > I think can just be replaced with $(PHASE_) but I haven't confirmed (I
> > > > > > > > > > > > > > > > > > think it does show that the old way was confusing however).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > OK, I think I see. You don't want people to have to 'know' that
> > > > > > > > > > > > > > > > > CONFIG_xPL_xxx is used to control feature xxx in each xPL build?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm saying they have to know that, and also know which symbols that's
> > > > > > > > > > > > > > > > not true for. And that is more confusing than today. I'm saying that
> > > > > > > > > > > > > > > > compared with today's arch/arm/mach-rockchip/Makefile the following is
> > > > > > > > > > > > > > > > worse:
> > > > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > > index 5e7edc99cdc4..3b176966f75b 100644
> > > > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > > @@ -29,7 +29,7 @@ ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > > >  endif
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > (And CONFIG_TPL_RAM and CONFIG_SPL_RAM still exist).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And this is better:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > > index 5e7edc99cdc4..23c30f68f878 100644
> > > > > > > > > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > > > > > > > > @@ -7,15 +7,13 @@
> > > > > > > > > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > > -obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > > > -obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > > > > > > +obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > > -ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > > > +obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > > > > > > @@ -23,14 +21,13 @@ ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > > >  # meaning "turn it off".
> > > > > > > > > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > > > > > > -endif
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > > > > > > > > +obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > +ifdef CONFIG_PPL
> > > > > > > > > > > > > > > > +# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > > > > > > @@ -46,10 +43,4 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > > -# Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > > > > > > -obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > > -# Now add SPL/TPL objects back into the main build
> > > > > > > > > > > > > > > > -obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > > > > > > -obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > > > > > > +endif
> > > > > > > > > > > > > > > > (CONFIG_SPL_RAM and CONFIG_TPL_RAM no longer exist as options).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This Makefile is a very strange example. I've thought about cleaning
> > > > > > > > > > > > > > > it up a few times, but then I know someone will say it needs to be in
> > > > > > > > > > > > > > > its own series, etc. so I've never got around to it. Even with the
> > > > > > > > > > > > > > > current xPL stuff (i.e. making CONFIG_SPL_BUILD mean just SPL) it is
> > > > > > > > > > > > > > > needlessly complex.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There's some complexity that can be removed here today, maybe. But not a
> > > > > > > > > > > > > > lot of it, because it's complex to build three different things when
> > > > > > > > > > > > > > configuring once.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Anyway, with my scheme, you can still use
> > > > > > > > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD if you want to. It adds SPL_ versions
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > No. You have to use it still, with yours. Because
> > > > > > > > > > > > > > "ROCKCHIP_COMMON_BOARD", "SPL_ROCKCHIP_COMMON_BOARD" and
> > > > > > > > > > > > > > "TPL_ROCKCHIP_COMMON_BOARD" are the same concept of "use common board
> > > > > > > > > > > > > > code" but different files at TPL, SPL and PPL. And you still have to
> > > > > > > > > > > > > > with mine, because for the same reason. With mine, the Kconfig is:
> > > > > > > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > > > >   bool "SPL rockchip common board file"
> > > > > > > > > > > > > >   depends on SPL
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > > > > > > >   bool "TPL rockchip common board file"
> > > > > > > > > > > > > >   depends on TPL
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And since you are only ever configuring for TPL or SPL or PPL (or VPL or
> > > > > > > > > > > > > > ...) the resulting config only ever asks for the appropriate one.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > of symbols to autoconf_spl.h for this reason. There are also places in
> > > > > > > > > > > > > > > the code where people directly check CONFIG_SPL_xxx and these need to
> > > > > > > > > > > > > > > work.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, this is part of the confusion I keep noting with your proposal as
> > > > > > > > > > > > > > it will be inconsistent for which symbols CONFIG_SPL_xxx is referred to
> > > > > > > > > > > > > > in code as CONFIG_SPL_xxx or as CONFIG_xxx.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If it is confusing, we can change all of them to CONFIG_xxx in a
> > > > > > > > > > > > > follow-up. There is no need to mention SPL_, it just allows the
> > > > > > > > > > > > > existing code to work without a wholesale change.
> > > > > > > > > > > >
> > > > > > > > > > > > No, that's not correct. Please look again at what I've written
> > > > > > > > > > > > explaining why.
> > > > > > > > > > >
> > > > > > > > > > > See below.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > > This surprised me:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Are you saying you are OK with this one, instead of, for example:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > obj-$(CONFIG_TPL_RAM) += sdram.o
> > > > > > > > > > > > > > > obj-$(CONFIG_SPL_RAM) += sdram.o
> > > > > > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If so, why are you OK with that and not the others?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Because there is no:
> > > > > > > > > > > > > > config TPL_RAM
> > > > > > > > > > > > > >   bool "RAM driver in TPL"
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > in what I am proposing. That's why. There's one symbol because there's
> > > > > > > > > > > > > > the same files being built.
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK, well that works the same for my scheme too. Either will do.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't see how that can work in your scheme.
> > > > > > > > > > >
> > > > > > > > > > > Here is the full Kconfig for that file, with my scheme:
> > > > > > > > > > >
> > > > > > > > > > > >>>>
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > > > #
> > > > > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > > > > >
> > > > > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > obj-spl-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o
> > > > > > > > > > > spl_common.o
> > > > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > > > obj-tpl-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > > > obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > > > >
> > > > > > > > > > > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > > > >
> > > > > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > > >
> > > > > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > > > > # meaning "turn it off".
> > > > > > > > > > > obj-y += boot_mode.o
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > > > endif
> > > > > > > > > > >
> > > > > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > > > endif
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > > >
> > > > > > > > > > > # Clear out SPL objects, in case this is a TPL build
> > > > > > > > > > > obj-spl-$(CONFIG_TPL_BUILD) =
> > > > > > > > > > >
> > > > > > > > > > > # Now add SPL/TPL objects back into the main build
> > > > > > > > > > > obj-$(CONFIG_XPL_BUILD) += $(obj-spl-y)
> > > > > > > > > > > obj-$(CONFIG_TPL_BUILD) += $(obj-tpl-y)
> > > > > > > > > > > <<<<
> > > > > > > > > > >
> > > > > > > > > > > The only change is the line that was:
> > > > > > > > > > > obj-$(CONFIG_$(PHASE_)RAM) += sdram.o
> > > > > > > > > >
> > > > > > > > > > Yes, that's also what I showed via unified diff format earlier, and so I
> > > > > > > > > > agree.
> > > > > > > > >
> > > > > > > > > OK good.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > > > > For this one:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > +obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't understand how it can work with your scheme, since you don't
> > > > > > > > > > > > > > > want to have any CONFIG_SPL_ things?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > No, that's not what I've been saying and trying to make clear with my
> > > > > > > > > > > > > > examples. I keep saying that there are explicitly SPL (or TPL or VPL)
> > > > > > > > > > > > > > only options. And these need to be named as such. And so that's the
> > > > > > > > > > > > > > confusion your proposal introduces (inconsistency about referring to a
> > > > > > > > > > > > > > symbol that has been enabled) and mine removes entirely (we only ever
> > > > > > > > > > > > > > refer to symbols based on their name).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Right, but you still have 'config SPL_RAM', right? Would you keep
> > > > > > > > > > > >
> > > > > > > > > > > > No, again, I do not. Please re-read my proposal as you seem to keep
> > > > > > > > > > > > making the same incorrect assumptions about it, and then saying that
> > > > > > > > > > > > your scheme would also do that. They are very much not at all the same.
> > > > > > > > > > >
> > > > > > > > > > > Maybe we have reached the limits of email on this one, but I am quite
> > > > > > > > > > > confused about your scheme. I suggested that you don't have
> > > > > > > > > > > CONFIG_SPL_ things and you said tht was wrong. Then I asked if you
> > > > > > > > > > > still have SPL_RAM and you said you don't. Let me try this:
> > > > > > > > > > >
> > > > > > > > > > > Q: In your scheme, do you have 'config SPL_RAM' and CONFIG_SPL_RAM, or
> > > > > > > > > > > do you not?
> > > > > > > > > >
> > > > > > > > > > In my scheme we do not have 'config SPL_RAM' nor CONFIG_SPL_RAM as there
> > > > > > > > > > is no case where 'config RAM' and 'CONFIG_RAM' is incorrect. Because we
> > > > > > > > > > are never configuring and building for more than one phase.
> > > > > > > > > >
> > > > > > > > > > In my scheme we do have 'config SPL_ROCKCHIP_COMMON_BOARD and
> > > > > > > > > > 'CONFIG_SPL_ROCKCHIP_COMMON_BOARD' because they are NOT the same thing
> > > > > > > > > > as 'config ROCKCHIP_COMMON_BOARD' and 'CONFIG_ROCKCHIP_COMMON_BOARD'
> > > > > > > > > > (and again for TPL_...). They control different code. While technically
> > > > > > > > > > possible, I am arguing against overloading ROCKCHIP_COMMON_BOARD and
> > > > > > > > > > having the Makefile have to do some two part check like we have today,
> > > > > > > > > > as those are one of the pain points of adding new code.
> > > > > > > > >
> > > > > > > > > OK I think I have some sort of understanding now.
> > > > > > > > >
> > > > > > > > > Here is the patch that works for me (on top of your patch above). Note
> > > > > > > > > that we don't have to make those changes, but they show how my scheme
> > > > > > > > > is different in what it expects:
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > index 23c30f68f87..0593e028de4 100644
> > > > > > > > > --- a/arch/arm/mach-rockchip/Makefile
> > > > > > > > > +++ b/arch/arm/mach-rockchip/Makefile
> > > > > > > > > @@ -7,27 +7,35 @@
> > > > > > > > >  # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > >  # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > >  # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > +ifdef CONFIG_XPL_BUILD
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > +endif
> > > > > > > > > +ifdef CONFIG_SPL_BUILD
> > > > > > > > >  obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > -obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > +endif
> > > > > > > > > +ifdef CONFIG_TPL_BUILD
> > > > > > > > >  obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > +endif
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > >
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > >
> > > > > > > > > +ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > > +
> > > > > > > > >  # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > >  # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > >  # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > >  # meaning "turn it off".
> > > > > > > > >  obj-y += boot_mode.o
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > +endif
> > > > > > > > >
> > > > > > > > > +ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > >  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > +endif
> > > > > > > > >
> > > > > > > > >  obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > -ifdef CONFIG_PPL
> > > > > > > > > -# TODO: Audit these Makefiles see if they really must be PPL only
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > @@ -43,4 +51,3 @@ obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > >  obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > > -endif
> > > > > > > > > --
> > > > > > > > > 2.43.0
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Here's the full file:
> > > > > > > > >
> > > > > > > > > # SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > #
> > > > > > > > > # Copyright (c) 2014 Google, Inc
> > > > > > > > > # Copyright (c) 2019 Rockchip Electronics Co., Ltd.
> > > > > > > > >
> > > > > > > > > # We don't want the bootrom-helper present in a full U-Boot build, as
> > > > > > > > > # this may have entered from ATF with the stack-pointer pointing to
> > > > > > > > > # inaccessible/protected memory (and the bootrom-helper assumes that
> > > > > > > > > # the stack-pointer is valid before switching to the U-Boot stack).
> > > > > > > > > ifdef CONFIG_XPL_BUILD
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> > > > > > > > > endif
> > > > > > > > > ifdef CONFIG_SPL_BUILD
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > endif
> > > > > > > > > ifdef CONFIG_TPL_BUILD
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > > endif
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> > > > > > > > >
> > > > > > > > > ifeq ($(CONFIG_XPL_BUILD)$(CONFIG_TPL_BUILD),)
> > > > > > > > >
> > > > > > > > > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > > > > > > > > # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
> > > > > > > > > # we can have the preprocessor correctly recognise both 0x0 and 0
> > > > > > > > > # meaning "turn it off".
> > > > > > > > > obj-y += boot_mode.o
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > ifeq ($(CONFIG_TPL_BUILD),)
> > > > > > > > > obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_RAM) += sdram.o
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_PX30) += px30/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3066) += rk3066/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3128) += rk3128/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3308) += rk3308/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
> > > > > > > > >
> > > > > > > > > So we need CONFIG_SPL_BUILD when using a
> > > > > > > > > CONFIG_SPL_ROCKCHIP_COMMON_BOARD option which I agree looks strange.
> > > > > > > > >
> > > > > > > > > We can't do this with my scheme:
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > >
> > > > > > > > You can't do that with any scheme, to be clear. I don't know why you're
> > > > > > > > mentioning it.
> > > > > > >
> > > > > > > Just so we have a baseline.
> > > > > > >
> > > > > > > >
> > > > > > > > > since that will compile both targets into whatever phases are enabled.
> > > > > > > > >
> > > > > > > > > To me, the ifdef I have above is less confusing than that, but I would
> > > > > > > > > actually prefer this:
> > > > > > > > >
> > > > > > > > > ifdef CONFIG_ROCKCHIP_COMMON_BOARD
> > > > > > > > > obj-$(CONFIG_SPL_BUILD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > obj-$(CONFIG_TPL_BUILD) += tpl.o spl_common.o
> > > > > > > > > endif
> > > > > > > >
> > > > > > > > That would be less bad than what you've had earlier, yes. But I think
> > > > > > > > mine is still clearer.
> > > > > > >
> > > > > > > Sure.
> > > > > > >
> > > > > > > >
> > > > > > > > > Anyway, this is a strange case and I don't think it is a huge deal. In
> > > > > > > >
> > > > > > > > Yes, but it's not the only case like this, it's just the first one that
> > > > > > > > came to mind.
> > > > > > >
> > > > > > > I've not seen that sort of construct (spl-xxx += ...) in U-Boot
> > > > > > > before, so I don't think it is common. I am sure there are others, but
> > > > > > > my scheme does work with existing Makefiles.
> > > > > >
> > > > > > It's one of many examples of the workarounds needed for "do we want this
> > > > > > object in all phases or just some phases".
> > > > >
> > > > > You're being too negative IMO. Most of the time the right thing
> > > > > happens. Yes there are corner cases but I believe you are
> > > > > mischaracterising my scheme.
> > > >
> > > > It's the problem with the way things work today, not just your scheme.
> > > > It's also one of the not infrequent pain points for what we have today
> > > > for including / excluding something from a given phase.
> > > >
> > > > > > > > > general, when you enable an option for some phases you get that code
> > > > > > > > > in those phases. When you actually *don't* want the code in a
> > > > > > > > > particular phase, either don't set the option, or add another
> > > > > > > > > condition.
> > > > > > > >
> > > > > > > > And your proposal doesn't solve that problem, still. Go back up in the
> > > > > > > > thread and see the DWC3 example I wanted to see if was still broken, and
> > > > > > > > is still broken.
> > > > > > >
> > > > > > > What is broken about it? Are you using the old series? I don't see any
> > > > > > > changes to the Makefile there in my new series.
> > > > > >
> > > > > > I summarized things in the email there. And yes, your series does not
> > > > > > address and seemingly makes even worse, the problem of
> > > > > > including/excluding DWC3 from different phases.
> > > > >
> > > > > But I really don't know what is wrong with DWC3, honest! When I build
> > > > > pinebook-pro-rk3399 I don't actually see any drivers/usb in SPL,
> > > > > neither before or after my series. So can you please explain in a bit
> > > > > more detail what you are getting at? The latest version is at splg4 in
> > > > > my tree, although it's not finished.
> > > >
> > > > One of the first steps described in the problem statement is enabling
> > > > USB gadget for SPL only. This then blows up due to how we have / haven't
> > > > done workarounds for *USB_DWC3* symbols in Kconfig and also Makefile
> > > > logic.
> > > >
> > > > > > > > > After all, the current Makefile code is actually a bit of a
> > > > > > > > > workaround. Any scheme is going to have drawbacks.
> > > > > > > >
> > > > > > > > Yes, there's lots of workarounds. My scheme removes all of those
> > > > > > > > workarounds once complete. What phase is being configured and built is a
> > > > > > > > strict "pick 1 from N" and so we do not have CONFIG_SPL_BUILD,
> > > > > > > > CONFIG_TPL_BUILD, CONFIG_XPL_BUILD, etc.
> > > > > > >
> > > > > > > Yes, I think that's right. For the most part my scheme will do the
> > > > > > > same, but there will be exceptions, like the rockchip one.
> > > > > >
> > > > > > If you're referring to arch/arm/mach-rockchip/Makefile that could be
> > > > > > rewritten, today, to be a little less cumbersome. It is still an example
> > > > > > of the tricky workarounds that are needed for including/excluding
> > > > > > objects based on phases, and is another example of how your series would
> > > > > > not make adding a new phase easier.
> > > > >
> > > > > It makes it easier because you don't have to add loads of plumbing to
> > > > > get a new phase. Also, with Kconfig changes, adding a phase could
> > > > > become just a Kconfig thing, with everything else downstream of that,
> > > > > There would be no need to add completely new Kconfig symbols for every
> > > > > feature.
> > > >
> > > > I guess this is what you've put up in "splg4" now? I'll refrain from
> > > > commenting until I've had a chance to see what you've done here.
> > > >
> > > > > > > > > With my scheme, I want to have the options for all phases in each
> > > > > > > > > autoconf_xpl.h so that you can check an option for one phase in
> > > > > > > > > another. That is part of my intent to (as now) have a single Kconfig
> > > > > > > > > which covers every option in every phase. The down-side of that is
> > > > > > > > > that you have to be aware of it.
> > > > > > > >
> > > > > > > > Yes, and we're going to violate a whole lot of  "least surprise" rules
> > > > > > > > by changing how something we've borrowed from a much larger and more
> > > > > > > > popular project works (and also how other projects which borrow it
> > > > > > > > work).
> > > > > > >
> > > > > > > I don't agree with that. Linux only builds a single build. We are
> > > > > > > always going to have to do more here than Linux. Also Linux has no
> > > > > > > interest in taking our Kbuild patches and incidentally, held out
> > > > > > > against FIT for 10 years! Linux will do what it wants to do. This is
> > > > > > > U-Boot.
> > > > > >
> > > > > > Again, I am proposing we only do a single build.
> > > > > >
> > > > > > And yes, this is U-Boot where one of our key attractions is "It's just
> > > > > > like working in the Linux Kernel, which you're likely already familiar
> > > > > > with". So "Ah, but CONFIG_FOO doesn't mean CONFIG_FOO!" will violate
> > > > > > that, badly.
> > > > >
> > > > > It means CONFIG_FOO for the phase being built, the same as your
> > > > > scheme. From that POV all we are really talking about is the style of
> > > > > plumbing.
> > > > >
> > > > > If I could think of a way to express things differently in Kconfig, I
> > > > > would do that. I did suggest at the start some possible extensions,
> > > > > but you don't want those either.
> > > >
> > > > Yes, I suggested language extensions to reduce the symbol increase of
> > > > "splc-working". I need to look at "splg4" now as that's apparently
> > > > entirely different before making assumptions and commenting further.
> > > >
> > > > > > > > > This did get me thinking though, whether with my scheme we could
> > > > > > > > > (later) change Kconfig so that there is an SPL symbol, which is only
> > > > > > > > > true when building SPL. Basically we would change the existing SPL to
> > > > > > > > > HAVE_SPL, and SPL_BUILD to SPL. But we could put the 'new' SPL into
> > > > > > > > > Kconfig, so you can depend on it, etc. Lots of options have 'depends
> > > > > > > > > on SPL' which would mean 'depends on HAVE_SPL', but we could just
> > > > > > > > > leave them as they are.
> > > > > > > > >
> > > > > > > > > So then you could use
> > > > > > > > >
> > > > > > > > > config SPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > >     depends on SPL
> > > > > > > > >
> > > > > > > > > config TPL_ROCKCHIP_COMMON_BOARD
> > > > > > > > >     depends on TPL
> > > > > > > > >
> > > > > > > > > and this would work:
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_SPL_ROCKCHIP_COMMON_BOARD) += spl.o spl-boot-order.o spl_common.o
> > > > > > > > > obj-$(CONFIG_TPL_ROCKCHIP_COMMON_BOARD) += tpl.o spl_common.o
> > > > > > > > >
> > > > > > > > > But there is a down-side. Because SPL_ROCKCHIP_COMMON_BOARD is not
> > > > > > > > > enabled in the TPL build, TPL will not have visibility into that
> > > > > > > > > option. We have effectively moved closer to your scheme: still with a
> > > > > > > > > unified Kconfig, but completely split in the source code. Still, we
> > > > > > > > > can control that, by having (for example) SPL_TEXT_BASE depend on the
> > > > > > > > > new HAVE_SPL instead of SPL. That way, CONFIG_SPL_TEXT_BASE it will
> > > > > > > > > appear in all builds.
> > > > > > > >
> > > > > > > > Yes, that sounds like it will make some of the existing complex logic
> > > > > > > > even more complex, and I'm not sure of the benefit.
> > > > > > >
> > > > > > > Trying to split the difference between our schemes. I'm going to call
> > > > > > > this 'option A' for my scheme.
> > > > > > >
> > > > > > > >
> > > > > > > > > We also have to run the 'conf' tool multiple times.
> > > > > > > >
> > > > > > > > And to be clear, with my scheme that's a requirement since we're only
> > > > > > > > building and configuring a single phase. The files I've described with
> > > > > > > > "PHASE:XPL:file" are a nice-to-have on top bit, and not required
> > > > > > > > especially if it leads to confusion while discussing things.
> > > > > > >
> > > > > > > Yes, understood.
> > > > > > >
> > > > > > > Basically I think both schemes work. At present I think we should go
> > > > > > > with my scheme now, since it is pretty close to being complete and
> > > > > > > involves minimal change to the existing Kconfig, then either do option
> > > > > > > A, or decide to split the Kconfig completely, i.e. your scheme. It
> > > > > > > seems that you believe my scheme is worse than the status quo, though,
> > > > > > > right?
> > > > > >
> > > > > > I think we need to come up with some way to get the community to vote on
> > > > > > your scheme or status quo. I don't think your scheme is "pretty close"
> > > > > > to being complete and I think it will make things worse than doing
> > > > > > nothing. I was hoping to get you to think about implementing what I
> > > > > > proposed instead, but since I still don't think you've understood it,
> > > > > > that's not an option either.
> > > > >
> > > > > I just don't like splitting the defconfig into completely different
> > > > > files. I know that will open up all sorts of issues. For example, how
> > > > > will this code work?:
> > > > >
> > > > > ulong spl_get_image_text_base(void)
> > > > > {
> > > > > #ifdef CONFIG_VPL
> > > > >    if (xpl_next_phase() == PHASE_VPL)
> > > > >       return CONFIG_VPL_TEXT_BASE;
> > > > > #endif
> > > > >    return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
> > > > >       CONFIG_TEXT_BASE;
> > > > > }
> > > >
> > > > Well, we start by asking why the FIT image being loaded isn't populated
> > > > with the load address being valid. And then is anyone still using
> > > > u-boot.bin and not u-boot.img and could we not just tidy away the whole
> > > > function?
> > >
> > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > you imagine we could retire the legacy image?
> >
> > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > stuck on reworking efi bootmanager integration, and LED is waiting for
> > someone to confirm that really, finally, we have all of the old use
> > cases supported in the new code.
> >
> > But more importantly, do we really have anyone not using u-boot.img? I
> > don't know.
> 
> If we did one of these sorts of things at a time, we would only get
> 2-3 things done each year!

A project with 4 yearly releases finishing two 2-3 big changes a year
sounds great to me. Rather than not finishing a dozen things?

> > > > But then if yes we need that function, we would do:
> > > >
> > > > config PPL_TEXT_BASE
> > > >         hex "Static load address for full U-Boot, formerly TEXT_BASE"
> > > >         depends on PPL || SPL
> > > >         ... current default 0xABC if BAR list for TEXT_BASE
> > > >
> > > > config TPL_TEXT_BASE
> > > >         hex "Static load address for TPL phase of U-Boot"
> > > >         depends on TPL
> > > >         ... default 0xABC if BAR list
> > > >
> > > > config VPL_TEXT_BASE
> > > >         hex "Static load address for VPL phase of U-Boot"
> > > >         depends on (TPL && SUPPORTS_VPL) || VPL
> > > >         ... default 0xABC if BAR list
> > > >
> > > > config SPL_TEXT_BASE
> > > >         hex "Static load address for SPL phase of U-Boot"
> > > >         depends on ((TPL || VPL) && SUPPORTS_SPL) || SPL
> > > >         ... current set of default 0xABC if BAR list
> > > >
> > > > ulong spl_get_image_text_base(void)
> > > > {
> > > > #if defined(CONFIG_TPL) && defined(CONFIG_SUPPORTS_VPL)
> > > >         return CONFIG_VPL_TEXT_BASE;
> > > > #elif (defined(CONFIG_TPL) || defined(CONFIG_VPL)) && \
> > > >                 defined(CONFIG_SUPPORTS_SPL)
> > > >         return CONFIG_SPL_TEXT_BASE;
> > > > #else
> > > >         return CONFIG_PPL_TEXT_BASE;
> > > > #endif
> > > > }
> > > >
> > > > And I assume one of your objections to the above is that we've removed
> > > > the macro functions that evaluate to 0 and let the optimizer discard
> > > > things (except for CC_OPTIMIZE_FOR_DEBUG related problems). But I also
> > > > see clever macros like that as a hindrance to understanding the code.
> > >
> > > Actually, my objection is that it is very confusing. Mixing TPL and
> > > VPL and SPL. We have to do this for every symbol that depends on or
> > > uses a default from another phase??
> >
> > It shouldn't be confusing. It's less confusing than the current example
> > because it doesn't rely on inline macros and test ? true : false inline
> > "if" statements.
> >
> > That said, it's also in the minority of symbols where we need some
> > *value* that we only indirectly use *and* it's not just the same value
> > and so only exists as one question at all. But finally, I was eliding
> > the default ... part there because none of these should be in a
> > defconfig and they should come from the Kconfig having the correct
> > default value. I would be strongly tempted to remove the prompt portion
> > of the entry if I could make sure the resulting failure was obvious.
> 
> It's confusing because we have to update one phase to make a copy of
> the symbol from another phase and then keep them in sync.

The implication that these are values that should be changed and need to
therefore be kept in sync is wrong. And getting these to all be under
default X if Y will make the times when they have been and need to be
again, slightly tweaked for an SoC easier, not harder.

> 
> The current code is much more obvious:
> 
> ulong spl_get_image_text_base(void)
> {
> #ifdef CONFIG_VPL
>         if (xpl_next_phase() == PHASE_VPL)
>                 return CONFIG_VPL_TEXT_BASE;
> #endif
>         return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
>                 CONFIG_TEXT_BASE;
> }
> 
> and with splg, also obvious:
> 
> ulong spl_get_image_text_base(void)
> {
> #ifdef CONFIG_VPL
>         if (xpl_next_phase() == PHASE_VPL)
>                 return CONFIG_VPL_TEXT_BASE;
> #endif
>         return xpl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
>                 CONFIG_PPL_TEXT_BASE;
> }

I find your functions here unclear and confusing because we are not
ever really making some run-time decision. All of the above should be
optimized at compile time down to "return static value". It's implying
there's something more at work here than there is. Getting perhaps too
deep in to the weeds, it should be an inline function, even. But I'm not
sure if the compiler will be smart enough with the way it's constructed
here, but would be with mine.

> and I suspect we could avoid #ifdef with a bit of thought.

Possibly if CONFIG_VAL() handles undefined things right, otherwise we
risk more cases of "default 0x0" in order to make compile time C checks
work when compile time cpp checks would have already worked without a
potentially incorrect default being used.

> > > > We
> > > > would also change xpl_phase() to:
> > > > static inline enum xpl_phase_t xpl_phase(void)
> > > > {
> > > > #ifdef CONFIG_TPL
> > > >         return PHASE_TPL;
> > > > #elif defined(CONFIG_VPL)
> > > >         return PHASE_VPL;
> > > > #elif defined(CONFIG_SPL)
> > > >         return PHASE_SPL;
> > > > #else
> > > >         DECLARE_GLOBAL_DATA_PTR;
> > > >
> > > >         if (!(gd->flags & GD_FLG_RELOC))
> > > >                 return PHASE_BOARD_F;
> > > >         else
> > > >                 return PHASE_BOARD_R;
> > > > #endif
> > > > }
> > > >
> > > > But could not use it above because we will not globally have *TEXT_BASE
> > > > defined. And I don't worry about keeping these in sync between different
> > > > defconfig files as they are SoC dependent features. And maybe it's a
> > > > sign that my notion that we should have these defaults in the main
> > > > symbol, rather than arch/... various subdirs .../Kconfig was wrong and
> > > > has discouraged setting appropriate defaults. Because in this specific
> > > > example, FPGA-fun aside, it's not very arbitrary as to what address
> > > > space where is available to use when. Well Known Defaults should be
> > > > provided.
> > >
> > > I'm not sure, but yes, perhaps arch/ or even board/ is a better place.
> > >
> > > >
> > > > > > But imagine you aren't interested in
> > > > > > hearing No and not doing it, again.
> > > > >
> > > > > Not particularly, but I could just do nothing on this.
> > > >
> > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > look at it, and refrain from otherwise assuming how it solves the
> > > > problems I had seen previously.
> > >
> > > I pushed an updated version to dm/splg-working but it is not very
> > > updated. Still needs more work.
> >
> > Thanks.
> 
> [joining threads, sorry about sending out of turn]
> >
> >
> > > >
> > > > Actually, my objection is that it is very confusing. Mixing TPL and
> > > > VPL and SPL. We have to do this for every symbol that depends on or
> > > > uses a default from another phase??
> > >
> > > The other problem is that we have to keep these special symbols in
> > > sync manually. Or are you proposing some tools that will check that
> > > they match when the build is done?
> > >
> > > I went through one file and half of another and found these which rely
> > > on some PPL value:
> > >
> > > SPL_SILENT_CONSOLE
> > > SPL_LOG
> > > SPL_LOGLEVEL
> > > SPL_BLOBLIST
> > > SPL_ACPI
> > > SPL_CRC32
> > > SPL_SHA256
> > > SPL_SHA512
> > >
> > > It seems like we would have to do a lot of tedious and error-prone
> > > work to update things, but then we end up with something (in terms of
> > > configuration) less powerful and controllable than we have today?
> 
> > None of those symbols would exist with what I'm proposing, so their
> > normal default is fine.
> 
> Doesn't that mean that (before your scheme can land) you have to go
> through all the Kconfig to remove 90% of the SPL/TPL/VPL symbols from
> Kconfig?
> 
> I'm not sure if this is accurate, but it gives an idea, just for this point:
> 
> $ grep -A4 "config SPL_" `find . -name "Kconfig*"` |grep -P 'depends
> on (?!SPL_)' |wc -l
> 229

Before it can land? Maybe? Maybe not? Depends on how the switchover is
done. But yes, the point I keep trying to make is that most of the work
is in updating dependencies and removing existing symbols. So yes, we
would remove nearly all SPL, TPL and VPL symbols as they duplicate
without functional difference. CONFIG_SPL_LOG and CONFIG_LOG just
control the same logging functionality. Things like
CONFIG_SPL_ROCKCHIP_COMMON_BOARD are the exception, not the rule.

> I'm really very concerned about splitting the Kconfig entirely right
> off the bat. I believe for a first step, we need to keep a 'whole'
> Kconfig and allow phases to access each others options. In other
> words, do the minimum we can to split the config and deal with the
> fallout from that, then plan the next move.
> 
> Nothing in my scheme precludes splitting the config earlier. I do note
> your serious concerns about confusion in Makefiles but in general it
> will simplify the Makefiles and I don't see it as confusing as you do.
> 
> I don't think I have convinced you that my scheme is a step towards
> yours, though? You are so worried about one type of confusion that you
> don't even want to go there?

I still think you don't understand what I'm proposing. So, on top of the
current splg-working, the following is valid (and needed for consistency
with other changes you made to Makefiles), right?
commit 9ba0be66daaf786895bc8672ee9c43856ac29c78
Author: Tom Rini <trini@konsulko.com>
Date:   Fri Feb 21 11:26:19 2025 -0600

    CONFIG_SPL_LIBCOMMON_SUPPORT -> CONFIG_LIBCOMMON_SUPPORT
    
    Signed-off-by: Tom Rini <trini@konsulko.com>

diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-davinci/spl.c
index 8c6cf9c21925..5f9b04ff8489 100644
--- a/arch/arm/mach-davinci/spl.c
+++ b/arch/arm/mach-davinci/spl.c
@@ -15,7 +15,7 @@
 #include <spi_flash.h>
 #include <mmc.h>
 
-#ifndef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifndef CONFIG_LIBCOMMON_SUPPORT
 void puts(const char *str)
 {
 	while (*str)
@@ -29,7 +29,7 @@ void putc(char c)
 
 	ns16550_putc((struct ns16550 *)(CFG_SYS_NS16550_COM1), c);
 }
-#endif /* CONFIG_SPL_LIBCOMMON_SUPPORT */
+#endif /* CONFIG_LIBCOMMON_SUPPORT */
 
 void board_init_f(ulong dummy)
 {
diff --git a/boot/common_fit.c b/boot/common_fit.c
index a2f9b8d83c3b..507be98055b2 100644
--- a/boot/common_fit.c
+++ b/boot/common_fit.c
@@ -53,7 +53,7 @@ int fit_find_config_node(const void *fdt)
 	     node = fdt_next_subnode(fdt, node)) {
 		name = fdt_getprop(fdt, node, "description", &len);
 		if (!name) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 			printf("%s: Missing FDT description in DTB\n",
 			       __func__);
 #endif
diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
index 6dee03122bb7..997506041e38 100644
--- a/common/spl/spl_ext.c
+++ b/common/spl/spl_ext.c
@@ -39,7 +39,7 @@ int spl_load_image_ext(struct spl_image_info *spl_image,
 
 	err = ext4fs_mount();
 	if (!err) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 		printf("%s: ext4fs mount err - %d\n", __func__, err);
 #endif
 		return -1;
@@ -55,7 +55,7 @@ int spl_load_image_ext(struct spl_image_info *spl_image,
 	err = spl_load(spl_image, bootdev, &load, filelen, 0);
 
 end:
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 	if (err < 0)
 		printf("%s: error reading image %s, err - %d\n",
 		       __func__, filename, err);
@@ -83,7 +83,7 @@ int spl_load_image_ext_os(struct spl_image_info *spl_image,
 
 	err = ext4fs_mount();
 	if (!err) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 		printf("%s: ext4fs mount err - %d\n", __func__, err);
 #endif
 		return -1;
@@ -128,7 +128,7 @@ defaults:
 
 	err = ext4fs_read((void *)CONFIG_SPL_PAYLOAD_ARGS_ADDR, 0, filelen, &actlen);
 	if (err < 0) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 		printf("%s: error reading image %s, err - %d\n",
 		       __func__, CONFIG_SPL_FS_LOAD_ARGS_NAME, err);
 #endif
diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
index b6a3b9b21553..23ed87ba0f8d 100644
--- a/common/spl/spl_fat.c
+++ b/common/spl/spl_fat.c
@@ -33,7 +33,7 @@ static int spl_register_fat_device(struct blk_desc *block_dev, int partition)
 
 	err = fat_register_device(block_dev, partition);
 	if (err) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 		printf("%s: fat register err - %d\n", __func__, err);
 #endif
 		return err;
@@ -90,7 +90,7 @@ int spl_load_image_fat(struct spl_image_info *spl_image,
 	err = spl_load(spl_image, bootdev, &load, size, 0);
 
 end:
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 	if (err < 0)
 		printf("%s: error reading image %s, err - %d\n",
 		       __func__, filename, err);
@@ -141,7 +141,7 @@ defaults:
 	err = file_fat_read(CONFIG_SPL_FS_LOAD_ARGS_NAME,
 			    (void *)CONFIG_SPL_PAYLOAD_ARGS_ADDR, 0);
 	if (err <= 0) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 		printf("%s: error reading image %s, err - %d\n",
 		       __func__, CONFIG_SPL_FS_LOAD_ARGS_NAME, err);
 #endif
diff --git a/common/spl/spl_usb.c b/common/spl/spl_usb.c
index bf0d57678e78..0aab2e4e4936 100644
--- a/common/spl/spl_usb.c
+++ b/common/spl/spl_usb.c
@@ -31,7 +31,7 @@ int spl_usb_load(struct spl_image_info *spl_image,
 	}
 
 	if (err) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_LIBCOMMON_SUPPORT
 		printf("%s: usb init failed: err - %d\n", __func__, err);
 #endif
 		return err;
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 83168b46cc53..dca88730a4c5 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -301,7 +301,7 @@ struct mmc *find_mmc_device(int dev_num)
 	ret = blk_find_device(UCLASS_MMC, dev_num, &dev);
 
 	if (ret) {
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 		printf("MMC Device %d not found\n", dev_num);
 #endif
 		return NULL;
@@ -373,7 +373,7 @@ void mmc_do_preinit(void)
 	}
 }
 
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 void print_mmc_devices(char separator)
 {
 	struct udevice *dev;
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 14c62f63c822..16806ea92fba 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -328,7 +328,7 @@ int mmc_poll_for_busy(struct mmc *mmc, int timeout_ms)
 			break;
 
 		if (status & MMC_STATUS_MASK) {
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 			log_err("Status Error: %#08x\n", status);
 #endif
 			return -ECOMM;
@@ -341,7 +341,7 @@ int mmc_poll_for_busy(struct mmc *mmc, int timeout_ms)
 	}
 
 	if (timeout_ms <= 0) {
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 		log_err("Timeout waiting card ready\n");
 #endif
 		return -ETIMEDOUT;
@@ -483,7 +483,7 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst, lbaint_t start,
 
 	if (blkcnt > 1) {
 		if (mmc_send_stop_transmission(mmc, false)) {
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 			log_err("mmc fail to send stop cmd\n");
 #endif
 			return 0;
@@ -534,7 +534,7 @@ ulong mmc_bread(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt,
 		return 0;
 
 	if ((start + blkcnt) > block_dev->lba) {
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 		log_err("MMC: block number 0x" LBAF " exceeds max(0x" LBAF ")\n",
 			start + blkcnt, block_dev->lba);
 #endif
@@ -2724,7 +2724,7 @@ static int mmc_startup(struct mmc *mmc)
 	bdesc->log2blksz = LOG2(bdesc->blksz);
 	bdesc->lba = lldiv(mmc->capacity, mmc->read_bl_len);
 #if !defined(CONFIG_XPL_BUILD) || \
-		(defined(CONFIG_SPL_LIBCOMMON_SUPPORT) && \
+		(defined(CONFIG_LIBCOMMON_SUPPORT) && \
 		!IS_ENABLED(CONFIG_USE_TINY_PRINTF))
 	sprintf(bdesc->vendor, "Man %06x Snr %04x%04x",
 		mmc->cid[0] >> 24, (mmc->cid[2] & 0xffff),
@@ -2953,7 +2953,7 @@ retry:
 		err = mmc_send_op_cond(mmc);
 
 		if (err) {
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 			if (!quiet)
 				log_err("Card did not respond to voltage select! : %d\n",
 					err);
@@ -3008,7 +3008,7 @@ int mmc_start_init(struct mmc *mmc)
 #endif
 	if (no_card) {
 		mmc->has_init = 0;
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 		log_err("MMC: no card present\n");
 #endif
 		return -ENOMEDIUM;
diff --git a/drivers/mmc/mmc_legacy.c b/drivers/mmc/mmc_legacy.c
index 0ac092fad105..21d659e4c49d 100644
--- a/drivers/mmc/mmc_legacy.c
+++ b/drivers/mmc/mmc_legacy.c
@@ -44,7 +44,7 @@ struct mmc *find_mmc_device(int dev_num)
 			return m;
 	}
 
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 	printf("MMC Device %d not found\n", dev_num);
 #endif
 
@@ -93,7 +93,7 @@ void mmc_list_add(struct mmc *mmc)
 	list_add_tail(&mmc->link, &mmc_devices);
 }
 
-#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+#if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_LIBCOMMON_SUPPORT)
 void print_mmc_devices(char separator)
 {
 	struct mmc *m;

This is the kind of confusion I strongly object to because you have and
would not be removing:
common/spl/Kconfig:config SPL_LIBCOMMON_SUPPORT
common/spl/Kconfig-	bool "Support common libraries"
--
common/spl/Kconfig.tpl:config TPL_LIBCOMMON_SUPPORT
common/spl/Kconfig.tpl-	bool "Support common libraries"
--
common/spl/Kconfig.vpl:config VPL_LIBCOMMON_SUPPORT
common/spl/Kconfig.vpl-	bool "Support common libraries"

Despite these being all of the non-config that "LIBCOMMON_SUPPORT" touches:
arch/arm/mach-davinci/spl.c
arch/arm/mach-rockchip/bootrom.c
boot/common_fit.c
common/spl/spl_ext.c
common/spl/spl_fat.c
common/spl/spl_usb.c
drivers/mmc/mmc-uclass.c
drivers/mmc/mmc.c
drivers/mmc/mmc_legacy.c
include/spl.h
lib/hang.c

And the entire reason for four symbols and $(PHASE_)LIBCOMMON_SUPPORT is
to include the same thing in yet another phase, unchanged.

In my proposal we would tidy this up to either a single:
config XPL_LIBCOMMON_SUPPORT
  bool "Support common libraries in xPL phases"
  depends on !PPL # Not valid in full U-Boot

Because we can and should use the XPL namespace for items that are
common to all of the not-PPL builds but are identical within any other
phase.

Or tidy it up to a single:
config LIBCOMMON_SUPPORT
  bool "Support common libraries in xPL phases"
  depends on !PPL # Not valid in full U-Boot

Because using the XPL namespace is too confusing inside the CONFIG
namespace.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Rate of change in the project (Was: Re: xPL Proposal)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > Hi Tom,
[snip]
> > If we did one of these sorts of things at a time, we would only get
> > 2-3 things done each year!
> 
> A project with 4 yearly releases finishing two 2-3 big changes a year
> sounds great to me. Rather than not finishing a dozen things?

As this is a huge thread already, I'm splitting this part out.

I would seriously frame slowing down and having just one big change
being in progress at a time, until it's done, as a good thing, not a bad
thing. We're a small community with limited bandwidth.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of change in the project (Was: Re: xPL Proposal)

[Simon Glass]

Hi Tom,

(I think you chopped off too much context, so I've added it below)

On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > Hi Tom,
> [snip]

[unsnip]
> > > > >
> > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > you imagine we could retire the legacy image?
> > > >
> > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > someone to confirm that really, finally, we have all of the old use
> > > > cases supported in the new code.
> > > >
> > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > don't know.
[unsnip end]

> > > If we did one of these sorts of things at a time, we would only get
> > > 2-3 things done each year!
> >
> > A project with 4 yearly releases finishing two 2-3 big changes a year
> > sounds great to me. Rather than not finishing a dozen things?
>
> As this is a huge thread already, I'm splitting this part out.
>
> I would seriously frame slowing down and having just one big change
> being in progress at a time, until it's done, as a good thing, not a bad
> thing. We're a small community with limited bandwidth.

I can't see how that would work.

I just looked at LED[1] originally sent almost 5 months ago and the
latest version is marked 'changes requested'. I don't know of any
changes I can make. Are you hoping that [sorry forgot who it was] will
get around to digging the only affected device out of his drawer and
try to get the activity-LED going? It might take a while.

The sunxi one[2] was sent over 6 months ago and the latest version is
also marked 'changes requested'. You could apply that series with
either the bootmgr revert or the patch that drops bootmgr for sunxi.
Then Heinrich can come along with his patch on top of that.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=431000&state=*
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=432628&state=*

Re: Rate of change in the project (Was: Re: xPL Proposal)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]

On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> (I think you chopped off too much context, so I've added it below)

That's fine. But I omitted it because it's also true for any other DM
migration, and bootstd more fully and adding more classes of devices for
bootmeths and I honestly think you have a half dozen big things that are
in various states of being merged and enabled and perhaps even more that
didn't get much past sandbox being enabled.

> 
> On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > [snip]
> 
> [unsnip]
> > > > > >
> > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > you imagine we could retire the legacy image?
> > > > >
> > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > someone to confirm that really, finally, we have all of the old use
> > > > > cases supported in the new code.
> > > > >
> > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > don't know.
> [unsnip end]
> 
> > > > If we did one of these sorts of things at a time, we would only get
> > > > 2-3 things done each year!
> > >
> > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > sounds great to me. Rather than not finishing a dozen things?
> >
> > As this is a huge thread already, I'm splitting this part out.
> >
> > I would seriously frame slowing down and having just one big change
> > being in progress at a time, until it's done, as a good thing, not a bad
> > thing. We're a small community with limited bandwidth.
> 
> I can't see how that would work.

Well, what we have today is clearly not working well enough for you. And
"just land my changes" is still not an option for mainline.

> I just looked at LED[1] originally sent almost 5 months ago and the
> latest version is marked 'changes requested'. I don't know of any
> changes I can make. Are you hoping that [sorry forgot who it was] will
> get around to digging the only affected device out of his drawer and
> try to get the activity-LED going? It might take a while.

Yes, and as a reminder it's only been 6 or 7 months since mainline had
all of the required functionality, maybe. And what *you* could do to
speed things along is implement the functionality on any of the boards
at your disposal. Anything with a LED today would be fine for this.

> The sunxi one[2] was sent over 6 months ago and the latest version is
> also marked 'changes requested'. You could apply that series with
> either the bootmgr revert or the patch that drops bootmgr for sunxi.
> Then Heinrich can come along with his patch on top of that.

The sunxi one is blocked because it needs to be rebased on top of the
fix I did for BLK stuff and then yes you also could have done the
"bootstd uses bootmanager" idea that you've both agreed is a step in the
right direction. Because it's actually a generic issue with bootmgr +
bootstd that only became more evident as more platforms moved
towards using it. Which is why I had spent so much time trying to get
you to migrate more SoCs to bootstd because it's your feature.

So yes, I think things would be in a better place if we tried to get
*less* big things done at once and didn't pick up another big thing
until the last was really done.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

(I changed the subject as 'change' sounds like change for change's sake)

On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > (I think you chopped off too much context, so I've added it below)
>
> That's fine. But I omitted it because it's also true for any other DM
> migration, and bootstd more fully and adding more classes of devices for
> bootmeths and I honestly think you have a half dozen big things that are
> in various states of being merged and enabled and perhaps even more that
> didn't get much past sandbox being enabled.

Yes I often have new ideas and start things.

>
> >
> > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > [snip]
> >
> > [unsnip]
> > > > > > >
> > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > > you imagine we could retire the legacy image?
> > > > > >
> > > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > > someone to confirm that really, finally, we have all of the old use
> > > > > > cases supported in the new code.
> > > > > >
> > > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > > don't know.
> > [unsnip end]
> >
> > > > > If we did one of these sorts of things at a time, we would only get
> > > > > 2-3 things done each year!
> > > >
> > > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > > sounds great to me. Rather than not finishing a dozen things?
> > >
> > > As this is a huge thread already, I'm splitting this part out.
> > >
> > > I would seriously frame slowing down and having just one big change
> > > being in progress at a time, until it's done, as a good thing, not a bad
> > > thing. We're a small community with limited bandwidth.
> >
> > I can't see how that would work.
>
> Well, what we have today is clearly not working well enough for you. And
> "just land my changes" is still not an option for mainline.

You really haven't addressed my point here.

>
> > I just looked at LED[1] originally sent almost 5 months ago and the
> > latest version is marked 'changes requested'. I don't know of any
> > changes I can make. Are you hoping that [sorry forgot who it was] will
> > get around to digging the only affected device out of his drawer and
> > try to get the activity-LED going? It might take a while.
>
> Yes, and as a reminder it's only been 6 or 7 months since mainline had
> all of the required functionality, maybe. And what *you* could do to
> speed things along is implement the functionality on any of the boards
> at your disposal. Anything with a LED today would be fine for this.

Oh well. I would have thought that Christian's series was enough there?

>
> > The sunxi one[2] was sent over 6 months ago and the latest version is
> > also marked 'changes requested'. You could apply that series with
> > either the bootmgr revert or the patch that drops bootmgr for sunxi.
> > Then Heinrich can come along with his patch on top of that.
>
> The sunxi one is blocked because it needs to be rebased on top of the
> fix I did for BLK stuff and then yes you also could have done the
> "bootstd uses bootmanager" idea that you've both agreed is a step in the
> right direction. Because it's actually a generic issue with bootmgr +
> bootstd that only became more evident as more platforms moved
> towards using it.

So can you clearly explain what is blocking sunxi? Does it just need a
rebase? Which patches should be included and which not? Also we
normally expect patches sent first to have priority. Here you have
apparently applied your BLK stuff and then want me to rework on top of
it?

I agreed to the bootmanager work-around but I'm certainly not going to
write it. I would rather make bootmgr more iterative, if that is
possible.

> Which is why I had spent so much time trying to get
> you to migrate more SoCs to bootstd because it's your feature.

So take the sunxi patches and then I'll do the next one? On the one
hand you complain that there are too many balls in the air and on the
other you stop the balls from landing. It just doesn't 'compute' for
me, sorry.

>
> So yes, I think things would be in a better place if we tried to get
> *less* big things done at once and didn't pick up another big thing
> until the last was really done.

You should address my point above. Are you trying to limit me to 3-4
large series a year?

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6934 bytes --]

On Tue, Mar 04, 2025 at 06:13:36AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> (I changed the subject as 'change' sounds like change for change's sake)

Frankly, you have a lot of "tidy up" patches where nothing was
functionally wrong.

> On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > (I think you chopped off too much context, so I've added it below)
> >
> > That's fine. But I omitted it because it's also true for any other DM
> > migration, and bootstd more fully and adding more classes of devices for
> > bootmeths and I honestly think you have a half dozen big things that are
> > in various states of being merged and enabled and perhaps even more that
> > didn't get much past sandbox being enabled.
> 
> Yes I often have new ideas and start things.

And my point is they need to be finished.

> > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > [snip]
> > >
> > > [unsnip]
> > > > > > > >
> > > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > > > you imagine we could retire the legacy image?
> > > > > > >
> > > > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > > > someone to confirm that really, finally, we have all of the old use
> > > > > > > cases supported in the new code.
> > > > > > >
> > > > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > > > don't know.
> > > [unsnip end]
> > >
> > > > > > If we did one of these sorts of things at a time, we would only get
> > > > > > 2-3 things done each year!
> > > > >
> > > > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > > > sounds great to me. Rather than not finishing a dozen things?
> > > >
> > > > As this is a huge thread already, I'm splitting this part out.
> > > >
> > > > I would seriously frame slowing down and having just one big change
> > > > being in progress at a time, until it's done, as a good thing, not a bad
> > > > thing. We're a small community with limited bandwidth.
> > >
> > > I can't see how that would work.
> >
> > Well, what we have today is clearly not working well enough for you. And
> > "just land my changes" is still not an option for mainline.
> 
> You really haven't addressed my point here.

Then I don't see your point, or fundamentally disagree with it.

> > > I just looked at LED[1] originally sent almost 5 months ago and the
> > > latest version is marked 'changes requested'. I don't know of any
> > > changes I can make. Are you hoping that [sorry forgot who it was] will
> > > get around to digging the only affected device out of his drawer and
> > > try to get the activity-LED going? It might take a while.
> >
> > Yes, and as a reminder it's only been 6 or 7 months since mainline had
> > all of the required functionality, maybe. And what *you* could do to
> > speed things along is implement the functionality on any of the boards
> > at your disposal. Anything with a LED today would be fine for this.
> 
> Oh well. I would have thought that Christian's series was enough there?

Might be. Waiting for someone to have time to confirm functionality.
Which you had previously agreed was a good idea, I thought.

> > > The sunxi one[2] was sent over 6 months ago and the latest version is
> > > also marked 'changes requested'. You could apply that series with
> > > either the bootmgr revert or the patch that drops bootmgr for sunxi.
> > > Then Heinrich can come along with his patch on top of that.
> >
> > The sunxi one is blocked because it needs to be rebased on top of the
> > fix I did for BLK stuff and then yes you also could have done the
> > "bootstd uses bootmanager" idea that you've both agreed is a step in the
> > right direction. Because it's actually a generic issue with bootmgr +
> > bootstd that only became more evident as more platforms moved
> > towards using it.
> 
> So can you clearly explain what is blocking sunxi?r

In no particular order:
- Testing.
- Fixing the problems with efi boot manager, which is a global "use
  bootstd more" problem, not sunxi

And maybe:
- Handle FEL correctly. I'd have to re-read everything again to see if
  that was resolved right, or not.

> Does it just need a rebase?

Not just a rebase.

> Which patches should be included and which not?

Once the efi boot manager part is fixed, just the parts required for it?

> Also we
> normally expect patches sent first to have priority.

No we don't. There might be some general advice / rules of thumb but
it's far from some sort of absolute rule. Things are merged when they
work and are correct.

> Here you have
> apparently applied your BLK stuff and then want me to rework on top of
> it?

Yes, I applied the "handle BLK correctly" part that I tried to explain
to you how to fix a few times, and you either didn't understand or
didn't care. I'm leaning more towards "didn't care" now and thought we
should break things a little bit first and fix them later.

> I agreed to the bootmanager work-around but I'm certainly not going to
> write it. I would rather make bootmgr more iterative, if that is
> possible.

Then more bootstd migrations are likely blocked until it can handle efi
boot manager correctly, which you don't want to do.

> > Which is why I had spent so much time trying to get
> > you to migrate more SoCs to bootstd because it's your feature.
> 
> So take the sunxi patches and then I'll do the next one? On the one
> hand you complain that there are too many balls in the air and on the
> other you stop the balls from landing. It just doesn't 'compute' for
> me, sorry.

Yes, I'm sorry you're having trouble following my requests. Again, I
wanted more bootstd migration not for its own sake, but to expose
problems with the framework and for you to then fix those problems.

> > So yes, I think things would be in a better place if we tried to get
> > *less* big things done at once and didn't pick up another big thing
> > until the last was really done.
> 
> You should address my point above. Are you trying to limit me to 3-4
> large series a year?

You personally? No. The whole project? Yes, one big feature that's
complete and works every 3 months for a project with limited resources
sounds amazing. U-Boot isn't a toy personal project, it's something used
in production on real devices and needs to move at a sustainable pace
with minimal regressions.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Tue, 4 Mar 2025 at 08:29, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Mar 04, 2025 at 06:13:36AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > (I changed the subject as 'change' sounds like change for change's sake)
>
> Frankly, you have a lot of "tidy up" patches where nothing was
> functionally wrong.

Yes, but they are important too. One of the problems I see with U-Boot
is that not enough people are willing to do refactoring and code
maintenance on the required scale.

>
> > On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > (I think you chopped off too much context, so I've added it below)
> > >
> > > That's fine. But I omitted it because it's also true for any other DM
> > > migration, and bootstd more fully and adding more classes of devices for
> > > bootmeths and I honestly think you have a half dozen big things that are
> > > in various states of being merged and enabled and perhaps even more that
> > > didn't get much past sandbox being enabled.
> >
> > Yes I often have new ideas and start things.
>
> And my point is they need to be finished.

We've been through this quite a bit and I believe we have a shared
understanding of why it is hard for me to 'finish' things in your
tree.

>
> > > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > [snip]
> > > >
> > > > [unsnip]
> > > > > > > > >
> > > > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > > > > you imagine we could retire the legacy image?
> > > > > > > >
> > > > > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > > > > someone to confirm that really, finally, we have all of the old use
> > > > > > > > cases supported in the new code.
> > > > > > > >
> > > > > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > > > > don't know.
> > > > [unsnip end]
> > > >
> > > > > > > If we did one of these sorts of things at a time, we would only get
> > > > > > > 2-3 things done each year!
> > > > > >
> > > > > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > > > > sounds great to me. Rather than not finishing a dozen things?
> > > > >
> > > > > As this is a huge thread already, I'm splitting this part out.
> > > > >
> > > > > I would seriously frame slowing down and having just one big change
> > > > > being in progress at a time, until it's done, as a good thing, not a bad
> > > > > thing. We're a small community with limited bandwidth.
> > > >
> > > > I can't see how that would work.
> > >
> > > Well, what we have today is clearly not working well enough for you. And
> > > "just land my changes" is still not an option for mainline.
> >
> > You really haven't addressed my point here.
>
> Then I don't see your point, or fundamentally disagree with it.

My point is that I am trying to keep U-Boot in a position to solve the
major problems I see with boot firmware, largely because I don't see
much else out there. I can't do that with 2-3 big changes a year, not
even close.

>
> > > > I just looked at LED[1] originally sent almost 5 months ago and the
> > > > latest version is marked 'changes requested'. I don't know of any
> > > > changes I can make. Are you hoping that [sorry forgot who it was] will
> > > > get around to digging the only affected device out of his drawer and
> > > > try to get the activity-LED going? It might take a while.
> > >
> > > Yes, and as a reminder it's only been 6 or 7 months since mainline had
> > > all of the required functionality, maybe. And what *you* could do to
> > > speed things along is implement the functionality on any of the boards
> > > at your disposal. Anything with a LED today would be fine for this.
> >
> > Oh well. I would have thought that Christian's series was enough there?
>
> Might be. Waiting for someone to have time to confirm functionality.
> Which you had previously agreed was a good idea, I thought.

OK, so we'll just wait another few releases?

>
> > > > The sunxi one[2] was sent over 6 months ago and the latest version is
> > > > also marked 'changes requested'. You could apply that series with
> > > > either the bootmgr revert or the patch that drops bootmgr for sunxi.
> > > > Then Heinrich can come along with his patch on top of that.
> > >
> > > The sunxi one is blocked because it needs to be rebased on top of the
> > > fix I did for BLK stuff and then yes you also could have done the
> > > "bootstd uses bootmanager" idea that you've both agreed is a step in the
> > > right direction. Because it's actually a generic issue with bootmgr +
> > > bootstd that only became more evident as more platforms moved
> > > towards using it.
> >
> > So can you clearly explain what is blocking sunxi?r
>
> In no particular order:
> - Testing.
> - Fixing the problems with efi boot manager, which is a global "use
>   bootstd more" problem, not sunxi
>
> And maybe:
> - Handle FEL correctly. I'd have to re-read everything again to see if
>   that was resolved right, or not.

Andre did the testing which is how he found the bootmgr/FEL problem.
FEL is handled correctly in my series.

For bootmgr, there are two patches in my series so you can choose
which one you want.

>
> > Does it just need a rebase?
>
> Not just a rebase.
>
> > Which patches should be included and which not?
>
> Once the efi boot manager part is fixed, just the parts required for it?

So just take the patch which disables bootmgr from sunxi?

>
> > Also we
> > normally expect patches sent first to have priority.
>
> No we don't. There might be some general advice / rules of thumb but
> it's far from some sort of absolute rule. Things are merged when they
> work and are correct.

Well I was a bit put out seeing the series rejected on v3 due to an
out-of-tree thing I wasn't aware of.

>
> > Here you have
> > apparently applied your BLK stuff and then want me to rework on top of
> > it?
>
> Yes, I applied the "handle BLK correctly" part that I tried to explain
> to you how to fix a few times, and you either didn't understand or
> didn't care. I'm leaning more towards "didn't care" now and thought we
> should break things a little bit first and fix them later.
>
> > I agreed to the bootmanager work-around but I'm certainly not going to
> > write it. I would rather make bootmgr more iterative, if that is
> > possible.
>
> Then more bootstd migrations are likely blocked until it can handle efi
> boot manager correctly, which you don't want to do.

The correct way to handle bootmgr is (probably?) to have it use
bootstd to scan for stuff. But as you know, I can't get patches into
the EFI subsystem, so it's moot.

>
> > > Which is why I had spent so much time trying to get
> > > you to migrate more SoCs to bootstd because it's your feature.
> >
> > So take the sunxi patches and then I'll do the next one? On the one
> > hand you complain that there are too many balls in the air and on the
> > other you stop the balls from landing. It just doesn't 'compute' for
> > me, sorry.
>
> Yes, I'm sorry you're having trouble following my requests. Again, I
> wanted more bootstd migration not for its own sake, but to expose
> problems with the framework and for you to then fix those problems.

There is no problem with the framework. Please just follow my notes
above and apply the patches. Specifically these ones:

733876246aa sunxi: Add a bootmeth for FEL
ab5fbb4f7c0 efi_loader: bootstd: Drop bootmgr for sunxi
(leave this one out for now) 9f4ed60d90c RFC: Revert "bootstd: Make
efi_mgr bootmeth work for non-sandbox setups"
90d88509ebd sunxi: Move to bootstd
e0a16425620 sunxi: Drop old distro boot variables
da69a979ec7 env: Provide a work-around for unquoting fdtfile
7c37601d6be (dm/std-working, dm-public/std-working) sunxi: Move to
text environment

I'm tired of hearing that there is something wrong with bootstd here,
so please stop saying that.

>
> > > So yes, I think things would be in a better place if we tried to get
> > > *less* big things done at once and didn't pick up another big thing
> > > until the last was really done.
> >
> > You should address my point above. Are you trying to limit me to 3-4
> > large series a year?
>
> You personally? No. The whole project? Yes, one big feature that's
> complete and works every 3 months for a project with limited resources
> sounds amazing. U-Boot isn't a toy personal project, it's something used
> in production on real devices and needs to move at a sustainable pace
> with minimal regressions.

I believe that is getting better with the increased focus on testing,
something which I have been pushing for years.

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 11399 bytes --]

On Wed, Mar 05, 2025 at 07:19:25AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 4 Mar 2025 at 08:29, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Mar 04, 2025 at 06:13:36AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > (I changed the subject as 'change' sounds like change for change's sake)
> >
> > Frankly, you have a lot of "tidy up" patches where nothing was
> > functionally wrong.
> 
> Yes, but they are important too. One of the problems I see with U-Boot
> is that not enough people are willing to do refactoring and code
> maintenance on the required scale.

Again, how much "refactoring" is needed of everything.

> > > On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > (I think you chopped off too much context, so I've added it below)
> > > >
> > > > That's fine. But I omitted it because it's also true for any other DM
> > > > migration, and bootstd more fully and adding more classes of devices for
> > > > bootmeths and I honestly think you have a half dozen big things that are
> > > > in various states of being merged and enabled and perhaps even more that
> > > > didn't get much past sandbox being enabled.
> > >
> > > Yes I often have new ideas and start things.
> >
> > And my point is they need to be finished.
> 
> We've been through this quite a bit and I believe we have a shared
> understanding of why it is hard for me to 'finish' things in your
> tree.

I don't think we do. Because from my point of view you're as interested
in finishing up the details and working through the migrations as you
are on moving to the next thing.

> > > > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > > > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > [snip]
> > > > >
> > > > > [unsnip]
> > > > > > > > > >
> > > > > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > > > > > you imagine we could retire the legacy image?
> > > > > > > > >
> > > > > > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > > > > > someone to confirm that really, finally, we have all of the old use
> > > > > > > > > cases supported in the new code.
> > > > > > > > >
> > > > > > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > > > > > don't know.
> > > > > [unsnip end]
> > > > >
> > > > > > > > If we did one of these sorts of things at a time, we would only get
> > > > > > > > 2-3 things done each year!
> > > > > > >
> > > > > > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > > > > > sounds great to me. Rather than not finishing a dozen things?
> > > > > >
> > > > > > As this is a huge thread already, I'm splitting this part out.
> > > > > >
> > > > > > I would seriously frame slowing down and having just one big change
> > > > > > being in progress at a time, until it's done, as a good thing, not a bad
> > > > > > thing. We're a small community with limited bandwidth.
> > > > >
> > > > > I can't see how that would work.
> > > >
> > > > Well, what we have today is clearly not working well enough for you. And
> > > > "just land my changes" is still not an option for mainline.
> > >
> > > You really haven't addressed my point here.
> >
> > Then I don't see your point, or fundamentally disagree with it.
> 
> My point is that I am trying to keep U-Boot in a position to solve the
> major problems I see with boot firmware, largely because I don't see
> much else out there. I can't do that with 2-3 big changes a year, not
> even close.

Then maybe you need to fork off and make Simon-Boot. Or maybe you need
to take leadership of the project as a whole. Because I do not see what
you want as sustainable for the project.

> > > > > I just looked at LED[1] originally sent almost 5 months ago and the
> > > > > latest version is marked 'changes requested'. I don't know of any
> > > > > changes I can make. Are you hoping that [sorry forgot who it was] will
> > > > > get around to digging the only affected device out of his drawer and
> > > > > try to get the activity-LED going? It might take a while.
> > > >
> > > > Yes, and as a reminder it's only been 6 or 7 months since mainline had
> > > > all of the required functionality, maybe. And what *you* could do to
> > > > speed things along is implement the functionality on any of the boards
> > > > at your disposal. Anything with a LED today would be fine for this.
> > >
> > > Oh well. I would have thought that Christian's series was enough there?
> >
> > Might be. Waiting for someone to have time to confirm functionality.
> > Which you had previously agreed was a good idea, I thought.
> 
> OK, so we'll just wait another few releases?

Until someone, which could be you even, has the time to verify things,
yes. Easily. Happily.

> > > > > The sunxi one[2] was sent over 6 months ago and the latest version is
> > > > > also marked 'changes requested'. You could apply that series with
> > > > > either the bootmgr revert or the patch that drops bootmgr for sunxi.
> > > > > Then Heinrich can come along with his patch on top of that.
> > > >
> > > > The sunxi one is blocked because it needs to be rebased on top of the
> > > > fix I did for BLK stuff and then yes you also could have done the
> > > > "bootstd uses bootmanager" idea that you've both agreed is a step in the
> > > > right direction. Because it's actually a generic issue with bootmgr +
> > > > bootstd that only became more evident as more platforms moved
> > > > towards using it.
> > >
> > > So can you clearly explain what is blocking sunxi?r
> >
> > In no particular order:
> > - Testing.
> > - Fixing the problems with efi boot manager, which is a global "use
> >   bootstd more" problem, not sunxi
> >
> > And maybe:
> > - Handle FEL correctly. I'd have to re-read everything again to see if
> >   that was resolved right, or not.
> 
> Andre did the testing which is how he found the bootmgr/FEL problem.
> FEL is handled correctly in my series.

So FEL is OK afterall, good.

> For bootmgr, there are two patches in my series so you can choose
> which one you want.

And the answer there was neither, both are wrong. We instead finally hit
a more fundamental problem. Which you don't want to solve. And Heinrich
has said he'll post RFC on, but hasn't had time.

> > > Does it just need a rebase?
> >
> > Not just a rebase.
> >
> > > Which patches should be included and which not?
> >
> > Once the efi boot manager part is fixed, just the parts required for it?
> 
> So just take the patch which disables bootmgr from sunxi?

Who was in favour of that idea again?

> > > Also we
> > > normally expect patches sent first to have priority.
> >
> > No we don't. There might be some general advice / rules of thumb but
> > it's far from some sort of absolute rule. Things are merged when they
> > work and are correct.
> 
> Well I was a bit put out seeing the series rejected on v3 due to an
> out-of-tree thing I wasn't aware of.

Yes, you need to figure out how to get a better handle on your emails
since you shouldn't have been unaware then.

> > > Here you have
> > > apparently applied your BLK stuff and then want me to rework on top of
> > > it?
> >
> > Yes, I applied the "handle BLK correctly" part that I tried to explain
> > to you how to fix a few times, and you either didn't understand or
> > didn't care. I'm leaning more towards "didn't care" now and thought we
> > should break things a little bit first and fix them later.
> >
> > > I agreed to the bootmanager work-around but I'm certainly not going to
> > > write it. I would rather make bootmgr more iterative, if that is
> > > possible.
> >
> > Then more bootstd migrations are likely blocked until it can handle efi
> > boot manager correctly, which you don't want to do.
> 
> The correct way to handle bootmgr is (probably?) to have it use
> bootstd to scan for stuff. But as you know, I can't get patches into
> the EFI subsystem, so it's moot.

Since you insist on starting with several "tidy up" series that have
been rejected before starting on the problem at hand, yes, that's true.

> > > > Which is why I had spent so much time trying to get
> > > > you to migrate more SoCs to bootstd because it's your feature.
> > >
> > > So take the sunxi patches and then I'll do the next one? On the one
> > > hand you complain that there are too many balls in the air and on the
> > > other you stop the balls from landing. It just doesn't 'compute' for
> > > me, sorry.
> >
> > Yes, I'm sorry you're having trouble following my requests. Again, I
> > wanted more bootstd migration not for its own sake, but to expose
> > problems with the framework and for you to then fix those problems.
> 
> There is no problem with the framework. Please just follow my notes
> above and apply the patches. Specifically these ones:

That it doesn't work nicely with EFI boot manager IS a problem with the
framework.

> 733876246aa sunxi: Add a bootmeth for FEL
> ab5fbb4f7c0 efi_loader: bootstd: Drop bootmgr for sunxi
> (leave this one out for now) 9f4ed60d90c RFC: Revert "bootstd: Make
> efi_mgr bootmeth work for non-sandbox setups"
> 90d88509ebd sunxi: Move to bootstd
> e0a16425620 sunxi: Drop old distro boot variables
> da69a979ec7 env: Provide a work-around for unquoting fdtfile
> 7c37601d6be (dm/std-working, dm-public/std-working) sunxi: Move to
> text environment
> 
> I'm tired of hearing that there is something wrong with bootstd here,
> so please stop saying that.

Well, from my point of view there is a problem. Because your "tidy up"
isn't working with what mainstream OS distributions want. So it's not a
1:1 replacement for what we have today that does work.

> > > > So yes, I think things would be in a better place if we tried to get
> > > > *less* big things done at once and didn't pick up another big thing
> > > > until the last was really done.
> > >
> > > You should address my point above. Are you trying to limit me to 3-4
> > > large series a year?
> >
> > You personally? No. The whole project? Yes, one big feature that's
> > complete and works every 3 months for a project with limited resources
> > sounds amazing. U-Boot isn't a toy personal project, it's something used
> > in production on real devices and needs to move at a sustainable pace
> > with minimal regressions.
> 
> I believe that is getting better with the increased focus on testing,
> something which I have been pushing for years.

I'm referring to the breadth of testing, not the depth of testing. More
tests are good. More boards being tested is more important. Your lab is
good, yes, but it's not like HW vendors haven't been testing already and
for a long time. And your feedback on their feedback (needing to be able
to use a they-push-out model) wasn't positive.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Wed, 5 Mar 2025 at 09:22, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Mar 05, 2025 at 07:19:25AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 4 Mar 2025 at 08:29, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Mar 04, 2025 at 06:13:36AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > (I changed the subject as 'change' sounds like change for change's sake)
> > >
> > > Frankly, you have a lot of "tidy up" patches where nothing was
> > > functionally wrong.
> >
> > Yes, but they are important too. One of the problems I see with U-Boot
> > is that not enough people are willing to do refactoring and code
> > maintenance on the required scale.
>
> Again, how much "refactoring" is needed of everything.

Without regular refactoring, projects just die.

>
> > > > On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > (I think you chopped off too much context, so I've added it below)
> > > > >
> > > > > That's fine. But I omitted it because it's also true for any other DM
> > > > > migration, and bootstd more fully and adding more classes of devices for
> > > > > bootmeths and I honestly think you have a half dozen big things that are
> > > > > in various states of being merged and enabled and perhaps even more that
> > > > > didn't get much past sandbox being enabled.
> > > >
> > > > Yes I often have new ideas and start things.
> > >
> > > And my point is they need to be finished.
> >
> > We've been through this quite a bit and I believe we have a shared
> > understanding of why it is hard for me to 'finish' things in your
> > tree.
>
> I don't think we do. Because from my point of view you're as interested
> in finishing up the details and working through the migrations as you
> are on moving to the next thing.

That sounds right, it is nice to finish migrations. But I don't like
the slowness of it all.

>
> > > > > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > > > > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > [snip]
> > > > > >
> > > > > > [unsnip]
> > > > > > > > > > >
> > > > > > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > > > > > > you imagine we could retire the legacy image?
> > > > > > > > > >
> > > > > > > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > > > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > > > > > > someone to confirm that really, finally, we have all of the old use
> > > > > > > > > > cases supported in the new code.
> > > > > > > > > >
> > > > > > > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > > > > > > don't know.
> > > > > > [unsnip end]
> > > > > >
> > > > > > > > > If we did one of these sorts of things at a time, we would only get
> > > > > > > > > 2-3 things done each year!
> > > > > > > >
> > > > > > > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > > > > > > sounds great to me. Rather than not finishing a dozen things?
> > > > > > >
> > > > > > > As this is a huge thread already, I'm splitting this part out.
> > > > > > >
> > > > > > > I would seriously frame slowing down and having just one big change
> > > > > > > being in progress at a time, until it's done, as a good thing, not a bad
> > > > > > > thing. We're a small community with limited bandwidth.
> > > > > >
> > > > > > I can't see how that would work.
> > > > >
> > > > > Well, what we have today is clearly not working well enough for you. And
> > > > > "just land my changes" is still not an option for mainline.
> > > >
> > > > You really haven't addressed my point here.
> > >
> > > Then I don't see your point, or fundamentally disagree with it.
> >
> > My point is that I am trying to keep U-Boot in a position to solve the
> > major problems I see with boot firmware, largely because I don't see
> > much else out there. I can't do that with 2-3 big changes a year, not
> > even close.
>
> Then maybe you need to fork off and make Simon-Boot. Or maybe you need
> to take leadership of the project as a whole. Because I do not see what
> you want as sustainable for the project.

Or you could just be a little more flexible?

>
> > > > > > I just looked at LED[1] originally sent almost 5 months ago and the
> > > > > > latest version is marked 'changes requested'. I don't know of any
> > > > > > changes I can make. Are you hoping that [sorry forgot who it was] will
> > > > > > get around to digging the only affected device out of his drawer and
> > > > > > try to get the activity-LED going? It might take a while.
> > > > >
> > > > > Yes, and as a reminder it's only been 6 or 7 months since mainline had
> > > > > all of the required functionality, maybe. And what *you* could do to
> > > > > speed things along is implement the functionality on any of the boards
> > > > > at your disposal. Anything with a LED today would be fine for this.
> > > >
> > > > Oh well. I would have thought that Christian's series was enough there?
> > >
> > > Might be. Waiting for someone to have time to confirm functionality.
> > > Which you had previously agreed was a good idea, I thought.
> >
> > OK, so we'll just wait another few releases?
>
> Until someone, which could be you even, has the time to verify things,
> yes. Easily. Happily.

The incentives are wrong here, of course. People should *want* to test
in case patches break their use case. People who wait 6 months to test
are just not that interested in the project.

>
> > > > > > The sunxi one[2] was sent over 6 months ago and the latest version is
> > > > > > also marked 'changes requested'. You could apply that series with
> > > > > > either the bootmgr revert or the patch that drops bootmgr for sunxi.
> > > > > > Then Heinrich can come along with his patch on top of that.
> > > > >
> > > > > The sunxi one is blocked because it needs to be rebased on top of the
> > > > > fix I did for BLK stuff and then yes you also could have done the
> > > > > "bootstd uses bootmanager" idea that you've both agreed is a step in the
> > > > > right direction. Because it's actually a generic issue with bootmgr +
> > > > > bootstd that only became more evident as more platforms moved
> > > > > towards using it.
> > > >
> > > > So can you clearly explain what is blocking sunxi?r
> > >
> > > In no particular order:
> > > - Testing.
> > > - Fixing the problems with efi boot manager, which is a global "use
> > >   bootstd more" problem, not sunxi
> > >
> > > And maybe:
> > > - Handle FEL correctly. I'd have to re-read everything again to see if
> > >   that was resolved right, or not.
> >
> > Andre did the testing which is how he found the bootmgr/FEL problem.
> > FEL is handled correctly in my series.
>
> So FEL is OK afterall, good.
>
> > For bootmgr, there are two patches in my series so you can choose
> > which one you want.
>
> And the answer there was neither, both are wrong. We instead finally hit
> a more fundamental problem. Which you don't want to solve. And Heinrich
> has said he'll post RFC on, but hasn't had time.

Or you could just make a decision.

>
> > > > Does it just need a rebase?
> > >
> > > Not just a rebase.
> > >
> > > > Which patches should be included and which not?
> > >
> > > Once the efi boot manager part is fixed, just the parts required for it?
> >
> > So just take the patch which disables bootmgr from sunxi?
>
> Who was in favour of that idea again?

Andre seemed OK with it as no one uses it at present and it allows us
to make progress.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/#3418689

>
> > > > Also we
> > > > normally expect patches sent first to have priority.
> > >
> > > No we don't. There might be some general advice / rules of thumb but
> > > it's far from some sort of absolute rule. Things are merged when they
> > > work and are correct.
> >
> > Well I was a bit put out seeing the series rejected on v3 due to an
> > out-of-tree thing I wasn't aware of.
>
> Yes, you need to figure out how to get a better handle on your emails
> since you shouldn't have been unaware then.

Yes I've scaled back my reviews significantly and that is giving me more time.

>
> > > > Here you have
> > > > apparently applied your BLK stuff and then want me to rework on top of
> > > > it?
> > >
> > > Yes, I applied the "handle BLK correctly" part that I tried to explain
> > > to you how to fix a few times, and you either didn't understand or
> > > didn't care. I'm leaning more towards "didn't care" now and thought we
> > > should break things a little bit first and fix them later.
> > >
> > > > I agreed to the bootmanager work-around but I'm certainly not going to
> > > > write it. I would rather make bootmgr more iterative, if that is
> > > > possible.
> > >
> > > Then more bootstd migrations are likely blocked until it can handle efi
> > > boot manager correctly, which you don't want to do.
> >
> > The correct way to handle bootmgr is (probably?) to have it use
> > bootstd to scan for stuff. But as you know, I can't get patches into
> > the EFI subsystem, so it's moot.
>
> Since you insist on starting with several "tidy up" series that have
> been rejected before starting on the problem at hand, yes, that's true.

Yes, I am aware it is true.

>
> > > > > Which is why I had spent so much time trying to get
> > > > > you to migrate more SoCs to bootstd because it's your feature.
> > > >
> > > > So take the sunxi patches and then I'll do the next one? On the one
> > > > hand you complain that there are too many balls in the air and on the
> > > > other you stop the balls from landing. It just doesn't 'compute' for
> > > > me, sorry.
> > >
> > > Yes, I'm sorry you're having trouble following my requests. Again, I
> > > wanted more bootstd migration not for its own sake, but to expose
> > > problems with the framework and for you to then fix those problems.
> >
> > There is no problem with the framework. Please just follow my notes
> > above and apply the patches. Specifically these ones:
>
> That it doesn't work nicely with EFI boot manager IS a problem with the
> framework.

It's a problem with bootmgr, which I'm not going to take on, since I
am unable to get patches into EFI_LOADER.

>
> > 733876246aa sunxi: Add a bootmeth for FEL
> > ab5fbb4f7c0 efi_loader: bootstd: Drop bootmgr for sunxi
> > (leave this one out for now) 9f4ed60d90c RFC: Revert "bootstd: Make
> > efi_mgr bootmeth work for non-sandbox setups"
> > 90d88509ebd sunxi: Move to bootstd
> > e0a16425620 sunxi: Drop old distro boot variables
> > da69a979ec7 env: Provide a work-around for unquoting fdtfile
> > 7c37601d6be (dm/std-working, dm-public/std-working) sunxi: Move to
> > text environment
> >
> > I'm tired of hearing that there is something wrong with bootstd here,
> > so please stop saying that.
>
> Well, from my point of view there is a problem. Because your "tidy up"
> isn't working with what mainstream OS distributions want. So it's not a
> 1:1 replacement for what we have today that does work.

Which tidy-up?

>
> > > > > So yes, I think things would be in a better place if we tried to get
> > > > > *less* big things done at once and didn't pick up another big thing
> > > > > until the last was really done.
> > > >
> > > > You should address my point above. Are you trying to limit me to 3-4
> > > > large series a year?
> > >
> > > You personally? No. The whole project? Yes, one big feature that's
> > > complete and works every 3 months for a project with limited resources
> > > sounds amazing. U-Boot isn't a toy personal project, it's something used
> > > in production on real devices and needs to move at a sustainable pace
> > > with minimal regressions.
> >
> > I believe that is getting better with the increased focus on testing,
> > something which I have been pushing for years.
>
> I'm referring to the breadth of testing, not the depth of testing. More
> tests are good. More boards being tested is more important. Your lab is
> good, yes, but it's not like HW vendors haven't been testing already and
> for a long time. And your feedback on their feedback (needing to be able
> to use a they-push-out model) wasn't positive.

Are you saying that you want me to implement a framework to access
test results from HW vendors and that until I do that, you consider
that I am holding testing back?? Anyway, don't such frameworks already
exist?

Again, back to this thread, if you want me to migrate things, consider
applying the sunxi patches as I have described above. I will then look
at the next target for bootstd. But while you hold this up, I cannot
move forward with more bootstd migration. It doesn't seem that much to
ask.

- Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 15398 bytes --]

On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 5 Mar 2025 at 09:22, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Mar 05, 2025 at 07:19:25AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 4 Mar 2025 at 08:29, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Mar 04, 2025 at 06:13:36AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > (I changed the subject as 'change' sounds like change for change's sake)
> > > >
> > > > Frankly, you have a lot of "tidy up" patches where nothing was
> > > > functionally wrong.
> > >
> > > Yes, but they are important too. One of the problems I see with U-Boot
> > > is that not enough people are willing to do refactoring and code
> > > maintenance on the required scale.
> >
> > Again, how much "refactoring" is needed of everything.
> 
> Without regular refactoring, projects just die.

Strongly disagree. Regular refactoring makes contributions too hard for
new developers because everything is changing all the time. See for
example how you and I (seemingly) shared a gripe about how python
changes all the time and supporting things long term is too hard.

> > > > > On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > (I think you chopped off too much context, so I've added it below)
> > > > > >
> > > > > > That's fine. But I omitted it because it's also true for any other DM
> > > > > > migration, and bootstd more fully and adding more classes of devices for
> > > > > > bootmeths and I honestly think you have a half dozen big things that are
> > > > > > in various states of being merged and enabled and perhaps even more that
> > > > > > didn't get much past sandbox being enabled.
> > > > >
> > > > > Yes I often have new ideas and start things.
> > > >
> > > > And my point is they need to be finished.
> > >
> > > We've been through this quite a bit and I believe we have a shared
> > > understanding of why it is hard for me to 'finish' things in your
> > > tree.
> >
> > I don't think we do. Because from my point of view you're as interested
> > in finishing up the details and working through the migrations as you
> > are on moving to the next thing.
> 
> That sounds right, it is nice to finish migrations. But I don't like
> the slowness of it all.

Yes, you wish the project would move faster and I think it's moving too
fast.

> > > > > > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > > > > > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > [snip]
> > > > > > >
> > > > > > > [unsnip]
> > > > > > > > > > > >
> > > > > > > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > > > > > > > you imagine we could retire the legacy image?
> > > > > > > > > > >
> > > > > > > > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > > > > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > > > > > > > someone to confirm that really, finally, we have all of the old use
> > > > > > > > > > > cases supported in the new code.
> > > > > > > > > > >
> > > > > > > > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > > > > > > > don't know.
> > > > > > > [unsnip end]
> > > > > > >
> > > > > > > > > > If we did one of these sorts of things at a time, we would only get
> > > > > > > > > > 2-3 things done each year!
> > > > > > > > >
> > > > > > > > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > > > > > > > sounds great to me. Rather than not finishing a dozen things?
> > > > > > > >
> > > > > > > > As this is a huge thread already, I'm splitting this part out.
> > > > > > > >
> > > > > > > > I would seriously frame slowing down and having just one big change
> > > > > > > > being in progress at a time, until it's done, as a good thing, not a bad
> > > > > > > > thing. We're a small community with limited bandwidth.
> > > > > > >
> > > > > > > I can't see how that would work.
> > > > > >
> > > > > > Well, what we have today is clearly not working well enough for you. And
> > > > > > "just land my changes" is still not an option for mainline.
> > > > >
> > > > > You really haven't addressed my point here.
> > > >
> > > > Then I don't see your point, or fundamentally disagree with it.
> > >
> > > My point is that I am trying to keep U-Boot in a position to solve the
> > > major problems I see with boot firmware, largely because I don't see
> > > much else out there. I can't do that with 2-3 big changes a year, not
> > > even close.
> >
> > Then maybe you need to fork off and make Simon-Boot. Or maybe you need
> > to take leadership of the project as a whole. Because I do not see what
> > you want as sustainable for the project.
> 
> Or you could just be a little more flexible?

I need to go look at the other email thread where I asked you to tell me
something I can do, before I reply again here.

> > > > > > > I just looked at LED[1] originally sent almost 5 months ago and the
> > > > > > > latest version is marked 'changes requested'. I don't know of any
> > > > > > > changes I can make. Are you hoping that [sorry forgot who it was] will
> > > > > > > get around to digging the only affected device out of his drawer and
> > > > > > > try to get the activity-LED going? It might take a while.
> > > > > >
> > > > > > Yes, and as a reminder it's only been 6 or 7 months since mainline had
> > > > > > all of the required functionality, maybe. And what *you* could do to
> > > > > > speed things along is implement the functionality on any of the boards
> > > > > > at your disposal. Anything with a LED today would be fine for this.
> > > > >
> > > > > Oh well. I would have thought that Christian's series was enough there?
> > > >
> > > > Might be. Waiting for someone to have time to confirm functionality.
> > > > Which you had previously agreed was a good idea, I thought.
> > >
> > > OK, so we'll just wait another few releases?
> >
> > Until someone, which could be you even, has the time to verify things,
> > yes. Easily. Happily.
> 
> The incentives are wrong here, of course. People should *want* to test
> in case patches break their use case. People who wait 6 months to test
> are just not that interested in the project.

Strongly disagree. We're a boot loader. People reasonably expect that
it's not changing all the time and doesn't need constant attention and
re-testing.

> > > > > > > The sunxi one[2] was sent over 6 months ago and the latest version is
> > > > > > > also marked 'changes requested'. You could apply that series with
> > > > > > > either the bootmgr revert or the patch that drops bootmgr for sunxi.
> > > > > > > Then Heinrich can come along with his patch on top of that.
> > > > > >
> > > > > > The sunxi one is blocked because it needs to be rebased on top of the
> > > > > > fix I did for BLK stuff and then yes you also could have done the
> > > > > > "bootstd uses bootmanager" idea that you've both agreed is a step in the
> > > > > > right direction. Because it's actually a generic issue with bootmgr +
> > > > > > bootstd that only became more evident as more platforms moved
> > > > > > towards using it.
> > > > >
> > > > > So can you clearly explain what is blocking sunxi?r
> > > >
> > > > In no particular order:
> > > > - Testing.
> > > > - Fixing the problems with efi boot manager, which is a global "use
> > > >   bootstd more" problem, not sunxi
> > > >
> > > > And maybe:
> > > > - Handle FEL correctly. I'd have to re-read everything again to see if
> > > >   that was resolved right, or not.
> > >
> > > Andre did the testing which is how he found the bootmgr/FEL problem.
> > > FEL is handled correctly in my series.
> >
> > So FEL is OK afterall, good.
> >
> > > For bootmgr, there are two patches in my series so you can choose
> > > which one you want.
> >
> > And the answer there was neither, both are wrong. We instead finally hit
> > a more fundamental problem. Which you don't want to solve. And Heinrich
> > has said he'll post RFC on, but hasn't had time.
> 
> Or you could just make a decision.

I did. It's the one you don't like, which is to slow down
bootstd/bootmeth/etc.

> > > > > Does it just need a rebase?
> > > >
> > > > Not just a rebase.
> > > >
> > > > > Which patches should be included and which not?
> > > >
> > > > Once the efi boot manager part is fixed, just the parts required for it?
> > >
> > > So just take the patch which disables bootmgr from sunxi?
> >
> > Who was in favour of that idea again?
> 
> Andre seemed OK with it as no one uses it at present and it allows us
> to make progress.
> 
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/#3418689

That's not how I read the final parts of the thread.

> > > > > Also we
> > > > > normally expect patches sent first to have priority.
> > > >
> > > > No we don't. There might be some general advice / rules of thumb but
> > > > it's far from some sort of absolute rule. Things are merged when they
> > > > work and are correct.
> > >
> > > Well I was a bit put out seeing the series rejected on v3 due to an
> > > out-of-tree thing I wasn't aware of.
> >
> > Yes, you need to figure out how to get a better handle on your emails
> > since you shouldn't have been unaware then.
> 
> Yes I've scaled back my reviews significantly and that is giving me more time.
> 
> >
> > > > > Here you have
> > > > > apparently applied your BLK stuff and then want me to rework on top of
> > > > > it?
> > > >
> > > > Yes, I applied the "handle BLK correctly" part that I tried to explain
> > > > to you how to fix a few times, and you either didn't understand or
> > > > didn't care. I'm leaning more towards "didn't care" now and thought we
> > > > should break things a little bit first and fix them later.
> > > >
> > > > > I agreed to the bootmanager work-around but I'm certainly not going to
> > > > > write it. I would rather make bootmgr more iterative, if that is
> > > > > possible.
> > > >
> > > > Then more bootstd migrations are likely blocked until it can handle efi
> > > > boot manager correctly, which you don't want to do.
> > >
> > > The correct way to handle bootmgr is (probably?) to have it use
> > > bootstd to scan for stuff. But as you know, I can't get patches into
> > > the EFI subsystem, so it's moot.
> >
> > Since you insist on starting with several "tidy up" series that have
> > been rejected before starting on the problem at hand, yes, that's true.
> 
> Yes, I am aware it is true.

Then it's misleading to say you can't get patches in to the EFI
subsystem.

> > > > > > Which is why I had spent so much time trying to get
> > > > > > you to migrate more SoCs to bootstd because it's your feature.
> > > > >
> > > > > So take the sunxi patches and then I'll do the next one? On the one
> > > > > hand you complain that there are too many balls in the air and on the
> > > > > other you stop the balls from landing. It just doesn't 'compute' for
> > > > > me, sorry.
> > > >
> > > > Yes, I'm sorry you're having trouble following my requests. Again, I
> > > > wanted more bootstd migration not for its own sake, but to expose
> > > > problems with the framework and for you to then fix those problems.
> > >
> > > There is no problem with the framework. Please just follow my notes
> > > above and apply the patches. Specifically these ones:
> >
> > That it doesn't work nicely with EFI boot manager IS a problem with the
> > framework.
> 
> It's a problem with bootmgr, which I'm not going to take on, since I
> am unable to get patches into EFI_LOADER.

It's a problem with bootmgr and bootmeth/bootstd.

> > > 733876246aa sunxi: Add a bootmeth for FEL
> > > ab5fbb4f7c0 efi_loader: bootstd: Drop bootmgr for sunxi
> > > (leave this one out for now) 9f4ed60d90c RFC: Revert "bootstd: Make
> > > efi_mgr bootmeth work for non-sandbox setups"
> > > 90d88509ebd sunxi: Move to bootstd
> > > e0a16425620 sunxi: Drop old distro boot variables
> > > da69a979ec7 env: Provide a work-around for unquoting fdtfile
> > > 7c37601d6be (dm/std-working, dm-public/std-working) sunxi: Move to
> > > text environment
> > >
> > > I'm tired of hearing that there is something wrong with bootstd here,
> > > so please stop saying that.
> >
> > Well, from my point of view there is a problem. Because your "tidy up"
> > isn't working with what mainstream OS distributions want. So it's not a
> > 1:1 replacement for what we have today that does work.
> 
> Which tidy-up?

The bootstd/bootmeth framework.

> > > > > > So yes, I think things would be in a better place if we tried to get
> > > > > > *less* big things done at once and didn't pick up another big thing
> > > > > > until the last was really done.
> > > > >
> > > > > You should address my point above. Are you trying to limit me to 3-4
> > > > > large series a year?
> > > >
> > > > You personally? No. The whole project? Yes, one big feature that's
> > > > complete and works every 3 months for a project with limited resources
> > > > sounds amazing. U-Boot isn't a toy personal project, it's something used
> > > > in production on real devices and needs to move at a sustainable pace
> > > > with minimal regressions.
> > >
> > > I believe that is getting better with the increased focus on testing,
> > > something which I have been pushing for years.
> >
> > I'm referring to the breadth of testing, not the depth of testing. More
> > tests are good. More boards being tested is more important. Your lab is
> > good, yes, but it's not like HW vendors haven't been testing already and
> > for a long time. And your feedback on their feedback (needing to be able
> > to use a they-push-out model) wasn't positive.
> 
> Are you saying that you want me to implement a framework to access
> test results from HW vendors and that until I do that, you consider
> that I am holding testing back?? Anyway, don't such frameworks already
> exist?

Oh goodness no. I want you to stop trying to personally boil the entire
ocean, to use a phrase you often use.

What I am saying is that the direction you're trying to take testing in
seems to be the opposite of the community feedback, so maybe stop going
in that direction and focus on one of the other things you're trying to
do.

> Again, back to this thread, if you want me to migrate things, consider
> applying the sunxi patches as I have described above. I will then look
> at the next target for bootstd. But while you hold this up, I cannot
> move forward with more bootstd migration. It doesn't seem that much to
> ask.

I will take another look at what's still relevant. But I believe it's
still blocked on the fact that it changes behavior and breaks users.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]

On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
[snip]
> > Again, back to this thread, if you want me to migrate things, consider
> > applying the sunxi patches as I have described above. I will then look
> > at the next target for bootstd. But while you hold this up, I cannot
> > move forward with more bootstd migration. It doesn't seem that much to
> > ask.
> 
> I will take another look at what's still relevant. But I believe it's
> still blocked on the fact that it changes behavior and breaks users.

In details:

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/

Now that the underlying BLK problem is resolved, this can just be
dropped I believe. Removing the BLK dependency from BOOTSTD can happen
when you're supporting a flow that lacks a BLK device entirely. This
would be another reminder as to why putting unrelated changes in a
series is a problem.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/

This is fine.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/

This is not fine. This is also not a sunxi problem. It means that we
should drop bootmgr from rockchip, where the conversion has already
taken place, and would need to drop it from future conversion too.
Neither of which are desirable changes. This patch in particular is
where we have the note:

"Yes, the introduction of boot standard changed the boot order and
specifically deprioritizing scripts is unexpected."

Which should have had more attention than it did.

This is the thread that to me spelled out in details where the
conversions are now blocked. We changed behavior and that in turn breaks
users that have come to rely on ordering.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/

Is an alternative to the above which then turned in to a discussion that
I would very briefly summarize as "no discussions were had between
stakeholders before integrating efi bootmgr with bootstd".

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/

This is fine, but only relevant once migration happens.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/

If Andre is fine with this, this is fine.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/

This is a generic bugfix. I will take this to next today.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/

If Andre is fine with this, this is fine.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> [snip]
> > > Again, back to this thread, if you want me to migrate things, consider
> > > applying the sunxi patches as I have described above. I will then look
> > > at the next target for bootstd. But while you hold this up, I cannot
> > > move forward with more bootstd migration. It doesn't seem that much to
> > > ask.
> >
> > I will take another look at what's still relevant. But I believe it's
> > still blocked on the fact that it changes behavior and breaks users.
>
> In details:
>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
>
> Now that the underlying BLK problem is resolved, this can just be
> dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> when you're supporting a flow that lacks a BLK device entirely. This
> would be another reminder as to why putting unrelated changes in a
> series is a problem.

OK, then just don't apply this patch. Problem solved?

>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
>
> This is fine.
>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
>
> This is not fine. This is also not a sunxi problem. It means that we
> should drop bootmgr from rockchip, where the conversion has already
> taken place, and would need to drop it from future conversion too.
> Neither of which are desirable changes.

Why do you say that? I don't understand how this relates to rockchip
or why we would need to drop bootmgr from that.

> This patch in particular is
> where we have the note:
>
> "Yes, the introduction of boot standard changed the boot order and
> specifically deprioritizing scripts is unexpected."
>
> Which should have had more attention than it did.

From memory the scripts are a fallback used when the other things
don't work, so that was the decision I made at the time.

>
> This is the thread that to me spelled out in details where the
> conversions are now blocked. We changed behavior and that in turn breaks
> users that have come to rely on ordering.

I don't know what action to take on that comment. We cannot have 100%
backwards compatibility with the scripts, which after all weren't even
documented. But it is very close.

>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
>
> Is an alternative to the above which then turned in to a discussion that
> I would very briefly summarize as "no discussions were had between
> stakeholders before integrating efi bootmgr with bootstd".
>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
>
> This is fine, but only relevant once migration happens.
>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
>
> If Andre is fine with this, this is fine.
>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
>
> This is a generic bugfix. I will take this to next today.
>
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
>
> If Andre is fine with this, this is fine.

Well, is he? I thought he was. Can you check?

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4486 bytes --]

On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > [snip]
> > > > Again, back to this thread, if you want me to migrate things, consider
> > > > applying the sunxi patches as I have described above. I will then look
> > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > ask.
> > >
> > > I will take another look at what's still relevant. But I believe it's
> > > still blocked on the fact that it changes behavior and breaks users.
> >
> > In details:
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> >
> > Now that the underlying BLK problem is resolved, this can just be
> > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > when you're supporting a flow that lacks a BLK device entirely. This
> > would be another reminder as to why putting unrelated changes in a
> > series is a problem.
> 
> OK, then just don't apply this patch. Problem solved?

Well, for a hypothetical v6 you would not include it, sure.

> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> >
> > This is fine.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> >
> > This is not fine. This is also not a sunxi problem. It means that we
> > should drop bootmgr from rockchip, where the conversion has already
> > taken place, and would need to drop it from future conversion too.
> > Neither of which are desirable changes.
> 
> Why do you say that? I don't understand how this relates to rockchip
> or why we would need to drop bootmgr from that.

Then you don't have enough of a grasp of the details of the area you're
trying to solve problems in? Or maybe you need to refresh yourself on
the details of the area you're trying to work in.

> > This patch in particular is
> > where we have the note:
> >
> > "Yes, the introduction of boot standard changed the boot order and
> > specifically deprioritizing scripts is unexpected."
> >
> > Which should have had more attention than it did.
> 
> From memory the scripts are a fallback used when the other things
> don't work, so that was the decision I made at the time.

The key point being we changed behavior that others depended on, and
didn't document it well and didn't make sure the change would work for
them either.

> > This is the thread that to me spelled out in details where the
> > conversions are now blocked. We changed behavior and that in turn breaks
> > users that have come to rely on ordering.
> 
> I don't know what action to take on that comment. We cannot have 100%
> backwards compatibility with the scripts, which after all weren't even
> documented. But it is very close.

You need to get feedback from the people you want to migrate from the
scripts and ordering and rely on to something else and see what works
for them.

> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> >
> > Is an alternative to the above which then turned in to a discussion that
> > I would very briefly summarize as "no discussions were had between
> > stakeholders before integrating efi bootmgr with bootstd".
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> >
> > This is fine, but only relevant once migration happens.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> >
> > If Andre is fine with this, this is fine.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> >
> > This is a generic bugfix. I will take this to next today.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> >
> > If Andre is fine with this, this is fine.
> 
> Well, is he? I thought he was. Can you check?

You're free to. It's one of the innumerable examples of why when you
group multiple things in a series and there's problems with another part
of the series, unrelated changes get dropped.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > [snip]
> > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > applying the sunxi patches as I have described above. I will then look
> > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > ask.
> > > >
> > > > I will take another look at what's still relevant. But I believe it's
> > > > still blocked on the fact that it changes behavior and breaks users.
> > >
> > > In details:
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > >
> > > Now that the underlying BLK problem is resolved, this can just be
> > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > when you're supporting a flow that lacks a BLK device entirely. This
> > > would be another reminder as to why putting unrelated changes in a
> > > series is a problem.
> >
> > OK, then just don't apply this patch. Problem solved?
>
> Well, for a hypothetical v6 you would not include it, sure.
>
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > >
> > > This is fine.
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > >
> > > This is not fine. This is also not a sunxi problem. It means that we
> > > should drop bootmgr from rockchip, where the conversion has already
> > > taken place, and would need to drop it from future conversion too.
> > > Neither of which are desirable changes.
> >
> > Why do you say that? I don't understand how this relates to rockchip
> > or why we would need to drop bootmgr from that.
>
> Then you don't have enough of a grasp of the details of the area you're
> trying to solve problems in? Or maybe you need to refresh yourself on
> the details of the area you're trying to work in.

Or perhaps there isn't a problem? The sunxi case is special because we
have a FEL boothmeth. That isn't present on rockchip, for example.

>
> > > This patch in particular is
> > > where we have the note:
> > >
> > > "Yes, the introduction of boot standard changed the boot order and
> > > specifically deprioritizing scripts is unexpected."
> > >
> > > Which should have had more attention than it did.
> >
> > From memory the scripts are a fallback used when the other things
> > don't work, so that was the decision I made at the time.
>
> The key point being we changed behavior that others depended on, and
> didn't document it well and didn't make sure the change would work for
> them either.
>
> > > This is the thread that to me spelled out in details where the
> > > conversions are now blocked. We changed behavior and that in turn breaks
> > > users that have come to rely on ordering.
> >
> > I don't know what action to take on that comment. We cannot have 100%
> > backwards compatibility with the scripts, which after all weren't even
> > documented. But it is very close.
>
> You need to get feedback from the people you want to migrate from the
> scripts and ordering and rely on to something else and see what works
> for them.
>
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > >
> > > Is an alternative to the above which then turned in to a discussion that
> > > I would very briefly summarize as "no discussions were had between
> > > stakeholders before integrating efi bootmgr with bootstd".
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > >
> > > This is fine, but only relevant once migration happens.
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > >
> > > If Andre is fine with this, this is fine.
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > >
> > > This is a generic bugfix. I will take this to next today.
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > >
> > > If Andre is fine with this, this is fine.
> >
> > Well, is he? I thought he was. Can you check?
>
> You're free to. It's one of the innumerable examples of why when you
> group multiple things in a series and there's problems with another part
> of the series, unrelated changes get dropped.

It would be easier for me if you could apply the patches as I've suggested.

But if you are willing to apply these patches and just want me to send
the series again without the BLK and RFC patches, I can do that.
Please let me know either way.

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6155 bytes --]

On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > [snip]
> > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > ask.
> > > > >
> > > > > I will take another look at what's still relevant. But I believe it's
> > > > > still blocked on the fact that it changes behavior and breaks users.
> > > >
> > > > In details:
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > >
> > > > Now that the underlying BLK problem is resolved, this can just be
> > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > would be another reminder as to why putting unrelated changes in a
> > > > series is a problem.
> > >
> > > OK, then just don't apply this patch. Problem solved?
> >
> > Well, for a hypothetical v6 you would not include it, sure.
> >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > >
> > > > This is fine.
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > >
> > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > should drop bootmgr from rockchip, where the conversion has already
> > > > taken place, and would need to drop it from future conversion too.
> > > > Neither of which are desirable changes.
> > >
> > > Why do you say that? I don't understand how this relates to rockchip
> > > or why we would need to drop bootmgr from that.
> >
> > Then you don't have enough of a grasp of the details of the area you're
> > trying to solve problems in? Or maybe you need to refresh yourself on
> > the details of the area you're trying to work in.
> 
> Or perhaps there isn't a problem? The sunxi case is special because we
> have a FEL boothmeth. That isn't present on rockchip, for example.

Again, you seem to have forgotten what the problems with the series
were.

> > > > This patch in particular is
> > > > where we have the note:
> > > >
> > > > "Yes, the introduction of boot standard changed the boot order and
> > > > specifically deprioritizing scripts is unexpected."
> > > >
> > > > Which should have had more attention than it did.
> > >
> > > From memory the scripts are a fallback used when the other things
> > > don't work, so that was the decision I made at the time.
> >
> > The key point being we changed behavior that others depended on, and
> > didn't document it well and didn't make sure the change would work for
> > them either.
> >
> > > > This is the thread that to me spelled out in details where the
> > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > users that have come to rely on ordering.
> > >
> > > I don't know what action to take on that comment. We cannot have 100%
> > > backwards compatibility with the scripts, which after all weren't even
> > > documented. But it is very close.
> >
> > You need to get feedback from the people you want to migrate from the
> > scripts and ordering and rely on to something else and see what works
> > for them.
> >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > >
> > > > Is an alternative to the above which then turned in to a discussion that
> > > > I would very briefly summarize as "no discussions were had between
> > > > stakeholders before integrating efi bootmgr with bootstd".
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > >
> > > > This is fine, but only relevant once migration happens.
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > >
> > > > If Andre is fine with this, this is fine.
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > >
> > > > This is a generic bugfix. I will take this to next today.
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > >
> > > > If Andre is fine with this, this is fine.
> > >
> > > Well, is he? I thought he was. Can you check?
> >
> > You're free to. It's one of the innumerable examples of why when you
> > group multiple things in a series and there's problems with another part
> > of the series, unrelated changes get dropped.
> 
> It would be easier for me if you could apply the patches as I've suggested.
> 
> But if you are willing to apply these patches and just want me to send
> the series again without the BLK and RFC patches, I can do that.
> Please let me know either way.

Again, you should:
- Take the non-bootstd sunxi enhancements, rebase them to next and post
  for Andre. By themselves. This way they won't get stuck.
- You should work with Heinrich to come up with something that handles
  efi bootmanager and bootstd without breaking how our actual project
  users use us.
  There's no reason to migrate *more* platforms until we have this
  fundamental problem sorted out.
- You should work with any FOSS distributions to get their feedback on
  what would make their life easier, from a user of U-Boot perspective.
  bootstd won't be useful if it's not something our users want to use.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Mattijs Korpershoek]

On mar., avril 01, 2025 at 11:18, Tom Rini <trini@konsulko.com> wrote:

> On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
>> Hi Tom,
>> 
>> On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
>> >
>> > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
>> > > Hi Tom,
>> > >
>> > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
>> > > >
>> > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
>> > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
>> > > > [snip]
>> > > > > > Again, back to this thread, if you want me to migrate things, consider
>> > > > > > applying the sunxi patches as I have described above. I will then look
>> > > > > > at the next target for bootstd. But while you hold this up, I cannot
>> > > > > > move forward with more bootstd migration. It doesn't seem that much to
>> > > > > > ask.
>> > > > >
>> > > > > I will take another look at what's still relevant. But I believe it's
>> > > > > still blocked on the fact that it changes behavior and breaks users.
>> > > >
>> > > > In details:
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
>> > > >
>> > > > Now that the underlying BLK problem is resolved, this can just be
>> > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
>> > > > when you're supporting a flow that lacks a BLK device entirely. This
>> > > > would be another reminder as to why putting unrelated changes in a
>> > > > series is a problem.
>> > >
>> > > OK, then just don't apply this patch. Problem solved?
>> >
>> > Well, for a hypothetical v6 you would not include it, sure.
>> >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
>> > > >
>> > > > This is fine.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
>> > > >
>> > > > This is not fine. This is also not a sunxi problem. It means that we
>> > > > should drop bootmgr from rockchip, where the conversion has already
>> > > > taken place, and would need to drop it from future conversion too.
>> > > > Neither of which are desirable changes.
>> > >
>> > > Why do you say that? I don't understand how this relates to rockchip
>> > > or why we would need to drop bootmgr from that.
>> >
>> > Then you don't have enough of a grasp of the details of the area you're
>> > trying to solve problems in? Or maybe you need to refresh yourself on
>> > the details of the area you're trying to work in.
>> 
>> Or perhaps there isn't a problem? The sunxi case is special because we
>> have a FEL boothmeth. That isn't present on rockchip, for example.
>
> Again, you seem to have forgotten what the problems with the series
> were.
>
>> > > > This patch in particular is
>> > > > where we have the note:
>> > > >
>> > > > "Yes, the introduction of boot standard changed the boot order and
>> > > > specifically deprioritizing scripts is unexpected."
>> > > >
>> > > > Which should have had more attention than it did.
>> > >
>> > > From memory the scripts are a fallback used when the other things
>> > > don't work, so that was the decision I made at the time.
>> >
>> > The key point being we changed behavior that others depended on, and
>> > didn't document it well and didn't make sure the change would work for
>> > them either.
>> >
>> > > > This is the thread that to me spelled out in details where the
>> > > > conversions are now blocked. We changed behavior and that in turn breaks
>> > > > users that have come to rely on ordering.
>> > >
>> > > I don't know what action to take on that comment. We cannot have 100%
>> > > backwards compatibility with the scripts, which after all weren't even
>> > > documented. But it is very close.
>> >
>> > You need to get feedback from the people you want to migrate from the
>> > scripts and ordering and rely on to something else and see what works
>> > for them.
>> >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
>> > > >
>> > > > Is an alternative to the above which then turned in to a discussion that
>> > > > I would very briefly summarize as "no discussions were had between
>> > > > stakeholders before integrating efi bootmgr with bootstd".
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
>> > > >
>> > > > This is fine, but only relevant once migration happens.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
>> > > >
>> > > > If Andre is fine with this, this is fine.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
>> > > >
>> > > > This is a generic bugfix. I will take this to next today.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
>> > > >
>> > > > If Andre is fine with this, this is fine.
>> > >
>> > > Well, is he? I thought he was. Can you check?
>> >
>> > You're free to. It's one of the innumerable examples of why when you
>> > group multiple things in a series and there's problems with another part
>> > of the series, unrelated changes get dropped.
>> 
>> It would be easier for me if you could apply the patches as I've suggested.
>> 
>> But if you are willing to apply these patches and just want me to send
>> the series again without the BLK and RFC patches, I can do that.
>> Please let me know either way.
>
> Again, you should:
> - Take the non-bootstd sunxi enhancements, rebase them to next and post
>   for Andre. By themselves. This way they won't get stuck.
> - You should work with Heinrich to come up with something that handles
>   efi bootmanager and bootstd without breaking how our actual project
>   users use us.
>   There's no reason to migrate *more* platforms until we have this
>   fundamental problem sorted out.
> - You should work with any FOSS distributions to get their feedback on
>   what would make their life easier, from a user of U-Boot perspective.
>   bootstd won't be useful if it's not something our users want to use.

I can't speak for other distributions but for Android, it seems that the
direction is to use EFI boot via an excutable that implements the Android
bootflow. This is named GBL, and here are some pointers about it:
- https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/main/gbl/README.md
- https://lpc.events/event/18/contributions/1704/attachments/1550/3231/Android%20Generic%20Boot%20Loader.pdf
- https://baylibre.com/android-bootflow-experiments-with-u-boot-and-gbl/

So in my opinion, at least for Android, bootmeth_android (bootstd) will
be deprecated in favor of EFI boot + GBL.

>
> -- 
> Tom

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > [snip]
> > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > ask.
> > > > > >
> > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > >
> > > > > In details:
> > > > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > >
> > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > would be another reminder as to why putting unrelated changes in a
> > > > > series is a problem.
> > > >
> > > > OK, then just don't apply this patch. Problem solved?
> > >
> > > Well, for a hypothetical v6 you would not include it, sure.
> > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > >
> > > > > This is fine.
> > > > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > >
> > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > taken place, and would need to drop it from future conversion too.
> > > > > Neither of which are desirable changes.
> > > >
> > > > Why do you say that? I don't understand how this relates to rockchip
> > > > or why we would need to drop bootmgr from that.
> > >
> > > Then you don't have enough of a grasp of the details of the area you're
> > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > the details of the area you're trying to work in.
> >
> > Or perhaps there isn't a problem? The sunxi case is special because we
> > have a FEL boothmeth. That isn't present on rockchip, for example.
>
> Again, you seem to have forgotten what the problems with the series
> were.

No, it's just that we disagree on the path forward.

>
> > > > > This patch in particular is
> > > > > where we have the note:
> > > > >
> > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > specifically deprioritizing scripts is unexpected."
> > > > >
> > > > > Which should have had more attention than it did.
> > > >
> > > > From memory the scripts are a fallback used when the other things
> > > > don't work, so that was the decision I made at the time.
> > >
> > > The key point being we changed behavior that others depended on, and
> > > didn't document it well and didn't make sure the change would work for
> > > them either.
> > >
> > > > > This is the thread that to me spelled out in details where the
> > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > users that have come to rely on ordering.
> > > >
> > > > I don't know what action to take on that comment. We cannot have 100%
> > > > backwards compatibility with the scripts, which after all weren't even
> > > > documented. But it is very close.
> > >
> > > You need to get feedback from the people you want to migrate from the
> > > scripts and ordering and rely on to something else and see what works
> > > for them.
> > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > >
> > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > I would very briefly summarize as "no discussions were had between
> > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > >
> > > > > This is fine, but only relevant once migration happens.
> > > > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > >
> > > > > If Andre is fine with this, this is fine.
> > > > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > >
> > > > > This is a generic bugfix. I will take this to next today.
> > > > >
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > >
> > > > > If Andre is fine with this, this is fine.
> > > >
> > > > Well, is he? I thought he was. Can you check?
> > >
> > > You're free to. It's one of the innumerable examples of why when you
> > > group multiple things in a series and there's problems with another part
> > > of the series, unrelated changes get dropped.
> >
> > It would be easier for me if you could apply the patches as I've suggested.
> >
> > But if you are willing to apply these patches and just want me to send
> > the series again without the BLK and RFC patches, I can do that.
> > Please let me know either way.
>
> Again, you should:
> - Take the non-bootstd sunxi enhancements, rebase them to next and post
>   for Andre. By themselves. This way they won't get stuck.

There's no point, though, since it doesn't provide the bootstd migration.

> - You should work with Heinrich to come up with something that handles
>   efi bootmanager and bootstd without breaking how our actual project
>   users use us.
>   There's no reason to migrate *more* platforms until we have this
>   fundamental problem sorted out.

It isn't actually a fundamental problem at all. We shouldn't even be
discussing this and it is really unfortunate that you continue to
block this effort.

As to bootmgr, I would be willing to implement a solution here, but it
would involve changes to how bootmgr works under the hood, i.e. to
have it be iterative instead of doing everything at the start. My firm
understanding is that such changes would not be acceptable to
Ilias/Heinrich and anyway I am unable to get patches into the EFI
subsystem.

So the fallback is the work-around which Heinrich proposed. He is free
to implement that if he likes, but I am not planning to do this myself
as I see it as a short-term measure and it may cause problems for
bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
suppose they were happier days before everything froze up).

> - You should work with any FOSS distributions to get their feedback on
>   what would make their life easier, from a user of U-Boot perspective.
>   bootstd won't be useful if it's not something our users want to use.

Bootstd is designed to replace the distro scripts and the feedback I
have received is that it is good at that. If you have any other
feedback, or any suggestions on people I should contact, I'm happy to
approach them, or they can email the list and cc me.

But really, it would be a lot easier if you could just apply this
series so we can move on. If I can see even just a glimmer of
compromise here it will help my confidence.

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 9187 bytes --]

On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > [snip]
> > > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > > ask.
> > > > > > >
> > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > >
> > > > > > In details:
> > > > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > >
> > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > series is a problem.
> > > > >
> > > > > OK, then just don't apply this patch. Problem solved?
> > > >
> > > > Well, for a hypothetical v6 you would not include it, sure.
> > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > >
> > > > > > This is fine.
> > > > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > >
> > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > Neither of which are desirable changes.
> > > > >
> > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > or why we would need to drop bootmgr from that.
> > > >
> > > > Then you don't have enough of a grasp of the details of the area you're
> > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > the details of the area you're trying to work in.
> > >
> > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > have a FEL boothmeth. That isn't present on rockchip, for example.
> >
> > Again, you seem to have forgotten what the problems with the series
> > were.
> 
> No, it's just that we disagree on the path forward.

Then why did you bring up FEL? That's the part of the migration which is
NOT a problem, I keep being reminded when I ask.

> > > > > > This patch in particular is
> > > > > > where we have the note:
> > > > > >
> > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > specifically deprioritizing scripts is unexpected."
> > > > > >
> > > > > > Which should have had more attention than it did.
> > > > >
> > > > > From memory the scripts are a fallback used when the other things
> > > > > don't work, so that was the decision I made at the time.
> > > >
> > > > The key point being we changed behavior that others depended on, and
> > > > didn't document it well and didn't make sure the change would work for
> > > > them either.
> > > >
> > > > > > This is the thread that to me spelled out in details where the
> > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > users that have come to rely on ordering.
> > > > >
> > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > documented. But it is very close.
> > > >
> > > > You need to get feedback from the people you want to migrate from the
> > > > scripts and ordering and rely on to something else and see what works
> > > > for them.
> > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > >
> > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > >
> > > > > > This is fine, but only relevant once migration happens.
> > > > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > >
> > > > > > If Andre is fine with this, this is fine.
> > > > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > >
> > > > > > This is a generic bugfix. I will take this to next today.
> > > > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > >
> > > > > > If Andre is fine with this, this is fine.
> > > > >
> > > > > Well, is he? I thought he was. Can you check?
> > > >
> > > > You're free to. It's one of the innumerable examples of why when you
> > > > group multiple things in a series and there's problems with another part
> > > > of the series, unrelated changes get dropped.
> > >
> > > It would be easier for me if you could apply the patches as I've suggested.
> > >
> > > But if you are willing to apply these patches and just want me to send
> > > the series again without the BLK and RFC patches, I can do that.
> > > Please let me know either way.
> >
> > Again, you should:
> > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> >   for Andre. By themselves. This way they won't get stuck.
> 
> There's no point, though, since it doesn't provide the bootstd migration.

Are you saying there's no point in generally improving things if it
doesn't also involve one of your particular projects?

> > - You should work with Heinrich to come up with something that handles
> >   efi bootmanager and bootstd without breaking how our actual project
> >   users use us.
> >   There's no reason to migrate *more* platforms until we have this
> >   fundamental problem sorted out.
> 
> It isn't actually a fundamental problem at all. We shouldn't even be
> discussing this and it is really unfortunate that you continue to
> block this effort.
> 
> As to bootmgr, I would be willing to implement a solution here, but it
> would involve changes to how bootmgr works under the hood, i.e. to
> have it be iterative instead of doing everything at the start. My firm
> understanding is that such changes would not be acceptable to
> Ilias/Heinrich and anyway I am unable to get patches into the EFI
> subsystem.
> 
> So the fallback is the work-around which Heinrich proposed. He is free
> to implement that if he likes, but I am not planning to do this myself
> as I see it as a short-term measure and it may cause problems for
> bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> suppose they were happier days before everything froze up).
> 
> > - You should work with any FOSS distributions to get their feedback on
> >   what would make their life easier, from a user of U-Boot perspective.
> >   bootstd won't be useful if it's not something our users want to use.
> 
> Bootstd is designed to replace the distro scripts and the feedback I
> have received is that it is good at that. If you have any other
> feedback, or any suggestions on people I should contact, I'm happy to
> approach them, or they can email the list and cc me.
> 
> But really, it would be a lot easier if you could just apply this
> series so we can move on. If I can see even just a glimmer of
> compromise here it will help my confidence.

Your sunxi series is broken as posted. I am not interested in applying
or encouraging more bootstd usage until there's actual work being done
to move forward wit bootstd (a thing you want) and EFI (a thing most
distributions want). That would be some of the general feedback you've
been given and missed or forgotten.

This is even setting aside that I can't recall now if you ever started
on making non-BOOTSTD_FULL more useful / usable in general because it's
so minimal that every conversion ends up also enabling BOOTSTD_FULL in
order to be flexible enough for users to decide SD vs eMMC and so on.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Thu, 3 Apr 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > > [snip]
> > > > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > > > ask.
> > > > > > > >
> > > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > > >
> > > > > > > In details:
> > > > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > > >
> > > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > > series is a problem.
> > > > > >
> > > > > > OK, then just don't apply this patch. Problem solved?
> > > > >
> > > > > Well, for a hypothetical v6 you would not include it, sure.
> > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > > >
> > > > > > > This is fine.
> > > > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > > >
> > > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > > Neither of which are desirable changes.
> > > > > >
> > > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > > or why we would need to drop bootmgr from that.
> > > > >
> > > > > Then you don't have enough of a grasp of the details of the area you're
> > > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > > the details of the area you're trying to work in.
> > > >
> > > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > > have a FEL boothmeth. That isn't present on rockchip, for example.
> > >
> > > Again, you seem to have forgotten what the problems with the series
> > > were.
> >
> > No, it's just that we disagree on the path forward.
>
> Then why did you bring up FEL? That's the part of the migration which is
> NOT a problem, I keep being reminded when I ask.

FEL needs to get priority, that's all. It was a problem until I
adjusted the priority.

>
> > > > > > > This patch in particular is
> > > > > > > where we have the note:
> > > > > > >
> > > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > > specifically deprioritizing scripts is unexpected."
> > > > > > >
> > > > > > > Which should have had more attention than it did.
> > > > > >
> > > > > > From memory the scripts are a fallback used when the other things
> > > > > > don't work, so that was the decision I made at the time.
> > > > >
> > > > > The key point being we changed behavior that others depended on, and
> > > > > didn't document it well and didn't make sure the change would work for
> > > > > them either.
> > > > >
> > > > > > > This is the thread that to me spelled out in details where the
> > > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > > users that have come to rely on ordering.
> > > > > >
> > > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > > documented. But it is very close.
> > > > >
> > > > > You need to get feedback from the people you want to migrate from the
> > > > > scripts and ordering and rely on to something else and see what works
> > > > > for them.
> > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > > >
> > > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > > >
> > > > > > > This is fine, but only relevant once migration happens.
> > > > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > > >
> > > > > > > If Andre is fine with this, this is fine.
> > > > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > > >
> > > > > > > This is a generic bugfix. I will take this to next today.
> > > > > > >
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > > >
> > > > > > > If Andre is fine with this, this is fine.
> > > > > >
> > > > > > Well, is he? I thought he was. Can you check?
> > > > >
> > > > > You're free to. It's one of the innumerable examples of why when you
> > > > > group multiple things in a series and there's problems with another part
> > > > > of the series, unrelated changes get dropped.
> > > >
> > > > It would be easier for me if you could apply the patches as I've suggested.
> > > >
> > > > But if you are willing to apply these patches and just want me to send
> > > > the series again without the BLK and RFC patches, I can do that.
> > > > Please let me know either way.
> > >
> > > Again, you should:
> > > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> > >   for Andre. By themselves. This way they won't get stuck.
> >
> > There's no point, though, since it doesn't provide the bootstd migration.
>
> Are you saying there's no point in generally improving things if it
> doesn't also involve one of your particular projects?

The series is called 'bootstd: sunxi: Migrate to standard boot'. If
you'd like to apply just the patches from that series which don't
migrate sunxi to standard boot, please go ahead.

>
> > > - You should work with Heinrich to come up with something that handles
> > >   efi bootmanager and bootstd without breaking how our actual project
> > >   users use us.
> > >   There's no reason to migrate *more* platforms until we have this
> > >   fundamental problem sorted out.
> >
> > It isn't actually a fundamental problem at all. We shouldn't even be
> > discussing this and it is really unfortunate that you continue to
> > block this effort.
> >
> > As to bootmgr, I would be willing to implement a solution here, but it
> > would involve changes to how bootmgr works under the hood, i.e. to
> > have it be iterative instead of doing everything at the start. My firm
> > understanding is that such changes would not be acceptable to
> > Ilias/Heinrich and anyway I am unable to get patches into the EFI
> > subsystem.
> >
> > So the fallback is the work-around which Heinrich proposed. He is free
> > to implement that if he likes, but I am not planning to do this myself
> > as I see it as a short-term measure and it may cause problems for
> > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> > suppose they were happier days before everything froze up).
> >
> > > - You should work with any FOSS distributions to get their feedback on
> > >   what would make their life easier, from a user of U-Boot perspective.
> > >   bootstd won't be useful if it's not something our users want to use.
> >
> > Bootstd is designed to replace the distro scripts and the feedback I
> > have received is that it is good at that. If you have any other
> > feedback, or any suggestions on people I should contact, I'm happy to
> > approach them, or they can email the list and cc me.
> >
> > But really, it would be a lot easier if you could just apply this
> > series so we can move on. If I can see even just a glimmer of
> > compromise here it will help my confidence.
>
> Your sunxi series is broken as posted. I am not interested in applying
> or encouraging more bootstd usage until there's actual work being done
> to move forward wit bootstd (a thing you want) and EFI (a thing most
> distributions want). That would be some of the general feedback you've
> been given and missed or forgotten.
>
> This is even setting aside that I can't recall now if you ever started
> on making non-BOOTSTD_FULL more useful / usable in general because it's
> so minimal that every conversion ends up also enabling BOOTSTD_FULL in
> order to be flexible enough for users to decide SD vs eMMC and so on.

You can hold this up for as long as you like, it's your tree.

I'm always happy and willing to discuss and commit to future
improvements. The pattern I see, well-established now, is that you
block my current improvements until some other things are done (this
series, PXE and many others). Or sometimes you see my series, come up
with a clean-up and block my series until it is based on top of that.
If you could move away from that pattern and operate in a more
cooperative manner, we could definitely get a lot more done in your
tree.

But again, you can hold this up as long as you like. I just feel it
would be better for the project if you didn't.

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 12016 bytes --]

On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 3 Apr 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > > > [snip]
> > > > > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > > > > ask.
> > > > > > > > >
> > > > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > > > >
> > > > > > > > In details:
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > > > >
> > > > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > > > series is a problem.
> > > > > > >
> > > > > > > OK, then just don't apply this patch. Problem solved?
> > > > > >
> > > > > > Well, for a hypothetical v6 you would not include it, sure.
> > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > > > >
> > > > > > > > This is fine.
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > > > >
> > > > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > > > Neither of which are desirable changes.
> > > > > > >
> > > > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > > > or why we would need to drop bootmgr from that.
> > > > > >
> > > > > > Then you don't have enough of a grasp of the details of the area you're
> > > > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > > > the details of the area you're trying to work in.
> > > > >
> > > > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > > > have a FEL boothmeth. That isn't present on rockchip, for example.
> > > >
> > > > Again, you seem to have forgotten what the problems with the series
> > > > were.
> > >
> > > No, it's just that we disagree on the path forward.
> >
> > Then why did you bring up FEL? That's the part of the migration which is
> > NOT a problem, I keep being reminded when I ask.
> 
> FEL needs to get priority, that's all. It was a problem until I
> adjusted the priority.

And there's been zero objection to this. So why are you mentioning it
here, in the discussion on why the migration is blocked. I know I had
been unsure, but I asked, and people answered, and I accepted the
answer.

> > > > > > > > This patch in particular is
> > > > > > > > where we have the note:
> > > > > > > >
> > > > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > > > specifically deprioritizing scripts is unexpected."
> > > > > > > >
> > > > > > > > Which should have had more attention than it did.
> > > > > > >
> > > > > > > From memory the scripts are a fallback used when the other things
> > > > > > > don't work, so that was the decision I made at the time.
> > > > > >
> > > > > > The key point being we changed behavior that others depended on, and
> > > > > > didn't document it well and didn't make sure the change would work for
> > > > > > them either.
> > > > > >
> > > > > > > > This is the thread that to me spelled out in details where the
> > > > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > > > users that have come to rely on ordering.
> > > > > > >
> > > > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > > > documented. But it is very close.
> > > > > >
> > > > > > You need to get feedback from the people you want to migrate from the
> > > > > > scripts and ordering and rely on to something else and see what works
> > > > > > for them.
> > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > > > >
> > > > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > > > >
> > > > > > > > This is fine, but only relevant once migration happens.
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > > > >
> > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > > > >
> > > > > > > > This is a generic bugfix. I will take this to next today.
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > > > >
> > > > > > > > If Andre is fine with this, this is fine.
> > > > > > >
> > > > > > > Well, is he? I thought he was. Can you check?
> > > > > >
> > > > > > You're free to. It's one of the innumerable examples of why when you
> > > > > > group multiple things in a series and there's problems with another part
> > > > > > of the series, unrelated changes get dropped.
> > > > >
> > > > > It would be easier for me if you could apply the patches as I've suggested.
> > > > >
> > > > > But if you are willing to apply these patches and just want me to send
> > > > > the series again without the BLK and RFC patches, I can do that.
> > > > > Please let me know either way.
> > > >
> > > > Again, you should:
> > > > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> > > >   for Andre. By themselves. This way they won't get stuck.
> > >
> > > There's no point, though, since it doesn't provide the bootstd migration.
> >
> > Are you saying there's no point in generally improving things if it
> > doesn't also involve one of your particular projects?
> 
> The series is called 'bootstd: sunxi: Migrate to standard boot'. If
> you'd like to apply just the patches from that series which don't
> migrate sunxi to standard boot, please go ahead.

I'm not the sunxi custodian. General sunxi changes would go through that
tree. And then a repeat of everything I've said about how bundling
unrelated changes hurts everyone.

> > > > - You should work with Heinrich to come up with something that handles
> > > >   efi bootmanager and bootstd without breaking how our actual project
> > > >   users use us.
> > > >   There's no reason to migrate *more* platforms until we have this
> > > >   fundamental problem sorted out.
> > >
> > > It isn't actually a fundamental problem at all. We shouldn't even be
> > > discussing this and it is really unfortunate that you continue to
> > > block this effort.
> > >
> > > As to bootmgr, I would be willing to implement a solution here, but it
> > > would involve changes to how bootmgr works under the hood, i.e. to
> > > have it be iterative instead of doing everything at the start. My firm
> > > understanding is that such changes would not be acceptable to
> > > Ilias/Heinrich and anyway I am unable to get patches into the EFI
> > > subsystem.
> > >
> > > So the fallback is the work-around which Heinrich proposed. He is free
> > > to implement that if he likes, but I am not planning to do this myself
> > > as I see it as a short-term measure and it may cause problems for
> > > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> > > suppose they were happier days before everything froze up).
> > >
> > > > - You should work with any FOSS distributions to get their feedback on
> > > >   what would make their life easier, from a user of U-Boot perspective.
> > > >   bootstd won't be useful if it's not something our users want to use.
> > >
> > > Bootstd is designed to replace the distro scripts and the feedback I
> > > have received is that it is good at that. If you have any other
> > > feedback, or any suggestions on people I should contact, I'm happy to
> > > approach them, or they can email the list and cc me.
> > >
> > > But really, it would be a lot easier if you could just apply this
> > > series so we can move on. If I can see even just a glimmer of
> > > compromise here it will help my confidence.
> >
> > Your sunxi series is broken as posted. I am not interested in applying
> > or encouraging more bootstd usage until there's actual work being done
> > to move forward wit bootstd (a thing you want) and EFI (a thing most
> > distributions want). That would be some of the general feedback you've
> > been given and missed or forgotten.
> >
> > This is even setting aside that I can't recall now if you ever started
> > on making non-BOOTSTD_FULL more useful / usable in general because it's
> > so minimal that every conversion ends up also enabling BOOTSTD_FULL in
> > order to be flexible enough for users to decide SD vs eMMC and so on.
> 
> You can hold this up for as long as you like, it's your tree.

And you can do whatever you like in your personal tree, sure. But
there's rules for working in a community project.

> I'm always happy and willing to discuss and commit to future
> improvements. The pattern I see, well-established now, is that you
> block my current improvements until some other things are done (this
> series, PXE and many others). Or sometimes you see my series, come up
> with a clean-up and block my series until it is based on top of that.
> If you could move away from that pattern and operate in a more
> cooperative manner, we could definitely get a lot more done in your
> tree.
> 
> But again, you can hold this up as long as you like. I just feel it
> would be better for the project if you didn't.

I continue to not accept changes from anyone that knowingly break other
use cases and users. You are not an exception to the rule. Leaving
things broken for now and improving them later is not an option in
mainline.

And I ask everyone to fix problems that are exposed when they're doing
something else. Sometimes, when it comes to Kconfig symbols I'll end up
doing the cleanup because it's tricky to get things right for 1300
platforms.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Fri, 4 Apr 2025 at 03:27, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 3 Apr 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > > > > [snip]
> > > > > > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > > > > > ask.
> > > > > > > > > >
> > > > > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > > > > >
> > > > > > > > > In details:
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > > > > series is a problem.
> > > > > > > >
> > > > > > > > OK, then just don't apply this patch. Problem solved?
> > > > > > >
> > > > > > > Well, for a hypothetical v6 you would not include it, sure.
> > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is fine.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > > > > Neither of which are desirable changes.
> > > > > > > >
> > > > > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > > > > or why we would need to drop bootmgr from that.
> > > > > > >
> > > > > > > Then you don't have enough of a grasp of the details of the area you're
> > > > > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > > > > the details of the area you're trying to work in.
> > > > > >
> > > > > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > > > > have a FEL boothmeth. That isn't present on rockchip, for example.
> > > > >
> > > > > Again, you seem to have forgotten what the problems with the series
> > > > > were.
> > > >
> > > > No, it's just that we disagree on the path forward.
> > >
> > > Then why did you bring up FEL? That's the part of the migration which is
> > > NOT a problem, I keep being reminded when I ask.
> >
> > FEL needs to get priority, that's all. It was a problem until I
> > adjusted the priority.
>
> And there's been zero objection to this. So why are you mentioning it
> here, in the discussion on why the migration is blocked. I know I had
> been unsure, but I asked, and people answered, and I accepted the
> answer.
>
> > > > > > > > > This patch in particular is
> > > > > > > > > where we have the note:
> > > > > > > > >
> > > > > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > > > > specifically deprioritizing scripts is unexpected."
> > > > > > > > >
> > > > > > > > > Which should have had more attention than it did.
> > > > > > > >
> > > > > > > > From memory the scripts are a fallback used when the other things
> > > > > > > > don't work, so that was the decision I made at the time.
> > > > > > >
> > > > > > > The key point being we changed behavior that others depended on, and
> > > > > > > didn't document it well and didn't make sure the change would work for
> > > > > > > them either.
> > > > > > >
> > > > > > > > > This is the thread that to me spelled out in details where the
> > > > > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > > > > users that have come to rely on ordering.
> > > > > > > >
> > > > > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > > > > documented. But it is very close.
> > > > > > >
> > > > > > > You need to get feedback from the people you want to migrate from the
> > > > > > > scripts and ordering and rely on to something else and see what works
> > > > > > > for them.
> > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is fine, but only relevant once migration happens.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is a generic bugfix. I will take this to next today.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > >
> > > > > > > > Well, is he? I thought he was. Can you check?
> > > > > > >
> > > > > > > You're free to. It's one of the innumerable examples of why when you
> > > > > > > group multiple things in a series and there's problems with another part
> > > > > > > of the series, unrelated changes get dropped.
> > > > > >
> > > > > > It would be easier for me if you could apply the patches as I've suggested.
> > > > > >
> > > > > > But if you are willing to apply these patches and just want me to send
> > > > > > the series again without the BLK and RFC patches, I can do that.
> > > > > > Please let me know either way.
> > > > >
> > > > > Again, you should:
> > > > > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> > > > >   for Andre. By themselves. This way they won't get stuck.
> > > >
> > > > There's no point, though, since it doesn't provide the bootstd migration.
> > >
> > > Are you saying there's no point in generally improving things if it
> > > doesn't also involve one of your particular projects?
> >
> > The series is called 'bootstd: sunxi: Migrate to standard boot'. If
> > you'd like to apply just the patches from that series which don't
> > migrate sunxi to standard boot, please go ahead.
>
> I'm not the sunxi custodian. General sunxi changes would go through that
> tree. And then a repeat of everything I've said about how bundling
> unrelated changes hurts everyone.
>
> > > > > - You should work with Heinrich to come up with something that handles
> > > > >   efi bootmanager and bootstd without breaking how our actual project
> > > > >   users use us.
> > > > >   There's no reason to migrate *more* platforms until we have this
> > > > >   fundamental problem sorted out.
> > > >
> > > > It isn't actually a fundamental problem at all. We shouldn't even be
> > > > discussing this and it is really unfortunate that you continue to
> > > > block this effort.
> > > >
> > > > As to bootmgr, I would be willing to implement a solution here, but it
> > > > would involve changes to how bootmgr works under the hood, i.e. to
> > > > have it be iterative instead of doing everything at the start. My firm
> > > > understanding is that such changes would not be acceptable to
> > > > Ilias/Heinrich and anyway I am unable to get patches into the EFI
> > > > subsystem.
> > > >
> > > > So the fallback is the work-around which Heinrich proposed. He is free
> > > > to implement that if he likes, but I am not planning to do this myself
> > > > as I see it as a short-term measure and it may cause problems for
> > > > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> > > > suppose they were happier days before everything froze up).
> > > >
> > > > > - You should work with any FOSS distributions to get their feedback on
> > > > >   what would make their life easier, from a user of U-Boot perspective.
> > > > >   bootstd won't be useful if it's not something our users want to use.
> > > >
> > > > Bootstd is designed to replace the distro scripts and the feedback I
> > > > have received is that it is good at that. If you have any other
> > > > feedback, or any suggestions on people I should contact, I'm happy to
> > > > approach them, or they can email the list and cc me.
> > > >
> > > > But really, it would be a lot easier if you could just apply this
> > > > series so we can move on. If I can see even just a glimmer of
> > > > compromise here it will help my confidence.
> > >
> > > Your sunxi series is broken as posted. I am not interested in applying
> > > or encouraging more bootstd usage until there's actual work being done
> > > to move forward wit bootstd (a thing you want) and EFI (a thing most
> > > distributions want). That would be some of the general feedback you've
> > > been given and missed or forgotten.
> > >
> > > This is even setting aside that I can't recall now if you ever started
> > > on making non-BOOTSTD_FULL more useful / usable in general because it's
> > > so minimal that every conversion ends up also enabling BOOTSTD_FULL in
> > > order to be flexible enough for users to decide SD vs eMMC and so on.
> >
> > You can hold this up for as long as you like, it's your tree.
>
> And you can do whatever you like in your personal tree, sure. But
> there's rules for working in a community project.
>
> > I'm always happy and willing to discuss and commit to future
> > improvements. The pattern I see, well-established now, is that you
> > block my current improvements until some other things are done (this
> > series, PXE and many others). Or sometimes you see my series, come up
> > with a clean-up and block my series until it is based on top of that.
> > If you could move away from that pattern and operate in a more
> > cooperative manner, we could definitely get a lot more done in your
> > tree.
> >
> > But again, you can hold this up as long as you like. I just feel it
> > would be better for the project if you didn't.
>
> I continue to not accept changes from anyone that knowingly break other
> use cases and users. You are not an exception to the rule. Leaving
> things broken for now and improving them later is not an option in
> mainline.

If that is your justification for blocking progress then it won't work
in this case. There is nothing actually broken with my series. Shall I
send it again so you can take another look?

>
> And I ask everyone to fix problems that are exposed when they're doing
> something else. Sometimes, when it comes to Kconfig symbols I'll end up
> doing the cleanup because it's tricky to get things right for 1300
> platforms.

Yes, I know how you feel.

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 13876 bytes --]

On Mon, Apr 07, 2025 at 09:15:42AM +1200, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 4 Apr 2025 at 03:27, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 3 Apr 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > > > > > [snip]
> > > > > > > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > > > > > > ask.
> > > > > > > > > > >
> > > > > > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > > > > > >
> > > > > > > > > > In details:
> > > > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > > > > > series is a problem.
> > > > > > > > >
> > > > > > > > > OK, then just don't apply this patch. Problem solved?
> > > > > > > >
> > > > > > > > Well, for a hypothetical v6 you would not include it, sure.
> > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > This is fine.
> > > > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > > > > > Neither of which are desirable changes.
> > > > > > > > >
> > > > > > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > > > > > or why we would need to drop bootmgr from that.
> > > > > > > >
> > > > > > > > Then you don't have enough of a grasp of the details of the area you're
> > > > > > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > > > > > the details of the area you're trying to work in.
> > > > > > >
> > > > > > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > > > > > have a FEL boothmeth. That isn't present on rockchip, for example.
> > > > > >
> > > > > > Again, you seem to have forgotten what the problems with the series
> > > > > > were.
> > > > >
> > > > > No, it's just that we disagree on the path forward.
> > > >
> > > > Then why did you bring up FEL? That's the part of the migration which is
> > > > NOT a problem, I keep being reminded when I ask.
> > >
> > > FEL needs to get priority, that's all. It was a problem until I
> > > adjusted the priority.
> >
> > And there's been zero objection to this. So why are you mentioning it
> > here, in the discussion on why the migration is blocked. I know I had
> > been unsure, but I asked, and people answered, and I accepted the
> > answer.
> >
> > > > > > > > > > This patch in particular is
> > > > > > > > > > where we have the note:
> > > > > > > > > >
> > > > > > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > > > > > specifically deprioritizing scripts is unexpected."
> > > > > > > > > >
> > > > > > > > > > Which should have had more attention than it did.
> > > > > > > > >
> > > > > > > > > From memory the scripts are a fallback used when the other things
> > > > > > > > > don't work, so that was the decision I made at the time.
> > > > > > > >
> > > > > > > > The key point being we changed behavior that others depended on, and
> > > > > > > > didn't document it well and didn't make sure the change would work for
> > > > > > > > them either.
> > > > > > > >
> > > > > > > > > > This is the thread that to me spelled out in details where the
> > > > > > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > > > > > users that have come to rely on ordering.
> > > > > > > > >
> > > > > > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > > > > > documented. But it is very close.
> > > > > > > >
> > > > > > > > You need to get feedback from the people you want to migrate from the
> > > > > > > > scripts and ordering and rely on to something else and see what works
> > > > > > > > for them.
> > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > This is fine, but only relevant once migration happens.
> > > > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > This is a generic bugfix. I will take this to next today.
> > > > > > > > > >
> > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > > > > > >
> > > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > >
> > > > > > > > > Well, is he? I thought he was. Can you check?
> > > > > > > >
> > > > > > > > You're free to. It's one of the innumerable examples of why when you
> > > > > > > > group multiple things in a series and there's problems with another part
> > > > > > > > of the series, unrelated changes get dropped.
> > > > > > >
> > > > > > > It would be easier for me if you could apply the patches as I've suggested.
> > > > > > >
> > > > > > > But if you are willing to apply these patches and just want me to send
> > > > > > > the series again without the BLK and RFC patches, I can do that.
> > > > > > > Please let me know either way.
> > > > > >
> > > > > > Again, you should:
> > > > > > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> > > > > >   for Andre. By themselves. This way they won't get stuck.
> > > > >
> > > > > There's no point, though, since it doesn't provide the bootstd migration.
> > > >
> > > > Are you saying there's no point in generally improving things if it
> > > > doesn't also involve one of your particular projects?
> > >
> > > The series is called 'bootstd: sunxi: Migrate to standard boot'. If
> > > you'd like to apply just the patches from that series which don't
> > > migrate sunxi to standard boot, please go ahead.
> >
> > I'm not the sunxi custodian. General sunxi changes would go through that
> > tree. And then a repeat of everything I've said about how bundling
> > unrelated changes hurts everyone.
> >
> > > > > > - You should work with Heinrich to come up with something that handles
> > > > > >   efi bootmanager and bootstd without breaking how our actual project
> > > > > >   users use us.
> > > > > >   There's no reason to migrate *more* platforms until we have this
> > > > > >   fundamental problem sorted out.
> > > > >
> > > > > It isn't actually a fundamental problem at all. We shouldn't even be
> > > > > discussing this and it is really unfortunate that you continue to
> > > > > block this effort.
> > > > >
> > > > > As to bootmgr, I would be willing to implement a solution here, but it
> > > > > would involve changes to how bootmgr works under the hood, i.e. to
> > > > > have it be iterative instead of doing everything at the start. My firm
> > > > > understanding is that such changes would not be acceptable to
> > > > > Ilias/Heinrich and anyway I am unable to get patches into the EFI
> > > > > subsystem.
> > > > >
> > > > > So the fallback is the work-around which Heinrich proposed. He is free
> > > > > to implement that if he likes, but I am not planning to do this myself
> > > > > as I see it as a short-term measure and it may cause problems for
> > > > > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> > > > > suppose they were happier days before everything froze up).
> > > > >
> > > > > > - You should work with any FOSS distributions to get their feedback on
> > > > > >   what would make their life easier, from a user of U-Boot perspective.
> > > > > >   bootstd won't be useful if it's not something our users want to use.
> > > > >
> > > > > Bootstd is designed to replace the distro scripts and the feedback I
> > > > > have received is that it is good at that. If you have any other
> > > > > feedback, or any suggestions on people I should contact, I'm happy to
> > > > > approach them, or they can email the list and cc me.
> > > > >
> > > > > But really, it would be a lot easier if you could just apply this
> > > > > series so we can move on. If I can see even just a glimmer of
> > > > > compromise here it will help my confidence.
> > > >
> > > > Your sunxi series is broken as posted. I am not interested in applying
> > > > or encouraging more bootstd usage until there's actual work being done
> > > > to move forward wit bootstd (a thing you want) and EFI (a thing most
> > > > distributions want). That would be some of the general feedback you've
> > > > been given and missed or forgotten.
> > > >
> > > > This is even setting aside that I can't recall now if you ever started
> > > > on making non-BOOTSTD_FULL more useful / usable in general because it's
> > > > so minimal that every conversion ends up also enabling BOOTSTD_FULL in
> > > > order to be flexible enough for users to decide SD vs eMMC and so on.
> > >
> > > You can hold this up for as long as you like, it's your tree.
> >
> > And you can do whatever you like in your personal tree, sure. But
> > there's rules for working in a community project.
> >
> > > I'm always happy and willing to discuss and commit to future
> > > improvements. The pattern I see, well-established now, is that you
> > > block my current improvements until some other things are done (this
> > > series, PXE and many others). Or sometimes you see my series, come up
> > > with a clean-up and block my series until it is based on top of that.
> > > If you could move away from that pattern and operate in a more
> > > cooperative manner, we could definitely get a lot more done in your
> > > tree.
> > >
> > > But again, you can hold this up as long as you like. I just feel it
> > > would be better for the project if you didn't.
> >
> > I continue to not accept changes from anyone that knowingly break other
> > use cases and users. You are not an exception to the rule. Leaving
> > things broken for now and improving them later is not an option in
> > mainline.
> 
> If that is your justification for blocking progress then it won't work
> in this case. There is nothing actually broken with my series. Shall I
> send it again so you can take another look?

Well, again, your series includes "Pick one of these two NAK'd patches
to continue". So no, you probably shouldn't.

> > And I ask everyone to fix problems that are exposed when they're doing
> > something else. Sometimes, when it comes to Kconfig symbols I'll end up
> > doing the cleanup because it's tricky to get things right for 1300
> > platforms.
> 
> Yes, I know how you feel.

So are you engaging in some sort of tit-for-tat now? I honestly do not
understand why you're not either:
- Stopping with the things people have told you to stop doing.
- Continuing with your own downstream fork for fun.

Your "lets try having two trees" idea is not working and must stop. You
must decide if you are going to set aside concepts that have been
rejected or properly fork (and give the community the domain name).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Mon, 7 Apr 2025 at 10:53, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Apr 07, 2025 at 09:15:42AM +1200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 4 Apr 2025 at 03:27, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 3 Apr 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > > > > > > [snip]
> > > > > > > > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > > > > > > > ask.
> > > > > > > > > > > >
> > > > > > > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > > > > > > >
> > > > > > > > > > > In details:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > > > > > > series is a problem.
> > > > > > > > > >
> > > > > > > > > > OK, then just don't apply this patch. Problem solved?
> > > > > > > > >
> > > > > > > > > Well, for a hypothetical v6 you would not include it, sure.
> > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > This is fine.
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > > > > > > Neither of which are desirable changes.
> > > > > > > > > >
> > > > > > > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > > > > > > or why we would need to drop bootmgr from that.
> > > > > > > > >
> > > > > > > > > Then you don't have enough of a grasp of the details of the area you're
> > > > > > > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > > > > > > the details of the area you're trying to work in.
> > > > > > > >
> > > > > > > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > > > > > > have a FEL boothmeth. That isn't present on rockchip, for example.
> > > > > > >
> > > > > > > Again, you seem to have forgotten what the problems with the series
> > > > > > > were.
> > > > > >
> > > > > > No, it's just that we disagree on the path forward.
> > > > >
> > > > > Then why did you bring up FEL? That's the part of the migration which is
> > > > > NOT a problem, I keep being reminded when I ask.
> > > >
> > > > FEL needs to get priority, that's all. It was a problem until I
> > > > adjusted the priority.
> > >
> > > And there's been zero objection to this. So why are you mentioning it
> > > here, in the discussion on why the migration is blocked. I know I had
> > > been unsure, but I asked, and people answered, and I accepted the
> > > answer.
> > >
> > > > > > > > > > > This patch in particular is
> > > > > > > > > > > where we have the note:
> > > > > > > > > > >
> > > > > > > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > > > > > > specifically deprioritizing scripts is unexpected."
> > > > > > > > > > >
> > > > > > > > > > > Which should have had more attention than it did.
> > > > > > > > > >
> > > > > > > > > > From memory the scripts are a fallback used when the other things
> > > > > > > > > > don't work, so that was the decision I made at the time.
> > > > > > > > >
> > > > > > > > > The key point being we changed behavior that others depended on, and
> > > > > > > > > didn't document it well and didn't make sure the change would work for
> > > > > > > > > them either.
> > > > > > > > >
> > > > > > > > > > > This is the thread that to me spelled out in details where the
> > > > > > > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > > > > > > users that have come to rely on ordering.
> > > > > > > > > >
> > > > > > > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > > > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > > > > > > documented. But it is very close.
> > > > > > > > >
> > > > > > > > > You need to get feedback from the people you want to migrate from the
> > > > > > > > > scripts and ordering and rely on to something else and see what works
> > > > > > > > > for them.
> > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > This is fine, but only relevant once migration happens.
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > This is a generic bugfix. I will take this to next today.
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > > > > > > >
> > > > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > > >
> > > > > > > > > > Well, is he? I thought he was. Can you check?
> > > > > > > > >
> > > > > > > > > You're free to. It's one of the innumerable examples of why when you
> > > > > > > > > group multiple things in a series and there's problems with another part
> > > > > > > > > of the series, unrelated changes get dropped.
> > > > > > > >
> > > > > > > > It would be easier for me if you could apply the patches as I've suggested.
> > > > > > > >
> > > > > > > > But if you are willing to apply these patches and just want me to send
> > > > > > > > the series again without the BLK and RFC patches, I can do that.
> > > > > > > > Please let me know either way.
> > > > > > >
> > > > > > > Again, you should:
> > > > > > > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> > > > > > >   for Andre. By themselves. This way they won't get stuck.
> > > > > >
> > > > > > There's no point, though, since it doesn't provide the bootstd migration.
> > > > >
> > > > > Are you saying there's no point in generally improving things if it
> > > > > doesn't also involve one of your particular projects?
> > > >
> > > > The series is called 'bootstd: sunxi: Migrate to standard boot'. If
> > > > you'd like to apply just the patches from that series which don't
> > > > migrate sunxi to standard boot, please go ahead.
> > >
> > > I'm not the sunxi custodian. General sunxi changes would go through that
> > > tree. And then a repeat of everything I've said about how bundling
> > > unrelated changes hurts everyone.
> > >
> > > > > > > - You should work with Heinrich to come up with something that handles
> > > > > > >   efi bootmanager and bootstd without breaking how our actual project
> > > > > > >   users use us.
> > > > > > >   There's no reason to migrate *more* platforms until we have this
> > > > > > >   fundamental problem sorted out.
> > > > > >
> > > > > > It isn't actually a fundamental problem at all. We shouldn't even be
> > > > > > discussing this and it is really unfortunate that you continue to
> > > > > > block this effort.
> > > > > >
> > > > > > As to bootmgr, I would be willing to implement a solution here, but it
> > > > > > would involve changes to how bootmgr works under the hood, i.e. to
> > > > > > have it be iterative instead of doing everything at the start. My firm
> > > > > > understanding is that such changes would not be acceptable to
> > > > > > Ilias/Heinrich and anyway I am unable to get patches into the EFI
> > > > > > subsystem.
> > > > > >
> > > > > > So the fallback is the work-around which Heinrich proposed. He is free
> > > > > > to implement that if he likes, but I am not planning to do this myself
> > > > > > as I see it as a short-term measure and it may cause problems for
> > > > > > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> > > > > > suppose they were happier days before everything froze up).
> > > > > >
> > > > > > > - You should work with any FOSS distributions to get their feedback on
> > > > > > >   what would make their life easier, from a user of U-Boot perspective.
> > > > > > >   bootstd won't be useful if it's not something our users want to use.
> > > > > >
> > > > > > Bootstd is designed to replace the distro scripts and the feedback I
> > > > > > have received is that it is good at that. If you have any other
> > > > > > feedback, or any suggestions on people I should contact, I'm happy to
> > > > > > approach them, or they can email the list and cc me.
> > > > > >
> > > > > > But really, it would be a lot easier if you could just apply this
> > > > > > series so we can move on. If I can see even just a glimmer of
> > > > > > compromise here it will help my confidence.
> > > > >
> > > > > Your sunxi series is broken as posted. I am not interested in applying
> > > > > or encouraging more bootstd usage until there's actual work being done
> > > > > to move forward wit bootstd (a thing you want) and EFI (a thing most
> > > > > distributions want). That would be some of the general feedback you've
> > > > > been given and missed or forgotten.
> > > > >
> > > > > This is even setting aside that I can't recall now if you ever started
> > > > > on making non-BOOTSTD_FULL more useful / usable in general because it's
> > > > > so minimal that every conversion ends up also enabling BOOTSTD_FULL in
> > > > > order to be flexible enough for users to decide SD vs eMMC and so on.
> > > >
> > > > You can hold this up for as long as you like, it's your tree.
> > >
> > > And you can do whatever you like in your personal tree, sure. But
> > > there's rules for working in a community project.
> > >
> > > > I'm always happy and willing to discuss and commit to future
> > > > improvements. The pattern I see, well-established now, is that you
> > > > block my current improvements until some other things are done (this
> > > > series, PXE and many others). Or sometimes you see my series, come up
> > > > with a clean-up and block my series until it is based on top of that.
> > > > If you could move away from that pattern and operate in a more
> > > > cooperative manner, we could definitely get a lot more done in your
> > > > tree.
> > > >
> > > > But again, you can hold this up as long as you like. I just feel it
> > > > would be better for the project if you didn't.
> > >
> > > I continue to not accept changes from anyone that knowingly break other
> > > use cases and users. You are not an exception to the rule. Leaving
> > > things broken for now and improving them later is not an option in
> > > mainline.
> >
> > If that is your justification for blocking progress then it won't work
> > in this case. There is nothing actually broken with my series. Shall I
> > send it again so you can take another look?
>
> Well, again, your series includes "Pick one of these two NAK'd patches
> to continue". So no, you probably shouldn't.

This is the patch I think you are referring to:

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/

I think disabling bootmgr on sunxi is OK. People can always enable it
again if they don't want to use FEL, which after all is a development
feature. It's not a huge limitation in my view, although it might
eventually become a problem. We could always add a bit of
documentation to explain the issue.

>
> > > And I ask everyone to fix problems that are exposed when they're doing
> > > something else. Sometimes, when it comes to Kconfig symbols I'll end up
> > > doing the cleanup because it's tricky to get things right for 1300
> > > platforms.
> >
> > Yes, I know how you feel.
>
> So are you engaging in some sort of tit-for-tat now?

No, actually I was just empathising with you, that so few people are
willing/able to do the work to really make changes and dig into
things.

> I honestly do not
> understand why you're not either:
> - Stopping with the things people have told you to stop doing.
> - Continuing with your own downstream fork for fun.
>
> Your "lets try having two trees" idea is not working and must stop. You
> must decide if you are going to set aside concepts that have been
> rejected or properly fork (and give the community the domain name).

It is better for the project if we work together collaboratively. You
asked me to pick one thing on which you might compromise. I gave you
three options but you rejected all three. I have compromised on loads
of things from my side.

So how about you pick one thing that you could live with? The lack of
compromise is what is creating the issues here.

Regards,
Simon

Re: Rate of innovation in the project (Was: Re: Rate of change in the project)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 16976 bytes --]

On Mon, Apr 07, 2025 at 10:45:24PM +1200, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 7 Apr 2025 at 10:53, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Apr 07, 2025 at 09:15:42AM +1200, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 4 Apr 2025 at 03:27, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 3 Apr 2025 at 11:35, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > Again, back to this thread, if you want me to migrate things, consider
> > > > > > > > > > > > > > applying the sunxi patches as I have described above. I will then look
> > > > > > > > > > > > > > at the next target for bootstd. But while you hold this up, I cannot
> > > > > > > > > > > > > > move forward with more bootstd migration. It doesn't seem that much to
> > > > > > > > > > > > > > ask.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > > > > > > > >
> > > > > > > > > > > > In details:
> > > > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > > > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > > > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > > > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > > > > > > > series is a problem.
> > > > > > > > > > >
> > > > > > > > > > > OK, then just don't apply this patch. Problem solved?
> > > > > > > > > >
> > > > > > > > > > Well, for a hypothetical v6 you would not include it, sure.
> > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > This is fine.
> > > > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > > > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > > > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > > > > > > > Neither of which are desirable changes.
> > > > > > > > > > >
> > > > > > > > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > > > > > > > or why we would need to drop bootmgr from that.
> > > > > > > > > >
> > > > > > > > > > Then you don't have enough of a grasp of the details of the area you're
> > > > > > > > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > > > > > > > the details of the area you're trying to work in.
> > > > > > > > >
> > > > > > > > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > > > > > > > have a FEL boothmeth. That isn't present on rockchip, for example.
> > > > > > > >
> > > > > > > > Again, you seem to have forgotten what the problems with the series
> > > > > > > > were.
> > > > > > >
> > > > > > > No, it's just that we disagree on the path forward.
> > > > > >
> > > > > > Then why did you bring up FEL? That's the part of the migration which is
> > > > > > NOT a problem, I keep being reminded when I ask.
> > > > >
> > > > > FEL needs to get priority, that's all. It was a problem until I
> > > > > adjusted the priority.
> > > >
> > > > And there's been zero objection to this. So why are you mentioning it
> > > > here, in the discussion on why the migration is blocked. I know I had
> > > > been unsure, but I asked, and people answered, and I accepted the
> > > > answer.
> > > >
> > > > > > > > > > > > This patch in particular is
> > > > > > > > > > > > where we have the note:
> > > > > > > > > > > >
> > > > > > > > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > > > > > > > specifically deprioritizing scripts is unexpected."
> > > > > > > > > > > >
> > > > > > > > > > > > Which should have had more attention than it did.
> > > > > > > > > > >
> > > > > > > > > > > From memory the scripts are a fallback used when the other things
> > > > > > > > > > > don't work, so that was the decision I made at the time.
> > > > > > > > > >
> > > > > > > > > > The key point being we changed behavior that others depended on, and
> > > > > > > > > > didn't document it well and didn't make sure the change would work for
> > > > > > > > > > them either.
> > > > > > > > > >
> > > > > > > > > > > > This is the thread that to me spelled out in details where the
> > > > > > > > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > > > > > > > users that have come to rely on ordering.
> > > > > > > > > > >
> > > > > > > > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > > > > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > > > > > > > documented. But it is very close.
> > > > > > > > > >
> > > > > > > > > > You need to get feedback from the people you want to migrate from the
> > > > > > > > > > scripts and ordering and rely on to something else and see what works
> > > > > > > > > > for them.
> > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > > > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > > > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > This is fine, but only relevant once migration happens.
> > > > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > This is a generic bugfix. I will take this to next today.
> > > > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > > > > > > > >
> > > > > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > > > >
> > > > > > > > > > > Well, is he? I thought he was. Can you check?
> > > > > > > > > >
> > > > > > > > > > You're free to. It's one of the innumerable examples of why when you
> > > > > > > > > > group multiple things in a series and there's problems with another part
> > > > > > > > > > of the series, unrelated changes get dropped.
> > > > > > > > >
> > > > > > > > > It would be easier for me if you could apply the patches as I've suggested.
> > > > > > > > >
> > > > > > > > > But if you are willing to apply these patches and just want me to send
> > > > > > > > > the series again without the BLK and RFC patches, I can do that.
> > > > > > > > > Please let me know either way.
> > > > > > > >
> > > > > > > > Again, you should:
> > > > > > > > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> > > > > > > >   for Andre. By themselves. This way they won't get stuck.
> > > > > > >
> > > > > > > There's no point, though, since it doesn't provide the bootstd migration.
> > > > > >
> > > > > > Are you saying there's no point in generally improving things if it
> > > > > > doesn't also involve one of your particular projects?
> > > > >
> > > > > The series is called 'bootstd: sunxi: Migrate to standard boot'. If
> > > > > you'd like to apply just the patches from that series which don't
> > > > > migrate sunxi to standard boot, please go ahead.
> > > >
> > > > I'm not the sunxi custodian. General sunxi changes would go through that
> > > > tree. And then a repeat of everything I've said about how bundling
> > > > unrelated changes hurts everyone.
> > > >
> > > > > > > > - You should work with Heinrich to come up with something that handles
> > > > > > > >   efi bootmanager and bootstd without breaking how our actual project
> > > > > > > >   users use us.
> > > > > > > >   There's no reason to migrate *more* platforms until we have this
> > > > > > > >   fundamental problem sorted out.
> > > > > > >
> > > > > > > It isn't actually a fundamental problem at all. We shouldn't even be
> > > > > > > discussing this and it is really unfortunate that you continue to
> > > > > > > block this effort.
> > > > > > >
> > > > > > > As to bootmgr, I would be willing to implement a solution here, but it
> > > > > > > would involve changes to how bootmgr works under the hood, i.e. to
> > > > > > > have it be iterative instead of doing everything at the start. My firm
> > > > > > > understanding is that such changes would not be acceptable to
> > > > > > > Ilias/Heinrich and anyway I am unable to get patches into the EFI
> > > > > > > subsystem.
> > > > > > >
> > > > > > > So the fallback is the work-around which Heinrich proposed. He is free
> > > > > > > to implement that if he likes, but I am not planning to do this myself
> > > > > > > as I see it as a short-term measure and it may cause problems for
> > > > > > > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> > > > > > > suppose they were happier days before everything froze up).
> > > > > > >
> > > > > > > > - You should work with any FOSS distributions to get their feedback on
> > > > > > > >   what would make their life easier, from a user of U-Boot perspective.
> > > > > > > >   bootstd won't be useful if it's not something our users want to use.
> > > > > > >
> > > > > > > Bootstd is designed to replace the distro scripts and the feedback I
> > > > > > > have received is that it is good at that. If you have any other
> > > > > > > feedback, or any suggestions on people I should contact, I'm happy to
> > > > > > > approach them, or they can email the list and cc me.
> > > > > > >
> > > > > > > But really, it would be a lot easier if you could just apply this
> > > > > > > series so we can move on. If I can see even just a glimmer of
> > > > > > > compromise here it will help my confidence.
> > > > > >
> > > > > > Your sunxi series is broken as posted. I am not interested in applying
> > > > > > or encouraging more bootstd usage until there's actual work being done
> > > > > > to move forward wit bootstd (a thing you want) and EFI (a thing most
> > > > > > distributions want). That would be some of the general feedback you've
> > > > > > been given and missed or forgotten.
> > > > > >
> > > > > > This is even setting aside that I can't recall now if you ever started
> > > > > > on making non-BOOTSTD_FULL more useful / usable in general because it's
> > > > > > so minimal that every conversion ends up also enabling BOOTSTD_FULL in
> > > > > > order to be flexible enough for users to decide SD vs eMMC and so on.
> > > > >
> > > > > You can hold this up for as long as you like, it's your tree.
> > > >
> > > > And you can do whatever you like in your personal tree, sure. But
> > > > there's rules for working in a community project.
> > > >
> > > > > I'm always happy and willing to discuss and commit to future
> > > > > improvements. The pattern I see, well-established now, is that you
> > > > > block my current improvements until some other things are done (this
> > > > > series, PXE and many others). Or sometimes you see my series, come up
> > > > > with a clean-up and block my series until it is based on top of that.
> > > > > If you could move away from that pattern and operate in a more
> > > > > cooperative manner, we could definitely get a lot more done in your
> > > > > tree.
> > > > >
> > > > > But again, you can hold this up as long as you like. I just feel it
> > > > > would be better for the project if you didn't.
> > > >
> > > > I continue to not accept changes from anyone that knowingly break other
> > > > use cases and users. You are not an exception to the rule. Leaving
> > > > things broken for now and improving them later is not an option in
> > > > mainline.
> > >
> > > If that is your justification for blocking progress then it won't work
> > > in this case. There is nothing actually broken with my series. Shall I
> > > send it again so you can take another look?
> >
> > Well, again, your series includes "Pick one of these two NAK'd patches
> > to continue". So no, you probably shouldn't.
> 
> This is the patch I think you are referring to:
> 
> https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> 
> I think disabling bootmgr on sunxi is OK. People can always enable it
> again if they don't want to use FEL, which after all is a development
> feature. It's not a huge limitation in my view, although it might
> eventually become a problem. We could always add a bit of
> documentation to explain the issue.

That patch links to:
https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.arm.com/

Which I would summarize as "EFI boot manager plus boostd changes
behavior in bad for the user ways". And it's not FEL. The FEL challenge
is sunxi specific but also seemingly resolved well enough.

Which is why I don't want to migrate more architectures until:
- We can be more confident that we aren't breaking boot order for users.
- Someone is actually making progress on EFI boot manager plus bootstd.

> > > > And I ask everyone to fix problems that are exposed when they're doing
> > > > something else. Sometimes, when it comes to Kconfig symbols I'll end up
> > > > doing the cleanup because it's tricky to get things right for 1300
> > > > platforms.
> > >
> > > Yes, I know how you feel.
> >
> > So are you engaging in some sort of tit-for-tat now?
> 
> No, actually I was just empathising with you, that so few people are
> willing/able to do the work to really make changes and dig into
> things.
> 
> > I honestly do not
> > understand why you're not either:
> > - Stopping with the things people have told you to stop doing.
> > - Continuing with your own downstream fork for fun.
> >
> > Your "lets try having two trees" idea is not working and must stop. You
> > must decide if you are going to set aside concepts that have been
> > rejected or properly fork (and give the community the domain name).
> 
> It is better for the project if we work together collaboratively. You
> asked me to pick one thing on which you might compromise. I gave you
> three options but you rejected all three. I have compromised on loads
> of things from my side.
> 
> So how about you pick one thing that you could live with? The lack of
> compromise is what is creating the issues here.

My perspective is that your refusal to slow down and get something to
completion is the issue. You keep sending out 50 part series that
refactor a ton of things. And this is because you have a number of large
changes in mind at all times. This is not functional for a project where
most of our testing happens close to a release. Small incremental change
over time is what works for us.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
[snip]
> > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > look at it, and refrain from otherwise assuming how it solves the
> > > problems I had seen previously.
> > 
> > I pushed an updated version to dm/splg-working but it is not very
> > updated. Still needs more work.
> 
> Thanks.

So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
changes, here's another example of the problem with your approach. What
stops xilinx_zynqmp_kria from building in splg-working is that
BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
since I always use O=, rm -rf) is needed for changes there to be picked
up, but that's maybe just a missing Makefile dependency line. But that
just makes it easier to see the next problem, which I don't see the
answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
For SPL however:
  CC      spl/drivers/spi/zynqmp_gqspi.o
/home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
/home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
      |                      ^
/home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
      |                          ^
 
And I don't see, really, what's even getting us down this error path.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi  Tom,

On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> [snip]
> > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > look at it, and refrain from otherwise assuming how it solves the
> > > > problems I had seen previously.
> > >
> > > I pushed an updated version to dm/splg-working but it is not very
> > > updated. Still needs more work.
> >
> > Thanks.
>
> So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> changes, here's another example of the problem with your approach. What
> stops xilinx_zynqmp_kria from building in splg-working is that
> BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> since I always use O=, rm -rf) is needed for changes there to be picked
> up, but that's maybe just a missing Makefile dependency line. But that
> just makes it easier to see the next problem, which I don't see the
> answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> For SPL however:
>   CC      spl/drivers/spi/zynqmp_gqspi.o
> /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
>       |                      ^
> /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
>       |                          ^
>
> And I don't see, really, what's even getting us down this error path.

It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
across all phases.

I pushed a new tree which builds without the warning. Note that
SPL_SPI is enabled.

Regards,
SImon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]

On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> Hi  Tom,
> 
> On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > [snip]
> > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > problems I had seen previously.
> > > >
> > > > I pushed an updated version to dm/splg-working but it is not very
> > > > updated. Still needs more work.
> > >
> > > Thanks.
> >
> > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > changes, here's another example of the problem with your approach. What
> > stops xilinx_zynqmp_kria from building in splg-working is that
> > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > since I always use O=, rm -rf) is needed for changes there to be picked
> > up, but that's maybe just a missing Makefile dependency line. But that
> > just makes it easier to see the next problem, which I don't see the
> > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > For SPL however:
> >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> >       |                      ^
> > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> >       |                          ^
> >
> > And I don't see, really, what's even getting us down this error path.
> 
> It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> across all phases.
> 
> I pushed a new tree which builds without the warning. Note that
> SPL_SPI is enabled.

So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
scripts/conf_nospl is going to be a problem in and of itself, and likely
as confusing if not more-so than any of the in-the-end visible changes.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > Hi  Tom,
> >
> > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > [snip]
> > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > problems I had seen previously.
> > > > >
> > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > updated. Still needs more work.
> > > >
> > > > Thanks.
> > >
> > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > changes, here's another example of the problem with your approach. What
> > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > up, but that's maybe just a missing Makefile dependency line. But that
> > > just makes it easier to see the next problem, which I don't see the
> > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > For SPL however:
> > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > >       |                      ^
> > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > >       |                          ^
> > >
> > > And I don't see, really, what's even getting us down this error path.
> >
> > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > across all phases.
> >
> > I pushed a new tree which builds without the warning. Note that
> > SPL_SPI is enabled.
>
> So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> scripts/conf_nospl is going to be a problem in and of itself, and likely
> as confusing if not more-so than any of the in-the-end visible changes.

Yes, perhaps the key point I've been trying to get across is this confusion.

As you know, at present we have two types of options:
a) those for which each phase has its own value
b) those for which there is a single value shared across all phases

The only way today that you can tell them apart is by looking for uses
of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
then the option is a) otherwise it is b). There is no way to tell from
Kconfig. Also, some parts of the code may use CONFIG_IS_ENABLED() for
an option, some may use IS_ENABLED() for that same option. Some may
use $(PHASE_) and some may not. It's a bit of a mess.

Stepping back a bit, perhaps the goal of my series is to identify
options in b) so we can deal with them in a better way. They are all
listed in conf_nospl, in preparation for some future action.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6613 bytes --]

On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > Hi  Tom,
> > >
> > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > [snip]
> > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > problems I had seen previously.
> > > > > >
> > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > updated. Still needs more work.
> > > > >
> > > > > Thanks.
> > > >
> > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > changes, here's another example of the problem with your approach. What
> > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > just makes it easier to see the next problem, which I don't see the
> > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > For SPL however:
> > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > >       |                      ^
> > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > >       |                          ^
> > > >
> > > > And I don't see, really, what's even getting us down this error path.
> > >
> > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > across all phases.
> > >
> > > I pushed a new tree which builds without the warning. Note that
> > > SPL_SPI is enabled.
> >
> > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > as confusing if not more-so than any of the in-the-end visible changes.
> 
> Yes, perhaps the key point I've been trying to get across is this confusion.
> 
> As you know, at present we have two types of options:
> a) those for which each phase has its own value
> b) those for which there is a single value shared across all phases

Agreed.

> The only way today that you can tell them apart is by looking for uses
> of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,

Partially agreed. Those are strong indicators that both CONFIG_FOO and
CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
but not yet).

> then the option is a) otherwise it is b). There is no way to tell from
> Kconfig.

Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
would be a handy thing to have. But you're mentioning this in another
context, why we need some additional knowledge somewhere.

> Also, some parts of the code may use CONFIG_IS_ENABLED() for
> an option, some may use IS_ENABLED() for that same option. Some may
> use $(PHASE_) and some may not. It's a bit of a mess.

I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
big deal, and should be fixed.

I'm only going to rant slightly that checkpatch.pl telling people to use
these macros has made the situation worse, not better, out of an
ingrained need to silence checkpatch.pl.

And what you're missing is that sometimes we intentionally don't want
$(PHASE_), or would need to rewrite the Makefile to make use of it.
fs/Makefile is an example of this.

> Stepping back a bit, perhaps the goal of my series is to identify
> options in b) so we can deal with them in a better way. They are all
> listed in conf_nospl, in preparation for some future action.

There are two big problems here. The first of which is that conf_nospl,
as a concept, is going to be incomplete. Do you list every CMD in there?
Why? They'll never be in a non-PPL phase. It will be its own nightmare
to keep correct, once it is bug-compatible with what we have today.

The second big problem is that it doesn't make it any easier to solve
what I keep calling the DWC3 problem. It's a valid use case that two
developers have hit independently of wanting to enable USB gadget
support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
solving this problem, it gets worse to solve. Today it's "OK, I need to
find where to move obj-$(CONFIG_FOO) to be more visible and
obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
working here but not there?".

To me, at absolute best case here, we're making a lot of changes and
spending a lot of time to not really address the underlying problems,
just making some questionable value visibility changes. We could reduce
ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
must only be tested on CONFIG_FOO. I'm 80% sure we could simplify all of
$(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
which to use of those question. And update / expand upon the existing
documentation we have as it's not clear enough for everyone. Then we can
think, again, about how to solve the problems that are introduced by
building our entire source tree N times from a single configuration
file. Or if we need to do something radical there.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > Hi  Tom,
> > > >
> > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > [snip]
> > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > problems I had seen previously.
> > > > > > >
> > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > updated. Still needs more work.
> > > > > >
> > > > > > Thanks.
> > > > >
> > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > changes, here's another example of the problem with your approach. What
> > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > just makes it easier to see the next problem, which I don't see the
> > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > For SPL however:
> > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > >       |                      ^
> > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > >       |                          ^
> > > > >
> > > > > And I don't see, really, what's even getting us down this error path.
> > > >
> > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > across all phases.
> > > >
> > > > I pushed a new tree which builds without the warning. Note that
> > > > SPL_SPI is enabled.
> > >
> > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > as confusing if not more-so than any of the in-the-end visible changes.
> >
> > Yes, perhaps the key point I've been trying to get across is this confusion.
> >
> > As you know, at present we have two types of options:
> > a) those for which each phase has its own value
> > b) those for which there is a single value shared across all phases
>
> Agreed.
>
> > The only way today that you can tell them apart is by looking for uses
> > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
>
> Partially agreed. Those are strong indicators that both CONFIG_FOO and
> CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> but not yet).

OK

>
> > then the option is a) otherwise it is b). There is no way to tell from
> > Kconfig.
>
> Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> would be a handy thing to have. But you're mentioning this in another
> context, why we need some additional knowledge somewhere.

What I meant was that we don't have anything in the Kconfig for FOO
that says this is a global option or an xPL-specific one. We have to
hunt for SPL_FOO, etc.

>
> > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > an option, some may use IS_ENABLED() for that same option. Some may
> > use $(PHASE_) and some may not. It's a bit of a mess.
>
> I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> big deal, and should be fixed.

But this is largely the point of my series. It's the reason why
qconfig is able to locate these cases and warn about them. It is a big
deal, IMO, or at least big enough for me to attempt this.

>
> I'm only going to rant slightly that checkpatch.pl telling people to use
> these macros has made the situation worse, not better, out of an
> ingrained need to silence checkpatch.pl.
>
> And what you're missing is that sometimes we intentionally don't want
> $(PHASE_), or would need to rewrite the Makefile to make use of it.
> fs/Makefile is an example of this.

The next step from my side would be to get rid of the 'ifdef
CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.

>
> > Stepping back a bit, perhaps the goal of my series is to identify
> > options in b) so we can deal with them in a better way. They are all
> > listed in conf_nospl, in preparation for some future action.
>
> There are two big problems here. The first of which is that conf_nospl,
> as a concept, is going to be incomplete. Do you list every CMD in there?
> Why? They'll never be in a non-PPL phase. It will be its own nightmare
> to keep correct, once it is bug-compatible with what we have today.

This is actually the *nice* thing about conf_nospl. We should reduce
it to empty, just like we did with the Kconfig whitelist.

We have this rule:

libs-$(CONFIG_CMDLINE) += cmd/

which is enough for most things. The only issue is that sometimes,
e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.

So I don't agree at all that my series is a 'big problem'. It is a
solution to the current confusion and it shows up what is broken and
needs to be fixed.

>
> The second big problem is that it doesn't make it any easier to solve
> what I keep calling the DWC3 problem. It's a valid use case that two
> developers have hit independently of wanting to enable USB gadget
> support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> solving this problem, it gets worse to solve. Today it's "OK, I need to
> find where to move obj-$(CONFIG_FOO) to be more visible and
> obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> working here but not there?".

Is that because some Makefile higher in the hierarchy is not building
that subdir? I don't know what this is about.

>
> To me, at absolute best case here, we're making a lot of changes and
> spending a lot of time to not really address the underlying problems,
> just making some questionable value visibility changes. We could reduce
> ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> must only be tested on CONFIG_FOO.

Or we could finish and apply my series, which does this.

> I'm 80% sure we could simplify all of
> $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> which to use of those question.

Again, let's apply my series, which actually gets rid of PHASE_, SPL_
and XPL_ altogether.

> And update / expand upon the existing
> documentation we have as it's not clear enough for everyone. Then we can
> think, again, about how to solve the problems that are introduced by
> building our entire source tree N times from a single configuration
> file. Or if we need to do something radical there.

At this point I'm getting the feeling that you imagine my series is
some grand unified plan for Kconfig. It really isn't and this thread
is reminding me of why I originally wrote it. Bear in mind it was over
two years ago and I have mostly forgotten all the issues. It is a
clean-up series. It isn't the second coming but it isn't the
antichrist either.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 9320 bytes --]

On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > Hi  Tom,
> > > > >
> > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > [snip]
> > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > problems I had seen previously.
> > > > > > > >
> > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > updated. Still needs more work.
> > > > > > >
> > > > > > > Thanks.
> > > > > >
> > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > changes, here's another example of the problem with your approach. What
> > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > For SPL however:
> > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > >       |                      ^
> > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > >       |                          ^
> > > > > >
> > > > > > And I don't see, really, what's even getting us down this error path.
> > > > >
> > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > across all phases.
> > > > >
> > > > > I pushed a new tree which builds without the warning. Note that
> > > > > SPL_SPI is enabled.
> > > >
> > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > as confusing if not more-so than any of the in-the-end visible changes.
> > >
> > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > >
> > > As you know, at present we have two types of options:
> > > a) those for which each phase has its own value
> > > b) those for which there is a single value shared across all phases
> >
> > Agreed.
> >
> > > The only way today that you can tell them apart is by looking for uses
> > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> >
> > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > but not yet).
> 
> OK
> 
> >
> > > then the option is a) otherwise it is b). There is no way to tell from
> > > Kconfig.
> >
> > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > would be a handy thing to have. But you're mentioning this in another
> > context, why we need some additional knowledge somewhere.
> 
> What I meant was that we don't have anything in the Kconfig for FOO
> that says this is a global option or an xPL-specific one. We have to
> hunt for SPL_FOO, etc.
> 
> >
> > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > an option, some may use IS_ENABLED() for that same option. Some may
> > > use $(PHASE_) and some may not. It's a bit of a mess.
> >
> > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > big deal, and should be fixed.
> 
> But this is largely the point of my series. It's the reason why
> qconfig is able to locate these cases and warn about them. It is a big
> deal, IMO, or at least big enough for me to attempt this.
> 
> >
> > I'm only going to rant slightly that checkpatch.pl telling people to use
> > these macros has made the situation worse, not better, out of an
> > ingrained need to silence checkpatch.pl.
> >
> > And what you're missing is that sometimes we intentionally don't want
> > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > fs/Makefile is an example of this.
> 
> The next step from my side would be to get rid of the 'ifdef
> CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> 
> >
> > > Stepping back a bit, perhaps the goal of my series is to identify
> > > options in b) so we can deal with them in a better way. They are all
> > > listed in conf_nospl, in preparation for some future action.
> >
> > There are two big problems here. The first of which is that conf_nospl,
> > as a concept, is going to be incomplete. Do you list every CMD in there?
> > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > to keep correct, once it is bug-compatible with what we have today.
> 
> This is actually the *nice* thing about conf_nospl. We should reduce
> it to empty, just like we did with the Kconfig whitelist.
> 
> We have this rule:
> 
> libs-$(CONFIG_CMDLINE) += cmd/
> 
> which is enough for most things. The only issue is that sometimes,
> e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> 
> So I don't agree at all that my series is a 'big problem'. It is a
> solution to the current confusion and it shows up what is broken and
> needs to be fixed.
> 
> >
> > The second big problem is that it doesn't make it any easier to solve
> > what I keep calling the DWC3 problem. It's a valid use case that two
> > developers have hit independently of wanting to enable USB gadget
> > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > find where to move obj-$(CONFIG_FOO) to be more visible and
> > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > working here but not there?".
> 
> Is that because some Makefile higher in the hierarchy is not building
> that subdir? I don't know what this is about.
> 
> >
> > To me, at absolute best case here, we're making a lot of changes and
> > spending a lot of time to not really address the underlying problems,
> > just making some questionable value visibility changes. We could reduce
> > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > must only be tested on CONFIG_FOO.
> 
> Or we could finish and apply my series, which does this.
> 
> > I'm 80% sure we could simplify all of
> > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > which to use of those question.
> 
> Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> and XPL_ altogether.
> 
> > And update / expand upon the existing
> > documentation we have as it's not clear enough for everyone. Then we can
> > think, again, about how to solve the problems that are introduced by
> > building our entire source tree N times from a single configuration
> > file. Or if we need to do something radical there.
> 
> At this point I'm getting the feeling that you imagine my series is
> some grand unified plan for Kconfig. It really isn't and this thread
> is reminding me of why I originally wrote it. Bear in mind it was over
> two years ago and I have mostly forgotten all the issues. It is a
> clean-up series. It isn't the second coming but it isn't the
> antichrist either.

I worry you're going to spend another month of effort to get this to 1:1
compatibility (modulo fixing bugs) with what we have today and get
disappointed once it rolls out to -next. But I guess I've already spent
too much time trying to convince you this is a bad idea and that your
cure is worse than the disease.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > Hi  Tom,
> > > > > >
> > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > [snip]
> > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > problems I had seen previously.
> > > > > > > > >
> > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > updated. Still needs more work.
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > >
> > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > For SPL however:
> > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > >       |                      ^
> > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > >       |                          ^
> > > > > > >
> > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > >
> > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > across all phases.
> > > > > >
> > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > SPL_SPI is enabled.
> > > > >
> > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > >
> > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > >
> > > > As you know, at present we have two types of options:
> > > > a) those for which each phase has its own value
> > > > b) those for which there is a single value shared across all phases
> > >
> > > Agreed.
> > >
> > > > The only way today that you can tell them apart is by looking for uses
> > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > >
> > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > but not yet).
> >
> > OK
> >
> > >
> > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > Kconfig.
> > >
> > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > would be a handy thing to have. But you're mentioning this in another
> > > context, why we need some additional knowledge somewhere.
> >
> > What I meant was that we don't have anything in the Kconfig for FOO
> > that says this is a global option or an xPL-specific one. We have to
> > hunt for SPL_FOO, etc.
> >
> > >
> > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > >
> > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > big deal, and should be fixed.
> >
> > But this is largely the point of my series. It's the reason why
> > qconfig is able to locate these cases and warn about them. It is a big
> > deal, IMO, or at least big enough for me to attempt this.
> >
> > >
> > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > these macros has made the situation worse, not better, out of an
> > > ingrained need to silence checkpatch.pl.
> > >
> > > And what you're missing is that sometimes we intentionally don't want
> > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > fs/Makefile is an example of this.
> >
> > The next step from my side would be to get rid of the 'ifdef
> > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> >
> > >
> > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > options in b) so we can deal with them in a better way. They are all
> > > > listed in conf_nospl, in preparation for some future action.
> > >
> > > There are two big problems here. The first of which is that conf_nospl,
> > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > to keep correct, once it is bug-compatible with what we have today.
> >
> > This is actually the *nice* thing about conf_nospl. We should reduce
> > it to empty, just like we did with the Kconfig whitelist.
> >
> > We have this rule:
> >
> > libs-$(CONFIG_CMDLINE) += cmd/
> >
> > which is enough for most things. The only issue is that sometimes,
> > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> >
> > So I don't agree at all that my series is a 'big problem'. It is a
> > solution to the current confusion and it shows up what is broken and
> > needs to be fixed.
> >
> > >
> > > The second big problem is that it doesn't make it any easier to solve
> > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > developers have hit independently of wanting to enable USB gadget
> > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > working here but not there?".
> >
> > Is that because some Makefile higher in the hierarchy is not building
> > that subdir? I don't know what this is about.
> >
> > >
> > > To me, at absolute best case here, we're making a lot of changes and
> > > spending a lot of time to not really address the underlying problems,
> > > just making some questionable value visibility changes. We could reduce
> > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > must only be tested on CONFIG_FOO.
> >
> > Or we could finish and apply my series, which does this.
> >
> > > I'm 80% sure we could simplify all of
> > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > which to use of those question.
> >
> > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > and XPL_ altogether.
> >
> > > And update / expand upon the existing
> > > documentation we have as it's not clear enough for everyone. Then we can
> > > think, again, about how to solve the problems that are introduced by
> > > building our entire source tree N times from a single configuration
> > > file. Or if we need to do something radical there.
> >
> > At this point I'm getting the feeling that you imagine my series is
> > some grand unified plan for Kconfig. It really isn't and this thread
> > is reminding me of why I originally wrote it. Bear in mind it was over
> > two years ago and I have mostly forgotten all the issues. It is a
> > clean-up series. It isn't the second coming but it isn't the
> > antichrist either.
>
> I worry you're going to spend another month of effort to get this to 1:1
> compatibility (modulo fixing bugs) with what we have today and get
> disappointed once it rolls out to -next. But I guess I've already spent
> too much time trying to convince you this is a bad idea and that your
> cure is worse than the disease.

To me the core issue is whether to completely split the defconfig
files. I am quite worried about that. You are quite worried about the
confusion my series will cause.

I think it is reasonable, if we go with my series, that I drive
conf_nospl down to zero lines (and remove the feature) before going
any further. Would that make you more comfortable? It would be a fair
bit of work, but could be done over a few releases.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 11152 bytes --]

On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > Hi  Tom,
> > > > > > >
> > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > [snip]
> > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > problems I had seen previously.
> > > > > > > > > >
> > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > updated. Still needs more work.
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > For SPL however:
> > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > >       |                      ^
> > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > >       |                          ^
> > > > > > > >
> > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > >
> > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > across all phases.
> > > > > > >
> > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > SPL_SPI is enabled.
> > > > > >
> > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > >
> > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > >
> > > > > As you know, at present we have two types of options:
> > > > > a) those for which each phase has its own value
> > > > > b) those for which there is a single value shared across all phases
> > > >
> > > > Agreed.
> > > >
> > > > > The only way today that you can tell them apart is by looking for uses
> > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > >
> > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > but not yet).
> > >
> > > OK
> > >
> > > >
> > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > Kconfig.
> > > >
> > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > would be a handy thing to have. But you're mentioning this in another
> > > > context, why we need some additional knowledge somewhere.
> > >
> > > What I meant was that we don't have anything in the Kconfig for FOO
> > > that says this is a global option or an xPL-specific one. We have to
> > > hunt for SPL_FOO, etc.
> > >
> > > >
> > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > >
> > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > big deal, and should be fixed.
> > >
> > > But this is largely the point of my series. It's the reason why
> > > qconfig is able to locate these cases and warn about them. It is a big
> > > deal, IMO, or at least big enough for me to attempt this.
> > >
> > > >
> > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > these macros has made the situation worse, not better, out of an
> > > > ingrained need to silence checkpatch.pl.
> > > >
> > > > And what you're missing is that sometimes we intentionally don't want
> > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > fs/Makefile is an example of this.
> > >
> > > The next step from my side would be to get rid of the 'ifdef
> > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > >
> > > >
> > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > options in b) so we can deal with them in a better way. They are all
> > > > > listed in conf_nospl, in preparation for some future action.
> > > >
> > > > There are two big problems here. The first of which is that conf_nospl,
> > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > to keep correct, once it is bug-compatible with what we have today.
> > >
> > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > it to empty, just like we did with the Kconfig whitelist.
> > >
> > > We have this rule:
> > >
> > > libs-$(CONFIG_CMDLINE) += cmd/
> > >
> > > which is enough for most things. The only issue is that sometimes,
> > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > >
> > > So I don't agree at all that my series is a 'big problem'. It is a
> > > solution to the current confusion and it shows up what is broken and
> > > needs to be fixed.
> > >
> > > >
> > > > The second big problem is that it doesn't make it any easier to solve
> > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > developers have hit independently of wanting to enable USB gadget
> > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > working here but not there?".
> > >
> > > Is that because some Makefile higher in the hierarchy is not building
> > > that subdir? I don't know what this is about.
> > >
> > > >
> > > > To me, at absolute best case here, we're making a lot of changes and
> > > > spending a lot of time to not really address the underlying problems,
> > > > just making some questionable value visibility changes. We could reduce
> > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > must only be tested on CONFIG_FOO.
> > >
> > > Or we could finish and apply my series, which does this.
> > >
> > > > I'm 80% sure we could simplify all of
> > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > which to use of those question.
> > >
> > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > and XPL_ altogether.
> > >
> > > > And update / expand upon the existing
> > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > think, again, about how to solve the problems that are introduced by
> > > > building our entire source tree N times from a single configuration
> > > > file. Or if we need to do something radical there.
> > >
> > > At this point I'm getting the feeling that you imagine my series is
> > > some grand unified plan for Kconfig. It really isn't and this thread
> > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > two years ago and I have mostly forgotten all the issues. It is a
> > > clean-up series. It isn't the second coming but it isn't the
> > > antichrist either.
> >
> > I worry you're going to spend another month of effort to get this to 1:1
> > compatibility (modulo fixing bugs) with what we have today and get
> > disappointed once it rolls out to -next. But I guess I've already spent
> > too much time trying to convince you this is a bad idea and that your
> > cure is worse than the disease.
> 
> To me the core issue is whether to completely split the defconfig
> files. I am quite worried about that. You are quite worried about the
> confusion my series will cause.
> 
> I think it is reasonable, if we go with my series, that I drive
> conf_nospl down to zero lines (and remove the feature) before going
> any further. Would that make you more comfortable? It would be a fair
> bit of work, but could be done over a few releases.

Here is my core concern. Can macros be tricky? Yes. Do we need a
checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
bugs like:
- Take pinebook-pro-rk3399_defconfig
- Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
  CONFIG_SPL_USB_SDP_SUPPORT

Your proposal neither fixes that bug nor makes it easier to understand
why that bug happens. And this is the category of build problems that we
get that aren't "you missed using the right macro".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > Hi  Tom,
> > > > > > > >
> > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > [snip]
> > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > >
> > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > >
> > > > > > > > > > Thanks.
> > > > > > > > >
> > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > For SPL however:
> > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > >       |                      ^
> > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > >       |                          ^
> > > > > > > > >
> > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > >
> > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > across all phases.
> > > > > > > >
> > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > SPL_SPI is enabled.
> > > > > > >
> > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > >
> > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > >
> > > > > > As you know, at present we have two types of options:
> > > > > > a) those for which each phase has its own value
> > > > > > b) those for which there is a single value shared across all phases
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > >
> > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > but not yet).
> > > >
> > > > OK
> > > >
> > > > >
> > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > Kconfig.
> > > > >
> > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > context, why we need some additional knowledge somewhere.
> > > >
> > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > that says this is a global option or an xPL-specific one. We have to
> > > > hunt for SPL_FOO, etc.
> > > >
> > > > >
> > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > >
> > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > big deal, and should be fixed.
> > > >
> > > > But this is largely the point of my series. It's the reason why
> > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > deal, IMO, or at least big enough for me to attempt this.
> > > >
> > > > >
> > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > these macros has made the situation worse, not better, out of an
> > > > > ingrained need to silence checkpatch.pl.
> > > > >
> > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > fs/Makefile is an example of this.
> > > >
> > > > The next step from my side would be to get rid of the 'ifdef
> > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > >
> > > > >
> > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > listed in conf_nospl, in preparation for some future action.
> > > > >
> > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > to keep correct, once it is bug-compatible with what we have today.
> > > >
> > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > it to empty, just like we did with the Kconfig whitelist.
> > > >
> > > > We have this rule:
> > > >
> > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > >
> > > > which is enough for most things. The only issue is that sometimes,
> > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > >
> > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > solution to the current confusion and it shows up what is broken and
> > > > needs to be fixed.
> > > >
> > > > >
> > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > developers have hit independently of wanting to enable USB gadget
> > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > working here but not there?".
> > > >
> > > > Is that because some Makefile higher in the hierarchy is not building
> > > > that subdir? I don't know what this is about.
> > > >
> > > > >
> > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > spending a lot of time to not really address the underlying problems,
> > > > > just making some questionable value visibility changes. We could reduce
> > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > must only be tested on CONFIG_FOO.
> > > >
> > > > Or we could finish and apply my series, which does this.
> > > >
> > > > > I'm 80% sure we could simplify all of
> > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > which to use of those question.
> > > >
> > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > and XPL_ altogether.
> > > >
> > > > > And update / expand upon the existing
> > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > think, again, about how to solve the problems that are introduced by
> > > > > building our entire source tree N times from a single configuration
> > > > > file. Or if we need to do something radical there.
> > > >
> > > > At this point I'm getting the feeling that you imagine my series is
> > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > clean-up series. It isn't the second coming but it isn't the
> > > > antichrist either.
> > >
> > > I worry you're going to spend another month of effort to get this to 1:1
> > > compatibility (modulo fixing bugs) with what we have today and get
> > > disappointed once it rolls out to -next. But I guess I've already spent
> > > too much time trying to convince you this is a bad idea and that your
> > > cure is worse than the disease.
> >
> > To me the core issue is whether to completely split the defconfig
> > files. I am quite worried about that. You are quite worried about the
> > confusion my series will cause.
> >
> > I think it is reasonable, if we go with my series, that I drive
> > conf_nospl down to zero lines (and remove the feature) before going
> > any further. Would that make you more comfortable? It would be a fair
> > bit of work, but could be done over a few releases.
>
> Here is my core concern. Can macros be tricky? Yes. Do we need a
> checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> bugs like:
> - Take pinebook-pro-rk3399_defconfig
> - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
>   CONFIG_SPL_USB_SDP_SUPPORT
>
> Your proposal neither fixes that bug nor makes it easier to understand
> why that bug happens. And this is the category of build problems that we
> get that aren't "you missed using the right macro".

Honestly, what on earth does this have to do with my series?

The problem happens before and after my series, from what I can tell.

If you want these sorts of combinations to be tested, perhaps add a
board that enables them, or even rethink your opposition to my
buildman proposal?[4]

Regards,
Simon

[4] https://patchwork.ozlabs.org/project/uboot/patch/20241108152350.3686274-9-sjg@chromium.org/

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 12911 bytes --]

On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > Hi  Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > [snip]
> > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > >
> > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > >
> > > > > > > > > > > Thanks.
> > > > > > > > > >
> > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > For SPL however:
> > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > >       |                      ^
> > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > >       |                          ^
> > > > > > > > > >
> > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > >
> > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > across all phases.
> > > > > > > > >
> > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > SPL_SPI is enabled.
> > > > > > > >
> > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > >
> > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > >
> > > > > > > As you know, at present we have two types of options:
> > > > > > > a) those for which each phase has its own value
> > > > > > > b) those for which there is a single value shared across all phases
> > > > > >
> > > > > > Agreed.
> > > > > >
> > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > >
> > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > but not yet).
> > > > >
> > > > > OK
> > > > >
> > > > > >
> > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > Kconfig.
> > > > > >
> > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > context, why we need some additional knowledge somewhere.
> > > > >
> > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > hunt for SPL_FOO, etc.
> > > > >
> > > > > >
> > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > >
> > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > big deal, and should be fixed.
> > > > >
> > > > > But this is largely the point of my series. It's the reason why
> > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > >
> > > > > >
> > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > these macros has made the situation worse, not better, out of an
> > > > > > ingrained need to silence checkpatch.pl.
> > > > > >
> > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > fs/Makefile is an example of this.
> > > > >
> > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > >
> > > > > >
> > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > >
> > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > >
> > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > >
> > > > > We have this rule:
> > > > >
> > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > >
> > > > > which is enough for most things. The only issue is that sometimes,
> > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > >
> > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > solution to the current confusion and it shows up what is broken and
> > > > > needs to be fixed.
> > > > >
> > > > > >
> > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > working here but not there?".
> > > > >
> > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > that subdir? I don't know what this is about.
> > > > >
> > > > > >
> > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > must only be tested on CONFIG_FOO.
> > > > >
> > > > > Or we could finish and apply my series, which does this.
> > > > >
> > > > > > I'm 80% sure we could simplify all of
> > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > which to use of those question.
> > > > >
> > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > and XPL_ altogether.
> > > > >
> > > > > > And update / expand upon the existing
> > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > building our entire source tree N times from a single configuration
> > > > > > file. Or if we need to do something radical there.
> > > > >
> > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > antichrist either.
> > > >
> > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > too much time trying to convince you this is a bad idea and that your
> > > > cure is worse than the disease.
> > >
> > > To me the core issue is whether to completely split the defconfig
> > > files. I am quite worried about that. You are quite worried about the
> > > confusion my series will cause.
> > >
> > > I think it is reasonable, if we go with my series, that I drive
> > > conf_nospl down to zero lines (and remove the feature) before going
> > > any further. Would that make you more comfortable? It would be a fair
> > > bit of work, but could be done over a few releases.
> >
> > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > bugs like:
> > - Take pinebook-pro-rk3399_defconfig
> > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> >   CONFIG_SPL_USB_SDP_SUPPORT
> >
> > Your proposal neither fixes that bug nor makes it easier to understand
> > why that bug happens. And this is the category of build problems that we
> > get that aren't "you missed using the right macro".
> 
> Honestly, what on earth does this have to do with my series?

It's that your series doesn't address the real problems we keep having.

> The problem happens before and after my series, from what I can tell.

Yes, I've said that numerous times.

> If you want these sorts of combinations to be tested, perhaps add a
> board that enables them, or even rethink your opposition to my
> buildman proposal?[4]

This isn't relevant to the point I've raised several times now. The
failure mode above was reported by two different developers, neither of
whom saw how to correctly solve the problem.

And again, if you tried to solve this problem on your series you might
see how what you're proposing will make things worse, not better.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi  Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > [snip]
> > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks.
> > > > > > > > > > >
> > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > For SPL however:
> > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > >       |                      ^
> > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > >       |                          ^
> > > > > > > > > > >
> > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > >
> > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > across all phases.
> > > > > > > > > >
> > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > >
> > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > >
> > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > >
> > > > > > > > As you know, at present we have two types of options:
> > > > > > > > a) those for which each phase has its own value
> > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > >
> > > > > > > Agreed.
> > > > > > >
> > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > >
> > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > but not yet).
> > > > > >
> > > > > > OK
> > > > > >
> > > > > > >
> > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > Kconfig.
> > > > > > >
> > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > context, why we need some additional knowledge somewhere.
> > > > > >
> > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > hunt for SPL_FOO, etc.
> > > > > >
> > > > > > >
> > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > >
> > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > big deal, and should be fixed.
> > > > > >
> > > > > > But this is largely the point of my series. It's the reason why
> > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > >
> > > > > > >
> > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > >
> > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > fs/Makefile is an example of this.
> > > > > >
> > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > >
> > > > > > >
> > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > >
> > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > >
> > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > >
> > > > > > We have this rule:
> > > > > >
> > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > >
> > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > >
> > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > needs to be fixed.
> > > > > >
> > > > > > >
> > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > working here but not there?".
> > > > > >
> > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > that subdir? I don't know what this is about.
> > > > > >
> > > > > > >
> > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > must only be tested on CONFIG_FOO.
> > > > > >
> > > > > > Or we could finish and apply my series, which does this.
> > > > > >
> > > > > > > I'm 80% sure we could simplify all of
> > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > which to use of those question.
> > > > > >
> > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > and XPL_ altogether.
> > > > > >
> > > > > > > And update / expand upon the existing
> > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > building our entire source tree N times from a single configuration
> > > > > > > file. Or if we need to do something radical there.
> > > > > >
> > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > antichrist either.
> > > > >
> > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > too much time trying to convince you this is a bad idea and that your
> > > > > cure is worse than the disease.
> > > >
> > > > To me the core issue is whether to completely split the defconfig
> > > > files. I am quite worried about that. You are quite worried about the
> > > > confusion my series will cause.
> > > >
> > > > I think it is reasonable, if we go with my series, that I drive
> > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > any further. Would that make you more comfortable? It would be a fair
> > > > bit of work, but could be done over a few releases.
> > >
> > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > bugs like:
> > > - Take pinebook-pro-rk3399_defconfig
> > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > >   CONFIG_SPL_USB_SDP_SUPPORT
> > >
> > > Your proposal neither fixes that bug nor makes it easier to understand
> > > why that bug happens. And this is the category of build problems that we
> > > get that aren't "you missed using the right macro".
> >
> > Honestly, what on earth does this have to do with my series?
>
> It's that your series doesn't address the real problems we keep having.
>
> > The problem happens before and after my series, from what I can tell.
>
> Yes, I've said that numerous times.
>
> > If you want these sorts of combinations to be tested, perhaps add a
> > board that enables them, or even rethink your opposition to my
> > buildman proposal?[4]
>
> This isn't relevant to the point I've raised several times now. The
> failure mode above was reported by two different developers, neither of
> whom saw how to correctly solve the problem.

That surprises me a little, as the problem seems pretty fundamental.
If you don't enable USB_GADGET, then symbols which depend on it don't
exist.

>
> And again, if you tried to solve this problem on your series you might
> see how what you're proposing will make things worse, not better.

At least with my scheme you can do something like this:

config SPL_USB_GADGET
   bool "USB Gadget Support in SPL"
   depends on USB_GADGET

I normally make the SPL symbols depend on PPL, since it normally
doesn't make a lot of sense to have the feature in SPL unless it is in
PPL. Is this an exception to that rule?

If we do go ahead and enhance Kconfig, then we can combine the two
symbols, which is something.

Regards,
SImon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 15255 bytes --]

On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi  Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks.
> > > > > > > > > > > >
> > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > For SPL however:
> > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > >       |                          ^
> > > > > > > > > > > >
> > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > >
> > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > across all phases.
> > > > > > > > > > >
> > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > >
> > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > >
> > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > >
> > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > >
> > > > > > > > Agreed.
> > > > > > > >
> > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > >
> > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > but not yet).
> > > > > > >
> > > > > > > OK
> > > > > > >
> > > > > > > >
> > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > Kconfig.
> > > > > > > >
> > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > >
> > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > hunt for SPL_FOO, etc.
> > > > > > >
> > > > > > > >
> > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > >
> > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > big deal, and should be fixed.
> > > > > > >
> > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > >
> > > > > > > >
> > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > >
> > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > fs/Makefile is an example of this.
> > > > > > >
> > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > >
> > > > > > > >
> > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > >
> > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > >
> > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > >
> > > > > > > We have this rule:
> > > > > > >
> > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > >
> > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > >
> > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > needs to be fixed.
> > > > > > >
> > > > > > > >
> > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > working here but not there?".
> > > > > > >
> > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > that subdir? I don't know what this is about.
> > > > > > >
> > > > > > > >
> > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > >
> > > > > > > Or we could finish and apply my series, which does this.
> > > > > > >
> > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > which to use of those question.
> > > > > > >
> > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > and XPL_ altogether.
> > > > > > >
> > > > > > > > And update / expand upon the existing
> > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > file. Or if we need to do something radical there.
> > > > > > >
> > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > antichrist either.
> > > > > >
> > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > cure is worse than the disease.
> > > > >
> > > > > To me the core issue is whether to completely split the defconfig
> > > > > files. I am quite worried about that. You are quite worried about the
> > > > > confusion my series will cause.
> > > > >
> > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > bit of work, but could be done over a few releases.
> > > >
> > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > bugs like:
> > > > - Take pinebook-pro-rk3399_defconfig
> > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > >
> > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > why that bug happens. And this is the category of build problems that we
> > > > get that aren't "you missed using the right macro".
> > >
> > > Honestly, what on earth does this have to do with my series?
> >
> > It's that your series doesn't address the real problems we keep having.
> >
> > > The problem happens before and after my series, from what I can tell.
> >
> > Yes, I've said that numerous times.
> >
> > > If you want these sorts of combinations to be tested, perhaps add a
> > > board that enables them, or even rethink your opposition to my
> > > buildman proposal?[4]
> >
> > This isn't relevant to the point I've raised several times now. The
> > failure mode above was reported by two different developers, neither of
> > whom saw how to correctly solve the problem.
> 
> That surprises me a little, as the problem seems pretty fundamental.
> If you don't enable USB_GADGET, then symbols which depend on it don't
> exist.

But they don't want USB_GADGET in PPL. They only want it in SPL.

> > And again, if you tried to solve this problem on your series you might
> > see how what you're proposing will make things worse, not better.
> 
> At least with my scheme you can do something like this:
> 
> config SPL_USB_GADGET
>    bool "USB Gadget Support in SPL"
>    depends on USB_GADGET

That symbol already exists. The problems are around all of the gadget
symbols that don't exist.

> I normally make the SPL symbols depend on PPL, since it normally
> doesn't make a lot of sense to have the feature in SPL unless it is in
> PPL. Is this an exception to that rule?

This half of the problem (you're still missing the other half of the
problem, the DWC3 code being built in TPL now and throwing
warnings-turned-error with -Werror and then discarded at link time) is
one of many examples where we keep having to duplicate symbols in
Kconfig.

> If we do go ahead and enhance Kconfig, then we can combine the two
> symbols, which is something.

Or, we go the direction I suggested instead. Where we never duplicate
symbols, because we never need to anymore.

Or, we step back because believe you're missing the bigger problems.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > >
> > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > >
> > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > across all phases.
> > > > > > > > > > > >
> > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > >
> > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > >
> > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > >
> > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > >
> > > > > > > > > Agreed.
> > > > > > > > >
> > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > >
> > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > but not yet).
> > > > > > > >
> > > > > > > > OK
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > Kconfig.
> > > > > > > > >
> > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > >
> > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > >
> > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > big deal, and should be fixed.
> > > > > > > >
> > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > >
> > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > fs/Makefile is an example of this.
> > > > > > > >
> > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > >
> > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > >
> > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > >
> > > > > > > > We have this rule:
> > > > > > > >
> > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > >
> > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > >
> > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > needs to be fixed.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > working here but not there?".
> > > > > > > >
> > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > that subdir? I don't know what this is about.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > >
> > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > >
> > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > which to use of those question.
> > > > > > > >
> > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > and XPL_ altogether.
> > > > > > > >
> > > > > > > > > And update / expand upon the existing
> > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > >
> > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > antichrist either.
> > > > > > >
> > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > cure is worse than the disease.
> > > > > >
> > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > confusion my series will cause.
> > > > > >
> > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > bit of work, but could be done over a few releases.
> > > > >
> > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > bugs like:
> > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > >
> > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > why that bug happens. And this is the category of build problems that we
> > > > > get that aren't "you missed using the right macro".
> > > >
> > > > Honestly, what on earth does this have to do with my series?
> > >
> > > It's that your series doesn't address the real problems we keep having.
> > >
> > > > The problem happens before and after my series, from what I can tell.
> > >
> > > Yes, I've said that numerous times.
> > >
> > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > board that enables them, or even rethink your opposition to my
> > > > buildman proposal?[4]
> > >
> > > This isn't relevant to the point I've raised several times now. The
> > > failure mode above was reported by two different developers, neither of
> > > whom saw how to correctly solve the problem.
> >
> > That surprises me a little, as the problem seems pretty fundamental.
> > If you don't enable USB_GADGET, then symbols which depend on it don't
> > exist.
>
> But they don't want USB_GADGET in PPL. They only want it in SPL.

That seems to be splitting hairs, but OK. So why not make
USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?

It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
would be the same value? This is once good thing about what we have:
we can share values between phases without typing them in separately.

>
> > > And again, if you tried to solve this problem on your series you might
> > > see how what you're proposing will make things worse, not better.
> >
> > At least with my scheme you can do something like this:
> >
> > config SPL_USB_GADGET
> >    bool "USB Gadget Support in SPL"
> >    depends on USB_GADGET
>
> That symbol already exists. The problems are around all of the gadget
> symbols that don't exist.

OK. But we have to move in steps. We can't do everything at once.

>
> > I normally make the SPL symbols depend on PPL, since it normally
> > doesn't make a lot of sense to have the feature in SPL unless it is in
> > PPL. Is this an exception to that rule?
>
> This half of the problem (you're still missing the other half of the
> problem, the DWC3 code being built in TPL now and throwing
> warnings-turned-error with -Werror and then discarded at link time) is
> one of many examples where we keep having to duplicate symbols in
> Kconfig.

>
> > If we do go ahead and enhance Kconfig, then we can combine the two
> > symbols, which is something.
>
> Or, we go the direction I suggested instead. Where we never duplicate
> symbols, because we never need to anymore.
>
> Or, we step back because believe you're missing the bigger problems.

At this point I'm not sure where to go. You are determined to split
the defconfig files and have grace concerns about my schema. Vice
versa for me.

But my scheme takes us forward without needing to split the
defconfigs. It does offer some benefits IMO. Once we split the
defconfigs we can never put them back together.

Regards,
SImon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 18533 bytes --]

On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > >
> > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > >
> > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > >
> > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > >
> > > > > > > > > > Agreed.
> > > > > > > > > >
> > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > >
> > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > but not yet).
> > > > > > > > >
> > > > > > > > > OK
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > Kconfig.
> > > > > > > > > >
> > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > >
> > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > >
> > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > big deal, and should be fixed.
> > > > > > > > >
> > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > >
> > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > >
> > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > >
> > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > >
> > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > >
> > > > > > > > > We have this rule:
> > > > > > > > >
> > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > >
> > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > >
> > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > needs to be fixed.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > working here but not there?".
> > > > > > > > >
> > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > >
> > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > >
> > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > which to use of those question.
> > > > > > > > >
> > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > and XPL_ altogether.
> > > > > > > > >
> > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > >
> > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > antichrist either.
> > > > > > > >
> > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > cure is worse than the disease.
> > > > > > >
> > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > confusion my series will cause.
> > > > > > >
> > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > bit of work, but could be done over a few releases.
> > > > > >
> > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > bugs like:
> > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > >
> > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > get that aren't "you missed using the right macro".
> > > > >
> > > > > Honestly, what on earth does this have to do with my series?
> > > >
> > > > It's that your series doesn't address the real problems we keep having.
> > > >
> > > > > The problem happens before and after my series, from what I can tell.
> > > >
> > > > Yes, I've said that numerous times.
> > > >
> > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > board that enables them, or even rethink your opposition to my
> > > > > buildman proposal?[4]
> > > >
> > > > This isn't relevant to the point I've raised several times now. The
> > > > failure mode above was reported by two different developers, neither of
> > > > whom saw how to correctly solve the problem.
> > >
> > > That surprises me a little, as the problem seems pretty fundamental.
> > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > exist.
> >
> > But they don't want USB_GADGET in PPL. They only want it in SPL.
> 
> That seems to be splitting hairs, but OK. So why not make
> USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?

Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
VPL_USB_GADGET.

> It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> would be the same value? This is once good thing about what we have:
> we can share values between phases without typing them in separately.

Most of these should be, there may or may not be the questionable case
where one of the ID changes so the host knows what stage things are at.
But that's just an aside.

My point is that drivers/usb/gadget/Kconfig is yet another case where we
need to make it much more complicated so that it works for all the use
cases. And that it's a more common and harder for developers to fix
problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
Makefile?"

> > > > And again, if you tried to solve this problem on your series you might
> > > > see how what you're proposing will make things worse, not better.
> > >
> > > At least with my scheme you can do something like this:
> > >
> > > config SPL_USB_GADGET
> > >    bool "USB Gadget Support in SPL"
> > >    depends on USB_GADGET
> >
> > That symbol already exists. The problems are around all of the gadget
> > symbols that don't exist.
> 
> OK. But we have to move in steps. We can't do everything at once.

Yes, which is why we have so many of these duplicative symbols
(USB_GADGET, SPL_USB_GADGET) and keep needing to add more.

> > > I normally make the SPL symbols depend on PPL, since it normally
> > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > PPL. Is this an exception to that rule?
> >
> > This half of the problem (you're still missing the other half of the
> > problem, the DWC3 code being built in TPL now and throwing
> > warnings-turned-error with -Werror and then discarded at link time) is
> > one of many examples where we keep having to duplicate symbols in
> > Kconfig.
> 
> >
> > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > symbols, which is something.
> >
> > Or, we go the direction I suggested instead. Where we never duplicate
> > symbols, because we never need to anymore.
> >
> > Or, we step back because believe you're missing the bigger problems.
> 
> At this point I'm not sure where to go. You are determined to split
> the defconfig files and have grace concerns about my schema. Vice
> versa for me.
> 
> But my scheme takes us forward without needing to split the
> defconfigs. It does offer some benefits IMO. Once we split the
> defconfigs we can never put them back together.

My continued strongest preference is to do the minimal effort to better
document what we are doing today and add the missing tooling so we don't
keep getting wrong macros in the code. If you're hellbent on doing this
and do it against master and not your personal tree, I'm expecting you
to be available to help clarify problems for developers if they report
them.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > >
> > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > >
> > > > > > > > > > > Agreed.
> > > > > > > > > > >
> > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > >
> > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > but not yet).
> > > > > > > > > >
> > > > > > > > > > OK
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > Kconfig.
> > > > > > > > > > >
> > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > >
> > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > >
> > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > >
> > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > >
> > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > >
> > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > >
> > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > >
> > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > >
> > > > > > > > > > We have this rule:
> > > > > > > > > >
> > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > >
> > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > >
> > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > needs to be fixed.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > working here but not there?".
> > > > > > > > > >
> > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > >
> > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > >
> > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > which to use of those question.
> > > > > > > > > >
> > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > and XPL_ altogether.
> > > > > > > > > >
> > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > >
> > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > antichrist either.
> > > > > > > > >
> > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > cure is worse than the disease.
> > > > > > > >
> > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > confusion my series will cause.
> > > > > > > >
> > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > bit of work, but could be done over a few releases.
> > > > > > >
> > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > bugs like:
> > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > >
> > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > get that aren't "you missed using the right macro".
> > > > > >
> > > > > > Honestly, what on earth does this have to do with my series?
> > > > >
> > > > > It's that your series doesn't address the real problems we keep having.
> > > > >
> > > > > > The problem happens before and after my series, from what I can tell.
> > > > >
> > > > > Yes, I've said that numerous times.
> > > > >
> > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > board that enables them, or even rethink your opposition to my
> > > > > > buildman proposal?[4]
> > > > >
> > > > > This isn't relevant to the point I've raised several times now. The
> > > > > failure mode above was reported by two different developers, neither of
> > > > > whom saw how to correctly solve the problem.
> > > >
> > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > exist.
> > >
> > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> >
> > That seems to be splitting hairs, but OK. So why not make
> > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
>
> Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> VPL_USB_GADGET.

OK

>
> > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > would be the same value? This is once good thing about what we have:
> > we can share values between phases without typing them in separately.
>
> Most of these should be, there may or may not be the questionable case
> where one of the ID changes so the host knows what stage things are at.
> But that's just an aside.
>
> My point is that drivers/usb/gadget/Kconfig is yet another case where we
> need to make it much more complicated so that it works for all the use
> cases. And that it's a more common and harder for developers to fix
> problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> Makefile?"

Yes, I understand that, but this is a tradeoff between that complexity
and the one we would introduce by splitting the defconfigs. Given all
the Kconfig churn it would require just to get things to work, it
isn't a clear win, to say the least.

>
> > > > > And again, if you tried to solve this problem on your series you might
> > > > > see how what you're proposing will make things worse, not better.
> > > >
> > > > At least with my scheme you can do something like this:
> > > >
> > > > config SPL_USB_GADGET
> > > >    bool "USB Gadget Support in SPL"
> > > >    depends on USB_GADGET
> > >
> > > That symbol already exists. The problems are around all of the gadget
> > > symbols that don't exist.
> >
> > OK. But we have to move in steps. We can't do everything at once.
>
> Yes, which is why we have so many of these duplicative symbols
> (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.

Yes, I don't like it either. I believe that if I had been able to land
my solution last time, we would be having different discussions by
now, e.g. how to tidy up the Kconfig without changing the build
system.

>
> > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > PPL. Is this an exception to that rule?
> > >
> > > This half of the problem (you're still missing the other half of the
> > > problem, the DWC3 code being built in TPL now and throwing
> > > warnings-turned-error with -Werror and then discarded at link time) is
> > > one of many examples where we keep having to duplicate symbols in
> > > Kconfig.
> >
> > >
> > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > symbols, which is something.
> > >
> > > Or, we go the direction I suggested instead. Where we never duplicate
> > > symbols, because we never need to anymore.
> > >
> > > Or, we step back because believe you're missing the bigger problems.
> >
> > At this point I'm not sure where to go. You are determined to split
> > the defconfig files and have grace concerns about my schema. Vice
> > versa for me.
> >
> > But my scheme takes us forward without needing to split the
> > defconfigs. It does offer some benefits IMO. Once we split the
> > defconfigs we can never put them back together.
>
> My continued strongest preference is to do the minimal effort to better
> document what we are doing today and add the missing tooling so we don't
> keep getting wrong macros in the code.

I did actually do the tooling in qconfig - give it a try and see what
you think. For documentation, we can discuss that as part of myt
series.

> If you're hellbent on doing this
> and do it against master and not your personal tree, I'm expecting you
> to be available to help clarify problems for developers if they report
> them.

That's fine. I do my development on my own tree, but once I actually
do the series and it is reviewed, I can do a version against -next. As
you know, there are a lot of moving parts, so I would want it to go in
quickly to avoid a lot of rework.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 21411 bytes --]

On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > >
> > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > >
> > > > > > > > > > > > Agreed.
> > > > > > > > > > > >
> > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > >
> > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > but not yet).
> > > > > > > > > > >
> > > > > > > > > > > OK
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > >
> > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > >
> > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > >
> > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > >
> > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > >
> > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > >
> > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > >
> > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > >
> > > > > > > > > > > We have this rule:
> > > > > > > > > > >
> > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > >
> > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > >
> > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > needs to be fixed.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > working here but not there?".
> > > > > > > > > > >
> > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > >
> > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > >
> > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > which to use of those question.
> > > > > > > > > > >
> > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > >
> > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > >
> > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > antichrist either.
> > > > > > > > > >
> > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > cure is worse than the disease.
> > > > > > > > >
> > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > confusion my series will cause.
> > > > > > > > >
> > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > >
> > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > bugs like:
> > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > >
> > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > get that aren't "you missed using the right macro".
> > > > > > >
> > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > >
> > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > >
> > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > >
> > > > > > Yes, I've said that numerous times.
> > > > > >
> > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > buildman proposal?[4]
> > > > > >
> > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > failure mode above was reported by two different developers, neither of
> > > > > > whom saw how to correctly solve the problem.
> > > > >
> > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > exist.
> > > >
> > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > >
> > > That seems to be splitting hairs, but OK. So why not make
> > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> >
> > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > VPL_USB_GADGET.
> 
> OK
> 
> >
> > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > would be the same value? This is once good thing about what we have:
> > > we can share values between phases without typing them in separately.
> >
> > Most of these should be, there may or may not be the questionable case
> > where one of the ID changes so the host knows what stage things are at.
> > But that's just an aside.
> >
> > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > need to make it much more complicated so that it works for all the use
> > cases. And that it's a more common and harder for developers to fix
> > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > Makefile?"
> 
> Yes, I understand that, but this is a tradeoff between that complexity
> and the one we would introduce by splitting the defconfigs. Given all
> the Kconfig churn it would require just to get things to work, it
> isn't a clear win, to say the least.

Since we would be removing stuff from Kconfig with the larger idea I
proposed, I'm not sure what you mean. We wouldn't have this problem at
all with the larger idea.

> > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > see how what you're proposing will make things worse, not better.
> > > > >
> > > > > At least with my scheme you can do something like this:
> > > > >
> > > > > config SPL_USB_GADGET
> > > > >    bool "USB Gadget Support in SPL"
> > > > >    depends on USB_GADGET
> > > >
> > > > That symbol already exists. The problems are around all of the gadget
> > > > symbols that don't exist.
> > >
> > > OK. But we have to move in steps. We can't do everything at once.
> >
> > Yes, which is why we have so many of these duplicative symbols
> > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> 
> Yes, I don't like it either. I believe that if I had been able to land
> my solution last time, we would be having different discussions by
> now, e.g. how to tidy up the Kconfig without changing the build
> system.

I strongly doubt it.

> > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > PPL. Is this an exception to that rule?
> > > >
> > > > This half of the problem (you're still missing the other half of the
> > > > problem, the DWC3 code being built in TPL now and throwing
> > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > one of many examples where we keep having to duplicate symbols in
> > > > Kconfig.
> > >
> > > >
> > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > symbols, which is something.
> > > >
> > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > symbols, because we never need to anymore.
> > > >
> > > > Or, we step back because believe you're missing the bigger problems.
> > >
> > > At this point I'm not sure where to go. You are determined to split
> > > the defconfig files and have grace concerns about my schema. Vice
> > > versa for me.
> > >
> > > But my scheme takes us forward without needing to split the
> > > defconfigs. It does offer some benefits IMO. Once we split the
> > > defconfigs we can never put them back together.
> >
> > My continued strongest preference is to do the minimal effort to better
> > document what we are doing today and add the missing tooling so we don't
> > keep getting wrong macros in the code.
> 
> I did actually do the tooling in qconfig - give it a try and see what
> you think. For documentation, we can discuss that as part of myt
> series.

The missing tooling is things like:
https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/

I'm not sure what qconfig features you're talking about.

> > If you're hellbent on doing this
> > and do it against master and not your personal tree, I'm expecting you
> > to be available to help clarify problems for developers if they report
> > them.
> 
> That's fine. I do my development on my own tree, but once I actually
> do the series and it is reviewed, I can do a version against -next. As
> you know, there are a lot of moving parts, so I would want it to go in
> quickly to avoid a lot of rework.

Just don't post things that aren't against next, when you have something
as that makes review impossible for the rest of us.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 27 Feb 2025 at 10:17, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > > but not yet).
> > > > > > > > > > > >
> > > > > > > > > > > > OK
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > > >
> > > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > > >
> > > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > > >
> > > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > > >
> > > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > > >
> > > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > > >
> > > > > > > > > > > > We have this rule:
> > > > > > > > > > > >
> > > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > > >
> > > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > > >
> > > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > > needs to be fixed.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > > working here but not there?".
> > > > > > > > > > > >
> > > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > > >
> > > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > > >
> > > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > > which to use of those question.
> > > > > > > > > > > >
> > > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > > >
> > > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > > >
> > > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > > antichrist either.
> > > > > > > > > > >
> > > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > > cure is worse than the disease.
> > > > > > > > > >
> > > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > > confusion my series will cause.
> > > > > > > > > >
> > > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > > >
> > > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > > bugs like:
> > > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > > >
> > > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > > get that aren't "you missed using the right macro".
> > > > > > > >
> > > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > > >
> > > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > > >
> > > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > > >
> > > > > > > Yes, I've said that numerous times.
> > > > > > >
> > > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > > buildman proposal?[4]
> > > > > > >
> > > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > > failure mode above was reported by two different developers, neither of
> > > > > > > whom saw how to correctly solve the problem.
> > > > > >
> > > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > > exist.
> > > > >
> > > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > > >
> > > > That seems to be splitting hairs, but OK. So why not make
> > > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> > >
> > > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > > VPL_USB_GADGET.
> >
> > OK
> >
> > >
> > > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > > would be the same value? This is once good thing about what we have:
> > > > we can share values between phases without typing them in separately.
> > >
> > > Most of these should be, there may or may not be the questionable case
> > > where one of the ID changes so the host knows what stage things are at.
> > > But that's just an aside.
> > >
> > > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > > need to make it much more complicated so that it works for all the use
> > > cases. And that it's a more common and harder for developers to fix
> > > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > > Makefile?"
> >
> > Yes, I understand that, but this is a tradeoff between that complexity
> > and the one we would introduce by splitting the defconfigs. Given all
> > the Kconfig churn it would require just to get things to work, it
> > isn't a clear win, to say the least.
>
> Since we would be removing stuff from Kconfig with the larger idea I
> proposed, I'm not sure what you mean. We wouldn't have this problem at
> all with the larger idea.

But we have other problems, mainly that we cannot easily use an option
from one phase in another, so need to duplicate all such options, then
add tooling to try to keep them in sync, except when we don't want
them in sync, etc. Are you sure you have thought this through all the
way?

>
> > > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > > see how what you're proposing will make things worse, not better.
> > > > > >
> > > > > > At least with my scheme you can do something like this:
> > > > > >
> > > > > > config SPL_USB_GADGET
> > > > > >    bool "USB Gadget Support in SPL"
> > > > > >    depends on USB_GADGET
> > > > >
> > > > > That symbol already exists. The problems are around all of the gadget
> > > > > symbols that don't exist.
> > > >
> > > > OK. But we have to move in steps. We can't do everything at once.
> > >
> > > Yes, which is why we have so many of these duplicative symbols
> > > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> >
> > Yes, I don't like it either. I believe that if I had been able to land
> > my solution last time, we would be having different discussions by
> > now, e.g. how to tidy up the Kconfig without changing the build
> > system.
>
> I strongly doubt it.

I know you do, but I could be right about this.

>
> > > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > > PPL. Is this an exception to that rule?
> > > > >
> > > > > This half of the problem (you're still missing the other half of the
> > > > > problem, the DWC3 code being built in TPL now and throwing
> > > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > > one of many examples where we keep having to duplicate symbols in
> > > > > Kconfig.
> > > >
> > > > >
> > > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > > symbols, which is something.
> > > > >
> > > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > > symbols, because we never need to anymore.
> > > > >
> > > > > Or, we step back because believe you're missing the bigger problems.
> > > >
> > > > At this point I'm not sure where to go. You are determined to split
> > > > the defconfig files and have grace concerns about my schema. Vice
> > > > versa for me.
> > > >
> > > > But my scheme takes us forward without needing to split the
> > > > defconfigs. It does offer some benefits IMO. Once we split the
> > > > defconfigs we can never put them back together.
> > >
> > > My continued strongest preference is to do the minimal effort to better
> > > document what we are doing today and add the missing tooling so we don't
> > > keep getting wrong macros in the code.
> >
> > I did actually do the tooling in qconfig - give it a try and see what
> > you think. For documentation, we can discuss that as part of myt
> > series.
>
> The missing tooling is things like:
> https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/

Well that's good to have anyway.

>
> I'm not sure what qconfig features you're talking about.

It is qconfig --scan-source which prints a lot of warnings.

>
> > > If you're hellbent on doing this
> > > and do it against master and not your personal tree, I'm expecting you
> > > to be available to help clarify problems for developers if they report
> > > them.
> >
> > That's fine. I do my development on my own tree, but once I actually
> > do the series and it is reviewed, I can do a version against -next. As
> > you know, there are a lot of moving parts, so I would want it to go in
> > quickly to avoid a lot of rework.
>
> Just don't post things that aren't against next, when you have something
> as that makes review impossible for the rest of us.

I had thought we agreed that to minimise differences you would review
patches that I sent from my tree?

Anyway I'm going to do what you suggest and see how it goes.

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 24835 bytes --]

On Thu, Feb 27, 2025 at 12:32:42PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 27 Feb 2025 at 10:17, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > > > but not yet).
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We have this rule:
> > > > > > > > > > > > >
> > > > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > > > >
> > > > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > > > needs to be fixed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > > > working here but not there?".
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > > > which to use of those question.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > > > >
> > > > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > > > antichrist either.
> > > > > > > > > > > >
> > > > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > > > cure is worse than the disease.
> > > > > > > > > > >
> > > > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > > > confusion my series will cause.
> > > > > > > > > > >
> > > > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > > > >
> > > > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > > > bugs like:
> > > > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > > > >
> > > > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > > > get that aren't "you missed using the right macro".
> > > > > > > > >
> > > > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > > > >
> > > > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > > > >
> > > > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > > > >
> > > > > > > > Yes, I've said that numerous times.
> > > > > > > >
> > > > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > > > buildman proposal?[4]
> > > > > > > >
> > > > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > > > failure mode above was reported by two different developers, neither of
> > > > > > > > whom saw how to correctly solve the problem.
> > > > > > >
> > > > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > > > exist.
> > > > > >
> > > > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > > > >
> > > > > That seems to be splitting hairs, but OK. So why not make
> > > > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> > > >
> > > > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > > > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > > > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > > > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > > > VPL_USB_GADGET.
> > >
> > > OK
> > >
> > > >
> > > > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > > > would be the same value? This is once good thing about what we have:
> > > > > we can share values between phases without typing them in separately.
> > > >
> > > > Most of these should be, there may or may not be the questionable case
> > > > where one of the ID changes so the host knows what stage things are at.
> > > > But that's just an aside.
> > > >
> > > > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > > > need to make it much more complicated so that it works for all the use
> > > > cases. And that it's a more common and harder for developers to fix
> > > > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > > > Makefile?"
> > >
> > > Yes, I understand that, but this is a tradeoff between that complexity
> > > and the one we would introduce by splitting the defconfigs. Given all
> > > the Kconfig churn it would require just to get things to work, it
> > > isn't a clear win, to say the least.
> >
> > Since we would be removing stuff from Kconfig with the larger idea I
> > proposed, I'm not sure what you mean. We wouldn't have this problem at
> > all with the larger idea.
> 
> But we have other problems, mainly that we cannot easily use an option
> from one phase in another, so need to duplicate all such options, then
> add tooling to try to keep them in sync, except when we don't want
> them in sync, etc. Are you sure you have thought this through all the
> way?

Yes, I have. Because rarely are there cases where we *need* to share a
value from multiple phases *and* we can't have the default be correct.

> > > > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > > > see how what you're proposing will make things worse, not better.
> > > > > > >
> > > > > > > At least with my scheme you can do something like this:
> > > > > > >
> > > > > > > config SPL_USB_GADGET
> > > > > > >    bool "USB Gadget Support in SPL"
> > > > > > >    depends on USB_GADGET
> > > > > >
> > > > > > That symbol already exists. The problems are around all of the gadget
> > > > > > symbols that don't exist.
> > > > >
> > > > > OK. But we have to move in steps. We can't do everything at once.
> > > >
> > > > Yes, which is why we have so many of these duplicative symbols
> > > > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> > >
> > > Yes, I don't like it either. I believe that if I had been able to land
> > > my solution last time, we would be having different discussions by
> > > now, e.g. how to tidy up the Kconfig without changing the build
> > > system.
> >
> > I strongly doubt it.
> 
> I know you do, but I could be right about this.

You could. But you could also be very wrong. And the struggle I've had
with showing you problems other developers have has not left me feeling
great. But I've still said I'll take this but need you to commit to
following up with bug reports.

> > > > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > > > PPL. Is this an exception to that rule?
> > > > > >
> > > > > > This half of the problem (you're still missing the other half of the
> > > > > > problem, the DWC3 code being built in TPL now and throwing
> > > > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > > > one of many examples where we keep having to duplicate symbols in
> > > > > > Kconfig.
> > > > >
> > > > > >
> > > > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > > > symbols, which is something.
> > > > > >
> > > > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > > > symbols, because we never need to anymore.
> > > > > >
> > > > > > Or, we step back because believe you're missing the bigger problems.
> > > > >
> > > > > At this point I'm not sure where to go. You are determined to split
> > > > > the defconfig files and have grace concerns about my schema. Vice
> > > > > versa for me.
> > > > >
> > > > > But my scheme takes us forward without needing to split the
> > > > > defconfigs. It does offer some benefits IMO. Once we split the
> > > > > defconfigs we can never put them back together.
> > > >
> > > > My continued strongest preference is to do the minimal effort to better
> > > > document what we are doing today and add the missing tooling so we don't
> > > > keep getting wrong macros in the code.
> > >
> > > I did actually do the tooling in qconfig - give it a try and see what
> > > you think. For documentation, we can discuss that as part of myt
> > > series.
> >
> > The missing tooling is things like:
> > https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/
> 
> Well that's good to have anyway.
> 
> >
> > I'm not sure what qconfig features you're talking about.
> 
> It is qconfig --scan-source which prints a lot of warnings.

I'm not sure I saw what that was for when it went in. But I'm not sure
how useful that is either. The first section shows some dead code to
remove, which is good. It complains about cases of CONFIG_$(PHASE_)FOO
being used as future-proofing which is not good. And it caught none of
the errors like:
https://patchwork.ozlabs.org/project/uboot/patch/20250226203123.3831960-1-trini@konsulko.com/

And I'm not sure "CONFIG options used as Proper but without a non-xPL_
variant" is a valid variant at all. I'm sure you've found it useful but
I'm not sure it's something I would suggest people run normally.

> > > > If you're hellbent on doing this
> > > > and do it against master and not your personal tree, I'm expecting you
> > > > to be available to help clarify problems for developers if they report
> > > > them.
> > >
> > > That's fine. I do my development on my own tree, but once I actually
> > > do the series and it is reviewed, I can do a version against -next. As
> > > you know, there are a lot of moving parts, so I would want it to go in
> > > quickly to avoid a lot of rework.
> >
> > Just don't post things that aren't against next, when you have something
> > as that makes review impossible for the rest of us.
> 
> I had thought we agreed that to minimise differences you would review
> patches that I sent from my tree?

I said that back when I thought you would default to posting against
the relevant upstream branch and not developer further against your own
tree.

> Anyway I'm going to do what you suggest and see how it goes.

Thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 27 Feb 2025 at 13:30, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Feb 27, 2025 at 12:32:42PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 27 Feb 2025 at 10:17, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > > > > but not yet).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > OK
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > We have this rule:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > > > > needs to be fixed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > > > > working here but not there?".
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > > > > which to use of those question.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > > > > antichrist either.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > > > > cure is worse than the disease.
> > > > > > > > > > > >
> > > > > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > > > > confusion my series will cause.
> > > > > > > > > > > >
> > > > > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > > > > >
> > > > > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > > > > bugs like:
> > > > > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > > > > >
> > > > > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > > > > get that aren't "you missed using the right macro".
> > > > > > > > > >
> > > > > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > > > > >
> > > > > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > > > > >
> > > > > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > > > > >
> > > > > > > > > Yes, I've said that numerous times.
> > > > > > > > >
> > > > > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > > > > buildman proposal?[4]
> > > > > > > > >
> > > > > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > > > > failure mode above was reported by two different developers, neither of
> > > > > > > > > whom saw how to correctly solve the problem.
> > > > > > > >
> > > > > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > > > > exist.
> > > > > > >
> > > > > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > > > > >
> > > > > > That seems to be splitting hairs, but OK. So why not make
> > > > > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> > > > >
> > > > > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > > > > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > > > > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > > > > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > > > > VPL_USB_GADGET.
> > > >
> > > > OK
> > > >
> > > > >
> > > > > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > > > > would be the same value? This is once good thing about what we have:
> > > > > > we can share values between phases without typing them in separately.
> > > > >
> > > > > Most of these should be, there may or may not be the questionable case
> > > > > where one of the ID changes so the host knows what stage things are at.
> > > > > But that's just an aside.
> > > > >
> > > > > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > > > > need to make it much more complicated so that it works for all the use
> > > > > cases. And that it's a more common and harder for developers to fix
> > > > > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > > > > Makefile?"
> > > >
> > > > Yes, I understand that, but this is a tradeoff between that complexity
> > > > and the one we would introduce by splitting the defconfigs. Given all
> > > > the Kconfig churn it would require just to get things to work, it
> > > > isn't a clear win, to say the least.
> > >
> > > Since we would be removing stuff from Kconfig with the larger idea I
> > > proposed, I'm not sure what you mean. We wouldn't have this problem at
> > > all with the larger idea.
> >
> > But we have other problems, mainly that we cannot easily use an option
> > from one phase in another, so need to duplicate all such options, then
> > add tooling to try to keep them in sync, except when we don't want
> > them in sync, etc. Are you sure you have thought this through all the
> > way?
>
> Yes, I have. Because rarely are there cases where we *need* to share a
> value from multiple phases *and* we can't have the default be correct.

You're likely right about this, but I can imagine it being quite
painful for the cases where we do need something. We could have some
kconfig tooling which prints a list of those cases, perhaps.

>
> > > > > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > > > > see how what you're proposing will make things worse, not better.
> > > > > > > >
> > > > > > > > At least with my scheme you can do something like this:
> > > > > > > >
> > > > > > > > config SPL_USB_GADGET
> > > > > > > >    bool "USB Gadget Support in SPL"
> > > > > > > >    depends on USB_GADGET
> > > > > > >
> > > > > > > That symbol already exists. The problems are around all of the gadget
> > > > > > > symbols that don't exist.
> > > > > >
> > > > > > OK. But we have to move in steps. We can't do everything at once.
> > > > >
> > > > > Yes, which is why we have so many of these duplicative symbols
> > > > > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> > > >
> > > > Yes, I don't like it either. I believe that if I had been able to land
> > > > my solution last time, we would be having different discussions by
> > > > now, e.g. how to tidy up the Kconfig without changing the build
> > > > system.
> > >
> > > I strongly doubt it.
> >
> > I know you do, but I could be right about this.
>
> You could. But you could also be very wrong. And the struggle I've had
> with showing you problems other developers have has not left me feeling
> great. But I've still said I'll take this but need you to commit to
> following up with bug reports.

I'm happy to follow up with bug reports.

>
> > > > > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > > > > PPL. Is this an exception to that rule?
> > > > > > >
> > > > > > > This half of the problem (you're still missing the other half of the
> > > > > > > problem, the DWC3 code being built in TPL now and throwing
> > > > > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > > > > one of many examples where we keep having to duplicate symbols in
> > > > > > > Kconfig.
> > > > > >
> > > > > > >
> > > > > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > > > > symbols, which is something.
> > > > > > >
> > > > > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > > > > symbols, because we never need to anymore.
> > > > > > >
> > > > > > > Or, we step back because believe you're missing the bigger problems.
> > > > > >
> > > > > > At this point I'm not sure where to go. You are determined to split
> > > > > > the defconfig files and have grace concerns about my schema. Vice
> > > > > > versa for me.
> > > > > >
> > > > > > But my scheme takes us forward without needing to split the
> > > > > > defconfigs. It does offer some benefits IMO. Once we split the
> > > > > > defconfigs we can never put them back together.
> > > > >
> > > > > My continued strongest preference is to do the minimal effort to better
> > > > > document what we are doing today and add the missing tooling so we don't
> > > > > keep getting wrong macros in the code.
> > > >
> > > > I did actually do the tooling in qconfig - give it a try and see what
> > > > you think. For documentation, we can discuss that as part of myt
> > > > series.
> > >
> > > The missing tooling is things like:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/
> >
> > Well that's good to have anyway.
> >
> > >
> > > I'm not sure what qconfig features you're talking about.
> >
> > It is qconfig --scan-source which prints a lot of warnings.
>
> I'm not sure I saw what that was for when it went in. But I'm not sure
> how useful that is either. The first section shows some dead code to
> remove, which is good. It complains about cases of CONFIG_$(PHASE_)FOO
> being used as future-proofing which is not good. And it caught none of
> the errors like:
> https://patchwork.ozlabs.org/project/uboot/patch/20250226203123.3831960-1-trini@konsulko.com/
>
> And I'm not sure "CONFIG options used as Proper but without a non-xPL_
> variant" is a valid variant at all. I'm sure you've found it useful but
> I'm not sure it's something I would suggest people run normally.

The tool identifies problems which cause build errors (or changes in
the effective value of Kconfig options).

>
> > > > > If you're hellbent on doing this
> > > > > and do it against master and not your personal tree, I'm expecting you
> > > > > to be available to help clarify problems for developers if they report
> > > > > them.
> > > >
> > > > That's fine. I do my development on my own tree, but once I actually
> > > > do the series and it is reviewed, I can do a version against -next. As
> > > > you know, there are a lot of moving parts, so I would want it to go in
> > > > quickly to avoid a lot of rework.
> > >
> > > Just don't post things that aren't against next, when you have something
> > > as that makes review impossible for the rest of us.
> >
> > I had thought we agreed that to minimise differences you would review
> > patches that I sent from my tree?
>
> I said that back when I thought you would default to posting against
> the relevant upstream branch and not developer further against your own
> tree.

That's not what I intended you to think. We should look to find some
way to do this via pull requests.

>
> > Anyway I'm going to do what you suggest and see how it goes.
>
> Thanks.

Regards,
SImon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 27606 bytes --]

On Tue, Mar 04, 2025 at 08:35:29AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 27 Feb 2025 at 13:30, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Feb 27, 2025 at 12:32:42PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 27 Feb 2025 at 10:17, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > > > > > but not yet).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > OK
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > We have this rule:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > > > > > needs to be fixed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > > > > > working here but not there?".
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > > > > > which to use of those question.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > > > > > antichrist either.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > > > > > cure is worse than the disease.
> > > > > > > > > > > > >
> > > > > > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > > > > > confusion my series will cause.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > > > > > >
> > > > > > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > > > > > bugs like:
> > > > > > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > > > > > >
> > > > > > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > > > > > get that aren't "you missed using the right macro".
> > > > > > > > > > >
> > > > > > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > > > > > >
> > > > > > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > > > > > >
> > > > > > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > > > > > >
> > > > > > > > > > Yes, I've said that numerous times.
> > > > > > > > > >
> > > > > > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > > > > > buildman proposal?[4]
> > > > > > > > > >
> > > > > > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > > > > > failure mode above was reported by two different developers, neither of
> > > > > > > > > > whom saw how to correctly solve the problem.
> > > > > > > > >
> > > > > > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > > > > > exist.
> > > > > > > >
> > > > > > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > > > > > >
> > > > > > > That seems to be splitting hairs, but OK. So why not make
> > > > > > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> > > > > >
> > > > > > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > > > > > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > > > > > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > > > > > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > > > > > VPL_USB_GADGET.
> > > > >
> > > > > OK
> > > > >
> > > > > >
> > > > > > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > > > > > would be the same value? This is once good thing about what we have:
> > > > > > > we can share values between phases without typing them in separately.
> > > > > >
> > > > > > Most of these should be, there may or may not be the questionable case
> > > > > > where one of the ID changes so the host knows what stage things are at.
> > > > > > But that's just an aside.
> > > > > >
> > > > > > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > > > > > need to make it much more complicated so that it works for all the use
> > > > > > cases. And that it's a more common and harder for developers to fix
> > > > > > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > > > > > Makefile?"
> > > > >
> > > > > Yes, I understand that, but this is a tradeoff between that complexity
> > > > > and the one we would introduce by splitting the defconfigs. Given all
> > > > > the Kconfig churn it would require just to get things to work, it
> > > > > isn't a clear win, to say the least.
> > > >
> > > > Since we would be removing stuff from Kconfig with the larger idea I
> > > > proposed, I'm not sure what you mean. We wouldn't have this problem at
> > > > all with the larger idea.
> > >
> > > But we have other problems, mainly that we cannot easily use an option
> > > from one phase in another, so need to duplicate all such options, then
> > > add tooling to try to keep them in sync, except when we don't want
> > > them in sync, etc. Are you sure you have thought this through all the
> > > way?
> >
> > Yes, I have. Because rarely are there cases where we *need* to share a
> > value from multiple phases *and* we can't have the default be correct.
> 
> You're likely right about this, but I can imagine it being quite
> painful for the cases where we do need something. We could have some
> kconfig tooling which prints a list of those cases, perhaps.
> 
> >
> > > > > > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > > > > > see how what you're proposing will make things worse, not better.
> > > > > > > > >
> > > > > > > > > At least with my scheme you can do something like this:
> > > > > > > > >
> > > > > > > > > config SPL_USB_GADGET
> > > > > > > > >    bool "USB Gadget Support in SPL"
> > > > > > > > >    depends on USB_GADGET
> > > > > > > >
> > > > > > > > That symbol already exists. The problems are around all of the gadget
> > > > > > > > symbols that don't exist.
> > > > > > >
> > > > > > > OK. But we have to move in steps. We can't do everything at once.
> > > > > >
> > > > > > Yes, which is why we have so many of these duplicative symbols
> > > > > > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> > > > >
> > > > > Yes, I don't like it either. I believe that if I had been able to land
> > > > > my solution last time, we would be having different discussions by
> > > > > now, e.g. how to tidy up the Kconfig without changing the build
> > > > > system.
> > > >
> > > > I strongly doubt it.
> > >
> > > I know you do, but I could be right about this.
> >
> > You could. But you could also be very wrong. And the struggle I've had
> > with showing you problems other developers have has not left me feeling
> > great. But I've still said I'll take this but need you to commit to
> > following up with bug reports.
> 
> I'm happy to follow up with bug reports.
> 
> >
> > > > > > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > > > > > PPL. Is this an exception to that rule?
> > > > > > > >
> > > > > > > > This half of the problem (you're still missing the other half of the
> > > > > > > > problem, the DWC3 code being built in TPL now and throwing
> > > > > > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > > > > > one of many examples where we keep having to duplicate symbols in
> > > > > > > > Kconfig.
> > > > > > >
> > > > > > > >
> > > > > > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > > > > > symbols, which is something.
> > > > > > > >
> > > > > > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > > > > > symbols, because we never need to anymore.
> > > > > > > >
> > > > > > > > Or, we step back because believe you're missing the bigger problems.
> > > > > > >
> > > > > > > At this point I'm not sure where to go. You are determined to split
> > > > > > > the defconfig files and have grace concerns about my schema. Vice
> > > > > > > versa for me.
> > > > > > >
> > > > > > > But my scheme takes us forward without needing to split the
> > > > > > > defconfigs. It does offer some benefits IMO. Once we split the
> > > > > > > defconfigs we can never put them back together.
> > > > > >
> > > > > > My continued strongest preference is to do the minimal effort to better
> > > > > > document what we are doing today and add the missing tooling so we don't
> > > > > > keep getting wrong macros in the code.
> > > > >
> > > > > I did actually do the tooling in qconfig - give it a try and see what
> > > > > you think. For documentation, we can discuss that as part of myt
> > > > > series.
> > > >
> > > > The missing tooling is things like:
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/
> > >
> > > Well that's good to have anyway.
> > >
> > > >
> > > > I'm not sure what qconfig features you're talking about.
> > >
> > > It is qconfig --scan-source which prints a lot of warnings.
> >
> > I'm not sure I saw what that was for when it went in. But I'm not sure
> > how useful that is either. The first section shows some dead code to
> > remove, which is good. It complains about cases of CONFIG_$(PHASE_)FOO
> > being used as future-proofing which is not good. And it caught none of
> > the errors like:
> > https://patchwork.ozlabs.org/project/uboot/patch/20250226203123.3831960-1-trini@konsulko.com/
> >
> > And I'm not sure "CONFIG options used as Proper but without a non-xPL_
> > variant" is a valid variant at all. I'm sure you've found it useful but
> > I'm not sure it's something I would suggest people run normally.
> 
> The tool identifies problems which cause build errors (or changes in
> the effective value of Kconfig options).

Along with lots of false positives. I'm not saying there's nothing of
use here, but I am saying that for example "make this produce no output"
is neither a feasible nor good goal.

> > > > > > If you're hellbent on doing this
> > > > > > and do it against master and not your personal tree, I'm expecting you
> > > > > > to be available to help clarify problems for developers if they report
> > > > > > them.
> > > > >
> > > > > That's fine. I do my development on my own tree, but once I actually
> > > > > do the series and it is reviewed, I can do a version against -next. As
> > > > > you know, there are a lot of moving parts, so I would want it to go in
> > > > > quickly to avoid a lot of rework.
> > > >
> > > > Just don't post things that aren't against next, when you have something
> > > > as that makes review impossible for the rest of us.
> > >
> > > I had thought we agreed that to minimise differences you would review
> > > patches that I sent from my tree?
> >
> > I said that back when I thought you would default to posting against
> > the relevant upstream branch and not developer further against your own
> > tree.
> 
> That's not what I intended you to think. We should look to find some
> way to do this via pull requests.

Well, you used to put things in u-boot-dm, that had been reviewed or at
least not rejected by others, and send me a pull request. Along the way
you stopped doing that. You could start again, and that would be
helpful. If you find the "u-boot-dm" part too restrictive adding
contributor/sjg/ namespace is easy (and someone else had suggested this
in another thread, even).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Tue, 4 Mar 2025 at 09:25, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Mar 04, 2025 at 08:35:29AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 27 Feb 2025 at 13:30, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 27, 2025 at 12:32:42PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 27 Feb 2025 at 10:17, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > > > > > > but not yet).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > OK
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > We have this rule:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > > > > > > needs to be fixed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > > > > > > working here but not there?".
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > > > > > > which to use of those question.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > > > > > > antichrist either.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > > > > > > cure is worse than the disease.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > > > > > > confusion my series will cause.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > > > > > > bugs like:
> > > > > > > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > > > > > > get that aren't "you missed using the right macro".
> > > > > > > > > > > >
> > > > > > > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > > > > > > >
> > > > > > > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > > > > > > >
> > > > > > > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > > > > > > >
> > > > > > > > > > > Yes, I've said that numerous times.
> > > > > > > > > > >
> > > > > > > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > > > > > > buildman proposal?[4]
> > > > > > > > > > >
> > > > > > > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > > > > > > failure mode above was reported by two different developers, neither of
> > > > > > > > > > > whom saw how to correctly solve the problem.
> > > > > > > > > >
> > > > > > > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > > > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > > > > > > exist.
> > > > > > > > >
> > > > > > > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > > > > > > >
> > > > > > > > That seems to be splitting hairs, but OK. So why not make
> > > > > > > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> > > > > > >
> > > > > > > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > > > > > > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > > > > > > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > > > > > > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > > > > > > VPL_USB_GADGET.
> > > > > >
> > > > > > OK
> > > > > >
> > > > > > >
> > > > > > > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > > > > > > would be the same value? This is once good thing about what we have:
> > > > > > > > we can share values between phases without typing them in separately.
> > > > > > >
> > > > > > > Most of these should be, there may or may not be the questionable case
> > > > > > > where one of the ID changes so the host knows what stage things are at.
> > > > > > > But that's just an aside.
> > > > > > >
> > > > > > > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > > > > > > need to make it much more complicated so that it works for all the use
> > > > > > > cases. And that it's a more common and harder for developers to fix
> > > > > > > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > > > > > > Makefile?"
> > > > > >
> > > > > > Yes, I understand that, but this is a tradeoff between that complexity
> > > > > > and the one we would introduce by splitting the defconfigs. Given all
> > > > > > the Kconfig churn it would require just to get things to work, it
> > > > > > isn't a clear win, to say the least.
> > > > >
> > > > > Since we would be removing stuff from Kconfig with the larger idea I
> > > > > proposed, I'm not sure what you mean. We wouldn't have this problem at
> > > > > all with the larger idea.
> > > >
> > > > But we have other problems, mainly that we cannot easily use an option
> > > > from one phase in another, so need to duplicate all such options, then
> > > > add tooling to try to keep them in sync, except when we don't want
> > > > them in sync, etc. Are you sure you have thought this through all the
> > > > way?
> > >
> > > Yes, I have. Because rarely are there cases where we *need* to share a
> > > value from multiple phases *and* we can't have the default be correct.
> >
> > You're likely right about this, but I can imagine it being quite
> > painful for the cases where we do need something. We could have some
> > kconfig tooling which prints a list of those cases, perhaps.
> >
> > >
> > > > > > > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > > > > > > see how what you're proposing will make things worse, not better.
> > > > > > > > > >
> > > > > > > > > > At least with my scheme you can do something like this:
> > > > > > > > > >
> > > > > > > > > > config SPL_USB_GADGET
> > > > > > > > > >    bool "USB Gadget Support in SPL"
> > > > > > > > > >    depends on USB_GADGET
> > > > > > > > >
> > > > > > > > > That symbol already exists. The problems are around all of the gadget
> > > > > > > > > symbols that don't exist.
> > > > > > > >
> > > > > > > > OK. But we have to move in steps. We can't do everything at once.
> > > > > > >
> > > > > > > Yes, which is why we have so many of these duplicative symbols
> > > > > > > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> > > > > >
> > > > > > Yes, I don't like it either. I believe that if I had been able to land
> > > > > > my solution last time, we would be having different discussions by
> > > > > > now, e.g. how to tidy up the Kconfig without changing the build
> > > > > > system.
> > > > >
> > > > > I strongly doubt it.
> > > >
> > > > I know you do, but I could be right about this.
> > >
> > > You could. But you could also be very wrong. And the struggle I've had
> > > with showing you problems other developers have has not left me feeling
> > > great. But I've still said I'll take this but need you to commit to
> > > following up with bug reports.
> >
> > I'm happy to follow up with bug reports.
> >
> > >
> > > > > > > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > > > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > > > > > > PPL. Is this an exception to that rule?
> > > > > > > > >
> > > > > > > > > This half of the problem (you're still missing the other half of the
> > > > > > > > > problem, the DWC3 code being built in TPL now and throwing
> > > > > > > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > > > > > > one of many examples where we keep having to duplicate symbols in
> > > > > > > > > Kconfig.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > > > > > > symbols, which is something.
> > > > > > > > >
> > > > > > > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > > > > > > symbols, because we never need to anymore.
> > > > > > > > >
> > > > > > > > > Or, we step back because believe you're missing the bigger problems.
> > > > > > > >
> > > > > > > > At this point I'm not sure where to go. You are determined to split
> > > > > > > > the defconfig files and have grace concerns about my schema. Vice
> > > > > > > > versa for me.
> > > > > > > >
> > > > > > > > But my scheme takes us forward without needing to split the
> > > > > > > > defconfigs. It does offer some benefits IMO. Once we split the
> > > > > > > > defconfigs we can never put them back together.
> > > > > > >
> > > > > > > My continued strongest preference is to do the minimal effort to better
> > > > > > > document what we are doing today and add the missing tooling so we don't
> > > > > > > keep getting wrong macros in the code.
> > > > > >
> > > > > > I did actually do the tooling in qconfig - give it a try and see what
> > > > > > you think. For documentation, we can discuss that as part of myt
> > > > > > series.
> > > > >
> > > > > The missing tooling is things like:
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/
> > > >
> > > > Well that's good to have anyway.
> > > >
> > > > >
> > > > > I'm not sure what qconfig features you're talking about.
> > > >
> > > > It is qconfig --scan-source which prints a lot of warnings.
> > >
> > > I'm not sure I saw what that was for when it went in. But I'm not sure
> > > how useful that is either. The first section shows some dead code to
> > > remove, which is good. It complains about cases of CONFIG_$(PHASE_)FOO
> > > being used as future-proofing which is not good. And it caught none of
> > > the errors like:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20250226203123.3831960-1-trini@konsulko.com/
> > >
> > > And I'm not sure "CONFIG options used as Proper but without a non-xPL_
> > > variant" is a valid variant at all. I'm sure you've found it useful but
> > > I'm not sure it's something I would suggest people run normally.
> >
> > The tool identifies problems which cause build errors (or changes in
> > the effective value of Kconfig options).
>
> Along with lots of false positives. I'm not saying there's nothing of
> use here, but I am saying that for example "make this produce no output"
> is neither a feasible nor good goal.

OK. I didn't actually say that it was though.

>
> > > > > > > If you're hellbent on doing this
> > > > > > > and do it against master and not your personal tree, I'm expecting you
> > > > > > > to be available to help clarify problems for developers if they report
> > > > > > > them.
> > > > > >
> > > > > > That's fine. I do my development on my own tree, but once I actually
> > > > > > do the series and it is reviewed, I can do a version against -next. As
> > > > > > you know, there are a lot of moving parts, so I would want it to go in
> > > > > > quickly to avoid a lot of rework.
> > > > >
> > > > > Just don't post things that aren't against next, when you have something
> > > > > as that makes review impossible for the rest of us.
> > > >
> > > > I had thought we agreed that to minimise differences you would review
> > > > patches that I sent from my tree?
> > >
> > > I said that back when I thought you would default to posting against
> > > the relevant upstream branch and not developer further against your own
> > > tree.
> >
> > That's not what I intended you to think. We should look to find some
> > way to do this via pull requests.
>
> Well, you used to put things in u-boot-dm, that had been reviewed or at
> least not rejected by others, and send me a pull request. Along the way
> you stopped doing that. You could start again, and that would be
> helpful. If you find the "u-boot-dm" part too restrictive adding
> contributor/sjg/ namespace is easy (and someone else had suggested this
> in another thread, even).

I don't mind creating a PR if it will keep our trees more in sync. I
do need my own tree though, since some patches have already been
completely rejected. I finally figured out how to rename it so that
sjg.u-boot.org doesn't give strange errors anymore.

So it seems to me that this thread is complete. Does that sound right?
I probably need to wait until you have finished your Kconfig clean-up
stuff, but then I should take a crack at it?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 30130 bytes --]

On Wed, Mar 05, 2025 at 07:17:51AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 4 Mar 2025 at 09:25, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Mar 04, 2025 at 08:35:29AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 27 Feb 2025 at 13:30, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Feb 27, 2025 at 12:32:42PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 27 Feb 2025 at 10:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > > > > > > > but not yet).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > OK
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > We have this rule:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > > > > > > > needs to be fixed.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > > > > > > > working here but not there?".
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > > > > > > > which to use of those question.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > > > > > > > antichrist either.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > > > > > > > cure is worse than the disease.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > > > > > > > confusion my series will cause.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > > > > > > > bugs like:
> > > > > > > > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > > > > > > > get that aren't "you missed using the right macro".
> > > > > > > > > > > > >
> > > > > > > > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > > > > > > > >
> > > > > > > > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > > > > > > > >
> > > > > > > > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, I've said that numerous times.
> > > > > > > > > > > >
> > > > > > > > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > > > > > > > buildman proposal?[4]
> > > > > > > > > > > >
> > > > > > > > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > > > > > > > failure mode above was reported by two different developers, neither of
> > > > > > > > > > > > whom saw how to correctly solve the problem.
> > > > > > > > > > >
> > > > > > > > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > > > > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > > > > > > > exist.
> > > > > > > > > >
> > > > > > > > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > > > > > > > >
> > > > > > > > > That seems to be splitting hairs, but OK. So why not make
> > > > > > > > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> > > > > > > >
> > > > > > > > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > > > > > > > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > > > > > > > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > > > > > > > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > > > > > > > VPL_USB_GADGET.
> > > > > > >
> > > > > > > OK
> > > > > > >
> > > > > > > >
> > > > > > > > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > > > > > > > would be the same value? This is once good thing about what we have:
> > > > > > > > > we can share values between phases without typing them in separately.
> > > > > > > >
> > > > > > > > Most of these should be, there may or may not be the questionable case
> > > > > > > > where one of the ID changes so the host knows what stage things are at.
> > > > > > > > But that's just an aside.
> > > > > > > >
> > > > > > > > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > > > > > > > need to make it much more complicated so that it works for all the use
> > > > > > > > cases. And that it's a more common and harder for developers to fix
> > > > > > > > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > > > > > > > Makefile?"
> > > > > > >
> > > > > > > Yes, I understand that, but this is a tradeoff between that complexity
> > > > > > > and the one we would introduce by splitting the defconfigs. Given all
> > > > > > > the Kconfig churn it would require just to get things to work, it
> > > > > > > isn't a clear win, to say the least.
> > > > > >
> > > > > > Since we would be removing stuff from Kconfig with the larger idea I
> > > > > > proposed, I'm not sure what you mean. We wouldn't have this problem at
> > > > > > all with the larger idea.
> > > > >
> > > > > But we have other problems, mainly that we cannot easily use an option
> > > > > from one phase in another, so need to duplicate all such options, then
> > > > > add tooling to try to keep them in sync, except when we don't want
> > > > > them in sync, etc. Are you sure you have thought this through all the
> > > > > way?
> > > >
> > > > Yes, I have. Because rarely are there cases where we *need* to share a
> > > > value from multiple phases *and* we can't have the default be correct.
> > >
> > > You're likely right about this, but I can imagine it being quite
> > > painful for the cases where we do need something. We could have some
> > > kconfig tooling which prints a list of those cases, perhaps.
> > >
> > > >
> > > > > > > > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > > > > > > > see how what you're proposing will make things worse, not better.
> > > > > > > > > > >
> > > > > > > > > > > At least with my scheme you can do something like this:
> > > > > > > > > > >
> > > > > > > > > > > config SPL_USB_GADGET
> > > > > > > > > > >    bool "USB Gadget Support in SPL"
> > > > > > > > > > >    depends on USB_GADGET
> > > > > > > > > >
> > > > > > > > > > That symbol already exists. The problems are around all of the gadget
> > > > > > > > > > symbols that don't exist.
> > > > > > > > >
> > > > > > > > > OK. But we have to move in steps. We can't do everything at once.
> > > > > > > >
> > > > > > > > Yes, which is why we have so many of these duplicative symbols
> > > > > > > > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> > > > > > >
> > > > > > > Yes, I don't like it either. I believe that if I had been able to land
> > > > > > > my solution last time, we would be having different discussions by
> > > > > > > now, e.g. how to tidy up the Kconfig without changing the build
> > > > > > > system.
> > > > > >
> > > > > > I strongly doubt it.
> > > > >
> > > > > I know you do, but I could be right about this.
> > > >
> > > > You could. But you could also be very wrong. And the struggle I've had
> > > > with showing you problems other developers have has not left me feeling
> > > > great. But I've still said I'll take this but need you to commit to
> > > > following up with bug reports.
> > >
> > > I'm happy to follow up with bug reports.
> > >
> > > >
> > > > > > > > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > > > > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > > > > > > > PPL. Is this an exception to that rule?
> > > > > > > > > >
> > > > > > > > > > This half of the problem (you're still missing the other half of the
> > > > > > > > > > problem, the DWC3 code being built in TPL now and throwing
> > > > > > > > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > > > > > > > one of many examples where we keep having to duplicate symbols in
> > > > > > > > > > Kconfig.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > > > > > > > symbols, which is something.
> > > > > > > > > >
> > > > > > > > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > > > > > > > symbols, because we never need to anymore.
> > > > > > > > > >
> > > > > > > > > > Or, we step back because believe you're missing the bigger problems.
> > > > > > > > >
> > > > > > > > > At this point I'm not sure where to go. You are determined to split
> > > > > > > > > the defconfig files and have grace concerns about my schema. Vice
> > > > > > > > > versa for me.
> > > > > > > > >
> > > > > > > > > But my scheme takes us forward without needing to split the
> > > > > > > > > defconfigs. It does offer some benefits IMO. Once we split the
> > > > > > > > > defconfigs we can never put them back together.
> > > > > > > >
> > > > > > > > My continued strongest preference is to do the minimal effort to better
> > > > > > > > document what we are doing today and add the missing tooling so we don't
> > > > > > > > keep getting wrong macros in the code.
> > > > > > >
> > > > > > > I did actually do the tooling in qconfig - give it a try and see what
> > > > > > > you think. For documentation, we can discuss that as part of myt
> > > > > > > series.
> > > > > >
> > > > > > The missing tooling is things like:
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/
> > > > >
> > > > > Well that's good to have anyway.
> > > > >
> > > > > >
> > > > > > I'm not sure what qconfig features you're talking about.
> > > > >
> > > > > It is qconfig --scan-source which prints a lot of warnings.
> > > >
> > > > I'm not sure I saw what that was for when it went in. But I'm not sure
> > > > how useful that is either. The first section shows some dead code to
> > > > remove, which is good. It complains about cases of CONFIG_$(PHASE_)FOO
> > > > being used as future-proofing which is not good. And it caught none of
> > > > the errors like:
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20250226203123.3831960-1-trini@konsulko.com/
> > > >
> > > > And I'm not sure "CONFIG options used as Proper but without a non-xPL_
> > > > variant" is a valid variant at all. I'm sure you've found it useful but
> > > > I'm not sure it's something I would suggest people run normally.
> > >
> > > The tool identifies problems which cause build errors (or changes in
> > > the effective value of Kconfig options).
> >
> > Along with lots of false positives. I'm not saying there's nothing of
> > use here, but I am saying that for example "make this produce no output"
> > is neither a feasible nor good goal.
> 
> OK. I didn't actually say that it was though.
> 
> >
> > > > > > > > If you're hellbent on doing this
> > > > > > > > and do it against master and not your personal tree, I'm expecting you
> > > > > > > > to be available to help clarify problems for developers if they report
> > > > > > > > them.
> > > > > > >
> > > > > > > That's fine. I do my development on my own tree, but once I actually
> > > > > > > do the series and it is reviewed, I can do a version against -next. As
> > > > > > > you know, there are a lot of moving parts, so I would want it to go in
> > > > > > > quickly to avoid a lot of rework.
> > > > > >
> > > > > > Just don't post things that aren't against next, when you have something
> > > > > > as that makes review impossible for the rest of us.
> > > > >
> > > > > I had thought we agreed that to minimise differences you would review
> > > > > patches that I sent from my tree?
> > > >
> > > > I said that back when I thought you would default to posting against
> > > > the relevant upstream branch and not developer further against your own
> > > > tree.
> > >
> > > That's not what I intended you to think. We should look to find some
> > > way to do this via pull requests.
> >
> > Well, you used to put things in u-boot-dm, that had been reviewed or at
> > least not rejected by others, and send me a pull request. Along the way
> > you stopped doing that. You could start again, and that would be
> > helpful. If you find the "u-boot-dm" part too restrictive adding
> > contributor/sjg/ namespace is easy (and someone else had suggested this
> > in another thread, even).
> 
> I don't mind creating a PR if it will keep our trees more in sync. I
> do need my own tree though, since some patches have already been
> completely rejected. I finally figured out how to rename it so that
> sjg.u-boot.org doesn't give strange errors anymore.

It's a step in the right direction, yes.

> So it seems to me that this thread is complete. Does that sound right?
> I probably need to wait until you have finished your Kconfig clean-up
> stuff, but then I should take a crack at it?

Do you mean the PHASE_ rename I posted?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Wed, 5 Mar 2025 at 08:49, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Mar 05, 2025 at 07:17:51AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 4 Mar 2025 at 09:25, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Mar 04, 2025 at 08:35:29AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 27 Feb 2025 at 13:30, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Feb 27, 2025 at 12:32:42PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 27 Feb 2025 at 10:17, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 27, 2025 at 09:24:45AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Wed, 26 Feb 2025 at 07:53, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Feb 25, 2025 at 07:51:07PM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Tue, 25 Feb 2025 at 14:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 25, 2025 at 02:33:17PM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 25 Feb 2025 at 07:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Feb 24, 2025 at 04:38:50PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, 24 Feb 2025 at 09:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 07:07:06PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 18:06, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 05:24:35PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 17:03, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 04:35:16PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi  Tom,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > > > > > [snip]
> > > > > > > > > > > > > > > > > > > > > > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > > > > > > > > > > > > > > > > > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > > > > > > > > > > > > > > > > > > > > > problems I had seen previously.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > > > > > > > > > > > > > > > > > > > > > updated. Still needs more work.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > > > > > > > > > > > > > > > > > > > > > changes, here's another example of the problem with your approach. What
> > > > > > > > > > > > > > > > > > > > > > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > > > > > > > > > > > > > > > > > > > > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > > > > > > > > > > > > > > > > > > > > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > > > > > > > > > > > > > > > > > > > > > up, but that's maybe just a missing Makefile dependency line. But that
> > > > > > > > > > > > > > > > > > > > > > > just makes it easier to see the next problem, which I don't see the
> > > > > > > > > > > > > > > > > > > > > > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > > > > > > > > > > > > > > > > > > > > > For SPL however:
> > > > > > > > > > > > > > > > > > > > > > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > > > > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > > > > > > > > > > > > > > > > > > > > > >       |                      ^
> > > > > > > > > > > > > > > > > > > > > > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > > > > > > > > > > > > > > > > > > > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > > > > > > > > > > > > > > > > > > > > > >       |                          ^
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > And I don't see, really, what's even getting us down this error path.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > > > > > > > > > > > > > > > > > > > > > across all phases.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I pushed a new tree which builds without the warning. Note that
> > > > > > > > > > > > > > > > > > > > > > SPL_SPI is enabled.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> > > > > > > > > > > > > > > > > > > > > scripts/conf_nospl is going to be a problem in and of itself, and likely
> > > > > > > > > > > > > > > > > > > > > as confusing if not more-so than any of the in-the-end visible changes.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Yes, perhaps the key point I've been trying to get across is this confusion.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > As you know, at present we have two types of options:
> > > > > > > > > > > > > > > > > > > > a) those for which each phase has its own value
> > > > > > > > > > > > > > > > > > > > b) those for which there is a single value shared across all phases
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Agreed.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The only way today that you can tell them apart is by looking for uses
> > > > > > > > > > > > > > > > > > > > of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Partially agreed. Those are strong indicators that both CONFIG_FOO and
> > > > > > > > > > > > > > > > > > > CONFIG_SPL_FOO exist, but not always. We have, intentionally, both the
> > > > > > > > > > > > > > > > > > > inverse case (CONFIG_SPL_BAR and CONFIG_TPL_BAR exist, CONFIG_BAR does
> > > > > > > > > > > > > > > > > > > not) and some future-proofing (CONFIG_SPL_BAZ may exist in the future,
> > > > > > > > > > > > > > > > > > > but not yet).
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > OK
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > then the option is a) otherwise it is b). There is no way to tell from
> > > > > > > > > > > > > > > > > > > > Kconfig.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Kconfig will happily allow "depends on BOGUS_SYMBOL" yes, and a linter
> > > > > > > > > > > > > > > > > > > would be a handy thing to have. But you're mentioning this in another
> > > > > > > > > > > > > > > > > > > context, why we need some additional knowledge somewhere.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > What I meant was that we don't have anything in the Kconfig for FOO
> > > > > > > > > > > > > > > > > > that says this is a global option or an xPL-specific one. We have to
> > > > > > > > > > > > > > > > > > hunt for SPL_FOO, etc.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Also, some parts of the code may use CONFIG_IS_ENABLED() for
> > > > > > > > > > > > > > > > > > > > an option, some may use IS_ENABLED() for that same option. Some may
> > > > > > > > > > > > > > > > > > > > use $(PHASE_) and some may not. It's a bit of a mess.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'm sure you can find some examples where we have CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) and it's not intentional, but that's not a
> > > > > > > > > > > > > > > > > > > big deal, and should be fixed.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But this is largely the point of my series. It's the reason why
> > > > > > > > > > > > > > > > > > qconfig is able to locate these cases and warn about them. It is a big
> > > > > > > > > > > > > > > > > > deal, IMO, or at least big enough for me to attempt this.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'm only going to rant slightly that checkpatch.pl telling people to use
> > > > > > > > > > > > > > > > > > > these macros has made the situation worse, not better, out of an
> > > > > > > > > > > > > > > > > > > ingrained need to silence checkpatch.pl.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > And what you're missing is that sometimes we intentionally don't want
> > > > > > > > > > > > > > > > > > > $(PHASE_), or would need to rewrite the Makefile to make use of it.
> > > > > > > > > > > > > > > > > > > fs/Makefile is an example of this.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The next step from my side would be to get rid of the 'ifdef
> > > > > > > > > > > > > > > > > > CONFIG_XPL_BUILD' in the Makefiles. It's confusing and annoying.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Stepping back a bit, perhaps the goal of my series is to identify
> > > > > > > > > > > > > > > > > > > > options in b) so we can deal with them in a better way. They are all
> > > > > > > > > > > > > > > > > > > > listed in conf_nospl, in preparation for some future action.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > There are two big problems here. The first of which is that conf_nospl,
> > > > > > > > > > > > > > > > > > > as a concept, is going to be incomplete. Do you list every CMD in there?
> > > > > > > > > > > > > > > > > > > Why? They'll never be in a non-PPL phase. It will be its own nightmare
> > > > > > > > > > > > > > > > > > > to keep correct, once it is bug-compatible with what we have today.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This is actually the *nice* thing about conf_nospl. We should reduce
> > > > > > > > > > > > > > > > > > it to empty, just like we did with the Kconfig whitelist.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > We have this rule:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > libs-$(CONFIG_CMDLINE) += cmd/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > which is enough for most things. The only issue is that sometimes,
> > > > > > > > > > > > > > > > > > e.g. with CONFIG_CMD_DHCP it doesn't mean the command at all.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So I don't agree at all that my series is a 'big problem'. It is a
> > > > > > > > > > > > > > > > > > solution to the current confusion and it shows up what is broken and
> > > > > > > > > > > > > > > > > > needs to be fixed.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The second big problem is that it doesn't make it any easier to solve
> > > > > > > > > > > > > > > > > > > what I keep calling the DWC3 problem. It's a valid use case that two
> > > > > > > > > > > > > > > > > > > developers have hit independently of wanting to enable USB gadget
> > > > > > > > > > > > > > > > > > > support (and the HW uses DWC3) in SPL and not PPL. Not only are you not
> > > > > > > > > > > > > > > > > > > solving this problem, it gets worse to solve. Today it's "OK, I need to
> > > > > > > > > > > > > > > > > > > find where to move obj-$(CONFIG_FOO) to be more visible and
> > > > > > > > > > > > > > > > > > > obj-$(CONFIG_$(PHASE_)FOO". Tomorrow it's "Why isn't obj-$(CONFIG_FOO)
> > > > > > > > > > > > > > > > > > > working here but not there?".
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Is that because some Makefile higher in the hierarchy is not building
> > > > > > > > > > > > > > > > > > that subdir? I don't know what this is about.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To me, at absolute best case here, we're making a lot of changes and
> > > > > > > > > > > > > > > > > > > spending a lot of time to not really address the underlying problems,
> > > > > > > > > > > > > > > > > > > just making some questionable value visibility changes. We could reduce
> > > > > > > > > > > > > > > > > > > ourselves to one macro by saying only ever use CONFIG_IS_ENABLED(FOO)
> > > > > > > > > > > > > > > > > > > and IS_ENABLED(CONFIG_FOO) goes back to an ifdef for the case where it
> > > > > > > > > > > > > > > > > > > must only be tested on CONFIG_FOO.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Or we could finish and apply my series, which does this.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'm 80% sure we could simplify all of
> > > > > > > > > > > > > > > > > > > $(PHASE_)/$(XPL_)/$(SPL_) down to just $(PHASE_) and that eliminates the
> > > > > > > > > > > > > > > > > > > which to use of those question.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Again, let's apply my series, which actually gets rid of PHASE_, SPL_
> > > > > > > > > > > > > > > > > > and XPL_ altogether.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > And update / expand upon the existing
> > > > > > > > > > > > > > > > > > > documentation we have as it's not clear enough for everyone. Then we can
> > > > > > > > > > > > > > > > > > > think, again, about how to solve the problems that are introduced by
> > > > > > > > > > > > > > > > > > > building our entire source tree N times from a single configuration
> > > > > > > > > > > > > > > > > > > file. Or if we need to do something radical there.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > At this point I'm getting the feeling that you imagine my series is
> > > > > > > > > > > > > > > > > > some grand unified plan for Kconfig. It really isn't and this thread
> > > > > > > > > > > > > > > > > > is reminding me of why I originally wrote it. Bear in mind it was over
> > > > > > > > > > > > > > > > > > two years ago and I have mostly forgotten all the issues. It is a
> > > > > > > > > > > > > > > > > > clean-up series. It isn't the second coming but it isn't the
> > > > > > > > > > > > > > > > > > antichrist either.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I worry you're going to spend another month of effort to get this to 1:1
> > > > > > > > > > > > > > > > > compatibility (modulo fixing bugs) with what we have today and get
> > > > > > > > > > > > > > > > > disappointed once it rolls out to -next. But I guess I've already spent
> > > > > > > > > > > > > > > > > too much time trying to convince you this is a bad idea and that your
> > > > > > > > > > > > > > > > > cure is worse than the disease.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To me the core issue is whether to completely split the defconfig
> > > > > > > > > > > > > > > > files. I am quite worried about that. You are quite worried about the
> > > > > > > > > > > > > > > > confusion my series will cause.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think it is reasonable, if we go with my series, that I drive
> > > > > > > > > > > > > > > > conf_nospl down to zero lines (and remove the feature) before going
> > > > > > > > > > > > > > > > any further. Would that make you more comfortable? It would be a fair
> > > > > > > > > > > > > > > > bit of work, but could be done over a few releases.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Here is my core concern. Can macros be tricky? Yes. Do we need a
> > > > > > > > > > > > > > > checkpatch.pl test for 'IS_ENABLED(FOO)' ? Yes. But the real problem is
> > > > > > > > > > > > > > > bugs like:
> > > > > > > > > > > > > > > - Take pinebook-pro-rk3399_defconfig
> > > > > > > > > > > > > > > - Enable all 3 of: CONFIG_SPL_USB_DWC3_GENERIC CONFIG_SPL_USB_GADGET
> > > > > > > > > > > > > > >   CONFIG_SPL_USB_SDP_SUPPORT
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your proposal neither fixes that bug nor makes it easier to understand
> > > > > > > > > > > > > > > why that bug happens. And this is the category of build problems that we
> > > > > > > > > > > > > > > get that aren't "you missed using the right macro".
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Honestly, what on earth does this have to do with my series?
> > > > > > > > > > > > >
> > > > > > > > > > > > > It's that your series doesn't address the real problems we keep having.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > The problem happens before and after my series, from what I can tell.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, I've said that numerous times.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > If you want these sorts of combinations to be tested, perhaps add a
> > > > > > > > > > > > > > board that enables them, or even rethink your opposition to my
> > > > > > > > > > > > > > buildman proposal?[4]
> > > > > > > > > > > > >
> > > > > > > > > > > > > This isn't relevant to the point I've raised several times now. The
> > > > > > > > > > > > > failure mode above was reported by two different developers, neither of
> > > > > > > > > > > > > whom saw how to correctly solve the problem.
> > > > > > > > > > > >
> > > > > > > > > > > > That surprises me a little, as the problem seems pretty fundamental.
> > > > > > > > > > > > If you don't enable USB_GADGET, then symbols which depend on it don't
> > > > > > > > > > > > exist.
> > > > > > > > > > >
> > > > > > > > > > > But they don't want USB_GADGET in PPL. They only want it in SPL.
> > > > > > > > > >
> > > > > > > > > > That seems to be splitting hairs, but OK. So why not make
> > > > > > > > > > USB_GADGET_MANUFACTURER depend on USB_GADGET || SPL_USB_GADGET ?
> > > > > > > > >
> > > > > > > > > Yes, the solution today involves reworking drivers/usb/gadget/Kconfig so
> > > > > > > > > that USB_GADGET_MANUFACTURER, USB_GADGET_VENDOR_NUM,
> > > > > > > > > USB_GADGET_PRODUCT_NUM, USB_GADGET_VBUS_DRAW and that might be it, are
> > > > > > > > > exposed to USB_GADGET || SPL_USB_GADGET and possibly down the line
> > > > > > > > > VPL_USB_GADGET.
> > > > > > > >
> > > > > > > > OK
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > It wouldn't make sense to add SPL_USB_GADGET_MANUFACTURER as surely it
> > > > > > > > > > would be the same value? This is once good thing about what we have:
> > > > > > > > > > we can share values between phases without typing them in separately.
> > > > > > > > >
> > > > > > > > > Most of these should be, there may or may not be the questionable case
> > > > > > > > > where one of the ID changes so the host knows what stage things are at.
> > > > > > > > > But that's just an aside.
> > > > > > > > >
> > > > > > > > > My point is that drivers/usb/gadget/Kconfig is yet another case where we
> > > > > > > > > need to make it much more complicated so that it works for all the use
> > > > > > > > > cases. And that it's a more common and harder for developers to fix
> > > > > > > > > problem than "Do I use $(SPL_TPL_) I mean $(PHASE_) or $(XPL_) in the
> > > > > > > > > Makefile?"
> > > > > > > >
> > > > > > > > Yes, I understand that, but this is a tradeoff between that complexity
> > > > > > > > and the one we would introduce by splitting the defconfigs. Given all
> > > > > > > > the Kconfig churn it would require just to get things to work, it
> > > > > > > > isn't a clear win, to say the least.
> > > > > > >
> > > > > > > Since we would be removing stuff from Kconfig with the larger idea I
> > > > > > > proposed, I'm not sure what you mean. We wouldn't have this problem at
> > > > > > > all with the larger idea.
> > > > > >
> > > > > > But we have other problems, mainly that we cannot easily use an option
> > > > > > from one phase in another, so need to duplicate all such options, then
> > > > > > add tooling to try to keep them in sync, except when we don't want
> > > > > > them in sync, etc. Are you sure you have thought this through all the
> > > > > > way?
> > > > >
> > > > > Yes, I have. Because rarely are there cases where we *need* to share a
> > > > > value from multiple phases *and* we can't have the default be correct.
> > > >
> > > > You're likely right about this, but I can imagine it being quite
> > > > painful for the cases where we do need something. We could have some
> > > > kconfig tooling which prints a list of those cases, perhaps.
> > > >
> > > > >
> > > > > > > > > > > > > And again, if you tried to solve this problem on your series you might
> > > > > > > > > > > > > see how what you're proposing will make things worse, not better.
> > > > > > > > > > > >
> > > > > > > > > > > > At least with my scheme you can do something like this:
> > > > > > > > > > > >
> > > > > > > > > > > > config SPL_USB_GADGET
> > > > > > > > > > > >    bool "USB Gadget Support in SPL"
> > > > > > > > > > > >    depends on USB_GADGET
> > > > > > > > > > >
> > > > > > > > > > > That symbol already exists. The problems are around all of the gadget
> > > > > > > > > > > symbols that don't exist.
> > > > > > > > > >
> > > > > > > > > > OK. But we have to move in steps. We can't do everything at once.
> > > > > > > > >
> > > > > > > > > Yes, which is why we have so many of these duplicative symbols
> > > > > > > > > (USB_GADGET, SPL_USB_GADGET) and keep needing to add more.
> > > > > > > >
> > > > > > > > Yes, I don't like it either. I believe that if I had been able to land
> > > > > > > > my solution last time, we would be having different discussions by
> > > > > > > > now, e.g. how to tidy up the Kconfig without changing the build
> > > > > > > > system.
> > > > > > >
> > > > > > > I strongly doubt it.
> > > > > >
> > > > > > I know you do, but I could be right about this.
> > > > >
> > > > > You could. But you could also be very wrong. And the struggle I've had
> > > > > with showing you problems other developers have has not left me feeling
> > > > > great. But I've still said I'll take this but need you to commit to
> > > > > following up with bug reports.
> > > >
> > > > I'm happy to follow up with bug reports.
> > > >
> > > > >
> > > > > > > > > > > > I normally make the SPL symbols depend on PPL, since it normally
> > > > > > > > > > > > doesn't make a lot of sense to have the feature in SPL unless it is in
> > > > > > > > > > > > PPL. Is this an exception to that rule?
> > > > > > > > > > >
> > > > > > > > > > > This half of the problem (you're still missing the other half of the
> > > > > > > > > > > problem, the DWC3 code being built in TPL now and throwing
> > > > > > > > > > > warnings-turned-error with -Werror and then discarded at link time) is
> > > > > > > > > > > one of many examples where we keep having to duplicate symbols in
> > > > > > > > > > > Kconfig.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > If we do go ahead and enhance Kconfig, then we can combine the two
> > > > > > > > > > > > symbols, which is something.
> > > > > > > > > > >
> > > > > > > > > > > Or, we go the direction I suggested instead. Where we never duplicate
> > > > > > > > > > > symbols, because we never need to anymore.
> > > > > > > > > > >
> > > > > > > > > > > Or, we step back because believe you're missing the bigger problems.
> > > > > > > > > >
> > > > > > > > > > At this point I'm not sure where to go. You are determined to split
> > > > > > > > > > the defconfig files and have grace concerns about my schema. Vice
> > > > > > > > > > versa for me.
> > > > > > > > > >
> > > > > > > > > > But my scheme takes us forward without needing to split the
> > > > > > > > > > defconfigs. It does offer some benefits IMO. Once we split the
> > > > > > > > > > defconfigs we can never put them back together.
> > > > > > > > >
> > > > > > > > > My continued strongest preference is to do the minimal effort to better
> > > > > > > > > document what we are doing today and add the missing tooling so we don't
> > > > > > > > > keep getting wrong macros in the code.
> > > > > > > >
> > > > > > > > I did actually do the tooling in qconfig - give it a try and see what
> > > > > > > > you think. For documentation, we can discuss that as part of myt
> > > > > > > > series.
> > > > > > >
> > > > > > > The missing tooling is things like:
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250226153346.2736160-1-trini@konsulko.com/
> > > > > >
> > > > > > Well that's good to have anyway.
> > > > > >
> > > > > > >
> > > > > > > I'm not sure what qconfig features you're talking about.
> > > > > >
> > > > > > It is qconfig --scan-source which prints a lot of warnings.
> > > > >
> > > > > I'm not sure I saw what that was for when it went in. But I'm not sure
> > > > > how useful that is either. The first section shows some dead code to
> > > > > remove, which is good. It complains about cases of CONFIG_$(PHASE_)FOO
> > > > > being used as future-proofing which is not good. And it caught none of
> > > > > the errors like:
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250226203123.3831960-1-trini@konsulko.com/
> > > > >
> > > > > And I'm not sure "CONFIG options used as Proper but without a non-xPL_
> > > > > variant" is a valid variant at all. I'm sure you've found it useful but
> > > > > I'm not sure it's something I would suggest people run normally.
> > > >
> > > > The tool identifies problems which cause build errors (or changes in
> > > > the effective value of Kconfig options).
> > >
> > > Along with lots of false positives. I'm not saying there's nothing of
> > > use here, but I am saying that for example "make this produce no output"
> > > is neither a feasible nor good goal.
> >
> > OK. I didn't actually say that it was though.
> >
> > >
> > > > > > > > > If you're hellbent on doing this
> > > > > > > > > and do it against master and not your personal tree, I'm expecting you
> > > > > > > > > to be available to help clarify problems for developers if they report
> > > > > > > > > them.
> > > > > > > >
> > > > > > > > That's fine. I do my development on my own tree, but once I actually
> > > > > > > > do the series and it is reviewed, I can do a version against -next. As
> > > > > > > > you know, there are a lot of moving parts, so I would want it to go in
> > > > > > > > quickly to avoid a lot of rework.
> > > > > > >
> > > > > > > Just don't post things that aren't against next, when you have something
> > > > > > > as that makes review impossible for the rest of us.
> > > > > >
> > > > > > I had thought we agreed that to minimise differences you would review
> > > > > > patches that I sent from my tree?
> > > > >
> > > > > I said that back when I thought you would default to posting against
> > > > > the relevant upstream branch and not developer further against your own
> > > > > tree.
> > > >
> > > > That's not what I intended you to think. We should look to find some
> > > > way to do this via pull requests.
> > >
> > > Well, you used to put things in u-boot-dm, that had been reviewed or at
> > > least not rejected by others, and send me a pull request. Along the way
> > > you stopped doing that. You could start again, and that would be
> > > helpful. If you find the "u-boot-dm" part too restrictive adding
> > > contributor/sjg/ namespace is easy (and someone else had suggested this
> > > in another thread, even).
> >
> > I don't mind creating a PR if it will keep our trees more in sync. I
> > do need my own tree though, since some patches have already been
> > completely rejected. I finally figured out how to rename it so that
> > sjg.u-boot.org doesn't give strange errors anymore.
>
> It's a step in the right direction, yes.
>
> > So it seems to me that this thread is complete. Does that sound right?
> > I probably need to wait until you have finished your Kconfig clean-up
> > stuff, but then I should take a crack at it?
>
> Do you mean the PHASE_ rename I posted?

Yes, I need to wait until you get your fixes and rework in, then I can
start from there.

Regards,
Simon

Re: xPL Proposal

[Marek Vasut]

On 2/11/25 4:03 PM, Simon Glass wrote:
> Hi,

Hi,

> I just wanted to send a note to (re-)introduce my ideas[1] for the
> next iteration of xPL.
> 
> A recent series introduced 'xPL' as the name for the various
> pre-U-Boot phases

Can xPL build also U-Boot "side-stages" , like for example 
self-contained blob which contains all the __secure material currently 
placed in separate linker section of U-Boot? It could be used to produce 
e.g. self-standing PSCI provider built from U-Boot code base.

[...]

Re: xPL Proposal

[Simon Glass]

Hi Marek,

On Tue, 11 Feb 2025 at 19:13, Marek Vasut <marex@denx.de> wrote:
>
> On 2/11/25 4:03 PM, Simon Glass wrote:
> > Hi,
>
> Hi,
>
> > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > next iteration of xPL.
> >
> > A recent series introduced 'xPL' as the name for the various
> > pre-U-Boot phases
>
> Can xPL build also U-Boot "side-stages" , like for example
> self-contained blob which contains all the __secure material currently
> placed in separate linker section of U-Boot? It could be used to produce
> e.g. self-standing PSCI provider built from U-Boot code base.

Not yet, but with the work described here, yes. Ideally you would just
add a new phase to the Kconfig and everything would magically work.
I'd like to do the same for EFI runtime code.

>
> [...]

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]

On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:

> Hi,
> 
> I just wanted to send a note to (re-)introduce my ideas[1] for the
> next iteration of xPL.
> 
> A recent series introduced 'xPL' as the name for the various
> pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> still use filenames and function naming which uses 'spl', but could
> potentially adjust that.
> 
> The major remaining problem IMO is that it is quite tricky and
> expensive (in terms of time) to add a new phase. We also have some
> medium-sized problems:
> 
> a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> can be confusing, particularly when combined with ifdef and ifneq
> 
> b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> different things. For any given option, some code uses one and some
> the other, depending on what problems people have met along the way.
> 
> c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> the option is enabled in one or more xPL phases, or just in U-Boot
> proper. The only way to know is to look for $(PHASE_) etc. in the
> Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> and has not scaled well.
> 
> d. We need to retain an important feature: options from different
> phases can depend on each other. As an example, we might want to
> enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> may also want to share values between phases, such as TEXT_BASE. We
> can do this easily today, just by adding Kconfig rules.
> 
> Proposal
> 
> 1. Adjust kconf to generate separate autoconf.h files for each phase.
> These contain the values for each Kconfig option for that phase. For
> example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> 
> 2. Add a file to resolve the ambiguity in (c) above, listing the
> Kconfig options which should not be enabled/valid in any xPL build.
> There are around 200 of these.
> 
> 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> useful in rare cases. This indicates that the option applies only to
> U-Boot proper and is not defined in any xPL build. It is analogous to
> CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> needed at present, basically to allow access to the value for another
> phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> the address to which U-Boot should be loaded.
> 
> 4. There is no change to the existing defconfig files, or 'make
> menuconfig', which works just as today, including dependencies between
> options across all phases.
> 
> 5. (next) Expand the Kconfig language[2] to support declaring phases
> (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> declared once for any/all phases. We can then drop the file in 2
> above.
> 
> With this, maintaining Kconfig options, Makefiles and adding a new
> phase should be considerably easier.

Here is the big problem I see with your proposal. Today our Kbuild and
kconfig support is very much out of date. And while my attempts to
resync them together haven't worked, I believe it comes down to how we
build *pl targets today, at least in part, because that's just not
a thing upstream has to do. What you're proposing here will make any
future resyncs even harder as more of the code will diverge from
upstream (as seen in your previous RFC series).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Simon Glass]

Hi Tom,

On Thu, 13 Feb 2025 at 07:15, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
>
> > Hi,
> >
> > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > next iteration of xPL.
> >
> > A recent series introduced 'xPL' as the name for the various
> > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > still use filenames and function naming which uses 'spl', but could
> > potentially adjust that.
> >
> > The major remaining problem IMO is that it is quite tricky and
> > expensive (in terms of time) to add a new phase. We also have some
> > medium-sized problems:
> >
> > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > can be confusing, particularly when combined with ifdef and ifneq
> >
> > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > different things. For any given option, some code uses one and some
> > the other, depending on what problems people have met along the way.
> >
> > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > the option is enabled in one or more xPL phases, or just in U-Boot
> > proper. The only way to know is to look for $(PHASE_) etc. in the
> > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > and has not scaled well.
> >
> > d. We need to retain an important feature: options from different
> > phases can depend on each other. As an example, we might want to
> > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > may also want to share values between phases, such as TEXT_BASE. We
> > can do this easily today, just by adding Kconfig rules.
> >
> > Proposal
> >
> > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > These contain the values for each Kconfig option for that phase. For
> > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> >
> > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > Kconfig options which should not be enabled/valid in any xPL build.
> > There are around 200 of these.
> >
> > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > useful in rare cases. This indicates that the option applies only to
> > U-Boot proper and is not defined in any xPL build. It is analogous to
> > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > needed at present, basically to allow access to the value for another
> > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > the address to which U-Boot should be loaded.
> >
> > 4. There is no change to the existing defconfig files, or 'make
> > menuconfig', which works just as today, including dependencies between
> > options across all phases.
> >
> > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > declared once for any/all phases. We can then drop the file in 2
> > above.
> >
> > With this, maintaining Kconfig options, Makefiles and adding a new
> > phase should be considerably easier.
>
> Here is the big problem I see with your proposal. Today our Kbuild and
> kconfig support is very much out of date. And while my attempts to
> resync them together haven't worked, I believe it comes down to how we
> build *pl targets today, at least in part, because that's just not
> a thing upstream has to do. What you're proposing here will make any
> future resyncs even harder as more of the code will diverge from
> upstream (as seen in your previous RFC series).

Yes, that's true, but mostly in kconfig. I would be willing to resync
kconfig with Linux, if that helps.

For kbuild, my series doesn't do much there. I could perhaps offer a
resync of fixdep.c ?

Did Linaro show any interest in taking on Kbuild? Linux just has a
huge amount of build-code now. What problems do you have with U-Boot's
current Kbuild?

Regards,
Simon

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5004 bytes --]

On Thu, Feb 13, 2025 at 07:33:20AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 13 Feb 2025 at 07:15, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:
> >
> > > Hi,
> > >
> > > I just wanted to send a note to (re-)introduce my ideas[1] for the
> > > next iteration of xPL.
> > >
> > > A recent series introduced 'xPL' as the name for the various
> > > pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> > > phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> > > still use filenames and function naming which uses 'spl', but could
> > > potentially adjust that.
> > >
> > > The major remaining problem IMO is that it is quite tricky and
> > > expensive (in terms of time) to add a new phase. We also have some
> > > medium-sized problems:
> > >
> > > a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> > > can be confusing, particularly when combined with ifdef and ifneq
> > >
> > > b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> > > different things. For any given option, some code uses one and some
> > > the other, depending on what problems people have met along the way.
> > >
> > > c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> > > the option is enabled in one or more xPL phases, or just in U-Boot
> > > proper. The only way to know is to look for $(PHASE_) etc. in the
> > > Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> > > and has not scaled well.
> > >
> > > d. We need to retain an important feature: options from different
> > > phases can depend on each other. As an example, we might want to
> > > enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> > > may also want to share values between phases, such as TEXT_BASE. We
> > > can do this easily today, just by adding Kconfig rules.
> > >
> > > Proposal
> > >
> > > 1. Adjust kconf to generate separate autoconf.h files for each phase.
> > > These contain the values for each Kconfig option for that phase. For
> > > example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> > >
> > > 2. Add a file to resolve the ambiguity in (c) above, listing the
> > > Kconfig options which should not be enabled/valid in any xPL build.
> > > There are around 200 of these.
> > >
> > > 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> > > useful in rare cases. This indicates that the option applies only to
> > > U-Boot proper and is not defined in any xPL build. It is analogous to
> > > CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> > > needed at present, basically to allow access to the value for another
> > > phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> > > the address to which U-Boot should be loaded.
> > >
> > > 4. There is no change to the existing defconfig files, or 'make
> > > menuconfig', which works just as today, including dependencies between
> > > options across all phases.
> > >
> > > 5. (next) Expand the Kconfig language[2] to support declaring phases
> > > (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> > > SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> > > declared once for any/all phases. We can then drop the file in 2
> > > above.
> > >
> > > With this, maintaining Kconfig options, Makefiles and adding a new
> > > phase should be considerably easier.
> >
> > Here is the big problem I see with your proposal. Today our Kbuild and
> > kconfig support is very much out of date. And while my attempts to
> > resync them together haven't worked, I believe it comes down to how we
> > build *pl targets today, at least in part, because that's just not
> > a thing upstream has to do. What you're proposing here will make any
> > future resyncs even harder as more of the code will diverge from
> > upstream (as seen in your previous RFC series).
> 
> Yes, that's true, but mostly in kconfig. I would be willing to resync
> kconfig with Linux, if that helps.

Yes, re-syncing scripts/kconfig to v6.13 (as a stand alone series) would
be helpful, thanks.

> For kbuild, my series doesn't do much there. I could perhaps offer a
> resync of fixdep.c ?

That's another part of the infrastructure that is out of date, yes.

> Did Linaro show any interest in taking on Kbuild? Linux just has a
> huge amount of build-code now. What problems do you have with U-Boot's
> current Kbuild?

Yes, it's somewhere on various people's "would like to do" list. And in
terms of problems:
- clang is broken for everything except sandbox I believe
- clang + LTO never worked for us
- Our dtc ignore warning flags are well out of date (and harder to sync
  up with)
- All of the general fixes with the Kbuild logic post v4.20 are just
  missing.

That's just off the top of my head.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Jonas Karlman]

Hi,

On 2025-02-13 16:59, Tom Rini wrote:
> On Thu, Feb 13, 2025 at 07:33:20AM -0700, Simon Glass wrote:
>> Hi Tom,
>>

[snip]

>> Yes, that's true, but mostly in kconfig. I would be willing to resync
>> kconfig with Linux, if that helps.
> 
> Yes, re-syncing scripts/kconfig to v6.13 (as a stand alone series) would
> be helpful, thanks.

I did a dirty sync to Kconfig v6.8 about a year ago, when I though I
needed a newer Kconfig to support "default 0x0 if SYMBOL=value". Then
found a workaround for current Kconfig, adding spaces e.g. "default 0x0
if SYMBOL = value" so I dropped the entire upgrade attempt.

Pushed my dirty sync to [1] if it may help with anything :-)

The newer version seemed to work just fine after fixing syntax issues
in a few U-Boot Kconfig-files.

[1] https://github.com/Kwiboo/u-boot-rockchip/commits/v2024.04-kconfig/

Regards,
Jonas

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 10184 bytes --]

On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:

> Hi,
> 
> I just wanted to send a note to (re-)introduce my ideas[1] for the
> next iteration of xPL.
> 
> A recent series introduced 'xPL' as the name for the various
> pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> still use filenames and function naming which uses 'spl', but could
> potentially adjust that.
> 
> The major remaining problem IMO is that it is quite tricky and
> expensive (in terms of time) to add a new phase. We also have some
> medium-sized problems:
> 
> a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> can be confusing, particularly when combined with ifdef and ifneq
> 
> b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> different things. For any given option, some code uses one and some
> the other, depending on what problems people have met along the way.
> 
> c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> the option is enabled in one or more xPL phases, or just in U-Boot
> proper. The only way to know is to look for $(PHASE_) etc. in the
> Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> and has not scaled well.
> 
> d. We need to retain an important feature: options from different
> phases can depend on each other. As an example, we might want to
> enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> may also want to share values between phases, such as TEXT_BASE. We
> can do this easily today, just by adding Kconfig rules.
> 
> Proposal
> 
> 1. Adjust kconf to generate separate autoconf.h files for each phase.
> These contain the values for each Kconfig option for that phase. For
> example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> 
> 2. Add a file to resolve the ambiguity in (c) above, listing the
> Kconfig options which should not be enabled/valid in any xPL build.
> There are around 200 of these.
> 
> 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> useful in rare cases. This indicates that the option applies only to
> U-Boot proper and is not defined in any xPL build. It is analogous to
> CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> needed at present, basically to allow access to the value for another
> phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> the address to which U-Boot should be loaded.
> 
> 4. There is no change to the existing defconfig files, or 'make
> menuconfig', which works just as today, including dependencies between
> options across all phases.
> 
> 5. (next) Expand the Kconfig language[2] to support declaring phases
> (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> declared once for any/all phases. We can then drop the file in 2
> above.
> 
> With this, maintaining Kconfig options, Makefiles and adding a new
> phase should be considerably easier.
> 
> Regards,
> Simon
> 
> [1] https://lore.kernel.org/u-boot/20230131152702.249197-1-sjg@chromium.org/
> [2] https://lore.kernel.org/u-boot/CAK7LNARQ-PgxiCh+gm2efpfXmNBkdTp18OTk3sHtqNsk6by5-Q@mail.gmail.com/

I'm not sure where to bring this up, so I'm going back to the top. I
wondered if your proposal fixed the problem described here:
https://lore.kernel.org/all/01020194f07b459d-184820e6-90c2-44fe-9850-f57fc2ebaafe-000000@eu-west-1.amazonses.com/
which goes back to here:
https://lore.kernel.org/u-boot/20250211043335.92538-1-naoki@radxa.com/T/#m15a3058ef1ec8afb76528e1ed3edf864c8a77ef0

So I took:
https://source.denx.de/u-boot/custodians/u-boot-dm/-/tree/splc-working?ref_type=heads
and then modified pinebook-pro-rk3399_defconfig as described.

This fails to build to start with as:
  CC      spl/drivers/usb/gadget/g_dnl.o
In file included from /home/trini/work/u-boot/u-boot/drivers/usb/gadget/g_dnl.c:25:
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/composite.c: In function 'config_buf':
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/composite.c:214:47: error: 'CONFIG_USB_GADGET_VBUS_DRAW' undeclared (first use in this function)
  214 |         c->bMaxPower = config->bMaxPower ? : (CONFIG_USB_GADGET_VBUS_DRAW / 2);
      |                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/composite.c:214:47: note: each undeclared identifier is reported only once for each function it appears in
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/composite.c: In function 'set_config':
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/composite.c:462:53: error: 'CONFIG_USB_GADGET_VBUS_DRAW' undeclared (first use in this function)
  462 |         power = c->bMaxPower ? (2 * c->bMaxPower) : CONFIG_USB_GADGET_VBUS_DRAW;
      |                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/g_dnl.c: At top level:
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/g_dnl.c:49:36: error: 'CONFIG_USB_GADGET_MANUFACTURER' undeclared here (not in a function)
   49 | static const char manufacturer[] = CONFIG_USB_GADGET_MANUFACTURER;
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/trini/work/u-boot/u-boot/arch/arm/include/asm/byteorder.h:29,
                 from /home/trini/work/u-boot/u-boot/include/linux/libfdt_env.h:15,
                 from /home/trini/work/u-boot/u-boot/include/linux/libfdt.h:6,
                 from /home/trini/work/u-boot/u-boot/include/fdtdec.h:17,
                 from /home/trini/work/u-boot/u-boot/include/usb.h:14,
                 from /home/trini/work/u-boot/u-boot/drivers/usb/gadget/g_dnl.c:15:
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/g_dnl.c:65:44: error: 'CONFIG_USB_GADGET_VENDOR_NUM' undeclared here (not in a function)
   65 |         .idVendor = __constant_cpu_to_le16(CONFIG_USB_GADGET_VENDOR_NUM),
      |                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/trini/work/u-boot/u-boot/include/linux/byteorder/little_endian.h:24:60: note: in definition of macro '__constant_cpu_to_le16'
   24 | #define __constant_cpu_to_le16(x) ((__force __le16)(__u16)(x))
      |                                                            ^
/home/trini/work/u-boot/u-boot/drivers/usb/gadget/g_dnl.c:66:45: error: 'CONFIG_USB_GADGET_PRODUCT_NUM' undeclared here (not in a function)
   66 |         .idProduct = __constant_cpu_to_le16(CONFIG_USB_GADGET_PRODUCT_NUM),
      |                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/trini/work/u-boot/u-boot/include/linux/byteorder/little_endian.h:24:60: note: in definition of macro '__constant_cpu_to_le16'
   24 | #define __constant_cpu_to_le16(x) ((__force __le16)(__u16)(x))
      |                                                            ^
make[4]: *** [/home/trini/work/u-boot/u-boot/scripts/Makefile.build:267: spl/drivers/usb/gadget/g_dnl.o] Error 1
make[3]: *** [/home/trini/work/u-boot/u-boot/scripts/Makefile.build:407: spl/drivers/usb/gadget] Error 2
make[2]: *** [/home/trini/work/u-boot/u-boot/scripts/Makefile.spl:523: spl/drivers] Error 2
make[1]: *** [/home/trini/work/u-boot/u-boot/Makefile:2055: spl/u-boot-spl] Error 2
make[1]: Leaving directory '/tmp/pinebook-pro-rk3399'
make: *** [Makefile:177: sub-make] Error 2

I tried adding the following:
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index e120efeb0073..c28ff53f3770 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -47,6 +47,16 @@ config USB_GADGET_MANUFACTURER
 	  Vendor name of the USB device emulated, reported to the host device.
 	  This is usually either the manufacturer of the device or the SoC.
 
+config SPL_USB_GADGET_MANUFACTURER
+	string
+	depends on USB_GADGET_MANUFACTURER
+	default USB_GADGET_MANUFACTURER
+
+config TPL_USB_GADGET_MANUFACTURER
+	string
+	depends on USB_GADGET_MANUFACTURER
+	default USB_GADGET_MANUFACTURER
+
 config USB_GADGET_VENDOR_NUM
 	hex "Vendor ID of the USB device"
 	default 0x1f3a if ARCH_SUNXI
@@ -57,6 +67,16 @@ config USB_GADGET_VENDOR_NUM
 	  This is usually the board or SoC vendor's, unless you've registered
 	  for one.
 
+config SPL_USB_GADGET_VENDOR_NUM
+	depends on USB_GADGET_VENDOR_NUM
+	default USB_GADGET_VENDOR_NUM
+	hex
+
+config TPL_USB_GADGET_VENDOR_NUM
+	depends on USB_GADGET_VENDOR_NUM
+	default USB_GADGET_VENDOR_NUM
+	hex
+
 config USB_GADGET_PRODUCT_NUM
 	hex "Product ID of the USB device"
 	default 0x1010 if ARCH_SUNXI
@@ -70,6 +90,16 @@ config USB_GADGET_PRODUCT_NUM
 	help
 	  Product ID of the USB device emulated, reported to the host device.
 
+config SPL_USB_GADGET_PRODUCT_NUM
+	hex
+	depends on USB_GADGET_PRODUCT_NUM
+	default USB_GADGET_PRODUCT_NUM
+
+config TPL_USB_GADGET_PRODUCT_NUM
+	hex
+	depends on USB_GADGET_PRODUCT_NUM
+	default USB_GADGET_PRODUCT_NUM
+
 config USB_GADGET_ATMEL_USBA
 	bool "Atmel USBA"
 	select USB_GADGET_DUALSPEED
@@ -149,6 +179,11 @@ config USB_GADGET_VBUS_DRAW
 	   This value will be used except for system-specific gadget
 	   drivers that have more specific information.
 
+config SPL_USB_GADGET_VBUS_DRAW
+	int
+	depends on USB_GADGET_VBUS_DRAW
+	default USB_GADGET_VBUS_DRAW
+
 config SDP_LOADADDR
 	hex "Default load address at SDP_WRITE and SDP_JUMP"
 	default 0

But I guess there's just a bug with that iteration of the series and
converting non-boolean options to all their xPL variants.

It also I think highlights two big problems.

One, without the Kconfig language modification as well we're going to
have an even worse problem of duplicating questions.

Two, it doesn't solve the problem of it being confusing to avoid
building FOO when FOO isn't needed on a phase. In this example we're
still building drivers/usb/dwc3/ in TPL and need 2/2 in that series to
disable a warning.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: xPL Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3926 bytes --]

On Tue, Feb 11, 2025 at 08:03:20AM -0700, Simon Glass wrote:

> Hi,
> 
> I just wanted to send a note to (re-)introduce my ideas[1] for the
> next iteration of xPL.
> 
> A recent series introduced 'xPL' as the name for the various
> pre-U-Boot phases, so now CONFIG_XPL_BUILD means that this is any xPL
> phase and CONFIG_SPL means this really is the SPL phase, not TPL. We
> still use filenames and function naming which uses 'spl', but could
> potentially adjust that.
> 
> The major remaining problem IMO is that it is quite tricky and
> expensive (in terms of time) to add a new phase. We also have some
> medium-sized problems:
> 
> a. The $(PHASE_), $(SPL_) rules in the Makefile are visually ugly and
> can be confusing, particularly when combined with ifdef and ifneq
> 
> b. We have both CONFIG_IS_ENABLED() and IS_ENABLED() and they mean
> different things. For any given option, some code uses one and some
> the other, depending on what problems people have met along the way.
> 
> c. An option like CONFIG_FOO is ambiguous, in that it could mean that
> the option is enabled in one or more xPL phases, or just in U-Boot
> proper. The only way to know is to look for $(PHASE_) etc. in the
> Makefiles and CONFIG_IS_ENABLED() in the code. This is very confusing
> and has not scaled well.
> 
> d. We need to retain an important feature: options from different
> phases can depend on each other. As an example, we might want to
> enable MMC in SPL by default, if MMC is enabled in U-Boot proper. We
> may also want to share values between phases, such as TEXT_BASE. We
> can do this easily today, just by adding Kconfig rules.
> 
> Proposal
> 
> 1. Adjust kconf to generate separate autoconf.h files for each phase.
> These contain the values for each Kconfig option for that phase. For
> example CONFIG_TEXT_BASE in autoconf_spl.h is SPL's text base.
> 
> 2. Add a file to resolve the ambiguity in (c) above, listing the
> Kconfig options which should not be enabled/valid in any xPL build.
> There are around 200 of these.
> 
> 3. Introduce CONFIG_PPL as a new prefix, meaning U-Boot proper (only),
> useful in rare cases. This indicates that the option applies only to
> U-Boot proper and is not defined in any xPL build. It is analogous to
> CONFIG_TPL_xxx meaning 'enabled in TPL'. Only a dozen of these are
> needed at present, basically to allow access to the value for another
> phase, e.g. SPL wanting to find CONFIG_PPL_TEXT_BASE so that it knows
> the address to which U-Boot should be loaded.
> 
> 4. There is no change to the existing defconfig files, or 'make
> menuconfig', which works just as today, including dependencies between
> options across all phases.
> 
> 5. (next) Expand the Kconfig language[2] to support declaring phases
> (SPL, TPL, etc.) and remove the need for duplicating options (DM_MMC,
> SPL_DM_MMC, TPL_DM_MMC, VPL_DM_MMC), so allowing an option to be
> declared once for any/all phases. We can then drop the file in 2
> above.
> 
> With this, maintaining Kconfig options, Makefiles and adding a new
> phase should be considerably easier.

I believe this proposal will lead to the code and Makefiles being less
clear than they are today. The line:
drivers/Makefile:obj-$(CONFIG_$(PHASE_)BLK) += block/
will become:
drivers/Makefile:obj-$(CONFIG_BLK) += block/
without being clear that it could reference either full U-Boot (PPL) or
some xPL phase. While the same Makefile will continue to have (comments
my own):
obj-y += mtd/ # Subdirectory Makefiles control build contents
obj-$(CONFIG_MULTIPLEXER) += mux/ # Only valid for PPL.

And so the situation for humans will be worse off than today because
while $(PHASE_) and $(XPL_) are confusing at times, they make it clear
what can and cannot be enabled in PPL vs xPL.

Doing "something" is not better than doing nothing in this case.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]