u-boot.git/tools/binman, branch v2026.07

tools: Stop packaging patman as a pip module

2026-07-06T14:28:50Z

patman is no longer shipped from the U-Boot tree, so drop it from the 'make pip' target and from make_pip.sh, and remove its packaging files (setup.py, pyproject.toml, requirements.txt). Nothing else refers to them by this point in the series, so they can go. Also fix binman's pyproject.toml, which declares package-data for a 'patman' package (a copy-paste leftover); use 'binman' instead. Signed-off-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

global: Update URL for U-Boot project

2026-05-25T15:30:47Z

Our official domain is now u-boot-project.org, so update all in-tree references to use the correct domain. Reviewed-by: Tony Dinh Reviewed-by: Peter Robinson Signed-off-by: Tom Rini

binman: Use bintool wrappers for PKCS#11 tools in tests

2026-05-11T18:05:10Z

The PKCS#11 signing tests in ftest.py call tools.run('softhsm2-util', ...) directly (and the equivalent for pkcs11-tool and p11-kit), even though the test setup has already constructed the corresponding Bintool instances. As Quentin Schulz observed on v1, the bintool wrapper for these tools is currently used only as an "is this installed?" probe. Route the eight remaining call sites in ftest.py through .run_cmd(...), which the Bintool base class already provides. The change is test-side only; no production binman code calls these tools. Suggested-by: Quentin Schulz Signed-off-by: Simon Glass

binman: Flesh out the softhsm2-util bintool docstring

2026-05-11T18:05:10Z

The Sphinx-generated bintools.rst currently produces an empty section for this bintool, since its class docstring is only a single line and so the body under the heading is blank. Extend the docstring with a short description of what softhsm2-util does and how binman uses it, so the generated documentation has useful content. Suggested-by: Heinrich Schuchardt Signed-off-by: Simon Glass

binman: Flesh out the pkcs11-tool bintool docstring

2026-05-11T18:05:10Z

The Sphinx-generated bintools.rst currently produces an empty section for this bintool, since its class docstring is only a single line and so the body under the heading is blank. Extend the docstring with a short description of what pkcs11-tool does and how binman uses it, so the generated documentation has useful content. Suggested-by: Heinrich Schuchardt Signed-off-by: Simon Glass

binman: Flesh out the p11-kit bintool docstring

2026-05-11T18:05:10Z

The Sphinx-generated bintools.rst currently produces an empty section for this bintool, since its class docstring is only a single line and so the body under the heading is blank. Extend the docstring with a short description of what p11-kit does and how binman uses it, so the generated documentation has useful content. Suggested-by: Heinrich Schuchardt Signed-off-by: Simon Glass

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

binman: collection: Set build_done on referenced entries

2026-05-05T16:37:09Z

The collection etype uses phandles in the 'content' property to reference other entries. Mark each referenced entry with build_done to avoid rebuilding the same entry data multiple times. This is important for cases where rebuilding may change the data content, e.g. due to timestamps or random IVs in encryption. Refactor GetContentsByPhandle() to return both the entry object and its data. Signed-off-by: yan wang Reviewed-by: Simon Glass

binman: Generate preload header and sign data only once

2026-05-05T16:37:09Z

To optimize preload generation, generate the header and signatures only after all data has been collected in ProcessContentsUpdate(). This avoids signing the data multiple times. Since header_size is known upfront (from __init__), create a placeholder in `ObtainContents()` to avoid an extra packing pass when ProcessContentsUpdate() detects a size change. This reduces unnecessary repacking and signing operations. Signed-off-by: Paul HENRYS Reviewed-by: Simon Glass