On Fri, Feb 11, 2022 at 11:29:35AM +0000, Andre Przywara wrote:
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 nm@ti.com Signed-off-by: Andre Przywara andre.przywara@arm.com
Applied to u-boot/next, thanks!