PROCESSOR-SDK-AM64X: AM64x PTP related question

Hello Matt, 

1. What Linux SDK version are you using?

2. Are both your grandmaster and follower device a TI AM64x EVM?

3. What are the contents of your gPTP.cfg file?

Matt Tsai52 said:

Does the rms offset between grandmaster and slave look reasonable? If not, how can we fix it?

From tests I've ran in the past the rms offset should typically be in the double-digit ns level. So, we need to figure out what are the differences between your test setup and mine.

-Daolin

Hi Daolin,

For #1, #2:

Yes, both the PTP grandmaster and slave are running on TI AM64x EVM, with the default SDK on SD card.

root@am64xx-evm:~/# uname -a
Linux am64xx-evm 6.6.58-ti-01497-ga7758da17c28-dirty #1 SMP PREEMPT Wed Nov 27 13:23:15 UTC 2024 aarch64 GNU/Linux

For #3: The gPTP.cfg was taken from https://github.com/richardcochran/linuxptp/blob/master/configs/gPTP.cfg (as suggested by some TI instruction):

root@am64xx-evm:~/# cat gPTP.cfg
#
# 802.1AS example configuration containing those attributes which
# differ from the defaults.  See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable               1
priority1               248
priority2               248
logAnnounceInterval     0
logSyncInterval         -3
syncReceiptTimeout      3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step         1
path_trace_enabled      1
follow_up_info          1
transportSpecific       0x1
ptp_dst_mac             01:80:C2:00:00:0E
network_transport       L2
delay_mechanism         P2P

# Add these lines for the TI PHY:
ingressLatency 88
egressLatency  288

Hi Matt, 

Matt Tsai52 said:

root@am64xx-evm:~/# uname -a
Linux am64xx-evm 6.6.58-ti-01497-ga7758da17c28-dirty #1 SMP PREEMPT Wed Nov 27 13:23:15 UTC 2024 aarch64 GNU/Linux

