You have to write to the RTC before you can read from it. Something that
guide confuses . . . So actually the first steps you need to take is like
this:
root@wgd:~# apt-get install ntpdate
root@wgd:~# ntpdate pool.ntp.org
27 Jul 16:39:29 ntpdate[1903]: adjust time server 199.223.248.101 offset
0.004123 sec
Then if it's important to be on the right timezone . . .
( optional )
root@wgd:~# dpkg-reconfigure tzdata
Current default time zone: 'America/Phoenix'
Local time is now: Thu Jul 27 16:40:54 MST 2017.
Universal Time is now: Thu Jul 27 23:40:54 UTC 2017.
Then you can write to the RTC:
root@wgd:~# hwclock -w -f /dev/rtc1
So what all this does is update the system time, configures the timezone,
so that system time can be written to the real time clock. You could in
fact just write to the real time clock without doing all the above. But the
RTC will not be accurate.
Now we should be able to read from the RTC.
root@wgd:~# hwclock -r -f /dev/rtc1
Thu Jul 27 16:45:41 2017 -0.646341 seconds
Also to save you from future grief. Make sure you load the proper drivers for your hardware,then if you’re going to write your own software to read from the RTC. Use /dev/rtcx( probably /dev/rtc1 ), and do not try to read directly from the RTC over I2C. Trust me . . .
and see if the driver for your RTC is listed.
If not, try
dmesg
(I usually use dmesg | less, f is forward, b is backward, and q is quit)
and search for a message which may indicate a problem loading the driver.
Look for the character device
/dev/rtc1
Also, hwclock command behaves strangely sometimes, try sudo hwclock from a regular user account instead of from root. There may be some funky permission issues.
My driver is actually loaded from a custom overlay write I wrote myself. So all of the initial steps listed on that adafruit link, I do not have to bother with. But that’s a bit advanced, and going from experience, trying to explain how I did that “wont compute” until said person trying to understand what I’m saying has a firm grasp of how device tree overlays work.
Finally I got … the last hint from William Hermans indicated me something about the device name, which could be “rtcX”, which made me execute: “ls -la /dev/rtc*”:
root@beaglebone:~# ls -la /dev/rtc*
lrwxrwxrwx 1 root root 4 May 21 2016 /dev/rtc → rtc0
crw------- 1 root root 254, 0 May 21 2016 /dev/rtc0
Replace “rtc1” with “rtc0” in the commands and everything works! (the system date and time were already correct):
hwclock -w -f /dev/rtc0
To test if it worked and if the date and time were actually adjusted, I changed the system time, restarted the BBB and disconnected it from the internet to ensure the date and time would not be auto-tuned. After restarting it, I checked if the system time was still wrong and then read the RTC time (which must be correct!).
hwclock -r -f /dev/rtc0
It works!!! RTC date and time were correct.
I don’t even know how to thank everyone for their help. It should be simple to solve this problem, but it takes a lot of time, especially for those who don’t have experience like me.
Actually what is happening is this: when I remove the power from the BBB, the date and time return to the default setting. Because the RTC is automatically associated with system time auto-tuning, then its time is also being changed incorrectly (I had not noticed this in reboot because it is necessary to remove the power).
How do I prevent the system from automatically correcting the RTC? How do I remove this connection from the RTC with the system?
I intend to create a script to set date and time.
I tried the configuration via udev, but as reported in the above link, it doesn’t work.
Apparently the only way to get the /dev/rtc link to point to rtc1 instead of rtc0 is to change the kernel configuration and compile it that way.
I found the configuration setting, but I was too lazy to change it and compile a new kernel. My systemd service seems to be good enough.
And that brings up another point. Another system getting into the RTC act is systemd. Try this command:
Greg,
I’d just like to prevent the RTC from being updated with the system date and time so that I can even use a script to do this task when I need to.
How do I prevent the RTC from being updated automatically?
Command response “timedatectl”
root@beaglebone:~# timedatectl
Local time: Fri 2017-07-28 09:59:52 -03
Universal time: Fri 2017-07-28 12:59:52 UTC
RTC time: Sat 2016-05-21 22:38:04
Time zone: America/Sao_Paulo (-03, -0300)
Network time on: yes
NTP synchronized: no
RTC in local TZ: no
Greg, it’s okay. I was able to make the RTC be recognized as rtc1 in the system. Just turned off the BBB, disconnected everything that was connected to the hardware and starts again. I’m sure the RTC module was properly connected to the BBB, so I believe that there could only be some configuration conflict going on.
Only /dev/rtc0 is going to be updated automatically. /dev/rtc1 is not going to be updated automatically, as far as I can determine, with the Debian distributions as published.
You would have to use the config tools to switch from rtc0 to rtc1 and compile a new kernel.
So the common scheme you will find, for example, at the Adafruit site uses a script which is run by systemd to set the system time from /dev/rtc1.
This will happen soon after boot, but I am not precisely sure when.
An important point is that “system time” is what matters. That is what you will see with the date command.
So the common scripts use the hwclock command with option --rtc /dev/rtc1 (this is same as -f option) to set the system time.
So you have to assume /dev/rtc1 has been set accurately.
The best way to set the /dev/rtc1 is to use the hwclock -w /dev/rtc1 command with the device connected to the internet and accurate NTP time being in force.
This command writes the system time to the RTC. So if the system time is correct, the RTC time will be correct. This is like setting any clock. Thanks to the RTC having a battery, it will maintain time with Beagleboard power going off.
This can also be done manually at the command line if you don’t have an internet connection (but you have another accurate time source).
So basically the common scripts floating around out there overwrite the system time which was set automatically with the time provided by the RTC /dev/rtc1.
Note that there is a compensation system for the RTC which is also included in the system. I’m still working out the details on how to understand and manage what it is doing. What I am doing for now is periodically rebooting my BBGW with it connected to the internet + NTP. The compensation scheme is working, but the system time is running a little bit fast.