<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/tools, branch next</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/tools?h=next</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/tools?h=next'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2026-08-28T14:49:30Z</updated>
<entry>
<title>fdt: Fix phandles not copying when using templates</title>
<updated>2026-08-28T14:49:30Z</updated>
<author>
<name>Anshul Dalal</name>
<email>anshuld@ti.com</email>
</author>
<published>2026-07-29T10:24:57Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b8d9223a454374681bf7d0d4384bb101be92110d'/>
<id>urn:sha1:b8d9223a454374681bf7d0d4384bb101be92110d</id>
<content type='text'>
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:

&amp;binman {
  some_template: template-0 {
    ti-secure-rom {
      content = &lt;&amp;some_data&gt;;
      keyfile = "some_key";
    };
    some_data: blob-ext {
      optional;
    };
  };
  output-bin {
    insert-template = &lt;&amp;some_template&gt;;
  };
};

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 &lt;m-shah@ti.com&gt;
Signed-off-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>tools: fit: sign all config image references</title>
<updated>2026-08-25T23:12:40Z</updated>
<author>
<name>James Hilliard</name>
<email>james.hilliard1@gmail.com</email>
</author>
<published>2026-08-10T23:43:07Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f252d228be2b2d180737ad0a851f91749273cbd9'/>
<id>urn:sha1:f252d228be2b2d180737ad0a851f91749273cbd9</id>
<content type='text'>
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 &lt;james.hilliard1@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>buildman: Differentiate 32-bit and 64-bit LoongArch variants</title>
<updated>2026-08-18T00:46:29Z</updated>
<author>
<name>Yao Zi</name>
<email>me@ziyao.cc</email>
</author>
<published>2026-08-06T12:29:57Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d2b6f7d9c4b42ce48c83593cdec7ae9780a31057'/>
<id>urn:sha1:d2b6f7d9c4b42ce48c83593cdec7ae9780a31057</id>
<content type='text'>
Similar to RISC-V and ARM, 32-bit and 64-bit LoongArch cannot be
distinguished solely by CONFIG_SYS_ARCH, but require different
toolchains if multilib is disabled in compiler, which is the case of
toolchain provided by kernel.org.

Override the parsed arch parameter for LoongArch configs based on
CONFIG_ARCH_LA64 Kconfig symbol.

Signed-off-by: Yao Zi &lt;me@ziyao.cc&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>Merge patch series "mkimage: detect FIT image load address overlaps"</title>
<updated>2026-08-14T16:33:22Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-08-14T16:31:51Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=cf51beb755939728b119a8762b06b6c186f53429'/>
<id>urn:sha1:cf51beb755939728b119a8762b06b6c186f53429</id>
<content type='text'>
Aristo Chen &lt;aristo.chen@canonical.com&gt;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
</content>
</entry>
<entry>
<title>binman: fit: document how ELF load addresses are determined</title>
<updated>2026-08-14T16:33:22Z</updated>
<author>
<name>Aristo Chen</name>
<email>aristo.chen@canonical.com</email>
</author>
<published>2026-07-31T00:13:41Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dbe1b57e16caa3587c14a4abcf63559a6833742a'/>
<id>urn:sha1:dbe1b57e16caa3587c14a4abcf63559a6833742a</id>
<content type='text'>
The fit,load property confuses users because the load address is
taken from the ELF file rather than being specified in the binman
node. Document how to inspect an ELF file to find out where its
segments will be loaded, using readelf, the linker script or objdump,
and point at the elf_sections and elf_sections_tee test linker
scripts as examples of two components placed to avoid overlapping
memory. Also note that the mkimage load address overlap check works
on packaged data sizes and therefore assumes uncompressed images.

Compared to the previously applied version of this change, the text
now lives in the fit etype docstring. The entry documentation is
produced from docstrings by the binman_docs Sphinx extension at
documentation build time, so no pre-generated file needs updating.

Signed-off-by: Aristo Chen &lt;aristo.chen@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>tools: mkimage: detect overlapping load regions in FIT configurations</title>
<updated>2026-08-14T16:33:22Z</updated>
<author>
<name>Aristo Chen</name>
<email>aristo.chen@canonical.com</email>
</author>
<published>2026-07-31T00:13:39Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=21bb6417641b26bfc6738ff9cbf006a47d317c27'/>
<id>urn:sha1:21bb6417641b26bfc6738ff9cbf006a47d317c27</id>
<content type='text'>
Add a validation step to mkimage that checks, for every configuration
of a FIT image, whether the images referenced by that configuration
declare overlapping load regions. Images that are loaded together must
not share memory, and such conflicts currently go unnoticed until the
resulting image corrupts memory at runtime.

