> -----Original Message----- > From: Matthew Via [mailto:v...@matthewvia.info] > Sent: Friday, August 09, 2019 8:07 AM > To: linuxptp-users@lists.sourceforge.net > Subject: [Linuxptp-users] ptp4l with freescale dpaa2 ethernet > > 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:
This is requesting hardware timestamping. > 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 This usually indicates the driver is not sending the Tx timestamp back to the stack, especially if you increase it past a few milliseconds. > 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? But skb_tstamp_tx is for software timestamping, if I recall correctly. > > 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. Try using the software timestamping option for ptp4l, and see if that works first. (Should be -S) Thanks, Jake > > Thanks, Matthew > -- > Matthew Via > v...@matthewvia.info > > > _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
