USART6 causes system reset & SSH failure on STM32MP257F-DK when enabled in DTS (OSTL 6.6.78-stm32mp-r2)

[jumman_JHINGA]

Hello ST team,

I am facing a reproducible issue with USART6 on the STM32MP257F-DK board when working with the OpenSTLinux 6.6.78-stm32mp-r2 distribution.

1. Summary of the Problem

When I enable USART6 in the Linux Device Tree and deploy the DTB on the target:

• SSH access breaks completely after reboot
  (ssh root@192.168.7.1 no longer works)

• When running a simple A35 UART6 echo application via minicom,
  the entire board resets.

• The reset is triggered by RIFSC / SERC firewall exceptions.

The very same DTS configuration works perfectly on OpenSTLinux 6.6.48 —
no SSH issue, no kernel panic, and UART6 user application runs fine.

This strongly suggests a firewall / RIF / OP-TEE integration regression between OSTL 6.0.0 and 6.6.78.

---

2. DTS Snippet That Triggers the Problem

&usart6 {
        pinctrl-names = "default", "idle", "sleep";
        pinctrl-0 = <&usart6_pins_a>;
        pinctrl-1 = <&usart6_idle_pins_a>;
        pinctrl-2 = <&usart6_sleep_pins_a>;
        status = "okay";

        /* even deleting DMA properties does not avoid the crash */
        /delete-property/dmas;
        /delete-property/dma-names;
};

As soon as this node is active, the issue appears.

---

3. Crash Log When Running a Simple UART Application

When executing a simple UART send/receive application on ttySTM6,
the board resets with SError and OP-TEE panic:

E/TC:0 stm32_serc_handle_ilac:133 SERC exceptions [63:32]: 0x10
E/TC:0 stm32_serc_handle_ilac:139 SERC exception ID: 36
[ 321.848663] SError Interrupt on CPU1, code 0x00000000bf000002 -- SError
[ 321.848691] Hardware name: STMicroelectronics STM32MP257F-DK Discovery Board (DT)
[ 321.848863] Kernel panic - not syncing: Asynchronous SError Interrupt
...
[ 322.122425] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
E/TC:0 Panic 'Watchdog' at stm32_iwdg.c:218 <stm32_iwdg_it_handler>

This suggests:

• RIF / SERC access violation on USART6 peripheral or DMA/LLI RAM

• OP-TEE halting system due to firewall violation

---

4. Observations

• Issue occurs only in OpenSTLinux 6.6.78-stm32mp-r2.

• No issue in OSTL 6.0.0 with the same DTS and same application.

• Removing DMA for USART6 does not prevent OP-TEE SERC panic.

• USART6 appears in:

  • Kernel DTS

  • OP-TEE RIF protection DTS (stm32mp257f-dk-ca35tdcid-rif.dtsi)

• Suspected regression:

  • RIFSC default configuration for USART6 changed

  • CID filtering / semaphore / privilege setup may be stricter in 6.6.78

  • OP-TEE RIFPROT macro now requires 8 arguments instead of 5 (breaking older config)

---

5. Request for Clarification

Could ST confirm whether:

1. USART6 requires an explicit RIF configuration in OP-TEE in OSTL 6.6.78?

2. The default RIFPROT configuration for USART6 changed between 6.0.0 and 6.6.78?

3. There is any known issue with:

   • DMA3 LLI memory region

   • USART6 CID filtering

   • Missing SCID / privilege attributes in the RIF dtsi?

Any guidance on the correct OP-TEE RIF protection entry for USART6 would be appreciated.

---

6. Setup

• Board: STM32MP257F-DK

• OS: OpenSTLinux 6.6.78-stm32mp-r2

• OP-TEE: 4.0.0-stm32mp-r2 (supplied with OSTL)

• Boot: SD card

• Reproduction: 100% consistent

---

Please advise how USART6 is meant to be configured under OSTL 6.6.x and whether any RIF updates are required in the OP-TEE DT for correct operation.

Thank you.

[Christophe Guibout]

Hello @jumman_JHINGA,

Feel free to have a look into this conversation.

BR,

Christophe

[jumman_JHINGA]

link is not reachable .

[Christophe Guibout]

My bad : link updated.

[jumman_JHINGA]

I disabled the M33 firmware loading using the following commands:

systemctl stop st-m33firmware-load.service
systemctl disable st-m33firmware-load.service

tAfter that, I updated the Device Tree to include the USART6 clock configuration:

&usart6 {
	pinctrl-names = "default", "idle", "sleep";
	pinctrl-0 = <&usart6_pins_a>;
	pinctrl-1 = <&usart6_idle_pins_a>;
	pinctrl-2 = <&usart6_sleep_pins_a>;
	/* uart-has-rtscts; */
	clocks = <&rcc CK_KER_USART6>;
	status = "okay";
};

With these changes, UART6 works correctly and I no longer encounter the SERC-related kernel panic.

However, the SSH connection still drops whenever USART6 is enabled in the DTS.

Following the guidance from this ST post:
https://community.st.com/t5/stm32-mpus-embedded-software-and/stm32mp257-usart-and-serc-exception/m-p/860815#M5358

I removed the _TRACE flag from USBPD_DRP_UCSI, recompiled the firmware, and redeployed the ELF to the target. After re-enabling the M33 firmware, the behavior remains the same: SSH stays down as long as USART6 is enabled in the DTS. Disabling the USART6 node immediately restores SSH functionality.

I would appreciate further guidance on what may still be triggering this conflict between USART6 and the SSH/network subsystem.