On Mon, Feb 7, 2022 at 4:33 PM Alexander Graf <ag...@csgraf.de> wrote:
> > On 07.02.22 16:22, Peter Maydell wrote: > > On Mon, 7 Feb 2022 at 14:21, Alexander Graf <ag...@csgraf.de> wrote: > >> > >> On 27.01.22 16:46, Peter Maydell wrote: > >>> Change the Xilinx ZynqMP-based board xlnx-zcu102 to use the new > >>> boot.c functionality to allow us to enable psci-conduit only if > >>> the guest is being booted in EL1 or EL2, so that if the user runs > >>> guest EL3 firmware code our PSCI emulation doesn't get in its > >>> way. > >>> > >>> To do this we stop setting the psci-conduit property on the CPU > >>> objects in the SoC code, and instead set the psci_conduit field in > >>> the arm_boot_info struct to tell the common boot loader code that > >>> we'd like PSCI if the guest is starting at an EL that it makes > >>> sense with. > >>> > >>> Note that this means that EL3 guest code will have no way > >>> to power on secondary cores, because we don't model any > >>> kind of power controller that does that on this SoC. > >>> > >>> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> > >> > >> It's been a while since I worked with ZynqMP, but typically your ATF in > >> EL3 will want to talk to a microblaze firmware blob on the PMU. > >> > >> I only see a stand alone PMU machine for microblaze and a PMU IRQ > >> handling I/O block in QEMU, but nothing that would listen to the events. > >> So I'm fairly sure it will be broken after this patch - and really only > >> worked by accident before. > > Edgar submitted a power-control model patchset: > > > https://patchew.org/QEMU/20220203140141.310870-1-edgar.igles...@gmail.com/ > > > Ah, nice. Would this also work for Versal? > > > Thanks, > > Alex > Hi, Both Versal and ZynqMP require MicroBlaze firmware to run the reference implementations of Trusted Firmware. We never supported this in upstream QEMU but we do support it with our fork (by running multiple QEMU instances co-simulating). Having said that, we do have tons of EL3 test-cases that we use to validate QEMU that run with EL3 enabled in upstream. So there's two user flows: 1. Direct boots using QEMUs builtin PSCI (Most users use this to run Linux, Xen, U-boot, etc) 2. Firmware boot at EL3 without QEMUs builtin PSCI (Mostly used by test-code) Number #2 is the one affected here and that by accident used to have the builtin PSCI support enabled but now requires more power control modelling to keep working. Unless I'm missing something, the -kernel boots will continue to use the builtin PSCI implementation. Cheers, Edgar
