Let's talk about safety of Pinephone

[lot378]

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.

It has PureOS with GTK/Posh which is what I think users may have to use, not really much else choice. It's what I think I meant by "stuck". There is PureOS KDE/Plasma which seems to have fallen to the side along with UBports. Plus PMOS. I think Purism phone users will have stability they need and eventually get more distros.

It seemed like Pine64 had plans for a larger 5,000mAh battery according to May 2020 update: https://www.pine64.org/2020/05/15/may-up...ging-more/

I hope this plan to explore it as an option is still in motion.

[megous]

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?

The battery is user replaceable and is meant to be compatible with random samsung compatible batteries that the user can buy anywhere, not just from Pine64. So that's the reason for sticking with 3kOhm NTC, as Samsung batteries use that. If Pine used 10kOhm and people bought 3kOhm NTC batteries it would be a mess to support such situation. PMIC is programmable, so supporting 3kOhm NTC is not an issue. Yes, precision may be a little lower, because only ADC 8bits of the ADC output for voltage on NTC is used for the comparison against the limits.

The real issue here is that distros have to start caring about safety, and not take it as some upstream kernel/bootloader/hw manufacturer issue. It's the issue of the whole software/hardware package. Not sure how to achieve that, other than having users ask them what are they doing about it.

[fsflover]

Discussion on Hacker News: https://news.ycombinator.com/item?id=24596248.

[SwordfishII]

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.

I have seen this exact site posted on a number of places and came to many off the same conclusions you did. 

The site is very "fear-mongory." I am eagerly awaiting the blog entries about how planes can crash, heart attacks happen, and we can die tomorrow as well. Hardware is never infallible. People are never infallible.

If there is real concern use a slow charger, and don't charge while using convergence which doesn't work yet anyway. Temps and risk stay low.

At least for me once the pine keyboard is out, the phone will always be stand alone, unless i am using it to watch a movie or something on a tv.

[lot378]

I have seen this exact site posted on a number of places and came to many off the same conclusions you did. 

The site is very "fear-mongory." I am eagerly awaiting the blog entries about how planes can crash, heart attacks happen, and we can die tomorrow as well. Hardware is never infallible. People are never infallible.

If there is real concern use a slow charger, and don't charge while using convergence which doesn't work yet anyway. Temps and risk stay low.

At least for me once the pine keyboard is out, the phone will always be stand alone, unless i am using it to watch a movie or something on a tv.

Feeling disappointed reading this post when you've managed to appear sensible before - welcome to reality, I suppose.

It's an almost daily occurrence to read someone posting about their PinePhone feeling warm, or even hot to the touch after use. It would be extremely complacent to dismiss this concern a serious and objective response is required. As a community we needed to be forewarned it might hopefully be enough to prevent an incident until the PMIC configuration and software catches up to the point where thermal conditions are governed adequately.

[TimotheeLF]

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.

I have seen this exact site posted on a number of places and came to many off the same conclusions you did. 

The site is very "fear-mongory." I am eagerly awaiting the blog entries about how planes can crash, heart attacks happen, and we can die tomorrow as well. Hardware is never infallible. People are never infallible.

If there is real concern use a slow charger, and don't charge while using convergence which doesn't work yet anyway. Temps and risk stay low.

At least for me once the pine keyboard is out, the phone will always be stand alone, unless i am using it to watch a movie or something on a tv.

? So instead of attacking his arguments, you're calling him "fear-mongory"? You do know he's the guy that did all of this:

• Collecting information about PinePhone's dri­ver status, what's mis­sing, known issues, and how to use the PinePhone hardware from Linux on this website.
  
• He's been designing and testing audio codec routing setup for voice calling and prepared a sound „card“ controls documentati­on for A64 codec driver. He also wrote voice call audio routing setup app.
  
• He's implementing GC2145 (front camera) driver (basics are working now).
  
• He's maintaining a Linux kernel tree with the collection of the latest patches from all around the internet that are relevant to PP + his own driver work.
  
• He's providing easy to use binary builds for his Linux kernel tree
  
