> -----Original Message----- > From: A [mailto:aaron.bi...@gmail.com] > Sent: Thursday, March 15, 2018 12:09 PM > To: linuxptp-users@lists.sourceforge.net > Subject: [Linuxptp-users] Trouble with getting timestamping to work on Xilinx > Ultrascale board > > I've got a Xilinx ZCU102 with a macb driver from xilinx's 2017.3 branch which > has > 4.9 linux kernel and PTP support). > I believe I've got the necessary bits built into the kernel (kernel options > shown > below). > > I'm trying to run as a slave, but it looks like its not working. I'd > appreciate any and > all advice, as I'm at wits end. > > ptp4l -i eth0 -m -s > ptp4l[13.741]: selected /dev/ptp0 as PTP clock > ptp4l[13.741]: driver changed our HWTSTAMP options > ptp4l[13.741]: tx_type 1 not 1 > ptp4l[13.741]: rx_filter 1 not 12 > ptp4l[13.742]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[13.742]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[21.640]: driver changed our HWTSTAMP options > ptp4l[21.640]: tx_type 1 not 1 > ptp4l[21.640]: rx_filter 1 not 12 > ptp4l[21.640]: selected best master clock 000a35.fffe.002201 > ptp4l[29.520]: driver changed our HWTSTAMP options > ptp4l[29.520]: tx_type 1 not 1 > ptp4l[29.520]: rx_filter 1 not 12 > ptp4l[29.520]: selected best master clock 000a35.fffe.002201 > ptp4l[29.688]: port 1: new foreign master 003064.fffe.1982cd-1 > ptp4l[33.786]: selected best master clock 003064.fffe.1982cd > ptp4l[33.786]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE >
It looks like you're never entering the calibrated state, which should occur when the event MASTER_CLOCK_SELECTED occurs... This event occurs when the servo becomes locked, which depends on the servo in question. The default pi servo appears to handle this with a few possible checks: first it's possible the driver is going backwards somehow, so that servo updates never return from unlocked, (pi.c:87) second it's possible the frequency estimate is always failing (pi.c:95) This could be occurring if the local clock is not even running (or running very slow) Take a look at the master offsets: > ptp4l[34.810]: master offset 651262704418 s0 freq +0 path delay 0 > ptp4l[35.834]: master offset 649867375548 s0 freq +0 path delay 346072539 > ptp4l[36.859]: master offset 648818118960 s0 freq +0 path delay 346072539 > ptp4l[37.883]: master offset 647714697182 s0 freq +0 path delay 400129313 > ptp4l[38.908]: master offset 646665287635 s0 freq +0 path delay 400129313 > ptp4l[39.933]: master offset 645623541219 s0 freq +0 path delay 392486789 > ptp4l[40.957]: master offset 644575797496 s0 freq +0 path delay 390867813 > ptp4l[41.982]: master offset 643526460652 s0 freq +0 path delay 390867813 > > Notice how the offsets each gradually get smaller and smaller, 651...., 649..., 648..., 647.... 646...., 645..., 644..., etc... So this value is displayed in nanoseconds, which if we convert shows that the offset is 651s, then nearly 650 seconds, then 648 seconds etc. The default sync rate should be approximately 1 second. This means that once every sync packet the local clock is almost exactly 1 second closer to the remote master clock. That seems very suspicious, as it basically means our local clock did almost no movement, while the remote clock did around 1 second. One way to test this theory is to use the tools/testing/selftests/ptp/testptp.c tool, you can read the time, sleep for some long length, (say 10 seconds), and read the time again. Make sure the difference between the time is actually 10 seconds. Obviously this is a pretty rough guess but it seems plausible that the clock is running too slow here. I can't really offer any further debugging advice since I don't have the source code. Thanks, Jake ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
