balena-os / balena-raspberrypi

Balena support for RaspberryPI boards
https://www.balena.io/os/
Apache License 2.0
190 stars 73 forks source link

hwclock & fake-hwclock support #117

Open tetherit opened 7 years ago

tetherit commented 7 years ago

The Raspberry Pi doesn't have an RTC so if the unit fails to get the correct time, it can have trouble connecting to the OpenVPN server. I had that happen on a few networks where NTP was blocked and the unit was not able to connect.

For the Raspberry Pi units that don't have a physical hardware clock, the fake-hwclock package is very useful as it ensures that the clock moves forward after reboot and prevents the time going back to the year 2000.

An even better solution is to add this little device: https://www.ebay.co.uk/i/253056413179?chn=ps&dispItem=1&adgroupid=41920510205&rlsatarget=pla-325751485803&abcId=1128926&adtype=pla&merchantid=109797754&poi=&googleloc=9045006&device=c&campaignid=856841495&crdt=0

To set it up on the RPI, you run:

echo ds1307 0x68 | tee /sys/class/i2c-adapter/i2c-1/new_device

After that, the command hwclock starts to work:

root@resin:/# hwclock   
Sat Jan  1 23:18:01 2000  0.000000 seconds
root@resin:/# hwclock -w
root@resin:/# hwclock
Mon Aug 14 17:19:11 2017  0.000000 seconds

It would be great if support for the above was added to ResinOS out of the box.

Front logo Front conversations

floion commented 7 years ago

Hi, thanks for the report. @shaunmulligan would you consider we look into adding fake-hwclock for cases where the network blocks NTP? Or we consider NTP unblocking as a hard dependency which we absolutely need and hence we don't cover cases where this happens?

shaunmulligan commented 7 years ago

@floion I don't really know enough about these mechanisms, but it sounds reasonable to me. I would defer to @agherzan and @petrosagg to make the actual decision though

floion commented 6 years ago

ping @agherzan @petrosagg

SloMusti commented 6 years ago

@agherzan @petrosagg any info on the above? I am adding RTC DS3231 clock to the resin device that should operate in the following way:

agherzan commented 6 years ago

Hi @SloMusti. Did you try to setup the hwclock for the user container? Did you encounter any issues with that?

SloMusti commented 6 years ago

@agherzan above instructions work in the user container, but it be great to have hwclock support on the host

imrehg commented 6 years ago

@SloMusti what kind of device is that, one of the Raspberry Pi family? If so, you can try to use dtoverlay=i2c-rtc,ds1307 in the config.txt (which you can set remotely as well: https://docs.resin.io/reference/resinOS/advanced/#modifying-config-txt-remotely) As much as I checked, that should support DS3231 as well.

If not a Pi, then probably need some extra investigation.

LuisPinaSoares commented 4 years ago

@imrehg @agherzan For me it seems to work. But i have one doubt, is the RTC being updated by some NTP related task running on the background of Balena OS? Or do we have to be responsible for maintaining correct RTC time (RTC can lag depending on quality) using a specific service like this one: https://github.com/balena-io-playground/balena-rtc-multicontainer.

https://github.com/balena-io-playground/balena-rtc-multicontainer -> In this example the container time is updated with the RTC time. I mean the reverse case, if there is the need to check some NTP and compare with RTC and updating both system time and RTC time or if this is done transparently on Balena OS.

If the answer to the doubt is yes, so you guys on balena OS disable the fake-hwclock in this cases?

LuisPinaSoares commented 4 years ago

You can answer but it seems to be answered here, sorry. https://forums.balena.io/t/current-state-of-hardware-rtc-support/6727/17