Apalis iMX8QM Rpmsg issue on BSP 5.0

Dear Support Team,

according to below articles, the rpmsg function works well on Apalis iMX8QM v1.0B with Ycoto Linux BSP 3.04, but when we upgrade to latest HW Apalis iMX8QM V1.1B with latest Ycoto Linux BSP Reference-Multimedia-Image-Tezi_5.0.0-build.3 (20201006), it doesn’t work.

https://www.toradex.com/community/questions/51240/rpmsg-demo-issue-on-apalis-imx8qm.html?childToView=51484#answer-51484

Then after some investigation, compared with the “imx8qm-mek.dts” and “imx8qm-mek-rpmsg.dts” files, we dound toradex device tree didn’t enable rpmsg node and virtual channel by default, so we made below device tree modification to make m40 rpmsg work, it do works with m40 str_echo demo.

diff --git a/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
index ffa90243f635..c9a477cdce9d 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi

@@ -426,3 +426,10 @@
 	status = "okay";
 };
 
+&rpmsg0 {
+        status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
index 09e05dbdf6cb..c9772d21999e 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
@@ -215,12 +215,12 @@
 			no-map;
 			reg = <0 0x95000000 0 0x400000>;
 		};
-
+                /*
 		vdevbuffer: vdevbuffer {
 			compatible = "shared-dma-pool";
 			reg = <0 0x90400000 0 0x100000>;
 			no-map;
-		};
+		};*/
 
 		/* global autoconfigured region for contiguous allocations */
 		linux,cma {
@@ -293,6 +293,66 @@
 		status = "disabled";
 	};
 
+	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;
+		};
+
+		vdevbuffer: vdevbuffer {
+                        compatible = "shared-dma-pool";
+			reg = <0 0x90400000 0 0x100000>;
+			no-map;
+		};
+	};
+
 };
 
 &adc0 {

but when we extend this similar configration to m41 like below, after deploying device tree file, the module doesn’t boot with memory allocation error, seems there is some memory conflict, could you help advice on how can we modify to make m41 rpmsg work?

diff --git a/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
    index ffa90243f635..c9a477cdce9d 100644
    --- a/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
    +++ b/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
    
    @@ -426,3 +426,10 @@
     	status = "okay";
     };
     
    +&rpmsg0 {
    +        status = "okay";
    +};
    +&rpmsg1 {
    +        status = "okay";
    +};
    diff --git a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
    index 09e05dbdf6cb..c9772d21999e 100644
    --- a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
    +++ b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
    @@ -215,12 +215,12 @@
     			no-map;
     			reg = <0 0x95000000 0 0x400000>;
     		};
    -
    +                /*
     		vdevbuffer: vdevbuffer {
     			compatible = "shared-dma-pool";
     			reg = <0 0x90400000 0 0x100000>;
     			no-map;
    -		};
    +		};*/
     
     		/* global autoconfigured region for contiguous allocations */
     		linux,cma {
@@ -293,6 +293,66 @@
 		status = "disabled";
 	};
 
