Hi all,
I am having an issue with my P550 board and that is the hardware clock is not keeping time when power is completely disconnected for a time after the hwclock being set in OS(Fedora 42).
It resets itself to 1970-01-01 01:01:37.011085+01:00.
Anyone else noticed this issue ?
Did you install a battery for it? It doesn’t come with one.
Yes I have installed a fresh new battery.
Ive had this issue confirmed by someone else also running Fedora 42..
Have tried Ubuntu and same issue.
Has no one else experienced this issue ? or can test and see if they have this issue ?
It’s definitely not working. Easily seen in dmesg.
Feb 21 13:18:36 p550 systemd[1]: rpc-gssd.service - RPC security service for NFS client and server was skipped because of an unmet condition check (ConditionPathExists=/etc/krb5.keytab).
Feb 21 13:18:36 p550 systemd[1]: Reached target nfs-client.target - NFS client services.
Feb 21 13:18:36 p550 systemd-oomd[693]: No swap; memory pressure usage will be degraded
Feb 21 13:18:36 p550 systemd[1]: systemd-pstore.service - Platform Persistent Storage Archival was skipped because of an unmet condition check (ConditionDirectoryNotEmpty=/sys/fs/pstore).
Feb 21 13:18:36 p550 systemd[1]: systemd-repart.service - Repartition Root Disk was skipped because no trigger condition checks were met.
Feb 21 13:18:36 p550 systemd[1]: Started systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer.
Feb 21 13:18:36 p550 systemd-resolved[695]: Positive Trust Anchors:
Feb 21 13:18:36 p550 systemd-resolved[695]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Feb 21 13:18:36 p550 systemd-resolved[695]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.>
Jun 09 15:21:56 p550 systemd-timesyncd[697]: System clock time unset or jumped backwards, restored from recorded timestamp: Mon 2025-06-09 15:21:56 PDT
Jun 09 15:21:56 p550 systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
Jun 09 15:21:56 p550 systemd[1]: Finished systemd-update-utmp.service - Record System Boot/Shutdown in UTMP.
Jun 09 15:21:56 p550 systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon.
Jun 09 15:21:56 p550 systemd[1]: Started nfsdcld.service - NFSv4 Client Tracking Daemon.
Jun 09 15:21:56 p550 systemd-resolved[695]: Using system hostname 'p550'.
Jun 09 15:21:56 p550 systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jun 09 15:21:56 p550 systemd[1]: Reached target nss-lookup.target - Host and Network Name Lookups.
Jun 09 15:21:56 p550 systemd[1]: Reached target time-set.target - System Time Set.
Jun 09 15:21:56 p550 systemd[1]: Finished cloud-init-local.service - Cloud-init: Local Stage (pre-network).
Jun 09 15:21:56 p550 systemd[1]: Reached target network-pre.target - Preparation for Network.
This is by design, I think. If you look at the schematic of the carrier board:
The battery is connected to RTC_VBAT. Then RTC_VBAT is connected to the STM32 MCU:
The battery is not connected to the EIC7700 SoC. Thus, only the RTC clock inside the STM32 MCU can be kept running. I confirmed this with my board and each power cycle the EIC7700 SoC resets the RTC date/time, even if the power cord is still attched (5V standby from ATX power is always ON). From the MCU console, I can see the MCU date/time is being properly preserved and updated both with and without the power cord connected. Conclusion: this is a limitation of the carrier board by design. Only way to implement the feature I can think of is for the es-bmcd daemon to fetch the MCU time from the SoC side, but I did some reverse engineering of the binary, and currently this SoC > MCU request channel is not there. There’s the channel the other way around – MCU → SoC, where MCU can request some hwmon information from Linux, or request orderly shutdown of Linux.
My advice is not to waste time on this. systemd can already set the wall clock to the the last shutdown time on boot. After boot, timesyncd can use NTP to sync time. If you indeed need it, use a dedicated RTC instead.
