Add support for the Raspberry Pi Compute Module 4

[fkromer]

Is this request related to a missing driver support for a particular hardware platform, SoC or board? Please describe.

It seems like the Raspberry Pi Compute Module 4 is not supported yet.

Describe why you are asking for this support?

Describe why you are asking for this support instead of contributing it directly to the tree

I'd like to try Zephyr on this hardware in my spare time. I'm not experinced in adding HW support to Zephyr.

If this is a new board or SoC, please state whether you are willing to maintain the Zephyr support for it if it is included in the main tree.

I'm not experienced with the device model and device tree (yet)... no.

Additional context

Add any other context or graphics (drag-and-drop an image) about the hardware here.

Raspberry Pi Compute Module 4

[fkromer]

As #25182 has been closed there is probably no interest in adding support for the CM4...

As far as I can see, the main reason for one to choose Raspberry Pi over, for instance, Arduino is to run Linux. I wonder if there is any reason why one would want to run Zephyr on it.

However processing power and determinism are other things to consider.

The CM4 provides 4 Cores with 1.5 GHz each which is way more processing power than even the most powerful Arduino boards offer. For comparison: The most powerful Arduino processor seems to be the (Portenta H7) is way less powerful:

H7's main processor is the dual core STM32H747 including a Cortex® M7 running at 480 MHz and a Cortex® M4 running at 240 MHz. The two cores communicate via a Remote Procedure Call mechanism that allows calling functions on the other processor seamlessly.

Zephyr OS does support Symmetric Multiprocessing and supports Asymmetric Multiprocessing as well. Means one would benefit from 2 additional cores for parallelizing processing in comparison to Portenta H7.

In addition the degree of determinism one can achieve using a RTOS is better than the degree of determinism one can achieve with GPOS (general purpose operating systems). Embedded Linux is way more deterministic than other GPOS (like e.g. Windows). On the other side achieving "good" deterministic behaviour may be easier to achieve using a RTOS instead.

Another thing to note here is that the Compute Module 4 is targeting at industrial applications whereas Arduinos are seen as rapid-prototyping solutions only usually.

[stephanosio]

In addition the degree of determinism one can achieve using a RTOS is better than the degree of determinism one can achieve with GPOS (general purpose operating systems). Embedded Linux is way more deterministic than other GPOS (like e.g. Windows). On the other side achieving "good" deterministic behaviour may be easier to achieve using a RTOS instead.

The current industry-wide trend is to do either one of the following:

1. Use a SoC that integrates both high performance cores (with Linux for heavy processing) and low performance cores (with RTOS for I/O and other real-time/safety-critical tasks) -- e.g. TI AM6548 (4x Cortex-A53 + 2x Cortex-R5)
2. Use a SoC that supports virtualisation, and run both Linux and RTOS in a hypervisor that guarantees RTOS's time share (e.g. ACRN).

[fkromer]

@stephanosio In general you are right. I'm just not quite sure if the Raspberry Pi Compute Module 4 satisfies the system requirements of ACRN.

[stephanosio]

I'm just not quite sure if the Raspberry Pi Compute Module 4 satisfies the system requirements of ACRN.

ACRN does not support ARM, though there are other commercial closed source real-time safety hypervisor solutions out there that do.

I am just pointing out that supporting Raspberry Pi in the Zephyr RTOS is quite pointless and there are better/more suitable solutions for the applications you described.

Even if we manage to get Zephyr RTOS running on the Raspberry Pi, it will be quite useless because Zephyr lacks the software stack necessary to fully take advantage of the resources available on it.

We could try adding to Zephyr the very features that make Linux a better/more attractive option, but that would simply result in us re-inventing Linux, which is not really what we are trying to do.

[fkromer]

ACRN does not support ARM, ...

Thanks. Didn't know that.

... though there are other commercial closed source real-time safety hypervisor solutions out there that do.

Right.

Even if we manage to get Zephyr RTOS running on the Raspberry Pi, it will be quite useless because Zephyr lacks the software stack necessary to fully take advantage of the resources available on it.

We could try adding to Zephyr the very features that make Linux a better/more attractive option, but that would simply result in us re-inventing Linux, which is not really what we are trying to do.

I understand.