u-boot.git/arch/arm/cpu, branch v2025.07

arm: armv7: restore section to .text after saved_args

2025-06-09T15:18:17Z

when CONFIG_BLOBLIST is enabled, the section is switched to .data but is not switched back to .text. It makes all the code below placed in .data section, also breaks CONFIG_POSITION_INDEPENDENT. Fix it by adding `.section .text` to switch the section back to .text. Fixes: 5103e69344d6 ("arm: armv7: save boot arguments") Signed-off-by: Yang Xiwen

sunxi: armv8: FEL: save and restore SP_IRQ

2025-04-28T18:45:44Z

Thanks for Jernej's JTAG debugging effort, it turns out that the BROM expects SP_IRQ to be saved and restored, when we want to enter back into FEL after the SPL's AArch64 stint. Save and restore SP_IRQ as part of the FEL state handling. The banked MRS/MSR access to SP_IRQ, without actually being in IRQ mode, was introduced with the ARMv7 virtualisation extensions. The Arm Cortex-A8 cores used in the A10/A13s or older F1C100s SoCs would not support that, but this code here is purely in the ARMv8/AArch64 code path, so it's safe to use unconditionally. Reported-by: Jernej Skrabec Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec

sunxi: armv8: FEL: save and restore GICv3 registers

2025-04-28T18:45:44Z

To be able to return to the BootROM FEL USB debug code, we must restore the core's state as accurately as possible after the SPL has been run. Since the BootROM runs in AArch32, but the SPL uses AArch64, this requires a core reset, which clears the core's state. So far we were saving and restoring the required registers like SCTLR and VBAR, but could ignore the interrupt controller's state (GICC), since that lives in MMIO registers, unaffected by a core reset. Newer Allwinner SoCs now feature a GICv3 interrupt controller, which keeps some GIC state in architected system registers, and those are cleared when we switch back to AArch32. To enable FEL operation on the Allwinner A523 SoC, Add AArch32 assembly code to save and restore the ICC_PMR and ICC_IGRPEN1 system registers. The other GICv3 sysregs are either not relevant for the BROM operation, or haven't been changed from their reset defaults by the BROM anyway. This enables FEL operation on the Allwinner A523 family of SoCs. Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec

spin_table: add missing header for ENODEV and ENOSPC symbols

2025-04-15T17:55:17Z

Add the necessary header as is removed Signed-off-by: yan wang

Merge patch series "Switch to using $(PHASE_) in Makefiles"

2025-04-11T18:16:49Z

Tom Rini says: This series switches to always using $(PHASE_) in Makefiles when building rather than $(PHASE_) or $(XPL_). It also starts on documenting this part of the build, but as a follow-up we need to rename doc/develop/spl.rst and expand on explaining things a bit. Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com

Kbuild: Always use $(PHASE_)

2025-04-11T18:16:44Z

It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini

armv8: start.S: Subordinate CPUs psci setup vector

2025-04-11T02:55:39Z

As current design, only Manager CPU called armv8_setup_psci() before jump to next stage(such as Linux Kernel), Subordinate CPUs also need setup psci vector to handle trap request which comes from higher EL level. Signed-off-by: Xu Zhang <423756212@qq.com> [trini: Guard with !CONFIG_XPL_BUILD check]

arm64: Fix page permissions for platforms running at EL2

2025-04-04T18:24:56Z

We currently set both and print both PXN and UXN bits when removing execution for pages. This happens even in the existing per platform definitions of 'struct mm_region'. That's not entirely correct though. For stage-1 translations, if a platform runs on a translation regime with a single privilege level or the the translation regime supports two privilege levels and we are not in EL1&0 with HCR_EL2.{NV, NV1} = {1, 1} only BIT54 (XN) is needed and BIT53(PXN) is reserved 0. Currently we support Non-Secure EL2, Non-secure EL2&0 and Non-secure EL1&0. We already have get_effective_el() which returns 1 if we are - Running in EL1 so we assume an EL1 translation regime but without checking HCR_EL2.{NV, NV1} != {1,1} - Running in EL2 with HCR_EL2.E2H = 1 The only problem with the above is that if we are in EL1&0 and HCR_EL2.{NV1, NV} == {1, 1}, then - Bit[54] holds the PXN instead of the UXN - The Effective value of UXN is 0 - Bit[53] is RES0 So let's re-use that function and set PXN only when we are in and EL[2|1]&0 translation regime. Signed-off-by: Ilias Apalodimas

Merge patch series "Various toolchain compatibility fixes/improvements"

2025-04-02T20:34:08Z

Sam Edwards says: This is v2 of my "misc. fixes" series, sent to prepare the codebase for more direct LLVM support in the near future. This series contains several fixes that I found in the process of preparing that support and which address issues independent of any future feature or enhancement. I am sending these now, both so that their inclusion is not delayed by discussion on my upcoming series and to make the latter more manageable. Link: https://lore.kernel.org/r/20250315221813.1265193-1-CFSworks@gmail.com

arm: Discard unwanted sections in linker script

2025-04-02T20:33:50Z

There are a handful of sections that are not useful in the U-Boot output binary. At present, the linker script moves these to the end of the binary, after the _image_binary_end marker symbol, so that they don't get loaded. The linker script syntax supports discarding sections that shouldn't be included in the output. Switch to this instead, to make the intention clearer and reduce the ELF sections that have to be handled later in the build. This is also consistent with the other architectures' linker scripts. Signed-off-by: Sam Edwards Reviewed-by: Ilias Apalodimas