EVMK2H IEEE 1588 PTP and PPS

Hi Tony,

We are working on your query. We will post our suggestions shortly.

Thank you.

Hi,

I am not sure, did you enable the CPTS in keystone_defconfig : CONFIG_TI_CPTS=y

Did you follow the steps to test the CPTS module as per the below wiki page,

http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Common_Platform_Time_Sync_.28CPTS.29

Hi Pubesh,

I use the default image keystone-evm-ubifs.ubi in MCSDK 3.00.04 release. I check its kernel source code,

keystone_defconfig : CONFIG_TI_CPTS=y.

Yes, I following the link to do CPTS/PTS test.

I use two EVMK2H boards for testing. One is slave and the other is Master.

Master: ./ptp4l -E -4 -S -i eth0 -l 7 -m -q -p /dev/ptp0

Slave: ./ptp4l -E -4 -S -i eth0 -s -l 7 -m -q -p /dev/ptp0

Slave can sync time with Master. PTP works fine.

But if I use hw timestamping, then PTP doens't work.

Master: ./ptp4l -E -4 -H -i eth0 -l 7 -m -q -p /dev/ptp0

Slave: ./ptp4l -E -4 -H -i eth0 -s -l 7 -m -q -p /dev/ptp0

 One more thing, does ptp4l support unicast? I dont' see parameter to specify the server ip address.

Tony,

I did not experiment this time-stamp protocol, but the ptp4l should support unicast. Did you get any working progress on the same.

Hi Pubesh,

No, no working pgogress.

Did TI has a patch code for ptp4l? So it works on TI EVM board.

Tony,

As of now there is no patch code for ptp4l provided by TI. You can search the keyword like ptp4l in google/linux forum.

And also I recommend you, please create new thread at linux forum to get fast response from the expert.

http://e2e.ti.com/support/embedded/linux/default.aspx

Hi, Tony,

Please be sure that you follow the instructions in the User's Guide, http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Testing_CPTS.2FPTP

Rex

Hi Rex,

Yes, I did follow the follow the instructions in the User's Guide. Below is testing result.

1. HW timestamp over L2 works fine, but over L4 doesn't work.

2. SW timestamp over L4/L2 works fine.

3.If connecting with PTP server, either HW/SW timestamp over L2/L4 doesn't work.

Note: <1>, <2> Master is EVMK2H board. <3> Master is PTP server

Tony

Hi, Tony,

What version of MCSDK release are you using? I tried HW timestamp over L4 using MCSDK 3.0.4 and it works for me. Please see the logs below. The clock time changed from 1/1/1970 to 7/16/2014. I am testing against server on a desktop PC. In case <3>, are you using a grandmaster or a local server? If the grandmaster (domain server), could you try with local setup?

keystone-evm login: root
root@keystone-evm:~# ./testptp -g
clock time: 17.455636589 or Thu Jan  1 00:00:17 1970
root@keystone-evm:~# ./testptp -g
clock time: 21.984037245 or Thu Jan  1 00:00:21 1970
root@keystone-evm:~# date
Sun Nov 24 22:34:16 UTC 2013
root@keystone-evm:~# ./ptp4l -E -4 -H -i eth0 -s -l 7 -m -q -p /dev/ptp0
ptp4l[48.620]: selected /dev/ptp0 as PTP clock
ptp4l[48.622]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[48.622]: port 1: get_ts_info not supported
ptp4l[48.623]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[48.624]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[49.443]: port 1: setting asCapable
ptp4l[50.443]: port 1: new foreign master 001871.fffe.7c869b-1
ptp4l[54.443]: selected best master clock 001871.fffe.7c869b
ptp4l[54.443]: foreign master not using PTP timescale
ptp4l[54.443]: running in a temporal vortex
ptp4l[54.443]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[55.150]: port 1: delay timeout
ptp4l[55.383]: port 1: delay timeout
ptp4l[56.878]: port 1: delay timeout
ptp4l[56.878]: path delay         26794      26794
ptp4l[57.187]: port 1: delay timeout
ptp4l[57.187]: path delay         25934      25075
ptp4l[57.443]: master offset -1405525296420810905 s0 freq      +0 path delay     25934
ptp4l[57.902]: port 1: delay timeout
ptp4l[57.902]: path delay         26173      26173
ptp4l[58.443]: master offset -1405525296420815762 s1 freq   -4857 path delay     26173
ptp4l[59.217]: port 1: delay timeout
^Cptp4l[59.259]: caught signal 2
root@keystone-evm:~# ./testptp -g
clock time: 1405525358.505513889 or Wed Jul 16 15:42:38 2014

Rex

Hi Rex,

I use MCSDK ver 3.00.04, the same as yours and I use a Grandmaster. May I check with you the below questions?

1. What is your master? A EVMK2H or a local server? What's the ptp4l command parameter?

2. Would  you provide /sys/device/soc.0/2090000.netcp/cpsw/port_ts/1/config, mcast_addr, uni_en setting?

Tony

1. Please see my last response. Server is running on my desktop Linux PC.

2.
root@keystone-evm:~# cat /sys/devices/soc.0/2090000.netcp/cpsw/port_ts/1/config
000f06bb 001e88f7 81008100 01a088f7 00040000
root@keystone-evm:~#
root@keystone-evm:~#
ddr @keystone-evm:~# cat /sys/devices/soc.0/2090000.netcp/cpsw/port_ts/1/mcast_ad
00
root@keystone-evm:~#
root@keystone-evm:~# cat /sys/devices/soc.0/2090000.netcp/cpsw/port_ts/1/uni_en
1oot@keystone-evm:~# cat /sys/devices/soc.0/2090000.netcp/cpsw/port_ts/1/uni_en
root@keystone-evm:~#

Hi Rex,

Thanks for your answer. I have two more questions.

1. You enable unicast, so ptp4l should use unicast, instead of multicast. But ptp4l does not specify "unicast" mode and PTP server id address.

2. Does your Desktop Linux PC support HW timestamp? Can you provide your ptp4l command parameters running on your Desktop Linux PC?

Tony

Hi, Tony,

I didn't purposedly enabled the unicast. Before I ran the ptp4l command on the EVM, uni_en was 0. After running it, uni_en became 1. I just follow the instructions in the wiki page and didn't do anything speicail.

I searched the internet and downloaded the ptpd2 server for my ptp test. The command I ran on desktop is "./tptd2 -m -i eth0" where -m: Master,slave when not best GM; -i: interface.

Rex

Hi Rex,

Let me check with you. Your test environment is as below. Right?

Master: Desktop Linux PC,

#ptpd2 -m -i eth0

==============================================

Slave: EVMK2H

#./ptp4l -E -4 -H -i eth0 -s -l 7 -m -q -p /dev/ptp0

==================================================

I follow your instructions, and it still doesn't work.

But if I change slave command to #./ptp4l -E -4 -S -i eth0 -s -l 7 -m -q -p /dev/ptp0

It works fine, but difference from yours.

Verify it with date and testptp command.

root@keystone-evm:~# date
Thu Jul 24 09:05:06 CST 2014...............................change it to correct date.

root@keystone-evm:~# ./testptp  -g
clock time: 2070.338428304 or Thu Jan  1 08:34:30 1970..........does not change

Hi, Tony,

Your description of my set up is correct which you can see from the logs in my earlier post. Something is different between our set up. My "date" does not change until I do "./testptp -S" to set the system time from the ptp clock time. Could you run the following command to see what is supported on your EVM. Mine shows below.

root@keystone-evm:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
        hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
        software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
        hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
        hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off                   (HWTSTAMP_TX_OFF)
        on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
        none                  (HWTSTAMP_FILTER_NONE)
        ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
        ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

Hi Rex,

The result is as below. It looks the same as yours.

root@keystone-evm:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
        hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
        software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
        hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
        hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off                   (HWTSTAMP_TX_OFF)
        on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
        none                  (HWTSTAMP_FILTER_NONE)
        ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
        ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

Hi Rex,

Would you help to check  if PTP slave still work fine under below conditions? If yes. What's the command parameters?

case 1:

PTP master (Desktop Linux PC) runs ptp4l.

case 2:

PTP master is a Grandmaster server equipped with GPS

Hi, Tony,

Your "ethtool -T" shows that eth0 does support Hardware timestamp, so there is no reason that it does not work for you. Here is what I get from running ptp4l master on Desktop PC. Commands are shown in the logs. The master is running software timestamp because the desktop PC does not have the hardware to support. I tried to capture the packets but the wireshark does not even capture the ICMP packets. I am not sure what my wireshark issue is. Any way, the logs for master and slave are shown below.

Master (Linux Desktop):

$ sudo ./ptp4l -E -4 -S -i eth0 -l 7 -m -q -p /dev/ptp0
[sudo] password for a0850461:
ptp4l[1143011.373]: PI servo: sync interval 1.000 kp 0.100 ki 0.001000
ptp4l[1143011.373]: port 1: get_ts_info not supported
ptp4l[1143011.375]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1143011.375]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1143017.648]: port 1: announce timeout
ptp4l[1143017.648]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1143017.648]: selected best master clock 0014c2.fffe.5e6541
ptp4l[1143017.648]: assuming the grand master role
ptp4l[1143017.649]: port 1: master tx announce timeout
ptp4l[1143017.649]: port 1: setting asCapable
ptp4l[1143018.648]: port 1: master sync timeout
ptp4l[1143019.648]: port 1: master sync timeout
ptp4l[1143019.649]: port 1: master tx announce timeout
ptp4l[1143020.648]: port 1: master sync timeout
ptp4l[1143021.648]: port 1: master sync timeout
ptp4l[1143021.649]: port 1: master tx announce timeout
ptp4l[1143022.648]: port 1: master sync timeout
ptp4l[1143023.648]: port 1: master sync timeout
ptp4l[1143023.649]: port 1: master tx announce timeout
ptp4l[1143024.648]: port 1: master sync timeout
^Cptp4l[1143025.574]: caught signal 2

Slave (K2H EVM):

root@keystone-evm:~# ./testptp -g
clock time: 1132.403647743 or Thu Jan  1 00:18:52 1970
root@keystone-evm:~#
root@keystone-evm:~# ./testptp -g
clock time: 1164.634427981 or Thu Jan  1 00:19:24 1970
root@keystone-evm:~# date
Sun Nov 24 22:53:16 UTC 2013
root@keystone-evm:~#
root@keystone-evm:~#
root@keystone-evm:~#
root@keystone-evm:~# ./ptp4l -E -4 -H -i eth0 -s -l 7 -m -q -p /dev/ptp0
ptp4l[1307.131]: selected /dev/ptp0 as PTP clock
ptp4l[1307.133]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[1307.133]: port 1: get_ts_info not supported
ptp4l[1307.135]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1307.135]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1310.452]: port 1: setting asCapable
ptp4l[1310.452]: port 1: new foreign master 0014c2.fffe.5e6541-1
ptp4l[1314.452]: selected best master clock 0014c2.fffe.5e6541
ptp4l[1314.452]: foreign master not using PTP timescale
ptp4l[1314.452]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1315.645]: port 1: delay timeout
ptp4l[1315.645]: path delay         24061      24061
ptp4l[1315.982]: port 1: delay timeout
ptp4l[1315.982]: path delay         24339      24618
ptp4l[1316.451]: master offset -1406657468300530478 s0 freq      +0 path delay     24339
ptp4l[1317.036]: port 1: delay timeout
ptp4l[1317.037]: path delay         24449      24449
ptp4l[1317.451]: master offset -1406657468300533424 s1 freq   -2946 path delay     24449
ptp4l[1318.393]: port 1: delay timeout
ptp4l[1319.347]: port 1: delay timeout
ptp4l[1320.179]: port 1: delay timeout
ptp4l[1321.317]: port 1: delay timeout
^Cptp4l[1321.733]: caught signal 2
root@keystone-evm:~# ./testptp -g
clock time: 1406658797.104442122 or Tue Jul 29 18:33:17 2014
root@keystone-evm:~#

Hi Rex,

 I attach ptp4l program, includes ptp4l_x86 and ptp4l_arm, in case if it related with ptp4l.

8484.ptp4l.7z

Would you also send me the ptp4l program your are testing,including PC and ARM versions? Thanks.

Hi, Tony,

I re-ran it and captured the traffic shown in the attached files.

Rex

5481.itri_capture.7z

6378.ptp4l_m_fail.7z

Hi Rex,

I found out the reason and partially fix it.

There are two kinds of images, one is normal, the other is RT version.

I flashed the normal version image before. Now I flash the RT version image.

If Host(Linux PC)

$sudo ptpd2 -m -i eth0.....................PTP works fine.

If Host(Linux PC)

$sudo ./ptp4l -E -4 -S -i eth0 -l 7 -m -q -p /dev/ptp0......PTP doesn't work. See the attached file.

BTW, can you tell me which image do you flash on EVMK2H?

Hi, Tony,

It does not make sense to me. I am using non-RT kernel. So, I believe something isn't right to your setup. You may want to get it straight with local FAE. The wireshark captures don't show traffic from slave, and may be that is why PTP doesn't work when running ptp4l on server. But, I can not explain why it works for ptpd2, not ptp4l.

I am not sure how you flash different kernels. I hope you are not just changing the kernel image from mounted file system. I would suggest you flash the ubi file rather just replace the kernel in the NAND. For details, please refer to Keystone-II User's Guide Exploring Chapter.

Rex

Hi Rex,

Thanks for your suggestion.

Yes, I flash the ubi file. I flashed keystone-evm-ubifs.ubi at the beginning. Then updated it with keystone-evm-ubifs-rt.ubi.

Would you tell me when or what situation need to use RT version image?

Tony