Hi Peter, On Tue, Jun 21, 2011 at 04:43:44PM +0100, Peter Maydell wrote: > On 21 June 2011 13:55, Jamie Iles <ja...@jamieiles.com> wrote: > > + case ARM_CPUID_ARM1176: > > + set_feature(env, ARM_FEATURE_V4T); > > + set_feature(env, ARM_FEATURE_V5); > > + set_feature(env, ARM_FEATURE_V6); > > + set_feature(env, ARM_FEATURE_V6K); > > + set_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? According to the TRM it does have the VA-PA translation operations in the cache operations cp15 register. We have a platform with an ARM1176JZ-S that had previously been confirmed by ARM has having the K extensions. Also it does support wait-for-interrupt stalling, but only through a cp15 access and not the wfi instruction (which is a nop). > It does have the v6K byte/halfword/double ld/st exclusives, CLREX, > YIELD and NOP. (It's like the 1136r1 in this regard, another case that > came up on the list recently.) > > I think we really need to split some of these subcases out into > their own ARM_FEATURE_ bits; see below. > > > @@ -945,7 +963,9 @@ static inline int check_ap(CPUState *env, int ap, int > > domain, int access_type, > > case 6: > > return prot_ro; > > case 7: > > - if (!arm_feature (env, ARM_FEATURE_V7)) > > + /* ARM1176 uses VMSAv7 remapping and access flag. */ > > + if (!arm_feature (env, ARM_FEATURE_V7) && > > + ARM_CPUID(env) != ARM_CPUID_ARM1176) > > return 0; > > return prot_ro; > > 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] = 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. If that's wrong anyway I'll submit a patch to change this to just be v6k for now before cleaning up the feature bits. > [We don't currently implement TEX remapping at all...] > > Anyway, feature bit cleanup. Here's a concrete proposal, > starting with the ones we already have. Rather than every > core setting every feature flag it needs, I suggest that we > have a little bit of common code which knows which features > imply which others. So each core picks one "core architecture > version" and then a hopefully small set of extra "specific > feature" flags for things not implied by the core arch version. > > "core architecture version" flags: these imply all the > preceding arch versions, and also various specific features > which are mandatory in that arch version. > > V4T > V5 implies V4T > V6 implies V5, V4T, AUXCR > V6K implies V6, V5, V4T > V7 implies V6K, V6, V5, V4T, THUMB2EE, THUMB2 > XSCALE implies V5 > IWMMXT implies XSCALE > > Existing "specific feature" flags: these indicate particular > well-defined features which may exist either as an > optional part of an arch version, or which might appear > in earlier cores before being rolled into the formal > architecture spec: > > THUMB2 > THUMB2EE > V7MP # ie the multiprocessing extensions > VFP > VFP3 implies VFP > VFP_FP16 # ie half-precision support > NEON > DIV > MPU > M # a bit of a special case since it's a whole other > # architecture variant, but it could be v6 or v7. > # M && V7 implies DIV, THUMB2. > > 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: > AUXCR 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. > STRONGARM > OMAPCP > > Which puts us in a position to define some new feature > flags to account for 1136/1176: > V6K_EXCLUSIVES # CLREX, LDREXB, LDREXH, LDREXD, > # STREXB, STREXD, STREXH > > V6K_VMSA # TEX remapping, SCTLR AFE, AP[2:0] = 0b111 encoding > > NOPHINTS # enable the nop/yield/wfi/wfe space > # (WFI and WFE are only non-NOPs if FEATURE_V6K.) I thought the only thing that made them non-NOPs were if the system was multi-core v6K. > (V6K implies V6K_EXCLUSIVES, V6K_VMSA, NOPHINTS. THUMB2 > implies NOPHINTS. V6K implies NOPHINTS. 1136r1 and 1176 > set V6, V6K_EXCLUSIVES, V6K_VMSA, NOPHINTS.) Jamie
