hendog82

Newcomers
  • Content Count

    1
  • Joined

  • Last visited

About hendog82

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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: [email protected]:~# devmem 0xFF0B01D0 0x7B6A6024 [email protected]:~# devmem 0xFF0B01D0 0x8A317732 [email protected]:~# devmem 0xFF0B01D0 0x99928EAA [email protected]:~# devmem 0xFF0B01D0 0xA8B6040C [email protected]:~# 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?