u-boot.git/cmd, branch v2026.07

drivers: sysreset: revert support for args in request

2026-07-03T19:45:58Z

This reverts: - commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl option is available") - commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not supported") - commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") - commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation") - commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs") - commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take arguments") There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") due to commit 02ef1859b44f ("configs: Resync with savedefconfig"), but the conflict resolution was trivial. The args support for the sysreset uclass contains a logic bug. The first sysreset device implementing the request_arg callback will consume the args, not support the specified arg and thus return -EPROTONOSUPPORT which will stop the iteration over all sysreset devices. This is an issue if one has multiple sysreset devices and each with support for different (valid) args. If a sysreset device implements a -dummy argument and another -foo and a user calls reset -dummy from the U-Boot CLI, it'll depend on which sysreset device will be attempted first. If it is the one implementing -foo, it'll return it doesn't support the argument with -EPROTONOSUPPORT in which case the device implementing -dummy will never be attempted and instead we'll do a cold reset which is very likely not what's expected from the user. Casey suggested[1] we revert this and start from scratch again with a different implementation instead. [1] https://lore.kernel.org/u-boot/77ff0f56-5c3b-42e7-bdd1-bf90296da900@linaro.org/ Acked-by: Casey Connolly Signed-off-by: Quentin Schulz

net: lwip: introduce net_lwip_eth_stop() function

2026-06-23T11:13:16Z

Add a introduce net_lwip_eth_stop() function and use that to stop the network interface after each command that uses the network. This makes the behavior the same as the legacy net code and avoids potential issues with the network interface being left in an active state after a command finishes. The start/stop is reference-counted since there is at least one command (dhcp) that calls another command (tftp) to avoid starting and stopping the network interface multiple times in a single command. Signed-off-by: David Lechner Reviewed-by: Jerome Forissier

cmd: boot: fix edl being shown when not supported

2026-05-18T06:37:13Z

edl is implemented in the sysreset_ops.request_arg callback of the qcom-psci sysreset driver. That callback is only called from sysreset_request_arg() which is compiled only when CONFIG_SYSRESET_CMD_RESET_ARGS=y. Therefore, only show the edl option if that symbol is enabled. It is in a separate if block because any option but -w will only be handled when CONFIG_SYSRESET_CMD_RESET_ARGS=y as seen with the implementation in do_reset() in drivers/sysreset/sysreset-uclass.c. Fixes: ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation") Signed-off-by: Quentin Schulz Reviewed-by: Simon Glass

cmd: part: support lookup by UUID

2026-05-12T13:52:01Z

The 'part' command currently allows looking up a partition only by its number or name. Extend the 'number', 'start', and 'size' subcommands to support looking up the partition via its UUID. Unlike names, UUIDs guarantee unique partition identification, avoiding ambiguity. The logic is updated to check if the provided string is a valid UUID before falling back to a name-based search. The help strings for these subcommands are updated accordingly. Signed-off-by: Dario Binacchi Reviewed-by: Simon Glass

efi_loader: centralize messaging for efi_init_obj_list

2026-05-01T08:30:03Z

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

cmd/bootefi: move efi_init_obj_list() to the start of do_bootefi

2026-05-01T08:30:03Z

None of the bootefi commands can be executed if the EFI sub-system cannot be initialized. Reviewed-by: Ilias Apalodimas Reviewed-by: Simon Glass Signed-off-by: Heinrich Schuchardt

Merge branch 'master' of git://source.denx.de/u-boot-usb

2026-04-29T23:09:13Z

- Fix UMS and eMMC HW partition selection

cmd: ums: Switch HW partition before block access

2026-04-29T08:32:04Z

An UMS session with eMMC device specifier "ums C mmc dev.part1,dev.part2" exposes the same eMMC HW partition 'part2' twice instead of exposing both HW partitions 'part1' and 'part2'. Fix this by switching the eMMC HW partition before block device read/write access. An eMMC is represented by a single struct blk_desc, with the currently selected HW partition being stored in this struct blk_desc. Each call to part_get_info_by_dev_and_name_or_num() with partition string dev[.partN] does trigger HW partition switch by calling blk_get_device_part_str() -> blk_get_device_part_str() -> get_dev_hwpart() -> get_dev_hwpart() -> blk_dselect_hwpart(). The ums_init() iterates over the device specifier string and calls part_get_info_by_dev_and_name_or_num() in a loop for each dev[.partN] entry used as the partition string. If the device specifier string contains more than one dev[.partN] partition strings for the same dev device, then it is the HW partition described in the last dev[.partN] partition string entry that is accessed for all dev device partition strings in the device specifier string, because that last dev[.partN] partition string entry was the last one that triggered blk_dselect_hwpart() call for that device. To access the expected HW partition for every dev[.partN] partition string entry, it is necessary to call blk_dselect_hwpart() before each block read or write. Store HW partition described for each dev[.partN] partition string in struct ums and use the stored value to make it so. The blk_dselect_hwpart() does test whether the currently selected HW partition is already configured in hardware and does not reconfigure the hardware if that is the case, therefore for the majority of block reads and writes, blk_dselect_hwpart() is a no-op with negligible performance impact. Example reproducer is listed below. The last sector of both eMMC HW BOOT partitions is populated with distinct test pattern and UMS is launched: " => mmc dev 1 1 ; mmc read $loadaddr 0x1fff 1 ; md $loadaddr 4 switch to partitions #1, OK mmc1(part 1) is current device MMC read: dev # 1, block # 8191, count 1 ... 1 blocks read: OK 84000000: 1234abcd 1234abcd 1234abcd 1234abcd ..4...4...4...4. => mmc dev 1 2 ; mmc read $loadaddr 0x1fff 1 ; md $loadaddr 4 switch to partitions #2, OK mmc1(part 2) is current device MMC read: dev # 1, block # 8191, count 1 ... 1 blocks read: OK 84000000: 567890ef 567890ef 567890ef 567890ef ..xV..xV..xV..xV => ums 0 mmc 1.1,1.2 UMS: LUN 0, dev mmc 1, hwpart 1, sector 0x0, count 0x2000 UMS: LUN 1, dev mmc 1, hwpart 2, sector 0x0, count 0x2000 " Read of the two block devices on host without this fix produces identical data present in HW BOOT partition 2: " $ dd if=/dev/sdX of=mmc-a.bin ; dd if=/dev/sdY of=mmc-b.bin $ hexdump -C mmc-a.bin | tail -n 3 | head -n 1 ; \ hexdump -C mmc-b.bin | tail -n 3 | head -n 1 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV| 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV| " Read of the two block devices on host with this fix produces the expected distinct data from either HW BOOT partition 1 or 2: " $ dd if=/dev/sdX of=mmc-a.bin ; dd if=/dev/sdY of=mmc-b.bin $ hexdump -C mmc-a.bin | tail -n 3 | head -n 1 ; \ hexdump -C mmc-b.bin | tail -n 3 | head -n 1 003ffe00 cd ab 34 12 cd ab 34 12 cd ab 34 12 cd ab 34 12 |..4...4...4...4.| 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV| " Reported-by: Christoph Niedermaier Signed-off-by: Marek Vasut Reviewed-by: Simon Glass

Merge patch series "net: migrate NO_NET out of the networking stack choice"

2026-04-27T17:28:25Z

Quentin Schulz 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:40Z

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 Reviewed-by: Simon Glass Reviewed-by: Peter Robinson Reviewed-by: Tom Rini