Testing this is part of standard functionality tested in Intel gpu driver test suites. I’m sure your computer can do that too. Unfortunately, I don’t remember which tool controlled that.
1 Like
To power-on the phone, the RTC has to be a hardware component (i.e. not a just some data kept in RAM by the operating system). Where it is located is less important than how it is connected, be it inside a battery or not.
From what I gather reading the issue linked to by @dcz, the Librem 5 has two hardware RTCs. It would be really silly not having at least one of them connected to power even when the phone is off. Without a constantly running RTC, you would have to enter the current time and date every time you switch on your phone. And RTCs are very low-power devices, at least the ones I have used.
Normally, the RTC can be programmed with at least one alarm. The OS will set this up before putting the CPU to sleep. At the set time, the RTC will signal an interrupt (a hardware thing) to wake up the CPU. From there on, the OS takes care of things, eventually leading to an audible alarm.
That doesn’t work when the phone is off, though. So the RTC interrupt has to be wired in a way that powers up the phone and the OS needs to know that it was started because of an alarm. This is what @kieran and @dcz were talking about above.
The challenge here, if I understood that issue right, is not the interrupt wiring or the power supply, but the fact that there are two independent hardware RTCs. Apparently, it is tricky to make sure the right one is used at all times - after power on, when an alarm triggers boot, at wake-up, …
4 Likes
precisely the case with my bb-q10. i think they purposely did NOT try to implement that to discourage users from completely removing the battery even though it IS hot-swapable … naughty-naughty manufacturers ! 
Or it would get the time from the network (be it the mobile network or via the internet, via cellular or WiFi) every time you switch on.
Raspberry Pi devices have no RTC (by default) and just use NTP to set the clock on each boot, via ethernet or WiFi. Of course it is painful if something is wrong with the network connection at startup and I have seen anomalies at startup if there are components that need to have some idea of the correct time.
1 Like
Of course with the hardware kill switches off you can’t get time from the network (which is a valid starting state) so you’d need to at least have the option to either enter time or have a default power on time every time you boot with the kill switches off assuming you’re not giving power to the RTC.
2 Likes
My router (off-the-shelf device, runs Linux) takes the approach of defaulting to Unix base time at power on. That is OK because you aren’t expecting to use a kill switch on a router. Kinda pointless. But the WAN can be down when the device boots. It does not retrospectively correct the time on early log entries after normal booting.
(If your router has attached storage then it can be quite important to have the correct time. I think my router supports attached storage but I don’t use the functionality.)
Other devices that I have seen, where they have associated disk storage, store the last known time / last shutdown time, so that the time will at least a) never go backwards, and b) be in the right ball park even before NTP is used.
1 Like
I think it’s worth mentioning that just because a device forgets the time when you remove the battery or cut the power does not necessarily mean it lacks an RTC, only that it lacks an extra battery to keep the RTC running. It may lack an RTC, but you can’t tell from those symptoms alone. (I think you probably know this, but your post can be construed the other way.)
A related anecdote: I have a NAS device that truly lacks an RTC and suffers from quite a large amount of clock drift as a result. It requires regular NTP updates to stay in sync. If I recall correctly, there is some code that compensates for the drift by measuring the previous drift and slowing down or speeding up the clock in software. The fact it forgets the time when you turn it off is only a secondary concern!
3 Likes
You’re right, of course.
I would prefer the L5 to have the hardware RTC always powered on, but it might be an ok compromise to fetch time from the network.
You would then have to manually enter time and date only if you are booting with kill switches off. Depending on how you use the phone, this may be close to never.
2 Likes
Finally someone got fed up / bored enough to do something about this 
Just as soon as the byz and crim updates come, so that everyone can get to enjoy this…
6 Likes
The link opened just fine for me as well, and I recently cleared out my cache. Here is the link to the github page that has the code change. Guido Günther / Clocks · GitLab
However, it looks like it may require building from source. I have never built from source so others will have to guide instructions for that.
1 Like
You mean GitLab.
1 Like
With Android and SailfishOS, yeah. Probably other Dalvik systems too.
1 Like
For the record, with arm64: dts: imx8mq-librem5: Enable SNVS RTC (!807) · Merge requests · Librem5 / linux · GitLab you can schedule the phone to be turned on with rtcwake by using SoC’s built-in RTC with -d rtc1. It won’t work in shipping mode though, so the shutdown script would have to learn not to enable it when an alarm is scheduled.
2 Likes
Wake from suspend - yes. Turn it on while off - no.
5 Likes
That’s good news
1 Like
Wow, great! In the case of LUKS encryption I would be useful together with hibernation routines, but is there any possibility to hibernate the phone?..
1 Like
Is there a difference between “hibernate” and “suspend”?
I know there are at least two kinds of suspend, called something like “runtime suspend” and “system-wide suspend”.
1 Like
I meant hibernate-to-disk, sorry. I read that hibernate-to-disk and suspend-to-ram phrases are commonly used, but the difference of single word is really minor :).
2 Likes