AM4376: PRU code modification for switch mode

Hello Vipin,

Can you please share the error logs you are facing so that I can investigate the issue better? Also, please mention which script you are using to bring up the switch setup.


Best regards,
Rishi Kumar
ICSS India

Hello Rishi,

Currently there are two ethernet ports on board with both connected to PRUs. When packets arrive, it will go to A9 core where the switching happens. Schneider team want to run the L2 switch in PRU itself so that if a packet is intended to a PRU, it will directly go to the PRU from PRU switch and it will go the Linux port only if its intended for that. Because of the switch implemented in Linux, sometimes packets are missed, hence switching need to be offloaded to PRU.

Could you please guide Schneider team on how to configure the PRU to use the switch firmware implemented in it? Please feel free to ask if you need any information.

Thanks,

Yasir

Hello Vipin, Yashir,

To run the PRU switch in L2 offload mode, you need to copy the firmware ELF files from the ti-linux-firmware repository. Please follow these steps:

1. Clone the Repository

git clone github.com/.../ti-linux-firmware
cd ti-linux-firmware
git checkout ti-linux-firmware-next
cd ti-pruss

2. Copy the Firmware to the AM437x DUT

scp am437x-pru0-prusw-fw.elf root@<DUT_IP>:/lib/firmware/ti-pruss/
scp am437x-pru1-prusw-fw.elf root@<DUT_IP>:/lib/firmware/ti-pruss/

3. Run the Offloaded Switch Script

Create a script named switch_setup.sh on the DUT with the following content:

#!/bin/sh

ip link add name br0 type bridge
ip link set dev eth1 master br0
ip link set dev eth2 master br0
ip link set dev br0 up
bridge vlan add dev br0 vid 1 pvid untagged self

sh switch_setup.sh

Can you please try these steps and let me know if they work for you?

Best regards,

Rishi Kumar
ICSS India

Hello Rishi,

Thanks for your response.

Is it for SDK version11.02.05.02. or we can also work on SDK 8.02.

Regards

Vipin Mishra

Hello Vipin,

Please use this with SDK version 11.02.05.02, I have not tested this with SDK 8.02.

Best regards,

Rishi Kumar
ICSS India

Hello Vipin,

It is recommended to use the latest PDK firmware version. Please follow the steps below to fetch the repository and build the firmware:

1. Clone the PDK repository and switch to the legacy_master branch:

git clone git.ti.com/cgit/processor-sdk/pdk
cd pdk
git checkout legacy_master

2. Acquire the build script:
   You can find the necessary build script (build_icss_firmware.sh) in the attached link:

3. Compile the switch firmware:
   Update your local toolchain path within the script, then execute it with the following command to compile the firmware for the AM4376 PRU switch

sh build_icss_firmware_emac.sh -o ti-pruss -f switch

4. Copy the switch firmware to the DUT:

cd ti-pruss
scp am437x-pru0-prusw-fw.elf root@<DUT_IP>:/lib/firmware/ti-pruss/
scp am437x-pru1-prusw-fw.elf root@<DUT_IP>:/lib/firmware/ti-pruss/

Best regards,

Rishi Kumar
ICSS India

/cfs-file/__key/communityserver-discussions-components-files/791/7484.build_5F00_icss_5F00_firmware.sh

Hello Rishi,

We are still working on previous version of PRU. While testing today we observe the device is getting restart when we start packet bombardment on ethernet port.

Also while configuring previous PRU we have below observation

root@am437x-evm:/home# cat Bridge_Config.sh

#ethtool -K eth0 l2-fwd-offload off

#ethtool -K eth1 l2-fwd-offload off

ip link set dev eth0 down

ip link set dev eth1 down

ip link add name br0 type bridge

ip link set dev eth0 master br0

ip link set dev eth1 master br0

ip link set dev br0 up

bridge vlan add dev br0 vid 1 pvid untagged self

ip link set dev eth0 up

ip link set dev eth1 up

