AM3359: Support for PRU Ethernet on each Linux SDK

Hello Chencheng,

Good question. Let me clarify:

In Linux SDK 6.3

We had support on AM335x & AM437x for "generic Ethernet" dual EMAC or single EMAC at 100M FD.

We also had support for some Industrial Networking protocols where the stack ran on Linux, and then the PRU subsystem offloaded processing from the Linux OS. This allowed for much better HSR & PRP performance using PRU Ethernet + Linux than using CPSW Ethernet + Linux. For more information about the protocols which were supported in that release, see 
https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/Industrial_Protocols.html

SDK 6.3 was also the last TI-RTOS release on AM335x & AM437x. There were additional Industrial Networking protocols that only ran on TI-RTOS. TI has no plans to release another version of TI-RTOS in the future. 
https://www.ti.com/tool/PRU-ICSS-INDUSTRIAL-SW 

In Linux SDK 7.3 

We dropped support for AM335x & AM437x Linux + Industrial Networking protocols on PRU subsystem. We supported AM335x & AM437x "generic Ethernet" dual EMAC or single EMAC at 100M FD

In Linux SDK 8.2 

We supported AM335x & AM437x "generic Ethernet" dual EMAC or single EMAC at 100M FD

In Linux SDK 9.1 & SDK 9.3 

We did not support ANY kind of PRU Ethernet on AM335x & AM437x

In Linux SDK 11.2 

We re-added support for PRU Ethernet on AM335x & AM437x, and some industrial networking protocols on Linux. We upstreamed the generic PRU Ethernet driver, so I expect that PRU Ethernet should continue to be supported in future versions of the Linux kernel.

Details:

PRU Ethernet - dual EMAC & single EMAC (NEW features)
https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU-ICSS_Ethernet.html

* dual EMAC & single EMAC
* 10M FD/HD, 100M FD/HD
* PTP supported

PRU Ethernet - switch (NEW!)
https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU-ICSS_Ethernet.html#two-port-ethernet-switch

Linux HSR w/ offload to PRU cores (first time supported since SDK 6.3)
https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/HSR_Offload.html

Linux PRP w/ offload to PRU cores (first time supported since SDK 6.3)
https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/PRP_Offload.html 

Regards,

Nick

For future readers, this e2e thread was split off from thread
AM3359: SD Card built Processor SDK Linux v11.02 (RT-Linux) not booting 

Hi Nick,

Thanks again for your reply.

Here is the essential yes/no question:

If we run PRUHSR/PRUPRP (HW offload) instead of PRUETH (the new one you mentioned in SDK 11) with TI Linux RT v6.12 (Scarthgap 11.02.x), is PTP (either HW timestamping or SW) still supported?

BR/Chencheng

Hello Chencheng,

RT Linux + AM335x?

First, please note that we do not release an RT Linux version of the AM335x Linux SDK 11.2, since RT Linux support for 32-bit processors was not upstreamed into Linux kernel 6.12 at the time that we were developing that software release.

RT Linux support for 64-bit processors was merged mainline for Linux kernel 6.12.

For every Linux kernel before kernel 6.12, RT Linux support was maintained in a separate repository as a set of patches that needed to be applied on top of the upstream kernel. So TI applied those RT patches to our ti-linux-kernel branch, optimized performance, etc and used that code for the RT Linux SDK.

The RT Linux project is still going, and there are 32-bit RT patches that you could apply on top of ti-linux-kernel. I can even point you to a non-tested ti-linux-kernel branch where another TI team applied those patches during summer 2025. Just keep in mind that I cannot guarantee performance since we have not validated and optimized on our end, so you would want to be rigorous in your own testing and validation.

If you are interested in discussing more about RT Linux on AM335x, please create a new e2e thread and we can continue the discussion there.

Can you do HSR + PTP or PRP + PTP? 

Good question, I have not tried this myself. Give me a day or so to look into this. Please ping the thread if I have not replied by Thursday or Friday.

Regards,

Nick

Hi Nick,

Thank you for your time to take a further look.

To be more precise, I want to test this exact version on AM335x: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-rt-linux-6.12.y-arm32&id=1379a8eb9786e78509f67ff8eac658bde5ddc66d

As per ICSS, I think the Linux kernel driver is exactly the same between TI Linux and TI RT Linux, since I have compare the driver source code `git diff --stat ti-linux-6.12.y ti-rt-linux-6.12.y-arm32 -- drivers/net/ethernet/ti/icssm` and it tells nothing is changed between `ti-linux-6.12.y` branch and `ti-rt-linux-6.12.y-arm32` branch.

