Hi Wolfgang, I was able to make the ptp4l work with my DP83640 + Zedboard setup.
I went through your comments about the dependency on where we declare skb_tx_timestamp(skb) function. I experimented some locations and the following worked (Was trying to put the function just over the nr_frags loop earlier. Then later changed it to the new location above the if condition) Thanks for sharing your documents. They were of great help. Xilinx_emacps.c file: nr_frags = skb_shinfo(skb)->nr_frags + 1; if (nr_frags > lp->tx_bd_freecnt) { netif_stop_queue(ndev); /* stop send queue */ return NETDEV_TX_BUSY; } skb_tx_timestamp(skb); if (xemacps_clear_csum(skb, ndev)) { kfree(skb); return NETDEV_TX_OK; } bd_tail = lp->tx_bd_tail; cur_p = &lp->tx_bd[bd_tail]; frag = &skb_shinfo(skb)->frags[0]; skb_tx_timestamp(skb); for (i = 0; i < nr_frags; i++) { if (i == 0) { len = skb_headlen(skb); mapping = dma_map_single(&lp->pdev->dev, skb->data, len, DMA_TO_DEVICE); Regards, Anmol From: Wolfgang Hennig <when...@xia.com> Sent: Friday, April 2, 2021 12:09 AM To: Dhanuka, Anmol <a-dhan...@ti.com>; linuxptp-users@lists.sourceforge.net Subject: Re: [EXTERNAL] Re: [Linuxptp-users] ptp4l gives tx timestamp polling timeout issue Hi Anmol, I never used Petalinux since I found it too limiting and everything was packaged into one bootfile. So I used xillinux instead: http://xillybus.com/xillinux In any case you would probably have to update the drivers. I will send the versions of emacps.c and dp83460.c I used, hope that helps (separate email, not sure if you can receive zip files). You will have to find the equivalent files in the official distribution and compare. I can't really answer your first 2 questions. For 3, I'm not sure about the SW timesamping (no need for any change?) but I used these options for HW timestamping (SoCe is a 3rd party FW TSU implementation): Kernel options Option Zynq TSU DP83640 TSU SoCe TSU PTP_1588_CLOCK y y y CONFIG_PPS y y Y CONFIG_NETWORK_PHY_TIMESTAMPING N (ignored) y N (1) CONFIG_XILINX_PS_EMAC_HWTSTAMP y N N CONFIG_SOCE_PS_EMAC_HWTSTAMP N N y CONFIG_NET_VENDOR_NATSEMI y Y CONFIG_NATIONAL_PHY y Y CONFIG_DP83640_PHY y N (2) (1) supposedly only needed for DP83640 (2) when turned on, 2 conflicting ptp devices. When turned off and (1) on or off, one ptp device, but "driver change HW settings error" Hope that helps, Wolfgang On 3/31/2021 8:56 AM, Dhanuka, Anmol wrote: Hi Wolfgang, Thank you for your quick response. I was not able to check with your SD card image as the access to that link is blocked in our company's network. The DP83640 EVMs we are using are different from one you had used as per the document. So I doubt whether the SD card image can be used as it is. I followed the steps mentioned in the shared document. However I am seeing similar issues as before I am using Petalinux 2016.2 version with Kernel version 4.4. This has option for emacps driver. I have enabled emacps and disabled the macb driver. I have a few questions: 1. The configuration for one-step sync timestamp insertion in DP83640 (Page 5, register 0x0016, bit 15) is getting cleared on running ptp4l. Is there some option I need to provide in the ptp4l command to run one-step mode? 2. Can you please clarify how is ptp4l fetching the hardware timestamps from the PHY? Is it polling for some event hardware interrupts to read the timestamp registers of PHY? Want to understand if I missed routing some signals in Vivado. 3. If I want to enable software based timestamping options as well, which kernel options need to be enabled? Following are the timestamping capabilities indicated with current setup. They seem to be same as the ones in your post Time stamping parameters for eth0: 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) one-step-sync (HWTSTAMP_TX_ONESTEP_SYNC) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) Regards, Anmol From: Wolfgang Hennig <when...@xia.com><mailto:when...@xia.com> Sent: Tuesday, March 30, 2021 10:32 PM To: Dhanuka, Anmol <a-dhan...@ti.com><mailto:a-dhan...@ti.com>; linuxptp-users@lists.sourceforge.net<mailto:linuxptp-users@lists.sourceforge.net> Subject: [EXTERNAL] Re: [Linuxptp-users] ptp4l gives tx timestamp polling timeout issue Hi Amol, It has been a long time since I used this. I think I saw that error also at some point. I looked through my notes but could not find any detail on it. I attach a summary that may give a bit more detail that the old thread. I later upgraded the Zynq to Ubuntu 18 and found that Xilinx removed the emacps driver at some point; the last kernel to include it was release 17.4 and things worked ok with that. While unused, the functionality is still included in the system we released publicly. An SD card image is here: https://www.mediafire.com/file/u24pn07ggbjvw69/PN_U18_8GB_STD_022226.img/file You might be able to boot your Zedboard with this; I used the MicroZed. I can also provide the updated kernel functions upon request. Best regards, Wolfgang On 3/29/2021 6:09 AM, Dhanuka, Anmol via Linuxptp-users wrote: Hi, I am using TI DP83640 PHY with Xilinx Zedboard (with Ubuntu 16.04 running on it) I have followed the steps mentioned in the following mail thread to configure the Xilinx_emacps drivers to detect HW timestamps from PHY: https://linuxptp-users.narkive.com/i5cijFRH/linuxptp-on-zynq-with-dp83640 However on running the following command "ptp4l -P -i eth0 -f ./gPTP.cfg -m", I get the following error: ptp4l[265621.845]: selected /dev/ptp0 as PTP clock ptp4l[265621.900]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[265621.900]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[265623.000]: timed out while polling for tx timestamp ptp4l[265623.001]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[265623.001]: port 1: send peer delay request failed ptp4l[265623.001]: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[265639.120]: port 1: FAULTY to LISTENING on FAULT_CLEARED I tried increasing the "tx_timestamp_timeout" to 10ms, 100ms. But it is not resolving the error Am I missing any step? Regards, Anmol _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net<mailto:Linuxptp-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/linuxptp-users -- Wolfgang Hennig, Ph.D. XIA LLC 31057 Genstar Rd. Hayward CA 94544 -- Wolfgang Hennig, Ph.D. XIA LLC 31057 Genstar Rd. Hayward CA 94544
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users