Any particular reason for using non-RT Linux vs RT Linux? (I noticed you're not using PREEMPT_RT)

Matt Tsai52 said:

priority1               248

Can you try configuring "priority1" in your gPTP.cfg to be "100" for the grandmaster and "240" for the follower?

-Daolin

Hi Daolin,

I used non-RT Linux because that is on the TI AM64x EVM SD card and the instructions I found online do not seem to mention to use RT Linux for TSN features.

Here is the output on the slave side after changing the gPTP.cfg as you suggested:

ptp4l[378.503]: selected /dev/ptp0 as PTP clock
ptp4l[378.554]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[378.554]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[378.554]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[381.879]: port 1 (eth0): new foreign master 70ff76.fffe.1fe2de-1
ptp4l[381.907]: selected local clock 641c10.fffe.24678f as best master
ptp4l[383.879]: selected best master clock 70ff76.fffe.1fe2de
ptp4l[383.879]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[384.846]: port 1 (eth0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[385.473]: rms 38884 max 77824 freq  +4611 +/- 2133 delay    33 +/-   0
ptp4l[386.473]: rms 1090 max 1413 freq  +7261 +/- 796 delay    33 +/-   0
ptp4l[387.474]: rms 1099 max 1424 freq  +8580 +/- 132 delay    33 +/-   0
ptp4l[388.474]: rms  512 max  641 freq  +8553 +/- 164 delay    33 +/-   0
ptp4l[389.475]: rms  291 max  445 freq  +7674 +/- 272 delay    33 +/-   0
ptp4l[390.475]: rms  239 max  371 freq  +7523 +/- 244 delay    33 +/-   0
ptp4l[391.476]: rms  263 max  384 freq  +7934 +/- 319 delay    33 +/-   0
ptp4l[392.476]: rms  357 max  463 freq  +8484 +/- 190 delay    33 +/-   0
ptp4l[393.477]: rms  256 max  416 freq  +8657 +/- 119 delay    33 +/-   0
ptp4l[394.478]: rms  230 max  474 freq  +8724 +/- 251 delay    33 +/-   0
ptp4l[395.478]: rms  481 max  619 freq  +9525 +/- 100 delay    33 +/-   0
ptp4l[396.479]: rms  116 max  228 freq  +9204 +/- 140 delay    33 +/-   0
ptp4l[397.479]: rms  145 max  263 freq  +9365 +/- 132 delay    33 +/-   0
ptp4l[398.480]: rms  205 max  332 freq  +9215 +/- 289 delay    33 +/-   0
ptp4l[399.481]: rms  173 max  295 freq  +9264 +/- 242 delay    33 +/-   0
ptp4l[400.481]: rms  223 max  277 freq  +9673 +/- 100 delay    33 +/-   0
ptp4l[401.482]: rms  372 max  479 freq +10142 +/- 239 delay    33 +/-   0
ptp4l[402.482]: rms  195 max  393 freq +10199 +/- 112 delay    34 +/-   0
ptp4l[403.483]: rms  377 max  488 freq  +9382 +/- 253 delay    34 +/-   0
ptp4l[404.483]: rms  348 max  454 freq  +9008 +/-  89 delay    34 +/-   0
ptp4l[405.484]: rms  327 max  386 freq  +8710 +/- 138 delay    34 +/-   0
ptp4l[406.484]: rms  245 max  384 freq  +9111 +/- 337 delay    34 +/-   0
ptp4l[407.485]: rms  155 max  282 freq  +9257 +/- 172 delay    34 +/-   0
ptp4l[408.485]: rms  402 max  541 freq  +9914 +/- 171 delay    34 +/-   0
ptp4l[409.486]: rms  437 max  611 freq  +8859 +/- 355 delay    33 +/-   0
ptp4l[410.486]: rms  339 max  488 freq  +8603 +/- 276 delay    33 +/-   0
ptp4l[411.487]: rms  231 max  384 freq  +9075 +/- 278 delay    34 +/-   0
ptp4l[412.487]: rms  125 max  168 freq  +9110 +/- 145 delay    33 +/-   0
ptp4l[413.488]: rms  538 max  702 freq  +8104 +/- 361 delay    33 +/-   

Any comments?

Thank you for your help!

HI Daolin,

Just checking the status of this, do you have any insights on why the rms offsets are not double digits and how to improve?

Thank you! 

Hi Matt, 

Apologies for the delay in response.

Matt Tsai52 said:

For #1, #2:

Yes, both the PTP grandmaster and slave are running on TI AM64x EVM, with the default SDK on SD card.

root@am64xx-evm:~/# uname -a
Linux am64xx-evm 6.6.58-ti-01497-ga7758da17c28-dirty #1 SMP PREEMPT Wed Nov 27 13:23:15 UTC 2024 aarch64 GNU/Linux

Are you able to replicate the same PTP offset on SDK 11.1 (which should be kernel version 6.12.x)? 

It might be worth checking if the RT-Linux version will also produce the same rms offsets, just as a sanity check or comparison with non-RT.

Just to clarify, you are using CPSW Ethernet (and not ICSSG Ethernet) to test PTP?

Here is what I found when testing on AM64x EVM1 eth0 <----> eth0 AM64x EVM2, where eth0 is CPSW Ethernet and using RT-Linux SDK 11.1. With this configuration, I see the expected 2-digit offset values.

EVM1- Grandmaster

root@am64xx-evm:~# cat gPTP.cfg 
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 100
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 96
egressLatency 288
root@am64xx-evm:~# ptp4l -P -2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0     
ptp4l[1261.577]: selected /dev/ptp0 as PTP clock
ptp4l[1261.605]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1261.605]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1261.606]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1265.107]: port 1 (eth0): new foreign master 1c6349.fffe.1ad7bc-1
ptp4l[1265.594]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1265.595]: selected local clock 3408e1.fffe.80a7ad as best master
ptp4l[1265.595]: port 1 (eth0): assuming the grand master role
ptp4l[1267.108]: selected best master clock 1c6349.fffe.1ad7bc
ptp4l[1267.108]: port 1 (eth0): assuming the grand master role
^Croot@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.35-g563c0d3bd742 #6 SMP PREEMPT_RT Thu Aug 14 15:16:24 CDT 2025 aarch64 GNU/Lx
root@am64xx-evm:~#

EVM2- Follower

root@am64xx-evm:~# cat gPTP.cfg 
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 240
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 96
egressLatency 288

