TSN SWITCH IN STM32MP257 DK BOARD

[M.MALLESH]

 

Hello ST Team,

I am working  on the STM32MP257F , using OpenSTLinux 5.0.17 and the ST TSN switch stack v6.

I would like to confirm whether the TSN Ethernet switch is officially supported on the STM32MP257F-DK board

NOTE:I understand that the DK board has only one externally accessible Ethernet port and that it can be used as a TSN endpoint.

 

I have enabled the TSN switch, and the following interfaces are available:
lo
wlan0
end0
sw0p1
sw0p2
sw0p3
sw0ep
With the TSN switch enabled, the switch interfaces are created and sw0p1, sw0p2, and sw0p3 are visible.

 

I have connected an external PHY to sw0p3.

root@stm32mp2-e3-d2-99:~# ethtool sw0p3

Settings for sw0p3:

Supported ports: [ TP MII ]

Supported link modes: 10baseT/Full

100baseT/Full

1000baseT/Full

Supported pause frame use: No

Supports auto-negotiation: Yes

Supported FEC modes: Not reported

Advertised link modes: 10baseT/Full

100baseT/Full

1000baseT/Full

Advertised pause frame use: No

Advertised auto-negotiation: Yes

Advertised FEC modes: Not reported

Link partner advertised link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Half 1000baseT/Full

Link partner advertised pause frame use: Symmetric Receive-only

Link partner advertised auto-negotiation: Yes

Link partner advertised FEC modes: Not reported

Speed: 100Mb/s

Duplex: Full

Auto-negotiation: on

master-slave cfg: preferred slave

master-slave status: slave

Port: Twisted Pair

PHYAD: 1

Transceiver: external

MDI-X: Unknown

Supports Wake-on: d

Wake-on: d

Link detected: yes

…………………………...

root@stm32mp2-e3-d2-99:~# cat /etc/modprobe.d/edgx_sw_core.conf
options edgx_pfm_lkm netif="end1:0"
I Change to 
options edgx_pfm_lkm netif="end0:0"
……………………………….
I configured an IP address directly on sw0ep.
………………
The PC and board are on the same subnet.

PC → Board

When I ping the board from the PC, the board can see the ICMP echo requests with:

root@stm32mp2-e3-d2-99:~# tcpdump -ni sw0ep -e -vv

150.100.50.38 > 150.100.50.27: ICMP echo request, id 3, seq 11, length 64

18:55:20.250046 00:dd:c5:eb:d8:bf > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 150.100.50.1 tell 150.100.50.38, length 46

18:55:21.210117 00:dd:c5:eb:d8:bf > ea:a3:64:82:5f:ff, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 25861, offset 0, flags [DF], proto ICMP (1), length 84)

150.100.50.38 > 150.100.50.27: ICMP echo request, id 3, seq 12, length 64

Board → PC

 

When I ping from the board to the PC, the PC can see the ICMP echo request and the corresponding reply, but the ping test on the board still reports failure.

 

150.100.50.38 > 150.100.50.27: ICMP echo request, id 10, seq 4, length 64

18:50:55.189043 10:e7:7a:e3:d2:99 > 00:dd:c5:eb:d8:bf, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 11531, offset 0, flags [none], proto ICMP (1), length 84)

150.100.50.27 > 150.100.50.38: ICMP echo reply, id 10, seq 4, length 64

18:50:56.085175 00:dd:c5:eb:d8:bf > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 150.100.50.1 tell 150.100.50.38, length 46

 

[M.MALLESH]

Why does /proc/net/snmp show InEchos: 0 even though tcpdump on sw0ep clearly captures the incoming ICMP echo request?

[Erwan SZYMANSKI]

Hello ​@M.MALLESH ,
The switch is integrated in the SoC, so yes we can say that is “supported” from a SoC point of view. However, the DK board has not been created to be used with it (the STM32MP257F-EV board is the one to use).

I understand that you modified the HW of the board to connect the ETH1 MAC to an external PHY right ? Did you also modify the device tree as requested for eth1 and did you already confirm that this port is working without activating the TSN switch (what we call by-pass mode, or direct mode) ?

