Wake up the clock before loading rtc_ds1307 module #1020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.