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

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

rename NET to NET_LEGACY

2026-04-27T17:26:40Z

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 Acked-by: Ilias Apalodimas Reviewed-by: Peter Robinson Reviewed-by: Tom Rini

cmd: bdinfo: fix incorrect Kconfig options check for print_eth()

2026-01-02T21:51:54Z

CMD_NET_LWIP has never existed so it cannot be right. I'm guessing the intent was to allow print_eth() to be called when NET_LWIP is defined (NET means "legacy networking stack" as opposed to NET_LWIP which is the newest (and incompatible) stack). There probably was some mix-up between CMD_NET and NET options. The dependency on CMD_NET seems unnecessary as it seems perfectly fine to run bdinfo without CMD_NET (build and run tested). So let's instead make the dependency on NET || NET_LWIP. Let's sync the unit test as well. Fixes: 95744d2527cb ("cmd: bdinfo: enable -e when CONFIG_CMD_NET_LWIP=y") Signed-off-by: Quentin Schulz Reviewed-by: Jerome Forissier

cmd: bdinfo: provide long help with all options

2025-12-24T08:17:21Z

Document the bdinfo -a, -e and -m options in the long help, but only when they can be used. The string concatenation is a bit odd with two newlines, but it does render properly once in U-Boot CLI. Tested-by: Michal Simek Signed-off-by: Quentin Schulz

cmd/bdinfo: LMB and device-tree are not related

2025-12-24T08:16:03Z

The usage of the LMB library and the device-tree source are not related. Remove the dependency in the bdinfo output and adjust the unit test. Reviewed-by: Ilias Apalodimas Signed-off-by: Heinrich Schuchardt

cmd: bdinfo: Fix showing correct IP address based on current device

2025-08-05T00:23:16Z

Use the same logic as is used for MAC address where bdi shows mac address for current device where index (idx) is used to point to correct IP address which is read and show. Signed-off-by: Michal Simek

global: Remove bi_sramstart/bi_sramsize

2024-11-17T01:49:13Z

These fields are currently set on exactly two platforms today, and used by only one of them. Update pic32mzdask to use CFG_SYS_SRAM* in the one location it needs it and otherwise drop this field from the bd_info struct. Signed-off-by: Tom Rini

cmd: bdinfo: enable -e when CONFIG_CMD_NET_LWIP=y

2024-10-16T17:11:56Z

Support "bdinfo -e" when lwIP is selected. Signed-off-by: Jerome Forissier Reviewed-by: Ilias Apalodimas Reviewed-by: Tom Rini

Merge patch series "Make LMB memory map global and persistent"

2024-09-03T20:09:30Z

Sughosh Ganu says: This is a follow-up from an earlier RFC series [1] for making the LMB and EFI memory allocations work together. This is a non-rfc version with only the LMB part of the patches, for making the LMB memory map global and persistent. This is part one of a set of patches which aim to have the LMB and EFI memory allocations work together. This requires making the LMB memory map global and persistent, instead of having local, caller specific maps. This is being done keeping in mind the usage of LMB memory by platforms where the same memory region can be used to load multiple different images. What is not allowed is to overwrite memory that has been allocated by the other module, currently the EFI memory module. This is being achieved by introducing a new flag, LMB_NOOVERWRITE, which represents memory which cannot be re-requested once allocated. The data structures (alloced lists) required for maintaining the LMB map are initialised during board init. The LMB module is enabled by default for the main U-Boot image, while it needs to be enabled for SPL. This version also uses a stack implementation, as suggested by Simon Glass to temporarily store the lmb structure instance which is used during normal operation when running lmb tests. This does away with the need to run the lmb tests separately. The tests have been tweaked where needed because of these changes. The second part of the patches, to be sent subsequently, would work on having the EFI allocations work with the LMB API's. [1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t Notes: 1) These patches are on next, as the alist patches have been applied to that branch. 2) I have tested the boot on the ST DK2 board, but it would be good to get a T-b/R-b from the ST maintainers. 3) It will be good to test these changes on a PowerPC platform (ideally an 85xx, as I do not have one).

lmb: remove the lmb_init_and_reserve() function

2024-09-03T20:08:50Z

With the changes to make the LMB reservations persistent, the common memory regions are being added during board init. Remove the now superfluous lmb_init_and_reserve() function. Signed-off-by: Sughosh Ganu Reviewed-by: Simon Glass Reviewed-by: Ilias Apalodimas