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

Merge tag 'v2026.07-rc3' into next

2026-05-25T17:35:35+00:00

Prepare v2026.07-rc3

arm: armv8: mmu: move mmu enablement out of mmu_setup

2026-05-25T15:29:50+00:00

Currently mmu_setup for ARMv8 performs two functions, first it sets up
the page tables based the memory map provided by the board and then it
enables the MMU.

However for some platforms runtime fixes to the generated page tables
are required before the MMU can be enabled, such as K3 family of SoCs.

Therefore this patch moves the enablement of the MMU out of mmu_setup
and to a standalone mmu_enable function to give more granular control to
the platforms.

Note that no functional changes are intended from this patch.

Reviewed-by: Ilias Apalodimas 
Signed-off-by: Anshul Dalal

imx9: Add support for saving DDR training data to NVM

2026-05-15T20:31:39+00:00

DDR training data can be saved to NVM and be available
to OEI at boot time, which will trigger QuickBoot flow.

U-Boot only checks for data integrity (CRC32), while
OEI is in charge of authentication when it tries to
load the data from NVM.

On iMX95 A0/A1, 'authentication' is done via another
CRC32. On the other SoCs, authentication is done by
using ELE to check the MAC stored in the ddrphy_qb_state
structure.

Supported platforms: iMX94, iMX95, iMX952 (using OEI)
Supported storage types: eMMC, SD, SPI flash.

Signed-off-by: Viorel Suman 
Signed-off-by: Ye Li 
Signed-off-by: Simona Toaca

imx: ahab: Use authenticated header for images loading

2026-05-15T20:31:39+00:00

When loading container image, the container header is loaded into
heap memory. If ahab is enabled, the header is be copied to another
fixed RAM for authentication in ahab_auth_cntr_hdr. The better method
is using container header memory being authenticated for following
image loading.
So update ahab_auth_cntr_hdr to return the address of container header
being authenticated. Caller uses this header for following parsing
and image loading.

Signed-off-by: Ye Li 
Reviewed-by: Peng Fan

imx9: scmi: Support iMX95/94/952 secondary boot

2026-05-15T20:31:39+00:00

When ROM boots from secondary container set, SPL should select
correct offset to load u-boot-atf container.
The implementation uses ROM passover information:
1) For non-eMMC boot partition device, use image offset in ROM
   passover data to get u-boot-atf container offset.
2) For eMMC boot partition device, use boot stage (secondary)
   in ROM passover data to select correct eMMC boot partition
   for u-boot-atf container.

Signed-off-by: Ye Li 
Reviewed-by: Peng Fan

imx: Add SPI NOR A/B switching support

2026-05-15T20:31:39+00:00

Query the SM via SCMI, obtain rom_passover_t->img_set_sel and based on
that, add 0 or 0x400000 offset (A or B copy offset) to boot container
read address.

Signed-off-by: Marek Vasut 
Signed-off-by: Fedor Ross

arm: gpio: include integer type definitions for gpio.h

2026-05-06T08:04:48+00:00

Both consumers and sub-arch specific versions of gpio.h
may reference stdint or other non-C90 type definitions.

Ensure the common ones are available by including linux/types.h
before any other headers.

This issue came to light when the usb onboard hub driver
was enabled for ten64_tfa_defconfig:

In file included from ./arch/arm/include/asm/gpio.h:2,
		 from common/usb_onboard_hub.c:10:
./arch/arm/include/asm/arch/gpio.h:17:9: error: unknown type name 'ulong'
   17 |         ulong addr;
./arch/arm/include/asm/arch/gpio.h:18:9: error: unknown type name 'ulong'
   18 |         ulong size;
./arch/arm/include/asm/arch/gpio.h:19:9: error: unknown type name 'uint'
   19 |         uint ngpios;

(In this instance, the cited errors actually originate from
arch/arm/include/asm/arch-fsl-layerscape/gpio.h, which is included
by the arm top level asm/gpio.h)

Implemented as per suggestion from Quentin Schulz in Link:

Signed-off-by: Mathew McBride 
Link: https://lore.kernel.org/u-boot/35038a9a-fa5a-4f9f-b34e-17cc80a7824c@cherry.de/
Signed-off-by: Peng Fan

arm: psci: Add API to check for support of specific PSCI function

2026-04-27T10:38:44+00:00

Add an API to check if a specific PSCI function is supported or not.
This is based on the psci_features() function present in Linux kernel
(drivers/firmware/psci/psci.c).

Reviewed-by: Casey Connolly 
Reviewed-by: Sumit Garg 
Signed-off-by: Varadarajan Narayanan 
Link: https://patch.msgid.link/20260121063920.1500293-2-varadarajan.narayanan@oss.qualcomm.com
Signed-off-by: Casey Connolly

arm: Add ARMv8-M aarch32 support

2026-04-13T23:34:02+00:00

Add configuration for ARMv8-M aarch32 core, which are currently
Cortex-M23/M33 cores. These cores are treated similar to ARMv7-M
cores, except the code has to be compiled with matching compiler
-march=armv8-m.main flag . These cores have no MMU, they have MPU,
which is currently not configured.

Unlike ARMv7-M, these cores have 512 interrupt vectors. While the
SYS_ARM_ARCH should be set to 8, it is set to 7 because all of the
initialization code is built from arch/arm/cpu/armv7m and not armv8.
Furthermore, CONFIG_ARM64 must be disabled, although DTs for devices
using these cores do come from arch/arm64/boot/dts.

To avoid excess duplication in Makefiles, introduce one new Kconfig
symbol, CPU_V7M_V8M. The CPU_V7M_V8M cover both ARMv7-M and ARMv8-M
cores.

Signed-off-by: Marek Vasut 
Acked-by: Udit Kumar

arm: mach-sc5xx: Align header paths with SYS_SOC convention

2026-04-07T17:32:59+00:00

Define CONFIG_SYS_SOC in the mach-sc5xx Kconfig. Follow the standard
U-Boot include path convention by moving the SC5xx SoC headers from
arch/arm/include/asm/arch-adi/sc5xx/ to the conventional
arch/arm/include/asm/arch-sc5xx/ location. Update includes from
 to  across mach-sc5xx and board
files.

Signed-off-by: Philip Molloy