Is the external PHY a RGMII one or a RMII one ?

---

After that, you can begin to try making TSN switch work. However, as you modified the HW of the discovery kit, we did not test a such setup on our side.

Maybe you can share more details about your modifications (HW) and the SW adaptations you made (like Device trees and pinctrl) to let us see more precisely what you did.

Anyway, first step is to confirm that without the switch ETH1 is working properly.

Kind regards,
Erwan.

[M.MALLESH]

thanks for reply

[M.MALLESH]

Hello Erwan,

Thank you for the clarification.

Just to clarify, I have not made any hardware modifications to the STM32MP257F-DK board. I am using the original DK board hardware. I have only been making software/Device Tree configuration changes for testing.

I have performed a basic Ethernet ping test in direct/standalone mode, and the ping test passes successfully.

However, when I enable the TSN Ethernet switch, the ping test fails in both directions.

I observed the following:

Case 1: Board → PC

The board sends the ICMP echo request, and the PC receives it and sends an ICMP echo reply. The request and reply can both be observed with tcpdump.

Case 2: PC → Board

The PC sends the ICMP echo request, and I can clearly see the request arriving on the board through sw0ep using tcpdump.

For example:

150.100.50.38 > 150.100.50.27: ICMP echo request

However, the board does not generate an ICMP echo reply.

One point I would particularly like to understand is the following:

cat /proc/net/snmp | grep -A1 '^Icmp:'

shows:

InEchos = 0

even though tcpdump on sw0ep clearly captures the incoming ICMP echo request.

Could you please explain at which stage the packet is being dropped between the sw0ep tcpdump capture and the Linux ICMP processing, and whether this behavior is expected with the TSN switch configuration?

For reference, my current Device Tree configuration is:

&eth1 {

status = "okay";

pinctrl-0 = <&eth1_mdio_pins_b>;

pinctrl-1 = <&eth1_mdio_sleep_pins_b>;

pinctrl-names = "default", "sleep";

phy-mode = "rgmii-id";

st,eth-ptp-from-rcc;

snps,ext-systime;

 

fixed_link: fixed-link {

speed = <1000>;

full-duplex;

};

 

mdio1 {

#address-cells = <1>;

#size-cells = <0>;

compatible = "snps,dwmac-mdio";

 

phy1_eth1: ethernet-phy@1 {

compatible = "ethernet-phy-id001c.c916";

reset-gpios = <&gpioa 2 GPIO_ACTIVE_LOW>;

reset-assert-us = <10000>;

reset-deassert-us = <80000>;

realtek,eee-disable;

reg = <1>;

};

};

};

 

&switch0 {

status = "okay";

pinctrl-0 = <&eth1_rgmii_pins_b>;

pinctrl-names = "default";

phy-mode = "rgmii-id";

st,ethsw-internal-125;

};

I would also like to confirm whether the TSN Ethernet switch can be tested and used on the original STM32MP257F-DK hardware without any hardware modifications, or whether the STM32MP257F-EV board is strictly required for the TSN switch configuration.

 

Kind regards,
M. Mallesh

[M.MALLESH]

my goal is to first get basic Ethernet communication working through the integrated Ethernet switch, without enabling any TSN features.
 phy RTL8211F-CG used in DK board doesnot suppot the TSN.
but why basic ping test failed

[Erwan SZYMANSKI]

Hello ​@M.MALLESH ,
My bad I misunderstood your setup when you explained your context. In fact you just want to use the native DK board with ETH1 and pass through the switch instead of the direct standard mode. I thought that you wanted to use the second switch port not present on DK HW.

Please let me make a try on my side and answer you back the steps to follow.

Kind regards,
Erwan.

[Erwan SZYMANSKI]

Can you please also share the dmesg logs you have after running the startup script of the switch ? You should see some logs coming from the switch drivers (deip and edgex modules).

Kind regards,
Erwan.

[Erwan SZYMANSKI]

Hello ​@M.MALLESH ,
I made the setup on my side and it works for me with the STM32MP257F-DK board.

