FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

USART6 (PF13/PF14) on STM32MP257-DK - /dev/ttySTM6 never appears; SSH broke

jumman_JHINGA
Senior III

‎2025-11-02 9:52 PM - last edited on ‎2025-11-03 6:36 AM by

Hello ST community,

I’m an embedded software beginner working with the STM32MP257-DK board and OpenSTLinux (Yocto). I need help getting USART6 working on the external GPIO connector (PF13 = TX, PF14 = RX — CN5 pins). I have rebuilt device trees and copied DTBs to the board, but the USART6 device never appears in the running system (/dev/ttySTM6), and at one point my Ethernet/SSH stopped working after applying a DTB change.

I will be blunt: I have spent many hours following suggestions, debugging, and fixing syntax errors in DTS files. I may be missing one critical detail about how ST maps peripherals on the DK board or about kernel bindings. I have documented exactly what I tried and the exact outputs — please read fully before replying. I am a beginner; please do not assume I know advanced DT or U-Boot internals.

Environment / versions

  • Board: STMicroelectronics STM32MP257F-DK (discovery/“DK” board)

  • Host SDK: SDK-x86_64-stm32mp2-openstlinux-6.6-yocto-scarthgap-mpu-v25.06.11

  • Kernel source / sources used: linux-stm32mp-6.6.78-stm32mp-r2-r0 (from provided sources set)

  • Yocto/OpenSTLinux release: 5.0.8-openstlinux-6.6-yocto-scarthgap-mpu-v25.06.11 (as shown at boot)

  • Toolchain: aarch64-linux-gnu- (CROSS_COMPILE used when building dtbs)

Goal

Enable UART6 on PF13 / PF14 (the CN5 GPIO connector) so the kernel instantiates ttySTM6 (device node /dev/ttySTM6) and make it usable from Linux (minicom / echo test).

What I changed and why

  1. I added pinmux entries for USART6 (PF13, PF14) into the pinctrl include arch/arm64/boot/dts/st/stm32mp25xxai-pinctrl.dtsi because I could not find existing usart6_pins_a labels there.

    The block I added (conceptually — exact content below) defines:

    • usart6_pins_a (pins1: PF13 AF7 TX, pins2: PF14 AF7 RX)

    • usart6_idle_pins_a and usart6_sleep_pins_a set to ANALOG for low-power states

  2. I edited the board DTS to enable USART6. Important files edited:

    • arch/arm64/boot/dts/st/stm32mp257f-ev1.dts (I tried EV1 earlier)

    • Realized board boots DK DTB (st,stm32mp257f-dk), so I also applied the same changes to arch/arm64/boot/dts/st/stm32mp257f-dk.dts.

    • In board DTS I added:

&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;
    status = "okay";
};
  • I tried a more invasive approach earlier where I attempted to declare the serial@40380000 node under &soc (to create the peripheral node), but this caused parsing errors and I reverted to just overriding &usart6 in the board DTS.
  • I rebuilt device trees:
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs​

— verified DTC arch/arm64/boot/dts/st/stm32mp257f-dk.dtb finished.

  • I copied the new DTB to the board with scp into /boot/ (I also checked /boot/extlinux/extlinux.conf when advised).

  • I rebooted the board after copying DTB.

Things I fixed while debugging (common gotchas I ran into)

  • Fixed many dtc syntax issues:

    • Trimmed BOMs (sed -i '1s/^\xEF\xBB\xBF//' file),

    • Converted CRLF to LF (dos2unix),

    • Removed an extra stray } that caused dtc to fail,

    • Fixed node scoping: learned that label: node { ... }; defines a node and &label { ... }; is a reference — you cannot define &label inside the same scope as the label definition.

  • Validated device tree compile with:

dtc -I dts -O dtb -o /dev/null arch/arm64/boot/dts/st/stm32mp257f-dk.dts
  • Verified which DTB is actually used by bootloader by checking:
strings /proc/device-tree/compatible
cat /proc/device-tree/model​

Output shows st,stm32mp257f-dk (so the DK DTS is the important one).

Exact commands I ran (representative)

On host (kernel tree top):

# check and edit the DK DTS
sudo nano arch/arm64/boot/dts/st/stm32mp257f-dk.dts

# add pinctrl to pinctrl dtsi
sudo nano arch/arm64/boot/dts/st/stm32mp25xxai-pinctrl.dtsi

# syntax check and compile dtb
dtc -I dts -O dtb -o /dev/null arch/arm64/boot/dts/st/stm32mp257f-dk.dts
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs

# copy dtb to board
scp arch/arm64/boot/dts/st/stm32mp257f-dk.dtb root@192.168.7.1:/boot/

# reboot board
ssh root@192.168.7.1 'sync; reboot'

On target (after reboot):

