u-boot.git/tools/binman/test, branch next

fdt: Fix phandles not copying when using templates

2026-08-28T14:49:30Z

The phandles used inside a template are not copied to the node inserting the template, leading to a missing phandle error. The following example can be used to reproduce the issue: &binman { some_template: template-0 { ti-secure-rom { content = <&some_data>; keyfile = "some_key"; }; some_data: blob-ext { optional; }; }; output-bin { insert-template = <&some_template>; }; }; With the error 'binman: Node '/binman/output-bin/ti-secure-rom': Cannot find node for phandle 103' observed. The test_copy_subnodes_from_phandles was also updated to verify the new behavior of phandles being copied. Reviewed-by: Moteen Shah Signed-off-by: Anshul Dalal Reviewed-by: Simon Glass

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

binman: Fix FIT image overlap issues for testFitSplitElf

2026-08-14T16:33:22Z

testFitSplitElf builds both the ATF and TEE test images from the same elf_sections binary, so the split-elf nodes generated for the two images end up with identical load addresses and overlap in memory. An upcoming commit teaches mkimage to validate whether the memory regions referenced by a configuration overlap, which makes this test fail. Update the test to use a non-overlapping memory layout so the two images no longer collide: 1. Add elf_sections_tee.lds, which mirrors elf_sections.lds with the section addresses shifted up by 0x100000 for the TEE image. 2. Build an elf_sections_tee binary from it in the test Makefile. 3. Update ftest.py to use the separate ELF file for the TEE component in split-elf operations. Signed-off-by: Aristo Chen Reviewed-by: Simon Glass

binman: Fix FIT image overlap issues

2026-08-14T16:33:21Z

Several binman test fixtures describe FIT images whose configuration references both a u-boot firmware image loaded at address 0x0 with a size of 0x2e bytes and a split-elf atf image whose first segment is loaded at 0x10, so the two images overlap in memory. The upcoming mkimage load address overlap check refuses to build such images, which makes the tests that run these fixtures through mkimage fail. Move the u-boot load and entry addresses to 0x2000, clear of the atf segments taken from elf_sections.lds, in the fixtures used by testFitFirmwareLoadables, testFitSignSimple, testFitSignNoSignatureNodes, testFitSignEngineSimple, testFitSignEncryptEngine, testFitSignPKCS11Simple, testFitSignPKCS11Object, testFitSignMultipleKeyPaths and testKeyNameHintIsPathSimpleFit. Signed-off-by: Aristo Chen Reviewed-by: Simon Glass

binman: add CST backend selection for i.MX8M signing

2026-08-03T12:31:24Z

Add support for setting the CST backend, both via DT property and CST_BACKEND environment variable. The CST currently supports two backends, 'ssl' and 'pkcs11', with 'ssl' being the default when CST tool is invoked without any -b parameter. Keep 'ssl' backend as the default, but explicitly pass it via the '-b' parameter, unless the user selects 'pkcs11' via either method. Signed-off-by: Marek Vasut Reviewed-by: Simon Glass

binman: imx8mimage: Generate FSPI header in binman instead of mkimage

2026-07-27T14:30:25Z

Stop depending on the current mkimage method of generating the FSPI header, instead generate the FSPI header within binman itself. This is more flexible, as the FSPI header properties can be configured from within the board-specific DT instead of being hard-coded in mkimage at build time. Acked-by: Peng Fan Signed-off-by: Marek Vasut Reviewed-by: Simon Glass

tools: binman: ti_board_cfg: Add configurable sw-rev support

2026-07-13T23:06:33Z

The software revision field in the combined board config binary header was hardcoded to 1, preventing independent control from SBL SWREV configured via ti-secure-rom's sw-rev property. Add support for the optional 'sw-rev' DTS property in ti_board_config nodes, which sets the SWREV byte in the header. Defaults to 1 for backward compatibility. Signed-off-by: Shiva Tripathi Reviewed-by: Simon Glass

binman: imx8mimage: Handle nxp,boot-from = "fspi"

2026-06-04T20:26:40Z

Boot from FSPI requires additional 448 Byte long header, with U-Boot SPL starting at offset 0x1000. Currently, both i.MX8MM and i.MX8MN attempt to generate this header using fspi_conf_block with filename pointing at CONFIG_FSPI_CONF_FILE file. This does not work, for two reasons. First, the CONFIG_FSPI_CONF_FILE is generated by mkimage -T imx8mimage and may not be available yet when the fspi_conf_block is evaluated. That leads to a race condition where highly parallel builds fail to find the CONFIG_FSPI_CONF_FILE, which is usually called fspi_header.bin, on first build attempt. Second, binman gets confused and patches incorrect offset of DDR PHY firmware blobs into U-Boot SPL, the offset is incremented by exactly 0x1000 which is the size of fspi_conf_block. Fix both problems at once, make imx8mimage handle the generated FSPI header and prepend it in front of the imx8mimage processed data. This way, the race condition is solved, because the data generated by the imx8mimage are surely combined only after mkimage -T imx8mimage ran. The binman offset calculation is also solved, because there is no fspi_conf_block node in the DT anymore. Signed-off-by: Marek Vasut

tools: binman: Test signing an encrypted FIT with a preload header

2026-05-05T16:37:09Z

Add a test to verify the preload header correctly signs an encrypted FIT. This test exercises the case where encryption uses random IVs that would change between mkimage calls. Signed-off-by: Paul HENRYS Reviewed-by: Simon Glass

test: binman: Add test for pkcs11 signed capsule

2026-03-18T12:14:17Z

Test pkcs11 URI support for UEFI capsule generation. Both public certificate and private key are used over pkcs11 protocol. Pkcs11-tool has been introduced as softhsm tool doesn't have functionality to import certificates in commonly distributed version (only in the latest). Signed-off-by: Wojciech Dubowik Reviewed-by: Simon Glass