4 ms·

The article mentions that "Unlike most SBCs, the Pinephone contains a rechargeable battery intended to power the device. Correct configuration of the charging c

by nilsb 5y ago

The article mentions that "Unlike most SBCs, the Pinephone contains a rechargeable battery intended to power the device. Correct configuration of the charging circuits, including various safety features such as thermal protection will not be enabled by the current OpenBSD kernel as of the time of writing." Is that really the case? If so, that seems like an unnecessarily dangerous design. I would expect safety features not to rely on (user-replaceable) software.

Arnavion 5y ago
I'd rather have features rely on user-controlled software than hardware-vendor-controlled software.
- squarefoot 5y ago
  When dealing with Lithium cells, the less software the better. If there's need to change dis/charging parameters from software, then that must be done behind a hardware protection with higher priority, so that the users still have control but cannot play outside safety limits. Not implementing a hardware safety seems really a bad deign choice to me.
- laputan_machine 5y ago
  Do you think thermal protection is an optional feature? Because that's what would happen in some cases if it's only defined through software. Every electronics project working with Li-Ion batteries in my opinion should use an overcharge/discharge protection circuit, it's basic safety. I don't want software to be able to control whether or not my phone turns into a bomb Edit: from this discussion https://news.ycombinator.com/item?id=24596248 https://news.ycombinator.com/item?id=24596248 it looks like it is using http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf http://files.pine64.org/doc/datasheet/pine64/AXP803_Datashee... as a separate IC
  - bildung 5y ago
    > You think lack of thermal protection is a feature? I read that as: vendor-controlled software sitting in hardware will be buggy and those bugs won't get fixed. Thermal protection implemented in user-controlled software can, over the long term, provide better safety because bugs can be fixed.
    - yjftsjthsd-h 5y ago
      Then stick it in a user-flashable chip, but still ship it pre-flashed. The point it that failing to init something at runtime should never be a safety problem.
      - toolz 5y ago
        How is a user flashable chip any different than shipping it preconfigured to be safe in software? The idea that there's more safety with physical separation but the same level of configurability seems incorrect at a glance. People will misconfigure either way. Freedom is always safer given a large enough window, just maybe not always safer in the short term.
        yjftsjthsd-h 5y ago
        The point is that if you run a new OS on the hardware (say, OpenBSD...) and it doesn't set things up, that failure to configure the running system should not result in a safety problem. Now one obvious way to do this is to do it in hardware, but the point was made that then you have to hope that the hardcoded safety measures are bug-free. So, the obvious fix is to do it in firmware, and allow updating the firmware, but do ship with it pre-flashed in persistent memory. Thus, doing nothing is safe, if a bug is found you can fix it, and yes a user could flash unsafe firmware but they'd have to go out of their way to do so; the default is to be safe regardless of what the main system OS does.
        toolz 5y ago
        A user has to go out of their way to flash an OS too, I'm not sure I buy the argument that open architecture is going to surprise people who also know how to flash an OS to a very new and unsupported device. No one is trivially flashing different OSes to pinephone and thus they'd need a good deal of domain knowledge to even achieve this goal. Effectively that means no one is flashing an OS to the pinephone, getting it to work but somehow is ignorant to the fact that pinephone has a battery and that battery could present danger if handled improperly. It seems like a safety measure that increases complexity which could potentially decrease safety just as likely as it is to increase safety.
  - deleted 5y ago
    [deleted]
  - Arnavion 5y ago
    >You think lack of thermal protection is a feature? Where in my comment did I say that?
    - laputan_machine 5y ago
      Fair enough, I've reworded my post to more accurately convey my point
- thereddaikon 5y ago
  I'd rather such things be a purely hardware implementation.
Bancakes 5y ago
Knowing BSDs, this is codeword for "we don't know how to do it, nor do we care to."
- nix23 5y ago
  Arch user right?
  - Bancakes 5y ago
    Correct
perihelions 5y ago
There was a lengthy HN thread discussing the question (software-based thermal protection): https://news.ycombinator.com/item?id=24596248 https://news.ycombinator.com/item?id=24596248 ("Let's talk about safety of Pinephone (xnux.eu)") (2020)

by nilsb 5y ago

Arnavion 5y ago

I'd rather have features rely on user-controlled software than hardware-vendor-controlled software.

squarefoot 5y ago
When dealing with Lithium cells, the less software the better. If there's need to change dis/charging parameters from software, then that must be done behind a hardware protection with higher priority, so that the users still have control but cannot play outside safety limits. Not implementing a hardware safety seems really a bad deign choice to me.
laputan_machine 5y ago
Do you think thermal protection is an optional feature? Because that's what would happen in some cases if it's only defined through software. Every electronics project working with Li-Ion batteries in my opinion should use an overcharge/discharge protection circuit, it's basic safety. I don't want software to be able to control whether or not my phone turns into a bomb Edit: from this discussion https://news.ycombinator.com/item?id=24596248 https://news.ycombinator.com/item?id=24596248 it looks like it is using http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf http://files.pine64.org/doc/datasheet/pine64/AXP803_Datashee... as a separate IC
- bildung 5y ago
  > You think lack of thermal protection is a feature? I read that as: vendor-controlled software sitting in hardware will be buggy and those bugs won't get fixed. Thermal protection implemented in user-controlled software can, over the long term, provide better safety because bugs can be fixed.
  - yjftsjthsd-h 5y ago
    Then stick it in a user-flashable chip, but still ship it pre-flashed. The point it that failing to init something at runtime should never be a safety problem.
    - toolz 5y ago
      How is a user flashable chip any different than shipping it preconfigured to be safe in software? The idea that there's more safety with physical separation but the same level of configurability seems incorrect at a glance. People will misconfigure either way. Freedom is always safer given a large enough window, just maybe not always safer in the short term.
      - yjftsjthsd-h 5y ago
        The point is that if you run a new OS on the hardware (say, OpenBSD...) and it doesn't set things up, that failure to configure the running system should not result in a safety problem. Now one obvious way to do this is to do it in hardware, but the point was made that then you have to hope that the hardcoded safety measures are bug-free. So, the obvious fix is to do it in firmware, and allow updating the firmware, but do ship with it pre-flashed in persistent memory. Thus, doing nothing is safe, if a bug is found you can fix it, and yes a user could flash unsafe firmware but they'd have to go out of their way to do so; the default is to be safe regardless of what the main system OS does.
        toolz 5y ago
        A user has to go out of their way to flash an OS too, I'm not sure I buy the argument that open architecture is going to surprise people who also know how to flash an OS to a very new and unsupported device. No one is trivially flashing different OSes to pinephone and thus they'd need a good deal of domain knowledge to even achieve this goal. Effectively that means no one is flashing an OS to the pinephone, getting it to work but somehow is ignorant to the fact that pinephone has a battery and that battery could present danger if handled improperly. It seems like a safety measure that increases complexity which could potentially decrease safety just as likely as it is to increase safety.
- deleted 5y ago
  [deleted]
- Arnavion 5y ago
  >You think lack of thermal protection is a feature? Where in my comment did I say that?
  - laputan_machine 5y ago
    Fair enough, I've reworded my post to more accurately convey my point
thereddaikon 5y ago
I'd rather such things be a purely hardware implementation.

Bancakes 5y ago

Knowing BSDs, this is codeword for "we don't know how to do it, nor do we care to."

nix23 5y ago
Arch user right?
- Bancakes 5y ago
  Correct

perihelions 5y ago

There was a lengthy HN thread discussing the question (software-based thermal protection): https://news.ycombinator.com/item?id=24596248 https://news.ycombinator.com/item?id=24596248 ("Let's talk about safety of Pinephone (xnux.eu)") (2020)