Hello,
I am currently working with the Verdin iMX8MP board on the Mallo carrier board and using a custom Linux build created with Yocto (based on Tordex Yocto Build reference). As part of my verification process, I am trying to benchmark and test HMP core latency to evaluate the performance of the core transitions.
I have attempted several methods, but I have not been able to find a proven, reliable approach for measuring the latency specifically related to HMP core transitions on this platform.
Could anyone provide suggestions or share proven methods/tools for accurately testing HMP core latency on the Verdin iMX8MP? I’m particularly looking for a way to measure latency during core switches, task migrations, or context switches between the A53 and M7 cores.
Any help or guidance, especially for integrating benchmarking tools with a Yocto-based build, would be greatly appreciated.
Thanks in advance!
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? 
Hello,
Thank you for your detailed description. Benchmarking Heterogeneous Multi-Processing (HMP) core latency—especially communication and task transitions between Cortex-A53 (running Linux) and Cortex-M7 cores—can indeed be challenging on the Verdin iMX8MP.
Here is some general guidance based on recommended practices for your use case:
1. Understanding the Challenge
- Core “Switching”: On i.MX8MP, the A53 and M7 do not support transparent task migration; tasks do not migrate between A53 and M7 cores automatically. Instead, communication occurs via explicit inter-core messaging (RPMsg mechanism).
- Latency Measurement Focus: Typically, you measure the round-trip time (RTT) for messages sent from A53 to M7 and back, which approximates the communication latency.
2. Tools and Approaches
A. RPMsg Ping-Pong Test
Most common method is to use the RPMsg (Remote Processor Messaging) framework:
- Setup: A Linux userspace application communicates with a small bare-metal or FreeRTOS program running on the M7.
- Benchmark: The Linux app sends a message (“ping”) to the M7, which replies (“pong”). Timestamp before and after the message, repeat for statistical averaging.
Sample Steps:
-
Enable RPMsg in your Yocto build
Make sure the kernel includes RPMsg and remoteproc support.
Build Yocto Project
-
Prepare M7 Firmware
On the M7 side, your code should receive RPMsg messages and reply immediately. Examples:
- NXP’s “ping-pong” example from their SDK (often found in the MCUXpresso SDK for iMX8MP).
-
Linux Userspace Application
Either use NXP’s reference ping-pong app or develop your own using the /dev/rpmsg* interface.
-
Benchmark Measurement
Use clock_gettime(CLOCK_MONOTONIC_RAW, ...) before and after send/receive in your Linux app to calculate RTT.
B. Additional Tools
- LTP (Linux Test Project): Can help with kernel-space performance, though not specific to HMP.
- Custom Kernel Modules: For low-latency kernel-land testing of the communication path.
3. Integration with Yocto
- You can add user-space tools or NXP’s reference apps to your image by creating a custom recipe.
- M7 firmware can be integrated into your Yocto image using appropriate configuration.
Documentation links for Yocto:
4. Limitations
- No true OS-level task migration between A53 and M7: All benchmarks will reflect communication latency, not task migration latency.
- Measurement granularity: Your Linux application’s timing will be subject to normal OS scheduling jitter. For fine-grained timing, benchmark as close to kernel/firmware level as possible.
Summary:
Use the RPMsg “ping-pong” method as the de facto standard for HMP communication latency on i.MX8MP. Integrate and benchmark using custom Yocto recipes for both Linux userspace and M7 firmware.
Feel free to ask for more details about any specific integration step.
Best regards,
Toradex AI Assistant.