root@am64xx-evm:~# ptp4l -P -2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0     
ptp4l[1257.220]: selected /dev/ptp0 as PTP clock
ptp4l[1257.251]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1257.252]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1257.252]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1261.220]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1261.221]: selected local clock 1c6349.fffe.1ad7bc as best master
ptp4l[1261.221]: port 1 (eth0): assuming the grand master role
ptp4l[1262.710]: port 1 (eth0): new foreign master 3408e1.fffe.80a7ad-1
ptp4l[1263.335]: port 1 (eth0): received SYNC without timestamp
ptp4l[1264.210]: port 1 (eth0): received SYNC without timestamp
ptp4l[1264.711]: selected best master clock 3408e1.fffe.80a7ad
ptp4l[1264.711]: port 1 (eth0): MASTER to UNCALIBRATED on RS_SLAVE
ptp4l[1265.461]: port 1 (eth0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1266.212]: rms 15114 max 19954 freq +16779 +/- 10396 delay  27 +/-  0
ptp4l[1267.212]: rms 2787 max 4269 freq +7682 +/- 3785 delay  27 +/-  0
ptp4l[1267.462]: port 1 (eth0): received SYNC without timestamp
ptp4l[1268.338]: rms 4737 max 5028 freq  -948 +/- 1247 delay  27 +/-  0
ptp4l[1269.339]: rms 2929 max 3924 freq -2476 +/- 139 delay  27 +/-  0
ptp4l[1270.339]: rms 913 max 1527 freq -1504 +/- 352 delay  27 +/-  0
ptp4l[1271.340]: rms 181 max 281 freq  -487 +/- 215 delay  27 +/-  0
ptp4l[1272.340]: rms 282 max 303 freq  -19 +/- 66 delay  26 +/-  0
ptp4l[1273.341]: rms 170 max 231 freq  +60 +/-  9 delay  26 +/-  0
ptp4l[1274.342]: rms  53 max  90 freq   +2 +/- 24 delay  27 +/-  0
ptp4l[1274.721]: port 1 (eth0): received PDELAY_REQ without timestamp
ptp4l[1275.342]: rms  38 max  56 freq  -104 +/- 32 delay  27 +/-  0
ptp4l[1276.343]: rms  21 max  37 freq  -116 +/- 10 delay  27 +/-  0
ptp4l[1277.343]: rms  8 max  13 freq  -88 +/-  8 delay  27 +/-  0
ptp4l[1278.344]: rms  11 max  14 freq  -72 +/-  5 delay  27 +/-  0
ptp4l[1279.345]: rms  4 max  7 freq  -76 +/-  4 delay  27 +/-  0
ptp4l[1280.345]: rms  5 max  9 freq  -85 +/-  5 delay  27 +/-  0
^Croot@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.35-g563c0d3bd742 #6 SMP PREEMPT_RT Thu Aug 14 15:16:24 CDT 2025 aarch64 GNU/Lx
root@am64xx-evm:~# 

-Daolin

Hi Daolin,

Thank you for the response. 
I believe I tested PTP with CPSW Ethernet. I roughly followed this TI webinar presentation to set up EVM1 as a switch (without cut-through), then testing PTP with EVM1 eth1 <--> EVM2 eth0
e2e.ti.com/.../TI-Sitara-Linux-TSN-webinar.pdf
Please explain if you think I might be using the ICSSG Ethernet.

I am willing to try SDK 11.1 with both non-RT kernel and RT kernel.
Can you please point out how do I obtain both images for the SD card?

Thank you for your help!

Hi Matt, 

Apologies again for the delay in response as I was/am out of office this week.

Matt Tsai52 said:

I am willing to try SDK 11.1 with both non-RT kernel and RT kernel.
Can you please point out how do I obtain both images for the SD card?

You can find the SDK 11.1 RT wic image here: https://www.ti.com/tool/de-de/download/PROCESSOR-SDK-LINUX-RT-AM64X 

For SDK 11.1 non-RT wic image: https://www.ti.com/tool/de-de/download/PROCESSOR-SDK-LINUX-AM64X 

Matt Tsai52 said:

I believe I tested PTP with CPSW Ethernet. I roughly followed this TI webinar presentation to set up EVM1 as a switch (without cut-through), then testing PTP with EVM1 eth1 <--> EVM2 eth0
e2e.ti.com/.../TI-Sitara-Linux-TSN-webinar.pdf
Please explain if you think I might be using the ICSSG Ethernet.

The webinar assumes that you are using the TI provided wic image. Based on that and assuming you made no changes to device tree or device tree overlay, both eth0 and eth1 by default are using CPSW Ethernet. 

-Daolin

Thank you, Daolin!

I will try PTP on SDK 11.1 and let you know the results. It may take a while. Thank you.

Hi Matt, 

Please let me know if/when you have an update

-Daolin

Hi Daolin,

Thank you for checking back with me. Sorry, I did not get a chance to try this on the RT kernel because we are trying to understand the AM64x more...

I have a question regarding TSN support on CPSW and PRU-ICSSG:

My understanding is they share the same software stacks, both in A53 (Linux) and R5F (FreeRTOS), except for hardware timestamping and some low-level hardware implemented features. But both CPSW and PRU-ICSSG have full TSN features (PTP, EST, IET, ...etc.) support. Is this correct?

