Correct way to adapt NXP SDK linker script & startup for remoteproc on i.MX8MP?

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.

Hi Chris,

Your analysis and approach for adapting the NXP MCUXpresso SDK linker script for RemoteProc is technically sound and aligns with the known constraints of the Linux remoteproc framework on Toradex modules.

Your Solution is Correct

Your modifications address a fundamental issue with how the Linux remoteproc loader validates ELF segments against Address Translation Table (ATT) entries(1). The remoteproc framework requires that each ELF PT_LOAD segment fits entirely within a single memory region (ITCM = 128KB, DTCM = 128KB, DDR = 2GB)(1).

The stock NXP SDK approach of packing .data initializers after .text in ITCM works fine for smaller applications but fails for larger firmware when the combined size exceeds the 128KB ITCM limit(1). Your error message confirms this:

Translation failed: da = 0x1a1d0 len = 0x16b90

Why RemoteProc is Different from U-Boot

The key difference is that U-Boot’s bootaux command is more permissive with ELF loading, while the Linux remoteproc framework enforces strict memory region validation(1)(2). RemoteProc loads each segment to its Load Memory Address (LMA) and validates that each segment fits within the corresponding ATT entry(1).

Your Changes Are Appropriate

Removing AT() directives: By setting LMA = VMA, you ensure each section loads directly to its runtime location, avoiding the ITCM overflow issue(1).

Removing data copy loops: Since remoteproc loads segments directly to their final addresses, the traditional startup copy from ITCM to DTCM/DDR becomes unnecessary and would indeed corrupt the correctly-loaded data(1).

Known Issue Context

Your approach aligns with community findings. There’s a documented case where similar ELF segment validation issues occur with larger firmware(3). The remoteproc framework’s stricter validation compared to U-Boot is a known characteristic(3).

Production Considerations

Your changes are architecturally sound for remoteproc usage. The modifications:

  • Respect the ATT memory boundaries
  • Eliminate unnecessary data copying that would corrupt remoteproc-loaded segments
  • Maintain proper .bss zeroing and cache initialization

Since you’re integrating into Yocto and need the firmware as part of the image, remoteproc is the appropriate choice over U-Boot bootaux(1).

Recommendation

Your approach is correct for production use with remoteproc. The lack of documentation for this specific adaptation reflects that most NXP examples target smaller applications that fit within ITCM constraints. Your larger firmware requires the sensible adaptations you’ve implemented.

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.