I have been testing Linux PTP on the Raspberry Pi CM4 for a couple of months. Here's a summary of the problems and workarounds I've found.
Problem 1. PTP support in the kernel isn't available in the latest Raspberry Pi kernel packages. The problem is that the PHYs on the Raspberry Pi 4 and the CM4 have the same id, but only the latter has PTP support. The initial addition of PTP support for the CM4 thus broke software timestamping on the 4, and so was disabled. But they found another way to distinguish these two PHYs (see https://github.com/raspberrypi/linux/issues/5104#issuecomment-1304593383), and so the support has been reenabled and should be available in the next version of the kernel package. In the meantime, the original working kernel packages are still available and can be used. Problem 2. ts2phc logs many "poll returns zero, no events" errors. The problem here is that while the driver is getting the time from the PHC, it has to temporarily disable handling of extts events. See https://github.com/raspberrypi/linux/issues/5231. The best workaround I've found is to use phc2sys -E ntpshm with chrony, and then use the phc2sys -R and -N options to minimize how often this error occurs. These provide more flexibility than dpoll in chrony with the PHC refclock; it helps to make the interval being successive reads of the PHC not be an integral number of seconds. (I was surprised how much work the driver has to do to get the time from the PHC. I was wondering if this is because the hardware supports SyncE.) Problem 3. ts2phc sometimes gives the error "nmea: unable to find utc time in leap second table". I believe this is caused by the bug that was fixed by this commit: https://sourceforge.net/p/linuxptp/code/ci/63fc1ef4fd5e5fc45dd4de3bf27920bb109a4357/ I built new packages for Raspberry Pi OS incorporating this and a few other fixes. Problem 4. ts2phc doesn't work when the network cable is unplugged. The problem here is that the driver does not behave well when there is no carrier: it sometimes ends up delivering 4 pps timestamps in a second. The best workaround I have found is to start and stop the ts2phc service using the link status. Raspberry Pi OS uses dhcpcd to manage the network. So this can be done by using a dhcpcd hook for the CARRIER and NOCARRIER reasons. Problem 5. When starting ts2phc on boot using systemd, it gets the error "interface eth0 does not have a PHC". Similarly, ptp4l can get the error "interface 'eth0' does not support requested timestamping". When I run ethtool -T at this point in the boot process, it shows eth0 as not having a PHC; running it a second time shows eth0 as having the PHC. So there's a short period when a PHC is not attached to the network interface. Is this normal? I had a look at the kernel source, and I could not see why this is happening. Starting ts2phc from a dhcpcd hook avoids this for the server case. For the client case, I added a oneshot service, before ptp4l and timemaster, restarting on failure, which just calls phc_ctl. Problem 6. (Not CM4 specific.) A Windows 11 PTP client ends up with the time 37 seconds off. The problem here is that Windows won't use the UTC offset supplied by the GM unless currentUtcOffsetValid is 1 in the grandmaster settings (even though ptpTimescale is 1). I fixed this by having systemd run pmc with an appropriate set GRANDMASTER_SETTINGS_NP command after starting ptp4l. I suppose problems 4 and 5 should be reported as kernel problems, but I'm not sure of the best place to do it. Should it be the raspberrypi/linux issue tracker or the kernel bugzilla? I've written a guide here: https://github.com/jclark/rpi-cm4-ptp-guide The config files I am using are all here: https://github.com/jclark/rpi-cm4-ptp-guide/tree/main/files I'm relatively new to PTP, so there may well be better ways to do things. Suggestions for improvements would be gratefully received. James
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