What are the differences between these two in terms of TSN features, performance, ...etc.?

Also, I will update you once I get to run the same test on the RT kernel.

Thank you!

Hi Matt, 

Thanks for your response.

Matt Tsai52 said:

My understanding is they share the same software stacks, both in A53 (Linux) and R5F (FreeRTOS), except for hardware timestamping and some low-level hardware implemented features.

Can you explain a bit more by what you mean by software stacks? Just to for clarity, both the CPSW and PRU-ICSSG have different Linux device drivers. I suspect the same to be true for FreeRTOS side but I will need to defer to a colleague for a more expert response there. In terms of hardware timestamping and low-level hardware implemented feature, they use completely different timestamping hardware (CPSW uses Common Platform Time Sync - CPTS and PRU-ICSSG uses Industrial Ethernet Peripheral - IEP), the same is true for low-level hardware, please see the AM64x TRM for more details.

Matt Tsai52 said:

But both CPSW and PRU-ICSSG have full TSN features (PTP, EST, IET, ...etc.) support. Is this correct?

I would suggest checking the SDK release notes/documentation for a full list of which TSN features CPSW and PRU-ICSSG have software support for. The TRM can also give information on which TSN features are supported in hardware but not all hardware supported features have a software implementation. To my knowledge, we only claim support for PTP, EST, IET but not ALL TSN features.

Matt Tsai52 said:

What are the differences between these two in terms of TSN features, performance, ...etc.?

I don't have specific numbers/benchmarks on how CPSW vs PRU-ICSSG TSN features perform but generally PRU-ICSSG is best used for industrial communications applications requiring strict timing/deterministic needs such as robotics. Simply put, PRU-ICSSG is specifically better/optimized for more real-time applications compared CPSW which usually could be used in applications such as audio/video streaming where time synchronization is useful but doesn't need to adhere to as strict latency requirements.

-Daolin

Hi Daolin,

Just to explain what I meant by software stack, I guess maybe I can generalize it as the device driver. Now I know CPSW and PRU-ICSSG use different Linux device drivers. So they should be using different (at least some differences) "software stacks".

Hi Matt,

Yes, the way CPSW Ethernet and PRU-ICSSG Ethernet functionality is implemented/controlled in Linux is via the respective Linux device drivers, and yes they are completely different software implementations.

CPSW: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti?h=ti-linux-6.12.y 

PRU-ICSSG: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/icssg?h=ti-linux-6.12.y 

-Daolin

Hi Daolin,

I had a chance to try the RT kernel. However, the results did not seem to make any difference.
Here are my settings:

On the grandmaster:
# uname -a
Linux am64xx-evm 6.12.35-ti-rt-00915-ge3e551586dfa #1 SMP PREEMPT_RT Tue Jul  1 21:17:52 UTC 2025 aarch64 GNU/Linux

# cat gPTP.cfg
[global]
gmCapable               1
priority1               100
priority2               248
logAnnounceInterval     0
logSyncInterval         -3
syncReceiptTimeout      3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step         1
path_trace_enabled      1
follow_up_info          1
transportSpecific       0x1
ptp_dst_mac             01:80:C2:00:00:0E
network_transport       L2
delay_mechanism         P2P

# Add these lines for the TI PHY:
ingressLatency 88
egressLatency  288

# phc2sys -a -rr --transportSpecific=1 &
# ptp4l -P -2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0
Tue Sep 23 17:10:00 UTC 2025
ptp4l[6019.116]: selected /dev/ptp0 as PTP clock
ptp4l[6019.135]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[6019.136]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[6019.136]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[6022.438]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[6022.438]: selected local clock 641c10.fffe.2467bc as best master
ptp4l[6022.438]: port 1 (eth0): assuming the grand master role

On the follower:
# uname -a
Linux am64xx-evm 6.12.35-ti-rt-00915-ge3e551586dfa #1 SMP PREEMPT_RT Tue Jul  1 21:17:52 UTC 2025 aarch64 GNU/Linux

# cat gPTP.cfg
[global]
gmCapable               1
priority1               240
priority2               248
logAnnounceInterval     0
logSyncInterval         -3
syncReceiptTimeout      3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step         1
path_trace_enabled      1
follow_up_info          1
transportSpecific       0x1
ptp_dst_mac             01:80:C2:00:00:0E
network_transport       L2
delay_mechanism         P2P

# Add these lines for the TI PHY:
ingressLatency 88
egressLatency  288

