| Message ID | 1308660911-9840-1-git-send-email-jamie.iles@picochip.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
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
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
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
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;
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(-)