I didn’t measure exactly yet, but my impression is that the phone runs less than an hour with the screen turned off. And it is very hot whether the screen is turned on or off.
Is this normal with the current version? If so, I hope this will get addresses with a future upgrade of the software.
3 Likes
This is normal with the current version. There is ongoing work on improving power management in the kernel that should help with this, so software updates should help.
7 Likes
Don’t know what you mean exactly by “power management in the kernel”. I’m a user of an Ubuntu Touch mobile E4.5, produced by Canonical and BQ.com (a Spanish hardware OEM) and nowadays the development is an OpenSource community, ubports.com.
To save really the power, the unused device must be in suspend mode, display off and CPU in halt. From what I read here (and before in other posts), it seems that the CPU is “idling” with CPU cycles in high frequency. From this comes also the heat of the device.
They mean doing the work to make the kernel understand how to “halt”. That’s the hard part. It requires knowing how to tell the silicon to lower the clockspeed. In fact when clock speed goes down voltage can go down with it providing a massive power savings.
When BQ made the device either an OEM made the kernel for that CPU, or they did (highly unlikely in the current market). All those features were most likely done for them already. The Ubuntu touch project uses a neutered Linux kernel, (literally millions of lines of code are removed) which already has kernel support for the hardware, and built on top of it. UBports doesn’t touch the kernel at all, just userspace.
3 Likes
It is meant to say that this not a hardware defect and will be solved by ongoing implementation of the power management in the software.
The difficulty is in figuring out how to halt the CPU and have it automatically wake, quickly and reliably, when a phone call comes in (or the user hits the power button, but that’s usually relatively easy). It also needs to halt all but one of the CPU cores when not under load, and cut the clock speed and voltage on the one running core. It may be enough to do just that, without actually halting the last core, but again, all this has to work every time without causing system instability.
potentially you also need to reduce clocks/volts on dram and turn off/suspend some other periphery
All these Ubuntu Touch devices until today run an Android kernel which controls all the hardware and the access from Ubuntu Touch userland is done via some libhybris which maps normal Linux libc calls to Android ones.
3 Likes
yeah what I said. Also mainline Linux support in ubuntu touch doesn’t count until it runs reliably on a librem.
For example, most WiFi client devices support some kind of power save mode.
I don‘t know if there is a port of UT to the L5 is on the way.
I meant that the developers who work on kernel things for Purism are working on power management issues. There are parts outside the kernel that need attention, too.
1 Like
It sounds like if they solve the problem with the phone not going idle when not in use, it will still have terrible battery life. The top comment said that with the screen off it lasts less than an hour. What if the phone is in use and the screen is on? It wont be able to go idle during this time… Will I only get half an hour of web browsing then have to plug it in to charge up again?
I think there is a big difference between the device being turned on and responding to user input and using just the necessary resources for that at each moment, and the CPU running all cores at full speed all the time. So there is still hope that it can work reasonably well in the end, I think.
1 Like
At the moment it doesn’t make a big difference if the screen is on or off. I think when all the power management is implemented, it could run for a week with such a big battery. It is just a lot of complicated work to implement.
2 Likes
According to NXP i.MX 8M fact sheet, this SoC is “Optimized for fanless operation, low thermal system cost and long battery life”.
It seems that NXP was optimistic about its speed in developing the drivers to achieve this objective. But it shows that this SoC is designed for batterypowered use.
7 Likes
#hold-my-ups 
Hello, I’m not an expert on kernels, but going from 1 hour to one or two days seems to me to be very optimistic. The Librem 5 protos have defects, no problem with that, it’s normal during that stage. However, 1 hour of battery seems too low for a device not connected in 4G.
Honestly, I’m not here to troll, but I’m legitimately starting to be very worried. Battery life is a critical point.
2 Likes
I’d say expecting one or two days of battery life is unrealistic, but 8-12 hours should be easily doable if they ship Evergreen with bigger batteries and make any sort of improvement over the zero power management they’re doing now. For me it really just needs to last from when I take it off the charger in the morning until I get home in the afternoon. Anything beyond that I’d consider a plus but not expected for a first-iteration phone. Fir’s CPU change should enable much longer battery life.
4 Likes
You get similar battery life increases (or more) in embedded systems when you take them from full power busy-waits to proper interrupt based CPU parking. Of course, the battery drain from running the radios puts an upper limit on how much reducing the power consumption of CPU can help. So yeah, assuming the problem really is that it’s got the high performance, low efficiency, cores running pell-mell continuously, I’d expect a considerable standby battery life increase when that’s fixed.
For non-standby, it may take a custom scheduler to get it to only run the low power cores for normal tasks, but that isn’t particularly difficult (just terribly documented and kinda poorly written).
6 Likes