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

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

[Jamie Iles]

Add support for the ARM1176JZ-s cores.  The ARM1176JZ-s is a v6K core
but uses the v7 VMSA for remapping and access permissions and there is
no way to identify these VMSA extensions from the cpuid feature
registers.

Cc: Paul Brook <paul@codesourcery.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Jamie Iles <jamie.iles@picochip.com>
---
 target-arm/cpu.h    |    1 +
 target-arm/helper.c |   23 ++++++++++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 01f5b57..8708f9e 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -414,6 +414,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
 #define ARM_CPUID_PXA270_C5   0x69054117
 #define ARM_CPUID_ARM1136     0x4117b363
 #define ARM_CPUID_ARM1136_R2  0x4107b362
+#define ARM_CPUID_ARM1176     0x410fb767
 #define ARM_CPUID_ARM11MPCORE 0x410fb022
 #define ARM_CPUID_CORTEXA8    0x410fc080
 #define ARM_CPUID_CORTEXA9    0x410fc090
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 1208416..63df576 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -36,6 +36,12 @@ static uint32_t arm1136_cp15_c0_c1[8] =
 static uint32_t arm1136_cp15_c0_c2[8] =
 { 0x00140011, 0x12002111, 0x11231111, 0x01102131, 0x141, 0, 0, 0 };
 
+static uint32_t arm1176_cp15_c0_c1[8] =
+{ 0x111, 0x11, 0x33, 0x01130003, 0x01130003, 0x10030302, 0x01222100, 0 };
+
+static uint32_t arm1176_cp15_c0_c2[8] =
+{ 0x0140011, 0x12002111, 0x11231121, 0x01102131, 0x01141, 0, 0, 0 };
+
 static uint32_t cpu_arm_find_by_name(const char *name);
 
 static inline void set_feature(CPUARMState *env, int feature)
@@ -86,6 +92,17 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_cachetype = 0x1dd20d2;
         env->cp15.c1_sys = 0x00050078;
         break;
+    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);
+        memcpy(env->cp15.c0_c1, arm1176_cp15_c0_c1, 8 * sizeof(uint32_t));
+        memcpy(env->cp15.c0_c2, arm1176_cp15_c0_c2, 8 * sizeof(uint32_t));
+        env->cp15.c0_cachetype = 0x1dd20d2;
+        env->cp15.c1_sys = 0x00050078;
+        break;
     case ARM_CPUID_ARM11MPCORE:
         set_feature(env, ARM_FEATURE_V4T);
         set_feature(env, ARM_FEATURE_V5);
@@ -377,6 +394,7 @@ static const struct arm_cpu_t arm_cpu_names[] = {
     { ARM_CPUID_ARM1026, "arm1026"},
     { ARM_CPUID_ARM1136, "arm1136"},
     { ARM_CPUID_ARM1136_R2, "arm1136-r2"},
+    { ARM_CPUID_ARM1176, "arm1176"},
     { ARM_CPUID_ARM11MPCORE, "arm11mpcore"},
     { ARM_CPUID_CORTEXM3, "cortex-m3"},
     { ARM_CPUID_CORTEXA8, "cortex-a8"},
@@ -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;
   default:
@@ -1770,6 +1790,7 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
                 return 1;
             case ARM_CPUID_ARM1136:
             case ARM_CPUID_ARM1136_R2:
+            case ARM_CPUID_ARM1176:
                 return 7;
             case ARM_CPUID_ARM11MPCORE:
                 return 1;
-- 
1.7.4.1

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

[Peter Maydell]

On 21 June 2011 13:55, Jamie Iles <jamie@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

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 <jamie@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

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

[Peter Maydell]

On 21 June 2011 17:13, Jamie Iles <jamie@jamieiles.com> wrote:
> Hi Peter,
>
> On Tue, Jun 21, 2011 at 04:43:44PM +0100, Peter Maydell wrote:
>> On 21 June 2011 13:55, Jamie Iles <jamie@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.

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] = 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.

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:
>>  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.

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:
>>  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.)

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

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

