A true mainline Linux Kernel for the Pinebook Pro

[tsys]

I've spent some time investigating the failing to load time from RTC at boot. (Some people are circumventing it by fumbling around with NTP daemons).

I saw someone mention that problem on the Dicord the other day.
I've just looked at it. First and foremost the IRQ GPIO of the pmic is just wrong which will prevent pretty much all read operations on the RTC from succeeding. I've fixed that.

Looking at the logs:

Code:

$ journalctl --boot | grep -P 'rtc0|timesyncd'|head -n 3
Dec 17 13:44:08 nereid kernel: hctosys: unable to open rtc device (rtc0)
Dec 17 13:44:13 nereid kernel: rk808-rtc rk808-rtc: registered as rtc0
Dec 17 13:44:17 nereid systemd-timesyncd[791]: System clock time unset or jumped backwards, restoring from recorded timestamp: Tue 2019-12-17 23:29:02 CET

Seems that there's a race condition: kernel's `hctosys` tries to fetch time before the RTC driver has actually registered a device to fetch from, and thus when timesyncd starts the clock is still wrong and gets restored from last shutdown timestamp.

It looks like a time race that looks exactly like this bug report.

In pinebook pro's situation:

Code:

$ zgrep -P 'RTC_(HCTOSYS|SYSTOHC|DRV_RK808)' /proc/config.gz
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_DRV_RK808=m

it seems that we hit the same situation:
- hctosys is a built-in kernel function and is ran immediately during kernel start-up, at which time there is no RTC available yet.
- rk808 is a module and is loaded much later (5 sec later), by which time it's too late.

Compare with a PC Workstation:

Code:

> zgrep -E 'RTC_(HCTOSYS|SYSTOHC|DRV_CMOS)' /proc/config.gz
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
CONFIG_RTC_DRV_CMOS=y

and thus

Code:

> sudo dmesg | grep rtc0
[    1.384356] rtc_cmos 00:04: registered as rtc0

RTC is loaded almost immediately and there are no error from hctosys.

Would it be possible to:
- either compile the RK808 driver as builtin? (CONFIG_RTC_DRV_RK808=y like the bug report mentionned above)
- or add a udev rule to `hwclock --hctosys` as soon as rtc0 is registered ?

The broken load order of the rtc subsystem is probably an issue, too though. Imho hctosys is missing a mechanism to defer loading unti the rtc dev appears. Adding the RTC module as a builtin does result in the correct load order since it uses a late initcall. I'm not sure I like that solution though.