Known workflow to load and run Cortex-M7 firmware on Verdin i.MX95 SoM

immypeko · April 15, 2026, 11:27am

I would like to ask, is there any known workflow to load and run the Cortex-M7 firmware binary to Toradex Verdin i.MX95 SoM V1.0A?

I am trying to load and run hello world binary on the Cortex-M7 of Verdin i.MX95 SoM (V1.0A) with Dahlia carrier board, and I am using verdin-imx95.cfg as the configuration of SM firmware, SDK_25_06_00_MIMX9506xxxxN to compile the binary.

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.101-7.4.0-g557af2783d91 #1-Torizon SMP PREEMPT Thu Sep 25 07:49:28 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/7847c3d1a3c999d38bca7b69810b1fb0b12876bf2b7535dc32d3455ee3a07c89/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.4.0-build.28
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx95-12594223
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX95 WB on Verdin Development Board
Toradex version:          0089 V1.0A
Serial number:            12594223
Processor arch:           aarch64
------------------------------------------------------------

When using pre-built Torizon OS image from Download Links | Toradex Developer Center , there’s no /sys/class/remoteproc/remoteproc1 and /sys/firmware/devicetree/base/remoteproc-cm7/.

I tried to use different device tree (e.g., imx95-verdin-nonwifi-dahlia.dts and imx95-verdin-wifi-dev.dts) from linux-toradex.git via torizoncore-builder. After that, /sys/firmware/devicetree/base/remoteproc-cm7/appears, but still missing /sys/class/remoteproc/remoteproc1. At the same time dmesg shows:

[    0.636022] remoteproc remoteproc0: neutron-rproc is available
[   24.808278] platform remoteproc-cm7: deferred probe pending

I also tried to load the binary via U-Boot console. Since Verdin i.MX95 is not yet covered in Toradex Developer Center, I refer to i.MX Linux User’s Guide (UG10163). However, this approach also resulted in errors:

Verdin iMX95 # ext4load mmc 0:1 0x90000000 /ostree/deploy/torizon/var/rootdirs/home/torizon/hello_world.bin
17120 bytes read in 5 ms (3.3 MiB/s)
Verdin iMX95 # cp.b 0x90000000 0x203c0000 ${filesize}
"Error" handler, esr 0xbe000011
elr: 0000000090294fcc lr : 00000000902950c0 (reloc)
elr: 00000000fff8afcc lr : 00000000fff8b0c0
x0 : 00000000203c0000 x1 : 0000000090000000
x2 : 00000000000042e0 x3 : 0000000000000040
x4 : 0000092500000925 x5 : 0000000000000000
x6 : 00000000203c0000 x7 : 0000000000000044
x8 : 0000000000000010 x9 : 0000000000000000
x10: 0000000000000000 x11: 00000000fdf111e0
x12: 0000000000000000 x13: 0000000000000200
x14: 00000000ffffffff x15: 00000000fdee73d8
x16: 00000000fff14a10 x17: 0000000000000000
x18: 00000000fdef5d30 x19: 0000000000000001
x20: 00000000fdf13ee0 x21: 00000000203c0000
x22: 0000000090000000 x23: 0000000000000000
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 00000000fdf204d0 x29: 00000000fdee7240

Code: eb03005f 540001e1 d65f03c0 f8636824 (f8236804) 
Resetting CPU ...

resetting ...

On SM debug monitor side, it shows error:

*** SM Debug Monitor ***

>$ err
SCMI err (chn=5): protocolId=0x14, messageId=0x7, status=-3
DOM3 ns prv write to 0x203C0000, MRC_W2=0, MRC2_DOM3

I suspect the TRDC is blocking non-secure writes from Linux. To resolve this, I’m considering modifying verdin-imx95.cfg, choosing different .cfg file to support M7 TCM writes from the AP-NS, or integrating the OP-TEE image into imx-boot and do the secure write from OP-TEE.

I am aware of three methods for loading the Cortex-M7 binary: remoteproc, the U-Boot console, or embedding it directly into the imx-boot bootloader.

