AM3357: PTP Synchronization Failure on AM3357-Based Custom Board

Hi pooja,

our expert is out of office please expect a delay in response.

regards,

Dilna K

Hello,

Can I get any update on this?

Hi,

The thread owner is out of office till until week of Feb 17. Please ping the thread if you do not get an update during that week.

Thank you for your patience.

Regards,
Harshith

Hello,

Can I get any update on this?

Regards,

Pooja

Hello Pooja,

Apologies for the delays here. I am finally back in office.

What version of Linux are you running on AM335x? Please note that we do not support PRU Ethernet on AM335x Linux SDK 9.1 or 9.3 (Linux kernel 6.1)

I will be able to provide PRU Ethernet support on the latest AM335x Linux SDK 11.2 (Linux kernel 6.12). You can find more documentation in the Linux SDK docs here: 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

I will still try to comment if you are using an older Linux SDK release, but Linux kernel 5.10 and earlier are now too old for us to be able to support on the forums.

Regards,

Nick

Hello Nick,

Currently, I am using SDK 6.3 (Linux Kernel 4.19) and planning to migrate to SDK 11.02 (Kernel 6.1).

In SDK 6.3, when running ethtool -T eth1, software timestamping capability is listed as supported. However, when I attempt to use software timestamping, synchronization fails and it does not work as expected.

In SDK 11.02 (tisdk-default-image-am335x-evm-11.02.05.02.rootfs.wic.xz), running ethtool -T eth1 shows that software timestamping is not supported.

For my custom board, I require software timestamping only.

I would like to understand:

1. What changes are required in SDK 11.02 (Kernel 6.1) to enable software timestamping support?

2. Why is software timestamping failing in SDK 6.3 (Kernel 4.19) even though it appears as supported in ethtool?

Regards,

Pooja 

Hello Pooja,

To clarify, SDK 11.2 uses Linux kernel 6.12, not Linux kernel 6.1. PRU Ethernet does not work on Linux kernel 6.1.

Let's talk about software timestamping vs hardware timestamping 

Why do you specifically want software timestamping instead of hardware timestamping? Hardware timestamping will ALWAYS give you more accurate results, and it is available inside the CPSW (through the CPTS module) and the PRU subsystem (through the IEP timer).

When an Ethernet packet is received at the processor pins, it is read into the Ethernet peripheral (either CPSW or PRU Ethernet). If you use hardware timestamping, the packet is timestamped immediately. No latency, no jitter. This should always give the best results when communicating with a PTP master.

After the packet is received, the CPSW peripheral or PRU cores pass the Ethernet packet up to the network stack. If you are using software timestamping, then the network stack running on the Linux ARM core is the one that timestamps the packet. Since you cannot control exactly when Linux will schedule the network stack to run on the ARM core, you cannot control exactly when the software timestamp occurs. Thus, your timestamp value will have an unknown latency from when the packet actually arrived at the processor pins. I would also expect that latency value to have more jitter from one timestamp to the next timestamp since there will be a different amount of time between when the packet is loaded into a FIFO for Linux to consume, and when Linux actually switches context to consume it.

Regards,

Nick

Hello Nick,

Software timestamping is a requirement for our product, which is why we are using it. However, it does not appear to be available in SDK 11.2 (Kernel v6.12). Could you please assist us with this?

Regards,

Pooja

Hello Pooja,

Let's ignore the hardware timestamp / software timestamp distinction for now

I think that we are running into a communication issue. All Linux cares about is that a timestamp is getting generated for PTP. Linux doesn't care about if the timestamp is the very accurate timestamp from the CPTS or the IEP counter, or the less accurate timestamp by the Linux driver. The software timestamp in Linux was designed as a backup, only to be used if the processor did not have a more accurate hardware timestamp source. I would be EXTREMELY surprised if your product specifically needed you to use less accurate timestamps.

First, What Ethernet interface are you using? 

Are you using CPSW, or PRU Ethernet?

Second, Please provide the full boot log for your failing test, and the full boot log for a passing test

Please also share:

1) Include information in the boot log like "uname -a" to confirm what version of Linux you are using for the test case

2) the oc.cfg file you are using for testing

Regards,

Nick

Hello Nick,

As I understand it, in the PRU subsystem, the IEP timer handles hardware timestamping, so no additional hardware is needed for this. Please correct me if I’m mistaken.

