Raspberry Pi Compute Module 4 Board RTC (pcf85063a)

Hello everyone.

I’ve got a CM4 with the onboard Wi-Fi, loaded it with the official Canonical UC20 image.
It seems that I cannot get the RTC working on boot. But when I “load” the driver (modprobe rtc-pcf85063) manually and invoking the i2c new-device add, it works, and is detected in hwclock.

I can can confirm that I can do a i2c scan, and detect the RTC on Address 0x51 on i2c-11 (snappy.i2cdetect) as per datasheet/document of the Raspberry Pi CM4 Board.
What seems to be the problem with the dtoverlay?
I’ve tried everything mentioned here: https://www.raspberrypi.org/forums/viewtopic.php?t=293632
And still hitting a brick wall.
dmesg only states that two i2c muxes is added, nothing related to the RTC itself.

Do I have to wait for a kernel/update to fix this issue that I have? I have refreshed all my snaps, all up to date.

BR

We’re discussing it with the kernel team for the whole day already :slight_smile:

If you follow my guide you will see /dev/rtc showing up but there is a “hwclock --hctosys” call missing in the whole setup … the github issue i linked has a udev rule you can put in place as a temporary hack in /etc/udev/rules.d that will then set your clock from the rtc during boot…

1 Like

Hi…You’ve picked a RTC for which the portion driver isn’t underlying the standard Raspberry Pi part configs (RTC_DRV_PCF85063 isn’t characterized). You’ll in this manner need to construct a custom portion which incorporates that module.

To really design the RTC you need a gadget tree overlay, as per i2c-rtc-overlay.dts, yet as you’ve included it GPIOs 44&45 for BSC0 you need to interface your DT hub to i2c_csi_dsi rather than i2c_arm.

You likewise need to empower hubs i2c0if and i2c0mux as the parent hubs to the I2C regulator with the goal that your overlay empowers all as opposed to requiring dtparam=i2c_vc=on also.

Thanks, I’ll have a look at it soon, since I was unable to compile a kernel with RTC_DRV_PCF85063 as a module, because UC20 had some problems with kernels not booting on the board (datetime was out of whack when kernel starts, then secure signatures fail, because they were signed in the “future”.)