Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Ben Hutchings]

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>

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Fabio Estevam]

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

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

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

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Russell King - ARM Linux]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Ian Campbell]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Russell King - ARM Linux]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Ian Campbell]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Ian Campbell]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

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.
> 

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Ian Campbell]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

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

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

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

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Ian Campbell]

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.

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

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>