Re: issue opened in FS#831, the RTC on mvebu targets can be borked, causing some grief.
Information from a rango which currently has a borked RTC:
root@bsaedgy:/etc# uname -a
Linux bsaedgy 4.9.61 #0 SMP Fri Nov 10 13:53:04 2017 armv7l GNU/Linux
root@bsaedgy:/etc# cat openwrt_version
r5297-bddffc5
root@bsaedgy:/etc# adjtimex
mode: 0
-o offset: 8839 us
-f freq.adjust: 267864 (65536 = 1ppm)
maxerror: 16000000
esterror: 16000000
status: 65 (PLL | UNSYNC)
-p timeconstant: 8
precision: 1 us
tolerance: 32768000
-t tick: 10000 us
time.tv_sec: 1510770059
time.tv_usec: 702501
return value: 5 (clock not synchronized)
root@bsaedgy:/etc# hwclock -r
Wed Dec 31 16:59:59 1969 0.000000 seconds
root@bsaedgy:/etc# date
Wed Nov 15 11:21:48 MST 2017
root@bsaedgy:/etc# hwclock -w
root@bsaedgy:/etc# hwclock -r
Wed Dec 31 16:59:59 1969 0.000000 seconds
Time is being set via NTP (busybox), but with a warning on reboot regarding the time discrepancy, and sysfixtime is unable to set the RTC.
Based on OOTB kernel configs, it appears that every 11 minutes the kernel should be taking the current time from userspace(NTP), and updating RTC. But the RTC cannot be set via hwclock. Based on information in FS#831, it appears that a reset of the date facility is required by way of uboot command. I currently do not have a serial connection to this device, so I am unable to confirm.
The solution presented in FS#831, removal of RTC, seems less than optimal. So, the question is, where does the issue lie? Is this truly a uboot issue or...