From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id +Js1NsCWOGEjjQAAgWs5BA (envelope-from ) for ; Wed, 08 Sep 2021 12:56:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id +E1aMsCWOGGIZQAAB5/wlQ (envelope-from ) for ; Wed, 08 Sep 2021 10:56:00 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D4CA3221F3 for ; Wed, 8 Sep 2021 12:55:59 +0200 (CEST) Received: from localhost ([::1]:49814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNvFG-0003fs-Gi for larch@yhetil.org; Wed, 08 Sep 2021 06:55:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNv6I-0001lP-1W for help-guix@gnu.org; Wed, 08 Sep 2021 06:46:42 -0400 Received: from dustycloud.org ([50.116.34.160]:58556) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNv6D-0002we-Sz for help-guix@gnu.org; Wed, 08 Sep 2021 06:46:41 -0400 Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 5DA15266C7; Wed, 8 Sep 2021 06:46:34 -0400 (EDT) References: <87ftcaqxer.fsf@dustycloud.org> <874kbogf1h.fsf@dustycloud.org> <877dgjd441.fsf@d2.com> <87mtordcqq.fsf@dustycloud.org> <20210907063652.697bd4e3@primarylaptop.localdomain> <87h7ewb5mg.fsf@dustycloud.org> <20210907220719.538f582a@primarylaptop.localdomain> User-agent: mu4e 1.6.2; emacs 27.2 From: Christine Lemmer-Webber To: Denis 'GNUtoo' Carikli Subject: Re: Guix on the MNT Reform Date: Wed, 08 Sep 2021 06:32:41 -0400 In-reply-to: <20210907220719.538f582a@primarylaptop.localdomain> Message-ID: <87wnnr9wfp.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=50.116.34.160; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix@gnu.org Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1631098560; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=2C2eokxlmhQGRzLDVOSdVwwtmIh2MALCDi809SReRwo=; b=d2GDNqCMrU8Mm1d2/55sXJQOO8qvDCj4UTtsCTEWOzOJ2IjHU/7rYbqU+QRlhrCK1MFks2 oxuY2wyb5Vkog91KtS/1M+GT2BE/flBdSCp9EZsoslqBuF/cIZKjOgMVtIt4rp5n/ChRYP o5N9sUizTpMRXWc0xukYeYuFkfCN3R4A6qOAVRFJB8Rjbh6h4jOTb2i+uti4ys2gMWemWt Y08rYOJH/GJes1mNQEUbHPMz07xUrfEq4N4S//Jv3q8od06EdCDFnt8FnbLcru6n1yGyYs UuSs9rDk6hTAJHyn/FZ3kpAiXXotaTZqFQQ2ESDGqY75PlxhMar2h6IwRQ9HYg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631098560; a=rsa-sha256; cv=none; b=TAnGLCs/+AZeXP+obsNfaVwNbCUZXFpRyvbrRX4ZLma7Plch+c7DDNyZH963Uo8TzCcWB9 RqH9Sl7CWFhSf4KPIDPzSwYRYrymn4jp/axRotfjgP/Wc2YGOycf2+B9/zm68EjtCdAGHD ik0l0jCPdZtHBtGL6DlkVjnugwwQLDRzagO+lfZDIxPrTtDuy48tofte3QuZT2qX9VGS2v SYWe5OZ1+u58N5k31SEs+U3Y/x+gK/Nei86iz+YqPBX6Gj8a4SB5w5otH8l5tUI28cl3Fp sSBGlnLQv/KdLJC0kzW0x6seFwROGuKZMe9yCDim9v4tEGi1Vz9UbDmf+nkfTw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Migadu-Spam-Score: -2.41 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Migadu-Queue-Id: D4CA3221F3 X-Spam-Score: -2.41 X-Migadu-Scanner: scn1.migadu.com X-TUID: lMcUkQ3NeJ0K Denis 'GNUtoo' Carikli writes: > [[PGP Signed Part:Undecided]] > 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. 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. >> 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. 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. >> 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]]