This is a custom ZynqMP platform using petalinux 2018.2. The driver is Cadence's MACB driver. There are three network ports. The PHY is Vitesse, but timestamping in the PHY is turned off. There is a weird MDIO topology where every ethernet port lives on the same 8-address phy, which is attached to eth0 - but this shouldn't matter. I had to modify the macb driver to handle the phy topology because xilinx told me it would work but it didn't.
Additionally, in the driver, I noticed a function where it was supposed to get the TSU clock frequency from the device tree, but that was never getting called. I modified the probe() to call that function. Then, instrumenting the driver, I see the TSU clock frequency is not what I put in there (I put "tsu_clk=<250000000>" into the device tree, but I get out 12.5MHz using the kernel's clk_get_*() function). I'm not sure the TSU registers in this platform are working as they should be: I have a separate custom ZynqMP platform using petalinux 2018.2, and it works fine... the platform is completely different, though, save for the fact that it is ZynqMP. One thing I'm noticing that is different between the two ZynqMP systems is the TSU counter register: Even without PTP running, on the "working" system, I can read the TSU seconds counter register manually using peek-type interface, and see it increment roughly once a second. The TSU nanoseconds jump around a bit, as you would expect they would if you were querying by hand once a second. However, on the bad system, the TSU seconds counter is incrementing by leaps and bounds every time I query it (tens of thousands of units per second). The nanoseconds counter is always zero. It's as if the platform is not sane. Unfortunately, I think ntp is looking like a pretty good option at this point. On Tue, Jun 23, 2020 at 10:54 PM Richard Cochran <richardcoch...@gmail.com> wrote: > On Mon, Jun 22, 2020 at 06:08:53PM -0400, Aaron Biver wrote: > > This should be running with a 250MHz clock fed to a Cadence macb driver > > through an entry in the device tree. > > What platform, kernel, and driver are you using? > > > The macb driver is doing the > > timestamping, supposedly. PHY timestamping is turned off in the kernel, > in > > the below examples, I believe phc2sys was not running, or if it was, it > was > > most certainly waiting for calibration. > > > > Mostly, on the failing slave, I get: > > > > # ptp4l -i eth0 -m -s -f ptp4l.conf > > ptp4l[1848.892]: selected /dev/ptp0 as PTP clock > > ptp4l[1848.893]: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[1848.893]: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[1848.893]: port 1: link up > > ptp4l[1849.809]: port 1: new foreign master 0200c0.fffe.a80328-1 > > ptp4l[1853.908]: selected best master clock 0200c0.fffe.a80328 > > ptp4l[1853.908]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > > It looks like the port is staying in the UNCALIBRATED state. It will > not progress until the port performs a path/peer delay measurement. I > would look to see why this failure to complete. > > Thanks, > Richard >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
