TSU timer is not incrementing correctly

[hendog82]

When using the Genesys ZU-3EG, I am seeing weird behavior in the tsu_timer registers of the Zynq Ultrascale that uses the DP83867CRRGZR Ethernet PHY.
According to the register reference, the tsu_timer_nsec register should hold the nanoseconds timer, and the tsu_timer_sec register (and tsu_timer_msb_sec) should hold the seconds timer.
However, what I am seeing is that the tsu_timer_nsec register remains empty (0x00000000) and the tsu_timer_sec register contains a combination of seconds and nanoseconds. For example, if I poll the tsu_timer_sec register (approximately) once every second, I see an output similar to the following: 
root@program:~# devmem 0xFF0B01D0
0x7B6A6024
root@program:~# devmem 0xFF0B01D0
0x8A317732
root@program:~# devmem 0xFF0B01D0
0x99928EAA
root@program:~# devmem 0xFF0B01D0
0xA8B6040C
root@program:~# devmem 0xFF0B01D0
0xB79CB402
These values also match the values read from emio_enet0_enet_tsu_timer_cnt . 
 
When I run ptp4l, the zynq clock fails to synchronize with the grand master clock, and I see similar bahavior on the tsu_ptp_tx and tsu_ptp_rx registers (_sec register increments by ~ 0x10000000 every second, and _nsec register remains empty).
 
I also see the following output from ptp4l: 
ptp4l : selected /dev/ptp0 as PTP clock
ptp4l : port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l : port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l : port 1: link up
ptp4l : port 1: new foreign master b42e99.fffe.a78faa-1
ptp4l : selected best master clock b42e99.fffe.a78faa
ptp4l : port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l : master offset 7632232494850134543 s0 freq 0 path delay 72933377
ptp4l : master offset 7632232493657728990 s0 freq 0 path delay 265294060
ptp4l : master offset 7632232492740700486 s0 freq 0 path delay 182310568
ptp4l : master offset 7632232491740612991 s0 freq 0 path delay 182310568
ptp4l : master offset 7632232490730573848 s0 freq 0 path delay 192324465
ptp4l : master offset 7632232489720530206 s0 freq 0 path delay 202338362
ptp4l : master offset 7632232488689645026 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232487689617780 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232486720382219 s0 freq 0 path delay 202338362
ptp4l : master offset 7632232485689481040 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232484689414294 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232483688347841 s0 freq 0 path delay 234193504
ptp4l : master offset 7632232482688317095 s0 freq 0 path delay 234193504
 
I can use wireshark to inspect the packets being sent by the host computer to the ZynqMP, and the time sent to the Zynq is correct.
 
It seems like all of the TSU timers are filling the "seconds" registers with the 8 LSB of seconds and 24 MSB of nanoseconds, and the rest of "seconds" spill over to the tsu_timer_msb_sec register. 
 
What is causing these registers to be stored / increment incorrectly?

[JColvin]

Hi @hendog82,

I have asked some other engineers for their input on this.

Thank you,
JColvin

[elodg]

@hendog82, give us some info on your setup. What Petalinux version are you using and what kernel and apps recipes you configured for ptp?

[shravya]

On 6/3/2020 at 9:19 PM, hendog82 said:

When using the Genesys ZU-3EG, I am seeing weird behavior in the tsu_timer registers of the Zynq Ultrascale that uses the DP83867CRRGZR Ethernet PHY.
According to the register reference, the tsu_timer_nsec register should hold the nanoseconds timer, and the tsu_timer_sec register (and tsu_timer_msb_sec) should hold the seconds timer.
However, what I am seeing is that the tsu_timer_nsec register remains empty (0x00000000) and the tsu_timer_sec register contains a combination of seconds and nanoseconds. For example, if I poll the tsu_timer_sec register (approximately) once every second, I see an output similar to the following: 
root@program:~# devmem 0xFF0B01D0
0x7B6A6024
root@program:~# devmem 0xFF0B01D0
0x8A317732
root@program:~# devmem 0xFF0B01D0
0x99928EAA
root@program:~# devmem 0xFF0B01D0
0xA8B6040C
root@program:~# devmem 0xFF0B01D0
0xB79CB402
These values also match the values read from emio_enet0_enet_tsu_timer_cnt . 
 
When I run ptp4l, the zynq clock fails to synchronize with the grand master clock, and I see similar bahavior on the tsu_ptp_tx and tsu_ptp_rx registers (_sec register increments by ~ 0x10000000 every second, and _nsec register remains empty).
 
I also see the following output from ptp4l: 
ptp4l : selected /dev/ptp0 as PTP clock
ptp4l : port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l : port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l : port 1: link up
ptp4l : port 1: new foreign master b42e99.fffe.a78faa-1
ptp4l : selected best master clock b42e99.fffe.a78faa
ptp4l : port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l : master offset 7632232494850134543 s0 freq 0 path delay 72933377
ptp4l : master offset 7632232493657728990 s0 freq 0 path delay 265294060
ptp4l : master offset 7632232492740700486 s0 freq 0 path delay 182310568
ptp4l : master offset 7632232491740612991 s0 freq 0 path delay 182310568
ptp4l : master offset 7632232490730573848 s0 freq 0 path delay 192324465
ptp4l : master offset 7632232489720530206 s0 freq 0 path delay 202338362
ptp4l : master offset 7632232488689645026 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232487689617780 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232486720382219 s0 freq 0 path delay 202338362
ptp4l : master offset 7632232485689481040 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232484689414294 s0 freq 0 path delay 233178421
ptp4l : master offset 7632232483688347841 s0 freq 0 path delay 234193504
ptp4l : master offset 7632232482688317095 s0 freq 0 path delay 234193504
 
I can use wireshark to inspect the packets being sent by the host computer to the ZynqMP, and the time sent to the Zynq is correct.
 
It seems like all of the TSU timers are filling the "seconds" registers with the 8 LSB of seconds and 24 MSB of nanoseconds, and the rest of "seconds" spill over to the tsu_timer_msb_sec register. 
 
What is causing these registers to be stored / increment incorrectly?

Hi,

Any solution on the above issue. I am also facing similar issue and unable to resolve, i have set the GEM0 in slave mode (2b11) but still see same issue like ptp4l application is not working as expected.

 

Thanks,

Shravya

[JColvin]

Hi @shravya,

In the interest of getting some needed information in advance for the engineer who is more familiar with Petalinux than I;

- What Petalinux version are you using
- what kernel and app recipes have you configured for ptp?

Thanks,
JColvin

[shravya]

Hi JColvin,

I am using petalinux 2020.2 bsp, I have enabled ptp4l in rootfs and no change in kernel code. I tried ping and it is working fine. But after Linux boot if I ran

ptp4l -i eth0 -s -m

command i see the output like above.

I read the timer_nsec register and I see it is always 0 and the timer_sec register is incrementing with random values.