[Jamie Iles]

On 21 June 2011 23:13, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 21 June 2011 17:13, Jamie Iles <jamie@jamieiles.com> wrote:
>> Hi Peter,
>>
>> On Tue, Jun 21, 2011 at 04:43:44PM +0100, Peter Maydell wrote:
>>> On 21 June 2011 13:55, Jamie Iles <jamie@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.
>
> 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.

Could we perhaps infer and detect some of these features?  For example,
my reading of the ARM ARM says that the VA<->PA translation registers
exist for >v7 or v6k if the security extensions exist.  We can detect
the security extensions from the cpuid registers so we could
automatically set that feature.

>>> 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

Incidentally, the ARM ARM says that ID_MMFR0[3:0] = 0b0011 means
VMSAv7 with the above remapping, but 1136 appears to have this too
(I think it's only 1156 out of the v6 cores that doesn't).

>>>  NOPHINTS # enable the nop/yield/wfi/wfe space
>>>           # (WFI and WFE are only non-NOPs if FEATURE_V6K.)
>
> Whoops, I forgot TLS_REGISTERS (1136r1 has those as does 1176).

Ahh, yes.  I can't see any way to detect this - though the security
extensions so you could infer that for 1176, but not 1136.

>> 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.

Agreed.  Again, could we autodetect this though, or would having
the features explicitly set be better?  We should be able to do
things like ARM_FEATURE_THUMB2EE from the cpuid registers too right?

Jamie

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

[Peter Maydell]

On 22 June 2011 00:42, Jamie Iles <jamie@jamieiles.com> wrote:
> On 21 June 2011 23:13, Peter Maydell <peter.maydell@linaro.org> wrote:
>> 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.
>
> Could we perhaps infer and detect some of these features?  For example,
> my reading of the ARM ARM says that the VA<->PA translation registers
> exist for >v7 or v6k if the security extensions exist.  We can detect
> the security extensions from the cpuid registers so we could
> automatically set that feature.

