Re: [Linuxptp-users] Hardware timestamping does not work

[Jan D. <jan...@gm...>]

Hi Richard,

2016-11-05 20:26 GMT+01:00 Richard Cochran <ric...@gm...>:

> On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> > What can I do to find out what the problem is?
>
> I guess that either the imx6 driver is broken by design, or that it is
> mis-configured on your board.  I would verify that the input clock to
> the time stamping unit is the same frequency as the driver expects, or
> if the driver detects the frequency, that this is correct.
>
> You will probably have to dig into the data sheet and into the driver
> source.
>
> Here is one simple sanity check for the clock.  Run
>
>   testptp -g; sleep 60; testptp -g
>
> and verify that the difference between the two outputs is about 60
> seconds.
>
>
The sanity check on the eval board seems ok:

$ ./a.out -f 0; ./a.out -g; sleep 60; ./a.out -g
frequency adjustment okay
clock time: 1478391262.040584932 or Sun Nov  6 00:14:22 2016
clock time: 1478391322.082633172 or Sun Nov  6 00:15:22 2016

The difference is 60.04204824 seconds so I have to check my PC:

$ ./a.out -f 0; ./a.out -g; sleep 60; ./a.out -g
frequency adjustment okay
clock time: 1478445034.316473288 or Sun Nov  6 16:10:34 2016
clock time: 1478445049.319217444 or Sun Nov  6 16:10:49 2016

The difference is 15.002744156 seconds. Ouch!

I guess I have to check the drivers used on my PC or is there anything else
I can do here?

Thanks,
Jan

2016-11-05 20:26 GMT+01:00 Richard Cochran <ric...@gm...>:

> On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> > I am using a Debian workstation and a i.MX6UL evaluation board running
> on a
> > Linux build with Yocto. According to ethtool -T eth0 both systems support
> > PTP hardware timestamping.
>
> ...
>
> > ptp4l[26435.632]: master offset 4399753214 s2 freq +32767999 path delay
> > -277121915
> >
> > It is not getting better after some minutes. Master offset is alway
> > increasing and freq is always the same value.
>
> The frequency is locked here at maximum offset, and the device is not
> converging.  This is most likely a driver or HW problem on the imx6.
>
> > Workstation:
> >
> > $ uname
> > -a
> >
> > Linux polaris 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
> > x86_64 GNU/Linux
> >
> > $ lspci
> > 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
> > I219-V (rev 31)
>
> If this i219 is working with the igb driver, and the driver shows HW
> time stamping enabled, then it should work well.  So this isn't the
> problem, most likely.
>
> > Eval board:
> >
> > $ uname -a
> > Linux imx6ulevk 4.1.15-2.0.0+gb63f3f5 #1 SMP PREEMPT Wed Nov 2 21:42:19
> CET
> > 2016 armv7l armv7l armv7l GNU/Linux
>
> I have never tested the ptp driver for the imx6, and I am highly
> suspicious of Freescale "quality" drivers.
>
> > What can I do to find out what the problem is?
>
> I guess that either the imx6 driver is broken by design, or that it is
> mis-configured on your board.  I would verify that the input clock to
> the time stamping unit is the same frequency as the driver expects, or
> if the driver detects the frequency, that this is correct.
>
> You will probably have to dig into the data sheet and into the driver
> source.
>
> Here is one simple sanity check for the clock.  Run
>
>   testptp -g; sleep 60; testptp -g
>
> and verify that the difference between the two outputs is about 60
> seconds.
>
> > Or am I misinterpreting the output?
>
> Looks like a problem on the imx6.  You can run a test between the i219
> and any other linux PC (even if that PC only has SW time stamping) in
> order to exclude a problem with the i219.
>
> > What does the "freq" value mean?
>
> This is the adjustment in parts per billion.  Normally the magnitute
> of this value should never exceed 100 ppm or so.
>
> HTH,
> Richard
>