From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBl0L-00089W-4z for qemu-devel@nongnu.org; Thu, 06 Oct 2011 06:16:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBl0K-0000xf-19 for qemu-devel@nongnu.org; Thu, 06 Oct 2011 06:16:41 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:53042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBl0J-0000xJ-Lt for qemu-devel@nongnu.org; Thu, 06 Oct 2011 06:16:39 -0400 Message-ID: <4E8D800A.9040409@web.de> Date: Thu, 06 Oct 2011 12:16:42 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1317581808-9784-1-git-send-email-andreas.faerber@web.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Sender: andreas.faerber@web.de Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 0/2] target-arm: Adding Cortex-R4F support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org Am 02.10.2011 23:44, schrieb Peter Maydell: > On 2 October 2011 19:56, Andreas F=C3=A4rber w= rote: >> I've been looking into adding support for Cortex-R4F. >=20 > 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? >=20 > That is indeed kind of ugly. I think if CPUID value isn't a unique valu= e > 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