# phc2sys -a -r --transportSpecific=1 &
# ptp4l -P -2 -H -i eth0 -s -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0
ptp4l[4041.115]: selected /dev/ptp0 as PTP clock
ptp4l[4041.137]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[4041.137]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[4041.138]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[4044.320]: port 1 (eth0): new foreign master 641c10.fffe.2467bc-1
ptp4l[4044.920]: selected local clock 641c10.fffe.24678f as best master
ptp4l[4046.320]: selected best master clock 641c10.fffe.2467bc
ptp4l[4046.320]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4047.449]: port 1 (eth0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[4048.075]: rms 78767586163 max 157535172486 freq  +2217 +/- 2466 delay    34 +/-   0
ptp4l[4049.076]: rms 1076 max 1939 freq  +4214 +/- 1368 delay    34 +/-   0
ptp4l[4050.076]: rms 2039 max 2246 freq  +7807 +/- 367 delay    33 +/-   0
ptp4l[4051.077]: rms  961 max 1285 freq  +7862 +/-  31 delay    33 +/-   0
ptp4l[4052.077]: rms  394 max  586 freq  +7734 +/- 123 delay    33 +/-   0
ptp4l[4053.078]: rms  354 max  620 freq  +6972 +/- 412 delay    34 +/-   0
ptp4l[4054.078]: rms  550 max  650 freq  +6064 +/-  74 delay    34 +/-   0
ptp4l[4055.079]: rms  204 max  312 freq  +6184 +/- 109 delay    34 +/-   0
ptp4l[4056.080]: rms  315 max  641 freq  +6475 +/- 438 delay    34 +/-   0
ptp4l[4057.080]: rms  345 max  573 freq  +7081 +/- 157 delay    35 +/-   0
ptp4l[4058.081]: rms  265 max  392 freq  +6777 +/- 373 delay    35 +/-   0
ptp4l[4059.082]: rms  477 max  540 freq  +5833 +/- 134 delay    35 +/-   0
ptp4l[4060.082]: rms  212 max  331 freq  +5847 +/-  63 delay    35 +/-   0
ptp4l[4061.083]: rms  440 max  711 freq  +6635 +/- 460 delay    35 +/-   0
ptp4l[4062.084]: rms  517 max  676 freq  +7387 +/-  83 delay    35 +/-   0
ptp4l[4063.084]: rms  336 max  514 freq  +7447 +/- 262 delay    35 +/-   0
ptp4l[4064.085]: rms  507 max  607 freq  +6266 +/- 286 delay    35 +/-   0
ptp4l[4065.085]: rms  518 max  615 freq  +5672 +/- 117 delay    35 +/-   0
ptp4l[4066.086]: rms  409 max  572 freq  +5842 +/- 527 delay    35 +/-   0
ptp4l[4067.087]: rms  356 max  472 freq  +6711 +/-  32 delay    35 +/-   0
ptp4l[4068.087]: rms  520 max  650 freq  +7351 +/- 234 delay    35 +/-   0
ptp4l[4069.088]: rms  286 max  566 freq  +6557 +/- 312 delay    35 +/-   0
ptp4l[4070.089]: rms  738 max  899 freq  +5286 +/- 154 delay    35 +/-   0
ptp4l[4071.089]: rms  356 max  541 freq  +5273 +/- 114 delay    35 +/-   0
ptp4l[4072.090]: rms  399 max  609 freq  +6174 +/- 390 delay    35 +/-   0
ptp4l[4073.090]: rms  563 max  775 freq  +6981 +/- 205 delay    35 +/-   0
ptp4l[4074.091]: rms   54 max  126 freq  +6492 +/-  75 delay    34 +/-   0
ptp4l[4075.092]: rms  245 max  358 freq  +6912 +/- 141 delay    34 +/-   0
ptp4l[4076.092]: rms  125 max  207 freq  +6692 +/- 174 delay    34 +/-   0
ptp4l[4077.093]: rms  173 max  273 freq  +6610 +/- 228 delay    34 +/-   0
ptp4l[4078.093]: rms  221 max  309 freq  +7083 +/-  98 delay    34 +/-   0
ptp4l[4079.094]: rms  270 max  324 freq  +7381 +/- 160 delay    34 +/-   0
ptp4l[4080.095]: rms  568 max  710 freq  +8233 +/- 225 delay    34 +/-   0
ptp4l[4081.095]: rms  295 max  412 freq  +8289 +/- 122 delay    34 +/-   0
ptp4l[4082.096]: rms  143 max  202 freq  +8274 +/-  91 delay    34 +/-   0
ptp4l[4083.096]: rms  122 max  188 freq  +8392 +/-  32 delay    34 +/-   0
ptp4l[4084.097]: rms   57 max   97 freq  +8382 +/-  30 delay    34 +/-   0
ptp4l[4085.098]: rms   19 max   28 freq  +8343 +/-  26 delay    34 +/-   0
ptp4l[4086.098]: rms   91 max  129 freq  +8354 +/- 126 delay    34 +/-   0
ptp4l[4087.099]: rms  518 max  665 freq  +7381 +/- 243 delay    34 +/-   0
ptp4l[4088.100]: rms  319 max  524 freq  +7396 +/- 318 delay    34 +/-   0
ptp4l[4089.100]: rms  413 max  503 freq  +8366 +/- 229 delay    34 +/-   0
ptp4l[4090.101]: rms  270 max  429 freq  +8545 +/-  75 delay    34 +/-   0
ptp4l[4091.102]: rms  197 max  387 freq  +8376 +/- 269 delay    34 +/-   0
ptp4l[4092.102]: rms  336 max  532 freq  +7712 +/- 139 delay    35 +/-   0
ptp4l[4093.103]: rms   61 max  108 freq  +8014 +/-  86 delay    34 +/-   0

Can you please help what I might still be missing?


Thank you for your help!

Hi Matt, 

If possible, can you please share a picture/diagram of your hardware setup/topology? 

Just to double check, do you have any other non-PTP traffic in your network?

Do the two AM64x EVMs you are using have a label "PROC101C"?

What Ethernet cable type are you using? I'm using CAT6.

My goal is to check there are no hardware differences between your setup and mine. 

From software side, my setup is using same exact SDK image so there should technically be no difference there.

As a sanity check can you check if the ptp4l version is 4.1? 

What is the result of "ethtool -T eth0" for you?

Below is my setup using the same steps as you

Grandmaster:

root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.35-ti-rt-00915-ge3e551586dfa #1 SMP PREEMPT_RT Tue Jul 1 21:17:52 UTC 2025 ax
root@am64xx-evm:~# [ 1155.302275] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - ff
[ 1160.421353] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
[ 1163.494305] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 1178.853302] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
[ 1182.950301] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

