Required Device Tree modifications for RPMSG on Colibri iMX7D 1GB

[ompie]

Hi all,

I am trying to get RPMSG working on a Colibri iMX7 Dual module.
On the M4 side, I based my code on the ‘ping pong’ example and this seems to start correctly (blocking on rpmsg_rtos_init() while waiting for the Linux side to connect).

After some searches on the Toradex Website, I understand that I have to activate RPMSG by enabling &rpmsg in the device tree and by giving the command sudo modprobe imx_rpmsg_tty.

Modifying the device tree and rebuilding a Torizon (5.6) image is not a problem but I cannot find any reference in the device trees to the &rpmsg item, so just adding

&rpmsg {
   status = "okay"
};

does not work.
There are also threads here that refer to other parts of the device tree to be modified (like here).
I can’t find any of such definitions in the standard dts/dtsi files from your repository.

So my question is, do you have some documentation on what to add (specifically for the Colibri iMX7D 1GB…) to the device tree in order to be able to use RPMSG ?

Any other things that are necessary (like the modprobe command mentioned above) ?

Thanks in advance for your support,

Jeroen

[hfranco.tx]

Hi @ompie,

Before we continue with the support, which kernel are you using, downstream (from NXP) or upstream (mainline kernel)?

Best Regards,
Hiago.

[ompie]

Hello @hfranco.tx ,

I am using Torizon version Tezi_5.6.0+build.13 (planning to go to Tezi_5.7.0+build.17 soon).
So I suppose this is the ‘upstream’ version.

Best regards,

Jeroen

[hfranco.tx]

Hi @ompie,

I’m sorry, you’re correct, TorizonCore uses the upstream version (mainline kernel) for BSP 5.6 and 5.7 (TorizonCore 6 uses the mainline as well).

The demo you’re trying to run

@ompie

modprobe imx_rpmsg_tty

is not available for the mainline kernel. This implementation comes from NXP (downstream kernel) and they’re not included (or they weren’t accepted) on the mainline kernel.

Instead, the mainline kernel supports a different sample from OpenAMP. As said on the OpenAMP readme:

...
3. Compatibility with upstream Linux remoteproc and rpmsg components
...

So, in order to test this feature, one possibility is to compile OpenAMP demos yourself and enable them on the linux kernel side as well (this will also require TorizonCore to be recompiled with Yocto or, if it’s possible, enable this feature as kernel modules and add them with TorizonCore Builder).

Another possibility would be testing these features with Zephyr, although we don’t fully support this option yet. You can take a look at this talk for more information: https://www.youtube.com/watch?v=_6dAPdR2-gU&t=1432s.

I will try to make it work on my side as well, then I can give you more updates if I find something.

Best Regards,
Hiago.

[ompie]

Hi @hfranco.tx,

Thanks for looking at my post!

@hfranco.tx

The demo you’re trying to run

@ompie

modprobe imx_rpmsg_tty

is not available for the mainline kernel. This implementation comes from NXP (downstream kernel) and they’re not included (or they weren’t accepted) on the mainline kernel.

Instead, the mainline kernel supports a different sample from OpenAMP

I admit I’m a bit confused. I’ve seen several other posts on the forum concerning RPMSG and Torizon (this one and this one for instance) and I did not see any mention of Torizon not supporting RPMSG or using OpenAMP. Although re-reading the post again, I could understand that recompilation is necessary (here so it is probably me that did not read correctly).

@hfranco.tx

So, in order to test this feature, one possibility is to compile OpenAMP demos yourself and enable them on the linux kernel side as well (this will also require TorizonCore to be recompiled with Yocto or, if it’s possible, enable this feature as kernel modules and add them with TorizonCore Builder).

Wow ! I was very glad not having to dive into Yocto when I started working on the Colibri (this is my first Toradex project) because of the already steep learning curve (between pin assignments, device trees, docker and containers plus getting the M4 up and running…).

Is there a way to add the necessary kernel module via Torizon Builder ? If so, can you guide me through this ?

I’m also not sure whether the mentioned modprobe imx_rpmsg_tty is the right module or command to use.
All I’m trying to do is make rpmsg working. So perhaps mentioning modprobe triggered an incorrect understanding on your side (I hope so ).

Best regards,

Jeroen

[hfranco.tx]

Hi @ompie,

Sorry for the delay.