We have PRU-ICSS configured with PRUHSR. However, we are experiencing issues when adding PTP support.

Could you clarify whether the firmware am335x-pru0-pruhsr-fw.elf and am335x-pru1-pruhsr-fw.elf generate timestamps for packets?

Regards,

Pooja Nagda

Hello Nick,

root@am335x-evm :~ # uname -a
Linux am335x-evm 6.12.49-ti-g1a86d36433ea #1 SMP PREEMPT Fri Nov 14 06:06:38 UTC 2025 armv7l GNU/Linux

Please find the logs:

dmesg.txt

PTP_software_timestamp.txt

PTP_hardware_timestamp.txt

ptp_slave.txt

Regards,

Pooja Nagda  

Hello Pooja,

thank you for attaching logs. Please give me a few days to get in touch with the developers. Please ping the thread if I have not responded by the middle of next week.

Regards,

Nick

Thanks for the update. Does TI have a plan to fix the SDK11 packaging bug to include ti-linuxptp-v0.3-am57xx-bc?

We tried this version but it does not work on ICEv2 EVM with HSR HW offloading + PTP.

Please refer to the log in  RE: AM3359: Support for PRU Ethernet on each Linux SDK 

Hello Nick,

Please provide an update. We tried the version suggested by the development team, but it does not work on the ICEv2 EVM with HSR HW offloading + PTP.

Regards,

Pooja Nagda

Here is the feedback I received

From the logs shared by customer it looks like there are some issues with the messages we receive to ptp4l via the socket.

 This error "ptp4l[114.197]: short SO_TIMESTAMPING message" was not expected and does expose some problem with socket because we are expecting driver to use "SO_REDUNDANT" socket type while sending the message to ptp4l.

We will run some experiments by forcing or using different clock to find any issues around this. In the meantime, can we ask customer to try with 2 AM335x ICEV2 devices using unmodified 11.x SDK image one acting as master and another one as slave to rule out any issues with Grand master configuration?

For reference below are the logs from 2 AM335x ICEv2 setup:

############################### PTP Test Logs #################################

############################ DUT - AM335x ICEv2 ##############################

 

root@am335x-evm:~/scriptsTi_am335x# uname -r

6.12.49-g1a86d36433ea

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x# 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: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000

 link/sit 0.0.0.0 brd 0.0.0.0

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default q0

 link/ether 76:a9:14:d9:a3:fd brd ff:ff:ff:ff:ff:ff

 inet6 fe80::74a9:14ff:fed9:a3fd/64 scope link proto kernel_ll

 valid_lft forever preferred_lft forever

4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default q0

 link/ether 1e:21:c3:ec:21:6a brd ff:ff:ff:ff:ff:ff

 inet6 fe80::1c21:c3ff:feec:216a/64 scope link proto kernel_ll

 valid_lft forever preferred_lft forever

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x# ./hsr_setup.sh

[ 116.219839] prueth pruss-eth eth0: Link is Down

[ 116.227804] remoteproc remoteproc1: stopped remote processor 4a334000.pru

[ 116.261421] prueth pruss-eth eth1: Link is Down

[ 116.269448] remoteproc remoteproc2: stopped remote processor 4a338000.pru

[ 117.235651] hsr0: Slave A (eth0) is not up; please bring it up to get a fully working HSR k

[ 117.244638] hsr0: Slave B (eth1) is not up; please bring it up to get a fully working HSR k

[ 117.332999] remoteproc remoteproc1: powering up 4a334000.pru

[ 117.431953] remoteproc remoteproc1: Booting fw image ti-pruss/am335x-pru0-pruhsr-fw.elf, s8

[ 117.476939] remoteproc remoteproc1: unsupported resource 5

[ 117.482839] remoteproc remoteproc1: remote processor 4a334000.pru is now up

[ 117.549677] remoteproc remoteproc2: powering up 4a338000.pru

[ 117.696827] remoteproc remoteproc2: Booting fw image ti-pruss/am335x-pru1-pruhsr-fw.elf, s4

[ 117.730320] remoteproc remoteproc2: unsupported resource 5

[ 117.745563] remoteproc remoteproc2: remote processor 4a338000.pru is now up

