> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, November 17, 2015 11:03 PM > To: Mark Rutland > Cc: Vladimir Olovyannikov; edk2-devel@lists.01.org > Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI > > On 17 November 2015 at 12:22, Mark Rutland <mark.rutl...@arm.com> > wrote: > [...] > >> Did that. Regardless of ArmInstructionSycnhronizationBarrier() and > subsequent enabling of the async abort > >> SError happens right in the ArmWriteVBar. > > > > Ok. > > > > Two theories: > > > > * When we take an exception, SError is masked. So perhaps we take > > another exception immediately after writing to VBAR_EL2, and that > > exception handler triggers the SError. I imagine that must be an > > asynchronous exception (i.e. one we can mask with DAIF). > > > > We should be able to see if that's the case if we change the > > ArmWriteVbar logic for EL2 to something like: > > > > mrs x1, daif > > msr daifset, #(0xb << 6) // D_IF masked After this instruction DAIF is 0x2C0 (bit A is not masked) > > mrs vbar_el2, x0 After msr vbar_el2, x0, isb+nop, and msr DAIFClr,#4 no SError - bit A was not masked. > > isb > > nop > > mrs daif, x1 > > nop > > > > If that is the case, I'd expect to take the SError immediately after > > the write back to daif. Mark, I tried this and made some other experiments with DAIF masked. It looks like the x0 address is not accepted by msr vbar_el2,x0. I tried to write vector in the very beginning, like this: mov x0, #0800 movk x0, #8500 lsl 16 msr vbar_el2, x0 isb nop and hit SError on the first msr DAIFClr,#4 I run UEFI from within the u-boot. Probably better would be just flash the UEFI and run UEFI only, and boot that way. Anyway when I setup vbar_el2 with u-boot exception vector address, at least no SError happens. If I setup u-boot vector with the UEFI vector address, it hits SError right away. (Boot into u-boot, load UEFI, then load u-boot and start execution with 0x85008800 vector address)
A side note: I got the u-boot source for that board and there are several hacks made to avoid SError (writing 0x20 to the HCR register (reroute SError to EL2), and just ERET from SError exception handler, and then write 0x0 to HCR before Linux boots), so it could be an HW issue I am not aware of as of yet. > > > > Ard, do we ever expect to take (non-fatal) synchronous exceptions? > > > > Never this early, since this version of the vector table is installed > very early, and deadloops on any exception that it takes. > > Only after CpuDxe is initialized, we can handle dispatch exceptions > and interrupts normally, but this is typically only used for the > timer interrupt. I could not find any invocations of > RegisterInterruptHandler() that installs a handler for synchronous > exceptions. > > > * As Ard originally suggested, the VBAR_EL2 address is close to some > > memory region we shouldn't speculatively fetch from, but for some > > reason do. > > > > Can you take a look at the new VBAR_EL2 value and your memory map, > and > > see if it's close to anything that shouldn't be fetched from? > > > > I'd still like to double check the value of VBAR_EL2 as it is written, > it should be a multiple of 2 KB It is always at 0x85008800 which is a multiple of 2K Any other things to verify? -- Thank you, Vladimir _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
