Research Kernel config: Change RTC_HCTOSYS as default?

[windysea]

Some SBCs, such as PIneA64, provide a built-in RTC on-board while others do not.

 

For those boards that do have a built-in RTC, it appears the kernel driver is configured as a builtin rather than as a module at least in some cases (I only checked a few).  This in turn brings up a question:

 

For boards that include a built-in RTC and also have the respective kernel driver configured as a built-in, should the kernel configuration to also set the system clock from that RTC (RTC_HCTOSYS) be enabled by default?

 

There is a dependency that the RTC be built-in as the kernel will try to read from the RTC rather early, before any loadable modules would have been loaded.  That would potentially preclude this from being a common default, but doesn't necessarily need to.   For cases where this can be done, this has the advantage of not requiring separate user-space accommodations.  For distributions based on systemd there are sadly a very large number of discussions and proposals on how to set the system time from RTC at boot time but also sadly there is no standard nor common solution.  /lib/udev/hwclock-set explicitly exits without setting the system clock if systemd is found, and systemd will not read the RTC itself expecting to use a network time source (NTP) instead.

 

Having the kernel set system time from RTC would happen a bit earlier than any user-land option which would result in consistent and correct timestamps on files created/modified during startup as well as in various logs.  It may not be a perfect nor complete solution, but where possible does this seem like something that could/should be done?

 

 

[lanefu]

7 minutes ago, windysea said:

 

Having the kernel set system time from RTC would happen a bit earlier than any user-land option which would result in consistent and correct timestamps on files created/modified during startup as well as in various logs.  It may not be a perfect nor complete solution, but where possible does this seem like something that could/should be done?

For the could part -- check out armbian firstrun and hardware optimization scrips.. That's probably where you'd wanna start.

https://github.com/armbian/build/tree/master/packages/bsp/common/usr/lib/armbian

[windysea]

Reviewing the defconfigs currently provided, it looks like most boards already have CONFIG_RTC_HCTOSYS=y, along with the matching CONFIG_RTC_HCTOSYS_DEVICE=rtc0 so I would think this should be good to submit a PR against for sunxi64-dev (used for pine64 DEV).

 

However I noticed that the pine64-default actually has CONFIG_RTC_HCTOSYS_DEVICE=rtc0 set but does not have CONFIG_RTC_HCTOSYS set.  That would hint that it had been enabled and at some point later disabled, as the former doesn't get defined until the latter is set to 'y':

linux-pine64-default.config:# CONFIG_RTC_HCTOSYS is not set
linux-pine64-default.config:CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
linux-sunxi64-dev.config:# CONFIG_RTC_HCTOSYS is not set
linux-sunxi64-next.config:# CONFIG_RTC_HCTOSYS is not set

 

Before I try to submit a PR to change this defconfig, is there a particular reason this should not be done?  At worst if the RTC is not able to be read the kernel should simply log a message and move along as if this option wasn't enabled.

 

This is the only set of defconfigs (default/dev/next) that I found like this, which is why I'm curious.

[windysea]

Just for completeness and closure PR #1329 implemented this for 'sunxi' and 'sunxi64' in both NEXT and DEV.  Other platforms already have this feature configured.

 

There should be no longer be any need for additional automated or otherwise scripted enhancements to do a separate 'hwclock -s' after boot as the kernel will do this itself very early, where it should be done when possible.