u-boot.git/boot, branch next Unnamed repository; edit this file 'description' to name the repository. Merge patch series "boot/fit: use fdt_for_each_subnode() in image-fit.c" 2026-05-25T19:44:28+00:00 Tom Rini trini@konsulko.com 2026-05-25T19:44:28+00:00 77efd55f89e406d49a8697fd5475b6ab2ba6497c Aristo Chen <aristo.chen@canonical.com> says: This series ends with replacing the verbose fdt_next_node() + ndepth idiom in boot/image-fit.c with fdt_for_each_subnode(), bringing the file in line with boot/image-fit-sig.c. Six of the seven sites in image-fit.c predate the macro by 2-6 years; the seventh was copy-pasted from a neighbour in 2015 just after the macro landed. The old idiom is legacy, not a deliberate technical choice. Converting straight to the macro turned out to need a prerequisite, which is patch 1. fit_print_contents() reads the default-config property using the loop variable left over after iterating /images children. With /images defined first in the source (the conventional layout) libfdt's walker happens to leave that variable pointing at /configurations and the read works. With /configurations defined first the read returns NULL and the "Default Configuration" line is silently omitted. fdt_for_each_subnode()'s post-loop value is unconditionally a negative error code, so a naive conversion would have made the missing line the unconditional behaviour. Patch 1 reads the property from confs_noffset directly and removes the layout dependency. Patch 2 adds a regression test for the configs-before-images layout, which had no coverage. Patch 3 is the mechanical conversion at all seven sites, equivalence-preserving as described in the per-patch message. Link: https://lore.kernel.org/r/20260508213217.3807786-1-aristo.chen@canonical.com 
Aristo Chen <aristo.chen@canonical.com> says:

This series ends with replacing the verbose fdt_next_node() + ndepth
idiom in boot/image-fit.c with fdt_for_each_subnode(), bringing the
file in line with boot/image-fit-sig.c. Six of the seven sites in
image-fit.c predate the macro by 2-6 years; the seventh was
copy-pasted from a neighbour in 2015 just after the macro landed.
The old idiom is legacy, not a deliberate technical choice.

Converting straight to the macro turned out to need a prerequisite,
which is patch 1. fit_print_contents() reads the default-config
property using the loop variable left over after iterating /images
children. With /images defined first in the source (the conventional
layout) libfdt's walker happens to leave that variable pointing at
/configurations and the read works. With /configurations defined
first the read returns NULL and the "Default Configuration" line is
silently omitted. fdt_for_each_subnode()'s post-loop value is
unconditionally a negative error code, so a naive conversion would
have made the missing line the unconditional behaviour. Patch 1
reads the property from confs_noffset directly and removes the
layout dependency.

Patch 2 adds a regression test for the configs-before-images
layout, which had no coverage.

Patch 3 is the mechanical conversion at all seven sites,
equivalence-preserving as described in the per-patch message.

Link: https://lore.kernel.org/r/20260508213217.3807786-1-aristo.chen@canonical.com
boot/fit: use fdt_for_each_subnode() in image-fit.c 2026-05-25T19:44:11+00:00 Aristo Chen aristo.chen@canonical.com 2026-05-08T21:32:01+00:00 2c9b117aa4811d583f2832b37a69f25c761ffc86 Replace the verbose fdt_next_node() + ndepth pattern with the fdt_for_each_subnode() macro at all seven sites in boot/image-fit.c where the loop only ever processes direct children. The macro is already defined in <linux/libfdt.h> and used in boot/image-fit-sig.c, so this brings image-fit.c in line with the rest of the FIT code. The conversions are equivalence-preserving: - fit_get_subimage_count(): the depth-1 filter and the macro are both restricted to direct children. - fit_conf_print(): the parameter is named noffset, so the loop now uses sub_noffset to keep the parent reference stable. - fit_print_contents(): the count reset that lived inside the for initialiser is moved out as an explicit assignment before each loop, so the second loop still starts from zero. - fit_image_print(): straightforward replacement. - fit_all_image_verify(): same shape as the print loops, with the count reset moved out as an explicit assignment before the loop. - fit_conf_find_compat(): the body's "if (ndepth > 1) continue" guard is redundant once the macro is in use, and is dropped. No behaviour changes outside of these mechanical reductions. Local ndepth declarations that are no longer referenced are removed. Signed-off-by: Aristo Chen <aristo.chen@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Replace the verbose fdt_next_node() + ndepth pattern with the
fdt_for_each_subnode() macro at all seven sites in boot/image-fit.c
where the loop only ever processes direct children. The macro is
already defined in <linux/libfdt.h> and used in boot/image-fit-sig.c,
so this brings image-fit.c in line with the rest of the FIT code.

