RTEMS | bsp/aarch64:SMP improvement on aarch64 (#5064)

[xiaojun zheng (@zhengxiaojun)]

xiaojun zheng created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5064



## Summary
  The multicore CPU may arrange in a cluster or multi-clusters, the current RTEMS do not deal 
with the cluster id, so it can not run on CPU arranged in clusters. Some changes about MPIDR must
be made to make RTEMS run. I describe the changes here, so it can be discussed.
  
  MPIDR provides an additional PE identification mechanism In a multiprocessor system.
There are 4 levels, <Aff3>.<Aff2>.<Aff1>.<Aff0>. Aff0 indicates the core number, Aff1,Aff2
indicates the cluster. For a cluster with four cores MPIDR is: 0x0, 0x1, 0x2, 0x3, 
for 4 clusters MPIDR is:0x100,0x200,0x300,0x400

## Issue
  MPIDR is used as the processer index in irq,start code.
  - start.S https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/aarch64/shared/start/start.S?ref_type=heads#L285
    secondary CPU use MPIDR calculate stack pointer, the code assume MPIDR is current processor index, so if the MPIDR
    is 0x100,0x200,... the SP may be out of memory.

  - gicv3_trigger_sgi() https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/include/dev/irq/arm-gicv3.h?ref_type=heads#L255
    The function used current MPIDR to setup the request, so it can not trigger the target core in the diffrent cluster.

  - _CPU_SMP_Get_current_processor() https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h?ref_type=heads#L342
    The function is assumed to return the core index.

## Changes
  I think it should setup a map from MPIDR to core index when the primary CPU boot up, and then
  - start.S: use a global variable to pass cluster ID to secondary CPU as parameters, something like this:
    struct boot_params {
      uint64_t mpidr;
      uint32_t cpu_index;
    };

  - gicv3_trigger_sgi: add a parameter to pass the cluster ID
     change gicv3_trigger_sgi(rtems_vector_number vector, uint32_t targets) to
     gicv3_trigger_sgi(rtems_vector_number vector, uint64_t cluster_id, uint32_t targets)

  - _CPU_SMP_Get_current_processor(): use _Per_CPU_Get_index() return the CPU index, do not read MPIDR.

## To be disscussed
  - Where to store the map?
    Linux get the CPU ID from a dts file, but RTEMS doesn't always use a dts file.
    Declare a map in the bsps source file, it doesn't seem flexible enough.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5064
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240709/b2ce4af0/attachment.htm>