u-boot.git/test/py/tests, branch next

test/py: nand: Add tests for NAND flash device

2026-08-28T20:57:37Z

Add tests for nand commands to test various NAND flash operations such as erase, write and read. Use the current test/py APIs (ubman fixture and utils helpers) and refactor the pre-command helper to return a dictionary. Also add the test_nand.py test to the generated documentation. See commit 8f8f0f0ed9d0 ("doc: pytest: Document the test_net_boot test") for the kinds of changes required for the docstring to be rendered correctly. Signed-off-by: Love Kumar

tools: fit: sign all config image references

2026-08-25T23:12:40Z

Target-side configuration verification builds the signed-region list from every image-reference property in the selected configuration. Host-side signing still uses either the signature node sign-images property or the legacy kernel/fdt/script default list. This lets mkimage generate configuration signatures which U-Boot cannot verify when the configuration references other image types, such as firmware, loadables or ramdisk entries. It also lets the host and target disagree when sign-images names only a subset of the configuration images. Build the host-side signing list from the configuration properties in the same way as target-side verification. Use one shared property classifier so the host and target cannot drift apart again. This makes signed configurations cover the root node, the configuration node, every referenced image node, and its hash, cipher and dm-verity subnodes, regardless of image type. Warn when a legacy sign-images property is present, since it no longer limits the signed image list. Require every referenced image to have at least one hash subnode. Add sandbox coverage proving that a firmware reference omitted from sign-images is still recorded in hashed-nodes and verified. Update the signed-configuration documentation to describe the same rule and the hash-subnode requirement. Fixes: 2092322b31cc ("boot: Add fit_config_get_hash_list() to build signed node list") Signed-off-by: James Hilliard Reviewed-by: Simon Glass

Merge tag 'v2026.10-rc3' into next

2026-08-25T01:31:25Z

Merge patch series "mkimage: detect FIT image load address overlaps"

2026-08-14T16:33:22Z

Aristo Chen m says: This series brings back the FIT load address overlap detection that was applied to next in September 2025 and reverted a day later in commit e482fdbbca93 ("Revert "Merge patch series "mkimage: Detect FIT image load address overlaps and fix related test/DTS issues"""). The v2 revert had two causes. On TI AM62x family boards the tispl FIT image references the mutually exclusive tifsstub variants at a single shared load address, and v2 tried to satisfy the checker by moving the variants 64 KiB apart. Neha had warned in the v1 review that this address is fixed by the platform and that moving the images would break tifsstub selection, and that feedback was regrettably still unaddressed when the series was applied. Nishanth then hit exactly this class of failure in the K3 upstream boot build with real firmware binaries, where am62px_evm, a board v2 had not even touched, failed the new check on tifsstub-hs and tifsstub-fs sharing 0x9ca00000. Separately, E Shattow reported an overlap on the StarFive VisionFive 2, which we later narrowed down to OpenSBI fw_payload.bin having been passed to the build instead of the documented fw_dynamic.bin. With fw_dynamic.bin the board has no overlap, as confirmed on the list in January 2026. Since then the structural fix for the tifsstub case has landed. The series merged as commit 4e7a9bb0885e ("Merge patch series "arm: k3: replace tifsstub runtime filter with per-state FIT configurations"") gives each K3 security state its own FIT configuration referencing only the matching tifsstub variant, so a per configuration overlap check sees no conflict while the variants keep their required common load address. That series was written precisely to unblock this one. The underlying semantics, that overlap is a property of a single configuration and that images referenced by different configurations never coexist in memory, were discussed with the FIT spec folks in flat-image-tree issue #32 [1]. The check itself is unchanged in spirit: for every configuration, collect the load regions of all referenced images that have both a load address and data, and fail the build if any two regions within that configuration intersect. Images referenced only by different configurations may freely share addresses. Verification done for this version: Running the new mkimage in reprocess mode over every FIT produced by current master builds of am62x_evm, verdin-am62 and phycore_am62x (A53 and R5 each) flags exactly one problem: the phycore u-boot FIT, where the four SPL devicetree overlays are loaded simultaneously from one configuration but are spaced only 4 KiB apart while each packaged image measures 5.9 to 6.1 KiB including its ti-secure certificate. That is a real overlap shipping today and patch 4 widens the spacing. All tispl FITs with the per-state tifsstub configurations pass. buildman with binman missing blob handling, matching CI, builds all of phycore_am62x, phycore_am62ax, phycore_am64x, am62x_evm, am62ax_evm, am62px_evm, am64x_evm, verdin-am62, verdin-am62p and am62x_beagleplay (A53 and R5 each) plus starfive_visionfive2 with the check active, since binman invokes the freshly built mkimage during these builds. starfive_visionfive2 was additionally built with a real OpenSBI 1.7 fw_dynamic.bin passed via OPENSBI and completes cleanly. The binman functional test suite shows no new failures compared to master in the same environment. The nine tests whose fixtures are touched by patches 1 to 3, including the OpenSSL engine and PKCS11 signing tests that only run when softhsm2 and opensc are available, all pass. The mkimage validation pytests, including the two new ones, pass against a sandbox build. [1] https://github.com/open-source-firmware/flat-image-tree/issues/32 Link: https://lore.kernel.org/r/20260731001347.35624-1-aristo.chen@canonical.com

test: fit: cover mkimage load address overlap detection

2026-08-14T16:33:22Z

