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 <[email protected]> > Signed-off-by: Andre Przywara <[email protected]>
Applied to u-boot/next, thanks! -- Tom
signature.asc
Description: PGP signature
