Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> writes:

> [[PGP Signed Part:Undecided]]
> 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.

Arguably, nobody is, RYF or not, since we are plagued with nonfree
either "hidden" from users or not.  However, I respect the RYF approach
as an interim solution... I think we need to work on it from multiple
angles, and the line drawn in the sand by RYF is still useful.

However, really long term what we want is a top to bottom FOSS system,
one where we have schematics for really all the components and the
firmware for them, whether exposed to users or not, as well.

At the moment, this feels like a pipe dream, but hackable hardware such
as the Reform at least does advance towards that; as you've already
noted, there are possible paths forward for swapping out this layer in
the Reform.  Thus I think this is a worthwhile direction.  Contrast to
where we've mostly been stuck for much of the last decade and a half of
computers, where it felt like nearly everything new on the market was
sealed off and unavailable for modification to users.

I am glad, btw, that you are looking for something RYF-compatible that
can be slotted into the Reform.  Please keep us updated here with the
results of your work.  (And is there a way we can support you?  For
instance, if purchasing and sending you hardware to experiment with
could help, I am happy to help there.)

Back to some optimism: even though nothing is currently ideal, the
current work on RISC-V boards and the increasing availability of
hardware that feels like it has "community touch" to it makes me hopeful
for the future in a way that I wasn't feeling for most of the last
decade.

> 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, that is disappointing, but also a space for optimism I guess?  I
would be curious to know more about this reverse engineering effort.

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

Yeah.

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

That seems reasonable.

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

Yes I agree with those concerns.

> 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?

I would love to see and support a libre hardware research lab.

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

I am guessing the Pinephone has a similar issue (or more) though I'm not
sure.  Pinephone doesn't have removeable cards, though it does have kill
switches, which is neat.  I guess "removeable" is better if it also
means "replaceable" though.

>> <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.
>
> [[End of PGP Signed Part]]