I was able to compile the OpenAMP demo with zephyr for the iMX7, with some modifications to the SDK. However I’m still having some errors with the mailbox unit, so I will keep you posted on any news that I have.

@ompie

I admit I’m a bit confused. I’ve seen several other posts on the forum concerning RPMSG and Torizon (this one and this one for instance) and I did not see any mention of Torizon not supporting RPMSG or using OpenAMP. Although re-reading the post again, I could understand that recompilation is necessary (here so it is probably me that did not read correctly).

Let me try to clarify the differences and feel free to ask anything you want.

As you know, we have basically two different Linux kernels: the upstream or mainline, which comes from the Linus Torvalds repository, and the downstream, which comes from NXP. The downstream version has a lot of modifications to support some NXP peripherals that are not yet available or were rejected on the mainline. One good example is the RPMSG.

The mainline kernel uses the OpenAMP implementation, which is an effort to make HMP easier for linux devices, while the downstream use the RPMSG-Lite, which is a protocol created by NXP and it’s not available on the mainline kernel (mainly because the OpenAMP was adopted).

So, basically, if you’re using the mainline kernel, the open-amp is needed on the cortex-m4. However, if you’re using the downstream kernel, you can also use the RPMSG-lite version.

The demos you mentioned (imx_rpmsg_tty, ping-pong…) are all NXP demos with RPMSG-Lite, so they won’t work with the mainline kernel.

Therefore, because of the Upstream First approach from Toradex, for BSP 6 or TorizonCore 6 and Colibri iMX7, only the mainline kernel is available. If you want to use the downstream version, you will need to downgrade to BSP 5.

We’re still working on supporting the OpenAMP on the mainline version, but this is still under discussion/testing.

@ompie

Is there a way to add the necessary kernel module via Torizon Builder ? If so, can you guide me through this ?

Sure, please check this article: TorizonCore Builder Tool “build” command | Toradex Developer Center

I hope the differences are a bit clearer now, sorry for the confusion.

Feel free to ask any questions you might have.

Best Regards,
Hiago.

[ompie]

Hi @hfranco.tx,

Thanks for this detailed answer which makes things a lot clearer. The explanation about upstream/downstream makes a lot of sense.

@hfranco.tx

Therefore, because of the Upstream First approach from Toradex, for BSP 6 or TorizonCore 6 and Colibri iMX7, only the mainline kernel is available. If you want to use the downstream version, you will need to downgrade to BSP 5 or TorizonCore 5 downstream kernel.

I am currently using Torizon 5 (downstream and thus supposed to support RPMsg), while I suspect you were referring to your all-new Torizon 6 Upstream kernel in which RPMsg is replaced with OpenAMP. That’s one of the causes of the confusion and explains there are posts on the forum regarding RPMsg…

I would be happy to upgrade to Torizon 6 but I read some posts in the last few weeks that mentioned some features (e.g. regarding U-Boot) not yet being implemented in Torizon 6 (sorry, I cannot refer to specific posts). And the same appears to apply to OpenAMP as you mention yourself:

@hfranco.tx

We’re still working on supporting the OpenAMP on the mainline version, but this is still under discussion/testing.

So I am very reluctant to do the upgrade right now. I cannot permit myself to loose more time on possibly new issues.

This means that I prefer remaining at Torizon 5 for the moment. Once I have a completely working version of my project, I’ll reconsider upgrading to T6.

The question is now how I get this to work:

• What are the specific device tree modifications/additions to make for the Colibri i.MX7D ?

I suppose I still have to add the imx_rpmsg_tty kernel module to my T5 image ? The Torizoncore Builder article shows how to specify a directory with the source code for the module to add but this doesn’t tell me what to put into that directory.

• Can you elaborate a bit more about this ?

I really appreciate your help !

Jeroen

[hfranco.tx]

Hi @ompie,

@ompie

I am currently using Torizon 5 (downstream and thus supposed to support RPMsg), while I suspect you were referring to your all-new Torizon 6 Upstream kernel in which RPMsg is replaced with OpenAMP. That’s one of the causes of the confusion and explains there are posts on the forum regarding RPMsg…

Actually, as you said earlier

@ompie

I am using Torizon version Tezi_5.6.0+build.13 (planning to go to Tezi_5.7.0+build.17 soon).
So I suppose this is the ‘upstream’ version.

