* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks [not found] <20150410232854.23367.58862.reportbug@cube.rcthomas.org> @ 2015-04-11 0:08 ` Ben Hutchings 2015-04-29 3:02 ` Fabio Estevam 2015-04-29 8:57 ` Russell King - ARM Linux 0 siblings, 2 replies; 15+ messages in thread From: Ben Hutchings @ 2015-04-11 0:08 UTC (permalink / raw) To: linux-arm-kernel Control: severity -1 important On Fri, 2015-04-10 at 16:28 -0700, Rick Thomas wrote: > Package: src:linux > Version: 3.16.7-ckt7-1 > Severity: wishlist > Tags: newcomer > > Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware real-time-clock gets > reset to midnight UTC, Dec 31, 1970. > Even though the SolidRun literature says that the i4Pro has a battery backed RTC. > > A bit of googling reveals that this is related to the following fact (Quoted from the SolidRun forums) > > >There are two RTC inside CuBox-i > >1. One connected to the SNVS rail (internal i.MX6) which is not battery backed and typically goes to /dev/rtc0 If this RTC is not battery backed, it seems like it ought to be disabled in this board's device tree. > >2. Second is NXP PFC8523 based and that one has battery backup (/dev/rtc1) > >SolidRun Engineering > >user rabeeh in #cubox on Freenode IRC > >by rabeeh Sat Jan 25, 2014 7:04 pm > > >It's a standard non rechargeable lithium 3.3v coin cell. > >Available only on the models that has RTC. > >SolidRun Engineering > >user rabeeh in #cubox on Freenode IRC > > Curiously, when I look at the Debian Jessie system running on the box, I find that there is only one /dev/rtc* device, > and that seems to be associated with the SNVS clock. The PFC8523 clock is not available > > Checking /boot/config-3.16.0-4-armmp, I see what I think is an explanation, because > > # CONFIG_RTC_DRV_PCF8523 is not set > > and > > CONFIG_RTC_DRV_SNVS=y > > Other Linux systems (e.g. Arch) appear (according to the above mentioned googling) to have their kernel compiled so as to > provide both /dev/rtc0 attached to the SNVS clock, and /dev/rtc1 attached to the PFC8523 clock. > > Would it be possible to configure the default Debian Jessie kernel to do the same? Yes, we can do that. > Ideally, the PFC8523 clock should show up as /dev/rtc0, linked to /dev/rtc, > so that the battery backed clock is used by default to set the system clock at boot-time. > Failing that, it may be possible to address this by setting HCTOSYS_DEVICE in /etc/default/hwclock appropriately. > Or maybe one could tweak a rule in /etc/udev ? I wonder about that. I think it would make more sense to disable the useless RTC so there's no need to treat this board specially in userland. > Karsten Merker commented via email: > > Yes, that should just need enabling the appropriate module. > The device-tree instantiates the pcf8523 clock chip: > > &i2c3 { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_cubox_i_i2c3>; > > status = "okay"; > > rtc: pcf8523 at 68 { > compatible = "nxp,pcf8523"; > reg = <0x68>; > }; > }; > > So if the module is available, it should be loaded automatically. > > Please file a wishlist bug against "Source: linux, Version: > 3.16.7-ckt9-1" so that the kernel maintainers can enable the > module for the next kernel upload. Actually we consider missing hardware support as severity 'important'. Ben. -- Ben Hutchings compatible: Gracefully accepts erroneous data from any source -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 811 bytes Desc: This is a digitally signed message part URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150411/6fa7f376/attachment-0001.sig> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-04-11 0:08 ` Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks Ben Hutchings @ 2015-04-29 3:02 ` Fabio Estevam 2015-04-29 5:46 ` Rick Thomas 2015-04-29 5:48 ` Rick Thomas 2015-04-29 8:57 ` Russell King - ARM Linux 1 sibling, 2 replies; 15+ messages in thread From: Fabio Estevam @ 2015-04-29 3:02 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings <ben@decadent.org.uk> wrote: >> Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware real-time-clock gets >> reset to midnight UTC, Dec 31, 1970. >> Even though the SolidRun literature says that the i4Pro has a battery backed RTC. > If this RTC is not battery backed, it seems like it ought to be disabled > in this board's device tree. Agreed. Just sent a patch for this. >> # CONFIG_RTC_DRV_PCF8523 is not set >> >> and >> >> CONFIG_RTC_DRV_SNVS=y And also a patch for turning on this option as well. Regards, Fabio Estevam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-04-29 3:02 ` Fabio Estevam @ 2015-04-29 5:46 ` Rick Thomas 2015-04-29 5:48 ` Rick Thomas 1 sibling, 0 replies; 15+ messages in thread From: Rick Thomas @ 2015-04-29 5:46 UTC (permalink / raw) To: linux-arm-kernel On Apr 28, 2015, at 8:02 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > >>> Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware real-time-clock gets >>> reset to midnight UTC, Dec 31, 1970. >>> Even though the SolidRun literature says that the i4Pro has a battery backed RTC. > >> If this RTC is not battery backed, it seems like it ought to be disabled >> in this board's device tree. > > Agreed. Just sent a patch for this. > >>> # CONFIG_RTC_DRV_PCF8523 is not set >>> >>> and >>> >>> CONFIG_RTC_DRV_SNVS=y > > And also a patch for turning on this option as well. > > Regards, > > Fabio Estevam Cool? Thanks! Any idea when we?ll see it in the kernel from Sid/Unstable repo?s? Rick ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-04-29 3:02 ` Fabio Estevam 2015-04-29 5:46 ` Rick Thomas @ 2015-04-29 5:48 ` Rick Thomas 1 sibling, 0 replies; 15+ messages in thread From: Rick Thomas @ 2015-04-29 5:48 UTC (permalink / raw) To: linux-arm-kernel On Apr 28, 2015, at 8:02 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > >>> Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware real-time-clock gets >>> reset to midnight UTC, Dec 31, 1970. >>> Even though the SolidRun literature says that the i4Pro has a battery backed RTC. > >> If this RTC is not battery backed, it seems like it ought to be disabled >> in this board's device tree. > > Agreed. Just sent a patch for this. > >>> # CONFIG_RTC_DRV_PCF8523 is not set >>> >>> and >>> >>> CONFIG_RTC_DRV_SNVS=y > > And also a patch for turning on this option as well. > > Regards, > > Fabio Estevam I don?t know if this makes any difference, but please remember that this box comes in several flavors. Only the i4pro flavor has the battery-backed clock turned on in the hardware. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-04-11 0:08 ` Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks Ben Hutchings 2015-04-29 3:02 ` Fabio Estevam @ 2015-04-29 8:57 ` Russell King - ARM Linux 2015-05-02 16:01 ` Ian Campbell 1 sibling, 1 reply; 15+ messages in thread From: Russell King - ARM Linux @ 2015-04-29 8:57 UTC (permalink / raw) To: linux-arm-kernel On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote: > If this RTC is not battery backed, it seems like it ought to be disabled > in this board's device tree. It's not that simple. On the lower-end models, the on-SoC RTC is the only RTC there is. If it were disabled, there would be no RTC available at all, so there would be no preservation of time-of-day across reboots. On the Pro models, the battery backed RTC is fitted. However, the battery backed RTC has no wakeup facility. Only the on-SoC RTC has that ability, so in order to perform time-based wakeup, the on-SoC RTC needs to be synchronised with the current ToD and its alarm set. Not having the on-SoC RTC enabled means that there is no ToD based wakeup possible. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-04-29 8:57 ` Russell King - ARM Linux @ 2015-05-02 16:01 ` Ian Campbell 2015-05-02 16:12 ` Russell King - ARM Linux 0 siblings, 1 reply; 15+ messages in thread From: Ian Campbell @ 2015-05-02 16:01 UTC (permalink / raw) To: linux-arm-kernel On Wed, 2015-04-29 at 09:57 +0100, Russell King - ARM Linux wrote: > On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote: > > If this RTC is not battery backed, it seems like it ought to be disabled > > in this board's device tree. > > It's not that simple. > > On the lower-end models, the on-SoC RTC is the only RTC there is. If > it were disabled, there would be no RTC available at all, so there > would be no preservation of time-of-day across reboots. > > On the Pro models, the battery backed RTC is fitted. However, the > battery backed RTC has no wakeup facility. > > Only the on-SoC RTC has that ability, so in order to perform time-based > wakeup, the on-SoC RTC needs to be synchronised with the current ToD > and its alarm set. > > Not having the on-SoC RTC enabled means that there is no ToD based > wakeup possible. So is your advice for a multi platform kernel supporting all Cubox devices to just enable both and to sort out any syncing/naming etc in userspace? Thanks, Ian. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-02 16:01 ` Ian Campbell @ 2015-05-02 16:12 ` Russell King - ARM Linux 2015-05-02 16:21 ` Ian Campbell 0 siblings, 1 reply; 15+ messages in thread From: Russell King - ARM Linux @ 2015-05-02 16:12 UTC (permalink / raw) To: linux-arm-kernel On Sat, May 02, 2015 at 05:01:04PM +0100, Ian Campbell wrote: > On Wed, 2015-04-29 at 09:57 +0100, Russell King - ARM Linux wrote: > > On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote: > > > If this RTC is not battery backed, it seems like it ought to be disabled > > > in this board's device tree. > > > > It's not that simple. > > > > On the lower-end models, the on-SoC RTC is the only RTC there is. If > > it were disabled, there would be no RTC available at all, so there > > would be no preservation of time-of-day across reboots. > > > > On the Pro models, the battery backed RTC is fitted. However, the > > battery backed RTC has no wakeup facility. > > > > Only the on-SoC RTC has that ability, so in order to perform time-based > > wakeup, the on-SoC RTC needs to be synchronised with the current ToD > > and its alarm set. > > > > Not having the on-SoC RTC enabled means that there is no ToD based > > wakeup possible. > > So is your advice for a multi platform kernel supporting all Cubox > devices to just enable both and to sort out any syncing/naming etc in > userspace? I don't see a problem locally, because I have both built in to my kernel: hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected mousedev: PS/2 mouse device common for all mice rtc-pcf8523 0-0068: rtc core: registered rtc-pcf8523 as rtc0 snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 20cc034.snvs-rtc-lp as rtc1 i2c /dev entries driver and so the battery-backed one gets the primary RTC device. I guess the problem comes when you have them as modules, and then systemd or udev, or whatever init daemon flavour you're using can load the modules in a random order (or even in parallel) so you've no idea which RTC is which. Yes, I believe this is a userspace problem, because: 1. You need the snvs_rtc if you wish to do wakeup-by-RTC time. 2. You need pcf8523 if you want time to be preserved across power cycles. One use case is "I want time preserved across power cycles" which means you want the pcf8523. Another use case is "I want to do time of day based wakeup" in which case you need snvs_rtc. Disabling one RTC or the other just because someone doesn't like it really isn't a valid argument - what you're effectively saying is that your use-case is somehow more important than other use cases, which is grossly unfair. Ideally, you always want the PCF8523 to be the "primary" or "default" RTC if it is present (the one which will be used for hctosys/systohc stuff) and fallback to snvs_rtc if it's not present. But you also must have snvs_rtc if we are to offer wakeup by ToD. I'm not sure that we have any good way to expose whether a RTC is properly wakeup-capable to userspace (in that it's an I2C RTC and we correctly set device_can_wakeup() according to the entire system capabilities.) That would be a bug since in this case, it's something that userspace needs to know so that it can program the appropriate RTC. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-02 16:12 ` Russell King - ARM Linux @ 2015-05-02 16:21 ` Ian Campbell 2015-05-06 8:01 ` Ian Campbell 0 siblings, 1 reply; 15+ messages in thread From: Ian Campbell @ 2015-05-02 16:21 UTC (permalink / raw) To: linux-arm-kernel On Sat, 2015-05-02 at 17:12 +0100, Russell King - ARM Linux wrote: > On Sat, May 02, 2015 at 05:01:04PM +0100, Ian Campbell wrote: > > So is your advice for a multi platform kernel supporting all Cubox > > devices to just enable both and to sort out any syncing/naming etc in > > userspace? > > I don't see a problem locally, because I have both built in to my kernel: > > hub 2-0:1.0: USB hub found > hub 2-0:1.0: 1 port detected > mousedev: PS/2 mouse device common for all mice > rtc-pcf8523 0-0068: rtc core: registered rtc-pcf8523 as rtc0 > snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 20cc034.snvs-rtc-lp as rtc1 > i2c /dev entries driver > > and so the battery-backed one gets the primary RTC device. We typically build RTCs statically (for this sort of reason) so it seems like the right thing for us to do here is to build both in. Does the battery backed one automatically get synced to the time based wake up one too, or is that in userspace? What I wasn't sure about was if both were =y whether the init order was guaranteed across kernel versions etc. It sounds like you are saying it will Just Work if we build both in, which is what I was hoping for. > I guess the problem comes when you have them as modules, and then systemd > or udev, or whatever init daemon flavour you're using can load the modules > in a random order (or even in parallel) so you've no idea which RTC is > which. Right. > Yes, I believe this is a userspace problem, because: [...] Yes, ack. Thanks, Ian. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-02 16:21 ` Ian Campbell @ 2015-05-06 8:01 ` Ian Campbell 2015-05-06 10:00 ` Rick Thomas 0 siblings, 1 reply; 15+ messages in thread From: Ian Campbell @ 2015-05-06 8:01 UTC (permalink / raw) To: linux-arm-kernel On Sat, 2015-05-02 at 17:21 +0100, Ian Campbell wrote: > We typically build RTCs statically (for this sort of reason) so it seems > like the right thing for us to do here is to build both in. Which I've now done in SVN. Rick, please test the next upload. Also, Rick, I'm getting messages from my MTA about not being able to deliver to rbthomas at cube.rcthomas.org, it's been queuing/retrying since the weekend and says I shouldn't worry, but I thought I'd mention it since I was here. Exim logs say: 2015-05-06 06:48:50 1YoZqj-0002JC-G0 == rbthomas at cube.rcthomas.org R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host Hopefully you will see this via some other route. Ian. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-06 8:01 ` Ian Campbell @ 2015-05-06 10:00 ` Rick Thomas 2015-05-06 10:27 ` Ian Campbell 0 siblings, 1 reply; 15+ messages in thread From: Rick Thomas @ 2015-05-06 10:00 UTC (permalink / raw) To: linux-arm-kernel OK, How will I identify the upload when I see it? The box is running Debian/Sid and I do regular updates. So presumably, I?ll see a ?linux-image-3.16.0-4-armmp? package go by sometime soon? And I?ll know I?ve got it when I see two /dev/rtc* devices? As for ?rbthomas at cube.rcthomas.org? ? I?m afraid it?s bogus. I had exim4 configured wrong when I submitted the original bugreport /-:. I?m subscribed to the bugreport with my proper address (?rbthomas at pobox.com?) now; so you can either just send stuff for me to the bugreport directly or to the ?@pobox.com? address, and delete (or simply ignore) ?rbthomas at cube.rcthomas.org? whenever it raises its head. Thanks! This has been an interesting and educational discussion! Rick On May 6, 2015, at 1:01 AM, Ian Campbell <ijc@debian.org> wrote: > On Sat, 2015-05-02 at 17:21 +0100, Ian Campbell wrote: >> We typically build RTCs statically (for this sort of reason) so it seems >> like the right thing for us to do here is to build both in. > > Which I've now done in SVN. Rick, please test the next upload. > > Also, Rick, I'm getting messages from my MTA about not being able to > deliver to rbthomas at cube.rcthomas.org, it's been queuing/retrying since > the weekend and says I shouldn't worry, but I thought I'd mention it > since I was here. Exim logs say: > > 2015-05-06 06:48:50 1YoZqj-0002JC-G0 == rbthomas at cube.rcthomas.org R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host > > Hopefully you will see this via some other route. > > Ian. > > -- > To unsubscribe, send mail to 782364-unsubscribe at bugs.debian.org. > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-06 10:00 ` Rick Thomas @ 2015-05-06 10:27 ` Ian Campbell 2015-05-06 10:35 ` Rick Thomas 0 siblings, 1 reply; 15+ messages in thread From: Ian Campbell @ 2015-05-06 10:27 UTC (permalink / raw) To: linux-arm-kernel Control: submitter -1 Rick Thomas <rbthomas@pobox.com> On Wed, 2015-05-06 at 03:00 -0700, Rick Thomas wrote: > OK, How will I identify the upload when I see it? The box is running > Debian/Sid and I do regular updates. So presumably, I?ll see a > ?linux-image-3.16.0-4-armmp? package go by sometime soon? I think the next thing to hit Sid will be some 4.0.x per https://lists.debian.org/debian-kernel/2015/05/msg00047.html I also committed to the Jessie branch so eventually (I don't know when) a new 3.16 based thing should appear in jessie-proposed-updates (staging area for a point release). I'm not sure if the BTS will say anything when this happens nor how else one might get notified. It would be preferable to test the thing in Sid before the upload to jessie-proposed-updates > And I?ll know I?ve got it when I see two /dev/rtc* devices? Yes, I suppose. > As for ?rbthomas at cube.rcthomas.org? ? I?m afraid it?s bogus. I had > exim4 configured wrong when I submitted the original bugreport /-:. > I?m subscribed to the bugreport with my proper address > (?rbthomas at pobox.com?) now; so you can either just send stuff for me > to the bugreport directly or to the ?@pobox.com? address, and delete > (or simply ignore) ?rbthomas at cube.rcthomas.org? whenever it raises its > head. I think the line at the top should have reset the submitter to your proper address too. If you wanted to do that yourself you could use "!" as a shorthand for the address in the From: line. Ian. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-06 10:27 ` Ian Campbell @ 2015-05-06 10:35 ` Rick Thomas 2015-05-12 8:33 ` Rick Thomas 0 siblings, 1 reply; 15+ messages in thread From: Rick Thomas @ 2015-05-06 10:35 UTC (permalink / raw) To: linux-arm-kernel On May 6, 2015, at 3:27 AM, Ian Campbell <ijc@debian.org> wrote: > It would be preferable to test the thing in Sid before the upload to > jessie-proposed-updates I?ll keep an eye out for it. But I don?t have one of the cubox models without the battery-backed RTC, so I won?t be able to test that case. Is there anyone out there in debian-arm land with an appropriate test box? Enjoy! Rick ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-06 10:35 ` Rick Thomas @ 2015-05-12 8:33 ` Rick Thomas 2015-05-12 9:11 ` Ian Campbell 0 siblings, 1 reply; 15+ messages in thread From: Rick Thomas @ 2015-05-12 8:33 UTC (permalink / raw) To: linux-arm-kernel On May 6, 2015, at 3:35 AM, Rick Thomas <rbthomas@pobox.com> wrote: > > On May 6, 2015, at 3:27 AM, Ian Campbell <ijc@debian.org> wrote: > >> It would be preferable to test the thing in Sid before the upload to >> jessie-proposed-updates > > I?ll keep an eye out for it. > > But I don?t have one of the cubox models without the battery-backed RTC, so I won?t be able to test that case. Is there anyone out there in debian-arm land with an appropriate test box? > > Enjoy! > Rick Am I looking in the wrong place? I would have expected to see something show up in sid by now. Is there a particular linux-image?.deb I should download from somewhere to test this? Thanks for all your help! Rick ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-12 8:33 ` Rick Thomas @ 2015-05-12 9:11 ` Ian Campbell 2015-05-13 4:54 ` Rick Thomas 0 siblings, 1 reply; 15+ messages in thread From: Ian Campbell @ 2015-05-12 9:11 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2015-05-12 at 01:33 -0700, Rick Thomas wrote: > On May 6, 2015, at 3:35 AM, Rick Thomas <rbthomas@pobox.com> wrote: > > > > > On May 6, 2015, at 3:27 AM, Ian Campbell <ijc@debian.org> wrote: > > > >> It would be preferable to test the thing in Sid before the upload to > >> jessie-proposed-updates > > > > I?ll keep an eye out for it. > > > > But I don?t have one of the cubox models without the battery-backed > RTC, so I won?t be able to test that case. Is there anyone out there > in debian-arm land with an appropriate test box? > > > > Enjoy! > > Rick > > Am I looking in the wrong place? I would have expected to see > something show up in sid by now. > > Is there a particular linux-image?.deb I should download from > somewhere to test this? According to https://tracker.debian.org/pkg/linux it was uploaded yesterday and according to https://buildd.debian.org/status/package.php?p=linux the armhf version has been built and was installed in the archive ~5hrs ago. It hasn't shown up on the UK mirror yet at least, whereas the binaries for some arches with faster buildds have. I expect it'll show up in the next mirror pulse. Ian. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks 2015-05-12 9:11 ` Ian Campbell @ 2015-05-13 4:54 ` Rick Thomas 0 siblings, 0 replies; 15+ messages in thread From: Rick Thomas @ 2015-05-13 4:54 UTC (permalink / raw) To: linux-arm-kernel On May 12, 2015, at 2:11 AM, Ian Campbell <ijc@debian.org> wrote: > On Tue, 2015-05-12 at 01:33 -0700, Rick Thomas wrote: >> On May 6, 2015, at 3:35 AM, Rick Thomas <rbthomas@pobox.com> wrote: >> >>> >>> On May 6, 2015, at 3:27 AM, Ian Campbell <ijc@debian.org> wrote: >>> >>>> It would be preferable to test the thing in Sid before the upload to >>>> jessie-proposed-updates >>> >>> I?ll keep an eye out for it. >>> >>> But I don?t have one of the cubox models without the battery-backed >>> RTC, so I won?t be able to test that case. Is there anyone out there >>> in debian-arm land with an appropriate test box? >>> >>> Enjoy! >>> Rick It arrived this morning. I?ve got two RTC entries now in /dev. But I?m a bit confused? Looking at the boot log with journalctl (see attachment), it appears that the snvs RTC (i.e. the one without a battery backup) is being found first, and the _kernel_ is setting system time from it ? ignoring /etc/init.d/hwclock.sh completely. The pcf8523 RTC (the one with battery backup) is being discovered later, and is not being used to set the system time at all. This is exactly the opposite of the behavior I was hoping for. Well? I thought I was prepared for that by planning to use parameters in /etc/default/hwclock to tell it which RTC to use when shutting-down or booting-up. But it appears that those parameters are being ignored. Looking in /lib/systemd/system/hwclock-save.service (the systemd equivalent of /etc/init.d/hwclock), I find ?ExecStart=/sbin/hwclock -D ?systohc? which is interesting because (1) it invokes a ?-D? option which is not documented in ?man hwclock?, (2) it ignores the /etc/default parameters, and (3) it?s only being done on shutdown/halt/reboot; there?s no corresponding service that gets run at boot time? Is the RTC driver itself supposed to be doing that, so there?s no need for sysvinit or systemd to worry about it??? The ?setting system clock? log entry would seem to substantiate that. So what to do now? Any constructive suggestions will appreciated. Rick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ClockBootLog.txt URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150512/a7ce649c/attachment-0001.txt> ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-05-13 4:54 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20150410232854.23367.58862.reportbug@cube.rcthomas.org> 2015-04-11 0:08 ` Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks Ben Hutchings 2015-04-29 3:02 ` Fabio Estevam 2015-04-29 5:46 ` Rick Thomas 2015-04-29 5:48 ` Rick Thomas 2015-04-29 8:57 ` Russell King - ARM Linux 2015-05-02 16:01 ` Ian Campbell 2015-05-02 16:12 ` Russell King - ARM Linux 2015-05-02 16:21 ` Ian Campbell 2015-05-06 8:01 ` Ian Campbell 2015-05-06 10:00 ` Rick Thomas 2015-05-06 10:27 ` Ian Campbell 2015-05-06 10:35 ` Rick Thomas 2015-05-12 8:33 ` Rick Thomas 2015-05-12 9:11 ` Ian Campbell 2015-05-13 4:54 ` Rick Thomas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.