Let's talk about safety of Pinephone

[megous]

https://xnux.eu/log/#017

[barray]

Using the information in the Wiki as a point of reference: https://wiki.pine64.org/index.php/PinePhone

It would be good if you could point to the sections of code you are specifically concerned about...

> The battery includes a protection circuit that isolates it in a number of fault conditions, including if it is discharged too far.

So without any software, the battery should try to protect itself. But this of course cannot be relied upon 100%. Checkout this for more: https://wiki.pine64.org/images/0/04/Pine...2-2750.pdf

> Pinephone's SoC is quite bare when it comes to software/firmware (that's why FOSS enthusiasts like it, no blobs, you know!). This
> has a dark side, too. All the safety critical parts are written (or rather were not written, yet) by some random people on The Internet.

You either rely on some random people on the internet whose code you can review, or some random engineers whose code you cannot review. You might think that code that is written by some company and reused many times is more robust, but actually it simply means people are less likely to re-review it and bugs can creep in.

> 1. Pinephone battery uses a 3 kOhm NTC to monitor the temperature. Power management chip in Pinephone expects 10 kOhm
> variant by default. So early on, when the times were adventurous, someone decided to patch the kernel to disable battery thermal
> monitoring completely. Quick and dirty fix for Pinephone not charging due to false under-temperature alarm.

The battery itself has thermal protection, but the power controller does too: http://files.pine64.org/doc/datasheet/pi...t_V1.0.pdf

> Now guess what… up to now, all distributions run with battery temperature sensing and regulation disabled. If you're unlucky and use
> a dud battery that will heat up more easilly during fast charging, you can burn down your house.

As you say, this should be enabled by default and manually enabled for early adopter devices.

> 2. And you know what, I also suspect that all distros fast charge all the way through the constant-current phase of charging, by
> default. Other than contributing to making the above mentioned house burning scenario more likely to happen, this also contributes to
> overheating issues on Pinephone.

Again, battery protections and the power controller:

> The AXP803 battery charger solution has two charging modes that it can be in. It is specifically designed to charge Li Ion
> or Li Polymer type batteries. The two modes are 1) Pre Charge Mode and 2) Fast Charge Mode. The delineation between
> these two modes is based on the battery voltage level of VTRKL which is set at 3.0V. When battery voltage, VBATSENSE is
> between 0V to 3.0V (VTRKL), the charger is in Pre Charge Mode where charging current is limited to a value of ITRKL (10% of
> ICHRG, default value is 120mA). This mode of operation is intended to prevent damage to the battery. Once VBATSENSE≥
> VTRKL, the charger will enter Fast Charge Mode.

> 3. Another thing. PMIC has an emergency thermal shutdown feature, for a situation when the chip itself overheats. It's disabled by
> default. It's also not well documented.

This should just be a case of setting registers if this is the case. There is also the thermal shutdown of the CPU which would greatly reduce the load too in such a condition.

> 4. And, another one! Battery is rated for some sustained continuous discharge current (0.5C, 1500mA, ~6W). I guess it overheats if it
> is dicharged at a significanlty faster rate for prolonged periods of time, and potentially becomes a safety hazard again. Maybe again
> only if it's a suboptimal piece that passed QA.

Are the batteries not 3000mAH? Not 1500mAH? The peak current can exceed the maximum continuous discharge current for short bursts, so as long as this isn't maintained for too long, it would be fine.

[megous]

Using the information in the Wiki as a point of reference: https://wiki.pine64.org/index.php/PinePhone

It would be good if you could point to the sections of code you are specifically concerned about...

> The battery includes a protection circuit that isolates it in a number of fault conditions, including if it is discharged too far.

So without any software, the battery should try to protect itself. But this of course cannot be relied upon 100%. Checkout this for more: https://wiki.pine64.org/images/0/04/Pine...2-2750.pdf

> Pinephone's SoC is quite bare when it comes to software/firmware (that's why FOSS enthusiasts like it, no blobs, you know!). This
> has a dark side, too. All the safety critical parts are written (or rather were not written, yet) by some random people on The Internet.

You either rely on some random people on the internet whose code you can review, or some random engineers whose code you cannot review. You might think that code that is written by some company and reused many times is more robust, but actually it simply means people are less likely to re-review it and bugs can creep in.

> 1. Pinephone battery uses a 3 kOhm NTC to monitor the temperature. Power management chip in Pinephone expects 10 kOhm
> variant by default. So early on, when the times were adventurous, someone decided to patch the kernel to disable battery thermal
> monitoring completely. Quick and dirty fix for Pinephone not charging due to false under-temperature alarm.

The battery itself has thermal protection, but the power controller does too: http://files.pine64.org/doc/datasheet/pi...t_V1.0.pdf

> Now guess what… up to now, all distributions run with battery temperature sensing and regulation disabled. If you're unlucky and use
> a dud battery that will heat up more easilly during fast charging, you can burn down your house.

As you say, this should be enabled by default and manually enabled for early adopter devices.

