u-boot.git/common, branch next Unnamed repository; edit this file 'description' to name the repository. Merge tag 'v2026.07-rc3' into next 2026-05-25T17:35:35+00:00 Tom Rini trini@konsulko.com 2026-05-25T17:35:35+00:00 7bb1917b15b77a7d8c27045df33b6bbc214c2f67 Prepare v2026.07-rc3 
Prepare v2026.07-rc3
imx: ahab: Use authenticated header for images loading 2026-05-15T20:31:39+00:00 Ye Li ye.li@nxp.com 2026-04-28T10:09:58+00:00 84a17fea21f8877a668f535145a105db4ccf791e When loading container image, the container header is loaded into heap memory. If ahab is enabled, the header is be copied to another fixed RAM for authentication in ahab_auth_cntr_hdr. The better method is using container header memory being authenticated for following image loading. So update ahab_auth_cntr_hdr to return the address of container header being authenticated. Caller uses this header for following parsing and image loading. Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> 
When loading container image, the container header is loaded into
heap memory. If ahab is enabled, the header is be copied to another
fixed RAM for authentication in ahab_auth_cntr_hdr. The better method
is using container header memory being authenticated for following
image loading.
So update ahab_auth_cntr_hdr to return the address of container header
being authenticated. Caller uses this header for following parsing
and image loading.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
powerpc: fix call to cpu_init_r 2026-05-15T11:28:29+00:00 Michael Walle mwalle@kernel.org 2026-05-06T12:34:10+00:00 674f35a88478cf6513285bbfbe8b820af43b828f Commit 6c171f7a184c ("common: board: make initcalls static") broke the call to cpu_init_r. That is because PPC is already defined to 1, see: powerpc-linux-gnu-gcc -dM -E - < /dev/null This will conflict with the CONFIG_IS_ENABLED(PPC). Change it to IS_ENABLED(CONFIG_PPC). Fixes: 6c171f7a184c ("common: board: make initcalls static") Signed-off-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com> 
Commit 6c171f7a184c ("common: board: make initcalls static") broke the
call to cpu_init_r. That is because PPC is already defined to 1, see:

  powerpc-linux-gnu-gcc -dM -E - < /dev/null

This will conflict with the CONFIG_IS_ENABLED(PPC). Change it to
IS_ENABLED(CONFIG_PPC).

Fixes: 6c171f7a184c ("common: board: make initcalls static")
Signed-off-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Merge patch series "add memdup_nul(), use it and memdup() in a few places" 2026-05-12T21:41:52+00:00 Tom Rini trini@konsulko.com 2026-05-12T21:41:52+00:00 e3e651c480c46b332f16a7555b97c6c6fd640a40 Rasmus Villemoes <ravi@prevas.dk> says: There are quite a few places where we allocate X+1 bytes, initialize the first X bytes via memcpy() and then set the last byte to 0. The kernel has a helper for that, kmemdup_nul(). Introduce a similar one, and start making use of it in a few places. Also the existing memdup() helper can be put to more use. There are lots more places one could modify. But for code shared with host tools, one would need to do some refactoring, putting memdup() and memdup_nul() in their own str-util.c TU which could then also be included in the tools build. Link: https://lore.kernel.org/r/20260421075439.16696-1-ravi@prevas.dk 
Rasmus Villemoes <ravi@prevas.dk> says:

There are quite a few places where we allocate X+1 bytes, initialize
the first X bytes via memcpy() and then set the last byte to 0.

The kernel has a helper for that, kmemdup_nul(). Introduce a similar
one, and start making use of it in a few places. Also the existing
memdup() helper can be put to more use.

There are lots more places one could modify. But for code shared with
host tools, one would need to do some refactoring, putting memdup()
and memdup_nul() in their own str-util.c TU which could then also be
included in the tools build.

