Re: SheevaPlug, hctosys: unable to open rtc device, after Buster upgrade
On 29/09/2019 22:05:38+0200, Uwe Kleine-König wrote:
> Hello,
>
> [I repaired the quoting style and expanded To: a bit]
>
> On Sun, Sep 29, 2019 at 07:36:27PM +0000, John Blake wrote:
> > On Saturday, September 28, 2019, 3:52:11 PM MDT, Rick Thomas <rbthomas@pobox.com> wrote:
> > > On Sep 28, 2019, at 1:14 PM, John Blake <blakejoh@yahoo.com> wrote:
> > > >
> > > > After upgrading my Sheevaplug from Stretch to Buster, it would not
> > > > set the system time from the RTC at boot. Here is what I see in
> > > > dmesg output:
> > > >
> > > > (kernel 4.19.67-2+deb10u1)
> > > > # dmesg | grep rtc
> > > > [ 2.088797] hctosys: unable to open rtc device (rtc0)
> > > > [ 2.535171] rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> > > >
> > > > This results in the system time being way off until after NTP starts and syncs.
> > > >
> > > > If I revert to the kernel from Stretch, it works fine:
> > > >
> > > > (kernel 4.9.168-1+deb9u5)
> > > > # dmesg | grep rtc
> > > > [ 2.205994] rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> > > > [ 2.238801] rtc-mv f1010300.rtc: setting system clock to 2019-09-07 22:51:49 UTC (1567896709)
> > > >
> > > > Does anyone know if there is a fix or workaround for this? I
> > > > searched the web for this problem and found where someone (on
> > > > archlinux) had a similar problem, his workaround being to change
> > > > kernel .config "CONFIG_RTC_DRV_CMOS=m" to "CONFIG_RTC_DRV_CMOS=y"
> > > > and compile a custom kernel. It seems to me there should be a
> > > > simpler solution.
> > >
> > > I do not have this problem on my sheevaplug running kernel
> > > ‘4.19.67-2’ . I see that ‘4.19.67-2+deb10u1’ is available, but not
>
> The step from 4.19.67-2 to 4.19.67-2+deb10u1 is harmless for this
> problem. The issue that John is describing comes from a change by Roger
> Shimizu to reduce the kernel size[1]. I guess there is some difference
> in userspace that is relevant for the problem not occuring for Rick.
> https://bugs.debian.org/855203 seems relevant here.
>
> > > yet installed on this machine. I think I’ll hold off on installing
> > > that update for a while!
> > >
> > > And, FWIW:
> > >
> > > rbthomas@sheeva:~$ grep RTC_DRV_CMOS /boot/config-4.19.0-6-marvell
> > > CONFIG_RTC_DRV_CMOS=m
>
> Note that CONFIG_RTC_DRV_CMOS isn't relevant for the Sheevaplug. The
> relevant symbol is CONFIG_RTC_DRV_MV there.
>
> I wonder if it would be sensible to implement the logic for hctosys
> (the "during boot" part that is) in rtc_register instead. This way it
> would not trigger to early if the relevant driver was modular (as is the
> case here).
>
My opinion is that distributions should stop relying on HCTOSYS and do
the RTC read from userspace. This is especially important because
distros are hardcoding rtc0 as the RTC to read from which is most likely
to not be the correct one on any embedded device.
This is not Lennart's opinion though:
https://lkml.org/lkml/2019/8/14/248
He later dismisses your use case in:
https://lkml.org/lkml/2019/8/14/454
"I'd argue that in the vast majority of cases the person building the
kernel for a device knows very well which RTC is connected to the
device they are interested in, and should just build that driver in,
and don't bother with userspace complexity, later userspace module
loading or anything like that."
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Reply to: