[systemd-devel] use RTC date/time to set system date time

[Michał Zegan]

W dniu 01.03.2021 o 16:59, Lennart Poettering pisze:
> On Mo, 01.03.21 14:52, Michał Zegan (webczat_200 at poczta.onet.pl) wrote:
> 
>> Someone should really find a way to make it cooperate well with modular
>> rtcs.
>> It's popping up over and over and over and over again and no one is/will
>> build all rtc drivers into the kernel.
> 
> To my knowledge the kernel these days can also sync from the RTC if
> the RTC is loaded as module, as long as the device is named "rtc0".
> 
> But this stuff is racy of course if the RTC is compiled as module and
> you care for generic hw, that might or might not have an RTC: we
> cannot gues swhether an RTC will show up or not in that case,
> i.e. whether there is an RTC connected and whether there's a driver
> for it. Hence we time-{set|sync}.target cannot possibly wait for it to
> show up since it might mean we have to wait indefinitely...
I actually think kernel doesn't set on module load, and if it does, it's
very recent. How recent would it be? What kernel?
> 
> My recommendation: if you have embedded hw you should kow your hw,
> hence compile it in. Time is such a basic concept, it's something that
> should just work, and not require userspace interference to work.
Well, note that things like rpi are user facing embedded hardware and
from what I remember they don't have any builtin rtc drivers. Same for
odroid c2/etc.
For odroid they sell an rtc, and it's a different thing if you just need
to enable rtc in device tree, different if you need to build the kernel
just to have it correct.
Just changingdevice tree then doing some userspace config is easier.
Maybe vendors should build rtc drivers in, but they don't and if there
is no builtin rtc in something, like rpi, you have to rebuild the kernel
instead of just early module load for example, etc.
> 
> If you really don't want to compile it in, and love the extra
> headaches this involves, then make sure you run a recent kernel that
> can sync the system clock to RTC even when the module is loaded
> later. And then manually add an ordering dep to time-set.target to
> wait for /dev/rtc0, since that is the target that should be delayed
> until the RTC shows up and is probed:
What is normally attached to this target? In addition, the fact the
device appear probably doesn't necessarily mean the time was set already?
> 
>     mkdir -p /etc/systemd/system/time-set.target.d
>     cat > /etc/systemd/system/time-set.target.d/wait-for-rtc0.conf <<EOF
>     [Unit]
>     Wants=dev-rtc0.device
>     After=dev-rtc0.device
>     EOF
> 
> And:
> 
>     mkdir -p /etc/udev/rules.d/
>     cat > /etc/udev/rules.d/70-rtc-systemd.rules <<EOF
>     ACTION!="remove",SUBSYSTEM=="rtc",TAG+="systemd"
>     EOF
> 
> i.e. the latter makes sure there are .device units for your /dev/rtc
> devices, the former then tells time-set.target to wait for it to show
> up.
> 
> (both untested, ymmv)
> 
> And yes, you need to do this manually on your system. We cannot
> possibly know whether it's worth waiting for an RTC or not,
> generically.
> 
> But really, just figure out what your hw is and link the driver into
> the kernel. It saves you a lot of headaches, and kernel timestamps
> won't be crap initially.
But kernel sets time at late boot anyway. So aren't they crap before it?
Like I don't understand something about the mechanism.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210301/4a620fb4/attachment.sig>