soc: rp2350: Add basic Asymmetric Multiprocessing (AMP) support

[dancollins]

I have a project using the RP2350, and figured it would be cool to run Zephyr on both cores. I have got a basic sample working that has both cores running Zephyr and printing a message on their respective UARTs.

I have noticed the reset controller, as an example, makes use of read-modify-writes that will not be compatible with my AMP setup. This, along with other peripherals, will need to either have hardware locking (RP2350 includes a hardware spinlock) or atomic access (RP2350 has memory addresses for atomic set/clear).

No doubt issues will crop up as I use this implementation - so I will keep it in draft status until I stop needing to make any changes to it. I intend on being able to demonstrate an OpenAMP sample running, as this should provide all the basic functionality needed for AMP.

[josuah]

The CI error message:

/__w/zephyr/modules/hal/rpi_pico/src/rp2_common/hardware_base/include/hardware/address_mapped.h:124:27: error: implicit declaration of function 'typeof' [-Werror=implicit-function-declaration]
  124 | #define hw_xor_alias(p) ((typeof(p))hw_xor_alias_untyped(p))
      |                           ^~~~~~
/__w/zephyr/modules/hal/rpi_pico/src/rp2_common/hardware_flash/flash.c:302:6: note: in expansion of macro 'hw_xor_alias'
  302 |     *hw_xor_alias(devinfo) = (*devinfo ^ wdata) & mask;
      |      ^~~~~~~~~~~~
/__w/zephyr/modules/hal/rpi_pico/src/rp2_common/hardware_base/include/hardware/address_mapped.h:124:27: error: called object is not a function or function pointer
  124 | #define hw_xor_alias(p) ((typeof(p))hw_xor_alias_untyped(p))
      |                          ~^~~~~~~~~~
/__w/zephyr/modules/hal/rpi_pico/src/rp2_common/hardware_flash/flash.c:302:6: note: in expansion of macro 'hw_xor_alias'
  302 |     *hw_xor_alias(devinfo) = (*devinfo ^ wdata) & mask;
      |      ^~~~~~~~~~~~
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.

It looks like C language features used in RPi SDK are getting in the way.

[josuah]

The documentation says the developer toolchain should require at least C11, so this might require a bit of discussion.

@soburi may I request your advise?

[dancollins]

Hopefully patch in #90939 help fix the tests!

[dsseng]

just some thoughts

[dsseng]

Perhaps needs some more DT-centric approach as I've discussed in Discord

[dsseng]

Because there are other parts like clock and reset controllers for peripherals

[dancollins]

I have split this out into three commits for now - this makes it easier to track what's going on. I've also removed the changes to the various samples/tests as I really like @dsseng's idea to avoid forcing the _cpu0 label onto all the non-AMP builds.

I also like the idea of using the device tree for disabling the clock init, rather than the Kconfig symbol I have. I'm not sure how to do that exactly - whether it's a special compat for the second core, or just a flag.

[dsseng]

As we discussed with @dancollins on Discord, I'll do some work, including implementing my proposed changes and perhaps IPM on my branch and notify here when some major progress is there

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud