SMP Porting to Cortex R5

Thanks for the reply.

Hi @jjulich Joseph,

I am porting SMP support for Cortex A53. I am making changes to my port files, thanks to this thread. I wanted to know whether you were able to create “porting checklist for SMP”, would be very helpful to everyone who are in this process.

I apologize but we have been tied up with other things and have not had time to write the checklist. If you would like to contribute a checklist in the documentation folder it would be appreciated.

Thanks

Sure, once i feel confident about my changes . I would love to contribute

Hi @jjulich Joseph,

Please see below a rough checklist for porting to SMP. Would be glad to get your review whenever you find time.

Regards
Srinivas

1 Like

Hello Srini,
Thats very helpful,Do you have code base where you have done porting if you can share?

Hello,

If you are able to run task between 2 cores for Cortex R52. Can you share port. I am looking for siimmilar R52 implementation for freertos SMP. It will be very helpful

Hi,
We did some POC, not finished.
In our case 2 R5 cores do not have coherent cache. We had to put rtos data (TCB, etc) into non-shared memory. Work without cache kills performance.
In most implementation R5 do not have shared coherent shared cache.

Hello,

Yes even we don’t have coherent cache for 2 R5 cores. I have few basic doubts
-Here 2 R5 cores will run on same memory map and each will be having own elf?
-What I understood same scheduler will run on both cores, but for R52 we need to define different stack pointers for r52 different modes sys/irq/fiq/hyp
-If same code runs on both core then how second core will be getting up. Will it be like second core will start and setup gic and stack pointer and be in wfi then primary core will wakeup?

Hi,
The Idea behind SMP that you share the same memory view code/data/heap between 2 cores.
You can run run tasks on separate cores and share code and data.
I do not remember the details, maybe you can find that thread. As far as I remember scheduler runs on one core and second is a kind of slave (but may be I’m wrong).
We were interested in some corner case - permanent affinity of tasks/interrupts to certain cores.
The goal was offloading of heavy computation to second core, but still be able to use shared software infrastructures and one single ELF.
At the end we found that data in shared non-cached memory (even in TCM) kills performance and it is more practical to use AMP if it deals with R5.
Some implementation like TI sitara have proprietary address translation mechanisms.
It allows sharing the same ELF, but use different entry points per core. This is separate discussion.