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-...@chromium.org/ [2] https://lore.kernel.org/u-boot/cak7lnarq-pgxich+gm2efpfxmnbkdtp18otk3shtqnsk6by...@mail.gmail.com/
