Crystal Installs OpenBSD on the PinePhone | Hacker News Reader

Crystal Installs OpenBSD on the PinePhone

exoticsilicon.com

109 pointsPanino58 comments

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.

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

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 it looks like it is using http://files.pine64.org/doc/datasheet/pine64/AXP803_Datashee... as a separate IC

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

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.

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.

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.

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.

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.

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

They're independent of each other, so flashing the OS can never damage the other chip. Isn't it obvious?

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.

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.

Understanding the risks is what makes a person want a design that eliminates them!

As stated before, moving the risk somewhere else does not eliminate it.

You can and should eliminate this particular risk when flashing the OS.

I'm not suggesting that it's not FOSS firmware, just that it runs on its own controller and is flashed independently of the main system. Kind of like how the Pinephone modem runs its own Linux, but without the blobs that that uses (modems are more proprietary than power controllers need to be)

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.

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.

>You think lack of thermal protection is a feature?

Where in my comment did I say that?

Fair enough, I've reworded my post to more accurately convey my point

I'd rather such things be a purely hardware implementation.

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.

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

Arch user right?

Correct

There was a lengthy HN thread discussing the question (software-based thermal protection):

https://news.ycombinator.com/item?id=24596248 ("Let's talk about safety of Pinephone (xnux.eu)") (2020)

Is Crystal the name of the author of this post? I couldn't find any other mention of the name, neither in this article, in its source or on the about/faq page of the site. This doesn't look like it's a personal blog where I'm expected to know who the author is already. (I was curious since I originally thought the article had something to do with the Crystal language, e.g. like how Zig is being used for cross-compilation)

Going by what's on the other pages, it seems to be the name (or nickname) of the author:

> Our resident Crystal Kolipe checks out the Pinephone, with mixed results.

https://www.exoticsilicon.com/crystal/pinephone_202102

https://www.exoticsilicon.com/welcome

Between the EULA for, erm, looking at the website, or the intro page, or the bird that flies away on the home page, I don't know whether I'm curious or concerned

One returns ETIMEDOUT, and the other returns EIO. Even without further understanding the code at this point, we can add two printf calls to identify which path is being followed

Printf debugging feels like stepping back in time. I guess OpenBSD does not have dtrace?

OpenBSD does have dt(4) which is similar:

https://man.openbsd.org/dt.4

https://man.openbsd.org/bt.5

Wow, it looks like its compatible with bpftrace.. That's pretty cool. I wonder why the author didn't use it.

This comment probably comes off as ignorant, but what is the point of BSD today? The only use I see is for ZFS because it is built in.

Lots of reasons, but often not what you think of as a typical desktop or server OS. FreeBSD is often used by corporations as a base to build things on because of its more generous license. Playstation's OS is based on FreeBSD. NetBSD is used on lower power or exotic devices since it is designed to be very portable, and is used as a base for some rump kernels and being able to compile device drivers into application software. OpenBSD is quite popular for bastions, routers, and firewalls because it is easy to administer, secure by default, and has pf for firewall rules. It is also a research OS and can experiment with changing things or deprecating things more quickly.

And some of it is just preference and what you need it for. I run OpenBSD servers because I like how administration works, it is secure by default, upgrades are extremely easy, and all of the software I need works on it.

> because of its more generous license

Gifting an OS to companies that use it to compete against the FLOSS ecosystem. That's a bit of a self-own.

The classic counterexample is GCC, which so contorted its design to prevent being embedded in proprietary software, that it allowed LLVM to take off as a powerful competitor not only due to its friendly license but also by virtue of being architected in a way easier to integrate with IDE software. Stallman’s own self‐own.

GCC "allowed" LLVM to exits by not having the same license as LLVM in the first place? That's some circular logic.

No, irrespective of GCC’s license, Stallman intentionally hampered GCC’s output to be difficult to use with other free software, in hopes that it would also be difficult to use with proprietary software. See this thread:

https://news.ycombinator.com/item?id=26397634

