Hi Richard & Jake, //Richard > On Tue, Mar 18, 2014 at 09:31:19AM +0100, Mohamed Belaouad wrote: > > > The core registers of the IP are the same. To me, everything seems > > fine with the registers addresses related to the > > reception/transmit/timestamping. > > Did you consider that the input clock to the time function within the > IP core might be at a different frequency than the driver expects? >
Yes, I thought about it at one point but was too much focused on the driver side that I forgot! Thanks for reminding me, I will investigate. >From the first test I did (running ptp4l to get the PC time then stopping it), >the board ptp time seems to run slower than the PC time. While 5 minutes >elapsed on the PC, 2/3min only do on the board. > > Yes, I also guess it is coming from the driver. I just want to make > > sure that it is not a misconfiguration on my settings. > > From the git log of drivers/net/ethernet/stmicro/stmmac it appears > that people have been using linuxptp with this driver and "normal" > hardware. I would not discount the possibility that the Altera > implementation is somehow buggy in hardware. > That's true even though I saw a not yet accepted patch of someone working with the Cyclone V and linuxptp. I may contact him if I don't find the cause. > > I think it is time to dig into the driver again (>,<). > > The first step is to see whether the basic clock operations work or > not by using the testptp program. I already did that yesterday. Everything seems fine on this side, set/get/shift time and adjust frequency. //Jake > The error you are seeing is a clock sanity check. The clock is running > slower than expected, or is jumping backwards. > > This could be caused by timing changes in the chip, though that is > somewhat unlikely. > > Most likely you have a driver bug, misconfiguring the hardware and > causing a jump. I would investigate the adjust frequency call, and the > adjust time call.. It's also possible your timestamping code is > incorrect (ie: not reading the values out correctly). The read & write timestamps are correct according to the prints I added in ptp4l and the packets in wireshark. > My guess is some > sort of overflow, possibly an overflow in the adjfreq's max ppb. My > reasoning for this, is because it keeps on getting more negative offset. > It will try to correct this by applying a large slew to the clock, which > in turn has a negative impact on time, because it overflowed. I would > investigate this first. > Adjust time seems fine since the board ptp clock sets at the PC clock. The adjust frequency however is quite strange. Printing the ppb passed to the driver gives +32,767,999 (corresponding to the -32,767,999 of the ptp4l log). After that, ptp4l still displays -32,767,999 so I guess something goes wrong on the driver/hardware side. It may be as Richard mentioned a different input clock or as you do with an overflow. > You can use Documentation/ptp/testptp.c program to sanity check these > ops. Done as mentioned. One strange thing which comes back is that the +32,767,999 passed to the driver with testptp gives an "okay". Actually, I just noticed the high level ptp driver always returns 0 even though the low level parts of it may return an error! I will get into that. There are so many unknowns that it may come from everywhere :). Thanks, Mohamed ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Linuxptp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-users
