I don't see any "wishy-washy fluff". It states quite clearly:
we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose.
In other words, you can modify the firmware on the Wi-Fi card or modem.
Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.
> Methods to flash the firmware on the Librem 5 are outside of my area of expertise.
That's CSO code for "I have no idea what I'm talking about, but I'm just giving you a canned response about our principles with no technical details and hoping you don't pry further and prove me wrong".
He never explicitly addressed the RAM blob. If he knew it was flashable he would've outright said it to answer the question. But he did not.
> Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.
Incorrect. The code is loaded in the DDR PHY. It then runs continuously. It is required for normal operation. This is because LPDDR requires continuous runtime re-training at its higher performance modes. What only runs on boot is the (dumb as hell) code they wrote to run on the Cortex-M4 as a workaround, because the FSF's ridiculous requirements forbid you not just from running proprietary code on the main CPU, but from touching proprietary code on the main CPU.
So Purism built code that runs on cpu A to run code they built that runs on cpu B to load a blob from external read-only memory C into cpu D, just so they could claim cpu A never got digital cooties from touching the blob.
Please appreciate the stupidity of this entire ordeal.
Means it can't be modified without the user knowing, and it also can't be modified with the user knowing.
Unless the Librem 5 literally has a DIP switch for "enable flashing RAM code", read only means read only, period. It means the write protect pin is tied to protected, or a set-only protect bit in the SPI flash config was flipped.
>Please appreciate the stupidity of this entire ordeal.
I have had a conversation with you about this before and I still don't see what the issue here is. Best case, that seems it might be covered under the secondary processor exception, worse case, the FSF would not endorse it. Since you have the ability to reverse engineer this and fix the situation once and for all, why not do it? What is the real problem here? If you are trying to get Purism to pay you for this work, I would suggest contacting them about that privately.
Purism has said that it will be providing proprietary firmware updates, and it already has instructions how to update the firmware for the RS9116 WiFi/BT on its web site.
Because Purism selected components for the Librem 5 that will be manufactured for many years, it is more likely to get firmware updates than most smartphones. Because the drivers are all FOSS, they can be updated by the community, and some cases the manufacturer helps maintain the mainline Linux drivers, so timely updates are very likely. For example, NXP promises to sell its i.MX 8M Quad processor until at least Jan. 2028 and it helps maintain the mainline Linux driver. Likewise, Redpine Signals helps maintain the mainline driver for the RS9116 WiFi/BT and likely to keep manufacturing the chip for at least the next 5 years.
In contrast, the SoC used in a typical smartphone is only manufactured for 1-2 years and it typically only gets 2-3 years of support from the manufacturer, so the Librem 5 is more likely proprietary firmware updates than most smartphones.
As for the question of whether it is better to store the proprietary firmware in the /lib/firmware directory or in the component or in Flash chips on the motherboard, there are advantages and disadvantages, so you have to weight what is important. When firmware is stored and loaded from the /lib/firmware directory, it is easier to update and the user will automatically get the latest firmware when upgrading the software on the device. In contrast, the user has do a separate procedure to upgrade the firmware and many users are unlikely to do it, so any potential security holes in the firmware are less likely to be closed with updates. However, a lot of this depends on what Purism does in the future to push firmware updates, so we shouldn't automatically assume that the Librem 5 will be insecure. The benefit of not storing the firmware in /lib/firmware is because it makes the user more conscious of the proprietary blobs on the device, and the user can make a deliberate choice whether to install firmware updates or not, after reading the description of each update. Also, it is harder for the firmware to be hacked by a bad actor when it is stored in the component or a separate Flash chip, because it requires a separate procedure to flash the firmware, so it can be argued that it is more secure. Another benefit is that system updates can be offered without including any proprietary files, so there are no restrictions on how they are distributed and installed.
In terms of promoting software freedom, I don't know of any cellular modems or any GNSS with FOSS firmware. There were only two WiFi/BT model series whose firmware was reverse engineered by the community but they never got past the experimental state and are now hopelessly outdated since they were 802.11b/g devices. There are some ath9k 802.11n models that required no firmware, but they have poor range and are energy inefficient and require proprietary firmware for the Bluetooth.
In other words, there is no realistic way to make a modern computing device without proprietary firmware, and the only hope is to pressure the manufacturers to release code or documentation for its firmware, but the modern patent situation with wireless communications makes that extremely unlikely to happen. However, the FSF's insistence on trying to separate the proprietary firmware and not let it be executed on the main CPU cores does draw public attention to the problem and show the component manufacturers that there is public demand for free firmware. When companies like Purism go through extreme steps to avoid executing DDR timing code on the main CPU cores, by adding a separate SPI Flash chip to the board to hold the blob and not using the Cortex-M4 core for any other purpose but to execute that blob, it sends a message to NXP that its customers really hate that proprietary blob and it should be eliminated. In contrast, a company that stick that blob in the main Linux file system tells NXP that its customers don't care about that blob and there is no pressure for NXP to eliminate it in future chips. The value of buying RYF products like the Librem 5, RaptorCS computers and Lulzbot is that it is creating a public statement that consumers care about not having proprietary blobs, and that the hardware industry should cater to that crowd. What Purism is doing value in promoting a public message and it is based on a long-term strategy to pressure the industry to free its firmware, whereas the people who criticize it have no strategy for ever achieving change. If they have an alternative strategy for how to free the firmware, I would love to hear it.
The more important point is that Purism selected components from hardware companies that are more willing to collaborate with the community and listen to Purism's requests, so there is more possibility of driving change up the supply chain. Purism paid Redpine Signals to modify its firmware so it could meet the RYF criteria and NXP engineers work with the community on the mainline Linux driver for the i.MX 8M, so it is possible to influence these component suppliers.
we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose.
In other words, you can modify the firmware on the Wi-Fi card or modem.
Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.
Edit:
> can’t be modified without the user knowing
> without the user knowing
Did you actually read what you quoted?