> 2. And you know what, I also suspect that all distros fast charge all the way through the constant-current phase of charging, by
> default. Other than contributing to making the above mentioned house burning scenario more likely to happen, this also contributes to
> overheating issues on Pinephone.

Again, battery protections and the power controller:

> The  AXP803  battery  charger  solution  has  two  charging  modes  that  it  can  be  in.  It  is  specifically  designed  to charge  Li  Ion
> or  Li  Polymer  type  batteries.  The  two  modes  are  1)  Pre  Charge  Mode and 2)  Fast  Charge  Mode. The delineation between
> these two modes is based on the battery voltage level of VTRKL which is set at 3.0V.  When  battery  voltage,  VBATSENSE  is 
> between  0V to  3.0V (VTRKL),  the  charger  is  in  Pre  Charge  Mode  where charging current is limited to a value of ITRKL (10% of
> ICHRG, default value is 120mA). This mode of operation is intended to  prevent  damage  to  the  battery. Once  VBATSENSE≥
> VTRKL,  the  charger will  enter  Fast  Charge  Mode.

> 3. Another thing. PMIC has an emergency thermal shutdown feature, for a situation when the chip itself overheats. It's disabled by
> default. It's also not well documented.

This should just be a case of setting registers if this is the case. There is also the thermal shutdown of the CPU which would greatly reduce the load too in such a condition.

> 4. And, another one! Battery is rated for some sustained continuous discharge current (0.5C, 1500mA, ~6W). I guess it overheats if it
> is dicharged at a significanlty faster rate for prolonged periods of time, and potentially becomes a safety hazard again. Maybe again
> only if it's a suboptimal piece that passed QA.

Are the batteries not 3000mAH? Not 1500mAH? The peak current can exceed the maximum continuous discharge current for short bursts, so as long as this isn't maintained for too long, it would be fine.

Battery protection circuit doesn't protect against anything I wrote about. It doesn't care about heat. And it's independent of the software anyway, so it doesn't relate to my core point about safety as an issue of interaction between SW and HW.

Battery protections in PMIC you cite are for something else than to regulate fast charging. These will only help at the beginning of charging, and perhaps if battery seems to not be getting charged for way too long. Meanwhile the phone happily fast charges from 0 to whenever CV phase begins, without regards to temperature.

There's no automatic thermal shutdown of the CPU, it's done by Linux and it's configurable, and depends on how well the thermal sensor driver is implemented or whatever kernel config you're using. Some people still report that the sensor gives them nonsensically high values. I don't think this was investigated.

