You realise that you (Purism) as the operator of the forum can decrease the minimum post length?
or how when i “power-off” the battery level is at 90% and 6 hrs later when i “power-on” it says 95%
my RTC apparently charges my battery rather than depleting it what the devil is this ?
I see, but it wouldnt be a problem for me if it worked the same as old nokias did, some small about of battery power sacrificed to my daily routine
Simply because is not accurate.
The trick that the most nokias did was to have the RTC in the battery (seperate from the main OS). There would be a microOS that would be “only” for the alarm. So the battery was the actual alarm that you were dealing with when the phone was off.
As it stands this approach with the librem 5 would not work as there is no RTC in the batteries that they are using but there could be something that could be setup within the bios to handle but then again you are thinking about bios plugins… which can be fun and risky.
I think that some BIOSes do have that kind of functionality on desktops. You set a wake up time in the BIOS and power off and the computer will boot at the specified time. Presumably that relies on having a clock chip that runs even when powered off - because there’s a CR button cell that powers the clock chip. Obviously the computer has to be still connected to mains power and switched on at the wall.
So something like that is possible to do - but it only really makes sense if the wake-up time is sufficiently far in the future and you can tolerate the delay of a full boot-up sequence. (In the context of a mobile phone, you wouldn’t need a separate button cell and the normal phone battery would do the job.)
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.
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, …
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.
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.
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.
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!
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.