IMX8MP Remote proc fails to load M7

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 your detailed description and the provided information.

Your observation is aligned with known behavior on the Verdin iMX8M Plus with Torizon OS 7.1.0: the Linux remoteproc framework enforces memory and segment integrity checks when loading M7 firmware, and has stricter limitations compared to U-Boot, especially regarding ELF program headers and memory regions.

Key Points from Your Scenario:

  • Loading via remoteproc fails when the binary exceeds a certain size, but succeeds with U-Boot.
  • The load error:
    [    7.253579] remoteproc remoteproc0: bad phdr da 0x1de78 mem 0xd5a0
[    7.259905] remoteproc remoteproc0: Failed to load program segments: -22
  • Your code and data are entirely mapped to TCM, using .elf files.

Why This Happens:

  • The Linux remoteproc loader expects program segments in the ELF file to be contiguous and fit within predefined memory regions (TCM in this case).
  • If a segment tries to load some part outside the available memory area or overlaps/extends it incorrectly according to remoteproc’s checks, the loader will return -EINVAL (-22) as you see.
  • U-Boot’s loader is less strict, so it may successfully load images that the Linux remoteproc will reject.

Some Recommendations:

  1. Check your linker script boundaries:

    • Ensure your code and data do not overflow configured TCM sizes (128KB ITCM, 128KB DTCM for M7).
    • Even if the sections appear within bounds, ensure the total of all used memory does not cross architectural or SoC-specific boundaries that remoteproc checks for.

  2. ELF File Segmentation:

    • The remoteproc loader parses program headers (phdrs). Large .elf files with many or non-aligned segments sometimes cause the loader to “see” a physical address for a segment that is out-of-range or disallowed.
    • Try limiting the number of program headers (combine sections if possible), or generate a “flat binary” (.bin) with only the code and data destined for TCM.

  3. Use stripped and size-limited debug builds:

    • If possible, strip unnecessary debug symbols or use -g1.
    • Sometimes changing debug build flags reduces .elf size and complexity.

  4. Workaround with U-Boot:
    Since U-Boot does not have the same segment restrictions, it remains an option for debug builds.

    • For TorizonOS and TorizonCore Builder, you typically cannot easily adjust U-Boot environment via TCB input parameters. The common workaround is to manually edit and inject the needed U-Boot variables in your provisioning pipeline.
    • This is not as streamlined, but ensures debug firmware can be loaded until the remoteproc issue is resolved in a future OS/kernel update.

  5. Test Across Versions:

    • Some users report better results (or at least different remoteproc behavior) on Torizon OS 6.x releases or with minimal kernel updates. Testing with an older OS or kernel, if practical, may help you determine if something has changed in the newer remoteproc driver.

Links for Reference:

Summary

  • This is a known constraint with the current kernel’s remoteproc loader.
  • Review TCM usage and program header segmentation.
  • Consider using stripped debug builds or fallback to U-Boot boot for larger/development firmware.
  • Watch for updates in future TorizonOS/Kernels for improved remoteproc handling.

Let me know if you need detailed guidance on linker script adjustments or remoteproc configuration!

Best regards,
Toradex AI Assistant.