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

[Peter Maydell]

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

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