Imx8 rpmsg_lite_str_echo demo issues

Technical Support
, ,
1

We’ve been having issues getting our rpmsg functioning between m4 and linux side on the latest Torizon. Today we saw [this]( remote proc kick failed when rpmsg is launched by U-Boot - NXP Community ) which helped us at least get some feedback that our build of rpmsg_lite_str_echo is working (updated MCUXpresso SDK/toolchain). However our own code (which is working with an earlier MCUXpresso SDK/toolchain with a Yocto build) did not work after building with the updated MCUXpresso SDK/toolchain.

But we’re not feeling confident after reading the above link.

Does anyone know any more details about this ? It looks like an upstream NXP issue - is that correct ? We have a deadline looming, and I don’t like to deploy anything in the field with the pd_ignore_unused patch mentioned.

I will have a closer look at our code in the debugger next week, but any feedback in the meantime would be of interest…

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

RPMsg Issues in Torizon OS 7.x

Based on the available information, there have been known issues with RPMsg functionality in Torizon OS 7.x that align with what you’re experiencing.

Known Issues and Resolution

There was a regression in Torizon OS 7.x where the /dev/ttyRPMSG30 device was not being created properly (1). This issue was identified and resolved by the Toradex team - there was a small error in the device tree overlay due to changes in the driver in the new kernel version (1).

The overlay has been adjusted and the fix is available in the device tree overlays repository (1). This suggests that the issue you’re experiencing may be related to this known regression rather than requiring the pd_ignore_unused patch mentioned in the NXP community post.

Recommended Troubleshooting Steps

1. Verify Device Tree Overlay Configuration

Ensure you’re using the correct HMP overlay for your module (2):

  • For Verdin iMX8M Plus: verdin-imx8mp_hmp_overlay.dts
  • For Verdin iMX8M Mini: verdin-imx8mm_hmp_overlay.dts

2. Check RPMsg Driver Registration

Verify the RPMsg driver is properly registered (2):

# dmesg | grep -i rpmsg
[    0.045742] imx rpmsg driver is registered.

3. Load the RPMsg TTY Module

After confirming proper driver registration (2):

# sudo modprobe imx_rpmsg_tty

4. Verify Device Creation

Check if the RPMsg devices are created (2):

# ls /dev/ | grep -i rpmsg
rpmsg_ctrl0
ttyRPMSG30

MCUXpresso SDK Considerations

When using updated MCUXpresso SDK versions, ensure you’re following the proper compilation process (3). The memory buffer reservations and resource table configurations must match between the Cortex-M firmware and the Linux device tree overlay (2).

The key memory addresses for RPMsg communication are defined in the MCUXpresso SDK and must align with the device tree overlay configuration (2).

Alternative Communication Methods

If RPMsg continues to cause issues, consider using shared memory communication as an alternative approach (4). This method doesn’t rely on RPMsg drivers and provides direct memory access between cores.

Given your deadline concerns, I’d recommend first updating to the corrected device tree overlay and testing with the standard RPMsg examples before implementing the NXP workaround patch.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hey, @Timo,

I talked with our BSP team, and it looks like this issue is not present in the mainline kernel, so it will not be seen in future versions of Torizon. There are currently two workarounds, setting the pd_ignore_unused kernel argument on U-Boot, as you said, is one of them. As a second option, you can start the Cortex M binary via remoteproc, and the issue should not be present then.

Let me know if this solves the issue.

Best regards,

4

Thanks for the feedback - hopefully the fix will be incorporated sooner rather than later :wink:

We are using the pd_ignore_unused kernel workaround for now. If I understand correctlyremoteproc is not an option for us on the iMX8 :-/

On the other hand, we have now had some success with out in-house code, after I sorted out removing UART_B, which it uses, from the linux device tree (with an overlay kindly provided by somebody in the forum :+1:).

1 Like