Re: xPL Proposal

[Tom Rini <trini@konsulko.com>]

[-- 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 --]