• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1422 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6548: CPU IDs of Dual-core Arm Cortex -R5F cores

Iqra Zaman1
Prodigy 170 points
Part Number: AM6548
Other Parts Discussed in Thread: DRA829

Hi,

I have a AM65x/DRA80xM Industrial Development Kit. On this platform, I am using the cluster 0's Cortex-A53 cores and MCU domain's Cortex-R5F cores.

The CPU ID of first core of A53 (cluster0 core 0) is 0x0 as indicated by the device tree nodes as well as the MPIDR value.

What will be the CPU IDs of R5F cores? The MPIDR is returning 0x0 and 0x1 for R5F core0 and R5F core1 respectively.

How can I differentiate among the A53 and R5F cores in this case? For targets like Xilinx ZynqMPSoC, the A53 cluster has CPU IDs 0, 1, 2 and 3 for the four cores present and the dual R5 cores have CPU IDs 0x100 and 0x101.

On this platform, I am not able to get unique CPU IDs for two different processor cores. I am developing an AMP system and I need to have a criteria to differentiate the cores.

Regads,
Iqra

  • 0
    TI__Mastermind 23955 points

    The MPIDR value for the ARMv8 CPUs hooked into the coherent computer cluster (direct connect to msmc) populate MPIDR AFF1 with the cluster # and AFF0 with the cpu # in a cluster.  On AM65xx, this means A53:0.0=(0x0000), A530.1=(0x0001) and A53:1.0 (0x0100), A53:1.1=(0x0101).  The other ARMv8 AFF2 & AFF3 fields are 0x0.

    The ARMv7 MCU R5 system is not part of the coherent cluster an populates its MPIDR AFF1=groupID, AFF0=cpu#.  The AM65x has 1 dualR5 instance with: R5:0.0=(0x0000) and R5:0.1=(0x0001).  The other ARMv7 AFF2 field is 0x0.    Other chips like DRA829/AM75xx have 3 instances of dualR5 clusters outside the compute cluster and their AFF1 fields do increment with the group ID  (MCU=0, MAIN0=1, MAIN1=2).

    The ARMv7 and ARMv8 arch spec's both note the AFFx encoding is unknown.  The v7 arch gives 2 somewhat conflicting examples how to use where the v8 only gives a general note.   Both say to look into the implementation ARM TRMs (like v8-A53 & v7-R5).  Those TRMs do define CPUs as they have been tied off above. 

    On the A53 clusters (2x2=4 CPUs) the MPIDR is can be used by the OS (or code) to schedule code on across the similar cores.  All have the same instruction set and MMU support level as they are all 64-bit ARMv8. For example an HLOS Linux-SMP will make use of this.  The 32-bit R5 (v7) CPUs in the MCU largely will not run the same code as exists for the A53, its a different ISA and has different system units (like MPU instead of MMU).  Code on the R5 (usually an RTOS) might schedule between the 2 R5 CPUs leveraging its locally unique MPIDR values.

    If you pass some structures between the clusters and want to embed some unique ID you could define one in SW or could leverage some combination of the MIDR and MPIDR registers.   For bare metal code, you find MPIDR is used to sequence booting on locally-related clusters.  Once code transitions to a higher level (RTOS or HLOS) those schedulers may MPIDR for actions relevant to their 'symmetric' resources.  Communication between the asymmetric cores will flow on other abstractions and can use whatever is appropriate to distinguish any shared objects.

    The convention used in AM65xx follows locally what ARM recommended and globally how SW would use it.  If all the clusters types were connected to the same interconnect (msmc) they would have been unique based on the scheme but since they are split and used in a superset/subset manner they are only locally unique.

    Regards,

    Richard W.