On Tue, 07 Sep 2021 14:18:01 -0400 Christine Lemmer-Webber wrote: > Oh really? I really wonder how to improve the situation. Several companies are making hardware that don't work with fully free software but a lot of users using their hardware think that they are running only free software. With Puri.sm laptops for instance, the issue is probably that the Coreboot project has a reputation of being fully free while it's not. On recent computers, in addition to the Intel Management Engine / AMD PSP issue, there is also a huge nonfree binary (Intel FSP or a nonfree version of AMD's AGESA) that does all the work. Another common misunderstanding is that "small nonfree firmwares" could turn to be really issues. As they are not well understood it's hard to know. For instance the GPU firmware of the Raspberry PI, at least on some models is a complete operating system[2]. The FSF has a (Respect Your Freedom) certification[1] to address precisely that kind of issues, though they require everything to work with free software not to steer users toward nonfree software. And that strictness is also a good thing in my opinion as otherwise users would probably end up buying hardware thinking it can work with only free software, and if it's too painful (for instance if the GPU doesn't work) they'd end up using nonfree software anyway, despite the fact that they decided to buy that kind of hardware precisely not to have to run nonfree software. > And it's not on hardware, needs to be compiled into either > u-boot or the kernel I guess? I don't know, I didn't look into where the nonfree binary is. > I had thought looking at the manual of the MNT Reform that only the > HDMI port required a blob. This will be disappoiting if we can't get > the Reform into Guix proper soon. There are of course channels, and > maybe the work here might have to move to one of those locations > rather than getting committed to the main guix repo, but I hope not. In their "Re-Introducing Reform" blog post[3], MNT Research states the following: > Unfortunately, during the boot process, i.MX8M requires a > closed-source firmware for an embedded ARCompact processor in the > Synopsys DDR4 PHY. This firmware, which is only a few kilobytes in > size, is responsible for regulating the physical connection to the > DDR chips in the face of changing temperatures. We are in contact > with reverse engineers with the goal of analyzing what the > capabilities of this so called PHY Utility Block (PUB) are, and to > find out if we have a chance to replace this firmware at some point > in the future. So it would also be a good idea to remind them about that and potentially look for other declarations from MNT Research about the DDR4 firmware. A way to handle that could be to make the most basic firmware that would make the machine boot and keep the machine running, not necessarily with huge performance. This is how it was done for the first generation Core I.5/I.7 computers in Coreboot. It was then improved to have cleaner code and make it way faster. > the trick is to flash the non-free bootloader into the > SoM's eMMC then you don't have to see the non-free > software ;) Here I see several issues with that: - If it's not shipped by default by the company making the hardware, users will expect to be able to install Guix on it for instance, and the instructions to make it work would require to steer users toward the download, compilation and installation of nonfree software. - If it's on an eMMC, users could accidentally remove it, and they would end up needing to install it again So we'd have the same issue than above. - If it needs to be updated for some reasons, once again we end up with the same issue. - And as usual with workarounds like that it doesn't really fix the issue. We probably need some kind of way to fix that, maybe some sort of collective funding to fund people to work on tasks like that? Here this I'MX8 issue also affect the Librem5 for instance, and probably several other devices as well. And the neat thing about the Librem 5 is that as I understand is that the modem and the WiFi cards are removable. > The i.MX8M has *no* IOMMU Oh, I didn't know that, thanks a lot. References: ----------- [1]https://ryf.fsf.org/ [2]https://ownyourbits.com/2019/02/02/whats-wrong-with-the-raspberry-pi/ [3]https://www.crowdsupply.com/mnt/reform/updates/re-introducing-reform Denis.