Orange Pi Plus 2E - time problem

[Fazik83 0]

Hello Guys,

I have a problem with time in my Orange Pi Plus 2E.

I have installed yesterday Linux orangepiplus2e 4.19.62-sunxi #5.92 SMP Wed Jul 31 22:07:23 CEST 2019 armv7l GNU/Linux and and I can't set right time.

 

root@orangepiplus2e:~# hwclock
2019-10-07 16:52:25.994362+02:00
root@orangepiplus2e:~# date
Mon Oct  7 16:56:46 CEST 2019

Now is 16:40 hour.  Yesterday different was about 20 minutes, today is about 4 minutes. How to align the time?

root@orangepiplus2e:~# hwclock --test -D
hwclock: use --verbose, --debug has been deprecated.
hwclock from util-linux 2.33.1
System Time: 1570460247.618048
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1570392310 seconds after 1969
Last calibration done at 1570392310 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2019/10/07 16:53:13
Hw clock time : 2019/10/07 16:53:13 = 1570459993 seconds since 1969
Time since last adjustment is 67683 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2019-10-07 16:53:11.370984+02:00
Test mode: nothing was changed.

root@orangepiplus2e:~# timedatectl status
               Local time: Mon 2019-10-07 16:59:06 CEST
           Universal time: Mon 2019-10-07 14:59:06 UTC
                 RTC time: Mon 2019-10-07 16:54:51
                Time zone: Europe/Warsaw (CEST, +0200)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

 

[ifThenERROR 0]

I, too, encountered this issue on a Nanopi Neo (original, not Neo2).

 

The system was flashed with a brand new image of Armbian Buster two days ago. No other software set up yet. No custom settings except the initial user creation yet. But right from the start the clock was screwed up. It showed 07/16/2019 7:40 AM as date and since did not update. I kept the Neo running for a day and did serveral reboots, but no change. Flashed again to be sure, same issue. Can't update because the date is so long in the past. The update servers' certificates seemingly are from the future.

 

Why do I think it's related to the problem above?

root@nanopineo:~# timedatectl status
               Local time: Thu 2019-07-18 05:58:17 UTC
           Universal time: Thu 2019-07-18 05:58:17 UTC
                 RTC time: Sat 1970-01-03 01:26:59
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Note the clock is not synchronized and the NTP service is inactive, same as above.

So the NTP is inactive you say?

