09-18-2020, 10:34 PM
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.
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.