On 19 November 2015 at 05:48, Vladimir Olovyannikov <volov...@broadcom.com> wrote: > > >> -----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.
OK, that would explain it. Note that the kernel will replace the EL2 vector table if booted at EL2, so this is definitely not a workaround that you would want to reuse in UEFI. >> > >> > 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? > No, that looks fine. You need to get in touch with the authors of the U-Boot code to figure out what it is they are working around. Simply ignoring SErrors is obviously not a long term solution. -- Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
