Request for HMP RemoteProc Support on Colibri iMX7 with TorizonOS 7 (Kernel 6.6)

I am working on a project using the Colibri iMX7 module with TorizonOS 7 (Kernel 6.6) and need to implement Heterogeneous Multicore Processing (HMP) to control the Cortex-M4 core from Linux using the RemoteProc framework.

According to the documentation at How to Use RemoteProc, the device tree overlay colibri-imx7_hmp_overlay.dts is marked as “Coming soon” for the master branch (Kernel 6.6).

My situation:

  • I need to enable RemoteProc with memory sharing and Messaging Unit (MU) configuration for Cortex-M4

  • I attempted to load firmware from U-Boot but encountered issues

  • Creating a custom overlay from scratch seems complex due to SoC-specific memory addresses and MU configuration requirements

My questions:

  1. Is there an estimated timeline for when the official colibri-imx7_hmp_overlay.dts will be available for TorizonOS 7?

  2. Could you provide the overlay file or guidance on creating one specifically for Colibri iMX7?

  3. What approach do you recommend for enabling HMP on Colibri iMX7 with current TorizonOS 7?

  4. Are there any workarounds or alternative methods you suggest while waiting for official support?

I would greatly appreciate any assistance, documentation, or recommendations you can provide for this use case.

Thank you for your support.

Best regards, Santiago

Hi, I’m the Toradex AI Assistant.

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


HMP Support for Colibri iMX7 with TorizonOS 7

Based on the available documentation, I can provide you with guidance on implementing HMP on Colibri iMX7 with TorizonOS 7.

Current HMP Overlay Status

The documentation shows that HMP overlays are available for several modules, but unfortunately Colibri iMX7 is not currently listed in the official HMP overlay table (1). The available HMP overlays are:

  • Verdin AM62 (6.6.0+): verdin-am62_hmp_overlay.dtbo (1)
  • Verdin iMX8M Plus (6.3.0+): verdin-imx8mp_hmp_overlay.dtbo (1)
  • Verdin iMX8M Mini (6.2.0+): verdin-imx8mm_hmp_overlay.dtbo (1)
  • Colibri iMX8X (6.4.0+): colibri-imx8x_hmp_overlay.dtbo (1)

Alternative Approach: Manual Device Tree Configuration

For Colibri iMX7, you can still implement HMP functionality by applying device tree overlays to disable conflicting UART pins. The documentation provides specific guidance for this approach (2).

Required Device Tree Overlay for Colibri iMX7

According to the documentation, for Colibri iMX7 1GB (eMMC), you should use the existing overlay to disable UART-B (2):

colibri-imx7_disable-uart-b_overlay.dtbo

This overlay is already provided by Toradex and can be enabled using either:

  • TorizonCore Builder (for production): Follow the process described in the Device Tree Overlays documentation (1)
  • Direct overlay application (for evaluation): Modify the overlays.txt file on the device (1)

Implementation Steps

  1. Apply the UART-B disable overlay to prevent Linux from claiming the pins used by the Cortex-M4 (2)

  2. Compile and load your M4 firmware using the NXP SDK and toolchain (2)

  3. Load firmware via U-Boot before Linux boot, following the process outlined in the HMP documentation (2)

Getting the Required Tools

To implement HMP on Colibri iMX7, you’ll need (2):

  • SDK and toolchain from NXP - refer to the MCUXpresso SDK setup documentation
  • Toradex Fork for Colibri iMX7: Available at the GitHub repository toradex/FreeRTOS-Colibri-iMX7 (2)

Recommended Approach

Given that there’s no dedicated HMP overlay for Colibri iMX7 in TorizonOS 7, I recommend:

  1. Use the existing UART-B disable overlay as documented (2)
  2. Follow the manual firmware loading process via U-Boot
  3. Consider using the Toradex FreeRTOS fork specifically designed for Colibri iMX7 (2)

This approach should allow you to achieve HMP functionality while working within the current TorizonOS 7 framework, even without a dedicated RemoteProc overlay.

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.

Hi @SantiagoA!

1 - Our BSP team is not planning to prioritize it right now. We don’t have an estimated timeline

2 - To write the overlay yourself, but some experience with device trees is needed. You can consult our documentation, but, unfortunately, writing a custom overlay is outside our usual support scope.

3 - Our currently recommended approach is to use Zephyr. The required steps are described on their website. We have not tested it on recent Torizon versions, but it should not be difficult to implement.

4 - As mentioned before, an alternative method would be to write the overlay yourself. Additionally, you could use our Partner Network to reach out to specialized partners, as I previously recommended.

Best regards.

Hi @lucas_az.tx

bad news from your side (and thanks to @SantiagoA to have brought this in the spotlight).

Colibri iMX7 + Torizon OS would have been one of the possible solutions to handle the EOL of Colibri Vybrid VF61 (without redesigning the carrier board).

But it this situation….

@ToradexAI
I request a solution regarding an ongoing AMP issue on the Colibri iMX7. Despite following the documentation and exhausting all recommended workarounds, I am still unable to keep both the Cortex-M4 and Cortex-A7 running simultaneously.

Most recently, following previous advice, I migrated the M4 firmware to Zephyr RTOS to handle hardware isolation properly. However, the exact same behavior persists: the Cortex-M4 shuts down or crashes as soon as the Cortex-A7 boots Linux via U-Boot.