root@nanopineo:~# systemctl status ntp
* ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-07-18 05:56:54 UTC; 2min 24s ago
     Docs: man:ntpd(8)
  Process: 1068 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 1074 (ntpd)
    Tasks: 2 (limit: 856)
   Memory: 812.0K
   CGroup: /system.slice/ntp.service
           `-1074 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -u 104:110

Jul 18 05:56:54 nanopineo ntpd[1074]: Listen normally on 3 eth0 192.168.178.24:123
Jul 18 05:56:54 nanopineo ntpd[1074]: Listen normally on 4 lo [::1]:123
Jul 18 05:56:54 nanopineo ntpd[1074]: bind(21) AF_INET6 fe80::1932:c3bf:c5ff:1a1e%3#123 flags 0x11 failed: Cannot assign requested address
Jul 18 05:56:54 nanopineo ntpd[1074]: unable to create socket on eth0 (5) for fe80::1932:c3bf:c5ff:1a1e%3#123
Jul 18 05:56:54 nanopineo ntpd[1074]: failed to init interface for address fe80::1932:c3bf:c5ff:1a1e%3
Jul 18 05:56:54 nanopineo ntpd[1074]: Listening on routing socket on fd #21 for interface updates
Jul 18 05:56:54 nanopineo ntpd[1074]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jul 18 05:56:54 nanopineo ntpd[1074]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jul 18 05:56:56 nanopineo ntpd[1074]: Listen normally on 6 eth0 [fe80::1932:c3bf:c5ff:1a1e%3]:123
Jul 18 05:56:56 nanopineo ntpd[1074]: new interface(s) found: waking up resolver

Oh, looks like it's actually running! It gives a couple messages though, looking like they shouldn't be this way.

 

Today I tried to manually set the correct date and update the system. Updating went well, but still got a dysfunct NTP.

 

Could it be that the current image for H3s is broken? Or is the problem located at the keyboard as usual?

 

Cheers

[Igor 1613]

5 hours ago, ifThenERROR said:

Could it be that the current image for H3s is broken? Or is the problem located at the keyboard as usual?

 

The only recent change in this area, possible related, is replacing ntpdate with chrony, but since you have ntp, changes hasn't landed to images yet. If you have an option, start with self-made image.

root@orangepizeroplus:~# timedatectl 
               Local time: Tue 2019-10-15 05:30:53 UTC
           Universal time: Tue 2019-10-15 05:30:53 UTC
                 RTC time: Tue 2019-10-15 05:30:54
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

[ifThenERROR 0]

3 hours ago, Igor said:

If you have an option, start with self-made image.

It's a little inconvinient, but can do.

 

To be sure I choose the correct config.

./compile.sh BOARD=nanopineo BRANCH=next KERNEL_ONLY=no RELEASE=buster

Is that right?

[Igor 1613]

4 minutes ago, ifThenERROR said:

Is that right?

Yes. Or ./compile.sh and select those options via menu.

[ifThenERROR 0]

As an addition, the documentation currently states issues with thermal management:

 

Quote

Due to H3’s overheating tendencies a working throttling implementation is important when more heavy workloads should run on the board. This is implemented in legacy kernel (settings have been improved a lot by linux-sunxi community and us compared to Allwinner’s defaults), but in mainline kernel it is still Work-in-Progress which is one of the reasons that prevent us from releasing Armbian images with mainline kernel. So while you currently only get legacy images in download area you can already try to build your own images with kernel 4.x using our build system and choosing next branch or use prebuilt nightly images for some boards.

https://docs.armbian.com/Hardware_Allwinner-H3/

 

 

Is that still the case and should I rather use the legacy kernel? At least the part about the available downloads seems to be outdated and the download page states „mainline based kernel 4.19.y“.

[Igor 1613]

51 minutes ago, ifThenERROR said:

Is that still the case

No, ignore. Legacy kernels are EOL and due for removal.

[ifThenERROR 0]

Ok, I compiled a new image according to the documentation and now got Armbian_5.98_Nanopineo_Debian_buster_next_4.19.79 up on the NEO. The time is correct right from the start. Strangely "timedatectl status" reports the clock as synchronized, but ntp still inactive. Did the aforementioned change take effect now?

 

Anyhow I'm all happy!

 

Is there anything I can do to help iron this issue out from the downloadable image so others won't run into it?

[Igor 1613]

7 minutes ago, ifThenERROR said:

but ntp still inactive

Perhaps because we changed to chrony package?
 

7 minutes ago, ifThenERROR said:

Is there anything I can do to help iron this issue out from the downloadable image so others won't run into it?

 

Help on development to push out next update sooner? Its happen in branch "arm64" https://github.com/armbian/build/tree/arm64

 

This is the job to be done:
https://github.com/armbian/build/pull/1586#issuecomment-541457614

[ifThenERROR 0]

37 minutes ago, Igor said:

This is the job to be done:

Sorry, but I don't get it. What exactly needs to be done there? Do you need testing of that branch?

[Igor 1613]

8 hours ago, ifThenERROR said:

Sorry, but I don't get it. What exactly needs to be done there? Do you need testing of that branch?

"we can also jump u-boot to 2019.10"

This can be done in any branch.  Change https://github.com/armbian/build/blob/master/config/sources/sunxi64_common.inc#L7 or https://github.com/armbian/build/blob/master/config/sources/sunxi_common.inc#L3 and you will notice that many u-boot patches will fail. They need to be adjusted or removed if they contribute nothing. Try. Job description = sources maintenance. Compare and adjust. 

If you can help maintain forum - moving topics here and there. Its also helpful.