If it is not officially tested or validated, could you give the exact repo branch and revision which is officially tested?

Could you also help to make observations on the following scenarios?

1. HSR with HW offloading + PTP (SW timestamping)

2. HSR with HW offloading + PTP (HW timestamping)

3. HSR without HW offloading + PTP (SW timestamping)

4. HSR without HW offloading + PTP (HW timestamping)

5. PRP with HW offloading + PTP (SW timestamping)

6. PRP with HW offloading + PTP (HW timestamping)

7. PRP without HW offloading + PTP (SW timestamping)

8. PRP without HW offloading + PTP (HW timestamping)

And could you also please clarify the ICSS-PRU firmware update:

https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware-6.12.y&id=a3b3ee294b0a0a7a605982accb250cb1ca8fdb96

ti-pruss: Update AM3/4 PRU HSR and PRP firmwares
Update AM3/4 PRU HSR/PRP firmwares to version 3.00.00.

This firmware fixes below issues:
- HSR: Performance & Setup: Performance test with 4-IDK setup, IO modules
sync failure with PTP, PTP packets transfer, MAC filter for RAW interfaces
- Data Integrity: Corruption of memory, Ping working with corrupted HSR tag,
Incorrect LAN information in tagged frames with pru
- PRP: Protocol Handling: Destination MAC check for unicast packets,
Host duplicate detection with PTP packets, Ping not working from
SAN without RED-box
- System Issues: emac_rx_packet crash, Paging issue during network storm,
- Unique rxc count increment, Remove backward compatibility for storm prevention
Common Issues (Affecting Both HSR/PRP):
- Memory & Counter Issues: txMcast Counter increment for supervision/PTP frames
- Memory map resource conflicts, Underflow handling,
- rxMisAlignment errors, Firmware locks during cable pull
Enhancement: TX optimization, Enhanced MAC filter

ef084d57f342dc531427e1c3e00a770f  ti-pruss/am335x-pru0-pruhsr-fw.elf
ec21b5760cdbb6eb0fa0a0c32f658139  ti-pruss/am335x-pru0-pruprp-fw.elf
2d1545880d8e58a743dd93a888439c58  ti-pruss/am335x-pru1-pruhsr-fw.elf
431bc278311b49d519b2a7832a411f78  ti-pruss/am335x-pru1-pruprp-fw.elf
ef084d57f342dc531427e1c3e00a770f  ti-pruss/am437x-pru0-pruhsr-fw.elf
ec21b5760cdbb6eb0fa0a0c32f658139  ti-pruss/am437x-pru0-pruprp-fw.elf
2d1545880d8e58a743dd93a888439c58  ti-pruss/am437x-pru1-pruhsr-fw.elf
431bc278311b49d519b2a7832a411f78  ti-pruss/am437x-pru1-pruprp-fw.elf

Based on tag: REL.PRU-ICSS-HSR-FW_03.00.00

Signed-off-by: Jayachandran Rameshbabu <j-rameshbabu@ti.com>

What does this linux-firmware changes mean for us users?

Thanks in advance!

BR/Chencheng

Hello Chengheng,

Hardware vs software timestamping 

Please see the discussion I had with another member of your team over here. Please start with my response on February 20, and also read the responses that came after it:
RE: AM3357: PTP Synchronization Failure on AM3357-Based Custom Board

 If you would like to have additional discussions around this topic, please create a new e2e thread and ask for me so that we can keep this thread focused on your original question. 

What about ti-rt-linux-6.12.y-arm32? 

That is the branch I was talking about when I said "non-tested ti-linux-kernel branch where another TI team applied those patches during summer 2025". The development team has not fully validated this code on AM335x. You are welcome to use this branch as a starting point for your own development, but 1) I am not sure if the RT patches have been updated since summer 2025, and if so I do not know if the other team re-applied the RT patches, and 2) If something goes wrong with the RT patches, the TI apps team will be unable to support questions to debug and fix (i.e., this branch is "not supported").

Refer to this thread for some more background:  RE: AM4378: Support Status of AM4378 SoC  

Ok, what about HSR + PTP or PRP + PTP on AM335x/AM437x? 

This is a pretty complicated topic, and I am still digging into it. Some of this information may be incorrect - if so, I will try to correct it later. But here is my understanding as of March 4, 2026:

