Dear Toradex Community,
I am building an application with a Apalis iMX8 on which both the M4Fs communicate with a separate CAN Bus to our product. On those I use FreeRTOS and they communicate with each other using the Message Unit.
Now I would like to also broadcast the received CAN Data from both of the M4Fs to the Linux-System. For this purpose I try to use RPMSG.
I tried to follow the readme.txt in the rpmsg_lite_str_echo_rtos example in the multicore folder of the SDK from NXP and your page Communicating between cores with RPMsg .
My problem now is that the RPMSG never appears as a TTY.
Until now I did the following steps:
- In the device Tree File imx8qm.dsti i changed the status of both rpmsg0 and rpmsg1 to "okay", then i compiled and uploaded the device tree using TCBuilder
- Then: modprobe imx_rpmsg_tty
- finally: echo imx_rpmsg_tty > /etc/modules-load.d/rpmsg_tty.conf
The problem now is i never see a TTY in /dev and when inspecting
dmesg i get several errors like this:
virtio_rpmsg_bus: probe of virtio0 failed with error -12
Do you have any suggestions on how to deal with RPMSG using Torizon?
Thank you in advance!
Hi @Juli7478,
I made this overlay works on BSP 6.3. Could you please check if it looks like yours or test it on TorizonCore 6 as well? It should work. This will enable the RPMsg channels and then, after the modprobe, you should see the tty devices appears in your module.
/dts-v1/;
/plugin/;
/ {
compatible = "toradex,apalis-imx8-v1.1",
"toradex,apalis-imx8",
"fsl,imx8qm";
};
&{/} {
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
vdev0vring0: vdev0vring0@90000000 {
compatible = "shared-dma-pool";
reg = <0 0x90000000 0 0x8000>;
no-map;
};
vdev0vring1: vdev0vring1@90008000 {
compatible = "shared-dma-pool";
reg = <0 0x90008000 0 0x8000>;
no-map;
};
vdev1vring0: vdev1vring0@90010000 {
compatible = "shared-dma-pool";
reg = <0 0x90010000 0 0x8000>;
no-map;
};
vdev1vring1: vdev1vring1@90018000 {
compatible = "shared-dma-pool";
reg = <0 0x90018000 0 0x8000>;
no-map;
};
vdev2vring0: vdev0vring0@90100000 {
compatible = "shared-dma-pool";
reg = <0 0x90100000 0 0x8000>;
no-map;
};
vdev2vring1: vdev0vring1@90108000 {
compatible = "shared-dma-pool";
reg = <0 0x90108000 0 0x8000>;
no-map;
};
vdev3vring0: vdev1vring0@90110000 {
compatible = "shared-dma-pool";
reg = <0 0x90110000 0 0x8000>;
no-map;
};
vdev3vring1: vdev1vring1@90118000 {
compatible = "shared-dma-pool";
reg = <0 0x90118000 0 0x8000>;
no-map;
};
vdevbuffer: vdevbuffer {
compatible = "shared-dma-pool";
reg = <0 0x90400000 0 0x100000>;
no-map;
};
};
rpmsg0: rpmsg@0 {
compatible = "fsl,imx8qm-rpmsg";
mbox-names = "tx", "rx", "rxdb";
mboxes = <&lsio_mu5 0 1
&lsio_mu5 1 1
&lsio_mu5 3 1>;
mub-partition = <3>;
vdev-nums = <2>;
reg = <0 0x90000000 0 0x20000>;
memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
<&vdev1vring0>, <&vdev1vring1>;
status = "okay";
};
rpmsg1: rpmsg1 {
compatible = "fsl,imx8qm-rpmsg";
mbox-names = "tx", "rx", "rxdb";
mboxes = <&lsio_mu6 0 1
&lsio_mu6 1 1
&lsio_mu6 3 1>;
mub-partition = <4>;
vdev-nums = <2>;
reg = <0 0x90100000 0 0x20000>;
memory-region = <&vdevbuffer>, <&vdev2vring0>, <&vdev2vring1>,
<&vdev3vring0>, <&vdev3vring1>;
status = "okay";
};
};
&iomuxc {
pinctrl-0 = <&pinctrl_cam1_gpios>, <&pinctrl_dap1_gpios>,
<&pinctrl_esai0_gpios>, <&pinctrl_fec2_gpios>,
<&pinctrl_gpio3>, <&pinctrl_gpio4>, <&pinctrl_gpio_keys>,
<&pinctrl_gpio_usbh_oc_n>,
<&pinctrl_lvds0_i2c0_gpio>, <&pinctrl_lvds1_i2c0_gpios>,
<&pinctrl_mipi_dsi_0_1_en>, <&pinctrl_mipi_dsi1_gpios>,
<&pinctrl_mlb_gpios>, <&pinctrl_qspi1a_gpios>,
<&pinctrl_sata1_act>, <&pinctrl_sim0_gpios>,
<&pinctrl_usdhc1_gpios>;
};
&lpuart2 {
status = "disabled";
};
&lsio_pwm0 {
status = "disabled";
};
&lsio_pwm1 {
status = "disabled";
};
Best Regards,
Hiago.
Dear @hfranco.tx ,
Thanks for your answer.
Specifically I am using TorizonCore 5.7.0 build 17. and not TC6
I tried to apply your Overlay as is, but the disabling of &lsio_pwm0 and &lsio_pwm1 result in the error Failed to apply '/tmp/tmptfa45zdx': FDT_ERR_NOTFOUND .
Thus, I replaced the groupnames with &pwm0 and &pwm1. Like this I can build the devicetree. However, I don’t know if this has any imapct on RPMSG.
Now I applied the adapted Overlay and the virtio error does not appear anymore. In dmesg i get these lines, which looks promising:
[ 2.359908] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 2.389929] virtio_rpmsg_bus virtio1: rpmsg host is online
[ 2.390339] imx-rpmsg 90100000.rpmsg1: assigned reserved memory node vdevbuffer
[ 2.419917] virtio_rpmsg_bus virtio2: rpmsg host is online
[ 2.449923] virtio_rpmsg_bus virtio3: rpmsg host is online
Nevertheless, the RPMSG TTY still does not appear in /dev. After the modprobe, I checked using lsmod and i get this line, which indicate that it is not used by anything:
imx_rpmsg_tty 20480 0
Do you have any further suggestions?
Sincerely
Hi @Juli7478,
I’m sorry for the delay.
For TorizonCore 5 or BSP 5, can you please try the following code?
/dts-v1/;
/plugin/;
#include <dt-bindings/firmware/imx/rsrc.h>
/* Enable RPMSG for Apalis iMX8 */
/ {
compatible = "toradex,apalis-imx8-v1.1",
"toradex,apalis-imx8",
"fsl,imx8qm";
};
&{/} {
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
/* Allocate TX and RX buffers for communication between m4 cores
with Linux and m4 core0 with m4 core1. Allocate the necessary resource
tables as well. */
vdev0vring0: vdev0vring0@90000000 {
compatible = "shared-dma-pool";
reg = <0 0x90000000 0 0x8000>;
no-map;
};
vdev0vring1: vdev0vring1@90008000 {
compatible = "shared-dma-pool";
reg = <0 0x90008000 0 0x8000>;
no-map;
};
vdev1vring0: vdev1vring0@90010000 {
compatible = "shared-dma-pool";
reg = <0 0x90010000 0 0x8000>;
no-map;
};
vdev1vring1: vdev1vring1@90018000 {
compatible = "shared-dma-pool";
reg = <0 0x90018000 0 0x8000>;
no-map;
};
rsc_table0: rsc_table0@0x900ff000 {
reg = <0 0x900ff000 0 0x1000>;
no-map;
};
rsc_table1: rsc_table1@0x901ff000 {
reg = <0 0x901ff000 0 0x1000>;
no-map;
};
vdev2vring0: vdev0vring0@90100000 {
compatible = "shared-dma-pool";
reg = <0 0x90100000 0 0x8000>;
no-map;
};
vdev2vring1: vdev0vring1@90108000 {
compatible = "shared-dma-pool";
reg = <0 0x90108000 0 0x8000>;
no-map;
};
vdev3vring0: vdev1vring0@90110000 {
compatible = "shared-dma-pool";
reg = <0 0x90110000 0 0x8000>;
no-map;
};
vdev3vring1: vdev1vring1@90118000 {
compatible = "shared-dma-pool";
reg = <0 0x90118000 0 0x8000>;
no-map;
};
};
};
&rpmsg0 {
status = "okay";
};
&rpmsg1 {
status = "okay";
};
It should be possible to compile and use it with TorizonCore 5 and the rpmsg will be enabled. Can you please check on your side and see if it works?
Best Regards,
Hiago.
Hi @hfranco.tx ,
Thanks for the suggestion. I tried your overlay, but the TTY still does not seem to appear. In dmesg I get exactly the same lines as previously.
Maybe I am overseeing it in /dev, as I am not sure whats the actual name of it. How exactly should it appear?
I am also not sure if this is related, and if it is even new, but i get the following Error while booting:
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Loading Ramdisk to fcd8c000, end fd64d32f ... OK
ERROR: reserving fdt memory region failed (addr=95000000 size=400000)
Loading Device Tree to 00000000fcd3f000, end 00000000fcd8bfff ... OK
Another question: Does the RPMSG on the M4 side has to be active for it to appear in /dev? And am I right, that the RPMSGLite Library on the M4 side is compatible with the normal RPMSG Protocol on the Linux side, as long as the memory area is correctly specified?
Many Thanks!!
Hi @Juli7478,
I tested the overlay on my side with TorizonCore 5 and it worked for me. Could you please double-check how you’re loading it?
If you want to try mine, here is the DTBO file (it’s going to be available for 3 months): Download - Toradex File Sharing Platform
Here I copied this file to /boot/ostree/<hash>/dtb/overlays and then edited the /boot/ostree/<hash>/dtb/overlays.txt file to include the name of this overlay, apalis-imx8_hmp_overlay.dtbo.
Next, I’ve compiled and loaded the M4 binary called rpmsg_lite_str_echo_rtos_m40.bin inside the multicore example folder.
For more information on how to load your binary, please check these guides:
After rebooting and M4 successfully running, I can see these messages on dmesg:
torizon@apalis-imx8-07204567:~$ dmesg | grep rpmsg
[ 0.082549] imx rpmsg driver is registered.
[ 2.392342] imx-rpmsg 90000000.rpmsg0: assigned reserved memory node vdevbuffer
[ 2.392820] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 2.393239] virtio_rpmsg_bus virtio1: rpmsg host is online
[ 2.393429] virtio_rpmsg_bus virtio1: creating channel rpmsg-virtual-tty-channel addr 0x1e
[ 2.393565] imx-rpmsg 90100000.rpmsg1: assigned reserved memory node vdevbuffer
[ 2.422026] virtio_rpmsg_bus virtio2: rpmsg host is online
[ 2.452446] virtio_rpmsg_bus virtio3: rpmsg host is online
After loading the driver, I can see the channel has been created and I can send messages and check the echo back:
torizon@apalis-imx8-07204567:~$ sudo modprobe imx_rpmsg_tty
Password:
torizon@apalis-imx8-07204567:~$ dmesg | grep rpmsg
[ 0.082549] imx rpmsg driver is registered.
[ 2.392342] imx-rpmsg 90000000.rpmsg0: assigned reserved memory node vdevbuffer
[ 2.392820] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 2.393239] virtio_rpmsg_bus virtio1: rpmsg host is online
[ 2.393429] virtio_rpmsg_bus virtio1: creating channel rpmsg-virtual-tty-channel addr 0x1e
[ 2.393565] imx-rpmsg 90100000.rpmsg1: assigned reserved memory node vdevbuffer
[ 2.422026] virtio_rpmsg_bus virtio2: rpmsg host is online
[ 2.452446] virtio_rpmsg_bus virtio3: rpmsg host is online
[ 80.633880] imx_rpmsg_tty virtio1.rpmsg-virtual-tty-channel.-1.30: new channel: 0x400 -> 0x1e!
[ 80.634086] Install rpmsg tty driver!
torizon@apalis-imx8-07204567:~$ ls /dev/ | grep -i rpmsg
ttyRPMSG30
torizon@apalis-imx8-07204567:~$ cat /dev/ttyRPMSG30 &
[1] 1500
torizon@apalis-imx8-07204567:~$ echo Toradex > /dev/ttyRPMSG30
torizon@apalis-imx8-07204567:~$ Toradex
Toradex
Let me know if you have any questions or need help.
Best Regards,
Hiago.
Dear @hfranco.tx
Many thanks for the support, I successfully loaded the M4 Image and now get the same behavior as yours. I think the problem was, that the M4 Program was not running previously.
Best regards,
Julian
1 Like