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.


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to