ip link set dev br0 address $(cat /sys/class/net/eth0/address)

ip addr flush dev br0

ip addr flush dev br

root@am437x-evm:/home#

root@am437x-evm:/home# ./Bridge_Config.sh

[  340.468892] prueth pruss1-eth eth0: Link is Down

[  340.479808] remoteproc remoteproc1: stopped remote processor 54434000.pru

[  340.542805] remoteproc remoteproc2: stopped remote processor 54438000.pru

[  340.640047] br0: port 1(eth0) entered blocking state

[  340.645209] br0: port 1(eth0) entered disabled state

[  340.650283] prueth pruss1-eth eth0: entered allmulticast mode

[  340.656648] prueth pruss1-eth eth0: entered promiscuous mode

[  340.756896] br0: port 2(eth1) entered blocking state

[  340.761993] br0: port 2(eth1) entered disabled state

[  340.767142] prueth pruss1-eth eth1: entered allmulticast mode

[  340.773464] prueth pruss1-eth: TI PRU ethernet now in Switch mode

[  340.779701] prueth pruss1-eth eth1: entered promiscuous mode

RTNETLINK answers: Operation not supported

[  340.957905] remoteproc remoteproc1: powering up 54434000.pru

[  340.979435] remoteproc remoteproc1: Booting fw image ti-pruss/am437x-pru0-prusw-fw.elf, size 8664

[  340.988527] remoteproc remoteproc1: unsupported resource 5

[  340.994339] remoteproc remoteproc1: remote processor 54434000.pru is now up

[  341.055195] remoteproc remoteproc2: powering up 54438000.pru

[  341.081480] remoteproc remoteproc2: Booting fw image ti-pruss/am437x-pru1-prusw-fw.elf, size 8472

[  341.090576] remoteproc remoteproc2: unsupported resource 5

[  341.096434] remoteproc remoteproc2: remote processor 54438000.pru is now up

[  341.148084] 8021q: adding VLAN 0 to HW filter on device eth0

[  341.212716] 8021q: adding VLAN 0 to HW filter on device eth1

Device "br" does not exist.

Kindly suggest correcting this issue

Regards

Vipin 

Hello Vipin,

Could you please share a bit more information about your setup to help us isolate this issue?

• Kernel Type: Are you using the RT (Real-Time) or non-RT Linux kernel?
• Kernel Version: Please provide the output of the uname -a command.
• Traffic parameters: What kind of frame formats are you using for the packet bombardment? Are you transmitting at 100% port load, and what is the total duration of the test?

Observations on your script:
I noticed your script uses the command ip addr flush dev br. This is missing the 0 at the end and should be ip addr flush dev br0. The typo is likely causing the error message: Device "br" does not exist.

Can you please correct the interface name in your script, and verify if the crash still occurs when using our latest PDK switch firmware on an RT kernel.

Best regards,
Rishi Kumar

Hello Rishi,

Please find below detail

non-rt 

root@am437x-evm:~# uname -a

Linux am437x-evm 6.12.49 #1 Mon Oct 12 11:40:34 IST 2026 armv7l GNU/Linux

root@am437x-evm:~#

Packet Traffic- 

It is approximate 10000 to 50000 packet per second.

The packet types used to inject traffic in Faulty Mode generally fall into the following technical categories:

1. Malformed PROFINET (PNIO) Protocol Frames

These frames test the robustness of the device's specialized industrial Ethernet stack. They look like standard PNIO frames but have deliberately induced syntax or structure violations:

• Invalid EtherType Variations: Frames carrying the PROFINET EtherType (0x8892) but filled with illegal or corrupted sub-identifiers.
• Incorrect FrameID Ranges: Injection of frames containing FrameIDs reserved for other synchronization classes (e.g., mixing up RTC1 and RTC3 boundaries or using out-of-bounds acyclic IDs).
• Truncated or Oversized Payloads: Packets that explicitly violate the expected data lengths specified by the PNIO state machines.
• Corrupted Status Fields: PNIO frames with deliberately corrupted DataStatus or TransferStatus bytes to see if the stack discards them properly without crashing.

