cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
703 Views
Registered: ‎02-26-2020

ntpdate does not update clock using ZynqMP Ultrascale+ and petalinux build

Jump to solution

Dear Support!

 

We have a ZynqMP Ultrascale+ MPSoC using petalinux 2019.2

In our project we need the actual date/time from a local NTP server instance, already during init phase.

I configured my Windows 10 to act as a NTP server, enabled the in/out traffic on windows and made “direct connection” between the TE0705 carrier board

192.168.0.1 -> windows host

192.168.0.10 -> ZynqMP Ultrascale+

 

I added the ntp package to the petalinux, the ntp.conf looks the following:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift
logconfig all
logfile /var/log/ntpd.log
fudge   127.127.1.0 stratum 10
server 192.168.0.1 iburst

 

Since the ntp cannot handle big time gaps, there is way to manually use (force) the time server’s time with ntpdate

[root@petalinux:~]# /etc/init.d/ntpd stop
Stopping ntpd: done
[root@petalinux:~]# ./ntpdate -d 192.168.0.1
24 Apr 09:50:35 ntpdate[2305]: ntpdate 4.2.8p12@1.3728-o Thu Apr 23 06:54:19 UTC 2020 (2)
Looking for host 192.168.0.1 and service ntp
host found : 192.168.0.1
transmit(192.168.0.1)
receive(192.168.0.1)
transmit(192.168.0.1)
receive(192.168.0.1)
transmit(192.168.0.1)
receive(192.168.0.1)
transmit(192.168.0.1)
receive(192.168.0.1)

server 192.168.0.1, port 123
stratum 4, precision -23, leap 00, trust 000
refid [10.60.100.103], root delay 0.060974, root dispersion 7.901413
transmitted 4, in filter 4
reference time:    e24d3707.25178126  Fri, Apr 24 2020  9:59:35.144
originate timestamp: e24d370d.e9301eab  Fri, Apr 24 2020  9:59:41.910  <-- This is the time I would get it configured
transmit timestamp:  e24d34f1.fd5825f1  Fri, Apr 24 2020  9:50:41.989

filter delay:  0.09340  0.02658  0.02652  0.02640
         0.00000  0.00000  0.00000  0.00000
filter offset: 539.9543 539.9209 539.9209 539.9208
         0.000000 0.000000 0.000000 0.000000
delay 0.02640, dispersion 0.00423
offset 539.920870

24 Apr 09:50:41 ntpdate[2305]: step time server 192.168.0.1 offset 539.920870 sec
[root@petalinux:~]# date
Fri Apr 24 09:50:44 UTC 2020  <-- this is the actual wrong time on the petalinux, 9 minutes behind the correct one

So it seems from network and ntp level everything is fine, the ntpdate got the correct time, but unfortunately nothing happens afterwards. The original (wrong) date remains.

 

However setting the time with date command and synchronization to and from the HW clock works perfectly

[root@petalinux:~]# hwclock --systohc
[root@petalinux:~]# date -s "2001-01-01"
Mon Jan  1 00:00:00 UTC 2001
[root@petalinux:~]# hwclock --hctosys
[root@petalinux:~]# date
Fri Apr 24 09:52:29 UTC 2020

The ntpq also shows the windows time server is contacted but does not taken in use (the leading * or + character is missing).