Link: https://lore.kernel.org/r/20260421075439.16696-1-ravi@prevas.dk
common/cli.c: use memdup_nul() in run_command_list() 2026-05-12T21:38:00+00:00 Rasmus Villemoes ravi@prevas.dk 2026-04-21T07:54:37+00:00 11168813bf9c088e1fce8a96f4b493ee815c966b Use memdup_nul() instead of open-coding it. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> 
Use memdup_nul() instead of open-coding it.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
stdio: drop stdio_clone 2026-05-12T21:38:00+00:00 Rasmus Villemoes ravi@prevas.dk 2026-04-21T07:54:32+00:00 719cacb92e039308e23cbd6b653275e939a5aca5 The helper stdio_clone only has a single caller, so it certainly doesn't need to be public. But in fact, it is merely an open-coded memdup() - which for some reason uses calloc() even if the whole allocation is obviously immediately overwritten. Drop it and just use memdup() directly. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> 
The helper stdio_clone only has a single caller, so it certainly
doesn't need to be public. But in fact, it is merely an open-coded
memdup() - which for some reason uses calloc() even if the whole
allocation is obviously immediately overwritten.

Drop it and just use memdup() directly.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
common: memsize: fix occasionally failing alias probing 2026-05-04T18:58:47+00:00 Emanuele Ghidoli emanuele.ghidoli@toradex.com 2026-04-29T10:03:56+00:00 2c733e6c85576b86358885c0a9462a0337797653 probe_ram_size_by_alias() detects whether a probe address still aliases a lower address by writing through one address and reading through the other. On i.MX95 this occasionally reported a false non-alias when the alias read happened immediately after the write. A memory barrier alone, mb(), was tested but did not make the failure go away. This suggests that ordering the CPU accesses is not sufficient for this probe, likely because the issue is in the path to the memory controller rather than in the core itself. Read the written address back before checking the alias address. This appears to force the write to become observable at the probe address before using the alias read to decide whether the tested address range exists. If the readback does not match the written pattern, restore the saved value and continue with the next check. This keeps the probe robust for addresses that do not reliably retain the test pattern. Fixes: 0977448b45e2 ("common: memsize: add RAM size probe based on alias detection") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
probe_ram_size_by_alias() detects whether a probe address still aliases
a lower address by writing through one address and reading through the
other.

On i.MX95 this occasionally reported a false non-alias when the alias
read happened immediately after the write.

A memory barrier alone, mb(), was tested but did not make the failure go
away. This suggests that ordering the CPU accesses is not sufficient for
this probe, likely because the issue is in the path to the memory
controller rather than in the core itself.

Read the written address back before checking the alias address. This
appears to force the write to become observable at the probe address
before using the alias read to decide whether the tested address range
exists.

If the readback does not match the written pattern, restore the saved
value and continue with the next check. This keeps the probe robust for
addresses that do not reliably retain the test pattern.

Fixes: 0977448b45e2 ("common: memsize: add RAM size probe based on alias detection")
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
bloblist: fix pointer comparison in bloblist_apply_blobs() 2026-05-04T18:58:44+00:00 Michal Simek michal.simek@amd.com 2026-04-29T06:29:53+00:00 0fd32094c04ff736977d88dea02c299a75965c4f The rec_from_blob() function returns a pointer, but the code was comparing it using "rec <= 0" which is incorrect for pointer types. Pointers should be compared using "== NULL" or "!= NULL". Addresses-Coverity-ID: CID 645841: Incorrect expression (BAD_COMPARE) Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Raymond Mao <raymondmaoca@gmail.com> 
The rec_from_blob() function returns a pointer, but the code was
comparing it using "rec <= 0" which is incorrect for pointer types.
Pointers should be compared using "== NULL" or "!= NULL".

