u-boot.git/boot/Kconfig, branch master

Kconfig: boot: restyle

2026-06-25T20:13:31Z

Restyle all Kconfigs for "boot": 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 "allow control DTB to double as "FIT image""

2026-06-11T13:56:52Z

Rasmus Villemoes says: The commit message for patch 1 explains what it is I'd like to be able to do, but here's some more background: For a long time, we've embedded the boot script in the U-Boot binary by building a bootscript.itb, and using a .dtsi like / { config { bootscript = /incbin/("/path/to/bootscript.itb"); }; }; which in turn is mentioned in CONFIG_DEVICE_TREE_INCLUDES, that bootscript.itb FIT image has been embedded in U-Boot's control dtb. Running that was then a matter of doing fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && source ${bsaddr} There are a couple of advantage of having the bootscript (and other script logic) embedded in the U-Boot binary. First, there's no need to figure out some separate partition to store the script in, and making sure that gets updated whenever the bootloader itself does. Second, one doesn't need to worry about verifying the script; whatever steps one needs to take to implement secure boot for U-Boot itself will by necessity also cover the control dtb (if nothing else then because that's where the public key for the kernel verification lives). And third, the boot script is automatically updated together with U-Boot itself; and if U-Boot is stored in an eMMC boot partition, that update is guaranteed to be atomic. Now with the stricter requirements of libfdt starting from v2026.04, the above command no longer worked, or only half the time, because the embedded FIT image may not land on an 8-byte aligned address. So that line had to be changed a little (line breaks added) fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && fdt get size bssize /config bootscript && cp.b ${bsaddr} ${loadaddr} ${bssize} && source ${loadaddr} which is getting quite unwieldy. Then it struck me that one could perhaps simplify all of this quite a lot: Cut out the intermediate bootscript.itb, just create a .dtsi which directly puts a /images node inside the control dtb / { images { default = "bootscript"; bootscript { description = "Boot script"; data = /incbin/("/path/to/bootscript.sh"); type = "script"; compression = "none"; }; }; }; and treat the control dtb itself as a FIT image; so the command to put in $bootcmd becomes simply source ${fdtcontroladdr}:bootscript and embedding other pieces of callable scripts is quite trivial. And that almost works out-of-the-box, except for the fit_check_format() sanity check. Introduce a CONFIG_ knob that allows one to opt out of those sanity checks, for the special case of the address being checked being identical to gd->fdt_blob. Link: https://lore.kernel.org/r/20260602213013.558064-1-rv@rasmusvillemoes.dk

image-fit.c: introduce CONTROL_DTB_AS_FIT config knob

2026-06-11T13:56:45Z

Having scripts embedded one way or the other in the U-Boot binary means they are automatically verified/trusted by whatever mechanism verifies U-Boot. Writing those scripts in the built-in environment leads to backslatitis and missing or wrong quoting and is generally not very readable or maintainable. Maintaining scripts in external files allows one to have both syntax highlighting and to some extent apply shellcheck on it (though U-Boot's shell is of course not quite POSIX sh, so some '#shellcheck disable' directives are needed). Getting those into the U-Boot binary is then a matter of having a suitable .dtsi file such as / { images { default = "boot"; boot { description = "Bootscript"; data = /incbin/("boot.sh"); type = "script"; compression = "none"; }; factory-reset { description = "Script for performing factory reset"; data = /incbin/("factory-reset.sh"); type = "script"; compression = "none"; }; }; }; and making that part of CONFIG_DEVICE_TREE_INCLUDES, so that U-Boot's control DTB effectively doubles as a FIT image containing a few "script" entries. At run-time, one's default bootcommand can then simply be source ${fdtcontroladdr}:boot Except of course that the control DTB is in fact not quite a FIT image. The lack of timestamp and description properties could potentially be worked around (by just adding those via that same .dtsi), but the no-@ check is not possible to get around. But since the control dtb is by definition trusted, we can make an exception for that particular address, if the new CONTROL_DTB_AS_FIT config option is enabled. One can of course build an ordinary FIT image with those scripts. However, that requires extra steps in the boot command for loading that script from storage, requires one to use "configurations" for pointing at a single script to run, and signing the FIT image using the same key used for verifying the kernel. Moreover, in certain situations, such as bootstrapping/production, there is no place to load that FIT image from, and it is much simpler to just have the necessary scripts be part of the U-Boot image itself. Reviewed-by: Simon Glass Signed-off-by: Rasmus Villemoes

boot: fit: support generating DM verity cmdline parameters

2026-05-27T19:41:33Z

Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter from the verity metadata (block-size, data-blocks, algo, root-hash, salt) and append it to bootargs. Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device so the kernel waits for the underlying FIT block device to appear before setting up device-mapper targets. This is needed when the block driver probes late, e.g. because it depends on NVMEM calibration data. The dm-verity target references /dev/fitN where N is the loadable's index in the configuration -- matching the order Linux's FIT block driver assigns block devices. hash-start-block is read directly from the FIT dm-verity node; mkimage ensures its value equals num-data-blocks by invoking veritysetup with --no-superblock. Signed-off-by: Daniel Golle Reviewed-by: Simon Glass

boot: remove NO_NET use

2026-04-27T17:26:40Z

NO_NET is now a transitional symbol which may eventually be removed. Its meaning is the opposite of the new meaning of NET (that is, any networking stack). Update the symbol dependency by using NET instead of !NO_NET. Signed-off-by: Quentin Schulz Reviewed-by: Simon Glass Reviewed-by: Ilias Apalodimas Reviewed-by: Peter Robinson Reviewed-by: Tom Rini

lmb: boot: Update dependencies within BOOT_DEFAULTS_CMDS

2026-04-07T17:32:29Z

The CMD_BOOT[IZ] symbols have a dependency on LMB, correctly, currently. Make sure that in BOOT_DEFAULTS_CMDS we only select these commands if LMB is enabled. Signed-off-by: Tom Rini

Merge branch 'next'

2026-04-06T18:16:57Z

boot: Add DM_RTC as a dependency to CEDIT

2026-04-03T19:42:49Z

The CEDIT functionality, due to the cmos functions, depends directly on DM_RTC being enabled in order to provide that API. Express this in Kconfig as well. Signed-off-by: Tom Rini

lmb: Correct dependency around CMD_BOOT[IMZ]

2026-04-03T19:42:49Z

The calls around lmb functions for these commands are not specific to SYS_BOOT_RAMDISK_HIGH but rather part of the general loading portion of the command itself currently. Move this dependency to the right spot. Signed-off-by: Tom Rini

global: Audit Kconfig usage of PARTITION_TYPE_GUID

2026-04-03T18:06:10Z

It is not functionally possible to use the code enabled by PARTITION_TYPE_GUID without having EFI_PARTITION be enabled as well. Not all users of the former had ensured that the latter was enabled however, so audit all current users and then as appropriate select or imply EFI_PARTITION as needed. Signed-off-by: Tom Rini