From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA2eP-0006yt-DI for qemu-devel@nongnu.org; Tue, 20 Mar 2012 13:15:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SA2e0-0007Rq-Lo for qemu-devel@nongnu.org; Tue, 20 Mar 2012 13:15:12 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:52841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA2e0-0007Rj-FP for qemu-devel@nongnu.org; Tue, 20 Mar 2012 13:14:48 -0400 From: Paul Brook Date: Tue, 20 Mar 2012 17:14:44 +0000 References: <201203201606.42031.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201203201714.44924.paul@codesourcery.com> Subject: Re: [Qemu-devel] ARM QOM conversion / class hierarchy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Anthony Liguori , Andreas =?utf-8?q?F=C3=A4rber?= > >> Yes, I think I'd agree there. So should we just have an init function > >> that provides the implementation-specific cp15 registers based on the > >> value provided in the QOM property for the main ID register? > > > > Something like that, yes. I'm not convinced the main ID register is the > > right property to use, but for actual implementation specific bits > > (rather than bits where an implementation picks one of a few common > > options) I guess we don't have any alternative but enumerating the > > implementations we support. > > Mmm, the disgusting thing the TI925T has where it can programmatically > change the value of its main ID register does somewhat argue against using > it for this. I was thinking more for when we have multiple revisions of a chip that are (for these purposes) the same. Currently we only have this for pxa, but in principle we probably want it for others. As I mentioned on IRC, this isn't particularly interesting for Linux, which will happily run on pretty much anything. However there are other systems that care[1] whether the core reports itself as e.g. arm1136-r0p1 v.s. arm1136-r0p2. Paul [1] The reason for this is usually not relevant to qemu. e.g. They've got a hardcoded table of known CPUID values, and arbitrarily refuse to run on anything else. Or you're checking that a workaround for a particular silicon errata doesn't make anything else explode.