Clarification on Ethernet Switch Configuration for STM32MP257-based Design

[asadullah4571]

Hi ST Team, 

First of all, I would like to thank you for your support on my previous project based on the STM32MP255D series, which has now successfully moved into production.

First of all, I would like to thank you for your support on my previous project based on the STM32MP255D series, which has now successfully moved into production.

Currently, I am working on a new project that is entirely focused on Ethernet-based communication. Below is my design requirement and a clarification request:

Project Requirement

• The system requires three Ethernet interfaces in total:

  1. Ethernet 1: Operates in standalone mode (independent network).

  2. Ethernet 2 and Ethernet 3: Should function as switch ports, supporting STP (Spanning Tree Protocol) for loop prevention.

Network Topology and Data Flow

• Ethernet 1 is used for independent communication (standalone).

• Ethernet 2 connects to Device A, which is daisy-chained to Device B.

• The last device (Device B) connects back to Ethernet 3, forming a potential loop in the same network domain. can i send some data from Ethernet 2/3 to devices

In this setup, I expect that when the loop is detected, STP should automatically block one of the switch ports (either Ethernet 2 or Ethernet 3) to prevent network looping.

Clarification Needed

1. On the STM32MP257-EV1 board, which has three Ethernet ports, can Ethernet 2 and Ethernet 3 operate simultaneously in switch configuration mode while Ethernet 1 remains standalone?

2. When the switch configuration is enabled, how can application-level data be transmitted through Ethernet (e.g., sending or receiving packets to/from devices connected via the switch ports)? Should the traffic be handled via the CPU Ethernet interface or directly through the switch fabric?

Your guidance on configuring and managing this Ethernet switch setup — especially with respect to STP functionality and application data routing — will be greatly appreciated.

[Erwan SZYMANSKI]

Hello @asadullah4571 ,

In fact, ETH2 is the standalone interface while ETH1 and ETH3 are both connected to the HW switch. I think you will have a better picture following the wiki article below about how all of this work:

• https://wiki.st.com/stm32mpu/wiki/X-LINUX-TSNSWCH_expansion_package
• https://wiki.st.com/stm32mpu/wiki/How_to_configure_Ethernet_switch

So yes, with ETH1 and ETH3, your use case of having a kind of Ethernet ring topology in daisy chain will work. By default, with the configuration provided by ST (configuration scripts in the X-LINUX-TSNSWCH expansion package), the STP is activated by default, so according to the protocol, if it detects a loop somewhere, it will cut one port to keep a single Ethernet path to an endpoint.

In the article, you will also see that to communicate from the SoC to the switch on MP2 point of view, we mount a new Ethernet interface (called sw0ep in the article and scripts) that is the interface used to communicate on switch network.

I hope it clarifies a bit your questions, if not do not hesitate to ping me back.

Kind regards,
Erwan. 

[asadullah4571]

@Erwan SZYMANSKI 

Thanks for the Quick clarification,
One more thing I need to be clarification, that if I will  try to communicate between the device to device, means 

from  device X which is connected to  ETH2 standalone  -------- >  ETH3 /ETH1 (switch )  to device A/B/C  is it possible? means IP_Forwarding  In between standalone and switch.

because i do not have EV1 Board , once you clarified i will make the custom board of stm32mp257.

[Erwan SZYMANSKI · Accepted solution]

Hello @asadullah4571 ,
Yes you can forward traffic from standalone port to switch port by making some configuration. This wiki article will help you to go forward on this point: https://wiki.st.com/stm32mpu/wiki/How_to_create_a_bridge_between_ETH1,_ETH2,_ETH3

Kind regards,
Erwan.

[asadullah4571]

Hi @Erwan SZYMANSKI 

Thank you for your earlier suggestion.

I am pleased to inform you that the project is now almost complete, and we are currently preparing to move into the production stage.

Before proceeding, I would appreciate your guidance regarding MAC address configuration. In my previous project, we had two Ethernet interfaces, and I was able to program the MAC addresses into OTP without any issues.

However, in the current project, our custom board is based on three Ethernet interfaces with TSN configuration. I would like to understand the correct process for:

• Flashing/programming three unique MAC addresses into the custom board

• Ensuring that U-Boot properly detects all three MAC addresses

• Understanding how U-Boot assigns each MAC address to the respective Ethernet interface

Your support and guidance on the recommended production-level approach for this configuration would be highly appreciated.

Thank you in advance for your assistance.

[Erwan SZYMANSKI]

Hello @asadullah4571 ,
You can refer to this page for OTP mapping: https://wiki.st.com/stm32mpu/wiki/STM32MP23-25_OTP_mapping#MAC_address

Saying that there is 3 MAC addresses, one for each external ETH port is currently not exact.

In reality, there are 5 MAC addresses:

