u-boot.git/include/env_callback.h, 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

env: Fix network support when CONFIG_NET_LWIP is set

2025-05-30T19:43:24Z

When lwIP (CONFIG_NET_LWIP) is used instead of legacy stack (CONFIG_NET), environment flags support associated with network was not built: restore support of "i" and "m" environment flags. Signed-off-by: Benjamin ROBIN Acked-by: Jerome Forissier Reviewed-by: Tom Rini

env: Switch the callback static list to Kconfig

2024-12-06T22:37:43Z

Switch the callback static list from the board configuration variable CFG_ENV_CALLBACK_LIST_STATIC to Kconfig CONFIG_ENV_CALLBACK_LIST_STATIC. Signed-off-by: Christoph Niedermaier Reviewed-by: Marek Vasut

Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"

2024-10-11T18:23:25Z

Simon Glass says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit.

include: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD

2024-10-11T17:44:48Z

Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass

dfu: define a callback function for the dfu_alt_info environment variable

2024-10-01T08:55:09Z

I'm trying to use dfu-util for bootstrapping an stm32mp board. It mostly works fine, but something goes horribly wrong as soon as I make use of the ability to run arbitrary u-boot shell commands. The shell commands themselves work fine, but the heuristic "dfu_alt_info may have changed, we have to reinit" seems to cause the board and/or my host machine to go into some bad state, and further dfu-util commands fail. U-Boot already has a mechanism whereby C code can be told about changes to specific environment variables. So instead of always doing re-init, add a hook to the dfu_alt_info variable so that we only do set dfu_reinit_needed if the commands actually did modify that variable. Signed-off-by: Rasmus Villemoes Reviewed-by: Mattijs Korpershoek Link: https://lore.kernel.org/r/20240911133900.1444083-1-rasmus.villemoes@prevas.dk Signed-off-by: Mattijs Korpershoek

Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"

2024-05-20T19:35:03Z

As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman Signed-off-by: Tom Rini

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

2024-05-19T14:16:36Z

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman Signed-off-by: Tom Rini

env: Remove and add needed includes

2024-05-06T21:05:04Z

Remove from all "env/" files and when needed add missing include files directly. Signed-off-by: Tom Rini