On 07.02.22 16:22, Peter Maydell wrote:
> On Mon, 7 Feb 2022 at 14:21, Alexander Graf <agraf@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.maydell@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:
> 20220203140141.310870-1-edgar.iglesias@gmail.com/"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://patchew.org/QEMU/20220203140141.310870-1-edgar.iglesias@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.