Hi Anshul, On Fri, 4 Apr 2025 at 10:55, Anshul Dalal <ansh...@ti.com> wrote: > > Using CMD_* configs from spl doesn't make logical sense. Therefore this > patch replaces the checks for CMD_BOOTx with newly added configs > SPL_HAS_BOOTx. > > SPL_HAS_BOOTZ is enabled by default for 32-bit ARM systems and > SPL_HAS_BOOTI is enabled by default for 64-bit ARM and RISCV. > > The respective C files (image.c/zimage.c) are compiled based on library > symbols LIB_BOOTx instead which are in turn selected by both CMD_BOOTx > and SPL_HAS_BOOTx. > > Signed-off-by: Anshul Dalal <ansh...@ti.com> > --- > Tested: > * U-Boot CI: https://github.com/u-boot/u-boot/pull/757 > Changes in v6: > * Add LIB_BOOTx library symbols > * Update existing configs ensuring no change in size or build failure > v5: > https://lore.kernel.org/all/20250314035505.4029331-1-ansh...@ti.com/ > Changes in v5: > * Remove imply clause for CMD_BOOTZ instead add default y for > SPL_HAS_BOOTZ > * Update commit message to reflect the changes > * Remove 'More info' link > v4: > https://lore.kernel.org/u-boot/20250313032842.1189977-1-ansh...@ti.com/ > Changes in v4: > * Don't set SPL_HAS_BOOTI for sandbox by default > * Updated prompts for SPL_HAS_BOOT[IZ] > * Removed check for SPL_HAS_FRAMEWORK from Makefile > v3: > https://lore.kernel.org/u-boot/20250312124757.789013-1-ansh...@ti.com/ > Changes in v3: > * Add imply clause for CMD_BOOTZ to enable SPL_HAS_BOOTZ > * Fix broken check for bootz_setup > v2: > https://lore.kernel.org/u-boot/20250312094241.629707-1-ansh...@ti.com/ > Changes in v2: > * Add SPL_HAS_BOOT[IZ] configs > v1: > https://lore.kernel.org/u-boot/20250311093709.3372104-1-ansh...@ti.com/ > --- > arch/arm/lib/Makefile | 9 +++------ > cmd/Kconfig | 2 ++ > common/spl/Kconfig | 16 ++++++++++++++++ > common/spl/spl.c | 5 +++-- > lib/Kconfig | 6 ++++++ > 5 files changed, 30 insertions(+), 8 deletions(-) >
I'm sorry that I am late to the party. But you should start by creating BOOTM, BOOTI, etc. and select them from CMD_BOOTM, etc. Then you can create SPL_BOOTM, SPL_BOOTI, etc. Then we can use CONFIG_IS_ENABLED(BOOTM) LIB_BOOTx doesn't really make any sense, this the code is in boot/ , not /lib Also, HAS_BOOTZ doesn't make any sense either. We use HAS_ or HAVE for things which could be enabled (with a separate option) if the user wants them enabled; they should not be used to actually enable something. Also, please check if this conflicts with my PXE series[1], part of which Tom has so far not been willing to apply. Regards, Simon [1] https://patchwork.ozlabs.org/project/uboot/list/?series=435516&state=*
