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