-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wake up the clock before loading rtc_ds1307 module #1020
base: master
Are you sure you want to change the base?
Conversation
Under Fedora 39 with kernel 6.5.6, loading the module rtc_ds1307 does not result in a functioning RTC. The clock needs to be read (woken up?) before the module is loaded. This change adds a read of the clock with a timeout. In addition, the /dev/rtc device file takes a fraction of a second to load so the test for its existence alway fails. A 1 second sleep gives time for the file to be created. It's not clear to me if eventually this will be required for Raspberry OS when it eventually gets to the 6.5.6 kernel. However it seems this change should always work on kernel 5. Also fix a misspelling of module in the success message.
When the RTC is reset to 0, for example from a loss of battery, it wreaks havoc on the systemd log and probably other subsystems. systemd will set the system time based on a recent file timestamp in the filesystem (how it does this depends if chrony or systemd.timesync is being used). But then when rtc_ds1307 loads, the kernel module sets the system time to the RTC's Jan 1, 2000. If network time is running it will eventually figure it out but the logs are messed up with the huge jumps in time. The best place to address this is just before the modprobe of rtc_ds1307. If the year is 2000, then most certainly the RTC has been reset. The convenient SetTime() method sets it to the current system time which is most certainly much closer to the correct time than year 2000.
Hold off on this one. I just realized that fedora's 6.5.6 package has an error and the dtb folder doesn't get created. When I addressed that, this fix didn't work. |
This can be reopened as is. It seems the user's fedora should be switched to firmware DT. As a result this PR works just fine. |
Latest fixes in Fedora 39 Beta change device tree, both f/w and kernel. The changes break hwclock. Closing this PR while a solution is investigated. |
The pid file doesn't get cleaned up when the service is stopped and also doesn't get cleaned up on an uninstall. Remove the pid file in the "stop" routine. Add a couple of helpful status messages regarding starting and looking for the RTC.
The solution for Fedora 39 is changes to the systemd unit file and rpm spec files. This pijuice_sys.py script works correctly as is. |
Under Fedora 39 with kernel 6.5.6, loading the module rtc_ds1307 does not result in a functioning RTC. The clock needs to be read (woken up?) before the module is loaded. This change adds a read of the clock with a timeout.
In addition, the /dev/rtc device file takes a fraction of a second to load so the test for its existence always fails. A 1 second sleep gives time for the file to be created.
It's not clear to me if eventually this will be required for Raspberry OS when it eventually gets to the 6.5.6 kernel. However it seems this change should always work on kernel 5.
Also fix a misspelling of module in the success message.
Tested on Raspberry OS bullseye by copying the pijuice_sys.py file over the old one and restarting the service. Then restarted the RPi checking systemctl status pijuice and sudo hwclock -r. Finally powered off, removed power (without a battery to reset RTC) and booted up. All the same checks and running fine. I have a generic Raspberry OS install running systemd-timesyncd for network time.