On 20 December 2013 21:41, Peter Crosthwaite
<peter.crosthwa...@xilinx.com> wrote:
> On Sat, Dec 21, 2013 at 4:16 AM, Peter Maydell <peter.mayd...@linaro.org>
> wrote:
>> On 20 December 2013 10:00, Peter Maydell <peter.mayd...@linaro.org> wrote:
>>> I'll have a think about this, because there are some wrinkles relating
>>> to reset that might be usefully solved this way.
>>
>> So my conclusion here is that really this boils down to how we
>> want to deal with sysregs for AArch64 capable CPUs in general.
>> There are two models I can think of:
>>
>> Option 1:
>> * we provide new reginfo definitions that describe the AArch64
>> views of the system registers
>> * for the AArch32 views, we just fall through and use the existing
>> definitions we've written for AArch32-only CPUs
>>
>> Option 2:
>> * we provide new reginfo definitions for the AArch64 views of
>> the registers, which include annotations to say whether there
>> is an AArch32 view of this register
>
> So to clarify, would MIDR and friends be in this bucket? And does t
> obsolete the old MIDR def such there is only one CPRegInfo globally?
I think we end up with a MIDR def for old CPUs and a MIDR
for v8-and-up CPUs which handles both AArch64 and AArch32 views:
{ .name = "MIDR_EL1",
.opc0 = 3, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 0,
.access = PL1_R,
.type = ARM_CP_CONST|ARM_CP_AA64|ARM_CP_AA32VIEW,
.resetvalue = cpu->midr },
because (a) ARMv8 gets rid of the "unimplemented c15 0 0 0 x
registers read as MIDR" and (b) we can ignore the annoying
special case handling for the TI925.
(I wonder if it would be nicer to have a .state field (values
CP_STATE_AA32 == 0, CP_STATE_AA64, CP_STATE_BOTH)
rather than shoehorning it into the flags field...)
For cases where we don't have annoying v7-and-earlier legacy
to deal with we can just have one reginfo struct I think.
I think it's the weird stuff that's going to get irritating because
we're going to end up with "not for v8" logic to suppress half of
them.
>> * for the few registers which aren't neatly arranged so the
>> crn/crm/opc1/opc2 line up, we just split up into a separate
>> reginfo for AArch64 and AArch32
>
> ACK, that sounds awkward but there nothing we can do abt it. how many
> are there? The few I checked always line up.
Well, everything in cp14 doesn't have architectural equivalents,
for a start. In AArch32 TCMTR is crn=0 crm=0 opc1=0 opc2=2
but that is OSDTRRX_EL1 in AArch64. The TLB and cache
maintenance ops don't always match up because they've been
tidied up, I think. The docs don't make it terribly easy to compile
a list of mismatches though.
>> * register_cp_regs_for_features() has separate AArch32
>> and AArch64 versions
>>
>
> Do we need this? With this scheme its still possible to enforce
> exclusivity in the CPRegInfo themselves.
Mmm, I guess we don't really, though it does mean we're
a bit more likely to have dubious stuff lurking around in
the AArch32-visible sysregs. (OTOH that's pretty irrelevant
until we have support for either Hyp or TrustZone, since
otherwise EL1 is always AArch64...)
-- PMM
