unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Christine Lemmer-Webber <cwebber@dustycloud.org>
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Cc: help-guix@gnu.org
Subject: Re: Guix on the MNT Reform
Date: Wed, 08 Sep 2021 06:32:41 -0400	[thread overview]
Message-ID: <87wnnr9wfp.fsf@dustycloud.org> (raw)
In-Reply-To: <20210907220719.538f582a@primarylaptop.localdomain>

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



  reply	other threads:[~2021-09-08 10:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 15:06 Guix on the MNT Reform Christopher Lemmer Webber
2020-05-08 18:19 ` Simon Josefsson
2020-05-09 13:03   ` Christopher Lemmer Webber
2020-05-08 18:30 ` Ekaitz Zarraga
2020-05-08 18:52 ` Vagrant Cascadian
2020-05-08 19:16   ` Leo Famulari
2020-05-08 20:44 ` John Soo
2020-09-02 22:22 ` Andreas Enge
2020-09-13 14:10   ` Andreas Enge
2020-09-15  3:23     ` Fredrik Salomonsson
2021-08-17 17:24 ` Christine Lemmer-Webber
2021-08-17 23:49   ` Fredrik Salomonsson
2021-09-05  1:31     ` Christine Lemmer-Webber
2021-09-06 17:07       ` Christine Lemmer-Webber
2021-09-06 19:37         ` Fredrik Salomonsson
2021-09-06 20:50           ` Christine Lemmer-Webber
2021-09-06 23:59             ` Fredrik Salomonsson
2021-09-07  1:13               ` Fredrik Salomonsson
2021-09-07  4:36       ` Denis 'GNUtoo' Carikli
2021-09-07 18:18         ` Christine Lemmer-Webber
2021-09-07 20:07           ` Denis 'GNUtoo' Carikli
2021-09-08 10:32             ` Christine Lemmer-Webber [this message]
2021-09-08 16:47               ` Vagrant Cascadian
2021-09-08 18:10                 ` Christine Lemmer-Webber
2021-09-09 14:10                 ` Denis 'GNUtoo' Carikli
2021-09-08 18:08               ` Christine Lemmer-Webber
2021-08-18  0:36 ` Jonathan McHugh
2021-08-29 19:10   ` Joshua Branson
2021-08-29 21:38   ` Jonathan McHugh
2021-08-29 23:27     ` Joshua Branson
2021-08-30  9:02     ` Jonathan McHugh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnnr9wfp.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=GNUtoo@cyberdimension.org \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).