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

[Rick Thomas <rbthomas@pobox.com>]

> On Sep 30, 2019, at 12:41 AM, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> 
> 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

Lennart’s argument fails, however, if you are on a machine like the Raspberry Pi where the hardware clock (and its driver) are provided (or not) by the end-user (or the supplier who sold them the clock) In that case, there’s no way for the kernel to know at compile time what clock is installed.

Another case where this argument falls down is the Cubox-iPro which has two hardware clocks.  The first, labeled /dev/rtc0 by the Debian kernel, is accurate as long as the power is up, but it has no battery backup, so when the power fails they clock fails as well.  The second, labeled /dev/rtc1 by Debian, has an optional battery backup, so it can (but may not depending on whether the battery is installed) ride thru a power failure.  It’s a user option whether to install the battery, so again, not something the kernel can know at compile time.

Rick