Re: [Linuxptp-users] Synchronization fault with stmmac

[Mohamed B. <mbe...@ad...>]

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