We ship units which have an expected life in the field of ten to twenty years. They include an RTC with a replaceable coin cell. Most of the time the machines will be powered on, so the RTC battery is sitting with no drain. In these circumstances we find that most batteries will retain adequate charge for short power cuts for well over ten years.

Nevertheless, over hundreds of systems, a small percentage of failures is still a thing to be dealt with.

On all previous models that has just meant that the clock runs along at 1-Jan-2000 or something for a few minutes till we can get an NTP fix. The hassle with that is that it can cause e2fsck panics and logged data with bad dates.

What I'd prefer to do is to have a look in the RTC inside u-boot, and if it doesn't look plausible ( before 2017 is probably good enough, checksum in RTC RAM would be even better, boot to a recovery partition. Then the code in that partition could get an NTP fix and put it in the RTC, then s/w reboot, which should of course them boot to the main partition. So a couple off questions:

  1. Does the uboot have the ability to get to the RTC.

  2. Do I just have to write some custom C or if this doable without custom code?

  • If your solution is good enough for a dead RTC battery, Why bother with a RTC at all? – Steve Robillard Aug 12 '17 at 20:53
  • Isn't it sufficient with adding a rc.local check if year is less than 2017, then set year to 2017... – MatsK Aug 12 '17 at 22:25
  • And I think you should reconsider the solution. In 2025 when a dead RTC is occuring, then it will set it to 2017, then will NTP adjust it to 2025 and you can still get a panic situation, consider to solve it with e2fsck.conf, and broken_system_clock parameter. – MatsK Aug 12 '17 at 22:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.