u-boot.git/include/configs, branch next

ls1028ardb: Move environment variables to .env file

2026-07-06T01:58:58Z

Move the bulk of the board environment from CFG_EXTRA_ENV_SETTINGS in ls1028ardb.h to board/nxp/ls1028a/ls1028ardb.env. Because the board directory is shared with ls1028aqds, the file is selected through CONFIG_ENV_SOURCE_FILE rather than the SYS_BOARD default. The distro_bootcmd machinery cannot be expressed in a .env file. The BOOTENV macro expands to environment text with embedded NUL separators, and the board overrides three distro variables (boot_scripts, boot_a_script and scan_dev_for_boot_part) that must follow BOOTENV to take effect. BOOTENV and those three overrides therefore remain in CFG_EXTRA_ENV_SETTINGS, which is concatenated after the .env text, while every other variable moves to the .env file. The resulting default environment is functionally unchanged for both the ls1028ardb_tfa and ls1028ardb_tfa_SECURE_BOOT defconfigs. This was verified with an order aware comparison of the default environment before and after the change. The only difference is that three accidental double spaces in xspi_bootcmd, sd_bootcmd and emmc_bootcmd collapse to single spaces, because the preprocessor normalises whitespace in the now unquoted text, which does not affect command parsing. Signed-off-by: Aristo Chen Signed-off-by: Peng Fan

Merge patch series "arm: aspeed: add initial AST2700 SoC support"

2026-06-29T21:29:56Z

Ryan Chen says: AST2700 is the 8th generation of Integrated Remote Management Processor introduced by ASPEED Technology Inc. It is a Board Management Controller (BMC) SoC family with a dual-die architecture: SoC0 ("CPU" die with four ARM Cortex-A35 application cores) and SoC1 ("IO" die with peripherals) each SoC have its own SCU PLLs, clock dividers and reset domains. Link: https://lore.kernel.org/r/20260612-ast2700_clk-v4-0-9bea29cfdc39@aspeedtech.com

arm: aspeed: add ASPEED AST2700 SoC family support

2026-06-29T19:43:20Z

Add initial support for the ASPEED AST2700, an arm64 (Cortex-A35) Baseboard Management Controller (BMC) SoC. AST2700 is Aspeed's 8th generation BMC and uses a dual-die architecture: SoC0 (the "CPU" die) hosts the four Cortex-A35 cores and its own SCU at 0x12c02000, while SoC1 (the "IO" die) hosts the peripherals and its own SCU at 0x14c02000. This commit adds: - ASPEED_AST2700 Kconfig option and the ast2700 mach subdir (mach Makefile, ast2700/Kconfig, board/aspeed/evb_ast2700/*) - arm64 MMU map covering the SoC device window and the DRAM region at 0x4_0000_0000 (up to 8 GiB) - lowlevel_init.S for early CPU bring-up - cpu-info: print SoC ID (AST2700/2720/2750 A0/A1/A2 variants) and reset cause (cold reset, EXT reset, WDT reset) - board_common: dram_init via UCLASS_RAM, AHBC timeout init - platform: env_get_location() that selects SPI/eMMC based on the IO-die HW strap; arch_misc_init() that exposes ${boot_device} and ${verify} to the boot script - SCU0/SCU1 register layout header (scu_ast2700.h) - configs/evb-ast2700_defconfig and include/configs/evb_ast2700.h for the AST2700 EVB board The defconfig depends on ast2700-evb.dts, which is introduced in a subsequent patch; this commit must be applied with the remaining series for evb-ast2700_defconfig to build. Signed-off-by: Ryan Chen

board: toradex: add initial support for aquila imx95

2026-06-27T02:02:45Z

Add initial U-Boot support for Aquila iMX95 SoM. Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95 Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit Signed-off-by: Franz Schnyder Reviewed-by: Francesco Dolcini

mx6sabre: Move environment variables to .env files

2026-06-26T20:08:26Z

