hctosys not reading hardware clock on CM4

Bug #1926911 reported by Oliver Grawert on 2021-05-02
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ubuntu-core-initramfs
Undecided
Unassigned
linux-raspi (Ubuntu)
Undecided
Unassigned
Focal
Undecided
Unassigned

Bug Description

[Impact]

At boot, the kernel does not synchronize the system clock from an RTC, if the driver that manages the RTC device is built as a module.

[Test Case]

$ dmesg|grep rtc
[ 1.593561] hctosys: unable to open rtc device (rtc0)
[ 10.767256] rtc-pcf85063 10-0051: registered as rtc0

[Where Problems Could Occur]

Loading of the relevant RTC module (which then triggers a clock sync from the RTC) is handled by userspace. This could interfere with systemd (or some other entity) hat handles clock sync'ing which could yield unexpected results.

[Original Description]

There is a timing issue when using the CM4 with the official CM4 IO baseboard.

The CM4 baseboard comes with a built in rtc and a battery holder by default, to enable it a devicetree overlay needs to be enabled and a matching module gets loaded ...

$ tail -2 /run/mnt/ubuntu-seed/config.txt
dtparam=i2c_vc=on
dtoverlay=i2c-rtc,pcf85063a,i2c_csi_dsi,addr=0x51

$ lsmod | grep pcf85063
rtc_pcf85063 20480 0

When booting the kernel runs hctosys about 1.5sec into the boot, the rtc module only gets loaded about 10sec later though:

$ dmesg|grep rtc
[ 1.593561] hctosys: unable to open rtc device (rtc0)
[ 10.767256] rtc-pcf85063 10-0051: registered as rtc0

Looking at the systemd journal the clock does not get set at all, only a network connection actually triggers setting of the clock (note the timestamps in the journal):

---
Apr 26 10:27:53 ubuntu kernel: mmc0: SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
Apr 26 10:27:53 ubuntu kernel: hctosys: unable to open rtc device (rtc0)
Apr 26 10:27:53 ubuntu kernel: of_cfs_init
Apr 26 10:27:53 ubuntu kernel: of_cfs_init: OK
...
Apr 26 10:28:02 CM4 systemd[1]: Started Network Name Resolution.
Apr 26 10:28:02 CM4 kernel: rtc-pcf85063 10-0051: registered as rtc0
Apr 26 10:28:02 CM4 systemd-udevd[459]: Using default interface naming scheme 'v245'.
...
Apr 26 10:28:08 CM4 avahi.daemon[593]: Registering new address record for 192.168.2.32 on wlan0.IPv4.
Apr 26 10:28:08 CM4 systemd-timesyncd[495]: Network configuration changed, trying to establish connection.
May 02 17:14:17 CM4 systemd-timesyncd[495]: Initial synchronization to time server 91.189.89.199:123 (ntp.ubu>
May 02 17:14:17 CM4 systemd[1]: Starting Online ext4 Metadata Check for All Filesystems...
---

I think the loading of the rtc_pcf85063 module should trigger an additional hctosys call (preferably from the module itself, but worst case a udev rule calling out to hwclock --hctosys might work too)...

Just for the record, the hwclock works fine otherwise:

$ sudo hwclock
2021-05-02 19:56:11.281975+00:00

Oliver Grawert (ogra) on 2021-05-02
description: updated
Juerg Haefliger (juergh) wrote :

Which kernel?

Oliver Grawert (ogra) wrote :

ogra@CM4:~$ snap list pi-kernel
Name Version Rev Tracking Publisher Notes
pi-kernel 5.4.0-1035.38 282 20/edge canonical✓ kernel

Juerg Haefliger (juergh) wrote :

Seem focal:
$ uname -a
Linux rpi-cm4-rev1d0-e428 5.4.0-1034-raspi #37-Ubuntu SMP PREEMPT Mon Apr 12 23:14:49 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
$ sudo dmesg | grep rtc
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=0 bcm2708_fb.fbheight=0 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:D6:C8:D1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 net.ifnames=0 dwc_otg.lpm_enable=0 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc console=tty1 console=ttyS0,115200 loglevel=8 quiet splash
[ 1.974818] hctosys: unable to open rtc device (rtc0)
[ 3.658840] rtc-pcf85063 10-0051: registered as rtc0

Changed in linux-raspi (Ubuntu Focal):
status: New → Confirmed
Juerg Haefliger (juergh) wrote :

Hirsute looks fine:
$ uname -a
Linux rpi-cm4-rev1d0-e428 5.11.0-1005-raspi #5 SMP PREEMPT Mon Apr 19 09:04:31 UTC 2021 armv7l armv7l armv7l GNU/Linux

$ sudo dmesg | grep rtc
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=0 bcm2708_fb.fbheight=0 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:D6:C8:D1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 net.ifnames=0 dwc_otg.lpm_enable=0 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc splash console=tty1 console=ttyS0,115200 loglevel=8
[ 3.696219] fixrtc
[ 5.599830] rtc-pcf85063 10-0051: registered as rtc0
[ 5.606145] rtc-pcf85063 10-0051: setting system clock to 2021-05-03T09:25:07 UTC (1620033907)

Oliver Grawert (ogra) wrote :

hirsute does not have Ubuntu Core images ;)

It seems to be solvable via a simple defconfig change according to:

https://github.com/raspberrypi/linux/issues/4205

We have at least one UC customer implementing a CM4 baseboard with TPM for Full disk encryption and secureboot in UC20, for this the clock needs to be correct. The module also needs to move into the UC initrd so it can load before mounting disks, i added an ubuntu-core-initramfs task for this ...

Juerg Haefliger (juergh) on 2021-05-03
description: updated
Tim Gardner (timg-tpi) on 2021-05-07
Changed in linux-raspi (Ubuntu Focal):
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-raspi (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.