low voltage detected, date/time is not reliable

[keypunch416]

Creating a bug report/issue

Required Information

• DietPi version | 8.6.1
• Distro version | bullseye
• Kernel version | Linux DietPi 5.10.123-meson64 #22.05.3 SMP PREEMPT Wed Jun 22 07:23:04 UTC 2022 aarch64 GNU/Linux
• SBC model | N2 (aarch64) (N2+ 4GB)
• Power supply used | ALLPOWER 15VDC/4A
• SD card used | 32GB Kingston CANVAS Select Plus MicroSD 100MB/s A1

Additional Information (if applicable)

• Software title | DietPi
• Was the software title installed freshly or updated/migrated? Freshly installed and up to date as of this issue
• Can this issue be replicated on a fresh installation of DietPi? Yes

• Bug report ID | N/A

Steps to reproduce

1. Boot system
2. dmesg | grep -i -e volt
3. wait hours or days
4. dmesg | grep -i -e volt

Expected behaviour

• I would expect no power events to be found in dmesg

Actual behaviour

• [ 2.471411] rtc-pcf8563 0-0051: low voltage detected, date/time is not reliable.
  [ 2.472945] rtc-pcf8563 0-0051: low voltage detected, date/time is not reliable.

Extra details

• The power supply being used is oversized on purpose to ensure SBC does not have any shortages of power.
• This issue occurs every time system is booted
• Until other issues and yet to be effected SBC, Linux, and application changes are made a USB Keyboard and HDMI are connected. No other USB devices are connected. This has been case since first started using N2+ after received about 9 days ago.
• This is consistent issue on every boot and appears to be boot related based on timestamps of dmesg

[MichaIng]

Many thanks for your report.

This is very similar to #5654. You don't have an RTC battery attached, do you? It seems like the kernel complains about "low voltage" (well, no power at all) at the RTC, so until fake-hwclock and later network time sync are done, the system clock is out of date, like on every other SBC without any RTC or no battery attached.

[keypunch416]

fake-hwclock does not cause this reported issue nor does RTC out of date condition.

[MichaIng]

Of course fake-hwclock cannot report low voltage, since it is no real hwclock, or do I misunderstand what you mean?

The system clock will be roughly synced by fake-hwclock and finally synced by systemd-timesyncd, so there is no actual issue.

The kernel errors are as said likely expected as long as you do not have a battery attached to the RTC, but can be safely ignored.

[keypunch416]

Sadly it took weeks to find a CR2032 battery for the N2+ likely due to ongoing supply chain issues. Various stores I had gone to a few times and at different locations did not have CR2032 battery. By chance while in one of the stores for something else there were now some CR2032 batteries. That said the issue as reported still occurs with new just purchased CR2032 battery installed in the N2+.

2022-08-22 19:46:03 +0000 UTC : 1661197563 userid@hostname 6303DC54 tty0 ~ $ dmesg | grep -i -e volt
[ 1.181875] reg-fixed-voltage regulator-flash_1v8: Failed to register regulator: -517
[ 1.182415] reg-fixed-voltage regulator-vcc_1v8: Failed to register regulator: -517
[ 1.182485] reg-fixed-voltage regulator-vcc_3v3: Failed to register regulator: -517
[ 1.182633] reg-fixed-voltage regulator-vddao_1v8: Failed to register regulator: -517
[ 1.957286] reg-fixed-voltage regulator-flash_1v8: Failed to register regulator: -517
[ 1.957650] reg-fixed-voltage regulator-vcc_1v8: Failed to register regulator: -517
[ 2.554005] rtc-pcf8563 0-0051: low voltage detected, date/time is not reliable.
[ 2.555265] rtc-pcf8563 0-0051: low voltage detected, date/time is not reliable.
2022-08-22 19:46:25 +0000 UTC : 1661197585 userid@hostname 6303DC54 tty0 ~ $

[keypunch416]

I had the N2+ off overnight and just booted the N2+. No there is no messages re rtc-pfc8563:

