Verdin Mini RPMSG imx_rpmsg_tty Issue

Hi,
I am trying to run the rpmsg_lite_str_echo_rtos example from the mcuxpresso SDK examples. I am using Verdin Mini with TorizonCore with evaluation containers. After inserting the imx_rpmsg_tty kernel module (I had to use sudo modprobe imx_rpmsg_tty instead of just modprobe imx_rpmsg_tty btw) I am not able to reach it:

verdin-imx8mm:~$ echo test > /dev/ttyRPMSG30
-sh: /dev/ttyRPMSG30: Permission denied

There are also no ttyRPMSG devices:

verdin-imx8mm:~$ ls /dev/ttyRPMSG*
ls: cannot access ‘/dev/ttyRPMSG*’: No such file or directory

This also means that the M4 debug output halts after the initial message:

RPMSG String Echo FreeRTOS RTOS API Demo…

Here is the additional kernel information:

verdin-imx8mm:~$ uname -a
Linux verdin-imx8mm-06944123 5.4.161-5.6.0+git.0f0011824921 #1-TorizonCore SMP PREEMPT Fri Mar 25 14:27:29 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

Thanks in advance for any help!

Hi @swiss,

Thanks for your message. I’m aware of some problems related to Verdin and the RPMSG.
I’ll have to take a deeper look into that. Did you make any modifications to your device tree or some configuration that you can share?

I’ll reply to you as soon as I have something here on my side.

Best Regards,
Hiago.

hi @hfranco.tx,
I made no changes to the device tree. I’m looking forward to your findings.
Best Regards

Hi @swiss,

I talked with some colleagues here and RPMsg doesn’t work with Verdin yet. There is a problem related to Verdin and it’s already being tracked here: Toradex System/Computer on Modules - Linux BSP Release

I have a preliminary overlay that we are working on to fix this issue. I think it works but I’ll have to try it first and check with our team if I can send it to you, just for testing.

Best Regards,
Hiago.

Hi,
Thanks for the response. We already bought 10 Verdin boards and are trying to develop a real time sensor readout over spi. Our idea was to use the M chip for the data acquisition and A chip for the management and further communication (the user can for example download all the data over USB). This will require the communication between two cores. If the rpmsg is still not viable solution, can you suggest some other solution for our design?

Hi @swiss,

Ok, in this case, let me check this overlay that I have here, maybe need some adjustments since it is not finished yet, then I can send it to you if it works.

You could connect the SPI or I2C from the Cortex-M to the Cortex-A externally using some jumper wires. But I’ve never tested this before, it’s just something that I think it should work. However, the RPMsg would be the best way to go with.
Let me first test this for you, then I will come back with something.

Be aware that if you’re looking for a real-time approach, probably you will need to do some kind of data processing in your Cortex-M because even if you use the RPMsg the Linux Kernel will be much slower than the Cortex-M by default.

Best Regards,
Hiago.

1 Like

Hi @swiss,

I have an update on this topic. I’ve been trying to use this overlay that I mentioned and it is not working yet. We still have some work to do on it. I will let you know as soon as I have something.

In the meanwhile, I will try to find a different way to communicate between the two cores. I guess it can be achieved by using a shared memory space between the two cores, but I’ve never tested it.
I’ve also posted a question on the NXP forum that you can find here: https://community.nxp.com/t5/i-MX-Processors/Reset-and-Updated-Cortex-M4-from-Cortex-A/m-p/1484935#M192209

Best Regards,
Hiago.

1 Like

Hi @swiss,

I apologize for the long delay. I could finally take a deeper look into this and it wasn’t quite easy, that’s why it took more time. Here is the overlay to enable rpmsg on the verdin iMX8M Mini:

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
 * Copyright 2022 Toradex
 */

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,verdin-imx8mm";
};

&{/} {

    reserved-memory {

		#address-cells = <2>;
		#size-cells = <2>;
		ranges;
        
        vdev0vring0: vdev0vring0@B8000000 {
			compatible = "shared-dma-pool";
			reg = <0 0xB8000000 0 0x8000>;
			no-map;
		};

		vdev0vring1: vdev0vring1@B8008000 {
			compatible = "shared-dma-pool";
			reg = <0 0xB8008000 0 0x8000>;
			no-map;
		};

		vdevbuffer: vdevbuffer@b8400000 {
			compatible = "shared-dma-pool";
			reg = <0 0xb8400000 0 0x100000>;
			no-map;
		};
        
        rsc_table: rsc_table@B80FF000 {
			reg = <0 0xb80ff000 0 0x1000>;
			no-map;
		};
    };
};

&rpmsg {
	/*
	 * 64K for one rpmsg instance:
	 * --0xb8000000~0xb800ffff: pingpong
	 */
	vdev-nums = <1>;
	reg = <0x0 0xb8000000 0x0 0x10000>;
	memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
    status = "okay";
};

Here is the compiled binary for you: Download - Toradex File Sharing Platform

Here I applied this overlay:

# cat /boot/ostree/torizon-197df9985ed050833c45da3c9f71a61d0ff961f710a005c4fbb8bb090a5b2ca4/dtb/overlays.txt
fdt_overlays=verdin-imx8mm_rpmsg.dtbo

And loaded the rpmsg_lite_str_echo_rtos.bin demo from NXP SDK. Then, after the module has been rebooted, run the command below:

#  sudo modprobe imx_rpmsg_tty

You should see the hello world on the m4 side. Now, to send messages, you can run:

# echo hello > /dev/ttyRPMSG30

And you should see the message in the m4 core.

This overlay will work but you will probably see a warning like this one in the dmesg:

[    0.000000] OF: reserved mem: OVERLAP DETECTED!
[    0.000000] vdev0vring0@B8000000 (0x00000000b8000000--0x00000000b8008000) overlaps with rpmsg@b8000000 (0x00000000b8000000--0x00000000b8400000)
[    0.000000] OF: reserved mem: OVERLAP DETECTED!

It should be a problem for you, however, if you want to get rid of this warning, you will need to patch the verdin device tree and compile it again. Here is the patch:

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
index eb9cf2576bf7..b1c7923deb9c 100755
--- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
@@ -126,20 +126,6 @@
 		startup-delay-us = <2000>;
 		off-on-delay = <100000>;
 	};
-
-	reserved-memory {
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
-
-		/* use the kernel configuration settings instead */
-		/delete-node/ linux,cma;
-
-		rpmsg_reserved: rpmsg@b8000000 {
-			no-map;
-			reg = <0 0xb8000000 0 0x400000>;
-		};
-	};
 };
 
 &A53_0 {
@@ -664,7 +650,6 @@
 	l1ss-disabled;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_pcie0>;
-	reserved-region = <&rpmsg_reserved>;
 	/* PCIE_1_RESET# (SODIMM 244) */
 	reset-gpio = <&gpio3 19 GPIO_ACTIVE_LOW>;
 };

From what I tested here, there is no need for this patch now, you should be fine with the overlay.

Let me know if you have any questions about that. I’ll also mark this answer as a solution so others can benefit from it, but you can ask any questions here.

Hope this helps!

Best Regards,
Hiago.