u-boot.git/common/spl/Kconfig, branch next

Makefile: add SPL_REMAKE_ELF_LDSCRIPT feature

2026-08-07T12:47:06Z

Some platforms (e.g. at least Qualcomm) use the ELF format in creative ways, including in the bootrom. Make SPL_REMAKE_ELF use a linker script specified in SPL_REMAKE_ELF_LDSCRIPT (with the previously hardcoded path as the default). Signed-off-by: Michael Srba Reviewed-by: Simon Glass Reviewed-by: Casey Connolly Link: https://patch.msgid.link/20260521-qcom_spl-v9-1-c108ebe8ff4e@seznam.cz Signed-off-by: Casey Connolly

Kconfig: common: restyle

2026-06-25T20:13:36Z

Restyle all Kconfigs for "common": Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Replace '---help---' by 'help' Signed-off-by: Johan Jonker

Merge patch series "arm: omap: Add back omap4 support"

2026-06-17T15:52:33Z

Bastien Curutchet says: This series aims to add back the omap4 support. This support was removed by commit b0ee3fe642c ("arm: ti: Remove omap4 platform support") because at that moment, none of the OMAP4-based boards had done the migration to DM_I2C. My use case is an old product based on the Variscite's omap4 system on module. I needed to upgrade U-Boot on it for security reasons. I think that this work could benefit to other people who may have same kind of product to maintain. Patch 1 to 3 remove the omap's clock driver dependency to the AM33xx as it is also present in omap4 platforms. I tested these changes on the beaglebone black to ensure I didn't break the AM33xx case. Patch 4 & 5 revert the deletion of the omap4 support. The revert makes checkpatch.pl angry. I fixed quite a lots of warnings already but it remains two kinds of warnings: - CamelCase on timings structure, I left the CamelCase because IMHO it's more readable this way. - #ifdef CONFIG_XYZ shouldn't be used anymore. I left one of this because I didn't find a clean way to get rid of it. Patch 6 adds support for the Variscite's system on module. This system on module is supported by the Linux project through ti/omap/omap4-var-som-om44.dtsi Link: https://lore.kernel.org/r/20260608-omap4-support-v3-0-8595ccd203f0@bootlin.com

arm: ti: Introduce back omap4 support

2026-06-17T15:50:36Z

omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform support") because the supported boards hadn't done the conversion to CONFIG_DM_I2C in time. It still exists some omap4-based products and they could benefit from the latest U-Boot support for obvious security reasons. Revert part of b0ee3fe642c to introduce back a minimal support for the omap4 platform. Fix the checkpatch's warning/errors induced by this revert. Following warnings are still present: | arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? | arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible | arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: I didn't find an clean way to fix the "don't use #ifdef" warning as we need to define the gpio_bank for the SPL build only. For the CamelCase warnings, the incriminated attributes represent timings, so IMHO, it is more readable with CamelCase. Set myself as OMAP4 maintainer. Signed-off-by: Bastien Curutchet

bloblist / handoff: Make this depend on BLOBLIST_FIXED

2026-06-02T15:30:28Z

Currently, the only way we support passing a bloblist from one stage to the next is via the BLOBLIST_FIXED mechanism. Update the Kconfig logic to express this constraint. Reviewed-by: Raymond Mao Tested-by: Alexander Stein Signed-off-by: Tom Rini

rename NET to NET_LEGACY

2026-04-27T17:26:40Z

Highlight that NET really is the legacy networking stack by renaming the option to NET_LEGACY. This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL. The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is using the legacy networking app so this seems fine to do. This also has the benefit of removing potential confusion on NET being a specific networking stack instead of "any" network stack. Signed-off-by: Quentin Schulz Acked-by: Ilias Apalodimas Reviewed-by: Peter Robinson Reviewed-by: Tom Rini

spl: Remove unused CONFIG_SPL_FRAMEWORK_BOARD_INIT_F option

2026-04-07T21:26:47Z

The option CONFIG_SPL_FRAMEWORK_BOARD_INIT_F enables a simple board_init_f function in SPL. This however is never enabled, so remove this function and option. Signed-off-by: Tom Rini

spl: env: Correct dependencies for SPL_SAVEENV and MMC

2026-04-07T17:32:39Z

The SPL_SAVEENV functionality, when working with an MMC device, can only work with SPL_MMC_WRITE enabled. This however only works with SPL_MMC also being enabled. Update the dependencies to show that if we have enabled SPL_ENV_IS_IN_MMC then we select SPL_MMC_WRITE and make SPL_ENV_IS_IN_MMC depends on SPL_MMC. Signed-off-by: Tom Rini

SPL: Rework logic around SPL_BLK_FS (and SPL_NVME)

2026-03-30T21:02:27Z

As exposed by "make randconfig", we have an issue around SPL_BLK_FS. This is functionally a library type symbol that should be selected when required and select what it needs. Have SPL_BLK_FS select SPL_FS_LOADER and then SPL_NVME will now correctly select SPL_FS_LOADER via SPL_BLK_FS. Signed-off-by: Tom Rini

spl: Remake SPL elf from bin

2026-03-13T19:21:52Z

On Xilinx MB-V there is a need to use ELF file for SPL which is placed in BRAM (Block RAM) because tools for placing code to bitstream requires to use ELF. That's why introduce SPL_REMAKE_ELF similar to REMAKE_ELF option as was originally done by commit f4dc714aaa2d ("arm64: Turn u-boot.bin back into an ELF file after relocate-rela"). There is already generic and simple linker script (arch/u-boot-elf.lds) which can be also used without any modification. Signed-off-by: Michal Simek