RTC can't hold time the after system rebooted in L4T 35.1

Hi NV

RTC can’t hold the after system rebooted in L4T 35.1 version AGX Xavier developer kit
I confirmed it worked fine in L4T 32.71 with same developer kit.
Here is my steps:
(1) Set system date and RTC time and read it back.

(2) System reboot. Then read system date and RTC time again.
The red block of the following image showed that RTC time became a wrong value.

Looks like regression for r35.1
Will update once get solution for it.

Modify the /lib/udev/rules.d/50-udev-default.rules to below for the problem.

SUBSYSTEM=="rtc", ATTR{hctosys}=="0", SYMLINK+="rtc"
SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc", OPTIONS+="link_priority=-100"
1 Like

Hi @ShaneCCC

Confirmed your method.
Seems It’s a workaround that use RTC0 as system date’s RTC source.
But RTC1 still got a wrong date after reboot:

Does Nvidia have any plan to fix RTC1’s issue?
Will the issue be fixed in Jetpack5.1?

Hi,

Do you have a battery connected in your setup?

Also, if you are asking if “RTC1” will get fixed, then the answer is no. It won’t get fixed.
Only RTC0 can keep the time across boot.

Hi @WayneWWW

I have done the same experiment on the same AGX Xavier developer kit with L4T 32.7.1.
RTC0 and RTC1 both worked fine.
So I don’t think the battery is the problem.
You can see the following images about the experiment result.
I am surprised the RTC1 won’t get fixed.
So the tegra_defconfig’s option CONFIG_RTC_HCTOSYS_DEVICE=“rtc1” will change as rtc0 in NVidia’s next version?
(1) Set system date and RTC time and read it back. ( L4T 32.7.1)
Screenshot from 2022-10-25 10-32-39

(2) System reboot. Then read system date and RTC time again. ( L4T 32.7.1)

Hi Share

Sorry. About previous method from you.

The system date still is wrong. I missed to compare the system time and RTC0.
You can see there are still not consistent.
image

So we don’t have any workaround or solution for the RTC issue.
Can you help to solve it?

Do you reboot the system or remove the power?

Please set the date time by sudo date -s “2022/11/04 15:30”
RTC time by “sudo hwclock -w /dev/rtc*” the reboot to verify.

1 Like

Hi @ShaneCCC

Confirmed your workaround can’t work.
Because the workaround is only create an symbolic /dev/rtc to /dev/rtc0.
That only can make timedatectl show a correct RTC time from rtc0.
But the system time sync mechanism is done by kernel driver.
You can check the dmesg to see it.
Provide a correct workaround: Set the option CONFIG_RTC_HCTOSYS_DEVICE as rtc0 in tegra_defconfig
After changed the option, the local, universal, and rtc time are all correct.

2 Likes

Looks like for r35.x release need to modify CONFIG_RTC_HCTOSYS_DEVICE

1 Like

We also have the same problem , can’t keep RTC data after reboot.

In my case, I build the kernel.
so, is there proper patch to the kernel to solve the issue?

@matanh
Modify kernel configure to modify CONFIG_RTC_HCTOSYS_DEVICE to rtc0 to build new kernel for it.

Thanks

1 Like

@ShaneCCC that didn’t work. I will able to continue working on it next week only. (but posting this message to hold the topic closure 14 days after the last reply)

@matanh
Please review all comment of this topic.
Suppose it should be worked and confirm by neil.lee1

is there way to ensure that the modification on the defconfig been applyed?

By the way, using the “proper” way to change the defconfig (‘make menuconfig’) there seems to be some problems on the Kconfig definitions because some lines are removed for example ‘CONFIG_NVVRS_PSEQ_RTC’.

But more major issue is the CONFIG_RTC_HCTOSYS_DEVICE is remove from the defconfig

ok, tested again. and solution works for me.
but notice to the note from the above replay

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.