+	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;
+		};
+
+		vdevbuffer: vdevbuffer {
+                        compatible = "shared-dma-pool";
+			reg = <0 0x90400000 0 0x100000>;
+			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;
+		};*/
+	};
+
 };
 
 &adc0 {

the boot failure console log is as below:

U-Boot 2020.04-5.0.0+git.f432a8c81b75 (Sep 30 2020 - 13:56:53 +0000)

CPU:   NXP i.MX8QM RevB A53 at 1200 MHz

DRAM:  4 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Apalis iMX8 QuadMax 4GB Wi-Fi / BT IT V1.1B, Serial# 06738378

 BuildInfo: 
  - SCFW 732e719a, SECO-FW 376e3c15, IMX-MKIMAGE 6745ccdc, ATF 
  - U-Boot 2020.04-5.0.0+git.f432a8c81b75 

switch to partitions #0, OK
mmc0(part 0) is current device
flash target is MMC:0
Net:   eth0: ethernet@5b040000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot:  0 
MMC: no card present
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
3655 bytes read in 16 ms (222.7 KiB/s)
## Executing script at 83100000
102464 bytes read in 22 ms (4.4 MiB/s)
Loading hdp firmware from 0x000000009c000000 offset 0x0000000000002000
Loading hdp firmware Complete
164451 bytes read in 36 ms (4.4 MiB/s)
14 bytes read in 19 ms (0 Bytes/s)
9805711 bytes read in 321 ms (29.1 MiB/s)
Uncompressed size: 23144960 = 0x1612A00
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
ERROR: Failed to allocate 0x4c000 bytes below 0xffe00000.
device tree - allocation error
FDT creation failed! hanging...### ERROR ### Please RESET the board ###

Thanks and Best Regards

Simon

Updated that finally has solved this issue with below modisfication:

./ For BSP 5.0 Uboot, add below env:

# setenv fdt_high '0xffffffffffffffff'

./ For device tree, modified as below patch:

diff --git a/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
index 1f0de824031c..91752f45b66e 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-apalis-eval.dtsi
@@ -313,7 +313,7 @@
 
 /* Apalis UART4 */
 &lpuart2 {
-	status = "okay";
+	status = "disabled";
 };
 
 /* Apalis UART2 */
@@ -328,12 +328,12 @@
 
 /* Apalis PWM3, MXM3 pin 6 */
 &pwm0 {
-	status = "okay";
+	status = "disabled";
 };
 
 /* Apalis PWM4, MXM3 pin 8 */
 &pwm1 {
-	status = "okay";
+	status = "disabled";
 };
 
 /* Apalis PWM1, MXM3 pin 2 */
@@ -422,3 +422,10 @@
 	status = "okay";
 };
 
+&rpmsg0{
+	status = "okay";
+};
+
+&rpmsg1{
+        status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
index 08bd086463db..fb32e5e989fc 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1.dtsi
@@ -293,6 +293,60 @@
 		status = "disabled";
 	};
 
+	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;
+		};
+	};
+
 };
 
 &adc0 {
@@ -438,7 +492,7 @@
 	pinctrl-0 = <&pinctrl_cam1_gpios>, <&pinctrl_dap1_gpios>,
 		    <&pinctrl_esai0_gpios>, <&pinctrl_fec2_gpios>,
 		    <&pinctrl_gpio3>, <&pinctrl_gpio4>,
-		    <&pinctrl_gpio_usbh_oc_n>, <&pinctrl_lpuart1ctrl>,
+		    <&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>,

Hello @hai.tx
I followed your instructions to modify the Device Tree and set the env variable like you said and it worked but with some errors and the in ping_pong example I only saw the output on the M4 console and not on the Cortex-A one. The “rpmsg_lite_str_echo_rtos_m40” worked well.

The error appeared on the U-Boot console as shown in this image:



I used Torizon Core Builder to unpack/apply/deploy the changes, and the files I modify are the following:
imx8-apalis-eval.dtsi and imx8-apalis-v1.1.dtsi


I checked the env var and it was correctly set so I suspect it might have something to do with the DT. Could you check the files out to see if I did something wrong? In case you need any more info, let me know.

I’m using the NXP SDK version 2.9 and my setup is:

Apalis iMX8QM V1.0B

Apalis Eva Board V1.1A

TorizonCore 5.3.0+build.7

Cheers,

Juan

Hello again @hai.tx,
I commented out theese lines on the “imx8-apalis-v1.1.dtsi” file and I no longer have the reserving memory error shown in U-Boot:

/*
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;
 };
 */

However, the problem with the ping pong example still persist. What could be happenning?

I’m attaching the console images for your reference:

Ping pong example images

Thanks,

Juan

Hi Juan,

please note that all the above test is based on Apalis iMX8QM HW version V1.1B for BSP 5.x, old version v1.0B HW only has BSP 3.x support.

Hi @hai.tx ,
So basically what you’re telling me is that we should downgrade to BSP 3.x in order for it to work properly?

As I mentioned on another comment, commenting out vdev2 and vdev3 lines fixed the error on U-Boot, but the pingpong example didn’t show me anything on the Linux side.

We’re planning to use FlexCAN on the M4 side and communicate to Cortex-A through RPMSG, would there be any problem if we use BSP 5.x instead of 3.x with our hardware?

Thanks,

Juan

I am using the same module. V1.1B can this be done via overlays? or best to fully recompile device tree??

sure, both way is okay for the related device tree modification.