Purism please bring a list of ALL the blobs for Librem 5 visible. At the moment there are no a dedicated list of blobs detailed for L5 which do not know exactly on u-boot. Purism is just hiding and ignoring the existence of blobs for the Librem 5, which make L5 and Gnu PureOS Obscure.
A list of blobs will help to alert the user, but also keep super tracked this evils blobs for a Libre replacement.
Hiding or ignoring the blobs will never resolve the Malware issue, but Protecting them.
Librem 5 blob status
| | | | | | | |BLOB ADN| | | | | | | |
Controller
Firmware
Extension
Filesystem
Arch
Size
Libre
Root
User
Note
SoC
Includes DDRC training code and DP firmware
?
?
?
?
No
Yes
No
Loaded as part of the initial boot process.
Modem
Separate SoC with its own hardware and software
?
?
?
?
No
Yes
No
Completely independent from the main system.
SparkLAN
Loads from the “firmware jail” in NOR
?
?
?
?
No
No
Yes
Requires non-free firmware.
Redpine
Loads from the “firmware jail” in NOR
?
?
?
?
No
Yes
Yes
Requires non-free firmware.
DMA
Can load from /lib/firmware, defaults to ROM copy if absent
?
?
?
?
No
Yes
Yes
In PureOS, the ROM copy is used.
Touchscreen
On-board flash memory
?
?
?
?
No
Yes
No
Firmware boots from this storage.
GNSS
On-board flash memory
?
?
?
?
No
Yes
No
Firmware boots from this storage.
USB-C
Reads firmware from SPI NOR flash that also contains the squashfs “firmware jail” file system
?
?
?
?
No
Yes
No
Shares storage with other firmware.
STM32L4
Not documented, but suspected to have updatable firmware
?
?
?
?
Yes
Yes
No
Some vendors do not disclose the existence or update method of this firmware.
eMMC
Not documented, but suspected to have updatable firmware
?
?
?
?
No
Yes
No
Some vendors do not disclose the existence or update method of this firmware.
One time I wanted Android on my Librem 5 so I went to NXP website who makes the CPU as I understand it to be, and I downloaded their Android image for NXP i.MX8M Quad and flashed it to my Librem 5. This was of course a comically terrible idea and the device stopped booting.
But when I flashed it back to PureOS, using either uboot or anything else, nothing mattered and the Librem 5 wouldn’t come back. Then @dos on the forums gave me a magic command because he is a magic man, and the command wrote to a different place on the Librem 5 that flashing PureOS with the flash script doesn’t clear out and then the device was reset back to standard mode and was usable again.
Does that “different place,” where Android can write to but flash script for PureOS doesn’t write to, count as a blob (in your opinion)?
Also fyi don’t download Android from NXP website, the NXP website asks you to agree to a ton of software license agreements about not reverse engineering how your NXP chip and its software work and fyi NXP if you’re reading this feel free to terminate all my agreements and block me from downloading Android image because IMO the only agreements binding my L5 that I consider valid are the agreement of purchasing it from Purism who says there are no agreements and the device is mine to do whatever I want with.
(Edit:) In summary:
What is the other place on my L5?
How much space is in the other place?
Can I store my own stuff there for fun?
What you’re talking about are just standard eMMC boot partitions, accessible from Linux as mmcblk0boot0 and mmcblk0boot1. There were scripts in librem5-devkit-tools that made use of them back when I joined in 2019 already, but the user-facing flasher did not use them until recently (since version 0.0.5, librem5-flash-image uses one of those partitions to flash u-boot there instead of relying on the one embedded into the image, which lets bootloaderless images work too). What happened in your case is just that the script you used happened to set the active boot partition to another one, and the older version of librem5-flash-image didn’t touch it as all and didn’t reset the boot partition setting either, so the SoC continued to boot from another partition than the one L5 flasher has written the correct u-boot to.
I’m pretty sure I have written several such lists here already Nothing’s hidden there.
u-boot image contains DDRC training code and DP firmware.
The modem is its own whole SoC, with separate hardware and software.
Both WiFi cards need a non-free firmware to function; the Redpine card contains an on-board flash where it can be optionally loaded from, and both Redpine and SparkLAN cards can have their firmware loaded from the “firmware jail” stored in NOR.
DMA controller has some firmware that can be loaded via /lib/firmware, but defaults to a copy in ROM if it’s not present (which is the case in PureOS).
The touchscreen controller and GNSS module both have on-board flashable storages where their firmware is booted from.
The USB-C controller reads its firmware from the SPI NOR flash that also holds the “firmware jail” squashfs filesystem.
If I haven’t forgotten anything, these are all components that we know how to reflash or load firmware into. As usual, there may be others that simply don’t advertise or document such possibility - eMMC would be an obvious one to suspect to have some flashable firmware, but there may be more - the fact that a component vendor did not specify an on-board flash with a way to upgrade it in its docs does not yet mean that it’s not there
Lol. I would like to have a perfect world. However the Blobs are on the Modem because some One have to take care of interoperability for intelligence in that case. And for not hate your neighbour device while flooding some sequences, to interrupt.
We have to follow some rules on the road and about the internat to have som interconection. Without we will not have. So it is not about bad intentions.
I am fine but do not trust it without addition layer of encryption. And it have to be open to show you know?
I work as a software developer although lately I seem to find myself in conversations talking to chatgpt users more often, and writing good software less often, as I wonder more and more about if and when I’ll be replaced by some absurd machine.
Is there any chance that these blobs could be rewritten by versions made with a ChatGPT/LLM in each case? I know ChatGPTs are probably a combination of being less powerful than advertised, more inherently malicious and deceptive than advertised, and possibly a bad thing for society. But if we could combine a bad thing (LLM) together with another bad thing (proprietary software) and make a good thing (open source remake), would it maybe be fun and interesting to do so?
This seems sad. If “we need rules of the road” means “you’re not allowed to read or understand how your computer sends and receives radio signals,” then what are we even doing?
No Dlonk, its about RFCs some folks try to follow to have some ip or tcp work in the first place. The ITF have to meet each other and talk about.
This can not be covered by an A.I. in future, or only digital. Which is not as bad as it seems but bad for humans in real life.
P.s.: The intelligence have brought up another not needed but important layer for some humans. And this kind will have to be in future to have some cheat space available. It seems important for some reason.
I had a class one time where I had to read RFCs and implement internet drivers in a custom OS the professor developed. Compared to dealing with soul-sucking proprietary machines, adding the IPv6 and UDP stack to the system that had only a single eth_write(void*) function was easy and fun. (We did not have to implement TCP, but I would imagine doing so would be likewise straightforward albeit slightly more time consuming.)
Why does adherence to RFCs and common guidelines in any way necessitate closed source proprietary blobs?
In Germany we need blobs fot WLAN or radio communication to not inteferrance in the first place. But as i mention. Because the public ad state as a whole will have some interest to snudge and explide or uncryped messages. Which i do not share, but some may have to, have this interest.
I would like more influence to some Algorithm, individual or A.I. in the first place that it have to be like this in the first place to protect lifre from chemicals, environment waste or atomic bombs or kind of A.I. in the free wild.
To emphasise the previous point … this is just standard, documented functionality that you will find in the eMMC specification.
If your operating system is using it to boot then it would not be a good idea to use it for your own purposes. There are technically two boot areas but I think the intention might be that the two boot areas have the same content except when messing around with a new version of the bootloader.
Each boot area is 4 MiB - so not a lot to play with. But, again, I recommend that you leave them alone.
Just added a initial blobs table for Librem 5 above, as dos just added a super blurry blobs table. I will improvements the table constantly.
I am very very disappointed with the high level of blobs needed in librem 5. I am sad for librem 5 as nobody worried about the freedom for Librem 5 from blobs.
This is what causes mainline, linux and uboot issues, i.e. leaving the responsibility to mainline for a real freedom for a device.
Even a Donkey knows that Linux and Uboot do not care about real freedom for devices. And also including firmware to user space just added control for vendors and slavery to user. imho.
Added to table above: Extension, Filesystem, Arch, Size.
I maybe unblobing the opensources friends.
ATM i stopped using my Librem 5, as i not like how it is structured. I do not want Honeypots Uboot on eMMC but SPI at very least .
Remove Jail from SPI as it is useless and deceptive. Redpine do not need jail in dowstream. I fully want downstream if there are real freedom.
I don’t understand that table. What do the columns mean? “Libre”, “Root” and “User” seem to have “No” and “Yes” placed at random, as I can’t figure out what the pattern behind them is supposed to be.
There’s also one more flashable component - the smartcard reader, which is a STM32L4 microcontroller. This one is running a GPLv3+ code though.
Libre: mean that firmware it is FSF License.
Root: mean that firmware can NOT be storaged in /lib/firmware
User: mean that firmware can BE storaged in /lib/firmware
This is nice! i just added STM32L4 to table marked as Libre. This is first libre firmware for L5.
What it this blob: skl_hda_dsp_generic-tplg.bin ? it is for audio acceleration?
The table still incomplete and it is a long term work.
I may delete eMMC from table as there is not a record of an updateable firmware. I am pretty sure there is a blob into emmc. So what to do with eMMC case?
I found it on a Librem5 that was recently installed with crimson luks support in /lib/firmware
I do not know how it got there, yes i was surprised too as i never seeing this blob before, nor on L14 either.
Nothing’s hidden there.