The conversions are equivalence-preserving:

  - fit_get_subimage_count(): the depth-1 filter and the macro are
    both restricted to direct children.
  - fit_conf_print(): the parameter is named noffset, so the loop
    now uses sub_noffset to keep the parent reference stable.
  - fit_print_contents(): the count reset that lived inside the for
    initialiser is moved out as an explicit assignment before each
    loop, so the second loop still starts from zero.
  - fit_image_print(): straightforward replacement.
  - fit_all_image_verify(): same shape as the print loops, with the
    count reset moved out as an explicit assignment before the loop.
  - fit_conf_find_compat(): the body's "if (ndepth > 1) continue"
    guard is redundant once the macro is in use, and is dropped.

No behaviour changes outside of these mechanical reductions. Local
ndepth declarations that are no longer referenced are removed.

Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
boot/fit: read default-config property from the configurations node 2026-05-25T19:44:10+00:00 Aristo Chen aristo.chen@canonical.com 2026-05-08T21:31:59+00:00 646be6d5cd37dc9f1e79f4c6677b872932605a2b In fit_print_contents() the default configuration's unit name is read by calling fdt_getprop() with noffset rather than confs_noffset. Today this happens to work by coincidence: the preceding loop walks /images using fdt_next_node(), and when iteration leaves the subtree libfdt returns the offset of the next sibling in DFS order, which by FIT layout convention is /configurations. The depth counter then drops below zero and the loop exits with noffset still pointing at /configurations. This relies on /images and /configurations being adjacent siblings and on the implementation detail of fdt_next_node()'s post-exhaustion return value. It also blocks a follow-up conversion to fdt_for_each_subnode(), whose post-loop loop variable is a negative error code rather than a valid offset. Use confs_noffset directly, which the comment immediately above the call already names as the source. Signed-off-by: Aristo Chen <aristo.chen@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
In fit_print_contents() the default configuration's unit name is read by
calling fdt_getprop() with noffset rather than confs_noffset. Today this
happens to work by coincidence: the preceding loop walks /images using
fdt_next_node(), and when iteration leaves the subtree libfdt returns
the offset of the next sibling in DFS order, which by FIT layout
convention is /configurations. The depth counter then drops below zero
and the loop exits with noffset still pointing at /configurations.

This relies on /images and /configurations being adjacent siblings and
on the implementation detail of fdt_next_node()'s post-exhaustion
return value. It also blocks a follow-up conversion to
fdt_for_each_subnode(), whose post-loop loop variable is a negative
error code rather than a valid offset.

