From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ9C7-00063x-IM for qemu-devel@nongnu.org; Tue, 21 Jun 2011 18:13:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ9C6-0003JA-CS for qemu-devel@nongnu.org; Tue, 21 Jun 2011 18:13:15 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:35212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ9C6-0003Iw-6e for qemu-devel@nongnu.org; Tue, 21 Jun 2011 18:13:14 -0400 Received: by pwi5 with SMTP id 5so254995pwi.4 for ; Tue, 21 Jun 2011 15:13:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110621161300.GK2647@pulham.picochip.com> References: <1308660911-9840-1-git-send-email-jamie.iles@picochip.com> <20110621161300.GK2647@pulham.picochip.com> Date: Tue, 21 Jun 2011 23:13:12 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] target-arm: support for ARM1176JZ-s cores List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Iles Cc: Jamie Iles , qemu-devel@nongnu.org, Aurelien Jarno , Paul Brook On 21 June 2011 17:13, Jamie Iles wrote: > Hi Peter, > > On Tue, Jun 21, 2011 at 04:43:44PM +0100, Peter Maydell wrote: >> On 21 June 2011 13:55, Jamie Iles wrote: >> > + =C2=A0 =C2=A0case ARM_CPUID_ARM1176: >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0set_feature(env, ARM_FEATURE_V4T); >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0set_feature(env, ARM_FEATURE_V5); >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0set_feature(env, ARM_FEATURE_V6); >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0set_feature(env, ARM_FEATURE_V6K); >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0set_feature(env, ARM_FEATURE_AUXCR); >> >> This isn't quite right -- the 1176 isn't a v6K. In particular it >> is missing the VA-PA translation cp15 regs, and SEV, WFI and WFE >> have to no-op rather than doing anything. > > Hmm, perhaps I should have specified the 1176JZ-S? =C2=A0According to the= TRM > it does have the VA-PA translation operations in the cache operations > cp15 register. Ah yes, sorry, I misread the TRM there. So it does have those, it's just the SEV/WFI/WFE it is missing. I guess we'll want an ARM_FEATURE_VAPA too. > Also it does support wait-for-interrupt stalling, but only through a > cp15 access and not the wfi instruction (which is a nop). Yes; I was specifically referring to the instruction forms of wfi etc, not the copro ops. >> Turning on features based on specific CPUs is a bit of a wart; >> I don't think this condition was quite right anyway. This >> (the additional access permission encoding AP[2:0] =3D 0b111) >> was introduced in ARMv6K, not ARMv7. It's also present in >> 1176 and in 1136r1 and above. (The same is true of the other >> v6K VMSA features, TEX remapping and the SCTLR access flag.) > > Yes, that is a bit ugly. =C2=A0If that's wrong anyway I'll submit a patch= to > change this to just be v6k for now before cleaning up the feature bits. Sounds OK. >> Existing feature flags which are really trying to >> get device-specific cp15 registers right; I think we >> could clean up our cp15 support to the point where these >> weren't actually needed, but that's a different topic and >> for now I'm happy to leave them be: >> =C2=A0AUXCR > > We should be able to get the presence of the ACR from memory model > feature register 0 if my understanding of the ARM ARM is correct, but as > the contents are implementation defined I guess we need a way to handle > the accesses. As I say, I'd rather we had a more flexible way to handle device-dependent cp15 registers (so you could say "I support the usual v6 cp15 registers; here are some device specific ones as well" and not have the current huge nested switches). I really must get round to doing this. (The ARM1026 has an ACTLR but no MMFR0, incidentally.) >> Which puts us in a position to define some new feature >> flags to account for 1136/1176: >> =C2=A0V6K_EXCLUSIVES =C2=A0# CLREX, LDREXB, LDREXH, LDREXD, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# STREXB, = STREXD, STREXH >> >> =C2=A0V6K_VMSA # TEX remapping, SCTLR AFE, AP[2:0] =3D 0b111 encoding >> >> =C2=A0NOPHINTS # enable the nop/yield/wfi/wfe space >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # (WFI and WFE are only non-NOPs if F= EATURE_V6K.) Whoops, I forgot TLS_REGISTERS (1136r1 has those as does 1176). > I thought the only thing that made them non-NOPs were if the system was > multi-core v6K. I think you end up in about the same place if you say "the 1176 is a v6 with all the v6K extras except non-nop WFI", as if you say "1176 is a v6K but v6K WFI is only non-nop on multicore". And it's easier to define the 1176 as v6 + lots than to try to have a means for cpus to remove feature flags that V6K would otherwise imply, just for this one corner case. -- PMM