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