c) Modem will ba able to wake up the L5 from suspend to RAM whether the call is via VoLTE or not
What you think about the DIY edition?
If i get all parts, i can assembling it if do not need soldering.
Then i can install the Pure OS.
Sending the DIY kit is less work for you, and more fun for me. Plus, when crossing the border, i have chance avoid the VAT, (27% + handling fee in my country) because the parts is just parts, not a phone.
The custom officers maybe not realise the price of the individual parts. If sending parts and describing only the manufacturing cost is legal, this way is a good solution for me, and i think, not just me.
The question is what can you use to wake up the system after 30 minutes of suspend-to-RAM? You have to have something running on the system that sends the signal to wake up the phone, so it can connect to the internet and check if you have any new internet messages. In theory, the BM818 (or maybe the RS9116 or TPS65982) be reprogrammed to send out a signal every 30 minutes, but they are black boxes that we can’t touch. There is a possibility of reprogramming the firmware for the extra 80MHz Cortex-M4 for controlling the smartcard reader, but is it wired to allow it to wake up the system?
This idea that the usage patterns we are used to because of Android and iOS need to be perpetuated with the Librem 5 is just the wrong idea.
Constant notifications destroy workflow and destroy concentration. For a platform that wants to harvest user data and usage patterns this is important.
But a phone not designed to do those things, doesn’t need to hit us with notifications until we are ready for them. That said, I’m not suggesting that the only low power mode be suspend to RAM.
It would be good when the user knows they wont be using the phone for a while, and the reception of notifications, and calls, all aren’t important.
However, since this is desktop Linux there isn’t any current suspend or standby mechanism other than suspend to RAM. I do wonder how much desktop Linux at idle and without a display uses. What about heat concerns?
But I want to be clear, if the Librem 5 only gets notifications while ON, I’m ok with this. This would be a usage pattern that is new, but not really. It is very similar to your desktop computer. Only now your desktop is tiny, and has a cellular capability, with a mobile data component.
This feels like a superior implementation of a mobile computing device than the current mobile platforms.
This is what MS should have done with their convergence efforts.
Furthermore, the work being done here will allow for MUCH more powerful devices that will all benefit from the cellular component.
I get that this is the beginning, but for v2 or 3 or 4, the CPU and the RAM need to be as beefy as mobile will permit. True computing convergence means a device that can handle what my desktop can, within reason of course. This is what Apple is poised to do now, only their hardware will be able to do it from a performance standpoint.
I am also in favor of suspend to RAM feature.
As far as I remember, on Android, some apps (like Signal for instance) asks you to disable “deep sleep mode” in the settings to still get notifications.
I imagine the same process in PureOS suspending to RAM by default, and some apps (like Signal for instance ^^) to ask to you disable “suspend to RAM feature” in the settings if you still want to get notifications.
To me, a full day use is the minimum requirement. I know other members can have another opinion (and I accept it) but I just can’t imagine myself looking everywhere for an electrical outlet to charge my Librem 5 during the day.
I agree that a full day is what I am after but I am in favor of achieving that however it can be achieved. I am agnostic regarding how it is achieved.
See also an official comment above at Blog Post: Librem 5 Evergreen Update: Mold and Milestones regarding priorities for this.
Such app can’t work with a power off CPU. Only an external component, like the modem can wake up the system.
You can’t enable suspend to RAM for some apps and not for others, it’s for the whole system.
Perhaps the post means: while a certain application is running do not suspend-to-RAM.
That was the original point made above about wanting to lock the phone while playing music - and not have the phone go off into la-la land, suspending to RAM, and thereby stopping the music.
It’s a similar problem if you are watching a long video on a desktop/laptop and the computer decides to screensave because you haven’t clicked anything or typed anything.
It’s mainline Linux, so that’s not true. Most applications handle
SIGSTOP/SIGCONT just fine. If your swappiness settings are right, they’ll even get compressed to zram or written out to disk if the system is loaded enough and you leave them stopped long enough.
I don’t understand.
We are talking about Suspend To RAM (STR), not about pausing / resuming a process.
You know, what might be more power efficient, and is essentially what Android and iOS are doing, would be use a rtcwake event to wake the L5 from STR for a set amount of time (short, 30-90 seconds) and then resume STR. During the wake time, it could allow processes to poll for updates, which then could trigger the led to pulse even while the device again suspended. Of course notification sounds could fire, allowing the user to prevent the automatic STR to occur. In this way, it would be VERY similar to how Android and iOS function, but with a MUCH deeper and longer lasting standby power mode. The display would not turn on for these occurrences.
Of course being able to set the frequency of this wake event would be something that would be an industry first. Scheduling could take into account night hours, etc.
Seems like a VERY VERY good solution that I wouldn’t imagine would be too difficult to implement. (Of course that is usually the understatement of the year with development causes.) You will still need the cellular activity to wake the device for phone calls or SMS messages, but honestly, even if we don’t have that yet for Evergreen, I’m good with that. The phone is really make GREAT progress!
The app can technically work with suspend because another component which can wake up the CPU from suspend is the real-time clock. If an app such as signal wants to check for new messages every 30 seconds it can tell the real-time clock to wake up from suspend every 30 seconds.
This would be an issue though if multiple apps does it at the same time as then it would probably wake-up and suspend too often. That could be solved however with some API/service where multiple processes can say “i’d like to be woken up every 15-60 seconds” and then let the service schedule when it should wake up and batch these requests together.
It would be problematic for IP-native calls like hangouts/duo/facetime however which needs to be woken up instantly. I’m not sure how that works on platforms like android and iOS.
Ok, I understand better what you mean.
A lot a of rules / strategies can be defined to use STR (and other power management function) in a way that fit well with each personal usage.
Is there a real-time clock?
According to this component list there is an real time clock yes
Thanks @johan-bjareholt for reminding me that I should be looking at the documentation and not speculating.
The i.MX 8M Quad has an Real Time Counter in its SNVS_LP (secure non-volatile storage low power) module which relies upon an external 32.768 kHz crystal oscillator which the schematics show that the Librem 5 has implemented. The RTC can be programmed to produce an interrupt in low power mode when everything except the SNVS is asleep.
I assume that this can be used to implement the rtcwake that @2disbetter mentioned to periodically awake the i.MX8MQ and check for new WiFi calls/messages.
To read about it, see:
- “3.1.4 External clock sources” and “3.1.6 Power modes” in i.MX 8M Dual / 8M QuadLite / 8M Quad Applications Processors Data Sheet for Consumer Products
- “6.4 Secure Non-Volatile Storage (SNVS)” on p. 940 of the i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual (you need to login to NXP’s site to download it)
I think that it would be better for the Librem 5 to use its extra Cortex-M4F core in a low-power mode to constantly monitor the WiFi traffic, if you want to use the Librem 5 as a WiFi phone. Coming out of suspend to RAM every 60 or 90 seconds to check for new WiFi calls still means that there is a large delay between when when people call you and you answer. Most people who call me on the phone, expect me to answer immediately.
The problem with using that low-power Cortex-M4F core for monitoring the WiFi traffic is that it would violate the RYF rules, since that core is used to execute the proprietary DDR timing blob by u-boot, under the RYF’s secondary embedded CPU exception.
Sorry that isn’t what I meant. I was saying that the phone would be awake only for that long, when woken via the RTC. How often the RTC would wake the phone would be a setting the user could set, but would be defaulted to every hour (or whatever).
Regarding being able to wake from STR fast enough to address an incoming phone call is what I imagine the Purism crew is really having to work hard on. If the phone can resume fast enough to make this functional, that will be a great achievement. And will blow the door wide open for Linux to become a true mobile member.
My solution for a quicker resolution that nets better battery now would be that in the STR suspend scheme, phone calls would go to voice mail, and you would only get a notification after the phone does its update wake. This would be a radical power saving mode, that I’m sure would not appeal to many people, at least not all the time.
On a separate note, I think this conversation highlights the uniqueness of the L5 being able to make and receive phone calls period. Imagine your Linux based laptop or desktop all of a sudden being able to answer your home phone and make calls. This is the functionality that Purism is adding to the Linux desktop stack.This is just one example of the massive effort that the relatively small team at Purism is doing to improve the situation for all users.
That’s excellent. Thanks for finding that. I had a look at the schematics the other day and didn’t find it because I wasn’t looking for the right things - so assumed that it would be in the CPU itself if anywhere but, as you say, assuming / speculating is not as good as finding and knowing.
However that isn’t really how this functionality is “supposed” to be used. That is, it is not supposed to be used for polling - unless you don’t trust the rest of the hardware and software.
An ideal system is interrupt driven - so the WiFi card and the cellular modem can wake the CPU from standby and the RTC can wake the CPU from standby and a specific user event (e.g. ‘wake’ / ‘sleep’ button) can wake the CPU from standby. The RTC would only be used for internally scheduled future events, such as a typical alarm clock app might use / such as
cron might use.
As you say, if the RTC is used for polling between sleeps it is going to be far from ideal for answering a call. Noone who calls me is going to wait, say, on average 30 seconds for me to answer.
Actually coming out of standby shouldn’t take long but it’s a complicated business and individual hardware components may have their own ideas about how long they take to get going if they have been sleeping.
Micro Crystal Switzerland RV-4162-C7 real time clock module with I2C bus
Oh, I’m gonna be sceptical until 2021, when Evergreen actually starts shipping.