Addresses-Coverity-ID: CID 645841: Incorrect expression (BAD_COMPARE)
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Merge patch series "net: migrate NO_NET out of the networking stack choice" 2026-04-27T17:28:25+00:00 Tom Rini trini@konsulko.com 2026-04-27T17:28:25+00:00 96c8b9c4ceb7a144e52b5bbf56ea58512f978bb7 Quentin Schulz <foss+uboot@0leil.net> says: This migrates the net options away from the main Kconfig to net/Kconfig, rename the current NET option to NET_LEGACY to really highlight what it is and hopefully encourage more people to use lwIP, add a new NET menuconfig (but keep NO_NET as an alias to NET=n for now) which then allows us to replace all the "if legacy_stack || lwip_stack" checks with "if net_support" which is easier to read and maintain. The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed for now even when no network is configured? Likely due to include/net-common.h with PKTBUFSRX? No change in behavior is intended. Only change in defconfig including other defconfigs where NO_NET=y or NET is not set, in which case NO_NET is not set or NET=y should be set in the top defconfig. Similar change required for config fragments. See commit log in patch adding NET menuconfig for details. This was tested based on 70fd0c3bb7c2 ("x86: there is no CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up similarly as in "build all platforms in a single job" GitLab CI job. #!/usr/bin/env bash set -o pipefail set -eux ARGS="-BvelPEWM --reproducible-builds --step 0" ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $* ./tools/buildman/buildman -o ${O} $ARGS -Ssd $* O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt I can't really decipher the log.txt, but there's no line starting with + which would be an error according to tools/buildman/builder.py help text. Additionally, because I started the script with set -e set and because buildman has an exit code != 0 when it fails to build a board, and I have the summary printed (which is the second buildman call), I believe it means all builds passed. The summary is the following: aarch64: (for 537/537 boards) all +0.0 rodata +0.0 uniphier_v8 : all +1 rodata +1 u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1) function old new delta data_gz 10640 10641 +1 arm: (for 733/733 boards) all -0.0 rodata -0.0 uniphier_v7 : all -1 rodata -1 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1) function old new delta data_gz 11919 11918 -1 opos6uldev : all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 18778 18775 -3 uniphier_ld4_sld8: all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 11276 11273 -3 stemmy : all -20 rodata -20 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20) function old new delta data_gz 15783 15763 -20 As far as I could tell this data_gz is an automatically generated array when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored in binary form. Because I'm changing the name of symbols, replacing a menu with a menuconfig, additional text makes it to .config and the "# Networking" section in .config disappears. Here is the diff for the 5 defconfigs listed above, generated with: for f in build/*-m; do diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config done (-m is the build directory for master, and without the suffix, it's the top commit of this series) """ --- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200 +++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200 @@ -970,4 +969,0 @@ - -# -# Networking -# @@ -975,0 +972 @@ +CONFIG_NET_LEGACY=y --- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200 +++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200 @@ -733,4 +732,0 @@ - -# -# Networking -# @@ -738,2 +733,0 @@ -# CONFIG_NET is not set -# CONFIG_NET_LWIP is not set --- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200 +++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200 @@ -997,4 +996,0 @@ - -# -# Networking -# @@ -1002,0 +999 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200 +++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200 @@ -1004,4 +1003,0 @@ - -# -# Networking -# @@ -1009,0 +1006 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200 +++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200 @@ -875,4 +874,0 @@ - -# -# Networking -# @@ -880,0 +877 @@ +CONFIG_NET_LEGACY=y """ This is fine: - Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't be in .config anymore. - opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but CONFIG_NET_LEGACY also needs to be defined now to reflect the stack choice (even if default), - stemmy has CONFIG_NO_NET set, which means CONFIG_NET and CONFIG_NET_LWIP are not reachable anymore hence why they don't need to be part of .config, GitLab CI was run on this series (well, not exactly, but it's only changes to the git logs that were made): https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849 It passes. Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de 
Quentin Schulz <foss+uboot@0leil.net> says:

This migrates the net options away from the main Kconfig to net/Kconfig,
rename the current NET option to NET_LEGACY to really highlight what it
is and hopefully encourage more people to use lwIP, add a new NET
menuconfig (but keep NO_NET as an alias to NET=n for now) which then
allows us to replace all the "if legacy_stack || lwip_stack" checks with
"if net_support" which is easier to read and maintain.

The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed
for now even when no network is configured? Likely due to
include/net-common.h with PKTBUFSRX?

No change in behavior is intended. Only change in defconfig including
other defconfigs where NO_NET=y or NET is not set, in which case NO_NET
is not set or NET=y should be set in the top defconfig. Similar change
required for config fragments. See commit log in patch adding NET
menuconfig for details.

This was tested based on 70fd0c3bb7c2 ("x86: there is no
CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container
trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up
similarly as in "build all platforms in a single job" GitLab CI job.

 #!/usr/bin/env bash
 set -o pipefail
 set -eux

 ARGS="-BvelPEWM --reproducible-builds --step 0"
 ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $*
 ./tools/buildman/buildman -o ${O} $ARGS -Ssd $*

O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt

I can't really decipher the log.txt, but there's no line starting with
+ which would be an error according to tools/buildman/builder.py help
text. Additionally, because I started the script with set -e set and
because buildman has an exit code != 0 when it fails to build a board,
and I have the summary printed (which is the second buildman call), I
believe it means all builds passed.

The summary is the following:
   aarch64: (for 537/537 boards) all +0.0 rodata +0.0
            uniphier_v8    : all +1 rodata +1
               u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1)
                 function                                   old     new   delta
                 data_gz                                  10640   10641      +1
       arm: (for 733/733 boards) all -0.0 rodata -0.0
            uniphier_v7    : all -1 rodata -1
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1)
                 function                                   old     new   delta
                 data_gz                                  11919   11918      -1
            opos6uldev     : all -3 rodata -3
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
                 function                                   old     new   delta
                 data_gz                                  18778   18775      -3
            uniphier_ld4_sld8: all -3 rodata -3
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
                 function                                   old     new   delta
                 data_gz                                  11276   11273      -3
            stemmy         : all -20 rodata -20
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20)
                 function                                   old     new   delta
                 data_gz                                  15783   15763     -20

