Hi Zymbit and Community!
Installation went perfectly well thanks to your [Getting Started Guide] (https://community.zymbit.com/t/getting-started-with-zymkey-3i/142/14) (blue led blinking once every 3s)
I will have to encrypt my SD so that proprietary software sources are protected. I will follow your guide about this and let you know
But before going further, I wanted to test my Node.js web app. As it needs session, it needs a proper system time set. Now that I’ve replaced my DS3231 RTC with the key, I can’t manage to get a correct time configured while/after booting. What would be the procedure to get correct time setup?
With the DS3231, after first installation, it was needed to set system time from
ntpdate-debian, then to save this to DS3231 using
sudo hwclock -w.
/sbin/hwclock -s command in
/etc/rc.local script would then correctly reset system time after any reboot.
(following this guide)
How do I get a similar behaviour now that I’ve installed zymkey 3?
Thanks for your answers
Hi again, Will!
Thanks for the question.
The time in the RTC in the Zymkey is set at the factory and is meant as a safeguard during system boot to insure that a “sane” time is in place before NTP runs or in the case where network connectivity is impaired and NTP doesn’t run. Given that Raspbian and friends are a moving target, we elected to not develop any kernel modules for the RTC and, therefore, the stock Linux components (e.g. hwclock) won’t work with Zymkey’s RTC.
Instead, our approach was to keep everything in user space and in systemd. During boot, we currently have a systemd script that checks zymkey for a more recent time than the last one that RPi captured and stored on disk during the last proper shutdown.
This means that, if everything is properly configured and running, the system time (GMT) should be initially set to zymkey’s time before NTP has had a chance to run. You should be able to see this in the console.
Also, we understand that RTCs drift with time and temperature, so we have a feature planned for a future release which will update the Zymkey’s time periodically if needed during normal operation.
Hope this answers your question.
Good to hear from you…
OK, I get the design choices made for the Zymkey.
In my case, main usage for the PI is to boot offline (no network connection available), it emits its own WIFI (access point mode) without password. PI is configured to share its internet connection whenever connected to a router using ethernet.
The PI is usually plugged out after usage (a few hours)… so no proper shutdown scripts are currently called is that a problem regarding the zymkey way of doing things?
I understand that as NTP can not be run successfully while booting offline, Zymkey should set the system time, even if last shutdown wasn’t properly done.
Currently, once booted (either ethernet connected or not) , I log in via ssh, and I get
Last login: Fri Jan 2 02:12:09 1970.
Once logged in:
pi@xxx:~ $ date vendredi 2 janvier 1970, 02:26:39 (UTC+0100)
(friday Jan, 2nd, 1970 …)
Now how can I ensure that the systemd boot scripts are correctly run?
When you say:
You should be able to see this in the console.
Where do you refer I should check?
How can I check the time currently stored in the Zymkey?
I’ve done nothing more than the installation scripts on an existing system, so would a previous DS3231 RTC configuration be in conflict with Zymkey?
Is it possible that my previous config has somehow made the date overwritten in the Zymkey?
Sorry to have so many questions for such trivial things, I’m more into devs than in Linux
4 last lines of
#cat /var/log/syslog | grep Zymkey:
Jan 1 01:00:07 ____ systemd: Starting Restore System Clock from Zymkey... Jan 2 09:17:58 ____ systemd: Started Restore System Clock from Zymkey. Jan 2 09:17:58 ____ systemd: Starting Zymkey Interface Connector... Jan 2 09:17:58 ____ systemd: Started Zymkey Interface Connector.
In python, trying to get time form zymkey
print('get_time(): ' + str(zymkey.client.get_time()))
It appears factory set time on the zymkey has been overwritten by some operations of mine…
For the DS3231 I had to update /boot/config.txt, and forgot to remove before starting the software installation procedure
Might this have something to do with a possible rewriting the key?
Hi, I dont want to hijack from Wiill but out of interest what is the protocol and DNS/IP ranges needed for the RTC module to get its time from your cloud system?
Is it possible to not use the Zymbit RTC module on the Pi and use another external module to do the job? Strange question but we have another board that has a builtin RTC module and would rather use that but still use your product for the encryption.
Sorry for the delay in responding. If you enter
sudo systemctl status zkbootrtc and a line which says something like
Jun 12 21:17:04 raspberrypi zkbootrtc: /sbin/zkbootrtc: using system time
is displayed, then the Zymkey has lost it’s time reference. This issue could have been caused by the removal of the coin cell battery at some point.
Based on your attempt to get the time from a Python script, it looks to me like the Zymkey has indeed lost its time reference. We will be issuing an update to the Zymkey software that will automatically keep the RTC up to date to compensate for drift while the host is running. In your case, the time should be restored with this feature as long as the coin cell is not dead and if the host is able to get a stable fix on time via NTP over internet.
Also, the dtoverlay that you mentioned should have no bearing on the Zymkey time.
I’ll keep you posted on the Zymkey software update. It should be ready by Tuesday next week.
No problem with the hijacking. It’s not really that, it’s about answering questions and helping out
To answer your first question, we don’t use any cloud components to keep Zymkey time up to date…
the post has to be cleaned up
. As I mentioned in my response to wiill, we will be issuing a release that will just update the Zymkey time per latest system time on the Pi. In the usual use case, the Pi will have internet connectivity and will have NTP running, so this should be sufficient for keeping the time in bounds.
As for your second question, it is easy to disable the Zymkey boot time update. Simply disable the zkbootrtc service with:
sudo systemctl disable zkbootrtc
This will stop the service from running for all subsequent reboots.
Thanks for your feedback, no problem!
Can’t wait for next tuesday
In the meantime, here is the output for the
sudo systemctl status zkbootrtc
pi@____:~ $ sudo systemctl status zkbootrtc ● zkbootrtc.service - Restore System Clock from Zymkey Loaded: loaded (/etc/systemd/system/zkbootrtc.service; enabled) Active: inactive (dead) since jeu. 1970-01-01 23:50:18 CET; 49s ago Process: 422 ExecStart=/sbin/zkbootrtc (code=exited, status=0/SUCCESS) Main PID: 422 (code=exited, status=0/SUCCESS) janv. 01 23:50:18 ____ zkbootrtc: /sbin/zkbootrtc: system time was initially 9.000219131. Time is now 82218 janv. 01 23:50:18 ____ systemd: Started Restore System Clock from Zymkey. pi@____:~ $ date jeudi 1 janvier 1970, 23:52:08 (UTC+0100)
Hope the coin cell is allright…
Just wanted to let you know that the RTC update is now available. However, the URL for the apt repo has changed. Please see the notice Zymkey apt repo url has changed.
This change will now set a correct Zymkey time when the Zymkey time goes bad for any reason (coin cell goes flat or is removed). Also this post (Using the Real Time Clock (RTC) on Zymkey) has been updated with the relevant notes at the bottom.
Thanks for all the updates, worked like a charm, now I will closely look after the offline usage of my Pi to check if there are any issue left with the coin cell… But resync has been made and my web app sessions are all OK.
Now proceeding with the encryption… see you
Please forgive me if this is a silly question but will your product work if a coin battery isn’t inserted if an RTC module is already installed on the Pi?
Our product will be offline for possibly up to a week so NTP isnt available to keep the Zymbit in check. The current RTC module we use has a very low drift and highly accurate so want to keep this. Ideally we’re trying to keep costs down and avoid installing 2 coin batteries in each product.
We will be using your product for partition encryption
In the current products, the coin cell is only needed for RTC. You can safely remove it if you don’t need the RTC functionality.
Out of curiosity, how would you manage to do so? I mean about the reconfiguration of which pins your RTC module would be plugged on, since the Zymkey takes the 10 firsts… This could be an option on my side as well, to keep a separate RTC module and use the Zymkey for encryption (my primary need for the Zymkey was for encryption, but I had to remove my DS3231 and rely on the Zymkey RTC)
To be honest Ive never tried to do this before so i was wondering whether i could solder the RTC onto the same pins and disable the Zymkey own RTC. My knowledge on this sort of stuff is very limited, i tend to learn by playing around. Obviously it may not be work, no idea!
Maybe the guys at Zymbit could answer this better than myself?
We thought it might be helpful to your discussion if we published the specification of our RTC, compared to the DS3231 and compared to what you might reasonably need in a typical commercial application. Under most circumstances the standard RTC onboard Zymkey should be good enough, which saves you time and money on integrating additional hardware and interface code.
(Post is in the main body, copied here for convenience).
##Accuracy of RTC
Zymkeys with integrated RTC are supplied with Standard Accuracy calibration. This is generally suitable for commercial applications that are not exposed to extreme temperature ranges and not disconnected from NTP for months on end. (see specs below)
An optional High Accuracy RTC are available, providing additional stability over extended temperature ranges.
I’m new with zymkey. For my project, I need a RTC to maintain time as my device won’t be powered up all the time and won’t have any network connection (RJ45 or Wifi).
Is it possible to use the zymkey as main clock source? If the time drifts, will it be possible to adjust it manually, without ntp?
Thanks in advance,
Zymkey would be able to provide a stable time reference when your host computer boots up. From that point on, you can reference the time using the standard libraries (e.g. time function call in C or date command line utility). However, the host pi clock will continue to drift independently after the boot-time reference is obtained from Zymkey. Another option would be to call the Zymkey API to get the clock in C/C++/Python.
We don’t expose an API which would allow one to set the Zymkey RTC since Zymkey is considered to be a secure device. Instead, an interface daemon determines when NTP is synchronized and enabled and sets the time from the current system time.
Hope this helps.
Thanks for your answer.
So if I do not have any NTP, I cannot set the time or adjust it if needed ? My device will never be connected to any ntp server…
This is true. We think of the Zymkey’s RTC as more of a “time bootstrap” during power and/or network outages. And, to promote security, we don’t allow the time to be set in user space by an arbitrary application. Although I don’t know the exact circumstances in your use case, in a real deployment which would never be in contact with an NTP time source, I would recommend allowing the time to be set by NTP one time before deployment in the field.