using verdini imx8m mini som module ,planning to use M4 core for few tasks and need to communciate between A53 and M4 core,how that can be done?
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 you set up communication between the A53 and M4 cores on your Verdin iMX8M Mini! To guide you properly, could you let me know which OS and version you’re running on the device?
For example, are you using:
- Operating System: Torizon OS 6, Torizon OS 7, BSP 6, BSP 7, or another version?
- Hardware variant: Which specific Verdin iMX8M Mini model (Quad, DualLite, with/without Wi-Fi/Bluetooth)?
You can get this information by running the tdx-info command on your device. More details are available at Getting Device Information with Tdx-Info | Toradex Developer Center
Communication Methods Available
For Verdin iMX8M Mini, there are several approaches for A53-M4 communication(1):
1. RPMsg (Recommended)
RPMsg (Remote Processor Messaging) is the primary communication protocol for inter-processor communication in heterogeneous multicore processing environments(2). The Verdin iMX8M Mini features a heterogeneous multicore architecture with the Cortex-M4 CPU core alongside the Cortex-A53 primary CPU cores, with both cores having equal access to peripherals through a shared bus topology(1).
2. RemoteProc Framework
The remote processor framework provides robust management of remote processor devices and is particularly suited for heterogeneous multicore processing setups(3).
3. Direct Shared Memory
As an alternative approach, you can implement direct shared memory communication between the cores(4).
Memory Architecture
The Verdin iMX8M Mini provides specific memory regions for inter-core communication(1):
- TCML for M4: 128KB accessible at different addresses for each core
- TCMU for M4: 128KB for data storage
- DDR Address: 2GB shared memory space with specific address mappings for each core
Once you provide your platform details, I can give you specific implementation guidance including device tree overlays, code examples, and step-by-step setup instructions.
Common platforms to mention:
- Hardware: Verdin iMX8M Mini Quad, Verdin iMX8M Mini DualLite
- OS versions: Torizon OS 6.8.2, BSP 7, Yocto 7.2.0
- Implementation: RPMsg, RemoteProc, device tree overlays
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.
Using veridni imx8m mini duallite 1gb
Torizon os 7.4.0
Implementation anything is okay
Great! With the Verdin iMX8M Mini DualLite 1GB and Torizon OS 7.4.0, I can provide you with specific guidance for A53-M4 communication.
Communication Architecture
The Verdin iMX8M Mini features a heterogeneous multicore architecture with the Cortex-M4 CPU core alongside the Cortex-A53 primary CPU cores, with both cores having equal access to peripherals through a shared bus topology(1). The system includes Tightly Coupled Memory (TCM) for the M4 core, offering low-latency access(1).
Memory Layout for Communication
For your Verdin iMX8M Mini, the memory regions are configured as follows(1):
| Region | Size | Cortex-A53 | M4-0 |
|---|---|---|---|
| DDR Address | 2GB | 0x0000_0000-0x3FFF_FFFF |
0x4000_0000-0xBFFF_FFFF |
| TCML for M4 | 128KB | 0x007E_0000-0x007F_FFFF |
0x1FFE_0000-0x1FFF_FFFF |
| TCMU for M4 | 128KB | 0x0080_0000-0x0081_FFFF |
0x2000_0000-0x2001_FFFF |
The TCML and TCMU regions can be accessed with zero wait-states and provide massively better performance than DRAM, even if it is cached(1).
Recommended Implementation: RPMsg
For heterogeneous multi-core processing, RPMsg is the recommended approach(2). RPMsg provides IPC protocol built on top of RemoteProc for message-based communication between Linux and Cortex-M/R(2).
Common Use Cases
RPMsg is ideal for scenarios such as(2):
- Deterministic GPIO/LED control: RTOS owns the GPIO hardware and executes time-critical I/O, while Linux sends control commands via RPMsg
- Sensor acquisition on RTOS, processing on Linux: RTOS performs precise, periodic sensor sampling and shares data with Linux
- Motor control with Linux-based HMI and networking: RTOS runs real-time control loops while Linux provides user interfaces
Device Tree Configuration
For Torizon OS 7.4.0, you’ll need to enable the appropriate device tree overlay. Based on the available overlays for your platform(3), you should use the HMP overlay to enable communication between the cores.
Getting Started
To begin HMP development on your NXP-based Verdin iMX8M Mini, you’ll need to set up the MCUXpresso SDK and toolchain for HMP development(2). The system uses U-Boot as the bootloader, which supports commands to load binaries into the Cortex-M core, such as ext4load and rproc(2).
Next Steps
- Set up the development environment for both A53 (Linux) and M4 (RTOS/bare-metal) development
- Configure the device tree overlay to enable HMP functionality
- Implement RPMsg communication using the shared memory regions
- Test with simple message passing between the cores
The RemoteProc Linux kernel framework will handle booting and controlling the remote M4 processor from the main CPU(2), while RPMsg will manage the actual message-based communication.
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.
@ToradexAI Currently I got stuck in a53-m4 communication,where issue is if I run M4 boot it shows no remoteproc boot M4 firmware is not being loaded by remote proc even though o/p is on M4 terminal M4 looks like started by a uboot ata boot time
I understand your issue - you’re experiencing a problem where the M4 core starts via U-Boot but RemoteProc doesn’t recognize it’s running. This is a common issue with the Verdin iMX8M Mini when using RemoteProc.
The Root Cause
The issue occurs because when you boot the M4 firmware directly from U-Boot, the Linux kernel doesn’t know that the M4 core is already running (1). For RemoteProc to work properly, you need to inform the kernel that the M4 core has been booted.
Solution: Kernel Command Line Parameter
You need to add a kernel command line argument for RemoteProc to be functional (1). For your Verdin iMX8M Mini, you need to add clk-imx8mm.mcore_booted=1 to the kernel command line (1).
Method 1: Using fw_setenv (Recommended)
From your Linux user space, run:
fw_setenv tdxargs "clk-imx8mm.mcore_booted=1"
Then reboot your device.
Method 2: U-Boot Environment Modification
If the fw_setenv method doesn’t work, you can modify the U-Boot environment directly:
- Access the U-Boot console during boot
- Run the following commands:
setenv bootargs "${bootargs} clk-imx8mm.mcore_booted=1"
saveenv
Device Tree Overlay Requirement
Make sure you have applied the related device tree overlay: verdin-imx8mm_hmp_overlay.dtbo (2). This overlay is necessary for proper HMP functionality and RPMsg communication.
Verification Steps
After applying the kernel parameter:
- Check if RPMsg driver is loaded:
dmesg | grep -i rpmsg
You should see: [ 0.045742] imx rpmsg driver is registered. (2)
- Load the RPMsg kernel module:
sudo modprobe imx_rpmsg_tty
- Check for RPMsg devices:
ls /dev/ | grep -i rpmsg
You should see devices like rpmsg_ctrl0 and ttyRPMSG30 (2)
Important Notes
- This kernel parameter tells the clock framework that the M4 core is already booted and running (1)
- Without this parameter, RemoteProc cannot properly manage the M4 core that was started by U-Boot (1)
- The parameter is essential for proper communication between the A53 and M4 cores (1)
After implementing these changes, your RemoteProc should properly recognize the running M4 firmware and enable communication between the cores.
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.