Yes batteries are 3000mAH, so 0.5C limit means max 1500mA continuous discharge current (5-6W). Those values I measured are not peak. 6.5W is idle minimum with dock connected to monitor, no CPU and no GPU use, no modem use and wifi not transmitting. There probably needs to be some userspace daemon that monitors thermals across the phone, and limits things when things are getting out of hand and maybe warns the user that the phone needs to be shut down soon if temperatures are still out of hand after automatic actions to reduce the thermal output of various components. (something like the one implemented in the modem's userspace)

It's great that code is open, but someone still needs to know there are issues, fix the issues and actually verify the safety features work and not just toggle some registers and call it a day. Company that does both SW and HW has motivation to make both work safely together, because they're potentially liable. Will some one or two person Linux distro project throwing together bunch of preexisting software mostly focusing on user facing features and prominent bugs work on the issues I presented and do a bit more comprehensive safety testing? I'm afraid not.

There are now distros that got significant financial contribution from pinephone sales. So someone somewhere has resources to spare on safety on the SW side. They should do so.

[lot378]

Bottom line? From what I reckon, to avoid a fire the PinePhone will need to use a different battery that has the right 10kOhm NTC (ideally, with 1% tolerance instead of 5% tolerance) for temperature sensing by the PMIC and larger capacity (by 50% or more) to fully support without compromise desktop convergence CPU 100% with all devices on and being used. The rest of the battle can then be met with PMIC configuration and software. It means a long-term solution, with Pine64 involved from the hardware point of view managing the risk, power costs, design changes, packaging etc.

It's interesting the schematic has an if this/or that for the 10kOhm NTC on TS so that particular issue was known.

I wonder why Pine64 chose to have batteries manufactured that have 3kOhm NTC instead of ordering them with 10kOhm NTC. A reason is compatibility with Samsung J7 batteries so anyone can obtain one locally. But that was a compromise and one that fails. Better to have the battery with the right NTC specification from the beginning, even if the capacity was still too low. That would have enabled the right building blocks to be in place for complete thermal oversight in the software.

In the short-term, I feel nothing except gratitude towards the tinkerers closely examining what's going on inside the PinePhone and providing their feedback.

I can foresee some experiments with replacing NTC on battery PCB or adding an NTC where it says NC on PinePhone PCB with 10kOhm to enable some tuning of PMIC and software. And may be jury-rigging up some other batteries to try them out, taking more measurements. Answering questions like does USB-C PD charging work at all?

[eKeith]

Thanks for the heads up!

Perhaps an alternative (partial) solution can be to port something like the third-party android Advanced Charging Controller App (AccA):
https://github.com/MatteCarra/AccA


Sent from my PH-1 using Tapatalk

[User 18618]

Perhaps an alternative (partial) solution can be to port something like the third-party android Advanced Charging Controller App (AccA):
https://github.com/MatteCarra/AccA

Something akin to AccuBattery or tlp would be marvelous for the A64 SoC.

[Paulie420]

Thanks for the writeup, megous. I am just not ordering a PinePhone.. and while my Linux skills are intermediate, I am by no means a developer... I do hope to contribute to the project in ways that I can, but they will be limited to my experience levels for sure...

I appreciate the discussion and topics you brought up; furthermore, I will certainly take more precautions that I originally anticipated when I do have the hardware in my hands. I knew that this wasn't a fully-cooked Linux Phone that I could replace my iPhone with... but I originally had thought I could use it as phone #2 and switch over fully when OSes became cooked enough. Now, I understand that this phone is more like.... phone hardware, coupled with OSes that are being developed and not in any way ready for prime time... that the phone hardware I'm ordering is way more for testing and attempting to get nearer to a final product phase.

Being the tinkerer that I am, even at my experience level, this is still something I want to get my hands on... I have dreams of one day owning a device that is as powerful as my iPhone, running a linux system that I can plug into a monitor or network and USE as a Linux box... with a phone for use as my daily driver. I thought that the PinePhone hardware could be made into exactly this. Now, I think that both the software AND hardware will have to be further developed before this can be a reality...

I would bet that if we ever get close or to that end, new hardware would be needed... with the fine tuned hardware that this development and research the community is doing now is providing. Regardless of that, I still want to be involved.

Thanks, tho for bringing up topics that should be considered by anyone who's using the PinePhone hardware. I'm still excited for what it CAN do today... even if there are more limitations than I first thought.

I'm going to follow your blog, and certainly the forum here.. and also try to get in one ONE development OS that I choose. What current one do YOU think has the best possibility of becoming capable of being a daily-driver phone OS? I guess I have two things on my wishlist that maybe I need to separate: Having a full Linux system and having a Linux based PHONE OS. Anyway, I'd love to hear what your picks are.

Anyway I wrote a book - all I wanted to say was THANKS..

[fsflover]

Thank you very much, megous, for the post. I guess I understand better now why Librem 5 is so much more expensive, since Purism develops both its hardware and software. It should probably be more safe in this sense.

I suggest to everyone concerned about these safety issues to consider Librem 5: https://forums.puri.sm/t/comparing-specs...hones/6827 (I personally preordered both phones).

[lot378]

Megous posted a follow-up: Some ways to improve Pinephone safety -- https://xnux.eu/log/#018

Alright, something can be gotten to work to protect the PinePhone from going up in flames. I know it will be pretty crude, due to granularity of 3kOhm vs 10kOhm NTC and the tolerance of the part (5% on NTC fitted to Pine64 battery vs 1%). It's better than nothing which is present situation.

Optimisations to eke out power usage safely are a compromise but can be worked on. It will possibly work out eventually for PinePhone outside of a convergence situation. However for convergence, there are still the concerns that Megous has mentioned in earlier (b)log with power consumption being over safe limit. Grateful to Megous for providing all those pointers on what needs doing thanks!

IMO it still may need a re-think about the battery and replacing it with a beefed up one with more granularity on TS. Mostly, in order to make convergence work safely.

May be it might also take a community edition of the PinePhone specifically to help fund safety.

Big question is who is going to take this on?

---

Thank you very much, megous, for the post. I guess I understand better now why Librem 5 is so much more expensive, since Purism develops both its hardware and software. It should probably be more safe in this sense.

I suggest to everyone concerned about these safety issues to consider Librem 5: https://forums.puri.sm/t/comparing-specs...hones/6827 (I personally preordered both phones).

Yes, another Linux phone offering convergence.

Of course, for the price you'd expect them to be on top of all the nitty-gritty details like thermal management and power developing the software themselves. The battery is 3,500mAh (probably 3,700-3,800mAh) so a better chance theirs will operate more safely during convergence. Plus, the notification LED has PWM which is desirable to me.

The downside of the Purism phone is also the software i.e. you might be stuck with what they offer.

Integrating or running other software distros might offer something minus whatever Purism added to manage safety.

So I prefer instead to buy a $200-or-less phone with diversity of software and carry on using a laptop.

[fsflover]

The downside of the Purism phone is also the software i.e. you might be stuck with what they offer.

Integrating or running other software distros might offer something minus whatever Purism added to manage safety.

Not sure I understand. The other distros for Librem 5 may have the same problems like Pinephone has, but it does not make Librem 5 worse or even equal. At least the other distros can follow the path of the official PureOS and implement all the same features much more easily.