Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware real-time-clock gets reset to midnight UTC, Dec 31, 1970. Even though the SolidRun literature says that the i4Pro has a battery backed RTC.
A bit of googling reveals that this is related to the following fact (Quoted from the SolidRun forums)
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)
SolidRun Engineering
user rabeeh in #cubox on Freenode IRCby rabeeh » Sat Jan 25, 2014 7:04 pm
It's a standard non rechargeable lithium 3.3v coin cell.
Available only on the models that has RTC.
SolidRun Engineering
user rabeeh in #cubox on Freenode IRC
Curiously, when I look at the Debian Jessie system running on the box, I find that there is only one /dev/rtc* device, and that seems to be associated with the SNVS clock. The PFC8523 clock is not available…
Checking /boot/config-3.16.0-4-armmp, I see what I think is an explanation, because
# CONFIG_RTC_DRV_PCF8523 is not set
and
CONFIG_RTC_DRV_SNVS=y
Other Linux systems (e.g. Arch) appear (according to the above mentioned googling) to have their kernel compiled so as to provide both /dev/rtc0 attached to the SNVS clock, and /dev/rtc1 attached to the PFC8523 clock.
Would it be possible to configure the default Debian Jessie kernel to do the same?
Ideally, the PFC8523 clock should show up as /dev/rtc0, linked to /dev/rtc, so that the battery backed clock is used by default to set the system clock at boot-time. Failing that, it may be possible to address this by setting HCTOSYS_DEVICE in /etc/default/hwclock appropriately. Or maybe one could tweak a rule in /etc/udev ?
Anyway…
Thanks!
Rick
PS: As a temporary partial workaround, I’ve installed the “fake-hwclock” package, which works as long as the system is always properly shut down before being unplugged, and never unplugged for more than a few seconds at a time.