Re: Guix on the MNT Reform

[Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>]

[-- Attachment #1: Type: text/plain, Size: 4592 bytes --]

On Tue, 07 Sep 2021 14:18:01 -0400
Christine Lemmer-Webber <cwebber@dustycloud.org> 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.

> <bluerise> the trick is to flash the non-free bootloader into the
> SoM's eMMC <bluerise> 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.

> <bluerise> 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]