root@am335x-evm:~/scriptsTi_am335x# [ 119.833915] prueth pruss-eth eth0: Link is Up - 100Mbpf

[ 119.899565] prueth pruss-eth eth1: Link is Up - 100Mbps/Full - flow control off

[ 125.086175] prueth pruss-eth eth0: Link is Down

[ 125.091936] prueth pruss-eth eth1: Link is Down

[ 128.206873] prueth pruss-eth eth1: Link is Up - 100Mbps/Full - flow control off

[ 128.216193] prueth pruss-eth eth0: Link is Up - 100Mbps/Full - flow control off

 

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x# 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: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000

 link/sit 0.0.0.0 brd 0.0.0.0

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default q0

 link/ether 70:ff:76:1c:35:32 brd ff:ff:ff:ff:ff:ff

 inet6 fe80::72ff:76ff:fe1c:3532/64 scope link proto kernel_ll

 valid_lft forever preferred_lft forever

4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default q0

 link/ether 70:ff:76:1c:35:32 brd ff:ff:ff:ff:ff:ff

 inet6 fe80::72ff:76ff:fe1c:3532/64 scope link proto kernel_ll

 valid_lft forever preferred_lft forever

5: hsr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen0

 link/ether 70:ff:76:1c:35:32 brd ff:ff:ff:ff:ff:ff

 inet 192.168.0.32/24 brd 192.168.0.255 scope global hsr0

 valid_lft forever preferred_lft forever

 inet6 fe80::72ff:76ff:fe1c:3532/64 scope link proto kernel_ll

 valid_lft forever preferred_lft forever

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x# ./ptp4l -v

3.0-00212-g82a7888-dirty

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x# cat oc.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 -3

logMinPdelayReqInterval -3

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 -3

logMinPdelayReqInterval -3

announceReceiptTimeout 3

syncReceiptTimeout 2

 

delay_mechanism P2P

network_transport L2

egressLatency 726

ingressLatency 186

fault_reset_interval 0

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x#

 

############ DUT acting as master #######################################

root@am335x-evm:~/scriptsTi_am335x# ./ptp4l -f oc.cfg -m

ptp4l[190.526]: selected /dev/ptp0 as PTP clock

ptp4l[190.531]: HSR master (port 1): slave1 eth0, slave2 eth1

ptp4l[190.532]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1

ptp4l[190.532]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0

ptp4l[190.532]: HSR master (port 1): slave1 eth0, slave2 eth1

ptp4l[190.532]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1

ptp4l[190.532]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0

ptp4l[190.571]: port 1 (hsr0): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[190.575]: red port 2 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[190.578]: red port 3 (eth1): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[190.581]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[193.859]: port 2: announce timeout 0

ptp4l[193.860]: red port 2 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

ptp4l[193.861]: selected best master clock 70ff76.fffe.1c3532

ptp4l[193.861]: selected local clock 70ff76.fffe.1c3532 as best master

ptp4l[193.861]: port 2: assuming the grand master role

ptp4l[194.311]: port 3: announce timeout 0

ptp4l[194.313]: red port 3 (eth1): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

ptp4l[194.314]: selected best master clock 70ff76.fffe.1c3532

ptp4l[194.314]: selected local clock 70ff76.fffe.1c3532 as best master

ptp4l[194.314]: port 2: assuming the grand master role

ptp4l[194.314]: port 3: assuming the grand master role

ptp4l[194.804]: port 2: new foreign master 70ff76.fffe.1c3533-2

ptp4l[194.994]: port 3: new foreign master 70ff76.fffe.1c3533-3

 

############ DUT acting as slave #######################################

root@am335x-evm:~/scriptsTi_am335x#

root@am335x-evm:~/scriptsTi_am335x# ./ptp4l -f oc.cfg -m -s

ptp4l[267.611]: selected /dev/ptp0 as PTP clock

ptp4l[267.615]: HSR master (port 1): slave1 eth0, slave2 eth1

ptp4l[267.616]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1

ptp4l[267.616]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0

ptp4l[267.616]: HSR master (port 1): slave1 eth0, slave2 eth1

ptp4l[267.616]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1

ptp4l[267.616]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0

ptp4l[267.672]: port 1 (hsr0): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[267.675]: red port 2 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[267.678]: red port 3 (eth1): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[267.681]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE

