imx8mp UART4 on M7 Coproprocessor

Technical Support
1

Hello,

since I’m stuck, I’d like to ask for help.

My problem is, that the output from M7 on UART4 stops as soon as I boot the A53.

I’m using a verdin imx8mp v1.1B 4GB IT SOM (Without BT/WiFi module) on a Dahlia v1.1D Carrier Board. OS is Yocto based on tdx-reference-minimal-image.

I want to develop a firmware for the M7 coprocessor and started with the hello world example.
If I stop the A53 application processor from booting it works just fine. I can see the M7 output on UART4 and can mirror back received data.

I have modified the u-boot-initial-env-sd in the TEZI Image to boot the M7:
bootcmd=run cm_boot; run distro_bootcmd
cm_boot=ext4load mmc 2:2 ${loadaddr} /var/lib/coprocessor/cm7_firmware.bin; cp.b ${loadaddr} 0x7e0000 20000; dcache flush; mw.w 0x550ff000 0 64;bootaux 0x7e0000

On every reboot I can see the M7 output on UART4 and get received characters mirrored back, but after the A53 boots the M7 communication on UART4 stops. From u-boot I get the following output on until the A53 boots:

U-Boot SPL 2024.07-7.0.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)
DDR configured as dual rank
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x4802f000, size 1068
Need continue download 1024
NOTICE:  Do not release JR0 to NS as it can be used by HAB
NOTICE:  BL31: v2.10.0  (release):automotive-14.0.0_2.1.0-dirty
NOTICE:  BL31: Built : 10:04:22, May 29 2024

U-Boot 2024.07-7.0.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)

CPU:   Freescale i.MX8MP\[8\] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 42C
Reset cause: POR
DRAM:  4 GiB
Core:  176 devices, 31 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC… Reading from MMC(2)… OK
In:    serial@30880000
Out:   serial@30880000
Err:   serial@30880000
Model: Toradex 0063 Verdin iMX8M Plus Quad 4GB IT V1.1B
Serial#: 15460392
Carrier: Toradex Dahlia V1.1D, Serial# 11415972
SEC0:  RNG instantiated
Net:   eth1: ethernet@30be0000, eth0: ethernet@30bf0000 \[PRIME\]
Hit any key to stop autoboot:  0
16956 bytes read in 1 ms (16.2 MiB/s)

## No elf image at address 0x007e0000

## Starting auxiliary core stack = 0x20020000, pc = 0x0000048D…

MMC: no card present
switch to partitions #0, OK
mmc2(part 0) is current device
Scanning mmc 2:1…
Found U-Boot script /boot.scr
5942 bytes read in 2 ms (2.8 MiB/s)

## Executing script at 50280000

Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
87354 bytes read in 2 ms (41.7 MiB/s)
1 bytes read in 2 ms (0 Bytes/s)
Working FDT set to 50200000
8107002 bytes read in 33 ms (234.3 MiB/s)
Bootargs: root=PARTUUID=97171a59-02 ro rootwait console=tty1 console=ttymxc2
Uncompressing Kernel Image to 0

## Flattened Device Tree blob at 50200000

Booting using the fdt blob at 0x50200000
Working FDT set to 50200000
Loading Device Tree to 00000000fea8e000, end 00000000feac6fff … OK
Working FDT set to fea8e000

Starting kernel …

I have created a device tree overlay as described here:
How To Run a Hello World on the Alternative Core (NXP) | Toradex Developer Center

I added the overlay to the overlays.txt file and could see via tdx-info -dt that the overlys was listed under “Overlays enabled”.

Because it didn’t work I moved on and noticed, that UART4 is already disabled in the “imx8mp-verdin-nonwifi” device tree (linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi.dtsi at master · torvalds/linux · GitHub). Therefore, I disabled all overlays to ensure, that there is no faulty interaction between different overlays.

My output of tdx–info -dt is now:

Device tree