you’re on the mainline version. TorizonCore 5 uses mainline, while with BSP you can choose between downstream and upstream. Sorry if you understood the opposite, I edited my last answer to avoid confusion. TorizonCore you’re mainline, I meant that to use downstream you would need to choose BSP instead.

You can check this article for more details: Torizon OS Technical Overview | Toradex Developer Center

Toradex maintain its BSPs with updated software for bootloader and Linux kernel following mainline. 
An exception may exist for recently launched platforms, where the BSP may contain downstream SoC
vendor components until Toradex recognizes the mainline efforts are mature enough to be deployed 
to production.

I’m still testing the Zephyr version with the OpenAMP on my side, I will get back to you once I have something.

Is RPMsg a requirement for your project? Or do you just want to test it?

I already have an overlay to make the remoteproc work, that I could share if you want and you can test it. But not the RPMSG. Would you like to test it?

Best regards,
Hiago.

[ompie]

Hi @hfranco.tx,

OK, so I’m on the mainline and thus will use OpenAMP. No problem.

@hfranco.tx

Is RPMsg a requirement for your project? Or do you just want to test it?

RPMsg or OpenAMP is absolutely necessary for my project unless you have another solution for me. On the M4, I am sampling 9 ADCs (16-bit) with a sample rate of 100kHz and I have to pass the result (plus a ms-accurate timestamp) to the Linux side.
This is about the only part of the project that still needs work. All the other software is implemented.
Due to relatively the high data rate ( a bit over 2MByte/s), I have to either increase the buffer size (if it is 512 bytes for OpenAMp as it is for RPMsg?) of find a way to share some part of memory between the two processors.

@hfranco.tx

I already have an overlay to make the remoteproc work, that I could share if you want and you can test it. But not the RPMSG. Would you like to test it?

Yes please. Even though I did not plan to use remote procedures, this may actually be useful for setting some parameters on the M4 side and it may also help me getting started with the changes for RPMSG (or the OpenAMP equivalent…)

Best regards,
Jeroen

[ompie]

Hi @hfranco.tx ,
just some additional observations from this weekend:

On the M4 side, the original “ping pong” that came with FreeRTOS uses functions like rpmsg_rtos_init() and rpmsg_rtos_send(). These functions are defined under the FreeRTOS source tree in a directory middleware/multicore/open-amp/rpmsg.
So I think on the M4 side, everything is OK, right ?

Jeroen

[hfranco.tx]

Hi @ompie,

@ompie

n the M4 side, the original “ping pong” that came with FreeRTOS uses functions like rpmsg_rtos_init() and rpmsg_rtos_send(). These functions are defined under the FreeRTOS source tree in a directory middleware/multicore/open-amp/rpmsg.
So I think on the M4 side, everything is OK, right ?

Although this is a version of open-amp, this comes from NXP, so I can’t tell if there are modifications inside that were done to make it compatible with their demos, like the tty or the ping pong. Were you able to test it?

On my side, just a quick update, I could compile the open amp demo as mentioned earlier, but I couldn’t make it work yet. I will give you updates once I have something.

Best Regards,
Hiago.

[ompie]

Hello @hfranco.tx !

@hfranco.tx

Although this is a version of open-amp, this comes from NXP, so I can’t tell if there are modifications inside that were done to make it compatible with their demos, like the tty or the ping pong. Were you able to test it?

I’m not able to test it since the Linux part is missing… (which is the initial question of this thread).
So I did not come any further than being able to compile my code with the appropriate function calls and run it until it blocks on rpmsg_rtos_init() (printing “RPMSG Init as Remote” as in the original demos).

@hfranco.tx

On my side, just a quick update, I could compile the open amp demo as mentioned earlier, but I couldn’t make it work yet. I will give you updates once I have something.

Thanks for looking into it. I hope it won’t take too long for you to make it work (both for you and for me )

Best regards,
Jeroen

[ompie]

Hi @hfranco.tx,

I hope you’re doing well!
Were you able to make some progress on your side ?
Here, I ran into some new “challenges” on the M4 side concerning memory usage and performance. Initially, all my code ran in TCM and I managed to execute the time critical part of my code in time (reading 6 words from ECSPI every 10µs). But calling the FreeRTOS “notification” from interrupt sometimes makes it exceed 10µs by quite a lot. So I am considering going bare metal. This would also mean using the RPMSG/OpenAMP without FreeRTOS.

Best regards,
Jeroen