[root@petalinux:~]# /etc/init.d/ntpd start
Starting ntpd: done
[root@petalinux:~]# ./ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
192.168.0.1     10.60.100.103    4 u    2   64    1    0.744  540827.   0.037
[root@petalinux:~]# cat /var/log/ntpd.log
24 Apr 09:49:51 ntpd[2257]: Listen and drop on 0 v6wildcard [::]:123
24 Apr 09:49:51 ntpd[2257]: Listen and drop on 1 v4wildcard 0.0.0.0:123
24 Apr 09:49:51 ntpd[2257]: Listen normally on 2 lo 127.0.0.1:123
24 Apr 09:49:51 ntpd[2257]: Listen normally on 3 lo [::1]:123
24 Apr 09:49:51 ntpd[2257]: Listening on routing socket on fd #20 for interface updates
24 Apr 09:49:51 ntpd[2257]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
24 Apr 09:49:51 ntpd[2257]: 0.0.0.0 c01d 0d kern kernel time sync enabled
24 Apr 09:49:51 ntpd[2257]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
24 Apr 09:49:51 ntpd[2257]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
24 Apr 09:49:51 ntpd[2257]: 0.0.0.0 c011 01 freq_not_set
24 Apr 09:49:51 ntpd[2257]: 0.0.0.0 c016 06 restart
24 Apr 09:49:54 ntpd[2257]: Listen normally on 4 eth0 192.168.0.10:123
24 Apr 09:49:54 ntpd[2257]: bind(24) AF_INET6 fe80::821f:12ff:fed1:99%3#123 flags 0x11 failed: Cannot assign requested address
24 Apr 09:49:54 ntpd[2257]: unable to create socket on eth0 (5) for fe80::821f:12ff:fed1:99%3#123
24 Apr 09:49:54 ntpd[2257]: failed to init interface for address fe80::821f:12ff:fed1:99%3
24 Apr 09:49:54 ntpd[2257]: new interface(s) found: waking up resolver
24 Apr 09:49:56 ntpd[2257]: Listen normally on 6 eth0 [fe80::821f:12ff:fed1:99%3]:123
24 Apr 09:49:56 ntpd[2257]: new interface(s) found: waking up resolver
24 Apr 09:50:12 ntpd[2257]: ntpd exiting on signal 15 (Terminated)
24 Apr 09:50:12 ntpd[2257]: 192.168.0.1 local addr 192.168.0.10 -> <null>
24 Apr 09:50:12 ntpd[2257]: 0.0.0.0 c01d 0d kern kernel time sync disabled
24 Apr 09:52:54 ntpd[2314]: Listen and drop on 0 v6wildcard [::]:123
24 Apr 09:52:54 ntpd[2314]: Listen and drop on 1 v4wildcard 0.0.0.0:123
24 Apr 09:52:54 ntpd[2314]: Listen normally on 2 lo 127.0.0.1:123
24 Apr 09:52:54 ntpd[2314]: Listen normally on 3 eth0 192.168.0.10:123
24 Apr 09:52:54 ntpd[2314]: Listen normally on 4 lo [::1]:123
24 Apr 09:52:54 ntpd[2314]: Listen normally on 5 eth0 [fe80::821f:12ff:fed1:99%3]:123
24 Apr 09:52:54 ntpd[2314]: Listening on routing socket on fd #22 for interface updates
24 Apr 09:52:54 ntpd[2314]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
24 Apr 09:52:54 ntpd[2314]: 0.0.0.0 c01d 0d kern kernel time sync enabled
24 Apr 09:52:54 ntpd[2314]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
24 Apr 09:52:54 ntpd[2314]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
24 Apr 09:52:54 ntpd[2314]: 0.0.0.0 c011 01 freq_not_set
24 Apr 09:52:54 ntpd[2314]: 0.0.0.0 c016 06 restart
[root@petalinux:~]#

 

Do I need to configure still something for PS in the Vivado and/or device-tree and/or anything else?

Or do You have an idea why it does not work?

 

Thank You in advance

0 Kudos
Reply
1 Solution

Accepted Solutions
611 Views
Registered: ‎02-26-2020

It seems the problem caused by the Windows 10 NTP server implementation.

I switched the configuration to use an Ubuntu 18 based NTP server and the issue disappeared immediately.

The time is synchronised automatically during the boot phase by /etc/init.d/ntpd

View solution in original post

1 Reply
612 Views
Registered: ‎02-26-2020

It seems the problem caused by the Windows 10 NTP server implementation.

I switched the configuration to use an Ubuntu 18 based NTP server and the issue disappeared immediately.

The time is synchronised automatically during the boot phase by /etc/init.d/ntpd

View solution in original post