On Fri, Nov 13, 2015 at 10:39:34PM +0000, Vladimir Olovyannikov wrote: > > > > -----Original Message----- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: Friday, November 13, 2015 3:00 AM > > To: Vladimir Olovyannikov > > Cc: edk2-devel@lists.01.org > > Subject: Re: Armv8 64bit: System error booting linux from the UEFI > > > (removed extra text) > > > >> This is a firmware problem, not a kernel problem. The kernel is > > >> entered with an pending asynchronous external abort, which may have > > >> several causes. You need to instrument the firmware (i.e., unmask the > > >> aborts earlier and run in the debugger) to get a feeling for what is > > >> going on there. It could be something like speculative accesses to > > >> unassigned physical ranges that are mapped cacheable inadvertently, > > >> but it could be lots of other things as well. > > > > > > > > > > FYI http://article.gmane.org/gmane.comp.bios.edk2.devel/4246 > > > > This fixes a bug that could potentially result in speculative reads to > > device regions. We have also made some other changes regarding > > cacheability and shareability recently (and the patch above will > > likely go in today) so it is probably worthwhile to make sure you are > > based on the latest upstream. > > Thank you Ard, I got the latest upstream. Same issue... It is not related to > the cache. > > I investigated and found that as soon as I do > msr DAIFClr, #4 (or call ArmEnableAsynchronousAbort()) anywhere in the UEFI, > I immediately get this exception.
This implies that either code very early in EDK2, or code prior to EDK2 is the problem, given that when masked, SError will pend until it is unmasked (whereupon it should be taken). What is the earliest point in EDK2 that you have unmasked SError? Are you doing this in PrePeiCoreEntryPoint.S, or later? > The boot sequence is BL2->BL3.1->UEFI (plus grub.efi app)->Linux I take it per the naming that you are running ARM Trusted Firmware. Are you able to unmask SError during BL2 or BL3.1, and if so, does it fire prior to entering EDK2? [...] > UEFI is running in EL2. > Maybe I am missing some initialization in the UEFI and that is the reason any > msr DAIFClr,#4 causes this SError exception? It is possible that some initialisation is missing at an early stage in the boot sequence, and that this contributes ot the SError. As an asynchronous exception, SError pends until it is unmasked, and should trigger as soon as it is unmasked. The DAIFClr itself is vanishingly unlikely to be the root cause of the SError, but rather makes it apparent. The earlier you are able to unmask SError, the closer you will be able to get to the root cause. Are you able to capture it were it earlier in the boot sequence (e.g. can you register a handler earlier, or capture the exception with a hardware debugger)? Thanks, Mark. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
