Imx8m mini A53-M4 Core

I understand your issue - you’re experiencing a problem where the M4 core starts via U-Boot but RemoteProc doesn’t recognize it’s running. This is a common issue with the Verdin iMX8M Mini when using RemoteProc.

The Root Cause

The issue occurs because when you boot the M4 firmware directly from U-Boot, the Linux kernel doesn’t know that the M4 core is already running (1). For RemoteProc to work properly, you need to inform the kernel that the M4 core has been booted.

Solution: Kernel Command Line Parameter

You need to add a kernel command line argument for RemoteProc to be functional (1). For your Verdin iMX8M Mini, you need to add clk-imx8mm.mcore_booted=1 to the kernel command line (1).

Method 1: Using fw_setenv (Recommended)

From your Linux user space, run:

fw_setenv tdxargs "clk-imx8mm.mcore_booted=1"

(1)

Then reboot your device.

Method 2: U-Boot Environment Modification

If the fw_setenv method doesn’t work, you can modify the U-Boot environment directly:

  1. Access the U-Boot console during boot
  2. Run the following commands:
setenv bootargs "${bootargs} clk-imx8mm.mcore_booted=1"
saveenv

(1)

Device Tree Overlay Requirement

Make sure you have applied the related device tree overlay: verdin-imx8mm_hmp_overlay.dtbo (2). This overlay is necessary for proper HMP functionality and RPMsg communication.

Verification Steps

After applying the kernel parameter:

  1. Check if RPMsg driver is loaded:
dmesg | grep -i rpmsg

You should see: [ 0.045742] imx rpmsg driver is registered. (2)

  1. Load the RPMsg kernel module:
sudo modprobe imx_rpmsg_tty

(2)

  1. Check for RPMsg devices:
ls /dev/ | grep -i rpmsg

You should see devices like rpmsg_ctrl0 and ttyRPMSG30 (2)

Important Notes

  • This kernel parameter tells the clock framework that the M4 core is already booted and running (1)
  • Without this parameter, RemoteProc cannot properly manage the M4 core that was started by U-Boot (1)
  • The parameter is essential for proper communication between the A53 and M4 cores (1)

After implementing these changes, your RemoteProc should properly recognize the running M4 firmware and enable communication between the cores.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.