ChibiOS Free Embedded RTOS

STM32MP1 --
Is there an existing STM32 I can load for support of the M4 on the STM32MP1?

Also @giovanni - I sent you a PM with more details on what drives my question. Thanks!

Hi,

Answered via PM.

Giovanni

russian wrote:ST Stellar MCU was announced only 11 months ago and it's complete silence since?

11+7=18 months now

It is alive and well.

Giovanni

Hi Giovanni,

I would like to ask you if multicore is supported curretly. I noticed mention about new RT7 branch, unfurtunately I don't see it in github. I bought new nucleo with H745, it's M7 - M4 multicore CPU.

I know that priority is new Pico board, just I would like to use chibios with multicore STM32.

Thank you very much for answer.

Hi,

Asymmetric multi core support is not planned, the problem is that M0, M4, M7 etc have slightly different instruction sets, FPU and internal peripherals (requiring different compiler options) so it is not practical to make one OS run on mixed cores.

If you split your application in two distinct executables you can just run 2 instances of ChibiOS RT and/or NIL. The two applications can then communicate and synchronize using the HW semaphores and shared RAM areas.

Giovanni

Hi,

How is the development of this implementation going?

abvg9 wrote:Hi,

How is the development of this implementation going?

It is basically done: viewtopic.php?f=3&t=5800&start=40#p39683

Giovanni

Just a note, RT 7 in trunk is now SMP-able, it has been demonstrated on RP2040.

Giovanni

Hi,

Just sharing some ideas about SMP/multicore support:

Critical Sections

Currently there is a single spinlock used for all kernel structures, it is encapsulated in chSysLock()/Unlock(). This means that using a critical zone always takes the spinlock affecting the other core. This is less than optimal considering that there are kernel structures that are core-private, others are core-shared.

The ready list is shared.
The registry is private (but could become shared, see next points).
The virtual timers list is private, there is one list per core.
The trace buffer is private.
Statistics are private.

Optimizing this would mean having 2 "locked" states:
- Local lock, implements a critical section for the current core only.
- Global lock, implements a critical section for all cores.

The "S" and "I" functions would no more be sufficient, we would need to split those in "SG"/"IG" (global lock required) and "SL"/IL" (local lock sufficient), and the lock functions would become chSysGobalLock()/Unlock() and chSysLocalLock()/Unlock(), this would break compatibility for some APIs.

The above changes would minimize unneeded interactions between different cores improving scalability (note that currently 2 cores are rare, scalability to many cores is not urgent matter).

Registry

Currently we have one registry for each core, threads can only enumerate threads belonging to the same core. It would be nice to have a single registry able to enumerate all threads.

Affinity

It is already possible to associate threads to specific cores, it would be nice to be able to allocate working areas in "preferred" RAMs belonging to the various cores for performance optimization.

Common Ready Queue

Right now threads are statically assigned to specific cores, it would be possible to have a shared ready list for threads without affinity that can be picked up by any idling core. I would make this shared list reserved for low priority threads. This kind of handling would come at cost of reduced kernel performance, rescheduling would require checking 2 queues instead of just one. Global throughput would potentially increase.

The question is: should we release the current implementation or wait to implement all the possible enhancements? this could mean months of delays. Note that 20.x is very good and there is no need to rush IMHO.

Giovanni