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!

Hi Daolin,

Just checking with you, any updates on this? Thank you.

Hi Matt, 

Daolin Qiu said:

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.

While I'm still waiting on feedback on this component removal (team who made the changes is on holiday this week), one thing I found out was that there are two versions of the PROC101D schematic that is public, one that has the resistor and capacitor removed and one that does not. Checking on the physical EVM, the physical EVM shows that the resistor and capacitor feeding into SoC_CLKIN are still installed so I think this rules out this particular change causing issues.

There are other changes between PROC101C and PROC101D but these changes I cannot see at the moment why that would cause time synchronization issues (see below). I would need to pull in some hardware experts to understand so this may take a bit of time. I'm thinking maybe something to test is to see if changes to the inductors and capacitors can be reverted to see if the synchronization issue is fixed, that way we can narrow down if it is actually these board changes causing synchronization issues.

-Daolin

Hi Daolin,

Thank you for the update.

Not sure if this matters, but I was able to run TI's PTP grandmaster/slave examples on the MCU (R5F core) using the same setup. I cannot get the offsetz under 100ns, either...

Console output from grandmaster:
domain=0, offset=0nsec, hw-adjrate=0ppb
        gmsync=true, last_setts64=0nsec
  89238.210s : CPU load =   2.45 %
  89243.211s : CPU load =   2.44 %
domain=0, offset=0nsec, hw-adjrate=0ppb
        gmsync=true, last_setts64=0nsec
  89248.212s : CPU load =   2.19 %
  89253.213s : CPU load =   2.44 %
domain=0, offset=0nsec, hw-adjrate=0ppb
        gmsync=true, last_setts64=0nsec
  89258.214s : CPU load =   2.19 %
  89263.215s : CPU load =   2.44 %
domain=0, offset=0nsec, hw-adjrate=0ppb
        gmsync=true, last_setts64=0nsec
  89268.216s : CPU load =   2.45 %

Console output from the follower:

IFV:gptp:089430-194647:domainIndex=0, clock_master_sync_receive:the master clock rate to 35162ppb, GMdiff=324nsec
domain=0, offset=0nsec, hw-adjrate=35162ppb
        gmsync=true, last_setts64=0nsec
IFV:gptp:089430-319637:domainIndex=0, clock_master_sync_receive:the master clock rate to 35184ppb, GMdiff=298nsec
IFV:gptp:089430-444643:domainIndex=0, clock_master_sync_receive:the master clock rate to 35258ppb, GMdiff=298nsec
IFV:gptp:089430-569906:domainIndex=0, clock_master_sync_receive:the master clock rate to 35394ppb, GMdiff=326nsec
IFV:gptp:089430-694646:domainIndex=0, clock_master_sync_receive:the master clock rate to 35500ppb, GMdiff=337nsec
IFV:gptp:089430-819633:domainIndex=0, clock_master_sync_receive:the master clock rate to 35624ppb, GMdiff=355nsec
IFV:gptp:089430-944641:domainIndex=0, clock_master_sync_receive:the master clock rate to 35833ppb, GMdiff=409nsec
IFV:gptp:089431-069632:domainIndex=0, clock_master_sync_receive:the master clock rate to 36000ppb, GMdiff=438nsec
IFV:gptp:089431-194636:domainIndex=0, clock_master_sync_receive:the master clock rate to 36142ppb, GMdiff=453nsec
IFV:gptp:089431-319626:domainIndex=0, clock_master_sync_receive:the master clock rate to 36298ppb, GMdiff=472nsec
IFV:gptp:089431-444638:domainIndex=0, clock_master_sync_receive:the master clock rate to 36410ppb, GMdiff=469nsec
IFV:gptp:089431-569901:domainIndex=0, clock_master_sync_receive:the master clock rate to 36580ppb, GMdiff=493nsec
IFV:gptp:089431-694639:domainIndex=0, clock_master_sync_receive:the master clock rate to 36851ppb, GMdiff=559nsec
IFV:gptp:089431-819626:domainIndex=0, clock_master_sync_receive:the master clock rate to 36966ppb, GMdiff=548nsec
IFV:gptp:089431-944636:domainIndex=0, clock_master_sync_receive:the master clock rate to 37061ppb, GMdiff=529nsec
IFV:gptp:089432-069624:domainIndex=0, clock_master_sync_receive:the master clock rate to 37179ppb, GMdiff=523nsec
IFV:gptp:089432-194630:domainIndex=0, clock_master_sync_receive:the master clock rate to 37232ppb, GMdiff=488nsec
IFV:gptp:089432-319616:domainIndex=0, clock_master_sync_receive:the master clock rate to 37221ppb, GMdiff=429nsec
IFV:gptp:089432-444633:domainIndex=0, clock_master_sync_receive:the master clock rate to 37205ppb, GMdiff=374nsec
IFV:gptp:089432-694628:domainIndex=0, clock_master_sync_receive:the master clock rate to 37174ppb, GMdiff=278nsec
IFV:gptp:089432-819623:domainIndex=0, clock_master_sync_receive:the master clock rate to 37133ppb, GMdiff=229nsec
IFV:gptp:089432-944630:domainIndex=0, clock_master_sync_receive:the master clock rate to 37060ppb, GMdiff=171nsec
IFV:gptp:089433-069625:domainIndex=0, clock_master_sync_receive:the master clock rate to 36929ppb, GMdiff=94nsec
IFV:gptp:089433-194620:domainIndex=0, clock_master_sync_receive:the master clock rate to 36844ppb, GMdiff=46nsec
  89433.232s : CPU load =   3.45 %

