I've installed an adafruit DS1307 rtc and it seems to be OK and running on 2015-05-05-raspian-wheezy
This installation, btw, is entirely different from older information that you will generally find on the internet - including the info at adafruit - since it's now a matter of enabling I2C and drivers in raspi-config, and then adding a line to /boot/config.txt:
This is discussed here
So now hwclock appears to work fine ( and 'i2cdetect' doesn't work at all; there is no /dev/i2c* at all)
Except that the rpi still powers up with the same time I turned it off, and the RTC does not appear to have advanced while the power was off. initially I suspected that the DS1307 oscillator was not running on battery (though a scope shows a 32khz wave), but now it appears that 'fake-hwclock' is superseding what's in the hwclock. I.e, during startup, fake-hwclock loads the time from /etc/fake-hwclock.data, and then sometime after that, hwclock -w is done (since the hwclock appears to be matching this wrong time by the time I log in). I've done an experiment where I manually put the /etc/fake-hwclock.data a half hour into the future - using a linux laptop while the rpi was off - and confirmed this.
In other words, I can power it off - change the /etc/fake-hwclock.data to some time in the future, then power it on before that time happens, and that time I selected will be the 'system time', and will also have been set into the RTC, as reported by hwclock -r. This will also occur if the recorded time is in the past (relative to when I do the power up) -- as is the case if I don't tinker with /etc/fake-hwclock.data at all.
I tried putting 'hwclock -s' in /etc/rc.local, but that runs way too late.
While I was gathering information for this, I came across this post which appears to have the proper method. I will try that and in any case will leave this post here as a pointer.
Update: Agggg. It appears that most of the information in that post is out of date (relating to installing the drivers), but the advice on removing fake-hwclock is there (including removing from crontab). I'll just quote part of that from here
http://blog.remibergsma.com/2013/05/08/ ... pberry-pi/
I talked about the ‘fake-hwclock’ package. Now that we have a hardware clock, we should remove this package and it’s crons.
Code: Select all
apt-get remove fake-hwclock
update-rc.d -f fake-hwclock remove
Enable the ‘hwclock.sh’ script (part of util-linux), instead:
The above (complete removal of fake-hwclock) appears to override the advice in the elevendroids link, which contains a less aggressive removal
http://www.elevendroids.com/2012/12/set ... -raspbian/
We can now disable fake-hwclock from running:
Either way, this means my SD card probably won't work very well at all on a PI not equipped with an RTC, but I guess I can deal with that.
No No No...
I removed fake-hwclock and enabled hwclock.sh, using update-rc.d, and reverted /etc/rc.local.
Now the time goes back to Jan 1 1970 when I restart, and 'hwclock -r' says the RTC is corrupted even though the RTC was readable before I restarted. I can restore the time, do a hwclock -w, and then hwclock -r works, and then it fails again on restart and says the RTC is corrupted. So now I'm thinking that I'm pretty thick, and that all this time 'hwclock' was actually talking to fake-hwclock - at least on the read side. (Evidence of writes to the rtc, since it didn't oscillate on battery under after hwclock -w was done).
Is it possible that the 'hwclock.sh' is trying to talk to the RTC before the RTC driver has been set up? Would explain failure to read the time, but not why the RTC is corrupted.
I did not follow the advice in the elevendroids article to modify hwclock.sh - since all of that ( things like 'echo ds1307 0x68 >> $bus/new_device' , and modprobes) appears to be related to the old driver setup which has been superseded by dtoverlay.
I have run out of time to spend on this for today, would appreciate any help.