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
In the main Kconfig, there are only two more menus, General Setup and Expert, in addition to the net menu. Since the part in the main Kconfig is mostly about selecting the network stack (legacy or lwIP), and that we already have a net/Kconfig, let's move those to net/Kconfig to have everything in the same place. No intended change in behavior. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Prepare for MX7-based module with SPL support. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>
Casey Connolly <casey.connolly@linaro.org> says: This series implements various improvements to Linux header compatibility, largely in preparation for a full port of Linux CCF but many of these changes would also be helpful when porting other drivers. Beside the basic header/compat stuff there are a few larger patches: Patch 1 adds the "%pOF" format specifier to vsprintf, this behaves the same as it does in Linux printing the name of the ofnode, but notably it expects an ofnode pointer rather than a device_node. Patch 2 adds an option to skip doing a full DM scan pre-relocation. Some platforms like Qualcomm don't actually need devices to be probed prior to relocation, it is also quite slow to scan the entire FDT before caches are up. This option gets us to main loop 30-50% faster. Unfortunately it isn't possible to totally skip DM since U-Boot will panic if it can't find a serial port, but the serial uclass code will bind the serial port itself by reading /chosen/stdout-path, however any dependencies like clocks won't be found so this should only be enabled if the serial driver gracefully handles missing clocks. Patch 3 adds [k]strdup_const(), this works the same as the Linux version saving a small amount of memory by avoiding duplicating strings stored in .rodata, this is particularly useful for CCF. Patch 4 adds 64-bit versions of some 32-bit ofnode utilities functions, making it possible to parse 64-bit arrays. Patch 6 provides a simple implementation of kref, this will be used by CCF. Patch 9 adds devm_krealloc() support to devres, it relies on storing allocation sizes in the devres struct which will add a small overhead. Link: https://lore.kernel.org/r/20260401-casey-ccf-compat-v2-0-414d5b7f040b@linaro.org
For some platforms like Qualcomm, it isn't necessary to perform a full DM init and scan prior to relocation, it's also particularly slow since it runs with dcache disabled and prior to building the livetree. The only device which needs to be probed pre-reloc is the serial port (otherwise U-Boot will panic), however this can be found through /chosen/stdout-path. Therefore we can avoid scanning the entire FDT and binding devices, instead just binding the serial port and clock driver on-demand. This decreases the total time from power on to reaching the interactive U-Boot shell be about 50% (from ~2.8s to 1.8s). Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
The data only relocation mode should be selected on per-SoC or per-core
basis, make these options non-user-configurable. The SoC or cores which
require this have to select this option using "default" keyword.
Fixes: d9eee3d17882 ("arm: relocate: Introduce data-only relocation mode")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Functionally, both networking stacks require DM_ETH. This is because they both also require some networking devices to be enabled. Express this more correctly by having both NET and NET_LWIP select NETDEVICES. In turn NETDEVICES no longer depends on NET or NET_LWIP as it's not prompted anymore. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Introduce new mode of relocation which relocates only data, not code. This is mainly meant to relocate data to read-write portion of the RAM, while the code remains in read-only portion of the RAM from which it is allowed to execute. This split configuration is present on various secure cores. The result of the relocation is U-Boot running at its original address, data relocated to the end of DRAM, but with added read-write area offset. The U-Boot binary area is not reserved from the end of the DRAM in this relocation mode, because U-Boot itself is not relocated. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The UEFI specification requires at least 128 KiB stack space. Consider this value as a prerequisite for CONFIG_EFI_LOADER. Mention the requirement in the CONFIG_STACK_SPACE description and decribe that the UEFI sub-system uses CONFIG_STACK_SPACE when defining the memory map. Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
TARGET namespace is for machines / boards / what-have-you that building U-Boot for. Simply replace from TARGET to ARCH make things more clear and proper for ALL SoCFPGA. Signed-off-by: Brian Sune <briansune@gmail.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com> # Conflicts: # drivers/ddr/altera/Makefile