Hi, I am trying to get ptp4l working on an NXP Bluebox and the dpaa2 ethernet
driver. The kernel I'm using appears to have code for hardware timestamping in
the ethernet driver, though I needed to pull in patches from a more recent
kernel to add support for ethtool to set the timestamping options. The
relevent ethtool and dpaa2 drivers can be seen
https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
and
https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/freescale/dpaa2/dpaa2-ethtool.c
.
ethtool -T eno0 shows:
Time stamping parameters for eno0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
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)
all (HWTSTAMP_FILTER_ALL)
But when I fire up ptp4l with `ptp4l -i eno0 -H -m`, I get:
ptp4l[516.260]: selected /dev/ptp0 as PTP clock
ptp4l[516.271]: driver changed our HWTSTAMP options
ptp4l[516.271]: tx_type 1 not 1
ptp4l[516.271]: rx_filter 1 not 12
ptp4l[516.271]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[516.271]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[522.612]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[522.612]: selected best master clock 00049f.fffe.052fee
ptp4l[522.612]: assuming the grand master role
ptp4l[523.613]: timed out while polling for tx timestamp
ptp4l[523.614]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[523.614]: port 1: send sync failed
ptp4l[523.615]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[539.634]: driver changed our HWTSTAMP options
ptp4l[539.634]: tx_type 1 not 1
ptp4l[539.635]: rx_filter 1 not 12
ptp4l[539.635]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[546.345]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[546.346]: selected best master clock 00049f.fffe.052fee
ptp4l[546.346]: assuming the grand master role
ptp4l[547.347]: timed out while polling for tx timestamp
ptp4l[547.347]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[547.348]: port 1: send sync failed
ptp4l[547.348]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[563.367]: driver changed our HWTSTAMP options
ptp4l[563.367]: tx_type 1 not 1
ptp4l[563.367]: rx_filter 1 not 12
ptp4l[563.367]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[569.932]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
Everything I've read suggests that this is usually the driver not using
skb_tstamp_tx in the right place, or in a buggy manner -- I've tried increasing
the timeout to over 1000 ms, and that had no effect. This happens consistently
for each packet though. I added a netdev_info call in dpaa2-eth.c where it
calls skb_tstamp_tx and I consistently get good looking timestamps each time
ptp4l tries to send. Does anyone have any idea what might not be working here?
Additionally, I added a skb_tx_timestamp call in the transmit path and the
relevent software timestamping flags to the ethtool interface in the hopes that
I could at least use software timestamping, and I get the exact same output
from ptp4l as above (with the -S option).
If anyone has any guidance on how to getting either hardware or software
timestamping working, I would appreciate it.
Thanks, Matthew
--
Matthew Via
[email protected]
_______________________________________________
Linuxptp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