2. Standard Network Layer (L2/L3/L4) Faulty Packets

These target the standard IT/IP software stack running in parallel to the real-time processing layer:

• Ethernet Layer (L2) Violations: Frames containing invalid Frame Check Sequences (FCS/CRC errors), oversized/runt frames, or illegal VLAN tagging topologies.
• IP Layer (L3) Malformations: Packets containing invalid IPv4/IPv6 headers, incorrect checksums, or bad Time-to-Live (TTL) settings.
• Layer 4 Protocol Corruptions: Heavily malformed TCP or UDP packets directed towards typical PNIO service ports (such as the RPC port 34964 used by PNIO-CM).

3. Flooding/Storm Packets (Background Netload)

Faulty mode overlays structural errors on top of raw high-bandwidth stress. The network load component forces the device to filter high volumes of data concurrently:

• ARP Storms: Massive bursts of Address Resolution Protocol (0x0806) broadcast lookups.
• SNMP / LLDP Noise: High volumes of management layer packets (0x88CC for LLDP) designed to overwhelm the CPU's background discovery parsing.
• Unicast & Multicast Flood Traffic: High ratios of cross-talk background traffic targeted at the device to verify that its internal rate limiters or hardware filters preserve the primary Application Relation (AR).

Regards

Vipin Mishra

@Gaurav.more@se.com

@Mahesh.sutar@se.com

Hello Rishi, 

@Mahesh.Sutar@se.com

One query regarding the pru firmware loading. There is one observation while kernel booting. Every time when it boots it firs runs or loads prueth elf files for both eth0 and eth1 and when we use the switch.sh script suggested byt you after performing below steps

scp am437x-pru0-prusw-fw.elf root@<DUT_IP>:/lib/firmware/ti-pruss/
scp am437x-pru1-prusw-fw.elf root@<DUT_IP>:/lib/firmware/ti-pruss/ 

it loads am437x-pru0-prusw-fw.elf am437x-pru1-prusw-fw.elf files. Is it a expected behavior? or it should load the same at the beginning? pleas confirm
. If it should only initiate after bridge then why after loading the scp am437x-prux-prusw-fw.elf it is affecting the DPWS ethernet service?

Let me know if required further clarifications.

Thanks,
Gaurav More

Hello Rishi,

Thanks for the clarification. 

DPWS is the service with runs on HTTP port. Here the device is detected in the laptop or PC provided both are in the same network. When I am not using the shared Script and uses the PRUETH base elf then it works properly and device is detected in the network. As soon as the I enable the switch .sh script and check then it stops working.

Basically, I am only disabling the offload part in the existing application and running the application again to use the am437x-pru0-prusw-fw.elf and am437x-pru1-prusw-fw.elf files.  Also, I am loading it one time only. 

Thanks

Gaurav More

Hello Gaurav,

Based on your description, the application likely requires an IP address to be assigned on the bridge interface (br0) to function correctly. I verified this by assigning an IP to br0 using: ifconfig br0 Ping tests on the br0 interface. I also tried ping using the CPSW port after DHCP ip assignment and both the test is working as expected.

Could you please try assigning an IP to br0 and re-run your application to confirm if this resolves the issue?

Also, it would help to understand your network topology: specifically, how this application is expected to interact with other devices on the network. A diagram would be helpful.

Could you also share your ifconfig output so we can better understand the issue?

Best regards,
Rishi Kumar
ICSS India

Hello Rishi,

Thanks for the response. I was busy with other deliverables so was not able to respond.

With respect to the above information, we had a discussion with the TI team and decided to use the prueth firmware file instead is prusw . With prueth firmware it is working properly. Regarding the prusw firmware it is required for profinet. and TI team has mentioned that it needs the pru firmware modification,

Currently working with the prueth elf file for eth0 and eth1 and exploring the same. If found any observation impacting our device functionality with revert.

BR,

Gaurav More