I only found one topic regarding to the SMP support which is all about the possibility. Looking forward to this important feautre to be supported specifically for ARMV8 arch processor. I would like to contribute to this activity if planned and needed.
1 Like
I really appreciate you offer to contribute. Do you have something already. While we encourage contributions it is a bit harder with SMP as it touches the core common files (the files that are built by all the kernel ports), which results in a lot of retest. It is also somewhat tricky to provide in a way that does not negatively impact single core devices. To somebody like myself though it is a fun topic and very interesting…so let me mention a few related projects.
First the FreeRTOS Interactive site hosts an academic paper written by somebody (forgive me for not providing the correct attribution, I would have to go and look) who created an SMP FreeRTOS port. This is a great resource, although somewhat old now.
Next Espressif host their own SMP version of FreeRTOS, which they run on their dual core ESP32 microcontrollers. That is not an ARM core though.
Finally and most recently I believe XMOS have provided a multicore (i.e. not limited to 2 cores) SMP version of FreeRTOS which I am very interested in, but have not found the time to fully investigate yet. I’m not in a position to be able to provide a web link at the moment, but if you search XMOS and FreeRTOS on github hopefully you will find it.
I would be interested in your particular use case, and why SMP is required rather than AMP. These conversations help us decide priorities and roadmap.
1 Like
My personal preferences would be that unless a SMP version can be produced with nearly all of the complexity of the Multi-core being in the Port Layer, with only minimal changes to the core, I would prefer that the basic FreeRTOS remain the simple single processor OS, with perhaps a multi-core variant on a separate branch.
Programming a multi-core system adds a lot of complexity in basic details that I would hate to see the basic core take on (or conversely, there are incredible simplifications that can be made if you can assume a single core that I would hate for it to lose).
One big effect is that many of the trade-offs are very different in the two cases. For example, to make a ‘complex’ access atomic on a single processor system can be simple, and constant cost by simply disabling interrupts for a short period of time, during which nothing else can get in to disturb the access. It isn’t that simple in a multi-core system, and normally it doesn’t even end up being constant time (if another core is in a related critical section, you may end up needing to ‘block’ till it is done). You also need to add in that you need memory barriers if you want to access a memory location that might have been updated by another core or you may end up loosing time coherence.
Thanks Rich for your reply and the info you provided. I just recently started introducing multi-core avaiable small OS. I perfer to go SMP just because it’s simplicity and flexibility in configuration(sure, great effort has been made in OS kenel to get this ready beforehand). I need tasks to be dynamically deployed in different cores in the fly rather than determine this since booting.
Just to be clear, having a FreeRTOS like SMP capable OS would be great, I just think that making the current FreeRTOS that OS would likely cost it too much in what it can currently do in the single processor system.
It may well be possible to take the existing FreeRTOS design, and even much of the available source code to build such a system, but my guess is that enough would need to change that trying to keep it as a single code base wouldn’t work. Some of the low level primitives that you build on likely need to be defined differently to account for the different sort of environment.
I’m working in a SoC company and we developed the SMP version of FreeRTOS for our product which is a ARMv8-A Cortex-A53 platform. The company would like to see if we can contribute to the open source community. I believe there would be a lot of potential use cases for SMP. So I don’t have a doubt if this would be valuable for FreeRTOS in the future. One of key benefits would be efficient task scheduling over multi-cores. However, the challenge is that it needs a lot of changes in the basic core such as task control block, task list, and many other data structures. Also, it affects the scheduling algorithm. The SMP kernel may no longer guarantee a constant time for its API execution. However, I strongly believe that the benefits will overwhelm the complexity and cost. What do you think?
1 Like
@wm2kgo, we always appreciate more contributions made to the FreeRTOS community and code goes a long way. Your submission might save others a lot of time. We’re all trying to not reinvent the wheel if we can help it. Please feel free to create your own repository and let us know here.
@rashed, I’m glad to see your positive feedback. I would appreciate it if I can get review from many people.
I have a question on the license. According to the guide from the legal team in my company, the company name needs to be added in the existing copyright header. But I don’t see any other company name except Amazon in the existing kernel source files. So I wonder how members in the community deal with the license issue. Specifically, does the community allow insertion of a contributor company name in the copyright header?
Code in the thirdparty directory has different names. Here is an example https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/master/portable/ThirdParty/CDK/T-HEAD_CK802/port.c
@rtel, thank you for the example. But my problem is that I have to modify the core kernel files such as tasks.c file.
Could you give an example of such a change. Reason for asking is there is a mechanism for adding new code into the kernel without updating the source file, but I’m assuming your use case is more about updating existing code.
For example, TCB data structure needs to be changed to include a few more fields. Specifically, the cpu id was added to the TCB_t to indicate the cpu that the task currently belongs to.
Right, that was the kind of change I expected. If there are many such changes I would suggest SMP versions are kept separate from non SMP - I think is what VxWorks does. Otherwise there may be overhead introduced for other ports, especially as FreeRTOS runs on very small processors too.
Did you see this port too? http://xcore.com/viewtopic.php?t=7774
@rtel, thank you for the link. I have not seen other SMP porting before. But I have read a very old paper related to SMP. The XMOS SMP looks very interesting. I see a few architectural differences from my project. We have been working to minimize the locking overhead to prevent multi-cores accesses to kernel data structures at the same time. However, it would be very nice for me to see others thoughts and their intention behind the codes.
Hi Wonmoon,
Have you created the repository for SMP version of FreeRTOS for ARMv8 architecture?
If so, Please share the link for the resources.
Thanks,
Jahnavi.
We have for V8-A, not yet for V8-M, which are you after?
Hi Richard,
It would be better if you have it for V8-R. But for now V8-A is also fine. Please share it.
Thanks,
Jahnavi.
Hi Richard and Wonmoon,
Is there any repository for SMP version of freertos for Cortext A53. I am particulary interested in modifications done in portable files like portSAVE_CONTEXT and portRESTORE_CONTEXT.
With the new changes in tasks.c the definition of pxCurrentTCB is changed and hence the portable\GCC\ARM_CA53_64_BIT\portASM.S wont work anymore
Not just yet - but keep watching the repo.