Blinking led application and kernel panic

Technical Support
, ,
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

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

Hello! Thank you for providing detailed logs and background.

What you are experiencing is a kernel panic occurring very early in the boot process, specifically within the remote processor (rproc) subsystem as it attempts to initialize the Cortex-M4 core on your Verdin iMX8M Mini. This is triggered during application of the verdin-imx8mm_hmp_overlay.dtbo device tree overlay, which enables Heterogeneous Multiprocessing (HMP) and the M4 core.

Key Observations

  • The panic appears in rproc_handle_resources within the imx_rproc_probe function—this means a resource-mapping or memory-setup issue during initialization of the imx_rproc driver for the Cortex-M4 (reference).
  • It only happens after you manually run the GPIO application from U-Boot and then launch the Linux kernel.

Possible Causes

  1. HMP Overlay Side Effect:
    The verdin-imx8mm_hmp_overlay.dtbo overlay enables resources for the M4 core. If the M4 has already been touched, initialized, or memory reserved differently (for instance, by the U-Boot-launched GPIO example), it might cause a conflict or double resource mapping when the kernel’s rproc driver initializes.

  2. Launching Application from U-Boot:
    Running the GPIO application from U-Boot before starting Linux may alter the state of the M4 core or its resources (such as TCM, ROM, etc.), causing memory or peripheral conflicts when Linux tries to reset or claim those resources.

How to Troubleshoot

  1. Try Booting Without Launching the M4 Core/Application

    • Power up the board and boot Linux/Torizon OS without running the GPIO example from U-Boot.
    • Check if the kernel panic still occurs. If the system boots fine, this strongly suggests the U-Boot stage application is causing the conflict.

  2. Remove HMP Overlay

    • Temporarily remove the verdin-imx8mm_hmp_overlay.dtbo overlay from your U-Boot/extlinux configuration.
    • Boot as usual and see if the kernel panic is resolved. If so, the issue is isolated to HMP functionality and how it’s interacting with the pre-started M4/application.

  3. Only Boot M4 Application From Linux

    • The recommended approach for Cortex-M4 development is to let the Linux kernel and imx_rproc driver manage loading, starting, and stopping the M4 core via standard mechanisms (remoteproc, /sys/class/remoteproc, etc.).
    • Do not run or boot applications for the M4 directly from U-Boot if Linux is going to manage it afterwards. This can cause unexpected resource conflicts.

  4. Verify Device Trees

    • Ensure your device trees (and overlays) match your hardware. Check you don’t have conflicting memory mappings or peripheral allocations.

References & More Reading

Summary

  • Do not pre-start the M4/application from U-Boot when using HMP device tree overlay and Linux remoteproc.
  • Let Linux manage the M4 firmware startup exclusively.
  • Remove the HMP overlay temporarily to confirm root cause.

If you share the exact steps you use to start the application from U-Boot, or whether you are loading a firmware for the M4 from U-Boot, I can provide more targeted advice.

Let me know how it goes or if you need step-by-step instructions for any of the above checks!

Best regards,
Toradex AI Assistant.