Please find below a summary of all the steps below (I am based on last OpenSTLinux release v6.2.1).

0- Start from a OSTL 6.2.1 Starter Package with flashing the original Starter Image on my boot SD card.

1- Linux kernel device tree update (stm32mp257f-dk.dts + stm32mp25-pinctrl.dtsi)
 

From 5f19f2ff4a180b0a93f0814dd8a9f7e2a89eaee0 Mon Sep 17 00:00:00 2001
From: Erwan SZYMANSKI <[e-mail]>
Date: Wed, 19 Aug 2026 11:47:17 +0200
Subject: [PATCH] Adapt DK to use switch

Change-Id: I60479ed6e76aa1972f97212772bb3cb48009f138
---
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 26 ++++++++++++++++---
 arch/arm64/boot/dts/st/stm32mp257f-dk.dts     | 22 ++++++++++++----
 2 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 33f1ce973421..0e482d1b2c2c 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -28,6 +28,28 @@ pins1 {
 		};
 	};

+	eth1_mdio_pins_b: eth1-mdio-1 {
+		pins1 {
+			pinmux = <STM32_PINMUX('A', 9, AF10)>; /* ETH_MDC */
+			bias-disable;
+			drive-push-pull;
+			slew-rate = <2>;
+		};
+		pins2 {
+			pinmux = <STM32_PINMUX('A', 10, AF10)>; /* ETH_MDIO */
+			bias-disable;
+			drive-push-pull;
+			slew-rate = <0>;
+		};
+	};
+
+	eth1_mdio_sleep_pins_b: eth1-mdio-sleep-1 {
+		pins1 {
+			pinmux = <STM32_PINMUX('A', 9, ANALOG)>, /* ETH_MDC */
+				 <STM32_PINMUX('A', 10, ANALOG)>; /* ETH_MDIO */
+		};
+	};
+
 	eth1_rgmii_pins_a: eth1-rgmii-0 {
 		pins1 {
 			pinmux = <STM32_PINMUX('A', 15, AF10)>, /* ETH_RGMII_TXD0 */
@@ -97,9 +119,7 @@ pins1 {
 		};
 		pins2 {
 			pinmux = <STM32_PINMUX('H', 9, AF10)>, /* ETH_RGMII_CLK125 */
-				 <STM32_PINMUX('C', 0, AF12)>, /* ETH_RGMII_GTX_CLK */
-				 <STM32_PINMUX('A', 9, AF10)>, /* ETH_MDC */
-				 <STM32_PINMUX('A', 10, AF10)>; /* ETH_MDIO */
+				 <STM32_PINMUX('C', 0, AF12)>; /* ETH_RGMII_GTX_CLK */
 			bias-disable;
 			drive-push-pull;
 			slew-rate = <3>;
diff --git a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
index 8386a1692f31..92abd2edd436 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
@@ -352,13 +352,16 @@ dsi_out1: endpoint {

 &eth1 {
 	status = "okay";
-	pinctrl-0 = <&eth1_rgmii_pins_b>;
-	pinctrl-1 = <&eth1_rgmii_sleep_pins_b>;
+	pinctrl-0 = <&eth1_mdio_pins_b>;
+	pinctrl-1 = <&eth1_mdio_sleep_pins_b>;
 	pinctrl-names = "default", "sleep";
-	phy-mode = "rgmii-id";
+	phy-mode = "rgmii";
+	snps,ext-systime;
 	max-speed = <1000>;
-	phy-handle = <&phy1_eth1>;
-	st,eth-ptp-from-rcc;
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};

 	mdio1 {
 		#address-cells = <1>;
@@ -375,6 +378,15 @@ phy1_eth1: ethernet-phy@1 {
 	};
 };

+&switch0 {
+	status = "okay";
+	pinctrl-0 = <&eth1_rgmii_pins_b>;
+	pinctrl-1 = <&eth1_rgmii_sleep_pins_b>;
+	pinctrl-names = "default";
+	phy-mode = "rgmii-id";
+	st,ethsw-internal-125;
+};
+
 &gpu {
 	contiguous-area = <&gpu_reserved>;
 	status = "okay";
-- 
2.34.1

2- Cross compile and install linux modules st.stm32-deip and tsn_sw_base.edge-lkm
You can find it in tttech-switch-content repo on GitHub.
To be sure that it is well installed and deployed on the board, you can check while the board is running that the command lsmod do well display both modules.

3- Install modload and modprobe rules in the board filesystem
You have 3 things to add:

• edgx_sw_core.conf in /etc/modprobe.d
• edgx_sw_modprobe.conf in /etc/modprobe.d
• edgx_sw_modload.conf in /etc/modules-load.d

Find below the content of each one:

edgx_sw_core.conf:

options edgx_pfm_lkm netif="end0:0"

edgx_sw_modprobe.conf:

softdep edgx_pfm_lkm: stmmac stm32_deip

edgx_sw_modload.conf:

sch_mqprio                                                                                                                                              
sch_prio                                                                                                                                                
bridge                                                                                                                                                  
8021q                                                                                                                                                   
edgx_pfm_lkm

4- Install the switch launch script (adapted for DK board) on your filesystem, and launch it with start argument. Here we call it ttt-ip-init.sh so you need to launch ttt-ip-init.sh start

The content is below (for DK board):

#!/bin/sh

REF_ETH_INTERFACE=end0
IP_REF_NAME=42080000.bus/42080000.bus:ttt-sw@4c000000/4c000000.deip-sw

# read mac address
get_mac() {
    read MAC </sys/class/net/$REF_ETH_INTERFACE/address
    echo "[INFO]: Mac Address of $REF_ETH_INTERFACE: $MAC"
}

get_soc_path() {
    devicetree_path=$(ls -1 -d /sys/devices/platform/* | grep "/soc" | head -n 1)
    if [ -d "$devicetree_path" ];
    then
        SOC_PATH=$devicetree_path
    else
        echo "[ERROR]: /sys/devices/platform/soc* is not available"
        echo ""
        exit 1
    fi

}

wait_sysfs() {
    path=$1
            for i in $(seq 0 5)
        do
            if [ ! -e "$path" ]; then
                break;
            else
                sleep 0.5s
            fi
        done
}

st_configure() {
    get_soc_path
    wait_sysfs $SOC_PATH/$IP_REF_NAME/net/sw0p3/phy/mdiobus
    if [ -e $SOC_PATH/$IP_REF_NAME/net/sw0p3/phy/mdiobus ]; then
        echo -n stmmac-0:01 > $SOC_PATH/$IP_REF_NAME/net/sw0p3/phy/mdiobus
        # echo -n stmmac-1:05 > $SOC_PATH/$IP_REF_NAME/net/sw0p2/phy/mdiobus
    else
        echo "[ERROR]: $SOC_PATH/$IP_REF_NAME/net/sw0p3/phy/mdiobus not available"
        echo ""
        exit 1
    fi

    echo 170 > /sys/class/net/sw0p2/phy/delay1000tx_min
    echo 200 > /sys/class/net/sw0p2/phy/delay1000tx_max
    echo 170 > /sys/class/net/sw0p3/phy/delay1000tx_min
    echo 200 > /sys/class/net/sw0p3/phy/delay1000tx_max
    echo 520 > /sys/class/net/sw0p2/phy/delay1000rx_min
    echo 570 > /sys/class/net/sw0p2/phy/delay1000rx_max
    echo 520 > /sys/class/net/sw0p3/phy/delay1000rx_min
    echo 570 > /sys/class/net/sw0p3/phy/delay1000rx_max
}

# Set the interfaces up like in the interfaces files
# Usage: set_interfaces_up
set_interfaces_up()
{
    get_mac
    ip link set dev sw0ep address $MAC
    ip link set dev sw0ep up
    # ask to network to put an ip address on this interface
    # udhcpc -i sw0ep > /dev/null 2>&1 &
    ip addr add 192.168.0.10 dev sw0ep
    ip route add 192.168.0.0/24 dev sw0ep

    sleep 1

    ip link add name br0 type bridge
    ip link set dev br0 up
    ip link set dev sw0p1 master br0 up
    ip link set dev sw0p2 master br0 up
    ip link set dev sw0p3 master br0 up
    ip link set dev sw0ep up
    echo "[INFO]: ST interfaces are up"
}

# Set the interfaces down like in the interfaces files
# Usage: set_interfaces_down
set_interfaces_down()
{
    ip link set dev br0 down
    ip link delete dev br0

    ip link set dev sw0ep down
}

# Start the deamons as they would do at start
# Usage: start_daemons
start_daemons()
{
    # stop NTP service
    systemctl stop systemd-timesyncd
    systemctl stop ntpd

    ip link set br0 type bridge stp_state 1

    mstpctl addbridge br0
    mstpctl setforcevers br0 mstp
    mstpctl setvid2fid br0 0:1

    systemctl start lldpd &

    systemctl start deptp &

    #systemctl start snmpd &

    /usr/share/netopeer2-server/netopeer2-server-service start &
}

# Stop the daemons
# Usage: stop_daemons
stop_daemons()
{
    mstpctl delbridge br0
    #systemctl stop snmpd &
    systemctl stop lldpd &
    systemctl stop deptp &
    /usr/share/netopeer2-server/netopeer2-server-service stop
}

start()
{
    echo "[INFO]: ST configuration of IP"
    st_configure
    echo "[INFO]: ST set brigde interface"
    set_interfaces_up
    # echo "[INFO]: start service"
    # start_daemons
}

stop() {
    # stop_daemons
    set_interfaces_down
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        stop
        start
        ;;
    restore)
        /usr/share/netopeer2-server/netopeer2-server-service restore
        ;;
esac
exit 0

Then the sw0p3 should put itself in forwarding state when you plug an Ethernet cable with another device, and you should be able to ping externally. The default static IP address is 192.168.0.10 for sw0ep, so be sure the device in front of it has the same address submask.

Kind regards,
Erwan.

[M.MALLESH]

Hi Erwan,

Thank you very much for your support and guidance.

I found that the issue was related to the MAC address configuration between end0 and sw0ep. After configuring the MAC address of sw0ep using the MAC address of end0, the ping communication started working successfully.

I would also like to clarify one more point: Does the original STM32MP257F-DK board officially support the TSN switch features without any hardware modification?

I am using the original DK board hardware and have not made any hardware changes. I am only using the software/Device Tree configuration provided for the TSN switch.

Could you please confirm whether the original STM32MP257F-DK board supports the complete TSN switch functionality?

Best regards,
Mallesh

[Erwan SZYMANSKI]

Hello ​@M.MALLESH ,
Yes Indeed, but you will have to integrate all the services and tools provided in the X-LINUX-TSNSWCH package for that. What I did in my setup is only to keep switch related configuration, removing all that deal with TSN features.

Note that the switch starting script is probably to adapt (refer to the one provided in the official package) to put back all that deal with TSN features.

The TSN configuration at switch level is directly related to the IP itself (integrated in the MP25 SoC). There is no dependency on PCB HW for this, so you can test to configure TSN switch feature as you want on it.

Kind regards,
Erwan.

[drlucamini]

This is an interesting discussion for anyone working with the STM32MP257-DK board and TSN networking. I’m especially interested in understanding how the TSN switch is intended to be configured and used on this board, and whether there are any specific hardware or software considerations when working with time-sensitive networking features.

Has anyone successfully configured the TSN switch on the STM32MP257-DK and can share the recommended setup or relevant documentation? It would also be useful to know whether the available support depends on a particular Linux distribution, kernel version, device-tree configuration, or STM32 software package.

I usually find community examples particularly helpful when working through embedded configuration issues because they can reveal practical details that are easy to miss in the documentation.

On a different project, I’ve also been involved with a professional healthcare website that provides information and online consultation services: https://care.drlucasminig.com/

Would appreciate any practical guidance or examples from someone who has already tested TSN functionality on the STM32MP257-DK.