...and the conversations was about license so stop shifting the goalposts.

Different purpose, which succeeded. It is a different philosophy to not be jealous of whatever use someone may make of it, even to making money. Why force a commercial venture to duplicate work if you can help them as well? If you can release high quality software which gets used and advances the state of the art _everywhere_, then that sounds like a good deal. I understand why copyleft might be useful in some circumstances, Linux has gained great adoption with the commercial tech giants because of it, but there is room for all philosophies in the code world; and they suit different purposes and temperaments. Some people simply feel happy that their high quality code is adopted and used, maybe they play Playstation and are happy they contributed to high quality entertainment, the world is a better place because of it.

15 PB of scientific data in our research company is served in production for twelve years using ZFS on FreeBSD and never failed one second. Billions of files replicated using ZFS send and receive streams in mere seconds. It's only flaw, ZFS diff is slow and gives inaccurate results. Grassroots I'am exploring are Minio and WeedFS and maybe Ceph.

I believe Netflix uses FreeBSD quite a bit?

FreeBSD is also the base for JunOS, used by every Juniper Device.

OpenBSD is the place where ssh development happens, as well as LibreSSL and some smaller projects.

ZFS is great, jails are great (much clearer and simpler than the complexity of containers on Linux), the properly integrated OS can still do little usability things that Linux can't like ^T. But mostly it's just stable and reliable and doesn't keep changing how everything works. Sound is still OSS. Network configuration is still ifconfig. The whole devfs/hal/udev mess was much less of a mess. I don't have to deal with systemd changing how everything works.

Frankly I'd turn your question around: FreeBSD does everything that Linux used to do for me, better than Linux does. So what's the point of Linux today?

Since the original post is about OpenBSD and the parent is about FreeBSD, just some addition:

1. ZFS is not supported in OpenBSD. Here's why OpenBSD doesn't have ZFS (pretty much every other BSD does): https://old.reddit.com/r/openbsd/comments/7xsx8u/why_doesnt_... (There's probably a better link out there)

2. Jails are not supported in OpenBSD. AFAIK, they are a FreeBSD-only feature.

I'm caught in a strange situation where my MacBook Pro wireless is supported by OpenBSD (and not FreeBSD) but I really like ZFS and Jails. Some features like those about trackpads, sound, wireless "just work" in a basic Arch install but not on FreeBSD. So I'd take "FreeBSD does everything that Linux used to do for me" with a grain of salt, because that has not been true for me.

OpenBSD does have pledge, on the other hand. And yeah, different systems have different features and tradeoffs; some people could legitimately say to take "Linux does everything that FreeBSD used to do for me" with a grain of salt, because that has not been true for them (say, if they like ZFS + boot environments, which is a relative pain on Arch).

I still haven't gotten boot from encrypted root pool with GRUB set up properly; it fails and drops to initramfs, I manually import and mount, after which it continues boots fine ¯\_(ツ)_/¯

Just think of BSD as a much better version of Linux.

That's not a good argument. It's just as bad as 'I use Arch BTW'. No explanation or reasons given.

Linux does all the arguing for me.

One obvious point ignoring all technology differences would be the license. I always like to have more options and even though I haven't used a BSD in maybe 5 years now, I'm still very happy they exist.

I'm most fond of OpenBSD and am VERY happy the project exists. OpenSSH alone makes the project a winner for me.

I also miss the documentation (man files) of the BSDs. They always seemed clearer to me than my current Linux counterparts.

Just to piggyback on this, the source code for the BSD utils is eminently readable and simple, almost always more so than the equivalent GNU options. I understand that there are reasons for this, and I'm obviously very grateful for all sorts of GNU software. But if I want to see how something works, I'm going to go for the BSD sources first if they exist.

It makes a great router.

I have summarized many of the points here:

- https://vermaden.wordpress.com/2020/09/07/quare-freebsd/

Thanks! This article was good.

Thanks :)

As a refuge from Linux, Windows and / or OS X.

Reply on news.ycombinator.com