linuxptp is NOT a TI-specific driver, but Linux community code. So if the Linux maintainer for linuxptp decides to drop support for HSR and PRP from the tool, that is not something that TI controls.

Back in Linux SDK 6.3, HSR & PRP with PRU offload DID work with PTP, at least for certain versions of linuxptp, on AM57x. The documentation seems to indicate that this was also supported on AM335x & AM437x, but it is technically possible that the developer wrote the page for AM57x and forgot to say that AM335x and AM437x did not support some or all of the features. Note that there were some limitations, documented in the SDK docs. So far I do not know exactly which versions of linuxptp code was used with Linux SDK 6.3 / Linux kernel 4.19
https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/Industrial_Protocols_PTP.html

My understanding is that over time, the Linux maintainer for the linuxptp tools dropped support for HSR & PRP, and we are now submitting code patches to get HSR & PRP support added back to linuxptp. If we are able to get that merged in, then we will be able to re-add support for HSR & PRP + PTP on the latest version of linuxptp tools, for both AM335x & Am437x with PRU-ICSS firmware, and also AM64x with PRU_ICSSG firmware.

I do see notes from a software debug in Sept 2025 where HSR + PTP was being debugged on AM335x. It seems like the issue was fixed, and that fix is the issue you find in the commit log titled "HSR: Performance & Setup". So it DOES look like someone has successfully done AM335x HSR w/ PRU offload + PTP on AM335x SDK 11.2. The missing information is what version of linuxptp they used with Linux kernel 6.12 - based on the information I have so far, I expect that they were NOT using the latest v4.4 of linuxptp. They may have required additional patches to linuxptp on top of what is currently available on the linuxptp downloads.

Regards,

Nick

Hi Nick,

Thanks for your effort.

Let's forget about TI Linux (ti-linux-6.12.y) vs TI RT Linux (ti-rt-linux-6.12.y-arm32). For me they have the same source code for ICSS kernel modules. And it is also easy for me to switch our code base between them.

I appreciate your response in RE: AM3357: PTP Synchronization Failure on AM3357-Based Custom Board

And I agree with you the PTP HW timestamping is a much better solution. We should aim to make both HSR/PRP HW offloading working with PTP HW timestamping.

Unfortunately, it does not work of me in my observation. And it does not work for Pooja in RE: AM3357: PTP Synchronization Failure on AM3357-Based Custom Board.

We work together but we have different geo-locations. And I don't have AM3359 ICEv2 EVM yet and I am in the process of acquiring one.

Let me give you some more input from my observation:

linuxptp IS a TI-specific driver when you use SDK 6:

https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware-6.12.y&id=a3b3ee294b0a0a7a605982accb250cb1ca8fdb96

Which means SDK 11 is using REL.PRU-ICSS-HSR-FW_03.00.00

However, I cannot find any setup which works for HSR/PRP HW offloading + PTP.

BR/Chencheng

Hello Chencheng,

Thank you for the additional context.

I am still getting in touch with the developers who added the Linux HSR/PRP drivers for AM335x on Linux kernel 6.12 to determine

1) exactly what they tested (e.g., that ti-linux-firmware comment is unclear on which OS and which version of OS was used to validate)

2) if they DID test PTP over HSR, what version of tools, whether additional patches were required, etc

3) whether this would be considered something "production-ready", or if it might require additional development and debug on your side in order to use

Please ping the thread if I have not responded by the middle of next week.

Regards,

Nick

Hi Nick,
I followed Pratheesh's feedback RE: AM3357: PTP Synchronization Failure on AM3357-Based Custom Board 

And integrated ti-linuxptp-v0.3-am57xx-bc to our platform.

The ptp.cfg:

[global]
sanity_freq_limit 0
step_threshold 0.00002
tx_timestamp_timeout 20

domainNumber 0
priority1    128
priority2    128
slaveOnly    0

twoStepFlag                  1
summary_interval             0
doubly_attached_clock        1

[hsr0]
redundancy                   1
delay_mechanism              P2P
network_transport            L2

[eth0]
redundancy                   1
redundancy_master_interface  hsr0
redundancy_slave_number      1

logAnnounceInterval          0
logSyncInterval              0
logMinPdelayReqInterval      0
announceReceiptTimeout       3
syncReceiptTimeout           2

delay_mechanism              P2P
network_transport            L2
egressLatency                726
ingressLatency               186
fault_reset_interval         0

[eth1]
redundancy                   1
redundancy_master_interface  hsr0
redundancy_slave_number      2