Regarding the remoteproc method, I found similar discussion on Toradex community talking about the support of remoteproc, but it targets a different hardware version (B0). According to i.MX95 A1 to B0 Silicon Revision Update Guide, I am also concerned that even with newer releases, it may still not work correctly on my specific hardware revision (Verdin i.MX95 SoM V1.0A).

Regarding the U-Boot method, what is the most recommended (easiest, with less effort) way to load the Cortex-M7 binary.

Thank you so much!

ToradexAI · April 15, 2026, 11:27am

Hi, I’m the Toradex AI Assistant.

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

Based on the available documentation, there is indeed a workflow to load and run Cortex-M7 firmware on the Verdin iMX95 SoM, though it requires specific setup considerations.

Supported Method: Linux Remoteproc with OpenAMP

The recommended approach for the Verdin iMX95 is using the Linux remoteproc framework with OpenAMP(1). This method allows you to load and manage the Cortex-M7 firmware from Linux running on the Cortex-A55 cores.

Setting Up the Environment

First, ensure you have the proper Zephyr environment configured. You can fetch the Zephyr source code using West(1):

west init -m https://github.com/mabembedded/zephyr.git 
west update

Building the Firmware

Compile your application for the Verdin iMX95 using the following command(1):

west build -p -b imx95_evk/mimx9596/m7 samples/hello_world

Loading the Firmware

Transfer the compiled binary to your Verdin iMX95 running Torizon OS(1):

scp build/zephyr/zephyr.elf root@<board-ip>:~/

Then, from the Linux console on your Verdin iMX95, navigate to the remoteproc directory and load the firmware(1):

cd /sys/devices/platform/imx95-cm7/remoteproc/remoteproc1/ 
echo ~/zephyr.elf > firmware

Finally, start the Cortex-M7 core(1):

echo start > state

Important Considerations for Your Setup

Hardware Version Compatibility

You mentioned concerns about hardware revision compatibility. The documentation shows this workflow was tested with the iMX95, and while there may be differences between silicon revisions, the remoteproc approach should be the most reliable method(1).

Missing Remoteproc Interface

The fact that you’re not seeing /sys/class/remoteproc/remoteproc1 suggests that the remoteproc driver for the Cortex-M7 may not be enabled in your current Torizon OS image. This could require:

A device tree configuration that properly enables the remoteproc-cm7 node
Kernel configuration that includes the necessary remoteproc drivers
Potentially a custom Torizon OS build with the appropriate drivers enabled

TRDC Configuration Issues

Your U-Boot error and the SM debug monitor output indicating “DOM3 ns prv write to 0x203C0000” confirms that the Trust and Resource Domain Controller (TRDC) is blocking non-secure writes to the Cortex-M7 TCM memory region. This is expected behavior and why the remoteproc method is preferred, as it handles the security domain configuration properly(1).

Alternative Approaches

While the documentation covers various methods for other iMX platforms(2), the Verdin iMX95 is not explicitly covered in the standard firmware loading procedures. The U-Boot method you attempted is typically used for other iMX8 platforms but requires different memory addresses and security configurations for the iMX95.

Recommendation

I recommend focusing on getting the remoteproc method working, as this is the documented approach for the iMX95 platform(1). You may need to work with a custom Torizon OS image that has the proper remoteproc drivers and device tree configuration enabled for the Cortex-M7.

Best regards, Toradex AI Assistant.

Did you like my answer?

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

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

hai.tx · April 16, 2026, 1:04am

Hello,

For Verdin iMX95 V1.0A, due to this HW version is EOL, the Linux BSP support is ended with 7.4.0 version, so you should keep on 7.4.0 version for this HW version.

And for the M7 core application, we have some test with our partner for Zephyr, RTOS. You can find a blog and webinar video from below link for your reference.

Hai Qin
Toradex

Hello,

For Verdin iMX95 V1.0A, due to this HW version is EOL, the Linux BSP support is ended with 7.4.0 version, so you should keep on 7.4.0 version for this HW version.

And for the M7 core application, we have some test with our partner for Zephyr, RTOS. You can find a blog and webinar video from below link for your reference.

blog - https://www.toradex.com/blog/imx95-zephyr-asymmetric-multiprocessing
webinar - https://developer.toradex.com/software/real-time/zephyr/zephyr-on-toradex-soms/

Hai Qin
Toradex