Hello all,
I’ve always lamented over the fact that modern laptops are so closed down and was ecstatic to learn about this open hardware project. The LS1028A being technically capable of FSF certification was super exciting, unfortunately by the time I learned about it it was discontinued. Will there ever be another reasonably powerful ASIC with no blobs available for the Reform?
Some LS1028A modules are still for sale at Crowd Supply (MNT Reform page). Caveat: even the LS1028A needs firmware to use the internal display, it’s only firmwareless when used as a headless server for example.
Oooh thanks for letting me know. I was also worried that I’d never be able to get the LS1028A board!
Rk3588 I believe is the next best thing in this way. Also it has 3x the speed at least than LS1028A
FYI, the RK3588 requires proprietary binary firmware blobs for (1) DDR initialisation in the bootloader and (2) the GPU. The RK3588 has Valhall gen 3 Mali GPU which now requires a firmware blob whereas earlier Mali versions didn’t.
The most recent SoC which can be used without proprietary blobs is the Rockchip RK3399.
True, but if these blobs are used only at initialization, and only to provide instructions to the hardware, then there is little difference between this and “burned-in” firmware. This is why FSF for instance has a somewhat relaxed attitude towards this kind of blob. (I’m assuming the blobs in question fall into this category.)
It would still be worthwhile for a skilled reverse engineer to analyze the blobs for potential issues. Personally I’d welcome an organized effort to poke at widely used blobs, firmware, etc to certify them as “safe enough”. Would happily donate to something like this if it had trustworthy people behind it!
IMHO silicon errors (or even bugdoors) are more of a risk than this type of blob.
if these blobs are used only at initialization
The GPU blob in the RK3588 manages command submission, it isn’t used only at initialisation.
there is little difference between this and “burned-in” firmware
One could say that there is “little difference” between hardware which requires a firmware blob during its whole operation and hardware which doesn’t. You’re not really saying anything beyond making clear your own personal priorities. For me, there is an enormous difference between an SoC that requires a proprietary blob in its bootloader in order to initialise DDR and an SoC that doesn’t.
Freedom isn’t safety. Indeed, fighting for freedom is often very risky.
Thanks for the additional context, in that case this does indeed warrant a closer look. After some digging, Collabora claims that only the DDR initialization blob remains, as BL31 can now be built without the closed source binary. There are still some gaps in the FOSS GPU driver (like HDMI out) but those are expected to be implemented by Q2. If I have something wrong here I’d welcome a correction!
Freedom isn’t safety
Yet freedom requires the ability to set personal boundaries, which is not possible without security. Fighting to increase freedom may be risky, but this does not imply that security should be an afterthought. Quite the contrary! Anyone fighting for freedom should be especially aware of security concerns if they have any desire to preserve their current level of freedom at a minimum.
I’m a bit confused by your comment. The article you linked to confirms that a blob is required for DDR initialisation. Also, the article doesn’t say anything about the GPU firmware blob. The firmware blob is not the driver and as far as I know, nobody has reverse engineered the firmware blob.
In which case, nothing you’ve said contradicts what I’ve said. The RK3588 requires proprietary binary firmware blobs for (1) DDR initialisation in the bootloader and (2) the GPU.
I think you missed my point: the concern in this thread is not security but freedom.
Sometimes, people talk to each other without the intend to contradict but maybe just to expand on the existing topic. 
Clearly we all have different priorities and “software freedom” means different things to each of us. I personally do not mind the DDR initialization blob in principle. My problem with it is that the licensing of, for example the NXP DDR blobs disallows redistribution by anybody who is not selling NXP devices. This makes it impossible for, for example, Debian to distribute this blob in the non-free-firmware section of the archive. I hope this situation is better with the DDR and GPU blobs for rk3588?
Maybe we can hope on some more-free riscv socs in the future.
Yes, as discussed upthread, an initialize-only DDR blob, though imperfect, might as well be burned-in firmware. I linked that article because they finally had a free BL31 and I was under the mistaken impression that this removed the last of the GPU blob code. I was wrong, though… it’s very difficult to find clear information on this if you aren’t already following it! Apparently, the CSF firmware blob mali_csffw.bin is still required by the Panthor driver. This is indeed more complex than the DDR blob and needs a free/open replacement as the GPU MCU controls 2 of the 3 hardware security layers that prevent it from having arbitrary memory access and the CSF drivers are imperfect. Fortunately from a security standpoint this is easy to mitigate; avoid granting untrusted GPU access (browsers especially). Always a good idea anyway given the dire state of GPU drivers in general. But you were correct here.
You brought up security, so I responded to that. I personally believe that freedom and security are inextricably connected, and any supposed freedom that comes without security is temporary at best, and vice versa. I too often find FOSS advocates downplaying the need for security, or even expressing hostility towards security, so I like to clarify this perspective when the opportunity arises.
This is your opinion. I disagree.
Err… you brought up security. You said “silicon errors (or even bugdoors) are more of a risk than this type of blob”. The word “risk” here implies security. That’s why I pointed out to you that this thread is about freedom and not security.
Uh… yes. This is what “free software” mean for the GNU project.
In Debian we have a different set of principles that define software freedom, the Debian Free Software Guidelines. Apparently, those principles differ so much from those of the GNU project, that Debian is not a free enough distribution for the GNU project.
I’m not saying that Debian’s perspective on the definition is a better one. I want to show why I believe that “software freedom” means different things to each of us.
And even if you give the GNU project the sole authority to define what “free software” means, the position of the GNU project towards matters of software and hardware freedom is not set in stone either but changes over time. As new technologies get developed, as new trends show up in society and as different people shape the GNU project, the meaning of “software freedom” for the GNU project changes as well. Have a look at the page that you linked from 10 years ago as archived by the waybackmachine of archive.org. The text was different back then. Things are in flux, things change and “free software” has different meaning for different people or different groups of people.
It will certainly need to adapt with AI developments. One thing that concerns me are the messages now coming from big tech trying to tell us to give up programming, and that AI will be writing the software.
Interesting conversation. I think we all enjoy understanding the tech, and having the freedom and choice to implement, fork, amend, dissect, etc are choices we do not want to give up. And also that we have the tools to understand the implications of using software/hardware that we may be compelled to use.
I would note that the Wikipedia page for Debian Free Software Guidelines redirects to a different page. That page is named:
“The Open Source Definition”
And as if this weren’t damning enough, in that page it’s noted that when the Debian Free Software Guideliness were written:
“The (then) Three Freedoms, which preceded the drafting and promulgation of the DFSG, were unknown to its authors.”
You’d be more convincing in your demonstration if the author of the document you referred to hadn’t subsequently founded the open source movement, explicitly distinct from the free software movement.
People who use the term “free software” to mean something other than the meaning used in the free software movement (codified by the GNU project’s free software definition) are either ignorant or trolls. Either way they are excluded. That is true now and it was true 10 years ago.
Please maintain a respectful tone. People are allowed to disagree with you and your preferences.
Software has been freely shared since time immemorial, whether that’s tapes, floppies, or code torn from the back pages of a magazine. No single person or group should get to dictate how people acquire or use the software that works for them.
from what I read, here:
https://mntre.com/modularity.html
It seems that not needing the gpu firmware is being worked on.
Also, for the boot blob,there is this:
The question I wonder is when will these chanes sow up in the linux kernel
I can’t see anything in that page that suggests the GPU firmware is being worked on.
This is not about the boot blob.