STM32MP135F-DK: RTC resets to 2024 after reboot beyond Y2038 on OpenSTLinux (Scarthgap)

[zoro]

Hi,

I am working with the STM32MP135F-DK board and built an SD card image using Yocto Scarthgap (openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06).

The image boots successfully. To prevent the Year 2038 (Y2038) problem, I confirmed that require conf/distro/include/time64.inc is already included and processed in the distro configuration.

To test Y2038 compliance, I manually set the system time to the year 2040.

The time was set successfully, and verifying it via the date command showed the correct time (2040).

Checking the RTC using hwclock --show --verbose also returned the correct time in 2040.

NTP is explicitly disabled via timedatectl set-ntp false, so network time synchronization is not causing any interference.

The Problem:
The issue occurs upon a reboot. After the system reboots, the time rolls back to the year 2024.

My Analysis:
Upon looking into the Linux kernel source (drivers/rtc/class.c), it appears that the kernel clamps or prevents system time overflow. This seems to be a fallback mechanism to prevent userspace applications (like older 32-bit time_t systemd versions) from malfunctioning or crashing.

My Workaround:
As a temporary fix, I created a custom systemd service that runs during the boot process to manually sync the RTC time to the system time. With this service enabled, the board successfully retains the year 2040 even after multiple reboots.

My Questions:

Is this manual systemd workaround an acceptable or recommended approach for handling Y2038 on OpenSTLinux?

Is there an official, standard, or more robust way recommended by ST to handle the RTC restore properly beyond 2038 without this manual workaround?

Any insights or recommendations would be greatly appreciated.

Thanks in advance!

[Bernard PUEL]

Hello,

About Y2038 issue, user space is not yet ready in the community.

Here are some advise = https://wiki.st.com/stm32mpu/wiki/How_to_prevent_the_year_2038_bug 

[zoro]

Hi Bernard,

Thank you for your answer.

Since it is not officially supported yet, I think I will have to stick with my current workaround for now.

For your reference link, the solution in the link you shared has already been applied. As mentioned in my original post: "To prevent the Year 2038 (Y2038) problem, I confirmed that require conf/distro/include/time64.inc is already included and processed in the distro configuration."

Thanks again for your help!