Re: [PATCH 1/1] arm: topology: parse the topology from the dt
From: Ruifeng Zhang
Date: Tue Apr 13 2021 - 02:14:11 EST
Valentin Schneider <valentin.schneider@xxxxxxx> 于2021年4月12日周一 下午11:33写道:
>
> On 12/04/21 20:20, Ruifeng Zhang wrote:
> > There is a armv8.3 cpu which should work normally both on aarch64 and aarch32.
> > The MPIDR has been written to the chip register in armv8.3 format.
> > For example,
> > core0: 0000000080000000
> > core1: 0000000080000100
> > core2: 0000000080000200
> > ...
> >
> > Its cpu topology can be parsed normally on aarch64 mode (both
> > userspace and kernel work on arm64).
> >
> > The problem is when it working on aarch32 mode (both userspace and
> > kernel work on arm 32-bit),
>
> I didn't know using aarch32 elsewhere than EL0 was something actually being
> used. Do you deploy this somewhere, or do you use it for testing purposes?
In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
version, one
of them is the kernel running on EL1 using aarch32.
user(EL0) kernel(EL1)
sc9863a_go aarch32 aarch32
sc9863a aarch64 aarch64
>
> > the cpu topology
> > will parse error because of the format is different between armv7 and armv8.3.
> > The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR
> > and store to the topology with armv7,
> > and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format.
> >
>
> I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
> I couldn't find anything about MPIDR format differences:
>
> DDI 0487G.a G8.2.113
> """
> AArch32 System register MPIDR bits [31:0] are architecturally mapped to
> AArch64 System register MPIDR_EL1[31:0].
> """
>
> Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
> just the same, i.e. for both of them, with your example of:
The cortex-a7 spec DDI0464F 4.3.5
https://developer.arm.com/documentation/ddi0464/f/?lang=en
The current arch/arm/kernel/topology code parse the MPIDR with a armv7 format.
the parse code is:
void store_cpu_topology(unsigned int cpuid)
{
...
cpuid_topo->thread_id = -1;
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
...
}
>
> core0: 0000000080000000
> core1: 0000000080000100
> core2: 0000000080000200
> ...
>
> we'll get:
>
> | | aff2 | aff1 | aff0 |
> |-------+------+------+------|
> | Core0 | 0 | 0 | 0 |
> | Core1 | 0 | 1 | 0 |
> | Core2 | 0 | 2 | 0 |
> ...
>
> Now, arm64 doesn't fallback to MPIDR for topology information anymore since
>
> 3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
>
> so without DT we would get:
> | | package_id | core_id |
> |-------+------------+---------|
> | Core0 | 0 | 0 |
> | Core1 | 0 | 1 |
> | Core2 | 0 | 2 |
>
> Whereas with an arm kernel we'll end up parsing MPIDR as:
> | | package_id | core_id |
> |-------+------------+---------|
> | Core0 | 0 | 0 |
> | Core1 | 1 | 0 |
> | Core2 | 2 | 0 |
>
> Did I get this right? Is this what you're observing?
Yes, this is a problem if an armv8.2 or above cpu is running a 32-bit
kernel on EL1.
>
> > In addition, I think arm should also allow customers to configure cpu
> > topologies via DT.