Need help getting Debian to sync the system clock with my RTC on boot (and not with rtc-omap)

[Justin Morgan]

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/*
<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?

[Robert Nelson]

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
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,
--
Robert Nelson
http://www.rcn-ee.com/

[Justin Morgan]

Post by Robert Nelson
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

Post by Robert Nelson
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.

Post by Robert Nelson
Regards,
--
Robert Nelson
http://www.rcn-ee.com/

[Cody Lacey]

Are you sure rcS is the run-level you are in?
Try adding a symlink to /etc/rc2.d

Post by Robert Nelson
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
[ 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
- 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

Post by Robert Nelson
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.

Post by Robert Nelson
Regards,
--
Robert Nelson
http://www.rcn-ee.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Justin Morgan]

Post by Cody Lacey
Are you sure rcS is the run-level you are in?
Try adding a symlink to /etc/rc2.d

Actually, I'm not sure the latest BBB Debian image (Debian 7.5 2014-05-14)
is using init.d...

[Justin Morgan]

Post by Cody Lacey
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.

[Robert Nelson]

Post by Justin Morgan

Post by Cody Lacey
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,
--
Robert Nelson
http://www.rcn-ee.com/

[Justin Morgan]

Post by Cody Lacey
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.

[Robert Nelson]

Post by Cody Lacey
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,
--
Robert Nelson
http://www.rcn-ee.com/

[w***@gmail.com]

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

Post by Justin Morgan
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/*
<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?