From: Jamie Iles <jamie@jamieiles.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Jamie Iles <jamie.iles@picochip.com>,
qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>,
Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] target-arm: support for ARM1176JZ-s cores
Date: Wed, 22 Jun 2011 00:42:42 +0100 [thread overview]
Message-ID: <BANLkTik5ys3y4NUO3OJ7SCunrCEa_X1kpw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimDYug3DQQm921L1jPqv9gHB3AB7A@mail.gmail.com>
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
next prev parent reply other threads:[~2011-06-21 23:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-21 12:55 [Qemu-devel] [PATCH] target-arm: support for ARM1176JZ-s cores Jamie Iles
2011-06-21 15:43 ` Peter Maydell
2011-06-21 16:13 ` Jamie Iles
2011-06-21 22:13 ` Peter Maydell
2011-06-21 23:42 ` Jamie Iles [this message]
2011-06-22 9:40 ` Peter Maydell
2011-06-22 15:45 ` Jamie Iles
2011-06-22 16:01 ` Peter Maydell
2011-06-22 16:16 ` Jamie Iles
2011-06-22 16:26 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTik5ys3y4NUO3OJ7SCunrCEa_X1kpw@mail.gmail.com \
--to=jamie@jamieiles.com \
--cc=aurelien@aurel32.net \
--cc=jamie.iles@picochip.com \
--cc=paul@codesourcery.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).