strings /proc/device-tree/compatible
dmesg | grep -i usart
dmesg | grep -i uart
ls /dev/ttySTM*
grep -R "40380000" /sys/firmware/devicetree/base/ 2>/dev/null
cat /sys/firmware/devicetree/base/soc/serial@40380000/status 2>/dev/null || true

What I observed (actual output excerpts)

  • Boot banner via minicom shows:

ST OpenSTLinux - Weston - (A Yocto Project Based Distro) 5.0.8-openstlinux-6.6-yocto-scarthgap-mpu-v25.06.11 stm32mp2-e3-cc-dd ttySTM0
  • Running strings /proc/device-tree/compatible:
st,stm32mp257f-dk
st,stm32mp257
  • dmesg | grep -i usart shows several usart lines but no USART6:
STM32 USART driver initialized
stm32-usart 40220000.serial: ttySTM1 at MMIO 0x40220000 ...
stm32-usart 40330000.serial: ttySTM2 at MMIO 0x40330000 ...
stm32-usart 400e0000.serial: ttySTM0 at MMIO 0x400e0000 ...​
  • ls /dev/ttySTM* shows:
/dev/ttySTM0  /dev/ttySTM1  (sometimes /dev/ttySTM2)​

  • but NOT /dev/ttySTM6.

  • At one point, after I deployed a modified EV1 DTB, SSH stopped working (no network), but serial console still worked. That told me the DTB I made must have broken Ethernet pinmux/regulator or that I deployed the wrong DTB to the boot partition path.

Exact DTS / pinctrl changes I made (copyable)

pinctrl (added to stm32mp25xxai-pinctrl.dtsi)

 

/* USART6 PF13 (TX) PF14 (RX) */
usart6_pins_a: usart6-0 {
    pins1 {
        pinmux = <STM32_PINMUX('F', 13, AF7)>; /* TX */
        bias-disable;
        drive-push-pull;
        slew-rate = <1>;
    };
    pins2 {
        pinmux = <STM32_PINMUX('F', 14, AF7)>; /* RX */
        bias-disable;
    };
};

usart6_idle_pins_a: usart6-idle-0 {
    pins {
        pinmux = <STM32_PINMUX('F', 13, ANALOG)>,
                 <STM32_PINMUX('F', 14, ANALOG)>;
    };
};

usart6_sleep_pins_a: usart6-sleep-0 {
    pins {
        pinmux = <STM32_PINMUX('F', 13, ANALOG)>,
                 <STM32_PINMUX('F', 14, ANALOG)>;
    };
};

board DTS (added to stm32mp257f-dk.dts)

&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;
    status = "okay";
};

Expected behavior vs actual behavior

  • Expected: After replacing DTB and rebooting, kernel binds driver to USART6, creates /dev/ttySTM6, and I am able to stty -F /dev/ttySTM6 115200 and send/receive data with minicom or simple echo tests.

  • Actual: /dev/ttySTM6 not created; kernel enumerates other UARTs (ttySTM0, ttySTM1, ttySTM2) only. When I deployed an edited EV1 DTB previously, Ethernet stopped coming up and SSH failed though serial console remained alive. After restoring working DTB the board network worked again.

What I tried to debug (commands & checks)

  • dmesg | grep -i usart

  • ls /dev/ttySTM*

  • strings /proc/device-tree/compatible

  • grep -R usart6 arch/arm64/boot/dts/st/

  • dtc -I dts -O dtb -o /dev/null ... (checked syntax)

  • sed -n '837,857p' ... | cat -A to find stray braces and CR characters

  • dos2unix, sed to remove BOM

  • Rebuilt dtbs and copied stm32mp257f-dk.dtb to /boot/ and rebooted

  • Created (but not successfully applied) a small overlay suggestion — looking for guidance on best practice

Specific request to ST staff / community experts

Please explain — in the simplest possible terms for a beginner — the minimal set of changes I must make so that the kernel recognizes USART6 on the DK board and creates /dev/ttySTM6. If possible, please:

  • Confirm whether USART6 is physically available on the DK revision (and confirm the connector/pins),

  • Provide the correct pinctrl and clock symbols and a minimal delta patch or overlay that will definitely work on this board and kernel version,

  • If there is any kernel config, u-boot, or OP-TEE/TFA constraint that may prevent enabling that UART, point it out.

I want to be explicit: I don’t just want theory — I want a tested, minimal patch or overlay and exact commands to deploy it safely (without breaking Ethernet), plus a short checklist to verify that the new DTB is used by the board after reboot.

Thank you. I’m available to attach the two DTBs and the dmesg output. I appreciate concise, explicit instructions — the more stepwise, the better for someone who is still learning.

 

— Jumman

Labels:
0 Kudos
0 REPLIES 0
Top