Hello! I've run into an interesting problem with RPMsg communication between the Cortex-A35 and M4 cores on the IMX8QXP platform, and I could use some insights.
I'm working with Linux 6.6, and here's the situation: When I try to load the demo provided imx8qx_m4_TCM_rpmsg_lite_str_echo_rtos binary from U-boot, the system immediately restarts. Interestingly, the same setup works perfectly fine on Linux 5.15, which suggests something might have changed in the newer kernel version.
Here's my device tree configuration for reference:
/ {
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
gpu_reserved: gpu_reserved@B0000000 {
no-map;
reg = <0 0xB0000000 0 0x08000000>;
};
vdev0vring0: vdev0vring0@90000000 {
reg = <0 0x90000000 0 0x8000>;
no-map;
};
vdev0vring1: vdev0vring1@90008000 {
reg = <0 0x90008000 0 0x8000>;
no-map;
};
vdev1vring0: vdev1vring0@90010000 {
reg = <0 0x90010000 0 0x8000>;
no-map;
};
vdev1vring1: vdev1vring1@90018000 {
reg = <0 0x90018000 0 0x8000>;
no-map;
};
rsc_table: rsc_table@900ff000 {
reg = <0 0x900ff000 0 0x1000>;
no-map;
};
vdevbuffer: vdevbuffer {
compatible = "shared-dma-pool";
reg = <0 0x90400000 0 0x100000>;
no-map;
};
dsp_reserved: dsp@92400000 {
reg = <0 0x92400000 0 0x1000000>;
no-map;
};
dsp_reserved_heap: dsp_reserved_heap {
reg = <0 0x93400000 0 0xef0000>;
no-map;
};
dsp_vdev0vring0: vdev0vring0@942f0000 {
reg = <0 0x942f0000 0 0x8000>;
no-map;
};
dsp_vdev0vring1: vdev0vring1@942f8000 {
reg = <0 0x942f8000 0 0x8000>;
no-map;
};
dsp_vdev0buffer: vdev0buffer@94300000 {
compatible = "shared-dma-pool";
reg = <0 0x94300000 0 0x100000>;
no-map;
};
/* global autoconfigured region for contiguous allocations */
linux,cma {
compatible = "shared-dma-pool";
reusable;
size = <0 0x08000000>;
alloc-ranges = <0 0xa8000000 0 0x08000000>;
linux,cma-default;
};
};
imx8x_cm4: imx8x_cm4@0 {
compatible = "fsl,imx8qxp-cm4";
rsc-da = <0x90000000>;
mbox-names = "tx", "rx", "rxdb";
mboxes = <&lsio_mu5 0 1
&lsio_mu5 1 1
&lsio_mu5 3 1>;
memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
<&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
fsl,resource-id = <IMX_SC_R_M4_0_PID0>;
fsl,entry-address = <0x34fe0000>;
status = "okay";
power-domains = <&pd IMX_SC_R_M4_0_PID0>,
<&pd IMX_SC_R_M4_0_MU_1A>;
};
rpmsg: rpmsg@0 {
compatible = "fsl,imx8qxp-rpmsg";
mbox-names = "tx", "rx", "rxdb";
mboxes = <&lsio_mu5 0 1
&lsio_mu5 1 1
&lsio_mu5 3 1>;
memory-region = <&vdevbuffer>;
mub-partition = <3>;
status = "okay";
};
};
&lsio_mu5 {
status = "okay";
};
My bootloader setup is straightforward:
setenv m4_0_image "imx8qx_m4_TCM_rpmsg_lite_str_echo_rtos.bin"
run m4boot_0
Has anyone encountered similar behaviour or have suggestions on what might be causing this regression in Linux 6.6? I'm particularly interested in:
- Changes in RPMsg handling between 5.15 and 6.6
- Potential memory mapping issues
- MU (Message Unit) configuration differences
Any insights or debugging suggestions would be greatly appreciated!
P.S : I noticed even if I run the sample demo imx8qx_m4_TCM_hello_world.bin, I got the same issue.
I also run into the same issue with Linux 6.6 on iMX8QuadMax. M4 firmware is loaded from U-boot. The M4 runs well if Linux kernel is not started. However, the entire system will reset if Linux kernel starts. The reset cause from U-boot is related to SCFW. But the same implement works on Linux 5.15.
Reset cause: SCFW fault reset
Is it because of the SCFW upgrade?
It is 1.16.0 on my iMX8QM.
After a skim through the sdk user guide, I found that you can't use the bootaux command to run the m4 demos, It's surprising since I made it work in 5.15 fine.
I am trying to build my project, and see if I can run the M4 binary alongside u-boot. It will be run by scfw to my understanding.
I will update you as soon as I get something
can you explain in detail the cause of the problem from your knowledge and investigation so far? is the problem that running M4 Demo on the latest scfw is not the same way as linux 5.15 and below or is it just because the bootaux command can't work in this 6.6 version?
I'm quite interested to solve this problem too.
Hello,
Fatload for M4 code load is usually used for mscale series M4 boot, A core will handle the load of M4 and start it. It is not suggested to be used in i.MX8/8X, because in 8/8X M core is parallel to A core. Fatload boot will break the relationship of A&M(A core and M core will be in one partition), and violate functions like Linux reboot(SCU will close the whole partition so M4 will be closed as well), board low power mode (SCU will handle this low power mode enter), etc…
For i.MX8QXP/QM, SCU_ROM will handle the load of M4 binary code, and we should inform SCU_ROM if we have M4 binary, in imx-mkimage by soc.mak file. SCU will create a seperate resource partition(generally partition 3) and based on that partition, there would be resource isolation(including memory region) between M core and A core.
To flash your own M4 image, please follow SDK doc "Getting Started with MCUXpresso SDK for MEK-MIMX8QXP" - "Run a demo using imx-mkimage".You need to build a flash.bin file with M4 by imx-mkimage, using "make SOC=iMX8QX REV=C0 flash_linux_m4". Then install the imx_rpmsg_tty.ko file by insmod command.
Best regards/Saludos,
Aldo.