RPMSG does not work on IMX8M-Plus.

Hi @gustavo.tx @alvaro.tx

I just tried your proposed solution (apply caam.patch and set fdt_high).
The system is still crashing during boot (once the overlay is activated). The message is slightly different, however. All tested on a clean tdx-reference-minimal-image.

kernel_panic_rpmsg_caam-patched.log (26.7 KB)

Hi alvaro san.

I tried your proposed solution (apply caam.patch and set fdt_high) too.
But the same problem caused.

apply caam.patch

$ cd ${DRIVERS}/crypto/caam
$ patch -u < caam.patch

set fdt_high (I tried both)

$ setenv fdt_high 0xffffffffffffff 7byte?
$ saveenv
$ boot

$ setenv fdt_high 0xffffffffffffffff 8byte?
$ saveenv
$ boot

Result is … the boot message stopped.

printk: bootconsole [ec_imx6q0] disabled
boot.log (6.8 KB)

Best regards, Takeo.

Greetings @deepimpact @dpenning!

I could not reproduce the issue, but I’m using a Dahlia carrier board with a Verdin iMX8MP Q 2GB.

Can you please try the overlay attached? This works for me on BSP 5.3.0+build.10 with the CAAM patch applied and fdt_high set to 0xffffffffffffff.

verdin-imx8mp_rpmsg_overlay.dtbo (2.9 KB)

Hi, @gustavo.tx san, @alvaro.tx san.

Thank you for reply. I tried again by using your dtbo file, but it was the same result.
(I’m using a Verdin Development Board + Verdin iMX8MP Q 4GB)

I could not reproduce the issue, but I’m using a Dahlia carrier board with a Verdin iMX8MP Q 2GB

Can you please try using a Verdin Development Board with iMX8MP Q 4GB ?

And one more thing,
The fdt_high variable originally did not exist in U-boot variables. You, too ?

$ pri fdt_high
Error fdt_high not defined.

Best regards, Takeo.

Hi @gustavo.tx @alvaro.tx

Thanks for your investigation. Unfortunately, I can confirm the findings of @deepimpact.
With your compiled overlay file, I am running in the same kernel panic posted above.
I am using the Verdin Development Board. The Device Tree in use is “imx8mp-verdin-nonwifi-dev.dts”
Maybe you could go from there and compare against the dahlia DT? (Dahlia is also included in Verdin Development Board).

The fdt_high variable is not defined.

Verdin iMX8MP # env print
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_targets=mmc1 mmc2 usb0 dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=setenv devtype dhcp; run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mfg=fastboot 0
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_mmc2=devnum=2; run mmc_boot
bootcmd_usb0=devnum=0; run usb_boot
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
preboot=setenv fdtfile imx8mp-verdin-${variant}-${fdt_board}.dtb
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
setup=setenv setupargs console=${console},${baudrate} console=tty1 consoleblank=0 earlycon
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

@gustavo.tx @alvaro.tx
To be clear, I created the minimal image using the instructions provided in OpenEmbedded (core) - Toradex System/Computer on Modules