2022-08-23 11:25:40 +0000 UTC : 1661253940 userid@hostname 6304B60C tty0 /etc/ntpsec $ dmesg | grep -i -e volt
[ 1.185897] reg-fixed-voltage regulator-flash_1v8: Failed to register regulator: -517
[ 1.186453] reg-fixed-voltage regulator-vcc_1v8: Failed to register regulator: -517
[ 1.186526] reg-fixed-voltage regulator-vcc_3v3: Failed to register regulator: -517
[ 1.186675] reg-fixed-voltage regulator-vddao_1v8: Failed to register regulator: -517
[ 1.994494] reg-fixed-voltage regulator-flash_1v8: Failed to register regulator: -517
[ 1.994862] reg-fixed-voltage regulator-vcc_1v8: Failed to register regulator: -517
2022-08-23 11:26:14 +0000 UTC : 1661253974 userid@hostname 6304B60C tty0 /etc/ntpsec $

Very odd when CR2032 battery was installed and in N2+ for 5 minutes prior to booting that there were rtc-pfc8563 log entries as reported for this issue.

That said as I recall when tested Manjaro Arch Linux a couple weeks ago where there was still no CR2032 battery in N2+ there were no messages re rtc-pfc8563 Hardkernel "official" release re issue 'Failed to register regulator' #5654 (#5654 (comment)).

[MichaIng]

Okay, so the RTC errors have been solved by attaching the battery, right?

I hope you did not buy the battery only to mute the error message: As long as there is no need to have an accurate clock during first seconds of boot process, or the system is often offline but needs to maintain clock, like a sensor or such, it can be simply ignored.

I'm also no friend of error messages, especially since they make it harder to debug actual problems. But in practice many kernel builds on many devices throw some, which are or must be ignored. Especially closer to mainline kernel builds do throw errors, since certain probing is often not done/foreseen before the "generic" kernel tries to load respective modules, respectively loading modules/features, throwing error messages, simply is the (unclean) probing 😉.

[keypunch416]

Noted RTC error as reported appear not to be occurring thus far, but bear in mind the RTC errors did occur after battery was installed. The noted errors still occurred after battery had been installed for 5 minutes before booting first time after battery was installed.

It was my intent before installing any OS to install RTC battery. It just took weeks due to ongoing supply chain issues before I could purchase some CR2032 batteries for the N2+. I wanted the RTC battery for two reasons. First for initial boot of kernel the RTC is in nowhereland with fakeclock or no battery installed for RTC. Fakeclock does not apply to N2+ as the N2+ has a RTC chip so the default N2+ image is configured for RTC via its I2C address and why I2C is enabled by default for the N2+.

I do know other images never reported any error for RTC with no battery.

Do not get me started on the Linux Kernel and Linux Kernel being ":clean". I will not explain what I know about the many unclean issues of the Linux Kernel that are only increasing in scope and/or severity. I have long given up on reporting Linux Kernel issues as the Linux Kernel developers have clearly demonstrated the inability to accept issues reported of many and just ignore any issues as matter of policy reported via venues that are normally used by almost all other open source projects.

I would be inclined to leave this issue open to all monitoring to see if better behaved in later Kernel. I think as excellent example of issue that should not be occurring is the issue I logged "Failed to register regulator" #5654 that should not be occurring and/or suggests some underlying issues in the Linux Kernel and/or N2+ Device Tree.

[MichaIng]

Fakeclock does not apply to N2+ as the N2+ has a RTC chip so the default N2+ image is configured for RTC via its I2C address and why I2C is enabled by default for the N2+.

But fake-hwclock still works when not disabled manually, it just takes some seconds before systemd stage is reached with starts it and sets the hwclock based on what was stored on shutdown before.

Before blaming Linux developers, not that you're using an open source product for free. It is pretty common and should be understandable that one cannot rely on every bug report (specially when it's visually only and no actual related issues can be observed) and wish being addressed soon or at all, as long as one does not fix it oneself or pays someone to fix it. And doing so for the Linux kernel upstream is even more difficult due to high quality standards and long review times through the mailing lists. In this particular case also one needs to find out whether it's really something missing/wrong in plain Linux for this SBC/SoC or related to downstream patches applied by Armbian which e.g. became obsolete or faulty with Linux v5.15 or so.

I'll close those this issue then.

[keypunch416]

Understand the concept of Open Source very well. Lets just say I know things about the Linux Kernel in terms of very very serious bugs that not only have been going on for years, but have continued on path to much worse. These very very serious bugs are being compounded by poor design choices compounded by more and/or bugs and other Kernel issues.

