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. 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.)
[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
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.)
(V6K implies V6K_EXCLUSIVES, V6K_VMSA, NOPHINTS. THUMB2
implies NOPHINTS. V6K implies NOPHINTS. 1136r1 and 1176
set V6, V6K_EXCLUSIVES, V6K_VMSA, NOPHINTS.)
-- PMM