logAnnounceInterval          0
logSyncInterval              0
logMinPdelayReqInterval      0
announceReceiptTimeout       3
syncReceiptTimeout           2

delay_mechanism              P2P
network_transport            L2
egressLatency                726
ingressLatency               186
fault_reset_interval         0

However, when we run our HSR setup with a Redbox + PTP grand master clock:

root@pm540:~# ptp4l -f /etc/iec61850-ptp-hsr.cfg -m
ptp4l[104.311]: selected /dev/ptp0 as PTP clock
ptp4l[104.314]: HSR master (port 1): slave1 eth0, slave2 eth1
ptp4l[104.314]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1
ptp4l[104.315]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0
ptp4l[104.315]: HSR master (port 1): slave1 eth0, slave2 eth1
ptp4l[104.315]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1
ptp4l[104.316]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0
ptp4l[104.319]: port 1 (hsr0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[104.320]: red port 2 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[104.322]: red port 3 (eth1): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[104.323]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105.195]: short SO_TIMESTAMPING message
ptp4l[105.195]: port 1: recv message failed
ptp4l[105.195]: hsr0: No red dispatch port
ptp4l[105.195]: short SO_TIMESTAMPING message
ptp4l[105.195]: port 1: recv message failed
ptp4l[105.195]: hsr0: No red dispatch port
ptp4l[106.195]: short SO_TIMESTAMPING message
ptp4l[106.195]: port 1: recv message failed
ptp4l[106.195]: hsr0: No red dispatch port
ptp4l[106.195]: short SO_TIMESTAMPING message
ptp4l[106.195]: port 1: recv message failed
ptp4l[106.196]: hsr0: No red dispatch port
ptp4l[106.197]: port 3: new foreign master 502df4.fffe.3a5df2-1
ptp4l[106.198]: port 2: new foreign master 502df4.fffe.3a5df2-1
ptp4l[107.195]: short SO_TIMESTAMPING message
ptp4l[107.195]: port 1: recv message failed
ptp4l[107.195]: hsr0: No red dispatch port
ptp4l[107.195]: short SO_TIMESTAMPING message
ptp4l[107.195]: port 1: recv message failed
ptp4l[107.197]: hsr0: No red dispatch port
ptp4l[107.613]: port 3: announce timeout 0
ptp4l[107.614]: red port 3 (eth1): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[107.614]: selected best master clock 7e3646.fffe.5a2b4e
ptp4l[107.614]: selected local clock 7e3646.fffe.5a2b4e as best master
ptp4l[107.614]: port 3: assuming the grand master role
ptp4l[108.195]: short SO_TIMESTAMPING message
ptp4l[108.196]: port 1: recv message failed
ptp4l[108.196]: hsr0: No red dispatch port
ptp4l[108.196]: short SO_TIMESTAMPING message
ptp4l[108.196]: port 1: recv message failed
ptp4l[108.196]: hsr0: No red dispatch port
ptp4l[108.200]: port 2: announce timeout 0
ptp4l[108.200]: red port 2 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[108.201]: selected best master clock 7e3646.fffe.5a2b4e
ptp4l[108.201]: selected local clock 7e3646.fffe.5a2b4e as best master
ptp4l[108.201]: port 2: assuming the grand master role
ptp4l[108.201]: port 3: assuming the grand master role
ptp4l[109.195]: short SO_TIMESTAMPING message
ptp4l[109.195]: port 1: recv message failed
ptp4l[109.196]: hsr0: No red dispatch port
ptp4l[109.196]: short SO_TIMESTAMPING message
ptp4l[109.196]: port 1: recv message failed
ptp4l[109.197]: hsr0: No red dispatch port
ptp4l[110.195]: short SO_TIMESTAMPING message
ptp4l[110.196]: port 1: recv message failed
ptp4l[110.196]: hsr0: No red dispatch port
ptp4l[110.196]: short SO_TIMESTAMPING message
ptp4l[110.196]: port 1: recv message failed
ptp4l[110.197]: hsr0: No red dispatch port
ptp4l[111.196]: short SO_TIMESTAMPING message
ptp4l[111.196]: port 1: recv message failed
ptp4l[111.196]: hsr0: No red dispatch port
ptp4l[111.196]: short SO_TIMESTAMPING message
ptp4l[111.196]: port 1: recv message failed
ptp4l[111.198]: hsr0: No red dispatch port
ptp4l[112.196]: short SO_TIMESTAMPING message
ptp4l[112.196]: port 1: recv message failed
ptp4l[112.196]: hsr0: No red dispatch port
ptp4l[112.196]: short SO_TIMESTAMPING message
ptp4l[112.196]: port 1: recv message failed
ptp4l[112.196]: hsr0: No red dispatch port
ptp4l[113.196]: short SO_TIMESTAMPING message
ptp4l[113.196]: port 1: recv message failed
ptp4l[113.196]: hsr0: No red dispatch port
ptp4l[113.196]: short SO_TIMESTAMPING message
ptp4l[113.196]: port 1: recv message failed
ptp4l[113.196]: hsr0: No red dispatch port
ptp4l[114.196]: short SO_TIMESTAMPING message
ptp4l[114.197]: port 1: recv message failed
ptp4l[114.197]: hsr0: No red dispatch port
ptp4l[114.197]: short SO_TIMESTAMPING message
ptp4l[114.197]: port 1: recv message failed
ptp4l[114.197]: hsr0: No red dispatch port
ptp4l[114.198]: selected best master clock 502df4.fffe.3a5df2 on port 3
ptp4l[114.199]: selected best master clock 502df4.fffe.3a5df2
ptp4l[114.199]: red port 2 (eth0): MASTER to PASSIVE_SLAVE on RS_PSLAVE
ptp4l[114.199]: updating UTC offset to 37
ptp4l[114.200]: red port 3 (eth1): MASTER to UNCALIBRATED on RS_SLAVE
ptp4l[114.200]: selected best master clock 502df4.fffe.3a5df2 on port 2
ptp4l[114.201]: selected best master clock 502df4.fffe.3a5df2
ptp4l[114.201]: updating UTC offset to 37
ptp4l[114.201]: red port 2 (eth0): PASSIVE_SLAVE to UNCALIBRATED on RS_SLAVE
ptp4l[114.202]: red port 3 (eth1): UNCALIBRATED to PASSIVE_SLAVE on RS_PSLAVE
ptp4l[115.196]: short SO_TIMESTAMPING message
ptp4l[115.197]: port 1: recv message failed
ptp4l[115.197]: hsr0: No red dispatch port
ptp4l[115.198]: short SO_TIMESTAMPING message
ptp4l[115.198]: port 1: recv message failed
ptp4l[115.199]: hsr0: No red dispatch port
ptp4l[116.196]: short SO_TIMESTAMPING message
ptp4l[116.197]: port 1: recv message failed
ptp4l[116.198]: hsr0: No red dispatch port
ptp4l[116.198]: short SO_TIMESTAMPING message
ptp4l[116.199]: port 1: recv message failed
ptp4l[116.199]: hsr0: No red dispatch port
ptp4l[116.202]: port 2: rx sync timeout 1
ptp4l[116.202]: selected best master clock 502df4.fffe.3a5df2 on port 3
ptp4l[116.202]: selected best master clock 502df4.fffe.3a5df2
ptp4l[116.202]: red port 2 (eth0): UNCALIBRATED to PASSIVE_SLAVE on RS_PSLAVE
ptp4l[116.202]: updating UTC offset to 37
ptp4l[116.202]: red port 3 (eth1): PASSIVE_SLAVE to UNCALIBRATED on RS_SLAVE
ptp4l[117.196]: short SO_TIMESTAMPING message
ptp4l[117.198]: port 1: recv message failed
ptp4l[117.198]: hsr0: No red dispatch port
ptp4l[117.199]: short SO_TIMESTAMPING message
ptp4l[117.199]: port 1: recv message failed
ptp4l[117.199]: hsr0: No red dispatch port
ptp4l[118.197]: short SO_TIMESTAMPING message
ptp4l[118.198]: port 1: recv message failed
ptp4l[118.198]: hsr0: No red dispatch port
ptp4l[118.199]: short SO_TIMESTAMPING message
ptp4l[118.199]: port 1: recv message failed
ptp4l[118.199]: hsr0: No red dispatch port
ptp4l[118.203]: port 3: rx sync timeout 1

The PTP never gets synced.

Pooja had also run the same setup on ICEv2 EVM with SDK 11 + ti-linuxptp-v0.3-am57xx-bc. And we got exactly the same behaviour.

Could you consult the developers again with these new findings?

Thanks & BR,

Chencheng

Hello Chencheng,

Apologies for the delayed responses here. I am going to pass this thread over to the same people who are handling the other thread
AM3357: PTP Synchronization Failure on AM3357-Based Custom Board - Processors forum - Processors - TI E2E support forums

Regards,

Nick