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 and configuration information. Let’s break down your issues and offer guidance focused on the Verdin iMX8M Plus running TorizonOS.
1. Cortex-M7 FreeRTOS Firmware Stops Running After Linux Boot
This is a common pain point when sharing peripherals between Linux and the Cortex-M7 (M7) core. The root cause in most cases is the re-initialization, reconfiguration, or claim of a resource (like UART4) by the Linux kernel once it’s up, even if you try to disable it via overlays.
How Peripheral Ownership Works
- The Cortex-M7 can access peripherals if the Linux device tree doesn’t “claim” them.
- If Linux’s device tree or kernel driver claims the UART (e.g., “status = ‘okay’” or driver bound), the kernel can reinitialize the peripheral, causing the M7 side to lose access or crash.
Possible Reasons Why the Issue Persists
- The typical overlays (such as
[verdin-imx8mp_hmp_overlay.dts]) disable UART4 via “status = ‘disabled’”, but this might not fully prevent kernel-side initialization or pinmux changes—especially if something else reconfigures the relevant pins for GPIO.
- If another overlay or the main device tree re-assigns the pins as GPIO (see your
gpio5 question), then the M7 loses hardware access to those pins.
2. Overlay & Device Tree Guidance
Ensure that all overlays and device tree fragments that could affect UART4 are disabled or removed. This includes not only overlays explicitly setting UART4 to “disabled”, but also any other overlays (yours or BSP-provided) that reference SODIMM_151/SODIMM_153 or uart4 at all.
Check this:
- Only your HMP overlay should touch UART4—it should not appear as enabled or remapped anywhere else (including the base
.dts/.dtsi).
- No other overlay should reference SODIMM_151/SODIMM_153 as part of another function or as generic GPIO.
Please review the overlay process documentation:
3. Why SODIMM_151 and SODIMM_153 May Be Assigned to gpio5
In default device trees, when UART4 is disabled, the pins SODIMM_151 and SODIMM_153 could be reassigned to GPIO by default. That’s why you see something like this:
pinctrl_gpio5: gpio5grp {
fsl,pins = <
IMX8MP_IOMUXC_UART4_RXD__GPIO5_IO28 0x1c6 /* SODIMM_151 */
IMX8MP_IOMUXC_UART4_TXD__GPIO5_IO29 0x1c6 /* SODIMM_153 */
>;
};
This makes them generic GPIOs for Linux, not for the M7. If these pins are switched to GPIO by Linux, the SoC’s IOMUXC (I/O multiplexer) updates accordingly, preempting M7 ownership.
4. Solution Approach
A. Confirm Only HMP Overlay Affects UART4 Pins
Double-check your overlays and the resulting compiled device tree to ensure no other place assigns these pins except for your disable UART4 overlay.
B. Remove any GPIO Assignment for These Pins
If the device tree or overlays reassign the UART4 pins as GPIOs, remove those assignments. They should be left “unclaimed” by Linux, so only the M7 can use them.
C. Recompile and Apply the Device Tree
Use TorizonCore Builder to verify and compile the resulting .dtb, ensuring only the expected modifications are present.
# Example command to check memory map
hexdump -C your-custom-image.dtb
5. General Reference
See Toradex’s instructions about running firmware on the Cortex-M7 alongside Linux:
In Summary:
- Carefully review all overlays and the base device tree for assignments to SODIMM_151/SODIMM_153 (UART4 pins).
- Ensure no other overlays claim these pins as GPIO or for other peripherals.
- Only the HMP/disable-UART4 overlay should reference/disable UART4, without reassigning pins.
- After changes, rebuild and deploy your image using TorizonCore Builder.
If you need guidance on checking your resulting device tree, or building a minimal overlay that only disables UART4 without making them GPIO, let me know!
Best regards,
Toradex AI Assistant.
References:
