Colibri IMX7D HMP

Technical Support
, , , ,
1

Hello,

As written in the documentation: Cortex-M RPMsg Guide | Toradex Developer Center the device I want is not available yet. I would like to have to have a device tree for imx7d with the evaluation board as example.

I already have a HMP working with RPmsg but with an older kernel version. It works with a kernel version 4.9 and BSP version 2.8b7.

I also found this: fsl,imx-rproc.yaml - Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml - Linux source code v6.1.55 - Bootlin Elixir Cross Referencer in the kernel documentation. But I also need the right firmware running on the m4.

Any example with a working RPMsg would be great, as I need to upgrade the linux kernel. I had to follow the EU resilient Act.

Best Regards,

Arnaud

PS: your SOMs are amazing, we’ve been using them in production for 5 years without any big issues.

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello Arnaud,

Thank you for your kind words about our System on Modules (SOMs). We’re delighted to hear about your positive experience with them in production.

To update your Colibri iMX7D setup for RPMsg with a newer Linux kernel, you’ll need to adjust the device tree to allocate the necessary RAM buffers for RPMsg.

Steps to Update the Device Tree

  1. Device Tree Overlays: Utilize device tree overlays provided by Toradex, which can simplify enabling RPMsg. Ensure you select the overlay that matches your BSP version.

  2. Manual Device Tree Updates: If manual updates are needed, verify that the memory regions for RPMsg are correctly defined in the device tree source files. This involves setting the appropriate memory addresses and sizes.

  3. Compiling and Applying Overlays: After making the necessary modifications, compile the device tree into a blob (.dtbo) and apply it to your system.

Verifying RPMsg Functionality

Once the device tree is updated and your module is rebooted, check the dmesg log to confirm the RPMsg driver is registered correctly. Look for messages indicating the establishment of RPMsg channels.

Testing RPMsg

To test the setup, you can run RPMsg TTY or Ping Pong demos. Compile these demos using the MCUXpresso SDK and load them onto your module. Verify communication between Linux and Cortex-M by checking the debug UART and dmesg logs for expected outputs.

By following these steps, you should be able to upgrade your system while maintaining RPMsg functionality and complying with the EU Resilient Act.

Best regards,

Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Is there a timeline for updating yocto repo manifest for latest yocto and Linux kernel?.

4

Hi @arnaud_mc !

As you correctly noticed, currently we don’t have a ready-to-use device tree overlay to HMP for Colibri iMX7D on Torizon OS / BSP 7.

I am checking internally if there is any update on it.

In parallel, have you checked the following article? This might be helpful to you.

This bit I didn’t understand. Could you please elaborate on the “right firmware”?

Best regards,

5

Hello @henrique.tx,

Thank you for the quick response,

I mean the right firmware according to me, means that the firmware for the cortex-m4 that works with the corresponding driver for the cortex-A7. My project is already running with the old BSP 2.87b7 with a downstream kernel. As well as the example. To implement the HMP, I just started with the examples there: rpmsg « demo_apps « imx7_colibri_m4 « examples - freertos-toradex.git - FreeRTOS for the Cortex M4 core of Heterogeneous Multicore modules

All the examples work with the old BSP. In the ideal world, I would need exactly the same examples running with an upstream kernel. This way I would just adapt the firmware for the m4 for our use case.

According to my research, there are two different implementations of the protocol: OpenAMP RPMSG and RMSG-Lite. One works with the downstream kernel and the other with the downstream one.

Our application with HMP has been working for more than 3 years without any issues. The only problem is that I have to upgrade the kernel to follow the EU cybersecurity standard.

I’m looking forward to getting any updates from you,

Best regards,

Arnaud

6

Hi @arnaud_mc !

Understood.

I need to invest some time on it to test and understand what is the current status. And most probably involve R&D.

Being realistic, this might take some time.

Would you be able to share your timeline so I can understand how urgent it might be for you?

Best regards,

7

Hello @henrique.tx ,

Take the time you need, I wouldn’t say it’s an emergency but it’s really important. Currently it’s my first priority. I understood that might involve R&D work. I don’t have any deadline yet, but since 2021 we ordered 1300 Colibri iMx7D. This year we will order 300 more.

In the ideal case I will need this upgrade by the end of March for 1300 Colibri. The upgrade will also solve some problem we faced with eMMc.

As R&D engineer, I totally understand it may become very hard to estimate the time to solve this. I’m ready to share any useful information.

Although the Cybersecurity act and some eMMc issues, our products based on the Colibri works very well. Because of the success, the order volume of Colibri might increase a lot.

Our Colibri based products success has exceeded our expectation. I even shared the success story at a seminar: https://www.youtube.com/watch?v=1-H1pMlI0S8

Best regards,

Arnaud S.

8

Hi @arnaud_mc !

Thank you for sharing the information and for your transparency. Appreciate it :slight_smile:

I brought up this topic internally, and discussed it with one of our Domain Experts. It became clear that the challenge with Colibri iMX7 is the fact that it is not clear how the upstream support to RPMsg/Remoteproc stands. Seems like it is there, but research and tests are needed.
Also, even if it is there and it is “healthy” from Linux/Cortex-A point of view, the challenge now extends to Cortex-M’s side.

NXP MCUXpresso’s FreeRTOS supports RPMsg-Lite, which is a different implementation from upstream’s RPMsg (as you correctly noted). So some implementation on Cortex-M’s side is anyway needed. To implement something compatible with upstream’s RPMsg on FreeRTOS, you can look at Zephy’s Cortex-M side implementation.

And, since talking about Zephyr, it could an interesting option. As we can see from i.MX 7 Computer on Module - Colibri iMX7 — Zephyr Project Documentation, it even has a demo to communicate via RPMsg between Zephyr on Cortex-M and upstream Linux on Cortex-A.

Since you are already on FreeRTOS, effort would need to be invested on porting your project to Zephyr.

Summarizing, seems like there won’t be a “free meal” available. :confused:

Please note that I am sharing all this without putting too much effort on reeeally testing stuff. So please take it with a grain of salt.
If much effort is needed, we can always recommend you a Toradex Partner with proven experience on this specific topic. Or you can find one yourself, of course: Embedded Computing | Hardware & Software Service Partners

It is possible that we find more information about it. If we do, I will surely update you here :wink:

And talking about timeline, since we are approaching Embedded World 2025, preparations are going strong. So most probably we will have more time to look at Colibri iMX7 HMP after the show. If you happen to attend EW2025, please come visit us at our booth: Embedded World 2025, Germany | Toradex. We will have very nice demos to show you :smiley:

Best regards,

9

Hello @henrique.tx ,

I will see the Zephyr documentation you gave me. I will try to boot zephyr on the Cortex-m4 to make the example works.

The thing that scares me, I use an interruption. I don’t know whether the hardware abstraction will cause me problems. FreeRTOS is not as complex as Zephyr. You can directly write to the microcontroler registers without any issues.

As soon as I have zehpyr example working, I will decide either to migrate the upstream driver to FreeRTOS or to migrate my application to Zephyr.

I’d rather keep the upstream kernel. I will have more control on the update. The downstream kernel update seems less reliable.

Best Regards,

Arnaud