cancel
Showing results for 
Search instead for 
Did you mean: 

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

jumman_JHINGA
Senior III

 

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

0 REPLIES 0