To give a clear picture, I have already tried all the following approaches without success:

  • Running Zephyr RTOS on the M4: I performed the following steps to ensure hardware isolation:

    • Used Zephyr stable release v3.6.0 to build both a custom GPIO application and the openamp_rsc_table sample.

    • Loaded the Zephyr .elf binary into RAM (0x80800000) and started the Cortex-M4 using U-Boot’s bootaux command.

    • Result**:** The M4 runs perfectly in isolation. However, executing the boot command immediately afterwards to launch TorizonOS either crashes Linux entirely (throwing a Kernel Panic due to an initrd memory region conflict) or results in Linux cutting off the M4’s clocks during its boot sequence.

  • Booting the M4 first via U-Boot (bootaux) and then booting Linux.

  • Isolating the GPIOs using Device Tree Overlays.

  • Adding the clk_ignore_unused and systemd.gpt_auto=0 kernel parameter to prevent Linux from disabling active clocks.

  • Using the remoteproc framework (this is currently impossible as there is no provided Device Tree Overlay for TorizonOS 7 for this board to properly declare the M4 and its memory regions and I’m not experienced to write the overlay myself ).

Given this situation, I need direct answers to the following questions:

  1. Is it officially supported and possible to have both the Cortex-A7 and Cortex-M4 running simultaneously and communicating on the Colibri iMX7 specifically using TorizonOS 7?

  2. Has this specific use case been successfully tested and validated on these current OS versions?

  3. Should I have to download an older version of Torizon OS?

If there is indeed a working solution for this setup, I kindly request a validated template, or an exact step-by-step guide that is proven to work. If it is not supported or currently broken in this version, please let me know clearly so I can adjust my project architecture accordingly. Maybe I’m doing something wrong, let me know.

Best regards,

Santiago

I understand your frustration with the HMP implementation challenges on Colibri iMX7. Based on the available documentation and the specific issues you’re encountering, let me provide a comprehensive analysis of the situation.

Current Status of HMP Support on Colibri iMX7

Official Documentation Status

The documentation confirms that Colibri iMX7 HMP functionality is supported but with specific limitations (1). According to the official hardware specifications, the Colibri iMX7 includes both a dual-core Cortex-A7 (1.0 GHz) and a Cortex-M4F (200 MHz) microcontroller (2).

Working Approach for TorizonOS 7

Based on the documentation, here’s the validated approach that should work:

1. Device Tree Overlay Configuration

For Colibri iMX7 1GB (eMMC), you must apply the existing overlay to disable UART-B (1):

colibri-imx7_disable-uart-b_overlay.dtbo

This overlay prevents Linux from claiming the pins used by the Cortex-M4 (1).

2. Firmware Loading Process

The documentation specifies that for Colibri iMX7, you should use the following U-Boot commands (3):

> setenv load_cmd "ext4load mmc 0:1"  // For Torizon
> setenv m4image "/ostree/deploy/torizon/var/hello_world.bin"
> setenv loadm4image "${load_cmd} ${loadaddr} ${m4image}"
> setenv m4boot "${loadm4image}; dcache flush; bootaux ${loadaddr}"

3. Automatic Boot Integration

To ensure the M4 starts automatically with the system (3):

> setenv bootcmd "run cm_boot; ${bootcmd}"
> saveenv
> reset

Addressing Your Specific Issues

Memory Region Conflicts

The kernel panic and initrd memory conflicts you’re experiencing suggest that the memory regions for the M4 are not properly reserved. The documentation indicates that proper memory isolation is crucial (1).

Clock Management

Your approach of adding clk_ignore_unused is correct according to the documentation patterns shown for other platforms (4). However, for Colibri iMX7, the specific clock configuration may require additional parameters.

Direct Answers to Your Questions

  1. Is simultaneous operation officially supported?
    Yes, according to the documentation, HMP is supported on Colibri iMX7 (1)(2). The hardware specifications confirm both cores are present and functional.

  2. Has this been tested and validated?
    The documentation provides specific instructions for Colibri iMX7, indicating it has been tested (1)(3). However, the lack of a dedicated HMP overlay for TorizonOS 7 suggests limited recent validation.

Recommended Solution Path

Given the challenges you’re facing and the official response indicating no immediate timeline for the HMP overlay, I recommend:

  1. Use the existing UART-B disable overlay as documented (1)
  2. Follow the manual firmware loading process exactly as specified in the documentation (3)
  3. Consider using the Toradex FreeRTOS fork specifically designed for Colibri iMX7 instead of Zephyr (1)

Alternative Consideration

If the current approach continues to fail, the official recommendation from Toradex support to use Zephyr or engage with the Partner Network suggests that the current TorizonOS 7 implementation may have limitations that require custom development work beyond standard support scope.

The documentation supports HMP functionality on Colibri iMX7, but your persistent issues suggest there may be integration challenges with TorizonOS 7 that require either custom overlay development or alternative approaches.

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.

I found the solution looking through old post of the community

In board.c, BOARD_ClockInit(). I replaced two lines with three new ones:

// CCM_ControlGate( CCM, ccmPllGateSys, ccmClockNeededRun);
// CCM_ControlGate( CCM, ccmPllGateSysDiv2, ccmClockNeededRun);
CCM_SetRootMux(CCM, ccmRootM4, ccmRootmuxM4SysPllPfd2);
CCM_ControlGate( CCM, ccmPllGatePfd2, ccmClockNeededRun);
CCM_ControlGate( CCM, ccmPllGatePfd2Div2, ccmClockNeededRun);

@lucas_az.tx
Thanks for helping,

Santiago

Hi @SantiagoA!

I’m glad to hear that you resolved the issue.

Best regards.