On Mon, Jun 16, 2014 at 9:11 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 16 June 2014 11:58, Andreas Färber <afaer...@suse.de> wrote: >> Well, for Cortex-A9 that may work. But Cortex-A15 (and Cortex-A5x if >> existant by now) should also be refactored alongside, as proof of >> concept - can you really create num_cpu cortex-a15 CPUs on the MPCore >> for a big.LITTLE configuration? I'd be really surprised if there were >> separate MPCore devices per cluster. That would then indicate that the >> homogeneity assumption among CPUs within an MPCore is wrong and we need >> to let its parent create the CPUs rather than an MPCore property. > > Not sure what the relevance of big.LITTLE is here -- QEMU > simply doesn't support heterogenous CPU configurations so > we can't model big.LITTLE at all. If we did, it would be > via having a SoC with one a15mpcore and one a7mpcore. > (This is how the hardware does it -- there are two > multicore clusters, plus some cache coherency interconnect > magic.) > >> Besides, not all CPUs have an MPCore, Cortex-A8 and Cortex-A5 come to >> mind, so we should be aware that ARMCPU child<>s on the MPCore will lead >> to asymmetry between SoCs. > > For the A8 and A5 the SoC object would just instantiate them > directly -- there's no equivalent in the hardware of the > "n CPUs and their private devices" layer. So I think > any asymmetry between SoCs in QEMU is just a reflection > of the differences in the hardware. >
+1. Either you have an MPCore package as part of your soc or standalone CPU. Both are valid instantiables on the SoC level. Regards, Peter > thanks > -- PMM >
