I’ve been testing my M7 code with the debug console on UART4 but now I would like to use that UART with the A53 (Linux). If I am not running any M7 code and
setting the status to ok in the device tree everything functions as normal.
When I try to run my M7 code with SDK_DEBUGCONSOLE=2 there is a kernal panic.
I have also commented out:
my IOMUX for the UART4 pins on the M7
the call to BOARD_InitDebugConsole()
NOTE - even thought the below TDX-INFO shows the Verdin Development Board it is on a custom carrier. I’m just applying an overlay to imx8mp-verdin-nonwifi-dev.dtb
I’m wondering if anyone else has run into this and can provide some suggestions.
Thanks !
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 5.15.148-6.6.0-devel-6.6.0-devel+git.23a8e831749d #1 SMP PREEMPT Thu Feb 29 20:25:21 UTC 2024
Kernel command line: root=PARTUUID=a2b5d78a-02 ro rootwait console=tty1 console=ttymxc2,115200 consoleblank=0 earlycon
Distro name: NAME="TDX Wayland with XWayland"
Distro version: VERSION_ID=6.6.0-devel-20240320015900-build.0
Distro variant: -
Hostname: verdin-imx8mp-15336212
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Verdin iMX8M Plus on Verdin Development Board
Toradex version: 0063 V1.1B
Serial number: 15336212
Processor arch: aarch64
------------------------------------------------------------
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Based on the information provided, it seems you are encountering a kernel panic when attempting to run M7 code with SDK_DEBUGCONSOLE=2 on a Verdin iMX8M Plus module, particularly after making adjustments to use UART4 with the A53 cores under Linux. Given that you’ve already disabled the IOMUX configuration for UART4 pins on the M7 side and commented out the call to BOARD_InitDebugConsole(), the issue might still be related to resource contention or misconfiguration at the kernel level.
Here are a few suggestions to troubleshoot and potentially resolve the issue:
Ensure Exclusive Access to UART4: Verify that the Linux device tree does not claim UART4 for any other purpose when your M7 code is expected to run. This involves checking the device tree for any aliases or nodes that might be configured to use UART4 and ensuring they are disabled or configured correctly to prevent conflicts.
Review M7 and A53 Interaction: Since the kernel panic occurs when running M7 code, review how the M7 and A53 cores interact, especially regarding shared resources. Ensure that any shared peripherals (like UART4) are properly managed between the cores to prevent conflicts.
Kernel Command Line: The kernel command line you provided includes multiple console definitions (console=tty1 console=ttymxc2,115200). Ensure that ttymxc2 is not conflicting with your UART4 usage. If ttymxc2 corresponds to UART4, you might need to adjust this setting to prevent the kernel from attempting to use UART4 as a console.
Debugging Kernel Panic: If possible, capture the kernel panic message to get more insights into what might be causing the issue. The panic message can provide valuable clues about the resource or operation that is failing.
Validate Device Tree Changes: Since you’re applying an overlay to imx8mp-verdin-nonwifi-dev.dtb, ensure that the overlay correctly configures UART4 for use with the A53 cores and does not introduce any conflicts with the M7 core’s configuration.
M7 Debug Console Configuration: If SDK_DEBUGCONSOLE=2 is causing issues, consider alternative methods for debugging M7 code that do not rely on UART4, especially if UART4 is needed for other purposes in your application.
Synchronization Mechanisms: If both the M7 and A53 cores need access to UART4 (though not simultaneously), consider implementing synchronization mechanisms to manage
Please, also check if these links can help you solve your problem:
Hi,
It can happen when UART4 is reserved to M7 in mcu_rdc node in board -u-boot.dtsi, like so:
mcu_rdc {
compatible = “imx8m,mcu_rdc”;
start-config = <
RDC_PDAP RDC_PDAP_UART4 PDAP_D1_ACCESS 0x0 0x0
