From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdPB2-0001Kz-01 for qemu-devel@nongnu.org; Wed, 21 Dec 2011 11:38:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdPAx-0001EQ-PP for qemu-devel@nongnu.org; Wed, 21 Dec 2011 11:37:59 -0500 Received: from smtp111.dfw.emailsrvr.com ([67.192.241.111]:36790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdPAx-0001EF-MQ for qemu-devel@nongnu.org; Wed, 21 Dec 2011 11:37:55 -0500 Message-ID: <4EF20B67.2070502@calxeda.com> Date: Wed, 21 Dec 2011 10:37:59 -0600 From: Mark Langsdorf MIME-Version: 1.0 References: <4EF0DDB5.9040806@calxeda.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "qemu-devel@nongnu.org" On 12/20/2011 01:48 PM, Peter Maydell wrote: > On 20 December 2011 19:10, Mark Langsdorf wrote: >> diff --git a/target-arm/helper.c b/target-arm/helper.c >> index 816c4c4..37110bc 100644 >> --- a/target-arm/helper.c >> +++ b/target-arm/helper.c >> @@ -2197,6 +2197,13 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t >> insn) >> * 0x200 << ($rn & 0xfff), when MMU is off. */ >> goto bad_reg; >> } >> + if (ARM_CPUID(env) == ARM_CPUID_CORTEXA9) { >> + switch (crm) { >> + case 0: >> + return env->cp15.c15_scubase; >> + } >> + goto bad_reg; >> + } > > This is underdecoded: the A9 has two registers in c15,c0: > CRn Op1 CRm Op2 Name > 15 0 c0 0 Power Control Register > 15 4 c0 0 Configuration Base Address > > I'm guessing you're after the Configuration Base Address register. > (please call the struct name something vaguely relating to the > official register name, incidentally.) Apparently it's called scubase in the Linux code, but I'll fix the name for qemu. >> return 0; >> } >> bad_reg: > > This commit leaves the register with a reset value of 0, which > isn't right (we only implement A9MP, not A9UP, so the reset value > should be settable by the board at init time somehow depending > where the a9mpcore_priv device is mapped. Not sure what the > cleanest way to do that is.) I can add a DEFINE_PROP_UINT32 to a9mpcore_priv, which would give anyone who wants to set the property an easy way to do so. I'm not sure how to hook the a9mpcore_priv to the CPUARMState, though. They don't appear to reference each other. --Mark Langsdorf Calxeda, Inc.