Re: [Qemu-devel] [RFC 0/2] target-arm: Adding Cortex-R4F support

[Peter Maydell]

On 2 October 2011 19:56, Andreas Färber <address@hidden> wrote:
> I've been looking into adding support for Cortex-R4F.

Ooh, that will be the first R profile core. In particular the only
other non-M-profile PMSA core we support is the 946 which was a v5
core, so you'll need to check that we actually implement v7 PMSA.
(The M3 support means we probably have the functionality, but not
the cp15 interface for obvious reasons.)

> 1) Currently, -cpu is used to look up a Main ID Register value and to base
> feature decisions on that. This doesn't work for Cortex-R4 and Cortex-R4F,
> which have an identical MIDR but only -R4F has the FPU.
> Re-checking the model string, while ugly, does the trick. Comments?

That is indeed kind of ugly. I think if CPUID value isn't a unique value
for the things we pass to -cpu then we shouldn't treat it as one. More
generally, it would be nice to be able to say "I want a Cortex-A9
but I only want the no-neon VFPv3D16 variant". (I think some of the
other targets already have syntax for this.)

Currently the approach is to say "you only get one variant of the
processor, and it's the one with all the bells and whistles enabled".
That would imply that '-cpu cortex-r4' gives you one with an FPU.
If we're going to move away from that model we should do it for
all cores.

> 2) The R4/R4F TRM says "It implements the ARMv7R architecture, and includes
> Thumb-2 technology" - how to incur the pre-v7 feature bits in addition to
> the easy _V7 and _THUMB2? I.e. where is it documented (in ARMv7-A/R TRM?)
> whether or not this should include _V4T, _V6K, etc.?
> If V7 were to always imply the same set of features, I would expect it
> alongside VAPA. (Could use some comments either way.)

The feature switches in qemu generally line up with architectural
features, but the canonical reference for what they do is qemu's
source code, not the TRM. That said, the reason why V7 doesn't
auto-imply V4/V5/V6 is purely historical -- we should clean the
code up so that it sets these features like that rather than having
all the CPUs set the feature flags individually.

R4F is going to want V4T, V5, V6, V7, THUMB2, MPU, VFP3, VFP_FP16
and DIV [although since R profile has UDIV and SDIV only in Thumb
mode and I've just sent patches that make the DIV feature enable
it for ARM mode too we'll need to sort that out].

> 3) How to handle processor revisions? The only two available TRMs for R4F
> seem to be r1p3 and r1p4. ARM_CPUID_CORTEXA9 seems to use r0p0, with r2p0
> being the oldest available TRM atm.
> Apart from the actual MIDR define and its binding to -cpu name, this also
> affects the FPSID register and gets a little ugly with non-linear mappings.
> The ARM1136 seems a particularly bad example, will try to post a cleanup.

I think that (1) the bare CPU name should be the most recent rev of the
core that QEMU knows about [and that we should be happy to change qemu
to move up to supporting newer revisions]
(2) we should really resist implementing (or retaining the implementation
of) older revisions of a core because mostly they're not really very
interesting
(3) where we do support more than one revision we should do it with
the same 'specify a feature' syntax rather than with different core
cpu names.

(Anybody want to argue with (1) ?)

1136 is particularly awful because the qemu cpu names are so misleading:
"arm1136" is an r1p0 which is actually later than the "arm1136_r2" which
is an r0p2. And we have way too many revs of the PXA270 IMHO. I guess
we're stuck with them for command line compatibility, though :-(

-- PMM