The check is strictly per configuration. Images that share a load
address while being referenced by different configurations are not
reported, because only one configuration is selected at boot. This
matches the layout used by the TI K3 tispl images since commit
c85bf61b14f9 ("arm: k3: select tifsstub via board_fit_config_name_match"),
where the mutually exclusive tifsstub variants moved into per security
state configurations precisely so that static tooling can reason about
each configuration on its own.

Images without a load address or without data are skipped, since
nothing is copied anywhere for them. Compared to the previously
reverted version of this check, the missing load address case no
longer prints a warning, as FDT images routinely have no load address
and the warning only added noise to every build. An image referenced
through several properties of the same configuration, for example
listed in both firmware and loadables, is only counted once.

When an overlap is found mkimage prints the configuration name
together with both image names and their regions, then fails with
FDT_ERR_BADSTRUCTURE. Teach main() to exit cleanly for that value the
same way it already does for FDT_ERR_NOTFOUND, since the error
message has already been printed.

Signed-off-by: Aristo Chen &lt;aristo.chen@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>binman: Fix FIT image overlap issues for testFitSplitElf</title>
<updated>2026-08-14T16:33:22Z</updated>
<author>
<name>Aristo Chen</name>
<email>aristo.chen@canonical.com</email>
</author>
<published>2026-07-31T00:13:37Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4a65f3eb67f43201df5834dea776aec15b6b64f1'/>
<id>urn:sha1:4a65f3eb67f43201df5834dea776aec15b6b64f1</id>
<content type='text'>
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 &lt;aristo.chen@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>binman: Fix FIT image overlap issues</title>
<updated>2026-08-14T16:33:21Z</updated>
<author>
<name>Aristo Chen</name>
<email>aristo.chen@canonical.com</email>
</author>
<published>2026-07-31T00:13:36Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6ac5492d596dd28aa53c16106abae4a743cb5651'/>
<id>urn:sha1:6ac5492d596dd28aa53c16106abae4a743cb5651</id>
<content type='text'>
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 &lt;aristo.chen@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>binman: Fix typo for the test case name</title>
<updated>2026-08-14T16:33:21Z</updated>
<author>
<name>Aristo Chen</name>
<email>aristo.chen@canonical.com</email>
</author>
<published>2026-07-31T00:13:35Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5d1aba89f305366dd1ee59c5fd00e69cc9517cb8'/>
<id>urn:sha1:5d1aba89f305366dd1ee59c5fd00e69cc9517cb8</id>
<content type='text'>
Fix typo from `Singature` to `Signature`

Signed-off-by: Aristo Chen &lt;aristo.chen@canonical.com&gt;
Reviewed-by: Dhruva Gole &lt;d-gole@ti.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>binman: Do not dedent docstrings twice on Python 3.13+</title>
<updated>2026-08-13T21:02:15Z</updated>
<author>
<name>Alexey Charkov</name>
<email>alchark@flipper.net</email>
</author>
<published>2026-07-30T11:59:04Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7cb377e2492a9f1a7b2f8d3c9387dd5d89c2feb1'/>
<id>urn:sha1:7cb377e2492a9f1a7b2f8d3c9387dd5d89c2feb1</id>
<content type='text'>
WriteDocs() and write_bintool_docs() strip four characters from the start
of every docstring line but the first, to undo the indentation the source
file gives them. Since Python 3.13 the compiler already removes the common
indentation from docstrings [1], so this removes four characters of actual
text from every line of every entry and bintool description:

  $ binman entry-docs | head
  ...
   that an image node whose only content is an optional entry which was
   is an example showing ATF, TEE and a device tree all combined::

Use inspect.cleandoc() instead, which produces the same result on both
older and newer interpreters.

The existing tests only checked that some output was produced, so they
missed this entirely; make them also confirm that a known line of a known
description survives intact.

Link: https://github.com/python/cpython/issues/81283 [1]
Signed-off-by: Alexey Charkov &lt;alchark@flipper.net&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
</feed>
