On 21 June 2011 17:13, Jamie Iles <ja...@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 <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.
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
