u-boot.git/arch/arm/include/asm/system.h, branch v2022.07

armv8: Always unmask SErrors

2022-03-02T18:59:29Z

The ARMv8 architecture describes the "SError interrupt" as the fourth kind of exception, next to synchronous exceptions, IRQs, and FIQs. Those SErrors signal exceptional conditions from which the system might not easily recover, and are normally generated by the interconnect as a response to some bus error. A typical situation is access to a non-existing memory address or device, but it might be deliberately triggered by a device as well. The SError interrupt replaces the Armv7 asynchronous abort. Trusted Firmware enters U-Boot (BL33) typically with SErrors masked, and we never enable them. However any SError condition still triggers the SError interrupt, and this condition stays pending, it just won't be handled. If now later on the Linux kernel unmasks the "A" bit in PState, it will immediately take the exception, leading to a kernel crash. This leaves many people scratching their head about the reason for this, and leads to long debug sessions, possibly looking at the wrong places (the kernel, but not U-Boot). To avoid the situation, just unmask SErrors early in the ARMv8 boot process, so that the U-Boot exception handlers reports them in a timely manner. As SErrors are typically asynchronous, the register dump does not need to point at the actual culprit, but it should happen very shortly after the condition. For those exceptions to be taken, we also need to route them to EL2, if U-Boot is running in this exception level. This removes the respective code snippet from the Freescale lowlevel routine, as this is now handled in generic ARMv8 code. Reported-by: Nishanth Menon Signed-off-by: Andre Przywara

Revert most of the series for adding vexpress_aemv8r support

2021-09-03T14:42:15Z

Per a request from Andre Przywara and agreed with by Peter Hoyes, the vexpress aemv8r support wasn't quite ready to be merged, but the discussion had moved off list. We should keep the first patch in the series for now, but revert the rest. This reverts the following commits: e0bd6f31ce41 doc: Add documentation for the Arm vexpress board configs 30e5a449e8c7 arm: Use armv8_switch_to_el1 env to switch to EL1 b53bbca63bf4 vexpress64: Add BASER_FVP vexpress board variant 2f5b7b74903f armv8: Add ARMv8 MPU configuration logic 37a757e227cc armv8: Ensure EL1&0 VMSA is enabled Signed-off-by: Tom Rini

psci: fix double declaration

2021-09-02T15:19:58Z

The prototype of psci_features() duplicated. Remove extra declaration. Fixed: e21e3ffdd1 ("psci: Fix warnings when compiling with W=1") Reported-by: Michael Scott Signed-off-by: Oleksandr Suvorov

armv8: Ensure EL1&0 VMSA is enabled

2021-09-02T14:17:45Z

On Armv8-R, the EL1&0 memory system architecture is configurable as a VMSA or PMSA, and resets to an "architecturally unknown" value. Add code to armv8_switch_to_el1_m which detects whether the MSA at EL1&0 is configurable using the id_aa64mmfr0_el1 register MSA fields. If it is we must ensure the VMSA is enabled so that a rich OS can boot. The MSA and MSA_FRAC fields are described in the Armv8-R architecture profile supplement (section G1.3.7): https://developer.arm.com/documentation/ddi0600/latest/ Signed-off-by: Peter Hoyes

armv8: Disable pointer authentication traps for EL1

2021-09-02T14:17:45Z

The use of ARMv8.3 pointer authentication (PAuth) is governed by fields in HCR_EL2, which trigger a 'trap to EL2' if not enabled. The reset value of these fields is 'architecturally unknown' so we must ensure that the fields are enabled (to disable the traps) if we are entering the kernel at EL1. The APK field disables PAuth instruction traps and the API field disables PAuth register traps Add code to disable the traps in armv8_switch_to_el1_m. Prior to doing so, it checks fields in the ID_AA64ISAR1_EL1 register to ensure pointer authentication is supported by the hardware. The runtime checks require a second temporary register, so add this to the EL1 transition macro signature and update 2 call sites. Signed-off-by: Peter Hoyes

armv8: Initialize CNTFRQ if at highest exception level

2021-07-23T22:53:46Z

CNTFRQ_EL0 is only writable from the highest supported exception level on the platform. For Armv8-A, this is typically EL3, but technically EL2 and EL3 are optional so it may need to be initialized at EL2 or EL1. For Armv8-R, the highest exception level is always EL2. This patch moves the initialization outside of the switch_el block and uses a new macro branch_if_not_highest_el which dynamically detects whether it is at the highest supported exception level. Linux's docs state that CNTFRQ_EL0 should be initialized by the bootloader. If not set, the the U-Boot prompt countdown hangs. Signed-off-by: Peter Hoyes

arm: remove set_dacr/get_dacr functions

2021-03-02T20:53:37Z

Remove the unused function set_dacr/get_dacr Serie-cc: Ard Biesheuvel Serie-cc: R Sricharan Signed-off-by: Patrick Delaunay

arm: cosmetic: align TTB_SECT define value

2021-03-02T20:53:37Z

Align TTB_SECT define value with previous value. Signed-off-by: Patrick Delaunay

arm: remove TTB_SECT_XN_MASK in DCACHE_WRITETHROUGH

2021-03-02T20:53:37Z

The normal memory (other that DCACHE_OFF) should be executable by default, only the device memory (DCACHE_OFF) used for peripheral access should have the bit execute never (TTB_SECT_XN_MASK). Signed-off-by: Patrick Delaunay

common: board_r: Drop initr_noncached wrapper

2021-01-15T19:36:12Z

Add a return value to noncached_init and use it directly in the post-relocation init sequence, rather than using a wrapper stub. Signed-off-by: Ovidiu Panait Reviewed-by: Simon Glass