Re: [Qemu-devel] [PATCH] target-arm: support for ARM1176JZ-s cores

[Jamie Iles]

Hi Peter,

On Tue, Jun 21, 2011 at 04:43:44PM +0100, Peter Maydell wrote:
> On 21 June 2011 13:55, Jamie Iles <address@hidden> 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