<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/lib/efi_loader, branch next</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>efi_loader: fix hii keyboard layout pointer computation</title>
<updated>2026-05-18T06:38:16+00:00</updated>
<author>
<name>Vincent Stehlé</name>
<email>vincent.stehle@arm.com</email>
</author>
<published>2026-05-12T17:40:33+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ec95a60d9dcd9436faa08f8151f05e4bba8e14a0'/>
<id>ec95a60d9dcd9436faa08f8151f05e4bba8e14a0</id>
<content type='text'>
The EFI_HII_KEYBOARD_LAYOUT field `layout_length' is expressed in bytes,
but we add it to the `layout' pointer with (scaled) pointer arithmetic.
When adding an HII keyboard package with multiple keyboard layouts, this
results in only the first layout being added correctly; fix it.

Fixes: 8d3b77e36e10 ("efi: hii: add keyboard layout package support")
Signed-off-by: Vincent Stehlé &lt;vincent.stehle@arm.com&gt;
Cc: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: AKASHI Takahiro &lt;akashi.tkhro@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The EFI_HII_KEYBOARD_LAYOUT field `layout_length' is expressed in bytes,
but we add it to the `layout' pointer with (scaled) pointer arithmetic.
When adding an HII keyboard package with multiple keyboard layouts, this
results in only the first layout being added correctly; fix it.

Fixes: 8d3b77e36e10 ("efi: hii: add keyboard layout package support")
Signed-off-by: Vincent Stehlé &lt;vincent.stehle@arm.com&gt;
Cc: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: AKASHI Takahiro &lt;akashi.tkhro@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: fix AllocatePages overlap status</title>
<updated>2026-05-18T06:32:58+00:00</updated>
<author>
<name>Harsimran Singh Tungal</name>
<email>harsimransingh.tungal@arm.com</email>
</author>
<published>2026-04-27T15:05:30+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d0d1c4a4f5d13c8dd792d5cc5379eb4c1e0f0c46'/>
<id>d0d1c4a4f5d13c8dd792d5cc5379eb4c1e0f0c46</id>
<content type='text'>
Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS overlap

When efi_allocate_pages() is called with EFI_ALLOCATE_ADDRESS, UEFI
expects EFI_NOT_FOUND if the requested address range is already
allocated or unavailable. U-Boot currently returns
EFI_OUT_OF_RESOURCES when efi_update_memory_map() detects an overlap
after a successful lmb_alloc_mem(), which does not match
EFI_ALLOCATE_ADDRESS semantics.

Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS requests that fail due
to an overlapping EFI memory descriptor, while keeping
EFI_OUT_OF_RESOURCES for other allocation types.

The UEFI specification [1] specifies that
EFI_BOOT_SERVICES.AllocatePages must return EFI_NOT_FOUND when the
requested address range is unavailable or already allocated;
EFI_OUT_OF_RESOURCES applies to non‑address‑specific allocation
failures.

[1] https://uefi.org/specs/UEFI/2.10_A/07_Services_Boot_Services.html

Signed-off-by: Harsimran Singh Tungal &lt;harsimransingh.tungal@arm.com&gt;

The UEFI specification does not clearly specify the behavior.
But let's follow the EDK II precedent here.

Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS overlap

When efi_allocate_pages() is called with EFI_ALLOCATE_ADDRESS, UEFI
expects EFI_NOT_FOUND if the requested address range is already
allocated or unavailable. U-Boot currently returns
EFI_OUT_OF_RESOURCES when efi_update_memory_map() detects an overlap
after a successful lmb_alloc_mem(), which does not match
EFI_ALLOCATE_ADDRESS semantics.

Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS requests that fail due
to an overlapping EFI memory descriptor, while keeping
EFI_OUT_OF_RESOURCES for other allocation types.

The UEFI specification [1] specifies that
EFI_BOOT_SERVICES.AllocatePages must return EFI_NOT_FOUND when the
requested address range is unavailable or already allocated;
EFI_OUT_OF_RESOURCES applies to non‑address‑specific allocation
failures.

[1] https://uefi.org/specs/UEFI/2.10_A/07_Services_Boot_Services.html

Signed-off-by: Harsimran Singh Tungal &lt;harsimransingh.tungal@arm.com&gt;

The UEFI specification does not clearly specify the behavior.
But let's follow the EDK II precedent here.

Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_mem_sort: use list_for_each_entry_safe instead</title>
<updated>2026-05-05T14:29:08+00:00</updated>
<author>
<name>Randolph Sapp</name>
<email>rs@ti.com</email>
</author>
<published>2026-04-22T17:09:45+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b1c28ad5fafd95c183b26165e498354db41b755b'/>
<id>b1c28ad5fafd95c183b26165e498354db41b755b</id>
<content type='text'>
Use list_for_each_entry_safe and comparisons against the current and
next efi_mem_desc. This reduces the computation required for merging
regions, prevents unnecessary additional iterations of the list, and
requires less temporary values.