Before you say I should report such very very serious issues be aware I tried and long since gave up trying to as the Linux Kernel community has own very defined circle of those that take serious as well as it was shocking for me to have response of Kernel developers how such tests for such issues are determined. I know what I am speaking about and suffice to say such responses and push back to addressing of software or hardware issues and bugs is universal. Universal meaning this has noting to do with of Open Source, Closed Source, Source of business applications companies develop for doing their business, of OTS solutions. Likewise for hardware. I know as I worked in the domains of software and hardware from embedded systems to mainframes and and software engineering companies to companies including with software engineering companies providing solutions for well know multinational companies.

This issue as noted could be Device Tree related. Though there is Device Tree code in the Linux Kernel Source is is really hardware code determined by ARM based hardware used in SBC designs which means that Device Tree issues or lack of Device Tree elements is a hardware vendor issue. I do not have skills or knowledge of Device Tree for SBC hardware to fiddle or test, but I do know this issue are reported with no battery in N2+ did not occur with Arch Based N2+ images. I would thin it makes sense to encourage SBC hardware makers to ensure they have the needed Device Tree and Linux Kernel support not just for this issue, but for:

#5639 "Odriod N2+ Does not Boot from eMMC"
#5644 "GPIOD missing GPIO 85 to at least GPIO 495"
#5645 "Unable to enable SPI /dev/spidev0.0"
#5654 "Odroid N2 | Failed to register regulator" that still exists and related to this issue

If such issues are addressed in later versions of Linux Kernel then it makes sense to give serious consideration to using later version of Linux Kernel. To suggest someone build and use later version of Linux Kernel is not appropriate as for sure anyone reporting an issue would be force to do test with the version of Kernel as provided by image/updates. That could very well mean the tests on Kernel of image cannot be done as the need for using later Kernel means the reason for using later version of Kernel is because the Kernel with image will not provide the basics of what is needed in later version of Kernel.

[MichaIng]

I cannot evaluate whether Linux upstream developers, SBC manufacturers or SoC manufacturers are more to blame for these SBC/SoC specific issues. The truth is likely in the middle between SoC manufacturers not producing open source hardware, SBC manufacturers not consequently trying to push all their custom kernel patches upstream, and Linux development making it not sufficiently easy for manufacturers to have their patches or new drivers merged, likely also because of high quality standards which we actually want for a kernel.

However, since it works, and large companies with high security and reliability standards use Linux, also on said platforms, I tend to put this into perspective and wouldn't rate the issues as critical as you seem to. Some features require patches or device trees yes, there are kernel errors which do not look great yes, but the hardware otherwise runs without obvious stability issues and nobody of tenth or hundreds of thousand users reported serious SBC/SoC-specific security vulnerabilities related to these missing kernel patches/features. Also that it is as it is, indeed not perfect, is long known, also with RPi, so one simply needs to decide whether to accept it and run ARM SBCs, or go with the much more standardised x86_64 hardware instead, where upstream and e.g. regular Debian kernel builds run without any such kernel errors during boot.

[mkavalec]

I had the same issue on N2 with original Odroid image and found this discussion while trying to solve it. At the end I realized that the solution is very simple. It's necessary to pay attention and install the battery correctly :) https://discourse.coreelec.org/t/battery-connections-on-n2-board/12422

[MichaIng]

Hehe, yes the battery is essential, of course. I find it nasty that there is, AFAIK, no way to check from a running system whether a battery is properly attached or not. That would also allow us to purge the fake-hwclock package on first boot, if a battery is present. On a running system, all one can see/check is that the hardware clock is powered, not allowing any differentiation between battery-powered and SBC-powered.

[dipen-sls]

We recently had new board with pcf8563 on Linux Kernel v5.4.125 and found low voltage issue with RTC with or without battery inserted.

• We checked these is reproducible on many boards.
• The error goes away, if we do soft reset via command line or reset via power button.
• Issue comes back if remove power supply and apply again (ie power cycle)
• We also checked VDD supply and found stable 3.0V - 3.3V so not sure why this occurs on first boot and detects the low voltage.

Checking kernel driver, it supports IOCTL for RTC where RTC_VL_CLR switch case where forcefully Low Voltage register being cleared by writing seconds in that register. In our case, IOCTL is not being clocked by hwclock userspace.

Any suggestion to overcome ?

Dipen Parmar

[MichaIng]

@dipen-sls
Please try it with a more recent kernel. For Odroid N2 we offer Linux 6.6.65 in the meantime.