[bildung]

> 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]

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]

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]

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.

[Arnavion]

So much energy being wasted in this thread...

That's already how it works.

The PMIC can be configured once, and it retains its configuration across reboots until OS reconfigures it.

[toolz]

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.

[DarylZero]

Someone could accidentally flash an invalid image to a phone. Happens all the time. Or maybe they flash the latest Linux kernel dev branch and it crashes. That shouldn't disable battery safety.

[toolz]

okay so if faulty flashing is the problem, how does flashing two parts of the device make flashing better?

[yjftsjthsd-h]

We are literally having this conversation on an article about a case where it would be useful; if battery control was on a separate controller that was flashed separately, then you could install OpenBSD and not worry about starting a fire.

[toolz]

What do you mean? Developing a chip with contained firmware isn't free or equivalent to software definitions, if that feature was necessary you may not even yet be in a position where you have a pinephone the even flash a new OS onto.

Further the article has domain knowledge and knew about this issue. Making my point about the type of person capable of flashing another OS as being someone capable of understanding the risks.

[DarylZero]

Because reflashing the chip that stores the OS can't affect the battery. It's simple physical isolation. What if the entire chip with the OS physically fails? The code with the protection should still run.