Move the shared environment from CFG_EXTRA_ENV_SETTINGS in mx6sabre_common.h to a common text environment fragment in include/env/nxp/mx6sabre_common.env. The mx6sabresd and mx6sabreauto board environments include this fragment and add their own console setting, which is the only board specific difference between them. The eMMC firmware update variables remain guarded by CONFIG_SUPPORT_EMMC_BOOT inside the fragment. The now unused CONSOLE_DEV defines and the linux/stringify.h include are dropped. The generated default environment is unchanged for both boards. This was verified by comparing the output of scripts/get_default_envs.sh before and after the change, which produced identical results. Signed-off-by: Aristo Chen Reviewed-by: Peng Fan

mx6ullevk: Move environment variables to .env file

2026-06-26T20:08:26Z

Move the board environment from CFG_EXTRA_ENV_SETTINGS in the config header to board/nxp/mx6ullevk/mx6ullevk.env for better maintainability. The file is named after CONFIG_SYS_BOARD so it is selected automatically without setting CONFIG_ENV_SOURCE_FILE. Drop the now unused linux/stringify.h include. The generated default environment is unchanged. This was verified by comparing the output of scripts/get_default_envs.sh before and after the change, which produced identical results. Signed-off-by: Aristo Chen Reviewed-by: Peng Fan

mx7ulp_evk: Move environment variables to .env file

2026-06-26T20:08:26Z

Move the board environment from CFG_EXTRA_ENV_SETTINGS in the config header to board/nxp/mx7ulp_evk/mx7ulp_evk.env for better maintainability. The file is named after CONFIG_SYS_BOARD so it is selected automatically without setting CONFIG_ENV_SOURCE_FILE. The generated default environment is unchanged. This was verified by comparing the output of scripts/get_default_envs.sh before and after the change, which produced identical results. Signed-off-by: Aristo Chen Reviewed-by: Peng Fan

treewide: move bi_dram[] from bd to gd

2026-06-25T00:13:24Z

Currently, the bi_dram[] information is stored in the board info structure (bd). Because bd is only valid after reserve_board(), dram_init_banksize() must be called late in the initialization process. This limitation is problematic, as it forces us to rely on a variety of bespoke functions to determine board RAM, bank memory sizes, and other early setup requirements. By moving bi_dram[] into the global data (gd), we can run it earlier. This is particularly convenient since boards define their own dram_init_banksize() routines, which do not always rely on parsing Device Tree (DT) memory nodes. Additionally, U-Boot defaults to relocating to the top of the first memory bank. While boards currently use custom functions to override this behavior, having the DRAM bank information available earlier in gd makes relocating to a different bank trivial and standardizes the process. Reviewed-by: Anshul Dalal Tested-by: Michal Simek # Versal Gen 2 Vek385 Tested-by: Anshul Dalal Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

Merge tag 'v2026.07-rc5' into next

2026-06-22T22:42:41Z

Prepare v2026.07-rc5

Merge patch series "arm: omap: Add back omap4 support"

2026-06-17T15:52:33Z

Bastien Curutchet says: This series aims to add back the omap4 support. This support was removed by commit b0ee3fe642c ("arm: ti: Remove omap4 platform support") because at that moment, none of the OMAP4-based boards had done the migration to DM_I2C. My use case is an old product based on the Variscite's omap4 system on module. I needed to upgrade U-Boot on it for security reasons. I think that this work could benefit to other people who may have same kind of product to maintain. Patch 1 to 3 remove the omap's clock driver dependency to the AM33xx as it is also present in omap4 platforms. I tested these changes on the beaglebone black to ensure I didn't break the AM33xx case. Patch 4 & 5 revert the deletion of the omap4 support. The revert makes checkpatch.pl angry. I fixed quite a lots of warnings already but it remains two kinds of warnings: - CamelCase on timings structure, I left the CamelCase because IMHO it's more readable this way. - #ifdef CONFIG_XYZ shouldn't be used anymore. I left one of this because I didn't find a clean way to get rid of it. Patch 6 adds support for the Variscite's system on module. This system on module is supported by the Linux project through ti/omap/omap4-var-som-om44.dtsi Link: https://lore.kernel.org/r/20260608-omap4-support-v3-0-8595ccd203f0@bootlin.com