u-boot.git/arch/arm/dts, branch next

Merge patch series "TI: AM64-EVM/SK: Enable MAIN UART1 for SYSFW tracing"

2026-07-03T16:10:34Z

Vishal Mahaveer says: Collecting SYSFW traces from DMSC firmware is broken on the current codebase. These changes enables MAIN_UART1 for collecting SYSFW traces when the trace option is enabled in the boardcfg. Link: https://lore.kernel.org/r/20260605193829.395161-1-vishalm@ti.com

arm: dts: k3-am642-evm/sk: enable MAIN UART1 for SYSFW logs

2026-07-03T16:09:56Z

Enable MAIN UART1 in the R5 SPL device tree to collect system SYSFW debug traces during early boot. Signed-off-by: Vishal Mahaveer Reviewed-by: Bryan Brattlof

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: dts: aspeed: Add initial AST27xx SoC device tree

2026-06-29T19:43:20Z

Add initial device tree support for the ASPEED AST27xx family, the 8th-generation Baseboard Management Controller (BMC) SoCs. AST27xx SOC Family - https://www.aspeedtech.com/server_ast2700/ - https://www.aspeedtech.com/server_ast2720/ - https://www.aspeedtech.com/server_ast2750/ The AST27xx features a dual-SoC architecture consisting of two ties, referred to as SoC0 and SoC1 - interconnected through an internal property bus. Both SoCs share the same address decoding scheme, while each maintains independent clock and reset domains. - SoC0 (CPU die): contains a dual-core Cortex-A35 cluster and two Cortex-M4 cores, along with high-speed peripherals. - SoC1 (I/O die): includes the BootMCU (responsible for system boot) and its own clock/reset domains low-speed peripherals. The device tree describes the SoC0 and SoC1 domains and their peripheral layouts. 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

imx93: Add support for OPTEE

2026-06-26T20:08:59Z

OPTEE-OS starts correctly when "opteed" is enabled for Secure Payload Dispatcher in TF-A (tested on OP-TEE version: 4.9.0), however imx93 devices require a patch for OPTEE targets because binman does not see the tee.bin file when it is available. Enable conditional OPTEE support for imx93 devices. Signed-off-by: Krzysztof Drobiński Signed-off-by: Mathieu Dubois-Briand

imx8m: dts: Update ddr firmware name

2026-06-26T20:06:15Z

Update to latest ddr firmware name, otherwise user may use legacy ddr firmware from linux-firmware-imx release. Signed-off-by: Peng Fan

imx952: Update gpio node regs

2026-06-26T20:00:22Z

Same to 85319b2e672 ("board: toradex: smarc-imx95: remove gpio1 reg"), there is no need to use dual base for i.MX952 gpio, so drop the U-Boot specific reg changes. Signed-off-by: Peng Fan

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