u-boot.git, branch main

Merge patch series "cyclic: update and optimization"

2026-07-16T22:11:24Z

Patrice Chotard says: First patch is replacing uint64_t by u64 as suggested by b4 Second patch optimizes cyclic_run() to parse cyclic list only if a cyclic function's timestamp is elapsed. Link: https://lore.kernel.org/r/20260706-optimize_cyclic_run-v3-0-06ecbd74ef7c@foss.st.com

cyclic: reduce get_timer_us() calls inside hlist_for_each_entry_safe()

2026-07-16T22:11:19Z

On STM32MP157C-DK2, when using the "ums" command, in sleep_thread(), ctrlc() is called every ~640ms which doesn't allows high reactivity when user press CTRL+C in U-Boot console. In sleep_thread() loop, ctrlc() is called every 200000 iterations. But schedule is called on each loop iteration. Optimize cyclic_run() in order to not call get_timer_us() on each entry. This allow to save computation time : _ before : ctrlc() is called every ~640ms _ after : ctrlc() is called every ~230ms Signed-off-by: Rasmus Villemoes Signed-off-by: Patrice Chotard Cc: Marek Vasut

cyclic: replace uint64_t by u64 suggested by b4

2026-07-16T22:11:11Z

For new patch, b4 is suggested to replace type 'uint64_t' by 'u64' : CHECK: Prefer kernel type 'u64' over 'uint64_t' Update cyclic.c accordingly in order to be coherent with following commit. Signed-off-by: Patrice Chotard Reviewed-by: Marek Vasut

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

test: vbe: cover vbe_read_fit() external-data bounds checks

2026-07-16T18:06:15Z

vbe_read_fit() rejects FITs whose external-data window extends past the trusted firmware area on disk by returning -E2BIG. Add two sandbox unit tests that construct synthetic FITs with attacker-controlled data-position and data-size values, write them to mmc1, and assert vbe_read_fit() catches each one before issuing the follow-up blk_read(). vbe_read_fit_oob_position uses a data-position past area_size, which trips the load_addr - addr > area_size clause. vbe_read_fit_oversize_data keeps data-position inside the area but picks a data-size that overruns area_size - (load_addr - addr), tripping the third clause. The two remaining bound clauses stay unreachable from a sandbox test. The load_addr < addr guard trivially holds when addr comes from CONFIG_VAL(TEXT_BASE), which is 0 on sandbox, and the FDT-region bound sits behind a !CONFIG_SANDBOX guard in vbe_read_fit(), so fdt_size stays 0 and that block is skipped in this test environment. The new file follows the existing bootstd VBE test layout and writes the FIT at block 16, past the version and nvdata blocks already used by bootstd_setup_for_tests(). Suggested-by: Simon Glass Reviewed-by: Simon Glass Signed-off-by: Aristo Chen

vbe: bound FIT external-data offset and size before blk_read

2026-07-16T18:06:15Z

vbe_read_fit() loads a firmware-phase FIT from the trusted firmware area and then issues a blk_read() to pull in the image, and optionally an FDT, referenced by the FIT image node. The source offset on the device and the read length both come from the FIT's data-position or data-offset property and its data-size property, which live on mutable boot media and can be controlled by an attacker with prior write access to the firmware area. Without a range check the resulting blk_read() can read past the firmware area on the device and, on the non-SPL path, write an attacker-chosen number of blocks past the malloc(aligned_size) FIT buffer into adjacent memory. Only the SPL branch routes through spl_load_simple_fit(), which hashes the data. The external-data block reached from TPL or VPL, and from the bootflow path via abrec_read_bootflow_fw() and vbe_simple_read_bootflow_fw(), runs before any signature or hash check on the loaded phase. Confine the FIT-supplied [load_addr, load_addr + len) window to [addr, addr + area_size] before computing block numbers and lengths, and apply the same constraint to fdt_load_addr and fdt_size. The checks are written in subtraction-only form against the trusted area_size so the comparison itself cannot overflow. Reviewed-by: Simon Glass Signed-off-by: Aristo Chen

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

Merge patch series "Add DM firmware reserved memory support"

2026-07-16T18:05:25Z

Paresh Bhagat says: This series adds support for DM firmware reserved memory fixup in device tree for K3 SoCs that use separate DM firmware (K3_DM_FW enabled). The series includes: 1. Fix for phandle corruption in FDT reserved memory fixup 2. Enable OF_SYSTEM_SETUP for AM62D2 to allow device tree fixups 3. Add Kconfig options for DM firmware reserved memory for other K3 SoCs 4. Add DM reserved memory fixup implementation The main issue being addressed is that the current reserved DDR carveout for DM firmware in device tree is insufficient to accommodate the DM firmware binary on AM62A7, and potentially other K3 SoCs in the future. Currently, the size is only modified for AM62A7 SoC. For rest of SocS existing values from device tree is taken. For vendor boards, please verify boot and check for errors if any. This series depends on dts update for effected devices. If "dm" node is not found then the existing mechanism creates a new node with same address, which cause memory overlap issue. Link: https://lore.kernel.org/r/20260701075021.3626094-1-p-bhagat@ti.com

arm: mach-k3: Add DM reserved memory fixup

2026-07-16T18:04:48Z

Add support for fixing up DM firmware reserved memory in the kernel device tree for K3 SoCs that use separate DM firmware. The fixup uses the CONFIG_K3_DM_FW_RESERVED_ADDR and CONFIG_K3_DM_FW_RESERVED_SIZE Kconfig options to update the reserved-memory node with the correct DM firmware carveout. Note that the fixup needs DM reserved memory node is to be renamed in dts. Example memory@9c900000 → dm@9c900000 Signed-off-by: Paresh Bhagat Reviewed-by: Neha Malcom Francis

arm: mack-k3: Kconfig: Add DM firmware reserved memory configs

2026-07-16T18:04:48Z

Add Kconfig options for DM firmware reserved memory for K3 SOCs that support DM firmware (K3_DM_FW enabled) - K3_DM_FW_RESERVED_ADDR: DM firmware address - K3_DM_FW_RESERVED_SIZE: DM firmware reserved size These configs will be used to fixup the kernel device tree's reserved memory node for DM. Currently the fixup is only done for AM62A7 SoC, as K3_DM_FW_RESERVED_SIZE is being used to update DM reserved memory from 0xf0000 to 0x1f0000 as the current reserved carveout is insufficient to accommodate the binary. For other platforms, the addresses and sizes are based on the existing device tree reserved memory. If needed for other SoCs, address and size could be modified in Kconfig. Signed-off-by: Paresh Bhagat