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

arm64: Add late jump to kernel board hook

2025-02-15T13:44:43Z

Add empty weak assembler function armv8_switch_to_el2_prep() which is jumped to just before U-Boot determines which EL it is running in and decides which path to take to boot the Linux kernel. This weak function is meant to be used by architecture specific code to implement jump to a firmware blob, which then returns right past this weak function and continues execution of U-Boot code which then boots the Linux kernel. One example of such use case is when U-Boot jump tp TFA BL31, which switches from EL3 to EL2 and then returns to U-Boot code newly running in EL2 and starts the Linux kernel. The weak function is called with caches already disabled and DM shut down. Any preparatory work or even loading of more data must be done in board_prep_linux(), this hook is meant only for the final jump to the firmware and return to U-Boot before booting Linux. Reviewed-by: Tom Rini Signed-off-by: Marek Vasut

armv8: Add arch-specific sysinfo platform driver

2025-01-14T20:29:29Z

Add sysinfo platform driver for all armv8 platforms to retrieve hardware information on processor and cache. Signed-off-by: Raymond Mao Reviewed-by: Simon Glass

armv8: cpu: Implement allow_unaligned()

2024-11-17T19:13:22Z

Usually ARMv8 platforms allow unaligned access for Normal memory. But some chips might not allow it by default, having SCTLR.A bit set to 1 before U-Boot execution. One such example is Exynos850 SoC. As allow_unaligned() is not implemented for ARMv8 at the moment, its __weak implementation is used, which does nothing. That might lead to unaligned access abort, for example when running EFI selftest. Fix that by implementing allow_unaligned() for ARMv8. The issue was found when running EFI selftest on E850-96 board (Exynos850 based): => bootefi selftest $fdtcontroladdr ... Executing 'HII database protocols' "Synchronous Abort" handler, esr 0x96000021, far 0xbaac0991 ... resetting ... Unaligned abort happens in u16_strnlen(), which is called from efi_hii_sibt_string_ucs2_block_next(): u16_strlen(blk->string_text) where 'blk' type is struct efi_hii_sibt_string_ucs2_block. Because this struct is packed, doing "->string_text" makes 'blk' address incremented by 1 byte, which makes it unaligned. Although allow_unaligned() was called in efi_init_early() before EFI selftest execution, it wasn't implemented for ARMv8 CPUs, so data abort happened. Signed-off-by: Sam Protsenko

armv8: Fix get_sctlr() return type

2024-11-17T19:13:22Z

SCTLR_EL2 is a 64-bit register [1]. Return its value as long (64 bit) instead of int (32 bit) in get_sctlr() to make sure it's not trimmed. [1] https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/SCTLR-EL2--System-Control-Register--EL2-?lang=en Fixes: 0ae7653128c8 ("arm64: core support") Suggested-by: Heinrich Schuchardt Signed-off-by: Sam Protsenko Reviewed-by: Ilias Apalodimas

Merge patch series "Implement ACPI on aarch64"

2024-10-28T00:44:13Z

Patrick Rudolph says: Based on the existing work done by Simon Glass this series adds support for booting aarch64 devices using ACPI only. As first target QEMU SBSA support is added, which relies on ACPI only to boot an OS. As secondary target the Raspberry Pi4 was used, which is broadly available and allows easy testing of the proposed solution. The series is split into ACPI cleanups and code movements, adding Arm specific ACPI tables and finally SoC and mainboard related changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the mandatory ACPI tables are supported, allowing to boot into Linux without errors. The QEMU SBSA support is feature complete and provides the same functionality as the EDK2 implementation. The changes were tested on real hardware as well on QEMU v9.0: qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \ -pflash secure-world.rom \ -pflash unsecure-world.rom qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \ -smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \ -dtb bcm2711-rpi-4-b.dtb -nographic Tested against FWTS V24.03.00. Known issues: - The QEMU rpi4 support is currently limited as it doesn't emulate PCI, USB or ethernet devices! - The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly cache related). - PCI on RPI4 isn't working on real hardware since the pcie_brcmstb Linux kernel module doesn't support ACPI yet. Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com

armv8: cpu: Enable ACPI parking protocol

2024-10-27T23:24:13Z

Update the generic entry point code to support the ACPI parking protocol. The ACPI parking protocol can be used when PSCI is not available to bring up secondary CPU cores. When enabled secondary CPUs will enter U-Boot proper and spin in their own 4KiB reserved memory page, which also acts as mailbox with the OS to release the CPU. TEST: Boots all CPUs on qemu-system-aarch64 -machine raspi4b Signed-off-by: Patrick Rudolph Reviewed-by: Simon Glass

arm: cpu: Add ACPI parking protocol support

2024-10-27T23:24:13Z

On Arm platforms that use ACPI they cannot rely on the "spin-table" CPU bringup usually defined in the FDT. Thus implement the 'ACPI Multi-processor Startup for ARM Platforms', also referred to as 'ACPI parking protocol'. The ACPI parking protocol works similar to the spin-table mechanism, but the specification also covers lots of shortcomings of the spin-table implementations. Every CPU defined in the ACPI MADT table has it's own 4K page where the spinloop code and the OS mailbox resides. When selected the U-Boot board code must make sure that the secondary CPUs enter u-boot after relocation as well, so that they can enter the spinloop code residing in the ACPI parking protocol pages. The OS will then write to the mailbox and generate an IPI to release the CPUs from the spinloop code. For now it's only implemented on ARMv8, but can easily be extended to other platforms, like ARMv7. TEST: Boots all CPUs on qemu-system-aarch64 -machine raspi4b Signed-off-by: Patrick Rudolph Reviewed-by: Simon Glass Cc: Simon Glass Cc: Tom Rini

layerscape: use the lmb API's to add RAM memory

2024-10-15T19:45:29Z

The EFI memory allocations are now being done through the LMB module, and hence the memory map is maintained by the LMB module. Use the lmb_arch_add_memory() API function to add the usable RAM memory to the LMB's memory map. Signed-off-by: Sughosh Ganu

Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"

2024-10-11T18:23:25Z

Simon Glass says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit.

global: Rename SPL_TPL_ to PHASE_

2024-10-11T17:44:48Z

Use PHASE_ as the symbol to select a particular XPL build. This means that SPL_TPL_ is no-longer set. Update the comment in bootstage to refer to this symbol, instead of SPL_ Signed-off-by: Simon Glass