I thought about that, but there are a couple of reasons I'd rather
not detect things from the cpuid/feature registers:
 * older cores don't have them, so you need to cope without them anyway
 * there's a tension between "emulate the same feature regs as the
   h/w" and "emulate feature regs matching what we implement" -- some
   guest OSes will actually refuse to boot unless they get exact matches
   on the feature reg values...
   (At the moment we tend to the former, so we probably advertise the
   security extensions even though we don't implement them, for instance)
 * at the moment the feature regs are just random hex values in helper.c;
   if we wanted to drive things from them we'd need to set up a lot of
   enumerations and constants anyway in order to have something maintainable

Inferring ARM_FEATURE_foo flags from other ARM_FEATURE_foo flags is fine,
though.

Mostly what I'd like is for the actual code implementing things to
be gated on a fairly fine-grained set of flags, so that we can confine
the "what does this core have? what things imply what other things?"
code to a single place where it's easy to tweak if we get it wrong.

-- PMM

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

[Jamie Iles]

On Wed, Jun 22, 2011 at 10:40:12AM +0100, Peter Maydell wrote:
> On 22 June 2011 00:42, Jamie Iles <jamie@jamieiles.com> wrote:
> > On 21 June 2011 23:13, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> 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.
> >
> > Could we perhaps infer and detect some of these features?  For example,
> > my reading of the ARM ARM says that the VA<->PA translation registers
> > exist for >v7 or v6k if the security extensions exist.  We can detect
> > the security extensions from the cpuid registers so we could
> > automatically set that feature.
> 
> I thought about that, but there are a couple of reasons I'd rather
> not detect things from the cpuid/feature registers:
>  * older cores don't have them, so you need to cope without them anyway
>  * there's a tension between "emulate the same feature regs as the
>    h/w" and "emulate feature regs matching what we implement" -- some
>    guest OSes will actually refuse to boot unless they get exact matches
>    on the feature reg values...
>    (At the moment we tend to the former, so we probably advertise the
>    security extensions even though we don't implement them, for instance)
>  * at the moment the feature regs are just random hex values in helper.c;
>    if we wanted to drive things from them we'd need to set up a lot of
>    enumerations and constants anyway in order to have something maintainable
> 
> Inferring ARM_FEATURE_foo flags from other ARM_FEATURE_foo flags is fine,
> though.
> 
> Mostly what I'd like is for the actual code implementing things to
> be gated on a fairly fine-grained set of flags, so that we can confine
> the "what does this core have? what things imply what other things?"
> code to a single place where it's easy to tweak if we get it wrong.

OK, I don't think I can object to that!  I'll submit a patch to fix up 
the v7 VMSA ap/remap dependency to be v6K rather than v7.  Given that, 
do you have any objection to adding 1167 as a v6K?  I'm happy to help 
with/test some of the feature cleanup.

Jamie

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

[Peter Maydell]

On 22 June 2011 16:45, Jamie Iles <jamie@jamieiles.com> wrote:
> On Wed, Jun 22, 2011 at 10:40:12AM +0100, Peter Maydell wrote:
>> Mostly what I'd like is for the actual code implementing things to
>> be gated on a fairly fine-grained set of flags, so that we can confine
>> the "what does this core have? what things imply what other things?"
>> code to a single place where it's easy to tweak if we get it wrong.
>
> OK, I don't think I can object to that!  I'll submit a patch to fix up
> the v7 VMSA ap/remap dependency to be v6K rather than v7.  Given that,
> do you have any objection to adding 1167 as a v6K?  I'm happy to help
> with/test some of the feature cleanup.

I think the question is, if you mark the 1176 as a v6K then how do
you gate the "working WFI from WFI instruction", which otherwise
could reasonably be marked as one of the features implied by v6K?

-- PMM

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

[Jamie Iles]

On Wed, Jun 22, 2011 at 05:01:30PM +0100, Peter Maydell wrote:
> On 22 June 2011 16:45, Jamie Iles <jamie@jamieiles.com> wrote:
> > On Wed, Jun 22, 2011 at 10:40:12AM +0100, Peter Maydell wrote:
> >> Mostly what I'd like is for the actual code implementing things to
> >> be gated on a fairly fine-grained set of flags, so that we can confine
> >> the "what does this core have? what things imply what other things?"
> >> code to a single place where it's easy to tweak if we get it wrong.
> >
> > OK, I don't think I can object to that!  I'll submit a patch to fix up
> > the v7 VMSA ap/remap dependency to be v6K rather than v7.  Given that,
> > do you have any objection to adding 1167 as a v6K?  I'm happy to help
> > with/test some of the feature cleanup.
> 
> I think the question is, if you mark the 1176 as a v6K then how do
> you gate the "working WFI from WFI instruction", which otherwise
> could reasonably be marked as one of the features implied by v6K?

The ARM1176 technically is a v6K core, but the actual definition of v6K 
seems a bit vague on required features.

As wfi is a valid encoding on 1176 I personally don't see this as being 
a blocking issue (though technically incorrect, though most code 
targeted for this CPU presumably wouldn't emit a wfi instruction?).

Jamie

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

[Peter Maydell]

On 22 June 2011 17:16, Jamie Iles <jamie@jamieiles.com> wrote:
> The ARM1176 technically is a v6K core, but the actual definition of v6K
> seems a bit vague on required features.
>
> As wfi is a valid encoding on 1176 I personally don't see this as being
> a blocking issue (though technically incorrect, though most code
> targeted for this CPU presumably wouldn't emit a wfi instruction?).

Yeah, I think we're down in the noise really here. Some older
versions of the Linux kernel incorrectly emitted a WFI insn
rather than the cp15 op, but that bug was fixed. In any case
I doubt anybody's written code that relies on the wfi insn
being implemented as a nop...

Calling it a v6k in qemu is probably on balance better than not.

-- PMM