root@am64xx-evm:~# cat gPTP.cfg 
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 100
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 88
egressLatency 288
root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.35-ti-rt-00915-ge3e551586dfa #1 SMP PREEMPT_RT Tue Jul 1 21:17:52 UTC 2025 ax
root@am64xx-evm:~# phc2sys -a -rr --transportSpecific=1 &
[1] 1208
root@am64xx-evm:~# ptp4l -P -2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0
ptp4l[1291.577]: selected /dev/ptp0 as PTP clock
ptp4l[1291.611]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1291.612]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1291.612]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1295.383]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1295.383]: selected local clock 3408e1.fffe.80a7ad as best master
ptp4l[1295.383]: port 1 (eth0): assuming the grand master role
^Croot@am64xx-evm:~# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.12.35-ti-rt-00915-ge3e551586d
firmware-version: 
expansion-rom-version: 
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
root@am64xx-evm:~# ptp4l -v
4.1
root@am64xx-evm:~#

Follower:

root@am64xx-evm:~# cat gPTP.cfg 
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 240
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 88
egressLatency 288
root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.35-ti-rt-00915-ge3e551586dfa #1 SMP PREEMPT_RT Tue Jul 1 21:17:52 UTC 2025 aax
root@am64xx-evm:~# phc2sys -a -r --transportSpecific=1 &
[1] 881
root@am64xx-evm:~# ptp4l -P -2 -H -i eth0 -s -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0
ptp4l[179.632]: selected /dev/ptp0 as PTP clock
ptp4l[179.660]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[179.661]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[179.661]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[182.771]: port 1 (eth0): new foreign master 3408e1.fffe.80a7ad-1
ptp4l[182.795]: selected local clock 1c6349.fffe.1ad8aa as best master
ptp4l[184.771]: selected best master clock 3408e1.fffe.80a7ad
ptp4l[184.772]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[185.924]: port 1 (eth0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[186.550]: rms 874272849532328064 max 1748545699064656128 freq -5502 +/- 2560 delay  35 +/- 0
ptp4l[187.550]: rms 506 max 776 freq -4195 +/- 686 delay  35 +/-  0
ptp4l[188.551]: rms 841 max 881 freq -2668 +/- 220 delay  34 +/-  0
ptp4l[189.552]: rms 531 max 705 freq -2376 +/- 21 delay  35 +/-  0
ptp4l[190.552]: rms 168 max 283 freq -2547 +/- 67 delay  35 +/-  0
ptp4l[191.553]: rms  33 max  50 freq -2736 +/- 38 delay  35 +/-  0
ptp4l[192.554]: rms  53 max  56 freq -2823 +/- 14 delay  34 +/-  0
ptp4l[193.555]: rms  32 max  45 freq -2838 +/-  3 delay  34 +/-  0
ptp4l[194.555]: rms  15 max  19 freq -2838 +/-  2 delay  34 +/-  0
ptp4l[195.556]: rms  10 max  11 freq -2843 +/-  2 delay  35 +/-  0
ptp4l[196.556]: rms  2 max  5 freq -2839 +/-  1 delay  35 +/-  0
ptp4l[197.557]: rms  5 max  7 freq -2828 +/-  4 delay  35 +/-  0
ptp4l[198.558]: rms  3 max  5 freq -2834 +/-  4 delay  36 +/-  0
ptp4l[199.558]: rms  1 max  2 freq -2835 +/-  1 delay  35 +/-  0
ptp4l[200.559]: rms  2 max  4 freq -2837 +/-  2 delay  34 +/-  0
ptp4l[201.559]: rms  8 max  10 freq -2850 +/-  5 delay  34 +/-  0
ptp4l[202.560]: rms  5 max  8 freq -2854 +/-  1 delay  35 +/-  0
ptp4l[203.561]: rms  2 max  4 freq -2846 +/-  3 delay  35 +/-  0
^Croot@am64xx-evm:~# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.12.35-ti-rt-00915-ge3e551586d
firmware-version: 
expansion-rom-version: 
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
root@am64xx-evm:~# ptp4l -v
4.1
root@am64xx-evm:~#

It might be worth capturing a tcpdump of the PTP traffic in a .pcap file and see if Wireshark can determine if there are any problems with PTP synchronization.

-Daolin

Hi Daolin,

My setup is two AM64x EVM connect to each other on eth0 (J14 CPSW, the standalone one) using the CAT6 cable included in TI EVM kit. I do not have the camera now. But I can share the photo later if needed.

The two EVMs have the label "PROC101D".

On the grandmaster:

root@am64xx-evm:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        ptpv2-l4-event
        ptpv2-l4-sync
        ptpv2-l4-delay-req
        ptpv2-l2-event
        ptpv2-l2-sync
        ptpv2-l2-delay-req
        ptpv2-event
        ptpv2-sync
        ptpv2-delay-req

root@am64xx-evm:~# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.12.35-ti-rt-00915-ge3e551586d
firmware-version:
expansion-rom-version:
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
root@am64xx-evm:~# ptp4l -v
4.1

On the follower:

root@am64xx-evm:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        ptpv2-l4-event
        ptpv2-l4-sync
        ptpv2-l4-delay-req
        ptpv2-l2-event
        ptpv2-l2-sync
        ptpv2-l2-delay-req
        ptpv2-event
        ptpv2-sync
        ptpv2-delay-req
        
root@am64xx-evm:~# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.12.35-ti-rt-00915-ge3e551586d
firmware-version:
expansion-rom-version:
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes

root@am64xx-evm:~# ptp4l -v
4.1

One thing I noticed is on both granmaster and follower, there are additional messages that are different from yours, not sure if this matters.

[  270.300970] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
[  271.336046] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POLL)
[  271.336077] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
root@am64xx-evm:~# [  274.406416] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

