* Re: [v3,00/10] Generate Android boot images with binman
From: Simon Glass @ 2026-06-14 16:21 UTC (permalink / raw)
To: devnull+me.samcday.com; +Cc: u-boot
In-Reply-To: <20260610-android-binman-v3-0-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> Binman configs that produce flashable boot artifacts are introduced for
> the following devices:
>
> * google-sargo (vanilla v2)
> * oneplus-fajita (vanilla v2)
> * samsung-a5u-eur (QCDT v0)
> * samsung-gt510 (QCDT v0)
> * samsung-j7xelte (DTBH v0)
> To date, this last-mile packaging step has been trapped in downstream CI
> pipelines, blogposts, documentation, etc.
Please add a short doc page under doc/ describing the
android_boot/QCDT/DTBH entries from a board-porter's perspective -
what to put in the -u-boot.dtsi, how to flash the resulting image, and
which devices it has been tested on. The per-etype docstrings are
great as reference but a narrative intro would help adopters.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v3 08/10] binman: Add DTBH support
From: Simon Glass @ 2026-06-14 16:20 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-8-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> binman: Add DTBH support
>
> DTBH, used by Samsung S-BOOT bootloaders, is similar to QCDT. That is,
> it's a multi-record container that carries vendor-specific magic values
> to assist the previous bootloader in picking the appropriate FDT for the
> booting device.
>
> dtbTool-exynos was used as a reference for this implementation.
>
> Link: https://github.com/dsankouski/dtbtool-exynos
> Signed-off-by: Sam Day <me@samcday.com>
>
> tools/binman/etype/android_boot.py | 23 +++++
> tools/binman/etype/dtbh.py | 108 +++++++++++++++++++++
> tools/binman/ftest.py | 106 ++++++++++++++++++++
> tools/binman/test/dtbh.dts | 22 +++++
> tools/binman/test/dtbh_bad_model_info.dts | 20 ++++
> tools/binman/test/dtbh_invalid_pagesize.dts | 12 +++
> tools/binman/test/dtbh_missing_model_info.dts | 16 +++
> tools/binman/test/dtbh_missing_payload.dts | 15 +++
> tools/binman/test/dtbh_missing_subnodes.dts | 10 ++
> tools/binman/test/dtbh_multi.dts | 29 ++++++
> tools/binman/test/dtbh_multiple_dtbs.dts | 22 +++++
> tools/binman/test/dtbh_page_size_from_abootimg.dts | 30 ++++++
> tools/binman/test/dtbh_special_subnodes.dts | 11 +++
> 13 files changed, 424 insertions(+)
> diff --git a/tools/binman/etype/dtbh.py b/tools/binman/etype/dtbh.py
> @@ -0,0 +1,108 @@
> +# Fixed per-record "space delimiter" used by dtbTool-exynos.
> +# It's unclear what the 0x20 magic actually means, if anything.
> +DTBH_RECORD_SPACE = 0x20
Did you try probing a real S-BOOT to see if it cares? If it really is
ignored, please say so explicitly ('S-BOOT appears to ignore this
field; dtbTool-exynos emits 0x20 so we do too').
> diff --git a/tools/binman/etype/dtbh.py b/tools/binman/etype/dtbh.py
> @@ -0,0 +1,108 @@
> +DTBH_MAGIC = b'DTBH'
> +DTBH_VERSION = 2
Just to check, are there older DTBH versions in the wild we might need
to support, or is v2 the only thing S-BOOT will accept? A one-line
comment would help future readers.
Reviewed-by: Simon Glass <sjg@chromium.org>
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v3 07/10] binman: Add QCDT support
From: Simon Glass @ 2026-06-14 16:19 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-7-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> binman: Add QCDT support
>
> This vendor-specific format is used by many bootloaders on older qcom
> SoCs, such as msm8916. It's a container for N FDTs. Each one is
> contained in a record that includes metadata about the platform/variant
> it targets. The previous bootloader picks the 'right' record based on
> this metadata.
>
> This initial impl targets a streamlined v2 path, with no support for
> different versions or multiple qcom,msm-id/qcom,board-id tuples. If/when
> that's needed it will be implemented in a follow-up.
>
> In the following commit, support for DTBH will also be introduced.
> Because QCDT and DTBH share a lot of common behaviour, this commit also
> introduces a Entry_Android_vendor_dt_table base class.
>
> This impl was based on the lk2nd/CAF LK dtbTool script.
>
> Link: https://github.com/msm8916-mainline/lk2nd/blob/main/lk2nd/scripts/dtbTool
> Signed-off-by: Sam Day <me@samcday.com>
>
> tools/binman/android_vendor_dt_table.py | 104 +++++++++++++++++++++
> tools/binman/etype/android_boot.py | 31 ++++++
> tools/binman/etype/qcdt.py | 80 ++++++++++++++++
> tools/binman/ftest.py | 96 +++++++++++++++++++
> tools/binman/test/qcdt.dts | 36 +++++++
> tools/binman/test/qcdt_bad_msm_id.dts | 17 ++++
> tools/binman/test/qcdt_invalid_pagesize.dts | 12 +++
> tools/binman/test/qcdt_missing_msm_id.dts | 12 +++
> tools/binman/test/qcdt_missing_payload.dts | 14 +++
> tools/binman/test/qcdt_missing_subnodes.dts | 13 +++
> tools/binman/test/qcdt_multiple_dtbs.dts | 34 +++++++
> tools/binman/test/qcdt_page_size_from_abootimg.dts | 33 +++++++
> tools/binman/test/qcdt_zero_pagesize.dts | 12 +++
> 13 files changed, 494 insertions(+)
> diff --git a/tools/binman/android_vendor_dt_table.py b/tools/binman/android_vendor_dt_table.py
> @@ -0,0 +1,104 @@
> +class Entry_Android_vendor_dt_table(Entry_section):
> + """Base class for legacy Android vendor DT table entries"""
The capital A breaks the naming convention every other entry type
follows (Entry_section, Entry_android_boot).
I'm not 100% sure about the best way to do this base class - but let's
run with what you have and see how it goes. We can always tweak later,
e.g. if someone else does a similar thing.
> diff --git a/tools/binman/android_vendor_dt_table.py b/tools/binman/android_vendor_dt_table.py
> @@ -0,0 +1,104 @@
> + def ReadEntries(self):
> + for node in self._node.subnodes:
> + if self.IsSpecialSubnode(node):
> + continue
> +
> + payloads = self._GetPayloadSubnodes(node)
> + if len(payloads) > 1:
> + self.Raise("subnode '%s': must contain exactly one DTB "
> + "payload subnode" % node.name)
> + if not payloads:
> + continue
The qcdt docstring advertises dtb-* subnodes, but nothing here
enforces the name - any non-special subnode is treated as a DTB
record. Either enforce the dtb- prefix so a typo produces a clear
error, or drop the implication from the docs.
Also, silently skipping a record node with no payload subnode means
the missing-payload error only surfaces later in _GetDtbData() -
raising at ReadEntries time would give a more obvious error location.
> diff --git a/tools/binman/etype/qcdt.py b/tools/binman/etype/qcdt.py
> @@ -0,0 +1,80 @@
> + Properties / Entry arguments:
> + - page-size: QCDT page size, defaults to 2048, unless there's a parent
> + android-boot node with an explicit page-size
> +
> + This entry uses the following subnodes:
> + - dtb-*: DTB records, each containing qcom,msm-id, qcom,board-id and
> + exactly one DTB payload entry
The docs do not mention that QCDT_VERSION is hardcoded to 2, nor do
they describe what qcom,msm-id and qcom,board-id actually mean
(platform_id/soc_rev and variant_id/hw_subtype). Since the etype
rejects malformed values with a specific cell-count error, users will
need this info to author a working DTS. Please flesh out the
docstring.
> diff --git a/tools/binman/etype/qcdt.py b/tools/binman/etype/qcdt.py
> @@ -0,0 +1,80 @@
> + def BuildSectionData(self, required):
> + page_size = self._GetPageSize()
> + dtbs = self._ReadDtbRecords(required, self._ReadDtbRecord)
> + if dtbs is None:
> + return None
> +
> + size = QCDT_HEADER_SIZE + len(dtbs) * QCDT_RECORD_SIZE
> + dtb_offset = self.AlignUp(size, page_size)
Just to check - page_size falls back to 2048 when no explicit setting
and no parent android-boot is found. There is no validation that
page_size is at least QCDT_HEADER_SIZE + N*QCDT_RECORD_SIZE; if a
caller sets a tiny page-size and many DTBs, the first dtb_offset
overflows into the page allocated for the header. Worth a sanity
check, matching the V0/V2 header-size checks in android_boot.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v3 06/10] binman: android_boot: vendor-dt support
From: Simon Glass @ 2026-06-14 16:19 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-6-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> binman: android_boot: vendor-dt support
>
> There's many Android bootloaders out there that expect non-standard
> abootimgs. Samsung and Qualcomm, and likely many others. This quirk has
> been codified in the widely used osm0sis fork/rewrite of mkbootimg.
>
> Presumably, these vendor-specific abootimgs were conceived before the v2
> format was widely available or specified. The evidence for this is their
> hijacking of the header_version field to specify the length of a payload
> that follows the main abootimg.
>
> At least QCDT and DTBH (both of which will be implemented as binman
> etypes in following commits) use this approach.
>
> Link: https://github.com/osm0sis/mkbootimg
> Signed-off-by: Sam Day <me@samcday.com>
>
> tools/binman/etype/android_boot.py | 41 ++++++++++++++++++++++++++--
> tools/binman/ftest.py | 15 ++++++++++
> tools/binman/test/android_boot_vendor_dt.dts | 27 ++++++++++++++++++
> 3 files changed, 81 insertions(+), 2 deletions(-)
> diff --git a/tools/binman/etype/android_boot.py b/tools/binman/etype/android_boot.py
> @@ -198,8 +217,14 @@ class Entry_android_boot(Entry_section):
> return default
> return entry.GetData(required)
>
> + def _BuildVendorDt(self, required):
> + if not self.vendor_dt_node:
> + return b''
> + return self._GetEntryData('vendor-dt', required)
> +
> def _BuildV0SectionData(self, required):
> kernel = self._GetEntryData('kernel', required)
> + vendor_dt = self._BuildVendorDt(required)
Since _ReadVendorDtEntries already stores the section under
self._entries['vendor-dt'], this helper is just a thin wrapper. I
think you can drop _BuildVendorDt and write:
vendor_dt = self._GetEntryData('vendor-dt', required, b'')
which mirrors how ramdisk is handled just below. What do you think?
> diff --git a/tools/binman/etype/android_boot.py b/tools/binman/etype/android_boot.py
> @@ -211,8 +236,18 @@ class Entry_android_boot(Entry_section):
> BOOT_ARGS_SIZE)
>
> boot_id_payloads = [kernel, ramdisk, b'']
> + if self.vendor_dt_node:
> + boot_id_payloads.append(vendor_dt)
> image_id = self._BootId(*boot_id_payloads)
>
> + overloaded_header_version = self.header_version
> + if self.vendor_dt_node:
> + # vendor DTs overload the header_version field to store the length
> + # of the appended payload. Hopefully AOSP abootimg never progresses
> + # to v8192-ish or we might have some real specificity problems on
> + # our hands.
> + overloaded_header_version = len(vendor_dt)
Stray double space after the '=' on the assignment. Worth noting in
the docstring that the vendor-dt subnode is itself a section, with a
small example showing how to compose this with the QCDT/DTBH etypes
added later.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v3 04/10] binman: Android boot image support
From: Simon Glass @ 2026-06-14 16:18 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-4-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> binman: Android boot image support
>
> Introduce initial support for Android boot images (abootimgs).
>
> The AOSP implementation was used as a reference for this work.
>
> We start with just v0 and v2 support. v1/v3/v4 are deliberately left
> unimplemented for now as no use-case has been found for them yet.
>
> Since we're targeting U-Boot use cases here, a couple of things were
> omitted from this impl, namely 'second' and recovery_dtbo support.
>
> Link: https://android.googlesource.com/platform/system/tools/mkbootimg/
> Signed-off-by: Sam Day <me@samcday.com>
>
> tools/binman/etype/android_boot.py | 285 +++++++++++++++++++++
> tools/binman/ftest.py | 148 +++++++++++
> tools/binman/test/android_boot_chonky_cells.dts | 13 +
> tools/binman/test/android_boot_dtb_in_v0.dts | 12 +
> tools/binman/test/android_boot_invalid_addr.dts | 13 +
> .../binman/test/android_boot_invalid_pagesize.dts | 11 +
> tools/binman/test/android_boot_invalid_subnode.dts | 12 +
> tools/binman/test/android_boot_missing_kernel.dts | 9 +
> .../test/android_boot_oversized_bootname.dts | 12 +
> .../test/android_boot_unsupported_version.dts | 11 +
> tools/binman/test/android_boot_v0.dts | 34 +++
> .../test/android_boot_v0_pagesize_too_smol.dts | 12 +
> tools/binman/test/android_boot_v2.dts | 50 ++++
> tools/binman/test/android_boot_v2_missing_dtb.dts | 12 +
> .../test/android_boot_v2_pagesize_too_smol.dts | 13 +
> tools/binman/test/android_boot_v2_vendor_dt.dts | 14 +
> 16 files changed, 661 insertions(+)
> diff --git a/tools/binman/etype/android_boot.py b/tools/binman/etype/android_boot.py
> @@ -0,0 +1,285 @@
> + def _BuildV0SectionData(self, required):
> + kernel = self._GetEntryData('kernel', required)
> + ramdisk = self._GetEntryData('ramdisk', required, b'')
> + if not required and (kernel is None or vendor_dt is None or
> + ramdisk is None):
> + return None
...
> diff --git a/tools/binman/test/android_boot_v2_vendor_dt.dts b/tools/binman/test/android_boot_v2_vendor_dt.dts
> @@ -0,0 +1,14 @@
> + android-boot {
> + header-version = <2>;
> + kernel {};
> + dtb {};
> + vendor-dt {};
> + };
This fixture and the corresponding testAndroidBootV2VendorDt() in
ftest.py belong in patch 6 - they exercise the vendor-dt subnode which
this patch does not yet recognise. Against this commit alone,
ReadEntries() raises "Unexpected subnode 'vendor-dt'" rather than the
message the test asserts on. Also vendor_dt is not defined
yet...please bisect-check the series.
> diff --git a/tools/binman/etype/android_boot.py b/tools/binman/etype/android_boot.py
> @@ -0,0 +1,285 @@
> +BOOT_IMAGE_HEADER_V0 = '<{}s10I{}s{}s{}s'.format(len(BOOT_MAGIC),
> + BOOT_NAME_SIZE,
> + BOOT_ARGS_SIZE,
> + IMAGE_ID_SIZE)
Continuation lines are over-indented past the opening paren. Please
align with the '(' or drop to a single hanging indent.
> diff --git a/tools/binman/etype/android_boot.py b/tools/binman/etype/android_boot.py
> @@ -0,0 +1,285 @@
> + boot_id_payloads = [kernel, ramdisk, b'']
> + image_id = self._BootId(*boot_id_payloads)
The v2 path passes the payloads inline to _BootId() - please do the
same here for consistency; the temporary list doesn't seem worth it.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v3 03/10] binman: section: add AlignUp+PadToAlignment helpers
From: Simon Glass @ 2026-06-14 16:18 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-3-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> binman: section: add AlignUp+PadToAlignment helpers
>
> In the following commits we will be introducing new etypes derived from
> Entry_section which need to align values and pad data. To avoid
> duplication we introduce the shared helpers here.
>
> tools/binman/etype/section.py | 9 +++++++++
> 1 file changed, 9 insertions(+)
> diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
> @@ -1040,3 +1040,12 @@ class Entry_section(Entry):
> + def AlignUp(self, value, align):
> + """Return value aligned to given power of 2"""
> + return (value + align - 1) & ~(align - 1)
We already have tools.align() in u_boot_pylib which does exactly this,
and it is used widely in binman - please drop AlignUp() and have the
qcdt/dtbh/android_boot callers use tools.align() directly.
> diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
> @@ -1040,3 +1040,12 @@ class Entry_section(Entry):
> +
> + def PadToAlignment(self, data, align):
> + """Null-pads given data to given power of 2"""
> + return data + b'\0' * (self.AlignUp(len(data), align) - len(data))
This is a one-liner over tools.align() + tools.get_bytes():
data + tools.get_bytes(0, tools.align(len(data), align) - len(data))
I'd rather not add a method on Entry_section just for this - neither
helper uses self, and the new etypes are the only callers. If you do
want a shared helper, please put it in u_boot_pylib/tools.py as a
plain function (e.g. pad_align()) alongside align() and get_bytes(),
and use snake_case to match the convention there.
Also, stray double blank line between the two new methods.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v3 02/10] binman: test name globbing support
From: Simon Glass @ 2026-06-14 16:18 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-2-710298a38fcc@samcday.com>
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> binman: test name globbing support
>
> This makes invocations like binman test testAndroid* possible. It also
> composes well with the previous commit that adds support for multiple
> test names: binman test 'testAndroid*' 'testQcdt*' also works as you'd
> expect.
>
> tools/binman/cmdline.py | 2 +-
> tools/u_boot_pylib/test_util.py | 12 +++++++-----
> 2 files changed, 8 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply
* Re: [PATCH v3 01/10] binman: support running multiple tests
From: Simon Glass @ 2026-06-14 16:18 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-1-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> binman: support running multiple tests
>
> The helptext for binman test suggests that this was already supported,
> but it wasn't properly wired up.
>
> tools/binman/main.py | 8 ++++----
> tools/u_boot_pylib/test_util.py | 23 ++++++++++++++++-------
> 2 files changed, 20 insertions(+), 11 deletions(-)
This looks good.
> diff --git a/tools/u_boot_pylib/test_util.py b/tools/u_boot_pylib/test_util.py
> @@ -157,7 +157,7 @@ def run_test_suites(toolname, debug, verbosity, no_capture, test_preserve_dirs,
> the output directory for this test. Both directories are displayed
> on the command line.
> processes: Number of processes to use to run tests (None=same as #CPUs)
> - test_name: Name of test to run, or None for all
> + test_name: Name of test, or list of test names, to run; None for all
> toolpath: List of paths to use for tools
Since the parameter now accepts a list, please rename it to test_names
and update the four other callers (tools/patman/__main__.py,
tools/dtoc/main.py, tools/buildman/main.py,
tools/u_boot_pylib/__main__.py, tools/dtoc/test_fdt.py) at the same
time. The isinstance() branch then goes away too.
> diff --git a/tools/u_boot_pylib/test_util.py b/tools/u_boot_pylib/test_util.py
> @@ -182,12 +182,19 @@ def run_test_suites(toolname, debug, verbosity, no_capture, test_preserve_dirs,
> resultclass=FullTextTestResult,
> )
>
> - if use_concurrent and processes != 1 and not test_name:
> + if isinstance(test_name, str):
> + test_names = [test_name]
> + else:
> + test_names = list(test_name or [])
> + test_name_set = set(test_names)
test_name_set is dead by the end of patch 2, which replaces 'module in
test_name_set' with _match_name(module). Please fold the two patches
so this set is never introduced, or skip building it here and just use
'in test_names' until patch 2 replaces the check.
> diff --git a/tools/binman/main.py b/tools/binman/main.py
> @@ -58,8 +58,8 @@ def RunTests(debug, verbosity, processes, test_preserve_dirs, args, toolpath):
> the output directory for this test. Both directories are displayed
> on the command line.
> processes: Number of processes to use to run tests (None=same as #CPUs)
> - args: List of positional args provided to binman. This can hold a test
> - name to execute (as in 'binman test testSections', for example)
> + args: List of positional args provided to binman. This can hold test
> + names to execute (as in 'binman test testSections', for example)
While you are here, the line above ("If a single test is selected (in
args[0]) it also preserves the output directory for this test") is now
stale - preserve_outdirs fires for any number of selected tests. Same
comment for the matching docstring in run_test_suites(). Please tidy
both up.
Regards,
Simon
^ permalink raw reply
* Re: [v1,0/2] bootdev: few fixes for automatic boot
From: Simon Glass @ 2026-06-14 16:15 UTC (permalink / raw)
To: dmukhin; +Cc: u-boot
In-Reply-To: <20260611014843.3735672-1-dmukhin@ford.com>
Hi Denis,
On 2026-06-11T01:48:41, None <dmukhin@ford.com> wrote:
> This mini-series addresses few findings in bootdev code.
Thanks for looking at this.
Patch 2 changes the bootdev hunting behaviour, which is covered by the
sandbox tests in test/boot/bootflow.c (bootflow_scan_drvs() and
friends). Please can you add a test for the new fall-through: a
high-priority bootdev whose hunter fails, followed by a lower-priority
bootdev that still gets scanned? Without that we have no regression
coverage.
Regards,
Simon
^ permalink raw reply
* [PULL] u-boot-sh/master
From: Marek Vasut @ 2026-06-14 16:08 UTC (permalink / raw)
To: u-boot, Tom Rini; +Cc: Marek Vasut
Two fixes for R-Car Gen5 RSIP, one to surely build u-boot-elf.shdr and
one to make u-boot-elf.shdr compatible with tooling.
Two fixes for R-Car Gen4, which could hang in SPL without them.
The following changes since commit 5ca1a73c7d3064582498a8aa96c29e714402a6d3:
Merge patch series "configs: imx95: enable PCI_INIT_R for Toradex modules" (2026-06-12 08:45:32 -0600)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-sh.git master
for you to fetch changes up to cc5d760ace890b57d78b23aafb47ba220e63ae4f:
arm64: renesas: Initialize GIC600 fully on R-Car S4/V4H/V4M (2026-06-14 04:01:39 +0200)
----------------------------------------------------------------
Marek Vasut (4):
arm: renesas: Build u-boot-elf.shdr for R-Car X5H Cortex-M33 RSIP port
arm: renesas: Make R-Car Gen5 u-boot-elf.shdr compatible with SDK flash_writer
arm64: renesas: Fold mach_cpu_init into board_init_f on R-Car S4/V4H/V4M SPL
arm64: renesas: Initialize GIC600 fully on R-Car S4/V4H/V4M
Kconfig | 3 ++-
arch/arm/mach-renesas/Kconfig.rcar4 | 3 +++
arch/arm/mach-renesas/Makefile | 2 ++
board/renesas/common/gen4-spl.c | 41 ++++++++++++++++---------------------
4 files changed, 25 insertions(+), 24 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 09/10] arch: arm: exynos: add j7xelte binman config
From: Simon Glass @ 2026-06-14 16:03 UTC (permalink / raw)
To: me
Cc: u-boot, Tom Rini, Simon Glass, Alper Nebi Yasak, Quentin Schulz,
Bryan Brattlof, Yannic Moog, Wojciech Dubowik, Yegor Yefremov,
Patrice Chotard, Heinrich Schuchardt, Marek Vasut,
Rasmus Villemoes, Javier Tia, Minkyu Kang, Kaustabh Chakraborty,
Henrik Grimler, yan wang, Marek Vasut, Denis Mukhin
In-Reply-To: <20260610-android-binman-v3-9-710298a38fcc@samcday.com>
Hi Sam,
On 2026-06-10T01:27:41, Sam Day via B4 Relay
<devnull+me.samcday.com@kernel.org> wrote:
> arch: arm: exynos: add j7xelte binman config
>
> Note that, as of this commit, j7xelte does not yet exist in U-Boot's
> upstream DTS tree. It was accepted into next so it should appear here
> eventually.
>
> Link: https://lore.kernel.org/all/177209522223.26390.6219893536178441080.b4-ty@kernel.org/
> Signed-off-by: Sam Day <me@samcday.com>
>
> arch/arm/dts/exynos7870-j7xelte-u-boot.dtsi | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> diff --git a/arch/arm/dts/exynos7870-j7xelte-u-boot.dtsi b/arch/arm/dts/exynos7870-j7xelte-u-boot.dtsi
> new file mode 100644
> index 00000000000..0cd4c12a2e4
> --- /dev/null
> +++ b/arch/arm/dts/exynos7870-j7xelte-u-boot.dtsi
As already mentioned the commit message only explains the caveat but
does not say what the patch does. Please add a sentence describing the
change - i.e. that this wires up binman to produce a DTBH+abootimg
flashable for the j7xelte's S-BOOT.
Just to check, is exynos7870-j7xelte.dts in the tree somewhere or is
that coming later?
Reviewed-by: Simon Glass <sjg@chromium.org>
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v5 2/2] binman: x509_cert: support PKCS#11 URI in keyfile for HSM signing
From: Simon Glass @ 2026-06-14 16:01 UTC (permalink / raw)
To: sergio.prado
Cc: u-boot, trini, sjg, alpernebiyasak, ilias.apalodimas,
marek.vasut+renesas, sughosh.ganu, wolfgang.wallner, bb,
xypron.glpk, y.moog, afd, quentin.schulz, Wojciech.Dubowik
In-Reply-To: <20260525132828.3348679-3-sergio.prado@e-labworks.com>
Hi Sergio,
On 2026-05-25T13:28:26, Sergio Prado <sergio.prado@e-labworks.com> wrote:
> binman: x509_cert: support PKCS#11 URI in keyfile for HSM signing
>
> Allow x509 certificate entries to be signed using a key stored in an
> HSM by accepting a PKCS#11 URI (RFC 7512) as the value of the
> 'keyfile' entry argument, instead of a path to a PEM key file on
> disk. The URI is forwarded as-is to openssl '-key', which resolves it
> via the pkcs11 provider configured externally through OPENSSL_CONF.
>
> A new make variable BINMAN_X509_KEY_URI is introduced. When set, it
> overrides the 'keyfile' entry argument for all x509 certificate
> signing operations:
>
> make BINMAN_X509_KEY_URI="pkcs11:token=mytk;object=mykey;type=private" \
> OPENSSL_CONF=/path/to/openssl.cnf
>
> Two URI forms are supported on OpenSSL 3.x:
>
> - Provider path: pkcs11:token=...;object=...;type=private
> - Engine path: org.openssl.engine:pkcs11:pkcs11:token=...;...
>
> [...]
>
> Makefile | 1 +
> tools/binman/binman.rst | 55 +++++++++++++++++
> tools/binman/etype/x509_cert.py | 37 ++++++++++--
> tools/binman/ftest.py | 92 +++++++++++++++++++++++++++++
> tools/binman/test/fit/openssl_provider.conf | 14 +++++
> 5 files changed, 194 insertions(+), 5 deletions(-)
> diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
> @@ -88,6 +93,15 @@ class Entry_x509_cert(Entry_collection):
> + # When keyfile is a PKCS#11 URI and PKCS11_PIN is set, append the
> + # PIN to the URI so signing runs non-interactively. The preferred
> + # way to deliver a PIN is to configure pkcs11-module-token-pin in
> + # openssl.cnf; PKCS11_PIN is the convenience fallback.
> + key_fname = self.key_fname
> + pin = os.environ.get('PKCS11_PIN')
> + if pin and 'pkcs11:' in key_fname:
> + key_fname = self._build_pkcs11_key(key_fname, pin)
nit: the 'pkcs11:' substring test is loose - a filesystem path
containing that token would be treated as a URI. Please use
key_fname.startswith(('pkcs11:', 'org.openssl.engine:')) instead.
Also, the commit message says the URI is forwarded as-is to openssl
-key, which isn't quite true once PKCS11_PIN is appended. Please
reword to match the code.
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> @@ -6905,6 +6906,97 @@ fdt fdtmap Extract the devicetree blob from the fdtmap
> + def testX509CertPkcs11(self):
> + """Test X509 certificate signing via a PKCS#11 URI in keyfile"""
The test only exercises the provider form; the engine prefix is
documented as supported but not covered. A small extra case in
testX509CertBuildPkcs11Key for an engine-prefixed URI would catch
regressions in the combiner without needing libengine-pkcs11-openssl
installed.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v5 1/2] binman: x509_cert: document Entry_x509_cert properties
From: Simon Glass @ 2026-06-14 16:00 UTC (permalink / raw)
To: sergio.prado
Cc: u-boot, trini, sjg, alpernebiyasak, ilias.apalodimas,
marek.vasut+renesas, sughosh.ganu, wolfgang.wallner, bb,
xypron.glpk, y.moog, afd, quentin.schulz, Wojciech.Dubowik
In-Reply-To: <20260525132828.3348679-2-sergio.prado@e-labworks.com>
On 2026-05-25T13:28:26, Sergio Prado <sergio.prado@e-labworks.com> wrote:
> binman: x509_cert: document Entry_x509_cert properties
>
> The Entry_x509_cert class only listed 'content' in its
> 'Properties / Entry arguments' section, even though 'keyfile',
> 'cert-ca', 'cert-revision-int' and 'sw-rev' are also read from the
> entry node and passed through to openssl.
>
> Expand the docstring so the binman documentation generated from it
> matches the actual behavior of the entry.
>
> No functional change.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
>
> tools/binman/etype/x509_cert.py | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply
* Re: [PATCH 1/7] qcom: capsule: add FIT capsule support with multi-partition
From: Casey Connolly @ 2026-06-14 15:29 UTC (permalink / raw)
To: Simon Glass, Ilias Apalodimas
Cc: Balaji Selvanathan, Sumit Garg, u-boot-qcom, u-boot, Tom Rini,
Neil Armstrong, Alexey Minnekhanov, Heinrich Schuchardt,
Mattijs Korpershoek, Jerome Forissier, Marek Vasut, Aswin Murugan,
Luca Weiss, Varadarajan Narayanan
In-Reply-To: <CAFLszTg2Ettpbi6RZmPnm2O_mTUsaxT+pv_AevpS834XRovRAQ@mail.gmail.com>
On 6/14/26 14:13, Simon Glass wrote:
> Hi Ilias,
>
> On Mon, 25 May 2026 at 15:07, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
>>
>> Hi Simon,
>>
>> On Mon, 25 May 2026 at 21:10, Simon Glass <sjg@chromium.org> wrote:
>>>
>>> Hi all,
>>>
>>> On Mon, 25 May 2026 at 05:24, Balaji Selvanathan
>>> <balaji.selvanathan@oss.qualcomm.com> wrote:
>>>>
>>>> Hi Ilias,
>>>>
>>>> On 5/23/2026 6:23 PM, Ilias Apalodimas wrote:
>>>>> [...]
>>>>>
>>>>>>>> To support multi-image RAW capsules, we would need to:
>>>>>>>>
>>>>>>>> 1. Enhance mkeficapsule to create multi-image capsules?
>>>>>>> There's an equivalent tool in EDKII that can produce a capsule with
>>>>>>> multiple payloads. There were also patches posted for mkeficapsule,
>>>>>>> but need some minor tweaks to merge them
>>>>>> Can you please point me those patches? I did a search myself, but
>>>>>> couldnt find those patches.
>>>>> https://lore.kernel.org/u-boot/20240419065542.1160527-1-sughosh.ganu@linaro.org/
>>>>
>>>> This patch you mentioned here can create capsule with only one payload;
>>>> means for multiple binaries we need to create multiple capsules. I have
>>>> also asked the person who made this series to respin, but havent heard
>>>> back from him.
>>>
>>> Before this respins as multi-payload RAW, I'd like to push back on the
>>> suggestion that FIT is the wrong answer here.
>>>
>>> CONFIG_EFI_CAPSULE_FIRMWARE_FIT is already a first-class handler in
>>> efi_firmware.c next to the RAW one.
>>
>> We accepted it back then because we lacked capsule authentication. I
>> really want to remove it now, since I see no point having a capsule
>> within a FIT.
>
> I may have misunderstood something here. My understanding with this
> series is that there is a FIT containing multiple images which all
> need updating atomically. So there is one ESRT, isn't there? How does
> it result in a capsule being inside a FIT?
>
>>
>>> So the choice isn't whether to add
>>> a new mechanism, just which of the two existing handlers Qualcomm
>>> wires up. Both produce an FMP and an ESRT entry; the OS-visible UEFI
>>> behaviour is identical. The difference is entirely in what sits inside
>>> the capsule payload.
>>
>> Not really. FIT capsule will expose a single FMP entry and no
>> information of the firmware components in the esrt, unless I remember
>> the code wrong.
>
> Well, FIT is designed to hold components so it is provided there, in a
> manner native to U-Boot.
Regardless of the merits of FIT, the EFI capsule spec explicitly
supports having multiple images in a single capsule and updating all of
them at once. U-Boot also already has the wiring for this. FIT is
totally unnecessary here particularly since we don't live in the world
where we use FIT for everything, so we don't gain any common tooling or
abstraction by using it for this one case. As Ilias clearly pointed out
we /lose/ visibility as EFI tooling just sees a FIT image as a binary blob.
If you wish to keep discussing in this thread please drop me from CC.
^ permalink raw reply
* [PATCH] mtd: spi-nor: Add Dosilicon DS25Q4BB support
From: Ssunk @ 2026-06-14 13:44 UTC (permalink / raw)
To: Vignesh R; +Cc: Takahiro Kuwano, Tom Rini, u-boot, Ssunk
Add support for dosilicon ds25q4bb (256M-bit) SPI NOR flash.
Datasheet:
https://drive.google.com/file/d/17UFJa5_3imH0YmWlRGTQYhO2JBXf4Klk/view
Signed-off-by: Ssunk <ssunkkan@gmail.com>
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index c0fa98424aa..b370e782627 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -87,6 +87,8 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("ds25q4dn", 0xe5301b, 0, 64 * 1024, 2048,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+ { INFO("ds25q4bb", 0xe53019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
#endif
#ifdef CONFIG_SPI_FLASH_EON /* EON */
/* EON -- en25xxx */
--
2.43.0
^ permalink raw reply related
* [PATCH v2] board: samsung: exynos-mobile: prohibit memory overwrite access beyond DDR low region
From: Kaustabh Chakraborty @ 2026-06-14 11:34 UTC (permalink / raw)
To: u-boot; +Cc: Tom Rini, Minkyu Kang, Kaustabh Chakraborty, Henrik Grimler
With commit a3075db94d49 ("lmb: Reinstate access to memory above
ram_top"), the memory region beyond 0x100000000 is now accessible for
allocation. This breaks booting in devices like at least in some
variants of the Samsung Galaxy J6, where only CPU0 is able to appear
online.
Similar to some other boards, limit the memory to the DDR low region.
This also appears to re-implement the logic which was reverted. The
lmb_arch_add_memory() takes over the lmb initialization for the board.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
This one's a critical fix, would be nice to have it pulled in by v2026.07.
---
Changes in v2:
- enable CONFIG_LMB_ARCH_MEM_MAP from target
- Link to v1: https://patch.msgid.link/20260613-j6lte-lmb-v1-1-a32c7ee66c12@disroot.org
To: u-boot@lists.denx.de
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Kaustabh Chakraborty <kauschluss@disroot.org>
Cc: Henrik Grimler <henrik@grimler.se>
---
arch/arm/mach-exynos/Kconfig | 1 +
board/samsung/exynos-mobile/exynos-mobile.c | 25 +++++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index b084b7284aa..8251599332a 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -258,6 +258,7 @@ config TARGET_EXYNOS_MOBILE
select BOARD_EARLY_INIT_F
select CLK_EXYNOS
select LINUX_KERNEL_IMAGE_HEADER
+ select LMB_ARCH_MEM_MAP
select OF_CONTROL
config SYS_SOC
diff --git a/board/samsung/exynos-mobile/exynos-mobile.c b/board/samsung/exynos-mobile/exynos-mobile.c
index 6b2b1523663..f1f6cf683dd 100644
--- a/board/samsung/exynos-mobile/exynos-mobile.c
+++ b/board/samsung/exynos-mobile/exynos-mobile.c
@@ -353,6 +353,31 @@ int dram_init_banksize(void)
return 0;
}
+void lmb_arch_add_memory(void)
+{
+ u64 ddr_low_top = 1ULL << 32;
+ unsigned int i;
+
+ for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+ u64 start = gd->bd->bi_dram[i].start;
+ u64 size = gd->bd->bi_dram[i].size;
+
+ if (!size)
+ continue;
+
+ lmb_add(start, size);
+
+ /* Limit memory used by U-Boot to the DDR low region */
+ if (start >= ddr_low_top)
+ lmb_alloc_mem(LMB_MEM_ALLOC_ADDR, 0, &start, size,
+ LMB_NOOVERWRITE);
+ else if (start + size > ddr_low_top)
+ lmb_alloc_mem(LMB_MEM_ALLOC_ADDR, 0, &ddr_low_top,
+ start + size - ddr_low_top,
+ LMB_NOOVERWRITE);
+ }
+}
+
int board_init(void)
{
return 0;
---
base-commit: 7e47c37adf53f3010a6bf151df32df04a3c9ab91
change-id: 20260613-j6lte-lmb-a9f7a49c8ba1
Best regards,
--
Kaustabh Chakraborty <kauschluss@disroot.org>
^ permalink raw reply related
* [PATCH] pinctrl: single: parse gpio-range as a raw array (O(N^2) -> O(N))
From: Jordi Trepat Mur @ 2026-06-14 10:32 UTC (permalink / raw)
To: u-boot; +Cc: trini, sjg, vigneshr, nm, Jordi Trepat Mur
single_add_gpio_func() calls ofnode_parse_phandle_with_args() once per
gpio-range entry. With a flat device tree, every call re-iterates the
property from index 0 and, because cellname is set, performs an
fdt_node_offset_by_phandle() (a full-FDT scan) at every step. The total
cost is therefore quadratic in the number of entries and proportional
to the size of the device tree.
On a TI J722S board this makes the pinctrl probe take 723 ms
pre-relocation (caches off) for only 7 entries; with this change it
takes 22 ms (-97%). Any pinctrl-single user with a populated
pinctrl-single,gpio-range property pays this cost.
Read the property once with ofnode_get_property() and iterate over the
raw cells in memory instead. The phandle target node is never used by
this function (only the three argument cells are stored), so resolve
only the first entry with ofnode_parse_phandle_with_args() to validate
the cell layout. Empty entries (phandle == 0) are skipped, matching the
previous behaviour.
Tested on TI J722S (HS-FS): pinctrl probe 723 ms -> 22 ms, identical
gpio-range list produced.
Signed-off-by: Jordi Trepat Mur <yordy1902@gmail.com>
---
drivers/pinctrl/pinctrl-single.c | 62 ++++++++++++++++++++++++--------
1 file changed, 48 insertions(+), 14 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 42980e09..44297951 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -511,27 +511,61 @@ static int single_add_gpio_func(struct udevice *dev)
const char *cellname = "#pinctrl-single,gpio-range-cells";
struct single_gpiofunc_range *range;
struct ofnode_phandle_args gpiospec;
- int ret, i;
-
- for (i = 0; ; i++) {
- ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), propname,
- cellname, 0, i, &gpiospec);
- /* Do not treat it as error. Only treat it as end condition. */
- if (ret) {
- ret = 0;
- break;
+ const __be32 *list;
+ int size, total_cells, cells_per_entry, entries, ret, i;
+ int ret_total = 0;
+
+ /*
+ * Read the property once and iterate over the raw cell array in
+ * memory. Calling ofnode_parse_phandle_with_args() once per index
+ * re-walks the property from the start on every call and resolves
+ * the phandle (a full-FDT scan) at each step, which is O(N^2) in
+ * the number of entries and very slow pre-relocation with caches
+ * off. Resolve only the first entry's phandle to validate the
+ * cell layout; the target node itself is never used here.
+ */
+ list = ofnode_get_property(dev_ofnode(dev), propname, &size);
+ if (!list || size <= 0)
+ return 0;
+ total_cells = size / sizeof(*list);
+
+ /* Validate cell layout via the first entry (one phandle lookup total). */
+ ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), propname,
+ cellname, 0, 0, &gpiospec);
+ if (ret)
+ return 0;
+ if (gpiospec.args_count != 3) {
+ dev_err(dev, "expected 3 gpio-range args/entry, got %d\n",
+ gpiospec.args_count);
+ return -EINVAL;
+ }
+ cells_per_entry = 1 + gpiospec.args_count; /* phandle + args */
+ if (total_cells % cells_per_entry) {
+ dev_err(dev, "gpio-range size %d cells not multiple of %d\n",
+ total_cells, cells_per_entry);
+ return -EINVAL;
+ }
+ entries = total_cells / cells_per_entry;
+
+ for (i = 0; i < entries; i++) {
+ const __be32 *entry = list + i * cells_per_entry;
+ u32 phandle_i = be32_to_cpup(entry + 0);
+
+ if (phandle_i == 0) {
+ /* empty entry - match original: skip without creating range */
+ continue;
}
range = devm_kzalloc(dev, sizeof(*range), GFP_KERNEL);
if (!range) {
- ret = -ENOMEM;
+ ret_total = -ENOMEM;
break;
}
- range->offset = gpiospec.args[0];
- range->npins = gpiospec.args[1];
- range->gpiofunc = gpiospec.args[2];
+ range->offset = be32_to_cpup(entry + 1);
+ range->npins = be32_to_cpup(entry + 2);
+ range->gpiofunc = be32_to_cpup(entry + 3);
list_add_tail(&range->node, &priv->gpiofuncs);
}
- return ret;
+ return ret_total;
}
static int single_probe(struct udevice *dev)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] ARM: fdt: copy TF-A reserved memory into fdt passed to Linux
From: Paul Kocialkowski @ 2026-06-14 13:54 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: u-boot, Tom Rini, Jernej Skrabec, André Przywara, Cody Eksal
In-Reply-To: <20260613204202.2360922-1-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6149 bytes --]
Hi,
Le Sat 13 Jun 26, 22:41, Alexander Sverdlin a écrit :
> Currently some ARM-based platforms reserve TF-A memory in their own ways:
> - Mediatek gets BL31 region via SMC call in ft_system_setup()
> - K3 uses CONFIG_K3_ATF_LOAD_ADDR, effectively in ft_system_setup()
>
> And others like Allwinner simply forget to do it, which results in Linux
> overwriting TF-A and crashing.
To be fair we've been adding the reserved memory regions statically in
the Linux device-trees to mitigate the issue.
But another thing we do overwrite current is the cpu idle states, which
are added by fdt_add_cpu_idle_states in tf-a. These are only set when the
SCP firmware is available (which is checked at run-time) and they are
never propagated to the final device-tree. Including the definitions
statically would result in cpu idle calls done even without the SCP
firmware, which would probably fail (although maybe some states can
still be supported).
Also note that the usual way to deal with this is to not load any
device-tree when booting the kernel, which will implicitly let U-Boot
use its current device-tree for Linux (with the modifications brought by
tf-a).
But of course I agree that it is very desirable to "forward" the
device-tree modifications to the kernel device-tree so we are not stuck
with whatever device-tree U-Boot was built with.
> Unfortunately seems that the things are not much better on TF-A side and
> there is no universal way to get the reserved memory region across
> platforms. But there is at least a most common way in TF-A, namely
> reserving memory range in the FDT, in particular:
> - Allwinner ("tf-a@40000000" node)
> - ARM FPGA ("tf-a@80000000" node)
> - Xilinx ("tf-a" node)
RaspberryPi seems to be using "atf@0". Generally speaking the property
is a free-form argument to fdt_add_reserved_memory in tf-a and I don't
think we can have a common way to match them.
Introducing a Kconfig property for the prefix would be a satisfying
solution in my opinion.
> While this patch aims to improve the situation for Allwinner platforms,
> it's deliberately adding more generic code to pave the potential way of
> unification for other platforms.
>
> Note that fdtdec_add_reserved_memory() has a check for an already existing
> carveout with exactly matching boundaries and will not create a duplicate
> even if the name doesn't match. It would not however detect an already
> existing bigger carveout fully containing the one requested.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
> The patch has been developed to faciliate Allwinner A133 SoC support, where
> most of the work currently happens on TF-A [1] and Linux [2] sides, but
> I wanted to send this patch upfront to get the first feedback and because
> already supported H616 SoC would already benefit from the patch.
Thanks for looking at this!
Like I said, I guess the same needs to be done for the cpuidle psci
nodes.
> [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/49754
> [2] https://lore.kernel.org/all/20260605070923.3045073-1-alexander.sverdlin@gmail.com/
> [3] https://lore.kernel.org/all/b428d57ba5464f1226daf099877f4c25fa4fc191.camel@gmail.com/
>
> arch/arm/lib/bootm-fdt.c | 55 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm/lib/bootm-fdt.c b/arch/arm/lib/bootm-fdt.c
> index 2671f9a0ebf..19d917943c1 100644
> --- a/arch/arm/lib/bootm-fdt.c
> +++ b/arch/arm/lib/bootm-fdt.c
> @@ -14,7 +14,9 @@
> * Copyright (C) 2001 Erik Mouw (J.A.K.Mouw@its.tudelft.nl)
> */
>
> +#include <dm/ofnode.h>
> #include <fdt_support.h>
> +#include <linux/ioport.h>
> #ifdef CONFIG_ARMV7_NONSEC
> #include <asm/armv7.h>
> #endif
> @@ -24,6 +26,52 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +static int tfa_copy_reserved_memory(void *new_blob)
I would keep a fdt-related prefix to the name, so something like:
fdt_update_tfa_reserved_memory or
fdt_update_bl31_reserved_memory
> +{
> +#ifdef CONFIG_OF_CONTROL
> + ofnode node, subnode;
> +
> + /*
> + * TF-A for several platforms inserts its memory region as
> + * reserved-memory node
This will always be the case, I don't think we need a comment about it.
> + */
> + node = ofnode_path("/reserved-memory");
> + if (!ofnode_valid(node))
> + return 0;
> +
> + ofnode_for_each_subnode(subnode, node) {
> + struct fdt_memory carveout;
> + struct resource res;
> + const char *name;
> + int ret;
> +
> + name = ofnode_get_name(subnode);
> + if (!name)
> + return -FDT_ERR_BADSTRUCTURE;
> +
> + /* only handle TF-A reservations */
Please capitalize the first letter and end with a dot (same for all
comments).
> + if (strncmp(name, "tf-a", 4))
> + continue;
> +
> + /* check if this subnode has a reg property */
> + ret = ofnode_read_resource(subnode, 0, &res);
> + if (ret)
> + continue;
> +
> + carveout.start = res.start,
> + carveout.end = res.end,
> +
> + ret = fdtdec_add_reserved_memory(new_blob, "tf-a", &carveout,
> + NULL, 0, NULL,
> + FDTDEC_RESERVED_MEMORY_NO_MAP);
> + if (ret < 0)
> + return ret;
Looks good otherwise.
> + }
> +#endif
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_FMAN_ENET
> __weak int fdt_update_ethernet_dt(void *blob)
> {
> @@ -56,6 +104,13 @@ int arch_fixup_fdt(void *blob)
> return ret;
> #endif
>
> + ret = tfa_copy_reserved_memory(blob);
> + if (ret) {
> + printf("ERROR: transfer of TF-A nodes to new fdt failed: %s\n",
> + fdt_strerror(ret));
This is very unlikely, not sure it is worth an error message.
Other calls in the same function are silent.
> + return ret;
> + }
> +
> #ifdef CONFIG_ARMV8_SPIN_TABLE
> ret = spin_table_update_dt(blob);
> if (ret)
> --
> 2.54.0
>
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 2/2] bootdev: scan boot devices at each priority level
From: Simon Glass @ 2026-06-14 12:56 UTC (permalink / raw)
To: dmukhin; +Cc: u-boot, sjg, trini
In-Reply-To: <20260611014843.3735672-3-dmukhin@ford.com>
Hi Denis,
On 2026-06-11T01:48:41, None <dmukhin@ford.com> wrote:
> bootdev: scan boot devices at each priority level
>
> Currently, default 'bootflow scan -lb' will stop booting the board
> if any of high-level priority bootdevs cannot be hunted even if there
I think you mean 'higher-priority bootdevs fail to be hunted'.
> are bootdevs of lower priority.
>
> For example, if board has both NVMe (priority 4) and USB MSD devices
> (priority 5), and if NVMe bootdev hunt fails (in an event of bad NVMe
> firmware update), USB (may be recovery bootdev) is never hunted
> automatically, leaving the board in U-Boot prompt (user intervention
> is needed, e.g. something like 'bootflow scan usb' to hunt USB).
>
> Fix bootdev_next_prio() to scan bootdevs at the lower priority level
> by not exiting the scan loop early.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> boot/bootdev-uclass.c | 2 --
> 1 file changed, 2 deletions(-)
> diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
> @@ -669,8 +669,6 @@ int bootdev_next_prio(struct bootflow_iter *iter, struct udevice **devp)
> BOOTFLOWIF_SHOW);
> log_debug("- bootdev_hunt_prio() ret %d\n",
> ret);
> - if (ret)
> - return log_msg_ret('hun', ret);
> }
> } else {
> ret = device_probe(dev);
The fix looks right - we can probably rely on the failing subsystem to
print a suitable message.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v1 1/2] bootdev: fix typos
From: Simon Glass @ 2026-06-14 12:54 UTC (permalink / raw)
To: dmukhin; +Cc: u-boot, sjg, trini
In-Reply-To: <20260611014843.3735672-2-dmukhin@ford.com>
On 2026-06-11T01:48:41, None <dmukhin@ford.com> wrote:
> bootdev: fix typos
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>
> include/bootdev.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply
* Re: [PATCH v3 0/3] Improve U-Boot's TPM handling in the non-EFI case
From: Simon Glass @ 2026-06-14 12:46 UTC (permalink / raw)
To: Ludwig Nussel
Cc: u-boot, Andrew Goodbody, Heiko Schocher, Heinrich Schuchardt,
Ilias Apalodimas, João Paulo Gonçalves, Marek Vasut,
Quentin Schulz, Sughosh Ganu, Tom Rini
In-Reply-To: <20260611161831.122299-1-ludwig.nussel@siemens.com>
Hi Ludwig,
On Thu, 11 Jun 2026 at 10:18, Ludwig Nussel <ludwig.nussel@siemens.com> wrote:
>
> U-Boot might be the first component to start the event log, eg when
> used in qemu. So allocate and attach the TPM event log to the TPM
> device if not initialized yet. The address is copied into the device
> tree for the kernel so the event log is accessible from Linux
> userspace too.
>
> Changes in v3:
> - fix test failure
> - sync description with cover letter
>
> Changes in v2:
> - fix return value handling
> - imply DEVRES in config TPM
> - use fdt_getprop for reading property
> - don't wrap #include in #if
> - fix memory leak in error case of tcg2_log_prepare_buffer
> - handle NULL elog parameter in tcg2_measurement_term
> - use CONFIG_TPM2_EVENT_LOG_SIZE
> - pass log_size instead of position in dt
>
> Ludwig Nussel (3):
> test: include mapmem.h explicitly
> tpm: print all PCRs from pcr_read
> tpm: allocate tpm event log if missing
>
> boot/bootm.c | 18 ++---
> boot/image-fdt.c | 69 ++++++++++++++++++++
> cmd/tpm-v2.c | 69 ++++++++++++++------
> include/tpm-common.h | 2 +
> include/tpm_tcg2.h | 9 +--
> lib/Kconfig | 1 +
> lib/tpm_tcg2.c | 130 +++++++++++++++++++++++++++++--------
> test/boot/measurement.c | 1 +
> test/py/tests/test_tpm2.py | 9 +--
> 9 files changed, 242 insertions(+), 66 deletions(-)
>
> --
> 2.43.0
>
> base-commit: 3cdce049f90d77c3f9221f1eb73922384c8972c3
> branch: us-tpm3
Somehow this email did not seem to reach patchwork, so it missed the
cover-letter title.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH] cros_ec: Convert dm_cros_ec_get_ops into an inline function and constify dm_cros_ec_ops
From: Simon Glass @ 2026-06-14 12:43 UTC (permalink / raw)
To: Marek Vasut; +Cc: u-boot, Tom Rini
In-Reply-To: <20260612015932.283341-1-marek.vasut+renesas@mailbox.org>
On Thu, 11 Jun 2026 at 19:59, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
>
> Convert dm_cros_ec_get_ops into an inline function to improve compiler
> code coverage, and constify struct dm_cros_ec_ops in a few places.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: u-boot@lists.denx.de
> ---
> drivers/misc/cros_ec.c | 9 ++++-----
> include/cros_ec.h | 7 +++++--
> 2 files changed, 9 insertions(+), 7 deletions(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply
* Re: [PATCH 00/13] boot: Make fit_image_load() easier to maintain
From: Simon Glass @ 2026-06-14 12:41 UTC (permalink / raw)
To: Tom Rini
Cc: u-boot, James Hilliard, Jonas Karlman, Marek Vasut,
Mayuresh Chitale, Neil Armstrong, Quentin Schulz, Shiji Yang,
Wolfgang Wallner
In-Reply-To: <20260408162616.GI41863@bill-the-cat>
Hi Tom,
On Wed, 8 Apr 2026 at 10:26, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Mar 25, 2026 at 10:54:09AM -0600, Simon Glass wrote:
>
> > Before fit_image_load() was created, the code to load kernels, ramdisks
> > and devicetrees from a FIT was spread around many functions. By
> > combining most of the code in one place, it became possible to add more
> > features in a consistent way. The 'loadables' feature was much easier to
> > plumb in, for example.
> >
> > While fit_image_load() was a substantial advance, it has never been a
> > svelte function and the passing years have not been entirely kind. With
> > a few new features on the horizon, this is a good time to improve the
> > implementation.
> >
> > This series splits much of the code from fit_image_load() into a number
> > of smaller functions. Most of the changes are fairly mechanical, with
> > just a few renames and tweaks here and there.
> >
> > This should make the function much easier to maintain. It may also
> > encourage someone to take a look at its callers, which could also use
> > some attention.
> >
> > Code-size impact: about +8 bytes on aarch64 and +24-40 bytes on arm, due
> > to the compiler's register allocation across the new helper functions.
> >
> >
> > Simon Glass (13):
> > boot: Split out the first part of fit_image_load()
> > boot: Move call to fit_image_select() and rename it
> > boot: Tidy up setting of the OS arch on host builds
> > boot: Move type and OS checking into a new function
> > boot: Move handling of the load_op into a separate function
> > boot: Move obtaining data from a FIT image into a function
> > boot: Check the image is allowed before setting os.arch
> > boot: Move the architecture check into check_allowed()
> > boot: Move image-decompression into a separate function
> > boot: Move decomp_image() into handle_load_op()
> > boot: Move setting the OS arch into check_allowed()
> > boot: Drop unnecessary data variable
> > boot: Tidy local variables in fit_image_load()
>
> I've reviewed through 5, and I assume 6-13 have similar issues as the
> rest. Please think about that before submitting a v2, thanks.
It is hard to be to figure out whether you are saying that this is
hard to review (which I agree). If so, I could perhaps split it up
into more patches.
Or is it that you don't like the end result?
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v2 00/12] test: Add support for passing arguments to C unit tests
From: Simon Glass @ 2026-06-14 12:38 UTC (permalink / raw)
To: Tom Rini
Cc: u-boot, Heinrich Schuchardt, Andrew Goodbody, Ilias Apalodimas,
Marek Vasut
In-Reply-To: <CAFLszTg5kA7fee0t_w93Xt9cR89V-8VWQ-_2eKLz1M4rjaqA2Q@mail.gmail.com>
Hi Tom,
On Thu, 16 Apr 2026 at 11:42, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Mon, 13 Apr 2026 at 14:13, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Apr 12, 2026 at 05:19:37AM -0600, Simon Glass wrote:
> > > Some tests have two parts: a Python test which handles setup, such as
> > > creating filesystem images or configuring the environment, and a C
> > > test which does the bulk of the work including assertions. At present
> > > there is no way to pass information between these two parts, so
> > > things like paths and device names must be hard-coded in the C test.
> > >
> > > This tends to make people write tests in Python, but this is not ideal
> > > for several reasons:
> >
> > You still need to work on explaining your changes in a positive manner.
> >
> > > - Python lacks access to things like return codes and has to scan the
> > > console output to figure out what happened
> >
> > Pro: Python exercises things the way users exercise them and so exposes
> > deficiencies in our user interface as well, when applicable.
> >
> > > - Python lacks access to internal state, so it cannot directly check
> > > the result of an operation
> >
> > It's unclear when that is, or is not a problem and when tests that do
> > check intermediate state are providing value.
> >
> > > - Python is ~100x slower due to console interaction, etc.
> >
> > Again, maybe you should go back to your suggestion of several years ago
> > to see about addressing that, as the tests themselves are not slow, it's
> > the pipe? Our brave new AI powered world runs on Python handing stuff
> > off and getting it back super quickly.
> >
> > > - C tests can be stepped through in gdb, which is much harder with
> > > Python driving the console
> > > - C tests can exercise internal APIs directly (e.g. fs_read(),
> > > fs_size()) rather than going through the command layer, so they
> > > test more precisely what they intend to
> >
> > All things that may or may not be problems for other people, or are
> > intentional choices as they again test the system the way it's used.
> > Using gdb attached to u-boot in the other terminal where you're running
> > breaking things sounds like a reasonable debug path to me. And having
> > unit tests calling in to functions is why today we have a lot of things
> > not marked as "static" and so not being optimized as well as they could
> > by the compiler, which is its own set of trade-offs and not an automatic
> > good thing and design win.
> >
> > [snip]
> > > 16 files changed, 1437 insertions(+), 279 deletions(-)
> >
> > All of which is to say, you need to explain yourself in a positive, not
> > negative or oppositional way. Otherwise this reads like "I don't like
> > what we do now, here's a bunch of change to what I like instead".
>
> Just to check, is this a discussion and you would like me to reply
> with more details about the benefits of C over Python in particular
> circumstances? Or are you wanting the cover-letter rewritten. Or is
> this just a NAK?
>
> I did some work on using a socket to talk to sandbox (it is faster and
> also avoids some of the confusion as to what state sandbox is in
> without having to rely on looking at console output). But I never
> quite finished it. The other option (which we briefly discussed years
> ago) would be to build U-Boot as a Python module. I haven't tried that
> at all, but it's an idea.
>
> I am well aware of the tradeoffs between Python and C, so I am not
> advocating one over the other in all cases. I use gdb a lot with the
> pytests - e.g. hunting down memory leaks recent. Really I just want
> them to coexist better - i.e. improving the sandbox pattern where
> Python sets something up and then C runs it.
>
I see that this series is marked 'deferred'. Does that mean rejected,
or is there something you are waiting on. I believe this (or something
like it) is an important new feature for testing.
Regards,
SImon
^ permalink raw reply
* Re: [PATCH v5 0/9] ARM: RPi5: Enable PCIe
From: Peter Robinson @ 2026-06-14 12:33 UTC (permalink / raw)
To: Simon Glass
Cc: Torsten Duwe, Matthias Brugger, Tom Rini, Jan Čermák,
Andrea della Porta, Ivan T. Ivanov, Stanimir Varbanov,
Oleksii Moisieiev, Volodymyr Babchuk, Marek Vasut, Paul Barker,
Patrice Chotard, Christian Marangi, Patrick Delaunay, Huan Zhou,
Gabriel Fernandez, Kever Yang, Jonas Karlman, Joseph Chen,
Elaine Zhang, Pedro Falcato, u-boot
In-Reply-To: <CAFLszTj4F+Wpv2QOtKPyK6sApK5YpBWtCdpi0vJa6FNgUgYWvw@mail.gmail.com>
On Sun, 14 Jun 2026 at 12:50, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Torsten,
>
> On Mon, 1 Jun 2026 at 04:36, Torsten Duwe <duwe@lst.de> wrote:
> >
> > Basic PCIe support for the RPi5. This is the prerequisite for PCIe
> > slot adapters / HATs and NVMe storage. Those might require their own
> > supporting drivers or changes. It is also the prerequisite for all
> > peripherials residing on the RP1 I/O controller, like USB, network,
> > GPIOs and all serial ports beyond the debug connector.
> >
> > Changes from v4:
> > - fixed remaining style issues, no functional changes
> > - patches 3&6 Reviewed-by Neil Armstrong
> >
> > Changes from v3:
> > - differentiate only between bcm2711 and -12. No possible future
> > extensions for other chips. In particular, keep EXT_CFG_INDEX and
> > EXT_CFG_DATA offsets fixed, no functions in the cfg struct that
> > are the same for both, like bridge_sw_init_set and rc_mode.
> > - pass error codes through the newly introduced reset call chain
> > - some patches Reviewed-by Neil Armstrong
> >
> > Changes from v2:
> > - fix wrong subject prefixes
> > - make reset drivers only found on the RPi5 depend on ARCH_BCM283X
> > - some patches Reviewed-by Peter Robinson
> >
> > Changes from v1:
> > - fixed inbound window rewrite, which broke RPi4
> > - series Tested-by Pedro Falcato
> >
> > Andrea della Porta (1):
> > pci: brcmstb: Fix PCIe bus numbers
> >
> > Torsten Duwe (8):
> > ARM: bcm283x: Add bcm2712 PCIe memory window
> > pci: brcmstb: Support different variants using a cfg struct
> > reset: Add RPi5 brcmstb reset facilities
> > reset: Add RPi5 rescal reset facilities
> > pci: brcmstb: Get and use bridge and rescal reset properties
> > pci: brcmstb: Fix iBAR size calculation
> > pci: brcmstb: rework iBAR handling
> > pci: brcmstb: Adapt to AXI bridge
> >
> > .../mach-bcm283x/include/mach/acpi/bcm2711.h | 6 +
> > arch/arm/mach-bcm283x/init.c | 10 +-
> > configs/rpi_arm64_defconfig | 2 +
> > drivers/pci/pcie_brcmstb.c | 389 ++++++++++++++++--
> > drivers/reset/Kconfig | 16 +
> > drivers/reset/Makefile | 2 +
> > drivers/reset/reset-brcmstb-rescal.c | 103 +++++
> > drivers/reset/reset-brcmstb.c | 97 +++++
> > 8 files changed, 589 insertions(+), 36 deletions(-)
> > create mode 100644 drivers/reset/reset-brcmstb-rescal.c
> > create mode 100644 drivers/reset/reset-brcmstb.c
> >
> > --
> > 2.54.0
> >
>
> I see that this series has been applied to -next although I didn't see
> any 'applied' email here.
That was probably me not replying and just marking it as applied in
patchwork. It's in master I believe.
> Do you know how I could try this out, please? I have a GeeekPi N07
> PCIe M.2 M-Key NVMe. What sort of changes might I need to make?
You need another series [1], which currently needs a rebase, and it
should mostly "just work".
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=503410
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox