AM4378: Error when using hardware timestamp to achieve IEEE 1588

Hello Luke,

For future readers, Luke used this command to generate the error in his initial post:
# ptp4l -i eth0 -m -H

QUESTIONS

Are you using CPSW or PRU Ethernet ports?

Is this on a TI EVM or a custom board?

ADDITIONAL RESOURCES

You can find more documentation about testing ptp4l in the Linux CPSW driver documentation (I suggest using Ctrl-F to search for ptp4l). We also have information in the Industrial Protocols PTP documentation. The Industrial Protocols documentation should answer your question about when the timestamp is captured.

Thread PTP issue might have some useful hints for you.

Regards,

Nick

Hi Nick,

We use CPSW and custom board.
I'v already check the TX/RX for hardware is support (By using ethtool command)

The error log shows that "increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug"
Regarding 1588, do we need to do any additional settings outside of TI's SDK to enable hardware timestamp use?


Many thanks.

Best Regards,
Luke Chen

Hi,

Could you post how you are calling the ptp4l? 

Answering a question from above in case the ptp.cfg is still open. The defined in the Documentation link to the Linux CPSW driver  

You can create this file in the /home/root on the board using an editor.

[global]
tx_timestamp_timeout     400

Please try this and see if you still are receiving the timeout message.

Best Regards,

Schuyler

Hi Schuyler,

I've generate the ptp.cfg file in /home/root.

And use  "ptp4l -E -2 -H -i eth0 -l 6 -m -q -p /dev/ptp0 -f ptp.cfg" command.

The Error is still occured.

Could you teach me what else I can try?

Many Thanks.

Btw, 

I'd see that in the section about SFD in the following link. The precision value is 10us~10ns.
I'd like to know that why the range is so large. Could you please tell me?

e2e.ti.com/.../how-to-implement-ieee-1588-time-stamping-in-an-ethernet-transceiver

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

root@SAMPLE:~# cat ptp.cfg
[global]

tx_timestamp_timeout 400

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

root@SAMPLE:~# ptp4l -E -2 -H -i eth0 -l 6 -m -q -p /dev/ptp0 -f ptp.cfg
ptp4l[1048.422]: selected /dev/ptp0 as PTP clock
ptp4l[1048.501]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1048.502]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1055.962]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1055.962]: selected best master clock a81087.fffe.d6382b
ptp4l[1055.962]: assuming the grand master role
ptp4l[1057.363]: timed out while polling for tx timestamp
ptp4l[1057.363]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[1057.363]: port 1: send sync failed

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

Best Regards,

Luke Chen

Hi,

It is possible that the SDK is too old. Could you try the latest SDK? There was a commit to a later kernel version related to fixing tx timestamp output.

What is the link speed?

Best Regards,

Schuyler

Hi Schuyler,

1.
Following are my logs from master and slave after change the SDK version.

Does this means "received DELAY_REQ without timestamp" my hardware timestamp doesn't work?

Could you tell me how to fix of how to implement it?  Thanks.

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

root@MCM204:~# ptp4l -E -2 -H -i eth0 -l 6 -m -q -p /dev/ptp0 -f ptp.cfg
ptp4l[993.472]: selected /dev/ptp0 as PTP clock
ptp4l[993.539]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[993.540]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[999.861]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[999.861]: selected best master clock a81087.fffe.d6382b
ptp4l[999.861]: assuming the grand master role
ptp4l[1004.146]: port 1: received DELAY_REQ without timestamp
ptp4l[1026.734]: port 1: received DELAY_REQ without timestamp
ptp4l[1049.592]: port 1: received DELAY_REQ without timestamp
ptp4l[1071.887]: port 1: received DELAY_REQ without timestamp
ptp4l[1095.090]: port 1: received DELAY_REQ without timestamp

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

root@MCM204:~# ptp4l -E -2 -H -i eth0 -l 6 -m -q -p /dev/ptp0 -f ptp.cfg -s
ptp4l[999.685]: selected /dev/ptp0 as PTP clock
ptp4l[999.763]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[999.767]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[999.858]: port 1: new foreign master a81087.fffe.d6382b-1
ptp4l[1000.857]: port 1: received SYNC without timestamp
ptp4l[1001.857]: port 1: received SYNC without timestamp
ptp4l[1002.857]: port 1: received SYNC without timestamp
ptp4l[1003.857]: port 1: received SYNC without timestamp
ptp4l[1003.858]: selected best master clock a81087.fffe.d6382b
ptp4l[1003.858]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1004.542]: timed out while polling for tx timestamp
ptp4l[1004.542]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[1004.542]: port 1: send delay request failed
ptp4l[1004.542]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

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

2.

And for the previous question "What is the link speed?"

Sorry, I don't know which component speed do you mean? Could you say more detail? Many thanks.
For the previous post I asked about the SFD precision range is bigger than we thought. So is it caused by the link speed of a certain component is different?
Thanks.

Best Regards,
Luke Chen