ptp4l[270.835]: port 2: announce timeout 0

ptp4l[270.835]: selected best master clock 70ff76.fffe.1c3532

ptp4l[270.835]: selected local clock 70ff76.fffe.1c3532 as best master

ptp4l[271.269]: port 3: announce timeout 0

ptp4l[271.270]: selected best master clock 70ff76.fffe.1c3532

ptp4l[271.270]: selected local clock 70ff76.fffe.1c3532 as best master

ptp4l[272.579]: port 3: new foreign master 70ff76.fffe.1c3533-3

ptp4l[272.988]: port 2: new foreign master 70ff76.fffe.1c3533-2

ptp4l[274.132]: port 2: announce timeout 0

ptp4l[274.134]: selected best master clock 70ff76.fffe.1c3532

ptp4l[274.134]: selected local clock 70ff76.fffe.1c3532 as best master

ptp4l[274.581]: selected best master clock 70ff76.fffe.1c3533 on port 3

ptp4l[274.583]: selected best master clock 70ff76.fffe.1c3533

ptp4l[274.583]: red port 3 (eth1): LISTENING to UNCALIBRATED on RS_SLAVE

ptp4l[274.838]: red port 3 (eth1): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED

ptp4l[274.993]: selected best master clock 70ff76.fffe.1c3533 on port 2

ptp4l[274.995]: selected best master clock 70ff76.fffe.1c3533

ptp4l[274.996]: red port 2 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE

ptp4l[274.996]: red port 3 (eth1): SLAVE to PASSIVE_SLAVE on RS_PSLAVE

