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
