I’ve noticed a difference in behavior between the latest Angstrom Linux image and the latest Debian image available for the BeagleBone Black when it comes to enumerating the real-time clocks present when a RTC “Cape” is “present”. [I have the actual clock present by use of a generic breakout board, but not the actual cape.]
I am trying to determine if Angstrom Linux has a patch that is not present in Debian, as I prefer the RTC behavior I am seeing in Angstrom. (I’d think Debian would want the Angstrom behavior, because if the user has attached an RTC, then there is most likely a battery backing it; the BBB currently does not support shutdown to the RTC rail only, so the on-board RTC is going to be wrong on a cold boot.)
When I tell Angstrom that I have a “BB-BONE-RTC” cape attached, my RTC (the DS1307) is enumerated as /dev/rtc0. As such, my clock becomes the clock that is used to set the system clock, and is otherwise going to get all of the privileges of being the first RTC.
When I tell Debian that I have a “BBB-RTC-01” cape attached, the on-board RTC is still enumerated as /dev/rtc0. My RTC is enumerated as /dev/rtc1. As such, the clock is wrong on boot.
I used different capes because I was going for firmware already on the BBB. I don’t see anything about either DTO that explains the difference in behavior.
Well, i just compared Angstrom's config with the one i've been pushing
out for our 3.8 branch.. No difference an any "RTC" config's..
Probally comes down to Angstrom's much newer version of systemd, or
something custom.
Regards,
I've noticed a difference in behavior between the latest Angstrom Linux
image and the latest Debian image available for the BeagleBone Black
when it
comes to enumerating the real-time clocks present when a RTC "Cape" is
"present". [I have the actual clock present by use of a generic breakout
board, but not the actual cape.]
I am trying to determine if Angstrom Linux has a patch that is not
present
in Debian, as I prefer the RTC behavior I am seeing in Angstrom. (I'd
think
Debian would want the Angstrom behavior, because if the user has
attached an
RTC, then there is most likely a battery backing it; the BBB currently
does
not support shutdown to the RTC rail only, so the on-board RTC is going
to
be wrong on a cold boot.)
When I tell Angstrom that I have a "BB-BONE-RTC" cape attached, my RTC
(the
DS1307) is enumerated as /dev/rtc0. As such, my clock becomes the clock
that
is used to set the system clock, and is otherwise going to get all of
the
privileges of being the first RTC.
When I tell Debian that I have a "BBB-RTC-01" cape attached, the
on-board
RTC is still enumerated as /dev/rtc0. My RTC is enumerated as
/dev/rtc1. As
such, the clock is wrong on boot.
I used different capes because I was going for firmware already on the
BBB.
I don't see anything about either DTO that explains the difference in
behavior.
Well, i just compared Angstrom's config with the one i've been pushing
out for our 3.8 branch.. No difference an any "RTC" config's..
Probally comes down to Angstrom's much newer version of systemd, or
something custom.
Is systemd really creating /dev/rtc0? Isn't initcall starting the driver
and posting an event to udev which then creates /dev/rtc0. I think this is
simply a race condition on which driver gets started first.
Here is a test that Justin can do to resolve this. Add ³initial_debug² to
his kernel command line (on both Debian and Angstrom) and after he has
booted each BBB OS, see which driver gets started first by running the
³dmesg" command.
Regards,
John
I've noticed a difference in behavior between the latest Angstrom Linux
image and the latest Debian image available for the BeagleBone Black
when it
comes to enumerating the real-time clocks present when a RTC "Cape" is
"present". [I have the actual clock present by use of a generic
breakout
board, but not the actual cape.]
I am trying to determine if Angstrom Linux has a patch that is not
present
in Debian, as I prefer the RTC behavior I am seeing in Angstrom. (I'd
think
Debian would want the Angstrom behavior, because if the user has
attached an
RTC, then there is most likely a battery backing it; the BBB currently
does
not support shutdown to the RTC rail only, so the on-board RTC is
going
to
be wrong on a cold boot.)
When I tell Angstrom that I have a "BB-BONE-RTC" cape attached, my RTC
(the
DS1307) is enumerated as /dev/rtc0. As such, my clock becomes the
clock
that
is used to set the system clock, and is otherwise going to get all of
the
privileges of being the first RTC.
When I tell Debian that I have a "BBB-RTC-01" cape attached, the
on-board
RTC is still enumerated as /dev/rtc0. My RTC is enumerated as
/dev/rtc1. As
such, the clock is wrong on boot.
I used different capes because I was going for firmware already on the
BBB.
I don't see anything about either DTO that explains the difference in
behavior.
Well, i just compared Angstrom's config with the one i've been pushing
out for our 3.8 branch.. No difference an any "RTC" config's..
Probally comes down to Angstrom's much newer version of systemd, or
something custom.
Is systemd really creating /dev/rtc0? Isn't initcall starting the driver
and posting an event to udev which then creates /dev/rtc0. I think this
is
simply a race condition on which driver gets started first.
Here is a test that Justin can do to resolve this. Add ³initial_debug² to
his kernel command line (on both Debian and Angstrom) and after he has
booted each BBB OS, see which driver gets started first by running the
³dmesg" command.
http://elinux.org/Initcall_Debug
You might have an interest in 3 old patches from me I've just posted
again for someone else: https://lkml.org/lkml/2014/6/13/6
These patches make it possible to choose the used RTC by driver name.
Regards,
Alexander Holler
You could write a udev rule to make your RTC symlink to /dev/rtc0