With correct POSIX handling, unquoted empty variables can turn the
expression like
test -n ${fdtfile}
into
test -n
The POSIX handling for single argument `test` evaluates it as true,
so the fallback initialization will be skipped unexpectedly.
Quoting variable expansions in `test` expressions will always result in
correct behavior for empty and non-empty values.
This change was triggered by
commit 8b0619579b22 ("cmd: test: fix handling of single-argument form of test")
The aim is to have a less fragile codebase that is not dependent on a
quirk of the shell implementation.
Use quoted variable expansions in `test` expressions throughout.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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
Highlight that NET really is the legacy networking stack by renaming the option to NET_LEGACY. This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL. The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is using the legacy networking app so this seems fine to do. This also has the benefit of removing potential confusion on NET being a specific networking stack instead of "any" network stack. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
The hardware configuration pins are used both to select the DDR
configuration and to determine the installed memory size.
On Aquila AM69, the DDR timing patch is applied in the R5 SPL, while the
memory size fixup for the next-stage U-Boot DT is done later in the A72
SPL path.
The previous immplementation was not taking in account that the hw_cfg
value is lost both during SPL execution (board_init_f and board_init_r)
and between SPL and U-Boot proper.
Fix this by reading the hardware configuration pins when the memory size
is actually needed:
- in the R5 SPL, to select the correct DDR configuration
- in the A72 SPL, to fix up the U-Boot DT memory size and bank layout
Fixes: 3f0528882c0d ("board: toradex: add aquila am69 support")
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The 16GB dual-rank DDR configuration uses an incorrect DDRSS_PLL_FHS_CNT
value. This makes DDR initialization hang during the DDR frequency
handshake sequence.
Update DDRSS_PLL_FHS_CNT to the correct value for the 16GB dual-rank
configuration.
Fixes: 39e014f43a15 ("board: toradex: aquila-am69: Add support for 16GB dual rank memory configuration")
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Ernest Van Hoecke <ernestvanhoecke@gmail.com> says: This patch series migrates the Aquila AM69 to OF_UPSTREAM to receive automatic device tree updates. It also adds remoteproc firmware pre-loading to the environment. Link: https://lore.kernel.org/r/20260417-elb-6911-aquila69-ofupstr-v1-0-400d93db3747@toradex.com
Some use cases require remoteproc firmware to be loaded before Linux boots. Introduce rprocsemmcboot and rproc_fw_binaries to load the remoteproc cores from U-Boot, relying on the TI k3_rproc framework which already handles the secure firmware variants, firmware loading, and proper initialization. The firmware binaries are expected to be present in the eMMC rootfs under /lib/firmware/. To activate, run rprocsemmcboot or add it to bootcmd: bootcmd=run rprocsemmcboot; bootflow scan -b The upstream U-Boot does not yet have the remoteproc DT nodes enabled for the Aquila AM69, making firmware loading fail. Marking as pending waiting for remoteproc enabling, which could happen along with the OF_UPSTREAM migration. Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Enable CONFIG_OF_UPSTREAM to receive automatic device tree updates for the Aquila AM69. Remove the now-obsolete device tree files: - arch/arm/dts/k3-am69-aquila-dev.dts - arch/arm/dts/k3-am69-aquila.dtsi Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Add these new PID4 to config block handling: - 0226 Verdin iMX95 Hexa 4GB WB IT - 0227 Verdin iMX95 Hexa 4GB ET - 0228 Verdin iMX95 Hexa 16GB IT Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for the Toradex Verdin iMX95. Link: https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95 Link: https://www.toradex.com/products/carrier-board/verdin-development-board-kit Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org>