Re: xlnx-zynqmp doesn't set psci-conduit on the R-cores

[Peter Maydell]

On Sat, 11 Jan 2020 at 21:36, Edgar E. Iglesias
<address@hidden> wrote:
> On Fri, 10 Jan. 2020, 08:42 Peter Maydell, <address@hidden> wrote:
>> Hi; somebody pointed out to me that hw/arm/xlnx-zynqmp.c only
>> sets the psci-conduit on the A-profile cores, not the R. This
>> means you can't set the boot-cpu to an R-profile core and
>> use PSCI to wake up the other one. Is the omission deliberate?
> I don't think this was given much thought.
>
> AFAIK, we don't have any r5 software that implements PSCI (should that be 
> done over svc? Hmm not sure if that's possible). The ATF port that runs on 
> the a53s only handles the A cores IIRC.
>
> I'll need to double check but in our sw stack the R5s are controlled via 
> EEMI, a SoC specific smc interface that runs on the PMU (MicroBlaze).
>
> Do you know how other SoCs with heterogeneous cores handle this?

I think usually in hardware they do some non-PSCI thing to
wake up other cores (and probably implement PSCI themselves
in the A-class firmware). PSCI itself doesn't really
contemplate the idea of heterogenous cores. But for QEMU's
xlnx-zynqmp model, every core except the 'boot_cpu' one
is started in the powered-off state so presumably the
only way to wake the other cores up is to use PSCI ?
Unlike the 'virt' board, there doesn't seem to be any
code to allow an "all CPUs start powered up and the
firmware handles putting the secondaries in a pen" approach,
and unlike the imx6 there's no model of a real-hardware
power controller whose implementation calls arm_set_cpu_on().

(The question came up because somebody was trying to do a
quick hack test-case of "start on an R core and wake the
A cores up later", but found they had to bodge several things
(including adding the psci-conduit on the R cores) to be able
to do this via PSCI. The use of the Xilinx board here is
mostly just because it's the only one we have which has
a separate R or M CPU as well as the main A-class cores.)

thanks
-- PMM