ptp4l[275.117]: red port 2 (eth0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED

ptp4l[275.620]: rms 224 max 310 ( 67, 310) freq +287 +/- 164 delay 202 +/- 1

ptp4l[276.625]: rms 48 max 71 ( -71, 33) freq +137 +/- 58 delay 204 +/- 0

ptp4l[277.629]: rms 73 max 79 ( -79, -60) freq +15 +/- 16 delay 202 +/- 1

ptp4l[278.634]: rms 43 max 59 ( -59, -21) freq -4 +/- 5 delay 203 +/- 0

ptp4l[279.639]: rms 13 max 22 ( -22, 1) freq +12 +/- 7 delay 202 +/- 1

ptp4l[280.643]: rms 3 max 5 ( -4, 5) freq +25 +/- 4 delay 202 +/- 0

ptp4l[281.647]: rms 5 max 9 ( -2, 9) freq +32 +/- 5 delay 202 +/- 0

ptp4l[282.651]: rms 4 max 6 ( -3, 6) freq +32 +/- 4 delay 202 +/- 1

ptp4l[283.657]: rms 4 max 6 ( 1, 6) freq +38 +/- 2 delay 204 +/- 0

ptp4l[284.660]: rms 6 max 8 ( -5, 8) freq +41 +/- 6 delay 203 +/- 0

ptp4l[285.665]: rms 4 max 7 ( -7, 6) freq +38 +/- 6 delay 204 +/- 1

ptp4l[286.669]: rms 8 max 14 ( -1, 14) freq +47 +/- 8 delay 203 +/- 1

ptp4l[287.674]: rms 6 max 9 ( -2, 9) freq +52 +/- 5 delay 202 +/- 0

ptp4l[288.679]: rms 5 max 8 ( -6, 8) freq +46 +/- 6 delay 203 +/- 1

ptp4l[289.683]: rms 6 max 9 ( -2, 9) freq +57 +/- 5 delay 203 +/- 1

ptp4l[290.689]: rms 4 max 8 ( -5, 8) freq +55 +/- 6 delay 202 +/- 0

ptp4l[291.693]: rms 4 max 7 ( -7, 2) freq +50 +/- 4 delay 203 +/- 1

ptp4l[292.698]: rms 5 max 8 ( -5, 8) freq +52 +/- 6 delay 204 +/- 0

ptp4l[293.702]: rms 3 max 4 ( -3, 4) freq +54 +/- 3 delay 203 +/- 0

ptp4l[294.708]: rms 3 max 4 ( -2, 4) freq +57 +/- 2 delay 204 +/- 0

ptp4l[295.712]: rms 5 max 9 ( -9, 1) freq +47 +/- 5 delay 204 +/- 0

ptp4l[296.718]: rms 3 max 7 ( -7, 3) freq +47 +/- 4 delay 203 +/- 1

ptp4l[297.721]: rms 3 max 7 ( -7, 1) freq +46 +/- 4 delay 202 +/- 0

ptp4l[298.726]: rms 7 max 16 ( -16, 0) freq +37 +/- 7 delay 202 +/- 0

ptp4l[299.731]: rms 5 max 8 ( -8, 1) freq +33 +/- 3 delay 203 +/- 0

ptp4l[304.757]: rms 8 max 14 ( -14, -1) freq +20 +/- 7 delay 204 +/- 0

ptp4l[305.762]: rms 5 max 9 ( -9, 5) freq +20 +/- 5 delay 202 +/- 0

ptp4l[306.771]: rms 5 max 11 ( -3, 11) freq +29 +/- 6 delay 203 +/- 0

ptp4l[307.776]: rms 5 max 9 ( -4, 9) freq +32 +/- 5 delay 203 +/- 0

ptp4l[308.781]: rms 4 max 6 ( -6, 2) freq +26 +/- 4 delay 203 +/- 0

ptp4l[309.785]: rms 5 max 11 ( -11, 0) freq +21 +/- 5 delay 203 +/- 0

ptp4l[310.791]: rms 6 max 10 ( 0, 10) freq +32 +/- 4 delay 204 +/- 0

ptp4l[311.795]: rms 4 max 7 ( -7, 4) freq +25 +/- 6 delay 204 +/- 1

ptp4l[312.800]: rms 2 max 3 ( -3, 2) freq +23 +/- 2 delay 204 +/- 0

ptp4l[313.804]: rms 4 max 6 ( -5, 6) freq +26 +/- 6 delay 204 +/- 0

ptp4l[314.809]: rms 6 max 10 ( -10, 6) freq +24 +/- 8 delay 204 +/- 0

ptp4l[315.814]: rms 4 max 6 ( -6, 0) freq +17 +/- 3 delay 204 +/- 0

ptp4l[316.819]: rms 4 max 8 ( -8, 4) freq +20 +/- 5 delay 203 +/- 1

ptp4l[317.823]: rms 6 max 9 ( -1, 9) freq +30 +/- 5 delay 203 +/- 1

ptp4l[318.829]: rms 3 max 8 ( -8, 4) freq +26 +/- 5 delay 202 +/- 0

ptp4l[319.833]: rms 6 max 9 ( -9, 4) freq +18 +/- 6 delay 202 +/- 0

^Croot@am335x-evm:~/scriptsTi_am335x#

Hello Pratheesh,

We tried the above setup with two AM335x ICEv2 EVMs and noticed a difference in the ptp4l versions. The version you are using is v3.0-00212-g82a7888-dirty, whereas on our EVM it is v3.0-00212-g82a7888. Could this difference be the reason why PTP is not working on our end?

Please check the attached logs.

PTP_master_logs.txt

PTP_slave_logs.txt

Regards,

Pooja Nagda

Hi Pooja, 

Difference in the ptp4l version (showing "dirty" suffix) is attributed to modifications made to the Makefile for cross-compilation purposes. These local changes result in the "dirty" designation in the version string. I'm attaching the ptp4l binary for your reference.

To further troubleshoot this issue, can you perform the following steps and share us the results:

• Capture host traffic: Please capture host traffic from the HSR interface using:

  • tcpdump -i hsr0

• If feasible, please also provide a packet capture directly from the network wire (using network tap) to analyze the actual PTP message flow.
• I'm providing our compiled ptp4l version for you to test. Additionally, could you share your current ptp4l binary so we can examine it for any differences or issues?
• Interface Timestamping: Please run the following command on each network interface to verify timestamping support

  • ethtool -T hsr0

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/ptp4l

BR
JC

Hi Jayachandra,

Could you please push your local changes ("dirty" suffix) to https://git.ti.com/cgit/processor-sdk/linuxptp so that we can use Yocto to compile and verify again on our end?

BR/Chencheng

Hello Jayachandran,

As mentioned earlier by Chencheng, could you please push the local changes ("dirty" suffix) so that we can verify them at our end?

Regards,

Pooja Nagda

Hi Pooja,

ptp4l version showing as 'dirty' is because we've modified the Makefile to enable cross-compilation. This local modification causes the version to be marked as dirty.

Question: Do you need this cross-compilation change in the Makefile?

Alternative: You can still perform native compilation by cloning the repository and running make install for ptp4l directly within the DUT instead.

BR
JC

Hi Jayachandran,

We do need cross-compile since we run Yocto on x86.

Could you please provide git commit or patch on cross-compile change?

Thanks in advance!

BR/Chencheng

We use this cross compiler   Here is the MakeFile patch

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/cross_5F00_compiler_5F00_for_5F00_ptp.patch

BR
JC

ok, thanks for the patch. It seems to be non-relavate.

Just to double confirm, the version you are using which is working is of commit 82a78889f84830aaafdece92432b26203aec21d4 right?

Hi Chencheng, 

Yes, this is the correct SHA

BR
JC

Hi again,

Previously we have issues with logs here:

 RE: AM3359: Support for PRU Ethernet on each Linux SDK 

Now, I think there is an Y2038 issue regarding the linuxptp/PRUSS-FW/TI-kernel.

Hi,

Chencheng Zhang said:

However, this is not a long term solution. Since 32-bit timing will not work after Y2038. I think TI should update linuxptp/TI-kernel/PRUSS-FW to support 64-bit timings on all 32-bit SoCs such as AM335x.

PRUSS FW (PRUICSS) -> IEP Timestamp with rollover counter is provided to TI PRUSS driver => No change required

PRUSS driver (ARM) -> Convert above IEP timestamp to 64bit time_struct - 48bit secs and 32bit ns => No change required

TI-kernel -> Need to check

LinuxPTP -> Need to check

We will check the TI-kernel/LinuxPTP and comeback.

BR
JC

I got a response from my peer team. Y2038 problem is fixed in “Core” kernel since 9.x SDK 

See https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/09_03_05_02/exports/docs/linux/How_to_Guides/Target/How_to_fix_y2k38.html

Filesystem in 9.x “is not” compliant with the same (core yocto issue). So the recommendation is to use 11.x SDK which has yocto all these addressed. https://www.ti.com/tool/PROCESSOR-SDK-AM335X

Which SDK are using? Can you give a try on 11.x SDK?

BR
JC

We are using TI official meta-ti BSP layer of tag 11.02.12

https://git.yoctoproject.org/meta-ti/tag/?h=11.02.12

If you do not know how to use Yocto, you can run on your ICEv2 EVM with the TI SDK (later than 9.x) you have, and you do native compile of git.ti.com/.../linuxptp on the EVM, but just add the compile flag `-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64`, then you will see the error "short SO_TIMESTAMPING message" as well as all its cascaded error.

BR/Chencheng

We were able to reproduce the issue in HSR. This fix is applicable only to the HSR PTP path. PRP-PTP and EMAC-PTP are unaffected and do not require any changes.

Apply the following fix, rebuild the 6.12 kernel, and re-test PTP -  the issue is no longer observed with this change in place.

Note: This is not related to Y2038. It is specifically a handling gap where the 64-bit time struct was not being used in the HSR code path within the kernel.

Ensure that PTP4L is built with the following compiler flags:

-D_TIME_BITS=64
-D_FILE_OFFSET_BITS=64

net/socket.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/socket.c b/net/socket.c
index 82fa17931..9f530fe23 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1003,7 +1003,11 @@ void __sock_recv_redinfo_timestamp(struct msghdr *msg, struct sock *sk,
         empty = 0;
 
     if (!empty) {
-        struct scm_timestamping tss1;
+        /* 
+         * If ptp application is build with 64 bit TIME_BITS and FILE_OFFSET_BITS 
+         * In order to support y2k38 rollover 64 bit secs and nsecs timestamps will be required
+         */
+        struct scm_timestamping64 tss1;
         int i;
 
         for (i = 0; i < ARRAY_SIZE(tss.ts); i++) {

BR
JC

Thank you JC. I will make a build and we will verify.

Hello,

I am currently facing an issue with PTP while synchronizing the system clock (CLOCK_REALTIME).

The ptp4l process successfully locks onto the grandmaster (GM) clock. When I check the PHC time using phc_ctl /dev/ptp0 get, it returns the correct time.

However, when attempting to synchronize the system clock using:
phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m
the reported offset is extremely large.

This suggests that CLOCK_REALTIME is not being updated and remains at Thu Jan 1 00:00:24 1970, which explains the large offset of approximately 56 years.

As a troubleshooting step, I manually set the system time using the date command to bring it closer to the time reported by phc_ctl. Despite this, the offset reported by phc2sys remains significantly high.

PTP_GM_logs.txt

PHC2SYS_CLOCK_REALTIME.txt

pmc -u -b 0 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
063a33.fffe.fec2f3-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 11
ingress_time 1776859953134749050
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 502df4.fffe.3a5df2

pmc -u -b 0 "GET CLOCK_DESCRIPTION"

sending: GET CLOCK_DESCRIPTION
        063a33.fffe.fec2f3-1 seq 0 RESPONSE MANAGEMENT CLOCK_DESCRIPTION 
                clockType             0x8000
                physicalLayerProtocol IEEE 802.3
                physicalAddress       06:3a:33:fe:c2:f3
                protocolAddress       3 06:3a:33:fe:c2:f3
                manufacturerId        00:00:00
                productDescription    ;;
                revisionData          ;;
                userDescription       
                profileId             00:1b:19:00:02:00
        063a33.fffe.fec2f3-2 seq 0 RESPONSE MANAGEMENT CLOCK_DESCRIPTION 
                clockType             0x8000
                physicalLayerProtocol IEEE 802.3
                physicalAddress       00:00:00:00:00:00
                protocolAddress       3 00:00:00:00:00:00
                manufacturerId        00:00:00
                productDescription    ;;
                revisionData          ;;
                userDescription       
                profileId             00:1b:19:00:02:00
        063a33.fffe.fec2f3-3 seq 0 RESPONSE MANAGEMENT CLOCK_DESCRIPTION 
                clockType             0x8000
                physicalLayerProtocol IEEE 802.3
                physicalAddress       00:00:00:00:00:00
                protocolAddress       3 00:00:00:00:00:00
                manufacturerId        00:00:00
                productDescription    ;;
                revisionData          ;;
                userDescription       
                profileId             00:1b:19:00:02:00

Regards,

Pooja Nagda

Hi Pooja, 

We are looking into it, I will respond to you once I have updates. 

BR
JC

Hello Jayachandran,

Have there been any updates on your end?

Regards,

Pooja Nagda

Hi Pooja,

We've confirmed that TI LinuxPTP 2.0 from git.ti.com is functioning correctly.

However, we still need to identify why it's failing on the current branch. I'll provide updates as we make progress on troubleshooting the root cause.

BR
JC

The root cause of the issue is in how system time is read alongside the IEP timestamp when phc2sys makes a request using gettimex64.

Background:

• SYSOFF_BASIC and SYSOFF_EXTENDED are two different offset synchronization modes.
• SYSOFF_EXTENDED expects the system time to be captured before and after reading the IEP/PHC time, then uses the average of those two readings as the offset in phc2sys.
• In the older 6.3 SDK, neither the kernel nor PTPv2 supported SYSOFF_EXTENDED — it was always handled as SYSOFF_BASIC.

The Problem:
In the newer SDK kernel with PTPv3, multiple offset methods are supported, and corresponding API changes were introduced across different layers - exposing this gap.

diff --git a/drivers/net/ethernet/ti/icssg/icss_iep.c b/drivers/net/ethernet/ti/icssg/icss_iep.c
index a09a2797d..168d447fc 100644
--- a/drivers/net/ethernet/ti/icssg/icss_iep.c
+++ b/drivers/net/ethernet/ti/icssg/icss_iep.c
@@ -383,7 +383,13 @@ static int icss_iep_ptp_gettimeex_v1(struct ptp_clock_info *ptp,
     u64 ns;
 
     mutex_lock(&iep->ptp_clk_mutex);
+    /*populate the pre and post IEP/PHC read system timestamp into sts struct*/
+    ptp_read_system_prets(sts);
+
     ns = timecounter_read(&iep->tc);
+
+    ptp_read_system_postts(sts);
+
     *ts = ns_to_timespec64(ns);
     mutex_unlock(&iep->ptp_clk_mutex);

After patching rebuild the kernel. No change in PTP4L stack.

BR
JC

Thank you JC. I will make a build and we will verify.