RPMSG doesn't work on iMX8QXP after update to BSP 7.1

Technical Support
, ,
1

Hi,

after upgrading from BSP 6.3 to 7.1, RPMSG stopped working on iMX8QXP, imx-rpmsg ends up “probe deferred” and no ttys open.

We’re using low level stuff from BSP (u-boot, SCU, ATF, etc.), kernel is based on the same commit as the BSP one, config is custom. Device tree is inspired by Toradex dtbs. Userspace is customized Debian.

RPMSG in dtb is configured in the same way as your hmp overlay (colibri-imx8x_hmp_overlay.dts « overlays - device-tree-overlays.git - Sources for Device Tree Overlays). From looking at the kernel prints it seems driver imx-rpmsg can’t find mailboxes provided by lsio_mu5. It looks like that message unit is not available/registered/turned on or something?

Weirdly in dmesg, there is error:
mu_a1: failed to power off resource 214 ret -22

The resource 214 is power domain of M4, I don’t what’s trying to turn it off and why. It just seems SCU refuses. I’m not sure if it’s related to my problem.
Someone was asking here:
https://community.nxp.com/t5/i-MX-Processors/dmesg-error-quot-mu-a1-failed-to-power-off-resource-214-ret-22/m-p/1964426
I tried to check dtb according to it, but still it didn’t work and that pertains to remoteproc instead of rpmsg anyway (I’m presuming I’m still supposed to use rpmsg and not remoteproc node for this SoC).

Any ideas or solutions? For now I’m thinking looking at SCU serial port if something would clue me in, but it seems a bit of long shot.

Thanks and best regards,
Marek

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!

To ensure RPMsg operates correctly on your Colibri iMX8X, please follow these steps:

  1. Apply the Correct Device Tree Overlay: Make sure the Colibri iMX8X HMP overlay is applied. This overlay is crucial for configuring RPMsg on the iMX8X. You can find it in the device-tree-overlays repository here.

  2. Verify RPMsg Driver Registration: After applying the overlay and rebooting your system, check if the RPMsg driver is registered by running the following command:

    dmesg | grep -i rpmsg

    You should see a message indicating “imx rpmsg driver is registered.” More details can be found here.

  3. Ensure Proper Memory Allocation: The memory regions for RPMsg must be correctly allocated in the device tree. Here are the key memory addresses that need configuration:

    vdev0vring0: vdev0vring0@b8000000 {
    reg = <0 0xb8000000 0 0x8000>;
    no-map;
};

vdev0vring1: vdev0vring1@b8008000 {
    reg = <0 0xb8008000 0 0x8000>;
    no-map;
};

    You can refer to the detailed guide here.

Regarding the specific error about resource 214 and MU5, this might indicate a conflict in the power domain configuration. This issue has been noted in community discussions, particularly with BSP 7.1. To address this:

  • Double-check that the device tree overlay is correctly applied.
  • Confirm the RPMsg driver registration as mentioned above.
  • Ensure the memory allocation for RPMsg communication is accurate.

If the problem continues, you may need to delve into the power domain configuration within your custom device tree.

I hope this helps resolve your issue!

Best regards,
Toradex AI Assistant.

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

Cortex-M RPMsg Guide | Toradex Developer Center.

3

Dear @marekh,

Thank you for providing this information. That is an interesting situation. May I ask if you have checked whether the M4 itself is running? I am asking this, because if not, then RPMSG will not work either unfortunately, which would explain this behaviour.

One further question that poses itself is how exactly you start the M4. Could you explain this to me so we get a better grasp of the situation?

Best regards,
Collin

4

Hello Collin,

sorry for late response, there were some other priorities. M4 is running for sure, I see printouts over serial port. M4 thread dealing with RPMSG is waiting for rpmsg_lite_is_link_up (from mcuxpresso SDK) to return true - this happens after Linux sets it up.

M4 is started through u-boot (bootaux). Since parts of the firmware are in DDR, I’m not sure if starting it through the remoteproc is even an option.

Marek

5

Dear @marekh,

Thank you for letting us know. We have noticed that you are not the only one experiencing these issues, so I have escalated this matter and will get back to you as soon as I have any valid solution.

Best regards,
Collin