qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 6/7] target/arm: Define cortex-a76


From: Richard Henderson
Subject: Re: [PATCH 6/7] target/arm: Define cortex-a76
Date: Mon, 11 Apr 2022 11:30:57 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

On 4/11/22 11:09, Peter Maydell wrote:
+    cpu->isar.id_aa64pfr0  = 0x1100000010111112ull;

This has the GIC field clear. On the one hand this is true
also of all our other CPU implementations. On the other hand
if we wire up a GICv3 in the board code then we will be
presenting the GIC CPU interface registers, which is what this
ID register field is supposed to be telling software.
I guess we should handle this by having gicv3_init_cpuif()
arrange for the ID field to be set. Which is mildly painful,
because that will mean the value for the cpreg isn't constant.

We already handle this via id_aa64pfr0_read().

+    cpu->isar.id_pfr1  = 0x10010000;

Here you have set the GIC field. We should at least be consistent :-)

Oops.  :-)  We have id_pfr1_read() for that as well.

+    cpu->midr = 0x413fd0b1;

This is r3p1; the r4p1 TRM is available so we might as
well claim to be that.

Ok.

Missing (just cross-checking what other CPUs are setting):
   cpu->revidr
   cpu->reset_fpsid
   cpu->id_afr0

revidr and id_afr0 are 0 -- explicit zero required? We certainly assume we begin with zero for other registers for other cpus...

FPSID is deprecated, and not mentioned in the a76 or n1 specs. Presumably this is because it is not accessible at all: FPSID is not accessible from EL0 for VFPv3, and the A76 does not support aa32 at other than EL0.

   cpu->isar.dbgdidr

"If EL1 cannot use AArch32 then the implementation of this register is OPTIONAL and deprecated."


r~



reply via email to

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