Using imx28 ENET PTP 1588 capture register - we found an intermittent problem:
Mode: 1e9 counting mode, 40MHz clockrate, external pps connected to event capture input
Intermittent, we read out a value from capture register which is wrong by 128xxxxxx nanosecs.
(workaround - ignore timestamps with impossible values)
To round it up, I´d like to repeat the other problems already found / solved:
Another issue already addressed is that we need (with our configuration) a delay by 72ns between setting capture bit in ctrl register and readout of atime.
(a workaround could be to write ctrl register 4 times minimum)
Anyway - reading out the nanosecs stamp can be time consuming using this scheme.
Further we observed that compare events <70ns dont´t trigger the event output / generate an irq.
(workaround - avoid compare values below <100ns)
The example used in imx28 datasheet is based on a 125MHz input clock which is not possible.
Up to now I have no clue how this speed can be accomplished - because an integer divide from 480MHz PLL doesn´t fit.
So we are using /12 and 40MHz clock to operate at nominal speed with 25ns increments - and use the alternate increment+freq for nanosecs correction.
Maybe the mentioned drawbacks don´t exist if running with higher speed.
The linux ptp driver for mx6 was written in a different way - using free-running 32bit counter.
Maybe people involved into writing that had some knowledge about ptp errata.
I posted this on imx6 group - because this device has similar PTP/ENET circuitry.
Did you observe similar behavior ?
Have you heard of some errata describing this ?