> -----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. Here is slightly modified efi_entry.S (immediately on ENTRY): ENTRY(efi_stub_entry) 0x995a440 msr DAIFClr, #4 <-- crashes here right away /* * Create a stack frame to save FP/LR with extra space * for image_addr variable passed to efi_entry(). */ 0x995a444 stp x29, x30, [sp, #-32]! ... So for me just performing this instruction causes SError immediately. Here is the excerpt from the UEFI exception handler on this command: SError Exception at 0x00000000A995A444 X0 0x00000000BEDB8798 X1 0x00000000BEFE0018 X2 0x00000000A995A440 X3 0x00000000000000B0 X4 0x00000000BEDB8598 X5 0x00000000BF4BDE8C X6 0x000000000000005C X7 0x0000000000000000 X8 0x00000000B986DF9C X9 0x00000000B9F80000 X10 0x000000000000FFFF X11 0x00000000FFFFD800 X12 0x00000000FFFFDC00 X13 0x000000000000200C X14 0x0000000000000003 X15 0x000000000000001D X16 0x00000000BFFFF5B0 X17 0x0A880C885C60448A X18 0x000000000A880C88 X19 0x00000000BF4D0780 X20 0x00000000000000B8 X21 0x00000000B986DF9B X22 0x00000000BE31A040 X23 0x00000000B98E727A X24 0x00000000B98E7274 X25 0x00000000B998D7A4 X26 0x0000000000000000 X27 0x0000000000000000 X28 0x0000000000000000 FP 0x00000000BFFFF630 LR 0x00000000BF4A36C0 ... SP 0x00000000BFFFF5B0 ELR 0x00000000A995A444 SPSR 0x60000209 FPSR 0x00000000 ESR 0xBF000000 FAR 0x0000000000000000 ESR : EC 0x2F IL 0x1 ISS 0x01000000 ASSERT /uefi/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(186): ((BOOLEAN)(0==1)) The boot sequence is BL2->BL3.1->UEFI (plus grub.efi app)->Linux 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? Thank you, Vladimir _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel