On 6/12/14, 8:41 PM, "John Syn" <[email protected]> wrote:
> >On 6/12/14, 8:01 PM, "Robert Nelson" <[email protected]> wrote: > >>On Thu, Jun 12, 2014 at 9:56 PM, Justin Morgan <[email protected]> wrote: >>> 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 > > >Regards, >John >> >>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 >>email to [email protected]. >>For more options, visit https://groups.google.com/d/optout. -- 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 email to [email protected]. For more options, visit https://groups.google.com/d/optout.
