Verdin iMX8MP – System Freeze When Starting M7 via remoteproc

Technical Support
, ,
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Looking at your setup, there are several key configuration issues that could cause the system freeze when starting remoteproc on the Verdin iMX8M Plus. Let me help you troubleshoot this systematically.

Critical Configuration Issue

First, there’s an error in your U-Boot environment variable. The correct command should be(1):

fw_setenv tdxargs "clk-imx8mp.mcore_booted=1"

Notice the dot (.) instead of a dash (-) in clk-imx8mp.mcore_booted=1. This is a critical parameter that prevents Linux from interfering with the M-core during boot(1).

Device Tree Overlay Verification

Ensure you have the correct device tree overlay enabled. For Verdin iMX8M Plus, you need the verdin-imx8mp_hmp_overlay.dtbo(1). You can verify this is active by checking:

cat /proc/device-tree/chosen/overlays/name

Remoteproc Status Verification

Before loading firmware, verify remoteproc is properly initialized(1):

# Check if remoteproc driver is available
dmesg | grep -E "remote|rproc"

You should see output similar to:

[    1.629455] remoteproc remoteproc0: imx-rproc is available

Firmware Loading Process

Follow this exact sequence for loading firmware(1):

# Ensure the remote processor is stopped
echo stop > /sys/class/remoteproc/remoteproc0/state

# Verify it's offline
cat /sys/class/remoteproc/remoteproc0/state

# Set the firmware name (must be .elf format)
echo hello_world_cm7.elf > /sys/class/remoteproc/remoteproc0/firmware

# Start the remote processor
echo start > /sys/class/remoteproc/remoteproc0/state

Known Issues and Workarounds

Based on community reports, there are known issues with remoteproc on certain Torizon OS versions(2). If you continue experiencing system freezes, consider these alternatives:

  1. Use U-Boot Loading: Load the firmware via U-Boot instead of remoteproc, as this method is more reliable for some firmware configurations(2).

  2. Firmware Size Considerations: Large firmware images can cause remoteproc loading failures. If your firmware is particularly large, try building a minimal version to test if size is the issue(3).

Additional Debugging Steps

  1. Check Memory Regions: Ensure your firmware’s memory layout doesn’t conflict with Linux memory regions(4).

  2. Verify ELF Format: RemoteProc requires .elf format files, not .bin files(1).

  3. Monitor System Logs: Use dmesg -w in another terminal while starting remoteproc to capture any error messages before the freeze occurs.

If the issue persists after correcting the kernel command line argument, the problem might be related to firmware memory layout or specific hardware interactions that require further investigation.

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.