u-boot.git/arch/arm/include/asm, branch master

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

ram: aspeed: add SDRAM controller driver for AST2700

2026-06-29T19:43:21Z

Add a SDRAM controller driver for the AST2700, derived from the existing AST2700 controller code used by the Ibex SPL but adapted to run from ARM U-Boot proper on the Cortex-A35 cores. The DDR4/DDR5 controller and its DesignWare PHY are programmed by the Ibex SPL before ARM U-Boot proper takes over. This driver reads back the configuration left by the SPL, probes the controller, and exposes ram_info (base and size, with the VGA carve-out subtracted) via UCLASS_RAM so that dram_init() can populate gd->ram_size. The PHY firmware-load entry points (dwc_ddrphy_phyinit_userCustom_*) are kept compiled but call a __weak fmc_hdr_get_prebuilt() stub when ARM U-Boot proper is the caller; the real implementation is provided by the Ibex SPL via the same fmc_hdr.h descriptor format (here added for the ARM build). Adds the supporting register-layout headers under arch/arm/include/asm/arch-aspeed/: - sdram.h: SDRAM controller and DWC PHY register definitions - scu.h: SCU bits referenced by the SDRAM driver - fmc_hdr.h: prebuilt-blob descriptor (binary-compatible with arch/riscv/include/asm/arch-ast2700/fmc_hdr.h used by the Ibex SPL) Signed-off-by: Ryan Chen

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

misc: ele_api: Add V2X Get State API

2026-06-27T02:02:46Z

Add V2X Get State API to return V2X states for debug purpose Signed-off-by: Ye Li

imx6: clock: allow different clock sources for ldb

2026-06-27T02:02:46Z

The LDB clock sources don't have to be the same, so allow DI1 clock to be configured separately. Unlikely to be significant, but the reason will become apparent in the following commit. Signed-off-by: Brian Ruley

Merge tag 'v2026.07-rc5' into next

2026-06-22T22:42:41Z

Prepare v2026.07-rc5

Merge patch series "armv8: mmu: fix region unmapping and optimise set_one_region()"

2026-06-17T15:55:31Z

Casey Connolly says: Currently trying to unmap a region results in slow and largely broken behaviour as we unnecessarily split blocks and manually set thousands of individual 4k pages instead of higher level blocks. This series fixes the behaviour of set_one_region() so that it works properly when called to unmap regions. See patch 4 for details. Patches 1 & 2 improve the existing debug functionality, the pagetable dumper will now print most explicitly unmapped regions (since they still have their PA intact), as well as adding a new function which does a very basic software TLB lookup to help with debugging. Patch 3 de-duplicates some code by moving the loop that always surrounds set_one_region() calls into its own function, this also helps with readability in the calling functions. Link: https://lore.kernel.org/r/20260608-b4-mmu-unmap-fixes-v6-0-ac0764cccf40@linaro.org

armv8: mmu: add a function to help debug TLB lookups

2026-06-17T15:55:00Z

Implement a super basic software TLB walk which can look up a single address in the TLB and print each stage of the translation. This is helpful for debugging TLB issues and will be compiled out if unused. Example output on QEMU aarch64: Performing software TLB lookup of address 0x50100000 va_bits: 40 PTE: 0x47fe0000. addr[47:39]: 0x000 (offset 0x00000) L0: 0x47fe0000 -> TABLE (0x47fe1000) PTE: 0x47fe1000. addr[38:30]: 0x001 (offset 0x00008) L1: 0x47fe1008 -> BLOCK (0x40000000) [0x40000000 - 0x80000000] Reviewed-by: Ilias Apalodimas Signed-off-by: Casey Connolly

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

board: variscite: add support for the omap4_var_som

2026-06-17T15:50:36Z

OMAP4 support is present but there isn't any board using it. Add minimal support for the Variscite OMAP4-SoM (debug console + boot from SD card). Use the ti/omap/omap4-var-stk-om44 device-tree from the Linux kernel. The real representation of the SoM's hardware is located in ti/omap/omap4-var-som-om44.dtsi included in it. Set myself as maintainer for it. Signed-off-by: Bastien Curutchet