Improvements to SMP under the arch64 architecture
Kinsey Moore
kinsey.moore at oarcorp.com
Wed May 8 16:01:06 UTC 2024
On Wed, May 8, 2024 at 9:36 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
> On 08.05.24 08:17, Sebastian Huber wrote:
> > Hello,
> >
> > on the arm target, we use this:
> >
> > static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control(
> > void )
> > {
> > struct Per_CPU_Control *cpu_self;
> >
> > /* Use PL1 only Thread ID Register (TPIDRPRW) */
> > __asm__ volatile (
> > "mrc p15, 0, %0, c13, c0, 4"
> > : "=r" ( cpu_self )
> > );
> >
> > return cpu_self;
> > }
> >
> > to access the per-CPU control. I guess, AArch64 has also a thread ID
> > register available for operating system use. With this we could
> > implement _CPU_Get_current_processor() like this:
> >
> > return _Per_CPU_Get_index( _CPU_Get_current_per_CPU_control() );
> >
> > The BSP-specific startup code has to decode the MPIDR and set the thread
> > ID register accordingly.
>
> If we assume that we always run in EL1 or higher, then we can use the
> TPIDR_EL1 for an _AArch64_Get_current_per_CPU_control().
>
As currently configured, AArch64 only runs in EL1 (with small portions of
the boot code possibly running in EL3/EL2 depending on the start state) and
is never expected to run in EL0 for any reason. RTEMS does use the EL0
stack pointer, but that's only for interrupt stacks and doesn't actually
drop to EL0 system state.
Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240508/02670a3f/attachment.htm>
More information about the devel
mailing list