Cubox i4pro - rtc setting at boot

[mcloaked]

I have a Cubox i4-pro which runs arch linux very nicely. However, after rebooting the cubox, the value of the date/time from the date command and the hwclock command is not current but set to a default time in 1970. I am running chrony as a systemd service enabled at boot, which appears to update nicely but the system and hardware clocks don't seem to synchronise with the value from chrony so what I do after rebooting is to set the clock manually using (as root):

$this->bbcode_second_pass_code('', '
date -s "Nov 30 2014 21:21:00"
hwclock -systohc
')

(with the relevant current time), and then checking chronyc later I see something like:

$this->bbcode_second_pass_code('', '
# chronyc tracking
Reference ID : 195.242.98.57 (mail.no-sense.net)
Stratum : 3
Ref time (UTC) : Wed Dec 3 21:59:14 2014
System time : 0.001257644 seconds slow of NTP time
Last offset : -0.001719983 seconds
RMS offset : 0.001624198 seconds
Frequency : 54.316 ppm slow
Residual freq : -0.082 ppm
Skew : 2.089 ppm
Root delay : 0.043619 seconds
Root dispersion : 0.021451 seconds
Update interval : 517.4 seconds
Leap status : Normal
')

which looks fine and then the clocks seem OK.

However I also noticed that the rtc has values:

$this->bbcode_second_pass_code('', '
# ls -l /dev/rtc*
lrwxrwxrwx 1 root root 4 Jan 1 1970 /dev/rtc -> rtc0
crw------- 1 root root 254, 0 Jan 1 1970 /dev/rtc0
crw------- 1 root root 254, 1 Jan 1 1970 /dev/rtc1
')

and testing the two clocks:

$this->bbcode_second_pass_code('', '
# hwclock -r -f /dev/rtc0 --debug
hwclock from util-linux 2.25.2
Using the /dev interface to the clock.
Last drift adjustment done at 1417641793 seconds after 1969
Last calibration done at 1417641793 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2014/12/03 21:40:54
Hw clock time : 2014/12/03 21:40:54 = 1417642854 seconds since 1969
Wed Dec 3 21:40:54 2014 -0.606948 seconds
# hwclock -r -f /dev/rtc1 --debug
hwclock from util-linux 2.25.2
Using the /dev interface to the clock.
Last drift adjustment done at 1417641793 seconds after 1969
Last calibration done at 1417641793 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2014/12/03 21:41:07
Hw clock time : 2014/12/03 21:41:07 = 1417642867 seconds since 1969
Wed Dec 3 21:41:07 2014 -0.454050 seconds
')

So rtc0 seems to have a problem which is not present in rtc1, but I also see from a posting on the SolidRun forum:
There are two RTC inside CuBox-i
1. One connected to the SNVS rail (internal i.MX6) which is not battery backed and typically goes to /dev/rtc0
2. Second is NXP PFC8523 based and that one has battery backup (/dev/rtc1)

So the question I would love to answer is whether there is a way to make /dev/rtc1 be the link to /dev/rtc at boot, and whether this would then allow the rtc to have the backed up time from the battery sustained hardware clock rather than the default that is a date and time in 1970?

If I manually remove the link to rtc0 and change it to rtc1 then it goes back to rtc0 after rebooting, say when pacman updates to a new kernel.

Any help with this would be appreciated.

[krabat]

Running mainline kernel on a Cubietruck I ran into a similar issue.
With this device there's the problem that the RTC driver is compiled as module and as such gets loaded too late during boot, only after the kernel tries to set the system clock using the RTC (which can only be mitigated by compiling the driver into the kernel, not by putting the module in MODULES in mkinitcpio.conf, btw.).
Based on these findings I think there are two sides:


The first is the reason, what's going wrong during boot. You may have a look at the output from 'journalctl -b0'. On the Cubietruck there's e. g.
$this->bbcode_second_pass_code('', '
Jan 01 01:00:10 ct1 kernel: drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[...]
Jan 01 01:00:10 ct1 kernel: sunxi-rtc 1c20d00.rtc: rtc core: registered rtc-sunxi as rtc0
Jan 01 01:00:10 ct1 kernel: sunxi-rtc 1c20d00.rtc: RTC enabled
')reflecting the problem stated above. Maybe you'll find something telling on your CuBox, too.


As for workarounds one duty is setting the time during boot. This can e. g. be done by means of a systemd unit
$this->bbcode_second_pass_code('', '
[Unit]
Description=[...]
ConditionCapability=CAP_SYS_TIME
DefaultDependencies=no
After=systemd-remount-fs.service systemd-tmpfiles-setup.service systemd-sysusers.service
Before=time-sync.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-sync.target

[Service]
Type=oneshot
ExecStart=/usr/bin/hwclock --hctosys
CapabilityBoundingSet=CAP_SYS_TIME CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN CAP_DAC_OVERRIDE CAP_FOWNER

[Install]
WantedBy=sysinit.target
')which is derived from systemd-timesyncd.service and sets the system time using the RTC during boot. It's executed when the driver module got loaded already.

An alternate is systemd-timesyncd which implements an SNTP client and maintains a file with timestamps which makes the system clock advance monotonically.
Some months ago it made some trouble if used with network tools other than systemd-networkd. Don't know whether this has been fixed in the meantime.

Setting the RTC isn't done by any of the common NTP clients by default, afaik. I'm using a snippet /etc/systemd/system/chrony.service.d/foo.conf according to [0]
$this->bbcode_second_pass_code('', '
[Service]
ExecStopPost=/usr/bin/hwclock --systohc
')that sets the RTC based upon the system clock when chrony.service is stopped, hence during every shutdown.

All hwclock commands to be adjusted to your needs, of course.

[0] man systemd.unit, see paragraph "Along with a unit file foo.service, a directory foo.service.d/ may exist..."

[pepedog]

zcat /proc/config.gz | grep HCTO
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

Edit
I don't know if this was implemented, if so put it in uEnv.txt
https://lkml.org/lkml/2013/6/22/17

[mcloaked]

Thank you for the replies - I ran:

$this->bbcode_second_pass_code('', '
# journalctl -b0 | grep rtc
Dec 05 22:47:09 cubox1 kernel: rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc0
Dec 05 22:47:09 cubox1 kernel: snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 20cc034.snvs-rtc-lp as rtc1
Dec 05 22:47:09 cubox1 kernel: rtc-pcf8523 2-0068: setting system clock to 2014-12-05 22:47:04 UTC (1417819624)
')

So the rtc related journal lines are different to your case.

The idea of using a systemd unit to set the clock is an excellent one and I will try to get some time in the next few days to implement that.

With the second reply showing the contents of /proc/config.gz - presumably that file could be changed to set rtc1 instead of rtc0 but would that allow the clock to be set at boot with no other changes I wonder?

[mcloaked]

I just looked again at the clock settings - subsequently to my original post there was a kernel update, and my earlier post this evening was when the cubox had been booted to the new kernel - I had also manually reset the clock as I described previously. However I decided to reboot the machine and not manually set the clock - and now it seems that a change has been brought in that does set the clock at boot.

So a short time after rebooting, with no other changes at all, and the same configs as I had in my original post, I now see:

$this->bbcode_second_pass_code('', '
[root@cubox1 ~]# date
Fri Dec 5 23:05:18 GMT 2014
[root@cubox1 ~]# hwclock
Fri Dec 5 23:05:26 2014 -0.192338 seconds
[root@cubox1 ~]# timedatectl
Local time: Fri 2014-12-05 23:05:38 GMT
Universal time: Fri 2014-12-05 23:05:38 UTC
RTC time: Fri 2014-12-05 23:05:37
Time zone: Europe/London (GMT, +0000)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: no
Last DST change: DST ended at
Sun 2014-10-26 01:59:59 BST
Sun 2014-10-26 01:00:00 GMT
Next DST change: DST begins (the clock jumps one hour forward) at
Sun 2015-03-29 00:59:59 GMT
Sun 2015-03-29 02:00:00 BST
')

So it would seem that the original problem has been fixed by one of the recent package updates, possibly the kernel. The only two relevant package updates since my original post were (apart from lvm which I don't use I think):

$this->bbcode_second_pass_code('', '
[2014-12-03 21:19] [PACMAN] upgraded device-mapper (2.02.112-1 -> 2.02.114-1)
[2014-12-03 21:20] [PACMAN] upgraded linux-imx6-cubox-dt (3.14.25-1 -> 3.14.25-2)
')

[pepedog]

Did you at any time do hwclock -w

[mcloaked]

pepedog: It is possible that when I was first looking at this around the time I first posted I may have written to the rtc though I can't remember for sure - but if that was what has resolved this then it is useful to know.

[krabat]

The output of journalctl -b0 basically shows that everything is fine. Both RTCs get their module loaded, the battery backed one is set as rtc0, which the kernel is using to set the system time.
Having a quick look at the recent commits to linux-imx6-cubox-dt I couldn't find anything related to RTCs.
This makes me wonder whether the actual issue could be some kind of artefact as you made those findings when no RTC had ever been set and chrony hadn't finished setting the system clock yet.
Anyway, if your system clock gets set to reasonable values during boot now the problem doesn't seem to be worth further tracking. The only thing you may still consider is running hwclock --systohc from time to time, of course after setting the system clock. This does make sense as those battery backed RTCs normally aren't that precise which yields faulty system time right after boot in a while.

[mcloaked]

krabat: thank you. One thing that puzzles me though is that I had thought that running chrony with the settings I have should occasionally write the time to rtc - but if I am wrong then your suggestion to periodically manually write the system time to the rtc is worth doing.

I have the rtcsync directive in my /etc/chrony.conf and this I thought from the chrony user guide should:

$this->bbcode_second_pass_code('', '
The rtcsync directive will enable a kernel mode where the system time is copied to the real time clock (RTC) every 11 minutes.

This directive is supported only on Linux and cannot be used when the normal RTC tracking is enabled, i.e. when the rtcfile directive is used.
')

However as time passes the times viewed in the hwclock and date commands slowly deviate from each other.

I have just updated to kernel linux-imx6-cubox-dt-3.14.26-1-armv7h and rebooted so I'll track the time output over the next few days and see if the new kernel makes any difference.

[krabat]

You're right, rtcsync should do the job, too. Simply forgot about it as I'm using rtcfile.

If RTC and system clock keep drifting you might have a look at /dev/rtc*, or check both RTCs by hwclock's -f switch. Maybe chrony is tweaking the wrong RTC?