commit 35cb96f1e8834a1a4dea2a3ee24b2bc0595438ba (HEAD → default, origin/dunfell-5.x.y,

1 Like

Hi @gustavo.tx ,

I think we are missing something. I tried with the Dahlia DTB but still got the CAAM error. Please check if you can boot with the Dev Board DTB even in the Dahlia CB.

setenv fdt_file imx8mp-verdin-wifi-dev.dtb

Can you double-check on the git info to check that we are definitely using the same kernel? Also, please check that you are not applying the changes from the original complete device tree that included the RPMsg changes :wink:

git log
commit 09dedcf8e8301c81290944fec7f46498a6057fb6 (HEAD -> toradex_5.4-2.3.x-imx, origin/toradex_5.4-2.3.x-imx)

Log with non-wifi-dahlia: non-wifi-dahlia_log.txt (23.6 KB)

Git diff:

alvaro@DESKTOP-5BD949L:~/Toradex/iMX8MPlus_RPMSG/linux-toradex$ git diff
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index b19f22aab64a..748c02459206 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -67,6 +67,14 @@ static void build_instantiation_desc(u32 *desc, int handle, int do_sk)
        append_jump(desc, JUMP_CLASS_CLASS1 | JUMP_TYPE_HALT);

+static const struct of_device_id imx8m_machine_match[] = {
+ { .compatible = "fsl,imx8mm", },
+ { .compatible = "fsl,imx8mn", },
+ { .compatible = "fsl,imx8mp", },
+ { .compatible = "fsl,imx8mq", },
+ { }
 /* Descriptor for deinstantiation of State Handle 0 of the RNG block. */
 static void build_deinstantiation_desc(u32 *desc, int handle)
@@ -79,6 +87,7 @@ static void build_deinstantiation_desc(u32 *desc, int handle)
        append_jump(desc, JUMP_CLASS_CLASS1 | JUMP_TYPE_HALT);

  * run_descriptor_deco0 - runs a descriptor on DECO0, under direct control of
  *                       the software (no JR/QI used).

I tried your DTBO and got the exact same error.


@dpenning @deepimpact

By default, fdt_high is not set in our BSP. That is correct. I think @gustavo.tx used this to avoid relocation, but I don’t think it is the issue here.

fdt_high - if set this restricts the maximum address that the flattened device tree will be copied into upon boot. If this is set to the special value 0xFFFFFFFF then the fdt will not be copied at all on boot. For this to work it must reside in writable memory, have sufficient padding on the end of it for u-boot to add the information it needs into it, and the memory must be accessible by the kernel.


Yes, the variable is not defined by default. I’ll try to reproduce your setup.

Hi guys!

Tried with the same module on a Verdin Dev Board and it works:

First you have to run the RPMsg application on the M7 core. The M7 UART output should look just like:
RPMSG String Echo FreeRTOS RTOS API Demo...

Once you boot Linux and modprobe imx_rpmsg_tty, the Linux debug UART shows:

root@verdin-imx8mp:~# modprobe imx_rpmsg_tty
[   55.331587] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: new channel: 0x400 -> 0x1e!
[   55.340559] Install rpmsg tty driver!

Immediately, on the M7 UART, you should see:

Nameservice sent, ready for incoming messages...
Get Message From Master Side : "hello world!" [len : 12]

You can see that /dev/ttyRPMSG30 now exists:

root@verdin-imx8mp:~# ls -la /dev/ttyRPMSG*
crw-rw----    1 root     dialout   511,   0 Sep 14 19:51 /dev/ttyRPMSG30

You can then write and read to/from this tty.

My fdtfile:

root@verdin-imx8mp:~# fw_printenv fdtfile

My overlays.txt:

root@verdin-imx8mp:~# cat /boot/overlays.txt

Hi, @gustavo.tx san, @alvaro.tx san.

Thank you for answering my question.
And trying to use a Verdin development board with iMX8M Plus.
But It seems that there are still differences in the environment.

The fdt file that I’m using is “imx8mp-verdin-wifi-dev.dtb”. Because I’m using a iMX8M Plus Quad 4GB with WIFI/BT. But having said that, I tried to change to the “imx8mp-verdin-nonwifi-dev.dtb”.

step1. Verdin iMX8MP# setenv fdtfile “imx8mp-verdin-nonwifi-dev.dtb”
step2. Verdin iMX8MP# saveenv
step3. Verdin iMX8MP# boot

Booting message is here. The same error still caused.

[ 0.013393] 000: printk: console [tty1] enabled
[ 0.017940] 000: printk: bootconsole [ec_imx6q0] disabled

The “fw_printenv” command does not exist in U-boot. But the “pri” command exist.

Verdin iMX8MP# fw_printenv
Unknown command ‘fw_printenv’ -try ‘help’

“pri” command result is here. Is there anything strange?
uboot-pri-env.txt (7.3 KB)
fw_env.config (1.3 KB)

Best regards, Takeo.

Hi @gustavo.tx (cc @deepimpact @dpenning)

I’ve just found the original commit and that my patch was incomplete, sorry for that. This is the complete patch:

However, after applying this new patch I still cannot make it run :sob:

Gustavo, can you send a patch with the changes from commit 09dedcf8e8301c81290944fec7f46498a6057fb6, please? (toradex_5.4-2.3.x-imx)


alvaro@DESKTOP-5BD949L:~/Toradex/iMX8MPlus_RPMSG/linux-toradex$ git diff 09dedcf8e8301c81290944fec7f46498a6057fb6
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index b19f22aab64a..a12e987ced62 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -79,6 +79,14 @@ static void build_deinstantiation_desc(u32 *desc, int handle)
        append_jump(desc, JUMP_CLASS_CLASS1 | JUMP_TYPE_HALT);

+static const struct of_device_id imx8m_machine_match[] = {
+       { .compatible = "fsl,imx8mm", },
+       { .compatible = "fsl,imx8mn", },
+       { .compatible = "fsl,imx8mp", },
+       { .compatible = "fsl,imx8mq", },
+       { }
  * run_descriptor_deco0 - runs a descriptor on DECO0, under direct control of
  *                       the software (no JR/QI used).
@@ -850,6 +858,9 @@ static int caam_probe(struct platform_device *pdev)
        nprop = pdev->dev.of_node;

        imx_soc_match = soc_device_match(caam_imx_soc_table);
+       if (!imx_soc_match && of_match_node(imx8m_machine_match, of_root))
+               return -EPROBE_DEFER;
        caam_imx = (bool)imx_soc_match;


I get the M7 core to output the message you mentioned but I still get the kernel panic. This is how I run it:

setenv m4addr 0x7e0000
setenv fdt_high 0xffffffffffffff
fatload mmc 2 0x48000000 rpmsg_demo.bin && cp.b 0x48000000 ${m4addr} 20000 && bootaux ${m4addr}

Hi @deepimpact @dpenning I just talked with Gustavo. He has been trying in the non-WiFi and Dahlia while I was testing with the WiFi+Dev Board. He will try the faulty combination hopefully before the end of the week.

Sorry to keep you waiting. He will let us know with anything.

Kind regards,

Hi @deepimpact, @dpenning and @alvaro.tx!

Indeed the issue seems to manifest itself only on the WiFi variant of the module.
When using the non-WiFi version, either with the Dahlia or the Verdin Dev Board, everything works just fine. One can even set the device tree to the Wi-Fi one (e.g. verdin-imx8mp-wifi-dev) on the non-WiFi and it doesn’t crash.
This leads me to think that it’s a pin assignment or hardware issue.
I’m investigating this more thoroughly and I’ll keep you informed.

Hi @gustavo.tx @alvaro.tx
Thanks for keeping us in the loop!
I am using the Verdin iMX8M Plus Quad 2GB. PN:00611001. This module does not have Wi-Fi and I am still experiencing the issue.

Oh, then that is something else. Let’s hope Gustavo can find the key issue then.