I have an RTC chip (uses ds1307 overlay) attached to standard Tinkerboard S that works just fine. It sits on the i2c-1 bus, and gets mapped to rtc1.
I am able to communicate with it using hwclock -f /dev/rtc1 -r and it reports the time. This is good.
However, I take that board and put it on a Tinkerboard S R2.0 running the Debian 3.0.11 image, with “ds1307-overlay” enabled. For some reason it gets mapped to rtc0.
I am NOT able to communicate with it using hwclock -f /dev/rtc0 -r. The interesting thing is when I look at /var/log/syslog, I can see where it finds the ds1307, maps it to rtc0, and then declares that it is setting the system time to the proper time value (that it could have only gotten if it was able to read the time from the RTC).
Why is this happening when hwclock -f /dev/rtc0 -r doesn’t work. I can’t set the clock either with a hwclock -f /dev/rtc0 -w command.
Performing a udevadm info -a -p /sys/class/rtc/rtc0 shows a valid time in the output text, but if I execute the command again, the time does not change.
It’s like communication with the RTC worked initially, but then something changed during boot that prevents communication further.
Update,
I believe I found the issue…
Somehow something caused the RTC chip to hang / freeze time. I disabled the overlay, and performed i2cdump to watch RTC registers…They weren’t changing! So pulled power, pulled the battery, and put it back in…Now time increments…hwclock is able to read the value now since it sees a changing value.
from dec