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

["Andreas Färber" <andreas.faerber@web.de>]

Am 02.10.2011 23:44, schrieb Peter Maydell:
> On 2 October 2011 19:56, Andreas Färber <andreas.faerber@web.de> 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,

Yeah, I rarely pick the easy tasks. :)

>> 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.

For the reset, the MIDR is read, then the memset() is performed and
cpu_reset_model_id() is called with the previously read MIDR value,
which the function then writes into the register first thing. I'd
suggest to move that out into cpu_reset(), drop the id parameter and
switch on the register instead (only other use is cpu_abort()).

> 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.)

Coming from a ppc background, we have a whole matrix of processors with
fixed features but I'm not aware of an arch where we opt-in/out
processor core features.

> 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.

I'll go with cortex-r4f then.

> 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]

> (Anybody want to argue with (1) ?)

I concur that an easy-to-type -cpu should provide the latest and
greatest features. Features hidden will not get much exposure. But if a
revision noticeably changes behavior, I guess we should remain command
line compatible.

Andreas