• He's implemented support for multiple cameras to the sun6i-csi driver, so that PP kernel can support multiple cameras.
  
• He's implemented optimizati­ons for u-boot for faster boot times (DDR support and DMA support for eMMC/SD drivers in u-boot), dcache support for aarch64 version of SPL, and many other smaller improvements.
  
• He wrote a specialized bootloader for extremely fast boot times. Typical boot times are ~50–100ms baseline + load times for images. For eMMC it's 85–88 MiB/s, for uSD it's 24MiB/s. So for a typical 12MiB Linux Image, the total boot time from eMMC is ~230ms.
  
• He's helping with getting PinePhone supported in mainline Linux. Basic support for 1.0 and 1.1. Support for LCD.
  

• He wrote patches to improve battery capacity reporting and enable charging to 4.35V.
  

• He wrote a modem power manager driver
  
• He created a multi-distribution image for Pinephone, containing 13 different Pinephone Linux distributions.
  

The reason this keeps appearing, is that nobody has ever talked about the pinephone's safety before and we should definitely make it a priority instead of dismissing it as an extra.

[SwordfishII]

Every phone I have ever owned has gotten warm. Hot even and I'm pretty old since I was around before cellphones.

That's what happens with the high powered chips of today and the passive cooling requirements of phones.

Barring damage to the battery, I just don't see the "omg it will bust into flames," I am a bit skeptical as like I said I have seen this site spammed all over Reddit and other forums. Some aspects are valid, some are definitely intended to scare and are unlikely.

Don't get me wrong. Should there be checks, absolutely. But this isn't a grenade waiting to happen.

[lot378]

Every phone I have ever owned has gotten warm. Hot even and I'm pretty old since I was around before cellphones.

That's what happens with the high powered chips of today and the passive cooling requirements of phones.

Barring damage to the battery, I just don't see the "omg it will bust into flames," I am a bit skeptical as like I said I have seen this site spammed all over Reddit and other forums. Some aspects are valid, some are definitely intended to scare and are unlikely.

Don't get me wrong. Should there be checks, absolutely. But this isn't a grenade waiting to happen.

It is very possible something could go very badly wrong with the PinePhone with careful reading so much is obvious. The other phones you're talking about have software already managing battery and thermal conditions which the PinePhone does not have yet. There is a vacuum where the work ought to be getting done by someone -- Pine64 has been sponsoring a couple of distros may be some money ought to go somewhere else if they're not already figuring out how to resolve the issue.

If a phone is getting hot or battery is being consumed really quickly those are indicators there could be an issue.

[SwordfishII]

It is very possible something could go very badly wrong with the PinePhone with careful reading so much is obvious. The other phones you're talking about have software already managing battery and thermal conditions which the PinePhone does not have yet. There is a vacuum where the work ought to be getting done by someone -- Pine64 has been sponsoring a couple of distros may be some money ought to go somewhere else if they're not already figuring out how to resolve the issue.

If a phone is getting hot or battery is being consumed really quickly those are indicators there could be an issue.

Again there has been zero demonstrable threat. Heat and battery drain are inherent on ALL phones being taxed and running at full speed.

Hardware fuses exist to prevent catastrophic fire. You ever have blue smoke come out of electronics? I have. No fire though. No explosions.

Hardware shutdowns due to overheat aren't software driven. The software side is to prevent damage to the cpu but again there is zero evidence the phone will explode even if that happened. Yes there should be software development to prevent the damage that could occur from a hardware shutdown. But I highly doubt the phone would "explode," as claimed.

Pentestors frequently develop proof of concept exploits to fully demonstrate the vulnerability.

This site is speculating and hasn't provided any proof of concept, just scary words. Show the issue if it exists. How many pinephones have exploded? If this issue is as serious as claimed and hyped, surely at least one? Surely that site owner could demonstrate the seriousness in action.

You can be scared and worried, but until this is actually demonstrated to be a significant threat, I won't be.

[lot378]

<snip the ignorance>

It's amazing you want someone to have their PinePhone explode before you will believe there is an issue. Fortunately, I think other people have more sense and understand the technical issues here better than you do and appreciate the heads-up that's been provided.