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@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
signature.asc
Description: This is a digitally signed message part