On 26/01/2020 02:28, Matthias Brugger wrote: > On 24/01/2020 01:26, André Przywara wrote:
[ ... ] >> Found the culprit, after following a lead started by an over-lunch >> discussion: Colleagues pointed out the SError (interrupts) early in the >> kernel could just show because they just got unmasked when dropping into >> EL1. And indeed in AArch64 U-Boot we keep Aborts masked - we don't clear >> the A bit in DAIF normally (only for Freescale). >> So allowing SError exceptions in U-Boot's start.S revealed that the >> SError interrupt was actually triggered by the writel in write_hwaddr(), >> I guess because the MAC wasn't reset before. And the SError condition >> stayed pending all the time, until the kernel announced its interest in >> being told about fatal errors - then it inherited U-Boot's error. > > Thanks for the explanation. I think the situation leaves space for improving. > Either should we warn about a pending Abort before leaving U-Boot or we should > allow aborts in general. Definitively we should unmasks SErrors in U-Boot, since they point us to serious problems, with this one here actually being somewhat on the harmless side. Also U-Boot has exception handlers that dump useful information, so we should use them. But doing so would need to be done for all ARMv8 ports (in start.S), so I am a bit reluctant to post something this late in the merge window without proper testing on multiple platforms. >> So for me the issue is fixed after adding the reset routine I sketched >> in that thread before. >> >> But you mentioned that it still didn't work for you? >> > > I just double checked and everything works fine. Please feel free to send a > new > version :) Great, thanks! Did just that. Cheers, Andre