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
signature.asc
Description: PGP signature
