在 2024/5/8 22:36, Sebastian Huber 写道:
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.
The thing that's troubling me is where to save configuration information
as it may affect other BSPs. I want to reduce the scope of impact. I
think the current BSPs can select update or use the origin way is best.
Maybe the core can decode itself is the best way, but I could not find a
way to do that. Linux use the information from device tree, so I think
maybe there's no such way.
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().
From the comment of start.S I think RTEMS always run in EL1.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