Use confs_noffset directly, which the comment immediately above the
call already names as the source.

Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
boot: image-fit.c: check target, not source, for 8-byte alignment when loading FDT 2026-05-08T21:49:27+00:00 Rasmus Villemoes ravi@prevas.dk 2026-05-04T14:44:55+00:00 55b152e6f0204e0b769f66ffd40ad02081f9bff0 A number of our boards no longer boot with v2026.04, ironically as a result of the effort to ensure 8-byte alignment of the dtb passed to the kernel and getting rid of the fdt_high=0xffffffff. The problem exists when the FIT image does specify a (properly aligned) load address to use for the fdt. For example, we have fdt-am335x-boneblack.dtb { description = "Flattened Device Tree blob"; data = /incbin/(...); ... load = <0x88000000>; } Now, with v2026.04 and depending on just exactly where that data ends up, in a good case we see Loading fdt from 0x8a8c6e10 to 0x88000000 Booting using the fdt blob at 0x88000000 Working FDT set to 88000000 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Using Device Tree in place at 88000000, end 8801af2f Working FDT set to 88000000 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 and the board boots (though with that ominous warning). However, modifying the .its file a little, e.g. just removing the word "blob" from the description, we end up with Loading fdt from 0x8a8c6e14 to 0x88000000 Booting using the fdt blob at 0x9df94718 Working FDT set to 9df94718 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Failed to reserve memory for fdt at 0x9df94718 FDT creation failed! resetting ... Notice how the "Loading fdt from" line still claims to load the fdt to that 0x88000000 address, but since this "else if" clause looks at the source address (buf) and comes before the "else if (load != data)" clause, we end up doing the "allocate another buffer to use as target" instead of actually copying to 0x88000000, but then the "fdt_high=~0" logic in boot_relocate_fdt() obviously fails to do an lmb-reservation of that area, and the boot fails. When there's no load= property in the fdt node, this should not change anything. But when there is, it is the alignment of that target which is relevant, not the alignment of the fdt blob within the FIT image. With this patch applied, we instead get the expected Loading fdt from 0x8a8c6e14 to 0x88000000 Booting using the fdt blob at 0x88000000 Working FDT set to 88000000 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Using Device Tree in place at 88000000, end 8801af2f Working FDT set to 88000000 Starting kernel ... Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address") Reviewed-by: Simon Glass <sjg@chromium.org> 
A number of our boards no longer boot with v2026.04, ironically as a
result of the effort to ensure 8-byte alignment of the dtb passed to
the kernel and getting rid of the fdt_high=0xffffffff.

The problem exists when the FIT image does specify a (properly
aligned) load address to use for the fdt. For example, we have

	fdt-am335x-boneblack.dtb {
		description = "Flattened Device Tree blob";
		data = /incbin/(...);
		...
		load = <0x88000000>;
	}

Now, with v2026.04 and depending on just exactly where that data ends
up, in a good case we see

     Loading fdt from 0x8a8c6e10 to 0x88000000
     Booting using the fdt blob at 0x88000000
  Working FDT set to 88000000
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
     Using Device Tree in place at 88000000, end 8801af2f
  Working FDT set to 88000000
  Starting kernel ...
  [    0.000000] Booting Linux on physical CPU 0x0

and the board boots (though with that ominous warning). However,
modifying the .its file a little, e.g. just removing the word "blob"
from the description, we end up with

     Loading fdt from 0x8a8c6e14 to 0x88000000
     Booting using the fdt blob at 0x9df94718
  Working FDT set to 9df94718
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
  Failed to reserve memory for fdt at 0x9df94718
  FDT creation failed!
  resetting ...

Notice how the "Loading fdt from" line still claims to load the fdt to
that 0x88000000 address, but since this "else if" clause looks at the
source address (buf) and comes before the "else if (load != data)"
clause, we end up doing the "allocate another buffer to use as target"
instead of actually copying to 0x88000000, but then the "fdt_high=~0"
logic in boot_relocate_fdt() obviously fails to do an lmb-reservation
of that area, and the boot fails.

When there's no load= property in the fdt node, this should not change
anything. But when there is, it is the alignment of that target which
is relevant, not the alignment of the fdt blob within the FIT
image. With this patch applied, we instead get the expected

     Loading fdt from 0x8a8c6e14 to 0x88000000
     Booting using the fdt blob at 0x88000000
  Working FDT set to 88000000
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
     Using Device Tree in place at 88000000, end 8801af2f
  Working FDT set to 88000000

  Starting kernel ...

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address")
Reviewed-by: Simon Glass <sjg@chromium.org>
efi_loader: centralize messaging for efi_init_obj_list 2026-05-01T08:30:03+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2026-04-20T22:03:21+00:00 82539af483175e076f3727b51e23dff020eeec41 If efi_init_obj_list() fails we cannot use the UEFI sub-system. * Instead of having messages for this everywhere write an error message in efi_init_obj_list(). * Always use (ret != EFI_SUCCESS) when checking the return value of efi_init_obj_list(). * Remove the return code from the error message as it does not help users to understand which initialization went wrong. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
If efi_init_obj_list() fails we cannot use the UEFI sub-system.

* Instead of having messages for this everywhere write an error message
  in efi_init_obj_list().
* Always use (ret != EFI_SUCCESS) when checking the return value of
  efi_init_obj_list().
