On Mon, Feb 7, 2022 at 5:24 PM Alexander Graf <agraf@csgraf.de
<mailto:agraf@csgraf.de>> wrote:
On 07.02.22 17:06, Philippe Mathieu-Daudé wrote:
> On 7/2/22 16:59, Alexander Graf wrote:
>>
>> On 07.02.22 16:52, Edgar E. Iglesias wrote:
>
>>> 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.
>>
>>
>> So nobody is using upstream QEMU to validate and prototype
>> ATF/EL1s/EL0s code? That's a shame :). I suppose there is little
>> value without the bitstream emulation and R cluster. Do you have
>> plans to bring multi process emulation upstream some day to enable
>> these there?
>
> The R cluster is already in mainstream, isn't it?
In that case, wouldn't it make sense to build an emulation model of the
PMU behavior so that normal ATF works out of the box?
Thanks,
Alex
Yes, that makes sense and there are several ways to implement it. To
fully support the programmability of the PMU we'd need to model the
MicroBlazes together with the ARM cores.
But PMU support does not really conflict with this patch series, or is
there something I'm missing?