Improvements to SMP under the arch64 architecture
zhengxiaojun
17935334 at qq.com
Fri May 10 01:38:26 UTC 2024
在 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.
More information about the devel
mailing list