As far as I could tell this data_gz is an automatically generated array
when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored
in binary form. Because I'm changing the name of symbols, replacing a
menu with a menuconfig, additional text makes it to .config and the
"# Networking" section in .config disappears.

Here is the diff for the 5 defconfigs listed above, generated with:

for f in build/*-m; do
	diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config
done

(-m is the build directory for master, and without the suffix, it's the
top commit of this series)

"""
 --- build/opos6uldev-m/.config	2026-04-20 10:53:49.804528526 +0200
 +++ build/opos6uldev/.config	2026-04-20 11:03:37.430242767 +0200
 @@ -970,4 +969,0 @@
 -
 -#
 -# Networking
 -#
 @@ -975,0 +972 @@
 +CONFIG_NET_LEGACY=y
 --- build/stemmy-m/.config	2026-04-20 11:01:33.653698123 +0200
 +++ build/stemmy/.config	2026-04-20 11:04:53.452577311 +0200
 @@ -733,4 +732,0 @@
 -
 -#
 -# Networking
 -#
 @@ -738,2 +733,0 @@
 -# CONFIG_NET is not set
 -# CONFIG_NET_LWIP is not set
 --- build/uniphier_ld4_sld8-m/.config	2026-04-20 11:00:41.605469071 +0200
 +++ build/uniphier_ld4_sld8/.config	2026-04-20 11:04:22.226439899 +0200
 @@ -997,4 +996,0 @@
 -
 -#
 -# Networking
 -#
 @@ -1002,0 +999 @@
 +CONFIG_NET_LEGACY=y
 --- build/uniphier_v7-m/.config	2026-04-20 10:53:04.019307319 +0200
 +++ build/uniphier_v7/.config	2026-04-20 11:03:01.688085486 +0200
 @@ -1004,4 +1003,0 @@
 -
 -#
 -# Networking
 -#
 @@ -1009,0 +1006 @@
 +CONFIG_NET_LEGACY=y
 --- build/uniphier_v8-m/.config	2026-04-20 10:43:05.614441175 +0200
 +++ build/uniphier_v8/.config	2026-04-20 10:41:03.214852130 +0200
 @@ -875,4 +874,0 @@
 -
 -#
 -# Networking
 -#
 @@ -880,0 +877 @@
 +CONFIG_NET_LEGACY=y
"""

This is fine:
- Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't
  be in .config anymore.
- opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have
  (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but
  CONFIG_NET_LEGACY also needs to be defined now to reflect the stack
  choice (even if default),
- stemmy has CONFIG_NO_NET set, which means CONFIG_NET and
  CONFIG_NET_LWIP are not reachable anymore hence why they don't need to
  be part of .config,

GitLab CI was run on this series (well, not exactly, but it's only
changes to the git logs that were made):
https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849

It passes.

Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de
simplify NET_LEGACY || NET_LWIP condition with NET condition 2026-04-27T17:26:40+00:00 Quentin Schulz quentin.schulz@cherry.de 2026-04-20T11:36:10+00:00 95d66d2eb02a4677c63d04c84ca21750a04c49f1 Since the move to make NET a menuconfig and NO_NET a synonym of NET=n, when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so let's simplify the various checks across the codebase. SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so the proper symbol is still defined in SPL whenever needed. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
Since the move to make NET a menuconfig and NO_NET a synonym of NET=n,
when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so
let's simplify the various checks across the codebase.

SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so
the proper symbol is still defined in SPL whenever needed.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>