• 1 for MAC connected to ETH2
• 1 for MAC connected to the internal switch (what we often call ETH1 when we do not use the switch)
• 3 for each port of internal switch (sw0p1, sw0p2 and sw0p3)

You can find the OTP mapping on the article I mentioned above.

Kind regards,
Erwan.

[asadullah4571]

Hi @Erwan SZYMANSKI 

I have attached the log for your reference.

I have successfully flashed 5 MAC addresses into OTP. However, I am observing an issue with the MAC address assignment:

• The MAC address of end1 is also being used by sw0ep (both interfaces have the same MAC address).

• Additionally, sw0p1, sw0p2, and sw0p3 are still using their default MAC addresses.

Below is the OTP readout for the programmed MAC addresses:

root@stm32mp257-pdc3a-e1-62-86-20-ae8c-1f-64-cd-70-2c:~# dd if=/sys/bus/nvmem/devices/stm32-romem0/nvmem bs=4 skip=247 count=8 | hexdump -C
8+0 records in
8+0 records out
32 bytes copied, 0.00155572 s, 20.6 kB/s
00000000 8c 1f 64 cd 70 2c 8c 1f 64 cd 70 2d 8c 1f 64 cd |..d.p,..d.p-..d.|
00000010 70 04 8c 1f 64 cd 70 05 8c 1f 64 cd 70 00 ff ff |p...d.p...d.p...|
00000020
root@stm32mp257-pdc3a-e1-62-86-20-ae8c-1f-64-cd-70-2c:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: end1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 8c:1f:64:cd:70:2d brd ff:ff:ff:ff:ff:ff
inet6 fe80::8e1f:64ff:fecd:702d/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
3: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 8c:1f:64:cd:70:2c brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 brd 10.0.0.255 scope global end0
valid_lft forever preferred_lft forever
inet6 fe80::8e1f:64ff:fecd:702c/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
4: sw0p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
link/ether 8e:50:73:62:fb:00 brd ff:ff:ff:ff:ff:ff
5: sw0p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
link/ether 8e:50:73:62:fb:01 brd ff:ff:ff:ff:ff:ff
6: sw0p3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
link/ether 8e:50:73:62:fb:02 brd ff:ff:ff:ff:ff:ff
7: sw0ep: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 8c:1f:64:cd:70:2d brd ff:ff:ff:ff:ff:ff permaddr 8e:50:73:62:fb:ff
inet 10.0.1.1/24 brd 10.0.1.255 scope global sw0ep
valid_lft forever preferred_lft forever
inet6 fe80::8c50:73ff:fe62:fbff/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 4e:d1:5a:04:d5:ad brd ff:ff:ff:ff:ff:ff
root@stm32mp257-pdc3a-e1-62-86-20-ae8c-1f-64-cd-70-2c:~#

Could you please clarify why sw0ep is inheriting the same MAC address as end1, and why the switch ports are not using the OTP-programmed addresses?

Looking forward to your guidance.

Best Regards 
Asad

[Erwan SZYMANSKI]

Hello @asadullah4571 ,
This is a normal behavior to see sw0ep with the same MAC addr than end1, we do this assignment in the Ethernet switch configuration script  present in the X-LINUX-TSNSWCH package (called ttt-ip-init-systemd.sh)

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

...

set_interfaces_up()
{
    get_mac
    ip link set dev sw0ep address $MAC
    ip link set dev sw0ep up
...
}

You can check it in your own system.

Concerning MAC addresses of sw0p1, 2 and 3, I think they are derived and indexed from a reference MAC address (that seems to be linked with the permaddr of sw0ep). But indeed, I do not know if U-Boot takes a role in this assignment for now. I will take a look at the code.

Kind regards,
Erwan.

[asadullah4571]

Hi @Erwan SZYMANSKI

Thank you for the information.

I will wait for your further response on this topic.

In the meantime, I would like to clarify one point from my understanding. If, on the kernel side, I manually read the MAC addresses from OTP and assign them to sw0p1, sw0p2, and sw0p3, will these ports be able to communicate correctly with sw0ep, considering that:

• sw0ep currently has a (permaddr) of 8e:50:73:62:fb:ff

• The MAC addresses assigned to sw0p1, sw0p2, and sw0p3 would be completely different from the sw0ep MAC address

Could you please confirm whether having different MAC addresses between sw0ep and the switch ports would impact communication, or if this configuration is expected to work correctly?

[Erwan SZYMANSKI]

Hello @asadullah4571 ,
I confirm you that in today's implementation, OTP for switch port MAC address are not taken into account at all by the software. Ethernet expert will take a look at this point.

Concerning the functional part, the network stack of Linux will simply create a random MAC address as it does not find one given. It will not impact the good behavior of the product, but it is true that OTP fuses will not be considered today.

Kind regards,
Erwan.