I was able to see the follower's system time synced with the grandmaster's. So I assume the ptp working.

Please let me know if you still need a tcpdump of .pcap file. I will try to capture it. I was afraid the tcpdump could slow down the EVMs. So please share a good method to capture the trace from the EVMs if you have.

Thank you for your help!

Hi Daolin,

My setup is two AM64x EVM connect to each other on eth0 (J14 CPSW, the standalone one) using the CAT6 cable included in TI EVM kit. I do not have the camera now. But I can share the photo later if needed.

The two EVMs have the label "PROC101D".

On the grandmaster:

root@am64xx-evm:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        ptpv2-l4-event
        ptpv2-l4-sync
        ptpv2-l4-delay-req
        ptpv2-l2-event
        ptpv2-l2-sync
        ptpv2-l2-delay-req
        ptpv2-event
        ptpv2-sync
        ptpv2-delay-req

root@am64xx-evm:~# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.12.35-ti-rt-00915-ge3e551586d
firmware-version:
expansion-rom-version:
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
root@am64xx-evm:~# ptp4l -v
4.1

On the follower:

root@am64xx-evm:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        ptpv2-l4-event
        ptpv2-l4-sync
        ptpv2-l4-delay-req
        ptpv2-l2-event
        ptpv2-l2-sync
        ptpv2-l2-delay-req
        ptpv2-event
        ptpv2-sync
        ptpv2-delay-req
        
