cm3588 nas - rtc device

[Marco Schirrmeister]

Just an information about the `edge` kernel (6.18) when used on the cm3588-nas system.

 

The rtc driver is not initialized on a `poweron`.

 

After a poweron, you will see the following in the log.

Nov 11 01:17:10 uhutest kernel: rtc-hym8563 6-0051: could not init device, -6
Nov 11 01:17:10 uhutest systemd[1]: System time advanced to built-in epoch: Tue 2025-11-11 01:17:09 CET

 

If you have `fake-hwclock` running, you will see the following a moment later. fake-hwclock restores the time, but the service will not properly start, because of the rtc device error.

Nov 11 01:17:12 uhutest fake-hwclock.sh[461]: Restoring saved system time
Nov 20 13:22:43 uhutest fake-hwclock.sh[466]: Thu Nov 20 01:22:43 PM CET 2025
Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Cannot access the Hardware Clock via any known method.
Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Use the --verbose option to see the details of our search for an access method.
Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Main process exited, code=exited, status=1/FAILURE
Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Failed with result 'exit-code'.
Nov 20 13:22:43 uhutest systemd[1]: Failed to start Restore system time on boot and save it on shutdown.

 

You would need to restart the fake-hwclock service, if you want that it saves time before the next restart.

 

If you do a `restart` of the system, the rtc device will get properly initialized and time is good. Following is seen in the logs.

Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: registered as rtc0
Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: setting system clock to 2025-11-20T12:26:11 UTC (1763641571)

Nov 20 13:26:16 uhutest fake-hwclock.sh[455]: Not restoring old system time

 

I have seen the issue right now only with the 6-18-RC kernel. The following patch mentioned here works as a pure workaround. https://patchwork.kernel.org/project/linux-rockchip/patch/20220608161150.58919-2-linux@fw-web.de/

Lets see how the development of kernel 6.18 goes and if the final version will not have this issue.

[Marco Schirrmeister]

This also happens on other kernels. Issue is present on final 6.18.0 kernel as well as on the older 6.12 kernel.

It seems to be related to some kernel options that are set to "m". Need to figure out which kernel options would need to be set to "y" (built-in) on Armbian to avoid this issue on power-on.