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!

-- 
Tom