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