Re: SheevaPlug, hctosys: unable to open rtc device, after Buster upgrade

[Rick Thomas <rbthomas@pobox.com>]

> On Sep 29, 2019, at 1:05 PM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> 
> 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.

So here’s what I get for that:
    rbthomas@sheeva:~$ grep RTC_DRV_MV /boot/config-4.19.0-6-marvell
    CONFIG_RTC_DRV_MV=m

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

Could you fill in the details a bit more here?  I assume this is something to do with the systemd way of initializing the system, which I’m afraid I don’t understand as well as I probably should… please forgive my ignorance!

In particular, where/when is the “hwclock hctosys” being done during boot currently?  And where/when would it be done under your proposal?

And, finally, would the suggested change work for other types of hardware than armel?


Thanks for your help!
Rick