qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jamie Iles
Subject: Re: [Qemu-devel] [PATCH] target-arm: support for ARM1176JZ-s cores
Date: Wed, 22 Jun 2011 00:42:42 +0100

On 21 June 2011 23:13, Peter Maydell <address@hidden> wrote:
> 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]