I am using a BBB running the new Debian image. I have connected a DS1307 RTC (via a “Tiny RTC I2C modules” breakout board) to I2C2, and have added “cape_enable=capemgr.enable_partno=BB-BONE-RTC” to uEnv.txt such that my BBB does see this RTC as /dev/rtc1.
I want to synchronize the system clock from this RTC on boot (and not the BBB’s rtc-omap that is registered as /dev/rtc0), so I modified /etc/init.d/hwclock.sh such that HCTOSYS_DEVICE=rtc1. I thought that should do it… after all, I was able to get a Raspberry Pi running Raspian to synchronize with a DS1307 on boot following these instructions: http://blog.elevendroids.com/2012/12/setting-up-hardware-rtc-in-raspbian/
However, my BBB keeps synchronizing with rtc-omap on boot… and doesn’t seem to be running hwclock.sh, either (time after boot is back in May, not the current time as I confirm by sudo hwclock -r -f /dev/rtc1).
So where is Debian actually synchronizing the time in the boot process, and how do I tell it I want to use my battery-backed clock?
So we have an init script to get the clock in the 'ball park'
https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/generic-debian.sh#L19
It's located at /etc/init.d/boot_scripts.sh
You can either remove "/etc/timestamp" and it'll ignore resetting the
clock on bootup.
Regards,
So we have an init script to get the clock in the ‘ball park’
That explains the May-ish date that I keep booting up to, instead of what this dmesg entry implies:
[ 1.025090] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
But I am still unclear as to when Debian is synchronizing /dev/rtc0 to the system clock (seems to me this is happening before boot_scripts.sh is called). I am also stumped as to why /etc/init.d/hwclock.sh is not running (/etc/rcS.d/S05hwclock.sh is symlinked to /etc/init.d/hwclock.sh, and I did perform an rc.d-update hwclock.sh).
If hwclock.sh was running, I would expect one of two outcomes (since I did change which RTC the script should be using):
- If it ran before boot_scripts.sh, I would expect the system clock and omap_rtc would have the correct time.
- If it ran after boot_scripts.sh, I would expect the system clock to have the correct time
https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/generic-debian.sh#L19
It’s located at /etc/init.d/boot_scripts.sh
You can either remove “/etc/timestamp” and it’ll ignore resetting the
clock on bootup.
Looking at boot_scripts.sh, it doesn’t look like removing this code would solve my problem. /dev/rtc1 is not being reset by anything. It still holds the current time from where I set it yesterday.
Are you sure rcS is the run-level you are in?
Try adding a symlink to /etc/rc2.d
Are you sure rcS is the run-level you are in?
Try adding a symlink to /etc/rc2.d
Actually, I’m no longer sure that the latest BBB Debian image (Debian 7.5 2014-05-14) is using init.d… it looks like it might be using system instead.
That and I think the kernel might be synchronizing the hwclock to the system clock. More research is necessary.
It's both...
systemd is enabled, so if an init.d script has a systemd counterpart,
that is used instead. Otherwise systemd will run anything else in an
init.d compatibility mode.
Regards,
Are you sure rcS is the run-level you are in?
Try adding a symlink to /etc/rc2.d
As far as I can tell from a Google search, rcS is correct for hwclock.sh, as this is something that needs to be done before Linux displays a login prompt. (That would match the header in hwclock.sh.) It also appears as if rcS.d is (or was in the pre-systemd days) executed on boot first before the system changes to the runlevel specified in /etc/inittab.
You could also review the systemd log:
systemd-journalctl
Regards,
Did you find a solution? I’m having the same problem. It seems that during boot the /etc/timestamp is used to set the hwclock. I suspected the boot_script.sh file but after changing it the problem remained. I can set the timestamp during a shutdown but I would rather see a more general solution.
Regards,
Wim