root@am64xx-evm:~# ethtool -i eth0
driver: am65-cpsw-nuss
version: 6.12.35-ti-rt-00915-ge3e551586d
firmware-version:
expansion-rom-version:
bus-info: 8000000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes

root@am64xx-evm:~# ptp4l -v
4.1

One thing I noticed is on both granmaster and follower, there are additional messages that are different from yours, not sure if this matters.

[  270.300970] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
[  271.336046] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POLL)
[  271.336077] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
root@am64xx-evm:~# [  274.406416] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

I was able to see the follower's system time synced with the grandmaster's. So I assume the ptp working.

Please let me know if you still need a tcpdump of .pcap file. I will try to capture it. I was afraid the tcpdump could slow down the EVMs. So please share a good method to capture the trace from the EVMs if you have.

Thank you for your help!

Hi Daolin,

I had trouble uploading a file to E2E. The "Insert" -> "Image/video/file" did not work me. If you still need the picture of my setup, please advise how do I upload it to E2E. Thank you!

Hi Matt, 

Matt Tsai52 said:

The two EVMs have the label "PROC101D".

Let me check internally what major differences there might be between PROC101C and PROC101D of the AM64x EVM. If you haven't heard back by Tuesday, please kindly ping this thread again

Matt Tsai52 said:

I had trouble uploading a file to E2E. The "Insert" -> "Image/video/file" did not work me. If you still need the picture of my setup, please advise how do I upload it to E2E.

Feel free to try and send the image via direct message to my E2E profile. You may need to request friendship first to connect.

Matt Tsai52 said:

One thing I noticed is on both granmaster and follower, there are additional messages that are different from yours, not sure if this matters.

[  270.300970] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
[  271.336046] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POLL)
[  271.336077] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
root@am64xx-evm:~# [  274.406416] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

I think the differences here is if you bring down and back up the interface via "ifconfig eth0 down/up" you will see the messages in blue. If you just physically disconnect the cable, then the messages in blue will not show up. Either way, it shouldn't interfere with the PTP synchronization.

-Daolin

Hi Matt, 

Daolin Qiu said:

Just to double check, do you have any other non-PTP traffic in your network?

Thanks for sharing a photo of your setup, just to double check, the only traffic between the two EVMs is just PTP traffic right?

Matt Tsai52 said:

Please let me know if you still need a tcpdump of .pcap file. I will try to capture it. I was afraid the tcpdump could slow down the EVMs. So please share a good method to capture the trace from the EVMs if you have.

What I would typically try is just run tcpdump -i eth0 -s 65535 -w <pcap filename>.pcap. I'm not entirely sure if the pcap will show any useful data but doesn't hurt to try to collect a pcap just in case it can shed some light into what is going on.

Daolin Qiu said:

Let me check internally what major differences there might be between PROC101C and PROC101D of the AM64x EVM.

I'm still trying to track down internally on what, if any, hardware differences are between PROC101C and PROC101D 

One feedback I got was to see if you can run ptp4l with the highest/or higher priority to avoid software context switching. For instance, you should change the priority and scheduling policy of ptp4l by "chrt -f -p <priority number> <process id>". The higher the priority number, the higher the priority. You can check process id with "ps -A | grep ptp4l". 

-Daolin

Hi Daolin,

Thank you for the inputs.

Yes, I believe PTP traffic is the only traffic between two EVMs. I just run the default software on the RT SDK. I don't think there are other programs generating network traffic in the background.

I also tried raising the priority by doing "chrt -f 99 ptp4l -P -2 -H -i eth0 ..." on both EVMs but did not find significant difference for the results. (Do you need to raise the priority of your ptp program in order to achieve 2 digit rms offsets? If you don't, then I should be able to replicate what you have...)

I captured the .pcap file and will send you shortly. I do not know PTP protocol well, maybe you will be able to spot something.

Thank you for your help!

Daolin Qiu said:

I'm still trying to track down internally on what, if any, hardware differences are between PROC101C and PROC101D 

It appears that all new EVMs shipped out are PROC101D (Rev D). The design files public on ti.com is not yet released but planned to be. The changes seem to be only bill of materials related and no changes to the SoC silicon nor the layout of the board. One the main clues I can find is the fact that a resistor and capacitor that was populated in Rev. C for SoC_CLKIN from the Ethernet PHY Clock Buffer was removed. I'm still working on trying to figure out why they were removed.

-Daolin

Thank you for the update. Please keep me posted. Thanks!