search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.98k stars 6.68k forks source link

How do we support an SoC that mixes ARM and RISCV? #78222

Closed soburi closed 2 weeks ago

soburi commented 2 months ago

The RP2350 (RaspberryPi Pico2) has two cores, ARM and RISCV, and can run the ARM and RISCV cores simultaneously. I think it will be difficult to support this elegantly with the current Zephyr mechanism, so I will first raise the issue.

Related #77368

nashif commented 2 months ago

wasnt this the main reason why we introduced hwmv2? We have some of those SoC in the tree already if I am not mistaken. @tejlmand FYI...

ajf58 commented 2 months ago

I think this is a discussion not issue at this stage, should this move?

wasnt this the main reason why we introduced hwmv2?

51831 for context.

RP2350 has 4 cores in total: 2 Arm Cortex M33 cores, and 2 RISC-V Hazard3 cores. The SoC can support running any permutation (M33 in core 0, Hazard3 in core 1, etc), but Raspberry Pi's documentation suggests that a Heterogeneous/SMP is expected to be the common use case.

My starting gambit would be that the SoC is defined as containing two clusters, one for the M33s, and one for the Hazard3s. At build-time the user specifies the "board" with the existing mechanism, e.g.

west build -b rpi_pico2/rp2350/m33 samples/hello_world

and

west build -b rpi_pico2/rp2350/hazard3 samples/hello_world

following the idiom used elsewhere regarding naming of CPU clusters.

tejlmand commented 2 weeks ago

wasnt this the main reason why we introduced hwmv2? We have some of those SoC in the tree already if I am not mistaken.

yes, detailed explanation follows.

The RP2350 (RaspberryPi Pico2) has two cores, ARM and RISCV, and can run the ARM and RISCV cores simultaneously. I think it will be difficult to support this elegantly with the current Zephyr mechanism, so I will first raise the issue.

Yes, so HWMv2 allows you to describe the SoC with two CPU clusters, https://docs.zephyrproject.org/latest/hardware/porting/soc_porting.html. Then a normal Zephyr build can target either of those clusters as is described in https://github.com/zephyrproject-rtos/zephyr/issues/78222#issuecomment-2349330507

Together with HWMv2 then sysbuild can be used to further give a good multi-image integration.

The Adding Zephyr applications to sysbuild section describes how an application can define extra images to build, for example adding a special image build for the other core, so that when a user does:

$ west build -b rpi_pico2/rp2350/m33 --sysbuild <application>

then two or more images are being built, for both the: rpi_pico2/rp2350/m33 and the rpi_pico2/rp2350/hazard3.

An example of such approach can be seen in https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/bluetooth/peripheral_hr/Kconfig.sysbuild where building for a like nRF5340 SoC with two cores will build the bluetooth sample (host) for the cpuapp cluster, and a second build with hci_ipc image is built for the the cpunet cluster.

In this example the two cores are the same architecture, but same principle is used when they are of different architectures. Default the same toolchain, such as zephyr SDK is used for both CPU clusters, as Zephyr SDK supports many architectures.

But it is also possible to target different toolchains for different images (and thus CPU clusters) like this:

$ west build -b rpi_pico2/rp2350/m33 --sysbuild <application> -- -DZEPHYR_TOOLCHAIN_VARIANT=zephyr  -D<second_image>_ZEPHYR_TOOLCHAIN_VARIANT=xt-xcc