Cortex-M SMP support for Raspberry Pi Pico

[carlescufi]

Is your enhancement proposal related to a problem? Please describe.

SMP in Cortex-M is not currently supported at all, and in particular for the RPi Pico.

Describe the solution you'd like

Implement SMP specifically for Cortex-M on the RPi Pico.

Additional context

Requires that the aarch32 architecture transitions to USE_SWITCH so this is blocked by #19932

Some additional required PRs:

• RFC: arch: arm: Remove aarch32 directory and split Cortex-M and Cortex-A/r code #60031
• arch: arm: aarch32: USE_SWITCH implementation for Cortex-A #60599
• arch: arm: Introduce SMP support for Cortex-A/R #61206

CC @ithinuel @SgrrZhf

### Tasks

[thedjnK]

There was a discussion on discord about this whereby it was mentioned that the pico SMP support was essentially bespoke to the pico because SMP support on ARM is not an official feature, are there any other similar ARM SMP cores where parts could be shared or would it be entirely for this CPU only?

[carlescufi]

There was a discussion on discord about this whereby it was mentioned that the pico SMP support was essentially bespoke to the pico because SMP support on ARM is not an official feature, are there any other similar ARM SMP cores where parts could be shared or would it be entirely for this CPU only?

Yes, that's correct. The only other chip I know combining Cortex-M with SMP is the Sony Spresense:
https://developer.sony.com/spresense/

Regarding whether the code could be shared, I will leave that to the implementer. I certainly hope it is possible!

[danielallstar]

Hey all,

I am using the Raspberry Pi Pico in combination with Zephyr and want to make use of the 2nd core to run a function.
My initial thought was using SMP functionality within Zephyr to assign a working thread on both cores.
To my suprise however I found out that for the Raspberry Pi Pico only 1 core is defined.

My second thought if this functionality is not supported was to make use of the Raspberry Pi SDK, since
the SDK contains functionality to map a function call to the 2nd processing core.
The Pi Pico SDK HAL is available in the modules folder, but I can however not manage to include the right
files.

Does anybody know how to make use of both processing cores within Zephyr?

Any help will be much apreciated!

@carlescufi @ithinuel @thedjnK @soburi

[soburi]

Hi, @danielallstar

Does anybody know how to make use of both processing cores within Zephyr?

The simple answer is "not yet worked".

We use the PicoSDK driver part only.
The PicoSDK's boot code that including SMP setup are not used by zephyr.
We need to enhancing the boot code for supporting Cortex-M SMP , but not yet completed.

[danielallstar]

@soburi, Thank you for your response. It is much appreciated!

If I understand correctly you do make use of the PicoSDK driver in Zephyr?

The PicoSDK hal files (HAL_PI_PICO) are loaded in the modules folder within Zephyr containing the needed multicore.h file to make use of the second core.
I do however not manage to include the multicore.h file from these files.
How did you manage to get the PicoSDK working within Zephyr?

Kind regards,

Daniël

[ithinuel]

Hi @danielallstar ,

With regards to SMP support, the implementation is not as straight forward for Cortex-M0/+ as it may be for newer armv7m or armv8m.
Because Cortex-M0/+ lack the exclusive monitor implementation, the core cannot be soundly synchronised using a shared memory based spinlock as the Kernel currently relies on.
To enable SMP on the rp2040, some changes are required in the kernel to enable SoC specific synchronisation primitive (eg using the Spinlocks available in the rp2040's SIO block).

[warasilapm]

@ithinuel I haven't been as locked in on this as I maybe want to have been - wasn't there a draft PR for this SoC kernel extension somewhere?

[rhvarrier]

Hi @danielallstar ,

With regards to SMP support, the implementation is not as straight forward for Cortex-M0/+ as it may be for newer armv7m or armv8m.
Because Cortex-M0/+ lack the exclusive monitor implementation, the core cannot be soundly synchronised using a shared memory based spinlock as the Kernel currently relies on.
To enable SMP on the rp2040, some changes are required in the kernel to enable SoC specific synchronisation primitive (eg using the Spinlocks available in the rp2040's SIO block).

Hi

Isn't there support for AMP either. As this could allow to use the second even though its not as ideal?