On Mon, 19 Nov 2018 at 11:24, Leif Lindholm <leif.lindh...@linaro.org> wrote: > > > On Mon, Nov 19, 2018 at 11:16:09AM -0800, Ard Biesheuvel wrote: > > On Mon, 19 Nov 2018 at 11:10, Leif Lindholm <leif.lindh...@linaro.org> > > wrote: > > > > > > On Fri, Nov 16, 2018 at 05:29:05PM -0800, Ard Biesheuvel wrote: > > > > On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel > > > > <ard.biesheu...@linaro.org> wrote: > > > > > > > > > > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg > > > > > that are not based on the device tree received from QEMU. > > > > > > > > > > For ArmVirtQemu, this does not really matter, given that the NOR > > > > > flash banks are always the same: the PEI code is linked to execute > > > > > in place from flash bank #0, and the fixed varstore PCDs refer to > > > > > flash bank #1 directly. > > > > > > > > > > However, ArmVirtQemuKernel can execute at any offset, and flash bank > > > > > > > > #0 is configured as secure-only when running with support for EL3 > > > > enabled. > > > > > > Never gets old :) > > > > No this is entirely reasonable: it makes perfect sense for a NOR flash > > at address 0x0 to be secure only on a system that implements EL3, > > since mach-virt's default reset vector is 0x0. > > *cough* sorry, I was referring to the leading #. >
Ah yes :-) Been caught by that a couple of times already. > > > > > In this case, NorFlashQemuLib should not expose the first flash bank > > > > > at all. > > > > > > > > > > To prevent introducing too much internal knowledge about which flash > > > > > bank is accessible under which circumstances, let's switch to using > > > > > the DTB to decide which flash banks to expose to the NOR flash driver. > > > > > > Does this mean we as a side effect get rid of the limitation that the > > > pflash image needs to be exactly 64MB. Or does that require further > > > changes on the QEMU side? > > > > No that is a QEMU thing. > > OK, thanks for confirming. > But this should mean that we don't need any changes on the guest sides > if/when we do fix this in QEMU? > This would indeed get rid of any discrepancies between what QEMU exposes and what the firmware assumes, so yes, it's an improvement in that sense. However, I don't think the QEMU side of this is likely to change any time soon. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