[hfranco.tx]

Hi @ompie,

No luck from my side on the RPMsg yet. I’ve also searched the supported NXP zephyr examples, but they don’t support RPMsg yet, unfortunately. For now, while we still didn’t figure out how to work with RPMSG and mainline, the best approach I believe would be to downgrade the BSP 5 (not TorizoCore) to use the RPMSG with the downstream kernel. Of course, this is also a problem, because you want to use TorizonCore and TorizonCore uses the mainline kernel but that would be a possibility. I opened a ticket internally to investigate this issue with our team and check what would be the best approach to work with the mainline, but I don’t have any updates right now.

@ompie

But calling the FreeRTOS “notification” from interrupt sometimes makes it exceed 10µs by quite a lot. So I am considering going bare metal. This would also mean using the RPMSG/OpenAMP without FreeRTOS.

This is a possibility, to use the M4 without any OS, however, I believe going with FreeRTOS or another RTOS will guarantee that your tasks are being executed properly and also make the development more scalable. Have you checked if it’s possible to configure your FreeRTOS to overcome this issue?

Best Regards,
Hiago.

[ompie]

Hi @hfranco.tx,

@hfranco.tx

No luck from my side on the RPMsg yet. I’ve also searched the supported NXP zephyr examples, but they don’t support RPMsg yet, unfortunately. For now, while we still didn’t figure out how to work with RPMSG and mainline, the best approach I believe would be to downgrade the BSP 5 (not TorizoCore) to use the RPMSG with the downstream kernel. Of course, this is also a problem, because you want to use TorizonCore and TorizonCore uses the mainline kernel but that would be a possibility.

That’s a pity. I didn’t expect to be the first one to use RPMSG with TorizonCore 5.x. !
If there is no guaranteed solution in the (very) near future (I’m already very late with the delivery of the project), then the best way to go is BSP 5. I don’t know exactly what this implies yet but if this guarantees that RPMSG will work, then it is the way to go.
Any pointers to articles on the Toradex web site for all that step necessary will be welcome…

@hfranco.tx

This is a possibility, to use the M4 without any OS, however, I believe going with FreeRTOS or another RTOS will guarantee that your tasks are being executed properly and also make the development more scalable. Have you checked if it’s possible to configure your FreeRTOS to overcome this issue?

I did not dive into FreeRTOS configuration yet concerning the issue. But I believe it is linked to the fact that if I give a notification, FreeRTOS has to do some context switching to prepare the notified task for execution. And this all takes place during my interrupt.
Going bare metal is not a problem for me. Most of the projects I do are bare metal. So I have my ideas of how to get this work.

Best regards,
Jeroen

[hfranco.tx]

Hi @ompie,

@ompie

That’s a pity. I didn’t expect to be the first one to use RPMSG with TorizonCore 5.x. !
If there is no guaranteed solution in the (very) near future (I’m already very late with the delivery of the project), then the best way to go is BSP 5. I don’t know exactly what this implies yet but if this guarantees that RPMSG will work, then it is the way to go.
Any pointers to articles on the Toradex web site for all that step necessary will be welcome…

Requests for HMP in general are increasing, but still, it’s not something popular yet. Despite that, I’m trying to track every request so we can speed up the HMP adoption. Unfortunately, we’re not there yet, but I will let you know of any changes.
I will be happy to help you with the downstream kernel. Feel free to tag me @hfranco.tx on any requests.

@ompie

I did not dive into FreeRTOS configuration yet concerning the issue. But I believe it is linked to the fact that if I give a notification, FreeRTOS has to do some context switching to prepare the notified task for execution. And this all takes place during my interrupt.
Going bare metal is not a problem for me. Most of the projects I do are bare metal. So I have my ideas of how to get this work.

Ok, I believe there are some demos that use rpmsg bare metal on our FreeRTOS repository that can help you with the code.

Best Regards,
Hiago.

[ompie]

Hi @hfranco.tx ,

@hfranco.tx

I will be happy to help you with the downstream kernel. Feel free to tag me @hfranco.tx on any requests.

Thanks ! This afternoon (at least in France), I opened a new topic after I started working on BSP5.7.
Perhaps you can have a look.

Otherwise, I think you can close this post (I don’t know how to do this without marking a reply as “solution” which would be a bit strange for an issue that is not solved (for TorizonCore)

Best regards,
Jeroen