Add a test that mkimage rejects a FIT image whose configuration references a kernel and an FDT with the same load address, and that the error message names the offending configuration and images. Also add a companion test for the intended escape hatch: two images may use the same load address as long as no single configuration references both of them. Only one configuration is selected at runtime, so such images never coexist in memory. This mirrors the TI K3 tispl layout after commit c85bf61b14f9 ("arm: k3: select tifsstub via board_fit_config_name_match"), where each security state has its own configuration and all tifsstub variants share one load address. Signed-off-by: Aristo Chen Reviewed-by: Simon Glass

Merge tag 'net-20260813' of https://git.u-boot-project.org/u-boot/custodians/u-boot-net

2026-08-13T14:58:29Z

Pull request net-20260813. net: - phy: dp83867: enable extended read / write for driver - phy: fix duplicate eth_phy binding - Drop unnecessary device_set_name - dwc_eth_xgmac: Return -ENODEV when phy_connect() fails - nfs: clean up bounds checks in nfs_readlink_reply() - rtl8169: add support for RTL8126A and RTL8127A - srand_mac(): fix -ENODEV crash with CONFIG_DM_RNG net-legacy: - Fix out-of-bounds write in IP fragment reassembly - test: net: add regression test for IP reassembly overflow net-lwip: - Add tftpsrv command - Handle chained pbufs in transmit path - sntp: fix netif leak when ntpserverip is unset - wget: free mbedtls x509 cert context to avoid memory leak - Fix DHCP fine timer interval

board_f: Call initf_malloc() before fdtdec_setup()

2026-08-10T20:48:11Z

In case MULTI_DTB_FIT_GZIP is enabled, fdtdec_setup() does uncompress the compressed DTs in uncompress_blob() using gunzip(), which invokes malloc() internally. The early simple malloc is initialized in board_f initf_malloc() call, which sets up the early simple malloc limit and offset pointer in global data. Currently, the initf_malloc() is called after fdtdec_setup(), which leads to malloc failure in fdtdec_setup() during the gzip decompression, because the early simple malloc is not initialized yet. Call initf_malloc() before fdtdec_setup() to assure fdtdec_setup() can use malloc() during gzip decompression of the DTs. The impact of this change on boot time is negligible, because the initf_malloc() only assigns two fields in global data. Signed-off-by: Marek Vasut Fixes: 95f4bbd581cf ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot") Reviewed-by: Simon Glass [trini: Update test/py/tests/test_trace.py] Signed-off-by: Tom Rini

Merge patch series "boot: fit: authenticate the dm-verity roothash"

2026-08-10T18:37:16Z

Daniel Golle says: A signed FIT configuration can delegate the integrity of a (potentially large) root filesystem image to the kernel's dm-verity instead of having U-Boot hash the whole payload at boot: the FIT carries a "dm-verity" subnode with the roothash, salt and block parameters, U-Boot passes the roothash to Linux through the dm-mod.create bootargs, and dm-verity then validates the filesystem block by block against it. For that to be safe the roothash has to be trusted, and in a signed configuration the only thing that establishes trust is the configuration signature. The roothash was not covered by it. fit_config_add_hash() collected the image node, its hash subnodes and its cipher subnode into the signed region, but not the dm-verity subnode, so the roothash, the sole integrity anchor for the filesystem, was left unsigned. The result is a verified-boot bypass for the root filesystem: an attacker who can rewrite the boot medium can replace the filesystem, recompute a matching dm-verity tree, write the new roothash into the unsigned dm-verity subnode, and the configuration signature still verifies. dm-verity then faithfully validates the malicious filesystem against the attacker's roothash. This series closes the gap. Link: https://lore.kernel.org/r/cover.1785276461.git.daniel@makrotopia.org

test: fit: verify dm-verity roothash is covered by the config signature

2026-08-10T18:32:41Z

A dm-verity protected filesystem image is not hashed by U-Boot; its integrity is delegated to the kernel, which trusts the roothash taken from the FIT dm-verity subnode. For that chain of trust to hold, the roothash (and salt) must be part of the region covered by the configuration signature, otherwise an attacker can replace both the filesystem and the roothash while keeping the signature valid. Add two independent checks of this property: - test/py/tests/test_fit_verity_sign.py signs a configuration that references a filesystem image carrying a dm-verity subnode, then confirms that tampering the roothash or the salt is rejected by fit_check_sign. A control that tampers a byte known to be signed proves the check can fail. A matching page is added under doc/develop/pytest/ so the module documentation is rendered with the rest of the generated docs. - test/boot/fit_verity.c gains a runtime unit test that builds the exact node list the configuration signature is computed over, turns it into hashed regions and checks both that the roothash bytes fall inside a signed region and that tampering them changes the hash. It needs no private key, so it also runs on real devices and uses the same hash path a device would. To let the unit test build the signed-region node list, rename the config node-list helper to fit_config_get_signed_nodes(), make it non-static and declare it in image.h. Signed-off-by: Daniel Golle Reviewed-by: Simon Glass

Merge tag 'efi-2026-01-rc2' of https://git.u-boot-project.org/u-boot/custodians/u-boot-efi

2026-07-28T13:52:13Z

Pull request efi-2026-01-rc2 CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-efi/-/pipelines/753 Documentation: * sandbox: fix enum host_platform_flags description * switch from setenv to env set and from printenv to env print * document Renesas R-Car Gen5 RSIP Cortex-R52 start * thead: lpi4a: detail how to enable fastboot UEFI: * unify and correct GUID selection for security database variables * test: check default GUID selection of security database variables * set correct frame buffer address * check efi_deserialize_load_option() in get_dp_device()