Is your feature request related to a problem? Please describe.
Eclipse ThreadX currently offers SMP ports for Cortex-A, Cortex-R8, MIPS interAptiv and ARC HS, plus the Linux and Win64 simulators. There is no SMP support for Armv8-R, even though we already ship a uniprocessor Cortex-R52 port in ports/cortex_r52.
That leaves a gap for users who need MPU-based, hard real-time, safety-oriented multicore. This came up in #229, where @AJIOB asked for Cortex-M SMP support on a dual Cortex-M4 subsystem. Cortex-M is not a realistic target for SMP, because Armv7-M and Armv8-M provide no core identity register, no architected inter-core interrupt and no shared exclusive monitor, so every one of those would be SoC-specific glue. Armv8-R is the architecture that actually answers that need, so this issue splits the tractable half of #229 out into its own request. Credit for raising the underlying use case goes to @AJIOB.
Describe the solution you'd like
An SMP port for Armv8-R, starting with Cortex-R52 in AArch32 and ideally extending to Cortex-R82 in AArch64. Concretely that means a ports_smp/cortex_r52_smp directory implementing the usual SMP port surface: _tx_thread_smp_core_get, _tx_thread_smp_core_preempt, _tx_thread_smp_protect and _tx_thread_smp_unprotect, _tx_thread_smp_initialize_wait, _tx_thread_smp_low_level_initialize, _tx_thread_smp_current_state_get, _tx_thread_smp_current_thread_get and _tx_thread_smp_time_get, alongside the context save and restore paths.
The building blocks are all present in the architecture. Armv8-R provides MPIDR for core identity, GIC software-generated interrupts for the inter-core preemption signal, and a cluster-level global exclusive monitor so that an LDREX/STREX spinlock genuinely arbitrates between cores rather than succeeding locally on each one.
Describe alternatives you've considered
AMP, which is what we recommend today: an independent ThreadX instance per core, a statically partitioned workload, and shared memory plus hardware mailboxes for IPC. This works and keeps each instance independently analysable, but it does not give users dynamic load balancing across cores, and it is not what everyone wants.
Additional context
ports_smp/cortex_r8_smp is the natural template. It is our existing 32-bit, MPU-based SMP port, and it already operates without hardware cache coherency between cores by keeping the shared kernel structures in shared, non-cacheable memory. A Cortex-R52 SMP port would need the same discipline, since Cortex-R52 does not maintain coherency between the per-core L1 data caches.
This is not something we have scheduled. It needs a contributor with access to a real Armv8-R multicore platform, since the lock and preemption paths cannot be meaningfully validated in simulation alone. We would be glad to help review the work.
Is your feature request related to a problem? Please describe.
Eclipse ThreadX currently offers SMP ports for Cortex-A, Cortex-R8, MIPS interAptiv and ARC HS, plus the Linux and Win64 simulators. There is no SMP support for Armv8-R, even though we already ship a uniprocessor Cortex-R52 port in
ports/cortex_r52.That leaves a gap for users who need MPU-based, hard real-time, safety-oriented multicore. This came up in #229, where @AJIOB asked for Cortex-M SMP support on a dual Cortex-M4 subsystem. Cortex-M is not a realistic target for SMP, because Armv7-M and Armv8-M provide no core identity register, no architected inter-core interrupt and no shared exclusive monitor, so every one of those would be SoC-specific glue. Armv8-R is the architecture that actually answers that need, so this issue splits the tractable half of #229 out into its own request. Credit for raising the underlying use case goes to @AJIOB.
Describe the solution you'd like
An SMP port for Armv8-R, starting with Cortex-R52 in AArch32 and ideally extending to Cortex-R82 in AArch64. Concretely that means a
ports_smp/cortex_r52_smpdirectory implementing the usual SMP port surface:_tx_thread_smp_core_get,_tx_thread_smp_core_preempt,_tx_thread_smp_protectand_tx_thread_smp_unprotect,_tx_thread_smp_initialize_wait,_tx_thread_smp_low_level_initialize,_tx_thread_smp_current_state_get,_tx_thread_smp_current_thread_getand_tx_thread_smp_time_get, alongside the context save and restore paths.The building blocks are all present in the architecture. Armv8-R provides MPIDR for core identity, GIC software-generated interrupts for the inter-core preemption signal, and a cluster-level global exclusive monitor so that an
LDREX/STREXspinlock genuinely arbitrates between cores rather than succeeding locally on each one.Describe alternatives you've considered
AMP, which is what we recommend today: an independent ThreadX instance per core, a statically partitioned workload, and shared memory plus hardware mailboxes for IPC. This works and keeps each instance independently analysable, but it does not give users dynamic load balancing across cores, and it is not what everyone wants.
Additional context
ports_smp/cortex_r8_smpis the natural template. It is our existing 32-bit, MPU-based SMP port, and it already operates without hardware cache coherency between cores by keeping the shared kernel structures in shared, non-cacheable memory. A Cortex-R52 SMP port would need the same discipline, since Cortex-R52 does not maintain coherency between the per-core L1 data caches.This is not something we have scheduled. It needs a contributor with access to a real Armv8-R multicore platform, since the lock and preemption paths cannot be meaningfully validated in simulation alone. We would be glad to help review the work.