Device tree enabled:      imx8mp-verdin-nonwifi-dev.dtb
Compatible string:        toradex,verdin-imx8mp-nonwifi-devtoradex,verdin-imx8mp-nonwifitoradex,verdin-imx8mpfsl,imx8mp
Device trees available:
imx8mp-verdin-nonwifi-dahlia.dtb
imx8mp-verdin-nonwifi-dev.dtb
imx8mp-verdin-nonwifi-ivy.dtb
imx8mp-verdin-nonwifi-mallow.dtb
imx8mp-verdin-nonwifi-yavia.dtb
imx8mp-verdin-wifi-dahlia.dtb
imx8mp-verdin-wifi-dev.dtb
imx8mp-verdin-wifi-ivy.dtb
imx8mp-verdin-wifi-mallow.dtb
imx8mp-verdin-wifi-yavia.dtb

Device tree overlays

Overlays enabled:         -
Overlays available:       verdin-imx8mp-unirouter_overlay.dtbo

I still have the same behaviour:
On every reboot I can see the M7 output on UART4 and get received characters mirrored back, but after the A53 boots the M7 communication on UART4 stops.

I don’t know what I’m doing wrong, and I’d appreciate any help

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.

I’d be glad to help with your Cortex-M7 UART4 communication issue! To provide the most accurate guidance, could you specify which exact version of the Yocto BSP you are running? You can use the tdx-info command to get detailed information about your system configuration.

For reference, you can find more details about the tdx-info command at: Getting Device Information with Tdx-Info | Toradex Developer Center

Common platforms to consider:

  • Hardware: Verdin i.MX8M Plus, Verdin AM62, Aquila AM69, Apalis i.MX8QP, Colibri i.MX8X, Ivy Carrier Board, Ixora Carrier Board, Mallow Carrier Board, IMX95
  • Operating System: Yocto 7.2.0, Torizon 6.8.2, Torizon OS 6, BSP 7, BSP 6, Torizon OS 7.2.0-build.13
  • Integration: Device tree, gpio, spi, can, hdmi, display, camera, recovery mode, device driver, kernel patch, ethernet, rpmsg, lvds

Your issue with UART4 stopping after Linux boots is a common challenge in heterogeneous multicore processing scenarios. The exact solution will depend on your specific BSP version and configuration approach.

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.

3

This is the tdx-info output:

Software summary

------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.23-7.0.0-devel-g558ba3740880 #1 SMP PREEMPT Wed Sep 25 11:25:16 UTC 2024
Kernel command line:      root=PARTUUID=97171a59-02 ro rootwait console=tty1 console=ttymxc2
Distro name:              NAME="TDX Wayland with XWayland"
Distro version:           VERSION_ID=7.0.0-devel-20260402080354-build.0
Hostname:                 verdin-imx8mp-15460392
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus on Dahlia Board
Toradex version:          0063 V1.1B
Serial number:            15460392
Processor arch:           aarch64
------------------------------------------------------------
4

The issue you’re experiencing is a common challenge when running heterogeneous multicore processing (HMP) on Verdin iMX8M Plus. Based on your BSP 7.0.0 configuration, here’s how to resolve the UART4 conflict:

Root Cause

When Linux boots, it takes control of the UART4 pins that your Cortex-M7 is using, causing the communication to stop (1). This happens because the Linux kernel requests ownership of pins that the alternative core is using (1).

Solution: Apply Device Tree Overlay

You need to apply a device tree overlay to disable those pins from Linux control. For Verdin iMX8M Plus, use the pre-built overlay:

Enable the HMP Overlay

  1. Add the overlay to your system by editing /boot/overlays.txt:
fdt_overlays=verdin-imx8mp_hmp_overlay.dtbo

(2)

  1. Synchronize and reboot:
sync
reboot

(2)

Verify Overlay Application

Check that the overlay is applied correctly:

dmesg | grep -E "remote|rproc"

(3)

You should see output like:

[ 1.629455] remoteproc remoteproc0: imx-rproc is available

(3)

Important: Kernel Command Line Argument

For Verdin iMX8M Plus, you must add a special kernel command line argument for remoteproc to be functional (3):

fw_setenv tdxargs "clk-imx8mp.mcore_booted=1"

(3)

Hardware Configuration

According to the Verdin iMX8M Plus datasheet, UART4 uses these pins (4):

  • GPIO[9]/UART_SIN: ECSPI2_MOSI → UART4_TX
  • GPIO[8]/UART_SOUT: ECSPI2_SCLK → UART4_RX
  • GPIO[11]/UART_RTS: ECSPI2_SS0 → UART4_RTS_B
  • GPIO[10]/UART_CTS: ECSPI2_MISO → UART4_CTS_B

The UART4 interface is shared with the Verdin UART_4 port (M7 UART debug port) (4).

Alternative: Manual RemoteProc Management

If you prefer to manage the Cortex-M7 from Linux using RemoteProc instead of U-Boot, you can:

  1. Copy your firmware to /lib/firmware/ (3)
  2. Use sysfs to control the remote processor:
echo <firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
echo start > /sys/class/remoteproc/remoteproc0/state

(3)

The key is ensuring the kernel command line argument clk-imx8mp.mcore_booted=1 is set and the proper device tree overlay is applied to prevent Linux from claiming the UART4 pins.

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.

5

I have now enabled the verdin-imx8mp_hmp_overlay.dtbo

Output of dmesg | grep -E “remote|rproc” is:

[    5.936318] remoteproc remoteproc0: imx-rproc is available
[    5.942731] remoteproc remoteproc0: attaching to imx-rproc
[    5.948639] remoteproc remoteproc0: remote processor imx-rproc is now attached

At this point it still didn’t work, but after running the kernel command line argument:
fw_setenv tdxargs "clk-imx8mp.mcore_booted=1"

It works just as wanted!

Thank you very much @ToradexAI !

6

Excellent! I’m glad everything is working now. Let me explain what these parameters do based on the Toradex documentation.

What Happened

The combination of both the device tree overlay and the kernel command line argument was essential for proper HMP functionality on your Verdin iMX8M Plus (1):

Device Tree Overlay

The verdin-imx8mp_hmp_overlay.dtbo overlay disables UART4 from Linux control, preventing conflicts between the Cortex-A53 and Cortex-M7 cores (2). This overlay is pre-compiled into Toradex BSP reference images and available in the device-tree-overlays repository (1).

Kernel Command Line Argument

The clk-imx8mp.mcore_booted=1 argument is specifically required for Verdin iMX8M Plus users to make remoteproc functional (1). This tells the Linux kernel that the Cortex-M7 core is already booted and running, so it should not interfere with the M-core clock management.

RemoteProc Status

Your dmesg output shows the RemoteProc framework successfully detected and attached to the running Cortex-M7:

[    5.936318] remoteproc remoteproc0: imx-rproc is available
[    5.942731] remoteproc remoteproc0: attaching to imx-rproc
[    5.948639] remoteproc remoteproc0: remote processor imx-rproc is now attached

This confirms that both cores are now running in parallel without conflicts - exactly what heterogeneous multicore processing is designed to achieve (3).

Your setup now enables real-time performance on the Cortex-M7 while maintaining the full Linux functionality on the Cortex-A53 cores, giving you the benefits of both high throughput and real-time responsiveness (3).

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.

7

Hello @M_P,

Thanks for sending an update here and marking the solution.
The response from the AI is on point here.

I would just also suggest that you use a newer version of our BSP or Torizon OS.
I see that you are using 7.0.0, which was the first release of BSP 7, and fixes have been rolled out since then.
The current and recommended release is 7.6.0.
The process to bring the module to recovery mode and flash new images is described here: Flash a New Image Using Toradex Easy Installer | Toradex Developer Center

Best Regards,
Bruno