* Remove the return code from the error message as it does not help
  users to understand which initialization went wrong.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.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
boot: remove NO_NET use 2026-04-27T17:26:40+00:00 Quentin Schulz quentin.schulz@cherry.de 2026-04-20T11:36:12+00:00 b06c5ef4ddf051b0da8276d2a00ee3df037cbf2f NO_NET is now a transitional symbol which may eventually be removed. Its meaning is the opposite of the new meaning of NET (that is, any networking stack). Update the symbol dependency by using NET instead of !NO_NET. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
NO_NET is now a transitional symbol which may eventually be removed. Its
meaning is the opposite of the new meaning of NET (that is, any
networking stack).

Update the symbol dependency by using NET instead of !NO_NET.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
boot/fit: fix misleading comment 2026-04-21T21:56:43+00:00 Julien Stephan jstephan@baylibre.com 2026-04-09T13:15:43+00:00 86122451b5b987a41a149e385f09d8335348bebe When load address is specified but set to 0, we ignore it and load in place instead. The current comment is misleading, so update it. Signed-off-by: Julien Stephan <jstephan@baylibre.com> 
When load address is specified but set to 0, we ignore it and load in
place instead. The current comment is misleading, so update it.

Signed-off-by: Julien Stephan <jstephan@baylibre.com>
bootstd: efi: Handle prior-stage FDT in network path 2026-04-17T06:09:41+00:00 Simon Glass sjg@chromium.org 2026-04-05T11:34:32+00:00 ee4bcfc65971730dc2fe137877e620f19a2f8e93 When CONFIG_OF_HAS_PRIOR_STAGE is enabled and fdtfile is not set, efi_get_distro_fdt_name() returns -EALREADY to indicate the prior-stage FDT should be used. The block-device EFI path handles this by setting BOOTFLOWF_USE_PRIOR_FDT, but the network path treats it as an error, causing the bootflow to stay in 'base' state with a -EALREADY error. This also means fdt_addr_r is required even when no FDT download is needed, giving a spurious -EINVAL error. Fix this by calling efi_get_distro_fdt_name() before checking fdt_addr_r, and handling -EALREADY by setting BOOTFLOWF_USE_PRIOR_FDT to skip the FDT download, matching the block-device behaviour. THere is no test for this at present, since sandbox does not enable CONFIG_OF_HAS_PRIOR_STAGE and lacks infra for network-based EFI boot. Signed-off-by: Simon Glass <sjg@chromium.org> 
When CONFIG_OF_HAS_PRIOR_STAGE is enabled and fdtfile is not set,
efi_get_distro_fdt_name() returns -EALREADY to indicate the prior-stage
FDT should be used. The block-device EFI path handles this by setting
BOOTFLOWF_USE_PRIOR_FDT, but the network path treats it as an error,
causing the bootflow to stay in 'base' state with a -EALREADY error.

This also means fdt_addr_r is required even when no FDT download is
needed, giving a spurious  -EINVAL error.

Fix this by calling efi_get_distro_fdt_name() before checking
fdt_addr_r, and handling -EALREADY by setting BOOTFLOWF_USE_PRIOR_FDT
to skip the FDT download, matching the block-device behaviour.

THere is no test for this at present, since sandbox does not enable
CONFIG_OF_HAS_PRIOR_STAGE and lacks infra for network-based EFI boot.

Signed-off-by: Simon Glass <sjg@chromium.org>
lmb: boot: Update dependencies within BOOT_DEFAULTS_CMDS 2026-04-07T17:32:29+00:00 Tom Rini trini@konsulko.com 2026-03-23T19:52:47+00:00 a6594e82bb93bc14d97ca16440f6387fa3e0c111 The CMD_BOOT[IZ] symbols have a dependency on LMB, correctly, currently. Make sure that in BOOT_DEFAULTS_CMDS we only select these commands if LMB is enabled. Signed-off-by: Tom Rini <trini@konsulko.com> 
The CMD_BOOT[IZ] symbols have a dependency on LMB, correctly,
currently. Make sure that in BOOT_DEFAULTS_CMDS we only select these
commands if LMB is enabled.

Signed-off-by: Tom Rini <trini@konsulko.com>