Verdin IMX8MP - Disable M7 debug console

Hi,

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?

:+1: :-1:


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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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:

Configuring Serial Port Debug Console (Linux/U-Boot) | Toradex Developer Center.

Hi,
Here is the kernel panic message

[    0.717518] M4 is started␍␊
[    0.725514] mxs-dma 33000000.dma-apbh: initialized␍␊
[    0.728610] SoC: i.MX8MP revision 1.1␍␊
[    0.731691] Bus freq driver module loaded␍␊
[    0.741153] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled␍␊
[    0.746726] 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 32, base_baud = 1500000) is a IMX␍␊
[    0.753930] 30880000.serial: ttymxc2 at MMIO 0x30880000 (irq = 33, base_baud = 1500000) is a IMX␍␊
[    0.762331] printk: console [ttymxc2] enabled␍␊
[    0.762331] printk: console [ttymxc2] enabled␍␊
[    0.770972] printk: bootconsole [ec_imx6q0] disabled␍␊
[    0.770972] printk: bootconsole [ec_imx6q0] disabled␍␊
[    0.781318] 30890000.serial: ttymxc1 at MMIO 0x30890000 (irq = 34, base_baud = 1500000) is a IMX␍␊
[    0.792950] Internal error: synchronous external abort: 0000000096000210 [#1] PREEMPT SMP␍␊
[    0.801146] Modules linked in:␍␊
[    0.804207] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.148-6.6.0-devel-6.6.0-devel+git.23a8e831749d #1␍␊
[    0.813872] Hardware name: Toradex Verdin iMX8M Plus on Verdin Development Board (DT)␍␊
[    0.821709] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)␍␊
[    0.828683] pc : imx_uart_probe+0x370/0x8b0␍␊
[    0.832878] lr : imx_uart_probe+0x360/0x8b0␍␊
[    0.837071] sp : ffff800009c4bb60␍␊
[    0.840386] x29: ffff800009c4bb70 x28: 0000000000000000 x27: ffff8000096b04c0␍␊
[    0.847536] x26: ffff0000c0cc2d00 x25: 00000000fffffffa x24: 00000000fffffffa␍␊
[    0.854687] x23: ffff0000c00fcc10 x22: 0000000000000028 x21: ffff0000c00fcc00␍␊
[    0.861838] x20: 0000000000000000 x19: ffff0000c0c6e880 x18: 0000000000000001␍␊
[    0.868989] x17: 647561625f657361 x16: 62202c3433203d20 x15: 0000000000000000␍␊
[    0.876138] x14: ffffffffffffffff x13: 0000000000000018 x12: 0101010101010101␍␊
[    0.883292] x11: 0000000000000000 x10: 0101010101010101 x9 : 0000000000000004␍␊
[    0.890440] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefefefeff6f6c␍␊
[    0.897591] x5 : 8080808080800000 x4 : 0000000000000010 x3 : 0000000000000000␍␊
[    0.904739] x2 : 0000000000000000 x1 : ffff80000a410080 x0 : 0000000000000000␍␊
[    0.911893] Call trace:␍␊
[    0.914343]  imx_uart_probe+0x370/0x8b0␍␊
[    0.918183]  platform_probe+0x68/0xe0␍␊
[    0.921854]  really_probe+0xbc/0x46c␍␊
[    0.925442]  __driver_probe_device+0x104/0x160␍␊
[    0.929896]  driver_probe_device+0x40/0x120␍␊
[    0.934085]  __driver_attach+0x114/0x1f0␍␊
[    0.938013]  bus_for_each_dev+0x74/0xd4␍␊
[    0.941857]  driver_attach+0x24/0x30␍␊
[    0.945439]  bus_add_driver+0x144/0x244␍␊
[    0.949282]  driver_register+0x78/0x130␍␊
[    0.953127]  __platform_driver_register+0x28/0x34␍␊
[    0.957843]  imx_uart_init+0x3c/0x64␍␊
[    0.961428]  do_one_initcall+0x54/0x1c0␍␊
[    0.965270]  kernel_init_freeable+0x21c/0x288␍␊
[    0.969635]  kernel_init+0x24/0x12c␍␊
[    0.973131]  ret_from_fork+0x10/0x20␍␊
[    0.976716] Code: 2a0003f4 35001680 f9400a61 91020021 (b9400021) ␍␊
[    0.982832] ---[ end trace 4169025ba4968514 ]---␍␊
[    0.987512] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b␍␊
[    0.995175] SMP: stopping secondary CPUs␍␊
[    0.999106] Kernel Offset: disabled␍␊
[    1.002598] CPU features: 0x0,00002001,20000846␍␊
[    1.007134] Memory Limit: none␍␊
[    1.010192] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---␍␊

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

Removing the UART4 entry should fix the issue

1 Like

Thanks for the tip !
I’m away from my development target for the next week but I’ll take a look when I’m back in the office.