u-boot.git/arch/sandbox, branch main

Merge patch series "vbe: bound FIT external-data reads against the firmware area"

2026-07-16T18:06:40Z

Aristo Chen says: vbe_read_fit() loads a firmware-phase FIT from a fixed firmware area on a block device and then issues a follow-up blk_read() to pull in the image, and optionally an FDT, referenced by the FIT's image node. The source offset on the device and the read length both come from the FIT itself, via data-position or data-offset and data-size. Those properties live on mutable boot media and can be controlled by an attacker with write access to the firmware area. On the TPL or VPL path, and on the bootmeth bootflow path reached via abrec_read_bootflow_fw() and vbe_simple_read_bootflow_fw(), the follow-up blk_read() runs before any signature or hash check on the loaded phase. Patch 1 is a sandbox test-tree preparation. The firmware1 node in arch/sandbox/dts/test.dts declared area-size = 0xe00000 (14 MiB), but the binman fw-update section in sandbox_vpl.dtsi is 32 MiB and the FIT inside it carries ~16 MiB of external data, so the FIT already extended past the declared area. The mismatch was tolerated because no caller bounded the external-data load against area_size. Patch 1 raises area-size to match the binman section size so test_vbe_vpl keeps passing once the bound is enforced. The patches are ordered so the test is never broken in the middle of the series. Patch 2 adds the missing range check, confining the FIT-supplied [load_addr, load_addr + len) window to [addr, addr + area_size] before block numbers and lengths are computed, and applying the same constraint to fdt_load_addr and fdt_size. The check is written in subtraction-only form against the trusted area_size so the comparison cannot itself overflow. Patch 3 adds two sandbox unit tests under test/boot/ that construct synthetic FITs with out-of-range data-position and oversized data-size, write them to mmc1, and confirm vbe_read_fit() returns -E2BIG for each before issuing the follow-up blk_read(). Deferring the external-data blk_read() until after the phase has been signature-verified would be a stronger structural fix and was discussed on the v1 thread. Simon confirmed the bounded read is the right first step and that the verify-then-load change should be a separate series, so this v3 stays scoped to the bound. Link: https://lore.kernel.org/r/20260705034414.2247-1-aristo.chen@canonical.com

sandbox: vbe: size firmware1 area to fit the binman fw-update section

2026-07-16T18:06:14Z

The firmware1 node in test.dts declares area-size = 0xe00000 (14 MiB) but the binman fw-update section in sandbox_vpl.dtsi is 0x2000000 (32 MiB) and the FIT inside it carries ~16 MiB of external data (spl + u-boot subimages). The FIT therefore extends past the declared firmware area, contradicting the documented contract of vbe_read_fit() that the FIT must fit within @area_size. The mismatch was tolerated because no caller actually bounded the external-data load against area_size. Bring the devicetree in line with the binman section size so the FIT extent stays within the trusted firmware area, in preparation for vbe_read_fit() enforcing that bound. state-offset and version-offset are left as-is; they were already inside the FIT data region and are not exercised by test_vbe_vpl. Reviewed-by: Simon Glass Signed-off-by: Aristo Chen

test: dm: pmbus: add a sandbox PMBus chip emulator

2026-07-13T03:24:40Z

Add a UCLASS_I2C_EMUL driver that emulates a PMBus 1.x compliant chip behind the sandbox I2C bus, plus the test.dts wiring and sandbox defconfig that bind it to the generic PMBus regulator (compatible = "pmbus"). This design is a stub only: it lets the follow-up dm unit test drive lib/pmbus.c, the generic regulator and the pmbus CLI command with no real hardware. The emulator models a flat per-command 16-bit register file and the three identification block strings (MFR_ID / MFR_MODEL / MFR_REVISION). READ_IIN and READ_POUT are deliberately left unimplemented (the chip NAKs them) so the telemetry printer's "(not supported)" path is exercised, mirroring a real buck that only calibrates a subset of the sensor classes. Signed-off-by: Vincent Jardin Reviewed-by: Simon Glass Signed-off-by: Peng Fan

test: dm: regulator: Add regulator_set_value_clamp() tests

2026-07-12T08:18:32Z

Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it to test regulator_set_value_clamp(). Test in-range requests, clamping against the regulator limits, invalid ranges outside the regulator limits and a min value higher than max. Signed-off-by: Jonas Karlman Reviewed-by: Peng Fan Signed-off-by: Peng Fan

treewide: move bi_dram[] from bd to gd

2026-06-25T00:13:24Z

Currently, the bi_dram[] information is stored in the board info structure (bd). Because bd is only valid after reserve_board(), dram_init_banksize() must be called late in the initialization process. This limitation is problematic, as it forces us to rely on a variety of bespoke functions to determine board RAM, bank memory sizes, and other early setup requirements. By moving bi_dram[] into the global data (gd), we can run it earlier. This is particularly convenient since boards define their own dram_init_banksize() routines, which do not always rely on parsing Device Tree (DT) memory nodes. Additionally, U-Boot defaults to relocating to the top of the first memory bank. While boards currently use custom functions to override this behavior, having the DRAM bank information available earlier in gd makes relocating to a different bank trivial and standardizes the process. Reviewed-by: Anshul Dalal Tested-by: Michal Simek # Versal Gen 2 Vek385 Tested-by: Anshul Dalal Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

Merge patch series "Fixes, cleanup and a test for the SPL FIT "full" loader"

2026-06-17T20:25:13Z

Francesco Valla says: This patch set contains a collection of small fixes and cleanups for the "full" FIT loader that can be used for the SPL. The main beneficiary is the falcon boot flow, but the same loader can be used also for U-Boot proper. Patch 1 was part of another set, but I decided to put it here for a better separation between plumbing (here) and new features (there). I kept the Reviewed-by tag collected from Simon in that occasion. Patch 6 introduces a new unit test covering most of the code that is being cleaned up. The set was tested on a i.MX93 FRDM, both with and without signature and to boot both U-Boot proper and the Linux kernel directly (i.e., falcon boot). Link: https://lore.kernel.org/r/20260604-spl_fit_full_cleanup-v1-0-ec036b5872e2@valla.it

test: spl: add unit test for the "full" FIT loader

2026-06-17T20:16:41Z

Following what is already done for the "simple" FIT loader, add a unit test for the "full" loader. Signed-off-by: Francesco Valla

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

test: hook up test of allowing control DTB to act as FIT image

2026-06-11T13:56:45Z

Add a test demonstrating how one can embed various scripts in the control DTB. Verify that the source command can be used with ${fdtcontroladdr} by itself (invoking the default script), and with : suffix. Check that the scripts themselves can invoke "sibling" scripts. Also verify that without CONTROL_DTB_AS_FIT set, the control DTB is not accepted by the source command. Reviewed-by: Simon Glass Signed-off-by: Rasmus Villemoes

reset: sandbox: Cover reset_reset() fallback with second sandbox provider

2026-06-08T08:50:06Z

Add a sandbox reset controller compatible string "sandbox,reset-ctl-fallback-only" that reuses the existing sandbox assert, deassert, request, and free helpers but omits rst_reset. That forces reset_reset() through the core assert / udelay / deassert fallback. Extend the reset-ctl-test DT node with a fifth reset line named "fallback" that points at the new provider, and add dm_test_reset_reset_fallback_path which verifies sandbox_reset_get_count() stays zero (rst_reset is never invoked) while the line ends deasserted after reset_reset(). This complements the existing rst_reset coverage on sandbox,reset-ctl and matches the approach of using a separate controller to exercise the fallback path in unit tests. Reviewed-by: Simon Glass Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/c1d40db6e2332a8b23ba842385b3f8c3d0290109.1779709539.git.michal.simek@amd.com