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
** Also affects: linux-raspi (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: linux-raspi (Ubuntu Focal)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-raspi in Ubuntu.
https://bugs.launchpad.net/bugs/1926911
Title:
hctosys not reading hardware clock on CM4
Status in linux-raspi package in Ubuntu:
New
Status in linux-raspi source package in Focal:
Confirmed
Bug 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1926911/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
