> -----Original Message----- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: Monday, November 16, 2015 11:11 AM > To: Vladimir Olovyannikov > Cc: Ard Biesheuvel; edk2-devel@lists.01.org > Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI > > On Mon, Nov 16, 2015 at 06:23:20PM +0000, Vladimir Olovyannikov wrote: > > > -----Original Message----- > > > From: Mark Rutland [mailto:mark.rutl...@arm.com] > > [...] > > > > What is the earliest point in EDK2 that you have unmasked SError? > > > > > > Are you doing this in PrePeiCoreEntryPoint.S, or later? > > Thanks for the pointers Mark. > > > > Async abort occurs in ArmWriteVBar() called by InitializeDebugAgent(), > DebugAgentSymbolsBaseLib.c. > > Interesting. > > Is the SError taken directly to EL2? I understood from your previous > reply that the EDK2 exception handler was invoked at this point, so is > there anything at EL3 which is trying to catch exceptions and then > re-inject them down to EL2? None that I would be aware of. > > The fact that we're clearly able to take the SError via the table > confuses me; it makes it sound like the table is fine. > > Is that exception taken via the old vector table, or the new one we're > trying to install with this write to VBAR_EL2? The exception is taken from the NEW vector table. > > > Prior to this call I can easily enable async aborts with no "bad" > consequences. > > > > Here is the exact instruction causing the SError in the ArmWriteVBar(): > > 2: msr vbar_el2, x0 // Set the Address of the EL2 Vector Table > > in the > VBAR register > > As SError is asynchronous, it's not necessarily the case that the write > to VBAR_EL2 is the trigger. > > I note that in ArmPkg/Library/ArmLib/AArch64/AArch64Support.S, there is > an ISB at the end of ArmWriteVBar(). That might happen to "flush" a > pending SError on the CPU and cause it to be taken. > > > Could it mean that I do not have enough privileges in the UEFI for this > operation? > > There are no traps or enables affecting VBAR_EL2. So long as EDK2 is > running at EL2 or higher it should be sufficiently privileged to read or > write VBAR_EL2.
I see. UEFI is running at EL2. > > > What would you advise? > > My hunch is that we have a pending SError that gets "flushed" by an ISB. > > You should be able to add ArmInstructionSynchronizationBarrier() calls > in the general vicinity of InitializeDebugAgent() (e.g. before the call > to ArmWriteVBar(), in the caller of InitializeDebugAgent(), before it > and the previous few functions are called). > > That may cause the SError to be taken closer to its trigger, and if so > it would be possible to bisect down to the trigger. Did that. Regardless of ArmInstructionSycnhronizationBarrier() and subsequent enabling of the async abort SError happens right in the ArmWriteVBar. Thank you, Vladimir _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
