Hacker News Reader

I believe the FSF position is that non-updatable firmware can be considered "part of the hardware", while updatable firmware cannot. I think they're concerned that updated firmware could change how the device functions in ways you can't control.

Except that I am almost 100% certain [1] that they are using the RS9113 which as I suspected IS updateable (in some cases wirelessly) [2]. In fact in the Linux Firmware tree they have multiple firmware images depending on how you want the device to function. [3]

>The host MCU can update the RS9113 module FW over UART using the kermit protocol or over SPI using the proprietary binary protocol. The default UART baud rate is 115200 kbps 8N1 with xon/off or no flow control. For baud rate >900000, hardware flow control must be used. Refer to the WiSeConnect PRM for more info - the "Upgrading the Firmware in Module" section discusses the SPI mode and "Firmware Upgradation" section discusses the UART mode.

[1] https://source.puri.sm/bob.ham/image-builder/commit/856c9caf... [2] http://www.redpinesignals.com/faqs.php [3] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

There are a lot of games overall. They made this entire post about how using a blob on a co-processor is fine because FSF guidelines have an exception for that. So after some gymnastics, you can make it look like your main processor needs no blobs. I don't know how they wrote this article with a straight face: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

What would you propose they do?

Live with the blob, and accept that the certification is quite meaningless if you have to do such gymnastics to get it.

These are not Purism’s gymnastics; they’re those of the FSF.

And I kind of agree with them. If code doesn’t have DMA or network access, I’m pretty happy to treat it like the code in my microwave.

There’s firmware blobs in almost everything. I’d prefer them to be FOSS, but we all need to get things done :)

>The i.MX 8 has some A53 cores and an M4 core all on the same silicon.

The FSF guidance on the co-processor exception is breathing room. I haven't read the fine print on what they mean by co-processor. My conjecture is that it was written at a time before these sort of architectures, and referred more to traditional GPU over pci-e like co-processors so that non-essential stuff can be excluded from requirements. In this case, you have single silicon, and single RAM. RAM needs blob for init. You claim that if you squint, you can see single silicon as multiple processors, and voila RAM init quandry is solved. That is purim's gymnastics.

One of the funny examples is Raspberry Pi where ARM cores are actually coprocessors.

I disagree. Requiring it puts pressure on the manufacturers to do it better and be more open.

Loading the blob by M4 core instead of A53 core don't put any pressure on the manufacturers.

Just letting another chip do the loading seems to be only part of the solution. The other part is to load it from read-only memory so it cannot be modified after production. That is what I consider to be the crucial property: the firmware must not be updateable.

> the firmware must not be updateable

Updatebale firmware With physical switch would be much better solution than completely non-updateable firmware.

You have two options:

- either you give your users an ability to upgrade the firmware, so they can RE it, write and use an open replacement

- or you don't give your users an ability to upgrade, which doesn't help anyone since they can never be sure if the chip manufacturer didn't put some undocumented interface somewhere that even you weren't aware of; so now only the chip manufacturer can upgrade the firmware and the user can't

Realistically, in a context of mobile phone components, there hardly such thing as "not updatable firmware". You can never be sure.

> so they can RE it, write and use an open replacement

Crypting and signing is trivial, so nobody is going to RE Intel ME or microcode updates.

Sure, but there are plenty of unsigned firmwares out there that could be replaced, but need to be sealed in order to get RYF certification.

I understand why FSF has this "no downloadable firmware" rule (they have to put a line somewhere), and I'm by all means a 100% Free Software zealot, but I honestly believe that this rule simply makes it not worth pursuing FSF certification in a device like a mobile phone, as you're ending up with actually less freedom as a user and no way to verify that it's really worth it (after all, a possibility to upgrade your firmware may simply be undocumented and you have no way to be sure that it's not there).

Just speaking as one free software lover to another, I am happier that the Redpine Signal doesn't need downloadable firmware to function.

It means that there will be just one version of firmware shipped. Just one version of firmware that the whole community will focus on analyzing, patching (only for the librem phone, it's only pure chance if that helps any other device), and if a patch is needed:

* Redpine can either tell the entire community how to flash the firmware, or else the egg is on their face for shipping a broken firmware. *

(There's basically no chance that the Redpine chip is actually not field-upgradeable if you have the right vendor tool and probably also a windows box to run the tool on.)

The rest of the world seems to think, "flash it every time it boots up and I don't really care where that binary blob came from."

I'll also just add, I can respect your position. Thanks for supporting Free Software, and I get it that there's value to being able to upgrade. That's kind of what I'm hoping happens later, if (cough, cough, when) there's a bug or exploit or worse.

If purism waited until a manufacturer offered a perfectly open device, they'd have to wait until GNU Hurd ships on a phone... j/k

Well, of course, not having to deal with distributing and handling the firmware in your OS is a very nice bonus. However, I could have worded myself better: FSF's RYF certification actually isn't about "downloadable firmwares", it's about "upgradable firmwares". IOW, if the user is able to install the software by themselves, the preinstalled one must be free, period - and no closed alternatives can be advertised or suggested. Redpine releasing a tool to flash the proprietary firmware would likely make the Librem 5's RYF certification void, which is a thing that IMO isn't helpful to anyone involved.

Openmoko already went through that route, although AFAIR there was no formal RYF programme yet back then. Freerunner was all fine from FSF PoV until Openmoko released a firmware upgrade for the Calypso baseband that fixed some ugly bugs, suddenly making it not free enough for FSF. Which is especially funny considering that it basically opened the way to run OsmocomBB on that thing.

Yeah, the Openmoko situation and OsmocomBB really highlights the nuances of the situation.

I wish the FSF RYF requirements explicitly allowed a later release of a flash tool. (It seems like this only improves the user's freedom - suddenly you can treat your device as programmable, but only if you want to.)

But I don't think people will be nearly as upset if the Librem 5's RYF certification becomes void later.

I think the impact will still be large if it has RYF certification on launch.