Not sure if you get a chance to try this on a PROC101D EVMs, I wonder what results you get.

It is critical for our project to be able to achieve the sub-100ns difference between TSN parties.

So please keep me posted.

Thank you!

Hi Matt,

Matt Tsai52 said:

Not sure if this matters, but I was able to run TI's PTP grandmaster/slave examples on the MCU (R5F core) using the same setup. I cannot get the offsetz under 100ns, either...

This is a valuable piece of information because it's an additional reason why the synchronization offset issue is not software specific. 

Matt Tsai52 said:

Not sure if you get a chance to try this on a PROC101D EVMs, I wonder what results you get.

I was able to test on PROC101D EVMs and while I didn't save the logs, I saw similar offset as you reported. Proves the problem is only observed on PROC101D EVMs. 

I looped in a Hardware expert. Please kindly ping this thread if you haven't heard back by Thursday.

-Daolin

Hi Daolin,

Thank you for the message and look forward to your update soon. Thanks!

Hi Matt,

I didn't find differences in terms of system clocking and Ethernet PHY from first glance. I will need some more time to check internally.

Thanks,

Stan

Hello Daolin,

Can you please describe the test methodology. Is the CPSW3G interface of SOC and the EPHY the key components 

On the Revd board, can you please confirm components circled are mounted in case these components are of concern.

I see those components mounted on the REVD schematics 

The below schematic that has the components DNId is for customers and has not been assembled.

Regards,

Sreenivasa

PROC101D_SCH_With_Design_Updates..Notes_V1.0.pdf

Hello,

Just checking back to see if there is any update/progress on this?

Thank you!

Hi All, 

Kallikuppa Sreenivasa said:

Can you please describe the test methodology. Is the CPSW3G interface of SOC and the EPHY the key components 

FYI, this was the last query i asked.

Regards,

Sreenivasa

Hi Sreenivasa,

I believe that is what Daolin described. Hi Daolin Qiu , please add comments if needed. Thank you!

Hello Matt,

Thank you.

Hi Daolin, let me know if you have some thoughts.

Regards,

Sreenivasa

Hi,

Just checking back, because there was no update since Sreenivasa's reply 21 days ago. Wanted to know if TI is still looking into this.

Any updates on this? Thank you!

Hi Matt, Sreenivasa,

Apologies, this thread was in Sreenivasa's dashboard so it didn't show in my dashboard so I didn't see the latest messages. 

Kallikuppa Sreenivasa said:

On the Revd board, can you please confirm components circled are mounted in case these components are of concern.

These components are already mounted on the RevD board. So these should not be an issue.

Kallikuppa Sreenivasa said:

PROC101D_SCH_With_Design_Updates..Notes_V1.0.pdf

My understanding is that this schematic does not actually reflect the RevD TI EVM that gets shipped out and are simply what is the recommended design.

Kallikuppa Sreenivasa said:

Can you please describe the test methodology. Is the CPSW3G interface of SOC and the EPHY the key components 

Test methodology is as described in  RE: PROCESSOR-SDK-AM64X: AM64x PTP related question  but with RevD version of the TI EVM resulting in PTP synchronization ~100s of ns as opposed to the expected <20ns. This problem does not occur for RevC version of the TI EVM with the same exact software.

The same issue occurs for both PRU-ICSSG and CPSW3G Ethernet interfaces.

-Daolin

Hello Daolin, 

Thank you.

The EVM team is checking for differences between revisions.

I will update the thread when i hear back.

Regards,

Sreenivasa

Hello Matt, 

Apologies in the delayed response below is an update.

Update:

We've identified that there is a problem with the 25MHz clock oscillator used as an input to the SoC. Currently it is sourced from part labeled U71 on the EVM. As a workaround, until we can identify specifically the issue with the clock oscillator, after making the below modifications, you will be able to see the expected jitter. 

1. Remove the resistor from R137 solder to R138
2. Remove the resistor from R140 solder to R139

Please let us know if this is a sufficient workaround for your use case or if it is not.

-Daolin

Hello Matt, 

Thank you for the inputs.

Regards,

Sreenivasa