Signed-off-by: Randolph Sapp &lt;rs@ti.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use list_for_each_entry_safe and comparisons against the current and
next efi_mem_desc. This reduces the computation required for merging
regions, prevents unnecessary additional iterations of the list, and
requires less temporary values.

Signed-off-by: Randolph Sapp &lt;rs@ti.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_dt_fixup: use fdtdec_get_bool</title>
<updated>2026-05-05T14:29:08+00:00</updated>
<author>
<name>Randolph Sapp</name>
<email>rs@ti.com</email>
</author>
<published>2026-04-22T17:09:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3ad3243f8a062c0a14adcb645c83f45b55eaeab9'/>
<id>3ad3243f8a062c0a14adcb645c83f45b55eaeab9</id>
<content type='text'>
Use the more straightforward fdtdec_get_bool instead of fdt_getprop and
a return code check.

Signed-off-by: Randolph Sapp &lt;rs@ti.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use the more straightforward fdtdec_get_bool instead of fdt_getprop and
a return code check.

Signed-off-by: Randolph Sapp &lt;rs@ti.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: initialize variables in efi_dp_from_http()</title>
<updated>2026-05-05T14:29:08+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2026-04-29T15:40:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=28980318032ea19031f0a739221e24f1ad87a09c'/>
<id>28980318032ea19031f0a739221e24f1ad87a09c</id>
<content type='text'>
When using lwIP, efi_dp_from_http() may fail to initialize ip or mask.
Initialize the variables before the call.

Addresses-Coverity-ID: 645840 - Uninitialized variables (UNINIT)
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When using lwIP, efi_dp_from_http() may fail to initialize ip or mask.
Initialize the variables before the call.

Addresses-Coverity-ID: 645840 - Uninitialized variables (UNINIT)
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: centralize messaging for efi_init_obj_list</title>
<updated>2026-05-01T08:30:03+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2026-04-20T22:03:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=82539af483175e076f3727b51e23dff020eeec41'/>
<id>82539af483175e076f3727b51e23dff020eeec41</id>
<content type='text'>
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 &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: correct efi_binary_run_dp() return value</title>
<updated>2026-05-01T08:30:03+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2026-04-20T22:03:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=257f9f52738641f8981b3ccb17d56567d145a084'/>
<id>257f9f52738641f8981b3ccb17d56567d145a084</id>
<content type='text'>
efi_binary_run_dp() is expected to return an efi_status_t value.

Reported-by: Simon Glass &lt;sjg@chromium.org&gt;
Fixes: 6422820ac3e5 ("efi_loader: split unrelated code from efi_bootmgr.c")
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
efi_binary_run_dp() is expected to return an efi_status_t value.

Reported-by: Simon Glass &lt;sjg@chromium.org&gt;
Fixes: 6422820ac3e5 ("efi_loader: split unrelated code from efi_bootmgr.c")
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: correct return value of efi_bootmgr_run()</title>
<updated>2026-05-01T08:30:03+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2026-04-20T22:03:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=96b33427eae16b7c49dfa5f596506dbe5d84c2ff'/>
<id>96b33427eae16b7c49dfa5f596506dbe5d84c2ff</id>
<content type='text'>
efi_bootmgr_run() is expected to return an efi_status_t value.

Reported-by: Simon Glass &lt;sjg@chromium.org&gt;
Fixes: 0bef4b0123f2 ("cmd: bootefi: move library interfaces under lib/efi_loader")
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
efi_bootmgr_run() is expected to return an efi_status_t value.

Reported-by: Simon Glass &lt;sjg@chromium.org&gt;
Fixes: 0bef4b0123f2 ("cmd: bootefi: move library interfaces under lib/efi_loader")
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>EFI Loader: Correct dependencies for EFI_HTTP_BOOT</title>
<updated>2026-05-01T07:11:07+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-03-17T01:24:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9d06ec9fd40726793e03b4adf964a52bbccdf8fe'/>
<id>9d06ec9fd40726793e03b4adf964a52bbccdf8fe</id>
<content type='text'>
As exposed by "make randconfig", we have an issue with the dependencies
for EFI_HTTP_BOOT. As this is implemented by running commands (as seen
by what it selects) it must depend on CMDLINE as well.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As exposed by "make randconfig", we have an issue with the dependencies
for EFI_HTTP_BOOT. As this is implemented by running commands (as seen
by what it selects) it must depend on CMDLINE as well.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge patch series "net: migrate NO_NET out of the networking stack choice"</title>
<updated>2026-04-27T17:28:25+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-04-27T17:28:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=96c8b9c4ceb7a144e52b5bbf56ea58512f978bb7'/>
<id>96c8b9c4ceb7a144e52b5bbf56ea58512f978bb7</id>
<content type='text'>
Quentin Schulz &lt;foss+uboot@0leil.net&gt; 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 |&amp; 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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Quentin Schulz &lt;foss+uboot@0leil.net&gt; 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 |&amp; 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
</pre>
</div>
</content>
</entry>
</feed>
