PTP Hardware Clock (PHC) on Apalis iMX6Q

Hello,

So I am running a custom Linux build (Kirkstone) on an Apalis iMX6Q

root@acu3:~# uname -r
6.0.5-rt14-6.1.0-devel+git.040e3123e9d9

On the network I have a Microsemi TP4100 PTP Grandmaster clock. What I am attempting to do, is sync the Linux system clock to this PTP, which should be pretty straight forward.

On my Linux workstation (Ubuntu 22) that is on the same network, the following works like a charm

mmorgan@mmorgan-edev-workstation2:~$ sudo ptp4l -i enp6s0 -m
[sudo] password for mmorgan: 
ptp4l[69154.335]: selected /dev/ptp0 as PTP clock
ptp4l[69154.336]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[69154.336]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[69154.675]: port 1: new foreign master 00b0ae.fffe.08c3cc-2
ptp4l[69158.676]: selected best master clock 00b0ae.fffe.08c3cc
ptp4l[69158.676]: updating UTC offset to 37
ptp4l[69158.676]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[69161.675]: master offset  -18185848 s0 freq  +32752 path delay      2354
ptp4l[69162.675]: master offset  -18186136 s1 freq  +32464 path delay      2354
ptp4l[69163.675]: master offset      -7328 s2 freq  +25136 path delay      2354
ptp4l[69163.675]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[69164.675]: master offset        608 s2 freq  +30874 path delay      2354
ptp4l[69165.675]: master offset       1751 s2 freq  +32199 path delay      2392
ptp4l[69166.675]: master offset       2073 s2 freq  +33046 path delay      2390
ptp4l[69167.675]: master offset       1443 s2 freq  +33038 path delay      2390
ptp4l[69168.675]: master offset        682 s2 freq  +32710 path delay      2392
ptp4l[69169.675]: master offset        625 s2 freq  +32858 path delay      2403
ptp4l[69170.675]: master offset       -244 s2 freq  +32176 path delay      2493
ptp4l[69171.675]: master offset        322 s2 freq  +32669 path delay      2415
ptp4l[69172.675]: master offset        169 s2 freq  +32613 path delay      2418
ptp4l[69173.675]: master offset       -438 s2 freq  +32056 path delay      2420
ptp4l[69174.675]: master offset        441 s2 freq  +32804 path delay      2420
ptp4l[69175.675]: master offset       -106 s2 freq  +32389 path delay      2579

You can see the frequency adjusting as expected and the master offset is nearing zero. I am assuming that the Yocto built Linux should work in essentially the same way. However,

root@acu3:~# ptp4l -i eth0 -m
ptp4l[171761.198]: selected /dev/ptp0 as PTP clock
ptp4l[171761.214]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[171761.217]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[171762.602]: port 1: new foreign master 00b0ae.fffe.08c3cc-2
ptp4l[171766.602]: selected best master clock 00b0ae.fffe.08c3cc
ptp4l[171766.608]: updating UTC offset to 37
ptp4l[171766.610]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[171768.602]: master offset -28299683372754529 s0 freq      +0 path delay  32052307
ptp4l[171769.601]: master offset -28299684550743588 s0 freq      +0 path delay 210042759
ptp4l[171770.602]: master offset -28299685554201248 s0 freq      +0 path delay 213499027
ptp4l[171771.601]: master offset -28299686667470060 s0 freq      +0 path delay 326769231
ptp4l[171772.603]: master offset -28299687667471451 s0 freq      +0 path delay 326769231
ptp4l[171773.602]: master offset -28299688610834957 s0 freq      +0 path delay 270134129
ptp4l[171774.602]: master offset -28299689610836349 s0 freq      +0 path delay 270134129
ptp4l[171775.602]: master offset -28299690610834956 s0 freq      +0 path delay 270134129
ptp4l[171776.603]: master offset -28299691618586828 s0 freq      +0 path delay 277884609
ptp4l[171777.602]: master offset -28299692618585436 s0 freq      +0 path delay 277884609
ptp4l[171778.603]: master offset -28299693618586827 s0 freq      +0 path delay 277884609
ptp4l[171779.602]: master offset -28299694618585435 s0 freq      +0 path delay 277884609
ptp4l[171780.603]: master offset -28299695618586827 s0 freq      +0 path delay 277884609
ptp4l[171781.602]: master offset -28299696618585434 s0 freq      +0 path delay 277884609
ptp4l[171782.603]: master offset -28299697531954762 s0 freq      +0 path delay 191252545

As you can see, the locking never occurs. I am assuming that this is because ptp4l is unable to manipulate the PHC on the PHY. I have tried various different configurations for ptp4l and profiles and nothing works.

What am I missing here, is there some device tree configuration needed to manipulate the PHC. I have ensured that the gpsd, ntpd, and chronyd daemons are not running. I have the following in my kernel config,

CONFIG_NET_PTP_CLASSIFY=y
# PTP clock support
CONFIG_PTP_1588_CLOCK=y
CONFIG_PTP_1588_CLOCK_OPTIONAL=y
# end of PTP clock support
CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_PHYLIB=y
CONFIG_SWPHY=y
# CONFIG_LED_TRIGGER_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_MICREL_PHY=y
CONFIG_MICROCHIP_PHY=m
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
# PPS clients support
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=y
CONFIG_PPS_CLIENT_GPIO=y
# PPS generators support

I am at a complete loss here and any help would be greatly appreciated.

OK, so I was actually able to solve this issue myself. I stumbled across a different article that talked about how GPIO_16 is routed to both IEEE 1588 and SPDIF which then lead me here Ethernet/Network (Linux)

So long story short, mux the proper pin, since apparently SPDIF is default for the Apalis device tree

&iomuxc {
    pinctrl-0 = <
        ....
        &pinctrl_ptp 
        ....
    >;
    ....
    pinctrl_ptp: ptpgrp {
		fsl,pins = <
			MX6QDL_PAD_GPIO_16__ENET_REF_CLK ((1<<30) | 0x1b0b0)
		>;
	};
    ....
};

and all is well.