On Sat, 11 Jan 2020 at 21:36, Edgar E. Iglesias <edgar.igles...@gmail.com> wrote: > On Fri, 10 Jan. 2020, 08:42 Peter Maydell, <peter.mayd...@linaro.org> 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
