On 11/12/2020 16:09, Kinsey Moore wrote:
-----Original Message-----
From: Sebastian Huber<sebastian.hu...@embedded-brains.de>
Sent: Thursday, December 10, 2020 23:48
To: Kinsey Moore<kinsey.mo...@oarcorp.com>;devel@rtems.org
Subject: Re: [PATCH 1/2] tm27: Use generic cpu index accessor
On 10/12/2020 21:42, Kinsey Moore wrote:
The arm_cp15 function for accessing the current CPU index is specific
to ARMv7 while this header is used for ARMv8 as well. Instead, use a
generic accessor that is part of the standard CPU API.
I am fine with this fix, however, this is basically now the same
approach as in my v2 patch:
https://lists.rtems.org/pipermail/devel/2020-December/063693.html
Since the tm27 test is configured to use only one CPU, the current
processor is always 0.
Unfortunately, that's the only API currently available to get that information
easily on both architectures. The base function that is wrapped
(_CPU_SMP_Get_current_processor) could be provided outside the RTEMS_SMP ifdef
block and that could be used instead since this is specific to ARM/AArch64.
Would that be acceptable?
If _CPU_SMP_Get_current_processor() returns != 0 if
CONFIGURE_MAXIMUM_PROCESSORS == 1, then this is undefined behaviour,
since this value is used to index _Per_CPU_Information.
I think for now, the patch is fine.
What we have is an API mismatch between the logical processor index and
the MPIDR register. Currently, a one-to-one mapping is assumed. For a
proper support of clustered systems we may need a more complex mapping
(for example a four core system consisting of a cluster (aff1: 0 or 1)
of two cores each (aff0: 0 or 1)).
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
