Re: Guix on the MNT Reform

[Denis 'GNUtoo' Carikli]

On Wed, 08 Sep 2021 09:47:02 -0700
Vagrant Cascadian  wrote:

> On 2021-09-08, Christine Lemmer-Webber wrote:
> > Denis 'GNUtoo' Carikli  writes:
> >> 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.
> 
> The Pinephone doesn't have that specific issue, as it's a different
> CPU (Allwinner A64), the same used on the pine64+ and pinebook, which
> are supported in Guix's u-boot. I vaguely recall those boards having
> similar types of issues early on requiring some binary blobs, but it
> was fixed in u-boot upstream with a free implementation!

WiFi:
-
For any FSDG compliant distribution, the issue with the Pinephone will
be the WiFi: the WiFi driver requires a nonfree firmware.

There might be a way around that though: There are various Realtek
drivers that are released as GPL with the binary firmware as hex arrays
inside the drivers, in files with GPL headers.

And I even managed to find someone at an event (CCC Camp) that did a
little bit of reverse engineering on one of such binary firmwares.

Since we have GPL headers, we should be legally safe here and almost
everything should be permitted, including decompilation, automatic
reconstruction of corresponding source code, etc.

However the firmware architecture (8051) is less well supported by some
of the tools like retdec for instance, but we still have tools
like radare2, or sdcc that support it. And we even probably have several
emulators for that architecture as well.

Modem:
--
There is also another issue that affects several smartphones like the
Librem5, the GTA04 (if I recall well), and the Pinephone, but it's not
directly related to FSDG distributions: the modem is connected through
USB. It also affects some laptops with (potentially builtin) USB modems.

While it's order of magnitude better than most phones that have shared
memory[2], we still need to protect against the modem being potentially
malicious.

To do that we might need to enable usbguard or similar things and
disable usb in u-boot for instance, to be sure that the modem can't
become a keyboard.

On some devices it might be really easy for an attacker to make the
modem become a keyboard as in some cases the modem is really a
smartphone on a chip[3], and so it has some mix of Android and GNU/Linux
running in one of its processor (and probably nonfree modem firmwares /
OS running on the other processors).

So on the GNU/Linux side of the modem you can probably reconfigure the
USB peripheral to also be a keyboard. And it might not be that hard for
attackers to find vulnerabilities in the modem cellular stack and
escalate to the GNU/Linux part of the modem[4].

Once there, the attacker wound't be able to reconfigure the modem as a
keyboard and run commands with 'Alt+F2 + curl  | sh' if
usbguard blocks the USB reconfiguration of the modem.

And while that kind of risk might not affect everybody, I think it
would still be a good idea to address them as sometimes compromise of
smartphones can lead to people being killed by repressive political
regimes[5]. And it would be a bad thing if these people wound't be able
to use free software because of security reasons.

And here GNU/Linux has probably way more potential to achieve that than
Android in the long run due to its architecture and code quality.

References:
---
[1]https://libreplanet.org/wiki/Group:Hardware/research/WiFi/Realtek
[2]https://redmine.replicant.us/projects/replicant/wiki/ModemIsolationResearch
[3]https://osmocom.org/projects/quectel-modems/wiki/Pine64_Pinephone
[4]https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20video%20and%20slides/DEF%20CON%2027%20Conference%20-%20Xiling%20Gong%20-%20Exploiting%20Qualcomm%20WLAN%20and%20Modem%20Over%20The%20Air.mp4
[5]Typically smartphones and computers of dissident living abroad are
   targeted in order to find out who they work with in the repressive
   country in order to kill / torture / imprison these people.

Denis.


pgp3AVky2X0kU.pgp
Description: OpenPGP digital signature

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Vagrant Cascadian  writes:

> [[PGP Signed Part:Undecided]]
> On 2021-09-08, Christine Lemmer-Webber wrote:
>> Denis 'GNUtoo' Carikli  writes:
>>> 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.
>
> The Pinephone doesn't have that specific issue, as it's a different CPU
> (Allwinner A64), the same used on the pine64+ and pinebook, which are
> supported in Guix's u-boot. I vaguely recall those boards having similar
> types of issues early on requiring some binary blobs, but it was fixed
> in u-boot upstream with a free implementation!

Oh good news!  It's nice to hear of success stories like this.

Speaking of, the other "guix system image" thing on my queue was to work
on getting Guix running (if not usable as a phone) on my pinephone.

I tried:

  guix system image --image-type=pine64-raw pine64-barebones.scm

and flashing the output to an SD card, but that didn't boot (or if it
did, it didn't display anything on the screen).  So I assume some extra
work is necessary.

 - Christine

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Christine Lemmer-Webber  writes:

> Denis 'GNUtoo' Carikli  writes:
>
>> Christine Lemmer-Webber  wrote:
>>
>>> 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.

I talked with them a bit today btw.  There hasn't been progress, and the
conversation might have reignited some interest, but it was made clear
that this was not a current focus at the moment.

Re: Guix on the MNT Reform

[Vagrant Cascadian]

On 2021-09-08, Christine Lemmer-Webber wrote:
> Denis 'GNUtoo' Carikli  writes:
>> 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.

The Pinephone doesn't have that specific issue, as it's a different CPU
(Allwinner A64), the same used on the pine64+ and pinebook, which are
supported in Guix's u-boot. I vaguely recall those boards having similar
types of issues early on requiring some binary blobs, but it was fixed
in u-boot upstream with a free implementation!


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

Yeah, one of the many features that pushed me over the edge in
supporting the mnt/reform was all the swappable components; if
reverse-engineering does not happen for one of the few components that
isn't already free, the component liklely can be swapped out for one
with a free implementation. And the inherent upgradability in designing
something with swappable components...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

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 

Re: Guix on the MNT Reform

[Denis 'GNUtoo' Carikli]

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.


pgpVUa54bU3S9.pgp
Description: OpenPGP digital signature

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Denis 'GNUtoo' Carikli  writes:

> [[PGP Signed Part:Undecided]]
> On Sat, 04 Sep 2021 21:31:08 -0400
> Christine Lemmer-Webber  wrote:
>
>> So we probably want to make a u-boot-mnt-reform in
>> gnu/packages/bootloaders.scm
> The issue is that the I.MX8 requires a nonfree firmware for the DDR4
> controller.

Oh really?  And it's not on hardware, needs to be compiled into either
u-boot or the kernel I guess?

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.

Hm, seems confirmed from the #mnt-reform channel on libera:

 hm is this true?
 https://lists.gnu.org/archive/html/help-guix/2021-09/msg00035.html
 do you need a piece of nonfree firmware to get the reform to boot?
 The bootloader contains a training firmware that is supplied to the
   DDR4 controller
 I see
 So yes, there's a blob that is given to the DDR4 controller
 so yes, until that is replaced
 'replaced'?
 looks like we won't be able to get the reform in guix proper then
 since it has a pretty strict libre policy
 but, it could go in a channel I guess

> If you grep for firmware-imx in the u-boot source code you will find
> mentions of it in the READMEs documentation for many I.MX8 boards.

That's too bad.

> So that firmware probably need to be reimplemented as free software
> somehow.

Or:

 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 ;)

Of course, though I think a purely libre policy is quite good, the
criticism remains correct that it's a bit absurd that we tend to relax
once we move it "out of sight, out of mind".  But one can only make so
much progress at once.  Maybe some day we'll have hardware that's truly
free from top to bottom.  I do think the Reform helps advance towards
that goal: at least it makes things very incrementally improvable in
ways that other laptop designs do not.  So I would like to get Guix
working with it... even if we have to outsource our process to a
separate channel until a fully free solution exists.

> Alternatively there are some new system on module (SOM) boards that are
> also compatible with the MNT Reform[1] that might at least boot with
> free software.
>
> I've also started documenting the MNT reform on a Liberplanet wiki
> page[2] but it's really a draft at this point.

Maybe of note for that page:

 'If it's connected through PCI, it could be a security issue as
   IOMMUs tend to be too easy to bypass in practice as they are often
   not well configured by various software components like u-boot,
   Linux and so on.'
 The i.MX8M has *no* IOMMU

> References:
> ---
> [1]https://community.mnt.re/t/ideas-for-processors-for-mnt-reform/237
> [2]https://libreplanet.org/wiki/Group:Hardware/research/laptop/Mnt_Reform
>
> Denis.

Thank you for your hard work on this and many other important things to
improve our computing freedom situations, Denis!

> [[End of PGP Signed Part]]

Re: Guix on the MNT Reform

[Denis 'GNUtoo' Carikli]

On Sat, 04 Sep 2021 21:31:08 -0400
Christine Lemmer-Webber  wrote:

> So we probably want to make a u-boot-mnt-reform in
> gnu/packages/bootloaders.scm
The issue is that the I.MX8 requires a nonfree firmware for the DDR4
controller.

If you grep for firmware-imx in the u-boot source code you will find
mentions of it in the READMEs documentation for many I.MX8 boards.

So that firmware probably need to be reimplemented as free software
somehow.

Alternatively there are some new system on module (SOM) boards that are
also compatible with the MNT Reform[1] that might at least boot with
free software.

I've also started documenting the MNT reform on a Liberplanet wiki
page[2] but it's really a draft at this point.

References:
---
[1]https://community.mnt.re/t/ideas-for-processors-for-mnt-reform/237
[2]https://libreplanet.org/wiki/Group:Hardware/research/laptop/Mnt_Reform

Denis.


pgpGDP0Cq8rZP.pgp
Description: OpenPGP digital signature

Re: Guix on the MNT Reform

[Fredrik Salomonsson]

Fredrik Salomonsson  writes:

> I'm building the image with:
> #+begin_src shell
> guix environment guix
> ./pre-inst-env guix system image --image-type=mnt-reform2-raw  config.scm
> #+end_src
>
> I tried with the =linux-libre-arm64-generic= first but that couldn't
> find the =sdhci-esdhc-imx= module. And now when I'm testing with just
> the linux-libre kernel I'm running out of space on my =/tmp=. Is there
> an easy way of telling the guix-daemon to use another path for building?
> Or do I need to restart it and change its =TMPDIR=?

Just to follow up, I got a bit further by changing the =TMPDIR= to a
directory in my home directory. I'm using guix on a foreign distro so I
just did a quick edit on the systemd service file:

#+begin_src shell
mkdir /home/plattfot/scratch
sudo systemctl stop guix-daemon.service
sudo systemctl edit guix-daemon.service
#+end_src

#+begin_src conf
[Service]
Environment=TMPDIR=/home/plattfot/scratch
#+end_src

#+begin_src shell
sudo systemctl start guix-daemon.service
#+end_src

It now fails when building the info-dir

#+begin_src shell
building directory of Info manuals...
builder for `/gnu/store/qv4mh2hvryj33qyi0cw4nzbgy1l17xv6-info-dir.drv' failed 
with exit code 1
build of /gnu/store/qv4mh2hvryj33qyi0cw4nzbgy1l17xv6-info-dir.drv failed
View build log at 
'/var/log/guix/drvs/qv/4mh2hvryj33qyi0cw4nzbgy1l17xv6-info-dir.drv.bz2'.
cannot build derivation 
`/gnu/store/g1lqn7h5baxq8grv2k2kjrjdvkpxlzn7-profile.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/wybzgz18szsrnk5rayyxgh3hvsqrg6mg-system.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/kp5086frygpvfmlyb2wa78shgciwvd4p-partition.img.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/3g9fqz36rw1pqzdh35ds3vnpgidqk40y-genimage.cfg.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/gazkm0vdj2i6iw7i0r8d1hlr02aqglpm-disk-image.drv': 1 dependencies 
couldn't be built
guix system: error: build of 
`/gnu/store/gazkm0vdj2i6iw7i0r8d1hlr02aqglpm-disk-image.drv' failed
#+end_src

The build log is empty, so I'm not sure what went wrong.

Sadly that's all the time I have for this today. I'll see if I can find
some time during the rest of week, otherwise I'll continue on the
weekend.

NOTE: to undo the changes on the service file you can simply run:
#+begin_src shell
sudo systemctl revert guix-daemon.service
#+end_src

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Guix on the MNT Reform

[Fredrik Salomonsson]

Christine Lemmer-Webber  writes:

> Ooh!  This is a great email.  Thank you for your help.

Not sure how much of a help I am :).

> That seems right.  I don't understand the config system that's here to
> know what to do.
>
> I noticed that the source/README directory says the following:
>
> #+BEGIN_QUOTE
> - CONFIG_SYS_MALLOC_SIMPLE
>   Provides a simple and small malloc() and calloc() for those
>   boards which do not use the full malloc in SPL (which is
>   enabled with CONFIG_SYS_SPL_MALLOC_START).
> #+END_QUOTE
>
> Now note that by following their custom instructions, I had set a rule
> in the package definition above to copy =mntreform-config= to =.config=
>
> But I also just noticed something strange.
>
> The build directory is:
>
>   /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0/source
>
> yet the error appears as:
>
>   
> /gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/malloc.h
>
> I don't know how common this is, but this surprised me to see that it
> was pointing at something from the checkout rather than in the build
> directory.
>
> So, I changed where the copy config step was and put it in the source
> section.  Then, since the config step incorrectly identified this as not
> being a valid board (we're really doing the config step manually) I
> deleted it:
>
> #+BEGIN_SRC scheme
> (define-public u-boot-mnt-reform2
>   (let ((base (make-u-boot-package "mnt-reform2" "aarch64-linux-gnu"))
> (commit "bdcdce7434b9db19aabd59181014f24d66af0db8"))
> (package
>   (inherit base)
>   (version "2021.06")
>   (name "u-boot-mnt-reform2")
>   (source (origin
> (method git-fetch)
> (uri (git-reference
>   (url 
> "https://source.mnt.re/reform/reform-boundary-uboot.git;)
>   (commit commit)))
> (file-name (git-file-name name version))
> (sha256
>  (base32
>   "1pwmcaaxx5zvn26gznwz4rjki4w3wwfzdnipxfr7d8067fmwgjp3"))
> (snippet
>  '(copy-file "mntreform-config" ".config"
>   (arguments
> (substitute-keyword-arguments (package-arguments base)
>   ((#:phases phases)
>`(modify-phases ,phases
>   (delete 'configure
> #+END_SRC
>
> Now things compile!

Nice find! I didn't notice the include coming from the checkout
directory so I was comparing the build output from running the

#+begin_src sh
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm make -j$(nproc)
#+end_src

in the =https://source.mnt.re/reform/reform-boundary-uboot.git= repo to
the output I got from guix build.

> Now note that it looks like we need to do two steps, so this probably is
> not complete.  From the mkuboot.sh mentioned previously:
>
> #+BEGIN_SRC sh
> # build rescue u-boot first (loads kernel from eMMC)
> make -j$(nproc) flash.bin KCPPFLAGS='-DMNTREFORM_BOOT_EMMC'
> cp flash.bin flash-rescue.bin
>
> # build normal u-boot second (loads kernel from SD card)
> make -j$(nproc) flash.bin
> #+END_SRC
>
> So maybe we need to incorporate that before using this.

I'm not sure we need both to get this working. As if you look in the
=mkimage.sh= script it actually creates two images. One for the eMMC and
one for the SD card. To just get this booting using the SD card, what we
have should be enough. I'm currently trying to create an image from it
but hitting some build issues. This is what I have right now:

#+begin_src diff
diff --git a/gnu/bootloader/u-boot.scm b/gnu/bootloader/u-boot.scm
index 6cad33b741..7d3f07e8ab 100644
--- a/gnu/bootloader/u-boot.scm
+++ b/gnu/bootloader/u-boot.scm
@@ -34,6 +34,7 @@
 u-boot-firefly-rk3399-bootloader
 u-boot-mx6cuboxi-bootloader
 u-boot-nintendo-nes-classic-edition-bootloader
+u-boot-mnt-reform2-bootloader
 u-boot-novena-bootloader
 u-boot-pine64-plus-bootloader
 u-boot-pine64-lts-bootloader
@@ -209,6 +210,11 @@
(inherit u-boot-imx-bootloader)
(package u-boot-wandboard)))
 
+(define u-boot-mnt-reform2-bootloader
+  (bootloader
+(inherit u-boot-imx-bootloader)
+(package u-boot-mnt-reform2)))
+
 (define u-boot-novena-bootloader
   (bootloader
(inherit u-boot-imx-bootloader)
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 5f7dfa0f8f..c365adc93a 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -980,6 +980,30 @@ to Novena upstream, does not load u-boot.img from the 
first partition.")
`(("firmware" ,arm-trusted-firmware-rk3399)
  ,@(package-native-inputs base))
 
+(define-public u-boot-mnt-reform2
+  (let ((base (make-u-boot-package "mnt-reform2" "aarch64-linux-gnu"))
+(commit "bdcdce7434b9db19aabd59181014f24d66af0db8"))
+(package
+  (inherit base)
+  (version "2021.06")
+  (name 

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Fredrik Salomonsson  writes:

> Christine Lemmer-Webber  writes:
>
>>> Cool!  Hope it gets up and running soon.
>
> Thanks, I got it running somewhat. My batteries are still a bit messed
> up after I accidentally let it drain them too low. I ordered a battery
> charger so hopefully I can get them in great shape again.

Ooh!  This is a great email.  Thank you for your help.

>>> In the meanwhile, some local notes...
>>>
>>> It looks like the relevant info to get going is here:
>>>
>>>   https://mntre.com/reform2/handbook/advanced.html#system-boot
>>>
>>> There's a script to compile a custom u-boot:
>>>
>>>   
>>> https://source.mnt.re/reform/reform-system-image/-/blob/main/reform2-imx8mq/mkuboot.sh
>>>
>>> #+BEGIN_SRC bash
>>> if [ ! -d u-boot ]
>>> then
>>>   echo "Cloning U-Boot..."
>>>   git clone --depth 1 
>>> https://source.mnt.re/reform/reform-boundary-uboot.git u-boot
>>> fi
>>>
>>> cd u-boot
>>> cp mntreform-config .config
>>>
>>> export CROSS_COMPILE=aarch64-linux-gnu-
>>> export ARCH=arm
>>>
>>> # build rescue u-boot first (loads kernel from eMMC)
>>> make -j$(nproc) flash.bin KCPPFLAGS='-DMNTREFORM_BOOT_EMMC'
>>> cp flash.bin flash-rescue.bin
>>>
>>> # build normal u-boot second (loads kernel from SD card)
>>> make -j$(nproc) flash.bin
>>>
>>> cd ..
>>> #+END_SRC
>>>
>>> So that doesn't look to complicated.
>>>
>>> Here's the custom u-boot:
>>>
>>>   https://source.mnt.re/reform/reform-boundary-uboot
>>>
>>> It says:
>>>
>>>   "Fork of the vendor (Boundary Devices) u-boot for Reform 2, with
>>>   minor tweaks. The goal is to migrate to mainstream u-boot or barebox
>>>   ASAP. The main impediment so far is the 4GB RAM config."
>>>
>>> So we probably want to make a u-boot-mnt-reform in
>>> gnu/packages/bootloaders.scm
>>>
>>> So we probably want to use "guix system image" and then add:
>>>
>>>   gnu/system/images/mnt-reform.scm
>>>
>>> Ideally in the end we should be able to do:
>>>
>>>   guix system image --image-type=mnt-reform my-os.scm
>>>
>>> So yeah, the rest of the pieces to figuring it out seem to be all here:
>>>
>>>   https://mntre.com/reform2/handbook/advanced.html#system-boot
>>>
>>> It *seems* like this should all be possible...
>>>
>>>  - Christine
>
> Thanks for the notes! I've just been poking around in the guix source
> code to get a grasp how it works plus reading the Guix on an ARM Board
> by Julien Lepiller [0]
>
> [0] https://guix.gnu.org/blog/2019/guix-on-an-arm-board/
>
>>
>> Here's the progress I've made so far:
>>
>> #+BEGIN_SRC diff
>> diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
>> index 2889a90d54..17a7abc657 100644
>> --- a/gnu/packages/bootloaders.scm
>> +++ b/gnu/packages/bootloaders.scm
>> @@ -953,6 +953,38 @@ to Novena upstream, does not load u-boot.img from the 
>> first partition.")
>> `(("firmware" ,arm-trusted-firmware-rk3399)
>>   ,@(package-native-inputs base))
>>  
>> +(define-public u-boot-mnt-reform2
>> +  (let ((base (make-u-boot-package "mnt-reform2" "aarch64-linux-gnu"))
>> +(commit "bdcdce7434b9db19aabd59181014f24d66af0db8"))
>> +(package
>> +  (inherit base)
>> +  (version "2021.06")
>> +  (name "u-boot-mnt-reform2")
>> +  (source (origin
>> +(method git-fetch)
>> +(uri (git-reference
>> +  (url 
>> "https://source.mnt.re/reform/reform-boundary-uboot.git;)
>> +  (commit commit)))
>> +(file-name (git-file-name name version))
>> +(sha256
>> + (base32
>> +  "1pwmcaaxx5zvn26gznwz4rjki4w3wwfzdnipxfr7d8067fmwgjp3"
>> +  (arguments
>> +(substitute-keyword-arguments (package-arguments base)
>> +  ((#:phases phases)
>> +   `(modify-phases ,phases
>> +  (replace 'configure
>> +(lambda _
>> +  (copy-file "mntreform-config" ".config")))
>> +  
>> +  ;; Phases do not succeed on the bl31 ELF.
>> +  #;(delete 'strip)
>> +  #;(delete 'validate-runpath)
>> +  #;(native-inputs
>> +   `(("firmware" ,arm-trusted-firmware-rk3399)
>> + ,@(package-native-inputs base
>> +))
>> +
>>  (define-public vboot-utils
>>(package
>>  (name "vboot-utils")
>> #+END_SRC
>>
>> However, I hit this error when trying to compile:
>>
>> #+BEGIN_VERBATIM
>> starting phase `build'
>>   HOSTCC  scripts/basic/fixdep
>> In file included from 
>> /gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdlib.h:9:0,
>>  from scripts/basic/fixdep.c:112:
>> /gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/malloc.h:875:22:
>>  error: missing binary operator before token "("
>>  #if CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE)
>>   ^
>> In file included from scripts/basic/fixdep.c:113:0:
>> 

Re: Guix on the MNT Reform

[Fredrik Salomonsson]

Christine Lemmer-Webber  writes:

>> Cool!  Hope it gets up and running soon.

Thanks, I got it running somewhat. My batteries are still a bit messed
up after I accidentally let it drain them too low. I ordered a battery
charger so hopefully I can get them in great shape again.

>> In the meanwhile, some local notes...
>>
>> It looks like the relevant info to get going is here:
>>
>>   https://mntre.com/reform2/handbook/advanced.html#system-boot
>>
>> There's a script to compile a custom u-boot:
>>
>>   
>> https://source.mnt.re/reform/reform-system-image/-/blob/main/reform2-imx8mq/mkuboot.sh
>>
>> #+BEGIN_SRC bash
>> if [ ! -d u-boot ]
>> then
>>   echo "Cloning U-Boot..."
>>   git clone --depth 1 https://source.mnt.re/reform/reform-boundary-uboot.git 
>> u-boot
>> fi
>>
>> cd u-boot
>> cp mntreform-config .config
>>
>> export CROSS_COMPILE=aarch64-linux-gnu-
>> export ARCH=arm
>>
>> # build rescue u-boot first (loads kernel from eMMC)
>> make -j$(nproc) flash.bin KCPPFLAGS='-DMNTREFORM_BOOT_EMMC'
>> cp flash.bin flash-rescue.bin
>>
>> # build normal u-boot second (loads kernel from SD card)
>> make -j$(nproc) flash.bin
>>
>> cd ..
>> #+END_SRC
>>
>> So that doesn't look to complicated.
>>
>> Here's the custom u-boot:
>>
>>   https://source.mnt.re/reform/reform-boundary-uboot
>>
>> It says:
>>
>>   "Fork of the vendor (Boundary Devices) u-boot for Reform 2, with
>>   minor tweaks. The goal is to migrate to mainstream u-boot or barebox
>>   ASAP. The main impediment so far is the 4GB RAM config."
>>
>> So we probably want to make a u-boot-mnt-reform in
>> gnu/packages/bootloaders.scm
>>
>> So we probably want to use "guix system image" and then add:
>>
>>   gnu/system/images/mnt-reform.scm
>>
>> Ideally in the end we should be able to do:
>>
>>   guix system image --image-type=mnt-reform my-os.scm
>>
>> So yeah, the rest of the pieces to figuring it out seem to be all here:
>>
>>   https://mntre.com/reform2/handbook/advanced.html#system-boot
>>
>> It *seems* like this should all be possible...
>>
>>  - Christine

Thanks for the notes! I've just been poking around in the guix source
code to get a grasp how it works plus reading the Guix on an ARM Board
by Julien Lepiller [0]

[0] https://guix.gnu.org/blog/2019/guix-on-an-arm-board/

>
> Here's the progress I've made so far:
>
> #+BEGIN_SRC diff
> diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
> index 2889a90d54..17a7abc657 100644
> --- a/gnu/packages/bootloaders.scm
> +++ b/gnu/packages/bootloaders.scm
> @@ -953,6 +953,38 @@ to Novena upstream, does not load u-boot.img from the 
> first partition.")
> `(("firmware" ,arm-trusted-firmware-rk3399)
>   ,@(package-native-inputs base))
>  
> +(define-public u-boot-mnt-reform2
> +  (let ((base (make-u-boot-package "mnt-reform2" "aarch64-linux-gnu"))
> +(commit "bdcdce7434b9db19aabd59181014f24d66af0db8"))
> +(package
> +  (inherit base)
> +  (version "2021.06")
> +  (name "u-boot-mnt-reform2")
> +  (source (origin
> +(method git-fetch)
> +(uri (git-reference
> +  (url 
> "https://source.mnt.re/reform/reform-boundary-uboot.git;)
> +  (commit commit)))
> +(file-name (git-file-name name version))
> +(sha256
> + (base32
> +  "1pwmcaaxx5zvn26gznwz4rjki4w3wwfzdnipxfr7d8067fmwgjp3"
> +  (arguments
> +(substitute-keyword-arguments (package-arguments base)
> +  ((#:phases phases)
> +   `(modify-phases ,phases
> +  (replace 'configure
> +(lambda _
> +  (copy-file "mntreform-config" ".config")))
> +  
> +  ;; Phases do not succeed on the bl31 ELF.
> +  #;(delete 'strip)
> +  #;(delete 'validate-runpath)
> +  #;(native-inputs
> +   `(("firmware" ,arm-trusted-firmware-rk3399)
> + ,@(package-native-inputs base
> +))
> +
>  (define-public vboot-utils
>(package
>  (name "vboot-utils")
> #+END_SRC
>
> However, I hit this error when trying to compile:
>
> #+BEGIN_VERBATIM
> starting phase `build'
>   HOSTCC  scripts/basic/fixdep
> In file included from 
> /gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdlib.h:9:0,
>  from scripts/basic/fixdep.c:112:
> /gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/malloc.h:875:22:
>  error: missing binary operator before token "("
>  #if CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE)
>   ^
> In file included from scripts/basic/fixdep.c:113:0:
> /gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdio.h:18:14:
>  error: expected declaration specifiers or '...' before numeric constant
>  int __printf(1, 2) printf(const char *fmt, ...);
>   ^
> 

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Christine Lemmer-Webber  writes:

> Cool!  Hope it gets up and running soon.  In the meanwhile, some local
> notes...
>
> It looks like the relevant info to get going is here:
>
>   https://mntre.com/reform2/handbook/advanced.html#system-boot
>
> There's a script to compile a custom u-boot:
>
>   
> https://source.mnt.re/reform/reform-system-image/-/blob/main/reform2-imx8mq/mkuboot.sh
>
> #+BEGIN_SRC bash
> if [ ! -d u-boot ]
> then
>   echo "Cloning U-Boot..."
>   git clone --depth 1 https://source.mnt.re/reform/reform-boundary-uboot.git 
> u-boot
> fi
>
> cd u-boot
> cp mntreform-config .config
>
> export CROSS_COMPILE=aarch64-linux-gnu-
> export ARCH=arm
>
> # build rescue u-boot first (loads kernel from eMMC)
> make -j$(nproc) flash.bin KCPPFLAGS='-DMNTREFORM_BOOT_EMMC'
> cp flash.bin flash-rescue.bin
>
> # build normal u-boot second (loads kernel from SD card)
> make -j$(nproc) flash.bin
>
> cd ..
> #+END_SRC
>
> So that doesn't look to complicated.
>
> Here's the custom u-boot:
>
>   https://source.mnt.re/reform/reform-boundary-uboot
>
> It says:
>
>   "Fork of the vendor (Boundary Devices) u-boot for Reform 2, with
>   minor tweaks. The goal is to migrate to mainstream u-boot or barebox
>   ASAP. The main impediment so far is the 4GB RAM config."
>
> So we probably want to make a u-boot-mnt-reform in
> gnu/packages/bootloaders.scm
>
> So we probably want to use "guix system image" and then add:
>
>   gnu/system/images/mnt-reform.scm
>
> Ideally in the end we should be able to do:
>
>   guix system image --image-type=mnt-reform my-os.scm
>
> So yeah, the rest of the pieces to figuring it out seem to be all here:
>
>   https://mntre.com/reform2/handbook/advanced.html#system-boot
>
> It *seems* like this should all be possible...
>
>  - Christine

Here's the progress I've made so far:

#+BEGIN_SRC diff
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 2889a90d54..17a7abc657 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -953,6 +953,38 @@ to Novena upstream, does not load u-boot.img from the 
first partition.")
`(("firmware" ,arm-trusted-firmware-rk3399)
  ,@(package-native-inputs base))
 
+(define-public u-boot-mnt-reform2
+  (let ((base (make-u-boot-package "mnt-reform2" "aarch64-linux-gnu"))
+(commit "bdcdce7434b9db19aabd59181014f24d66af0db8"))
+(package
+  (inherit base)
+  (version "2021.06")
+  (name "u-boot-mnt-reform2")
+  (source (origin
+(method git-fetch)
+(uri (git-reference
+  (url 
"https://source.mnt.re/reform/reform-boundary-uboot.git;)
+  (commit commit)))
+(file-name (git-file-name name version))
+(sha256
+ (base32
+  "1pwmcaaxx5zvn26gznwz4rjki4w3wwfzdnipxfr7d8067fmwgjp3"
+  (arguments
+(substitute-keyword-arguments (package-arguments base)
+  ((#:phases phases)
+   `(modify-phases ,phases
+  (replace 'configure
+(lambda _
+  (copy-file "mntreform-config" ".config")))
+  
+  ;; Phases do not succeed on the bl31 ELF.
+  #;(delete 'strip)
+  #;(delete 'validate-runpath)
+  #;(native-inputs
+   `(("firmware" ,arm-trusted-firmware-rk3399)
+ ,@(package-native-inputs base
+))
+
 (define-public vboot-utils
   (package
 (name "vboot-utils")
#+END_SRC

However, I hit this error when trying to compile:

#+BEGIN_VERBATIM
starting phase `build'
  HOSTCC  scripts/basic/fixdep
In file included from 
/gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdlib.h:9:0,
 from scripts/basic/fixdep.c:112:
/gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/malloc.h:875:22:
 error: missing binary operator before token "("
 #if CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE)
  ^
In file included from scripts/basic/fixdep.c:113:0:
/gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdio.h:18:14:
 error: expected declaration specifiers or '...' before numeric constant
 int __printf(1, 2) printf(const char *fmt, ...);
  ^
/gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdio.h:18:17:
 error: expected declaration specifiers or '...' before numeric constant
 int __printf(1, 2) printf(const char *fmt, ...);
 ^
/gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdio.h:53:14:
 error: expected declaration specifiers or '...' before numeric constant
 int __printf(2, 3) fprintf(int file, const char *fmt, ...);
  ^
/gnu/store/dj05znzsk7fq43zj5r719ll8ldgh9xxi-u-boot-mnt-reform2-2021.06-checkout/include/stdio.h:53:17:
 error: expected declaration specifiers or '...' before numeric 

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Fredrik Salomonsson  writes:

> Christine Lemmer-Webber  writes:
>
>> Hi!  Well my MNT Reform arrived.  I'd like to start putting Guix on it
>> but I'm kind of low on time right now...
>
> I got mine last week!

Neat!

>> I wonder if anyone else has started making progress towards this?
>
>> What I'd love: a tutorial that says "here are the steps to make an sd
>> card you can boot your reform with"!
>
> I'm planning to start hacking on that once I've found a NVMe that works.
> The XPG SX8200 Pro 1TB I bought for it had serious issues with access
> times. Next up is to buy a WD Blue SN550 1TB and hopefully that will
> work.

Cool!  Hope it gets up and running soon.  In the meanwhile, some local
notes...

It looks like the relevant info to get going is here:

  https://mntre.com/reform2/handbook/advanced.html#system-boot

There's a script to compile a custom u-boot:

  
https://source.mnt.re/reform/reform-system-image/-/blob/main/reform2-imx8mq/mkuboot.sh

#+BEGIN_SRC bash
if [ ! -d u-boot ]
then
  echo "Cloning U-Boot..."
  git clone --depth 1 https://source.mnt.re/reform/reform-boundary-uboot.git 
u-boot
fi

cd u-boot
cp mntreform-config .config

export CROSS_COMPILE=aarch64-linux-gnu-
export ARCH=arm

# build rescue u-boot first (loads kernel from eMMC)
make -j$(nproc) flash.bin KCPPFLAGS='-DMNTREFORM_BOOT_EMMC'
cp flash.bin flash-rescue.bin

# build normal u-boot second (loads kernel from SD card)
make -j$(nproc) flash.bin

cd ..
#+END_SRC

So that doesn't look to complicated.

Here's the custom u-boot:

  https://source.mnt.re/reform/reform-boundary-uboot

It says:

  "Fork of the vendor (Boundary Devices) u-boot for Reform 2, with
  minor tweaks. The goal is to migrate to mainstream u-boot or barebox
  ASAP. The main impediment so far is the 4GB RAM config."

So we probably want to make a u-boot-mnt-reform in
gnu/packages/bootloaders.scm

So we probably want to use "guix system image" and then add:

  gnu/system/images/mnt-reform.scm

Ideally in the end we should be able to do:

  guix system image --image-type=mnt-reform my-os.scm

So yeah, the rest of the pieces to figuring it out seem to be all here:

  https://mntre.com/reform2/handbook/advanced.html#system-boot

It *seems* like this should all be possible...

 - Christine

Re: Guix on the MNT Reform

[Jonathan McHugh]

Hi Joshua,

That is excellent news. 

I will send you a private mail, as I now have a greater (indirect) interest in 
git repos being rapidly deployable - think TildeGit
=> https://tildegit.org/

OpenBSD Amsterdam has raised €14,395 for the OpenBSD Foundation through their 
VPS services (10 EUR VPS/PA 15 EUR VPS/renewal)
=> https://openbsd.amsterdam

I had a very positive experience with Mischa, who oversees that service.
=> https://mischapeters.com/

A OpenBSD friend has a high opinion of the implementation, mentioning that 
practical concerns mean that some facets are upstream of that OS. He should be 
approachable should you have any points of concern for your project. Who knows, 
maybe you can even do some cross selling for your respective services)

As for me, I try to avoid actively consuming services operative within privacy 
repealing legislative domains (such a pity). However, you can still count me in 
for a small donation (woo, money for nowt!), certainly in reciprocation for 
this:
=> https://gnucode.me/make-money-contributing-to-gnu.html

I will first consider your server offer for a donation for my local 
hackerspace, HSBXL - though I dont know if the shipping fees (and custom 
charges) would counter the generosity. Focus may preclude me maintaining any 
pooled infrastructure there (I prefer banjaxing my setups instead), though I am 
negotiating greater input on forge management. Im the only Guix user at that 
coterie, so the hypervisor's governance would likely remain heterogenous (in 
lieu of its membership).

Nethertheless, your ambition does need replicating at an EEA level, Id like to 
be able to provide peripheral input (from 2022 at least). I may stalk Neutrinet 
meetups for stimulus and ideas.
=> https://neutrinet.be/

I look forward to viewing the interview (I used to interview musicians in a 
previous life, I miss the practice)
=> https://video.hardlimit.com/videos/watch/da57d61c-b2e9-473c-9ed0-9390bf610f67

I shall pass on the gossip concerning Libre-Soc's positive growth (Im heartened 
to read that NLNet have seeded them)
=> https://libre-soc.org




Jonathan McHugh
indieterminacy@libre.brussels

August 30, 2021 1:28 AM, "Joshua Branson"  wrote:

> "Jonathan McHugh"  writes:
> 
>> Hi Joshua,
>> 
>> It does appear from the website that 4GB is the peak. It would be nice
>> to take advantage of the open schematics and replace enough hardware
>> to overcome this but that would be wasteful indulgence.
>> 
>> Personally, I probably should prioritise a solid desktop/server to
>> handle more onerous chores (such as buildfarming and compiling). And
>> also a superb external keyboard... and then wait until the wheels fall
>> off one of my laptops machines.
> 
> I'm down for that! I'm actually hoping to crowdfund/purchase a Raptor
> server. There's a local ISP in town here. Most of the businesses use
> it. I could approach them and ask how much it would cost to host a
> server at their property. Then it's just a matter of convincing people
> to help me raise $9,000. Something like, let's get a Guix Power9 build
> server that guix people can hack on. If you give $10, you get a
> guix.gnu.org/~username webpage/gemini webpage for a year. If you donate
> $20, you get the previous perks plus an email account and so on. Would
> you like to help me work on this?
> 
>> Im still jealous of your 32GB Ram server, if you have enough ICT
>> signal you may as well switch to a leaner laptop which interacts with
>> your mothership.
> 
> That 32GB RAM server is for sale! For $200 I can sell it to you for
> 16GB of RAM. For $300 I can sell it for 16GB of RAM. If you live in
> the U.S., shipping would be pretty easy.
> 
>> FYI, Im getting increasing satisfaction from Gemini - so my RAM needs should 
>> be shrinking
>> considerably.
>> 
>> Also, because of the Guix Linode cookbook (thanks guys!) I even got around 
>> to pushing out a Gemini
>> capsule.
>> =>
>> https://guix.gnu.org/en/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html#Running-Guix-on-a
>> Linode-Server
> 
> Haha. Chris Lemmer-Webber wrote the guide. I just put it in the
> cookbook. :)
> 
>> Im really pleased that Guix is getting a grip on how to manage open hardware 
>> and more FOSS centric
>> infrastructure.
>> 
>> Thanks for the pointer re Luke Leighton, i hope to investigate that
>> down the road. Also, curious about the intersection between the MNT
>> Reform team and Amiga hardware (extensions?).
> 
> I interview him a week or two ago? He's got some really ambitious
> plans for it. He's also hiring for hardware/software developers.
> 
> https://video.hardlimit.com/videos/watch/da57d61c-b2e9-473c-9ed0-9390bf610f67
> 
> (The video is also available on the non-free platform. You know which
> one). :)
> 
> https://libre-soc.org
> 
>> Kind regards,
>> 
>> Jonathan
>> 
>> August 29, 2021 9:10 PM, "Joshua Branson"  wrote:
>> 
>>> "Jonathan McHugh"  writes:
>> 
>> I hope you are enjoying the mechanical keyboard, it 

Re: Guix on the MNT Reform

[Jonathan McHugh]

Hi Joshua,

The promise of a good laptop keyboard is making me reminisent of my old Sony 
VAIO GRV680 (still stored away for refashioning one day Admittedly it was 
more of a desktop replacement laptop than a lean setup.).

It does appear from the website that 4GB is the peak. It would be nice to take 
advantage of the open schematics and replace enough hardware to overcome this 
but that would be wasteful indulgence.

Personally, I probably should prioritise a solid desktop/server to handle more 
onerous chores (such as buildfarming and compiling). And also a superb external 
keyboard... and then wait until the wheels fall off one of my laptops machines.

Im still jealous of your 32GB Ram server, if you have enough ICT signal you may 
as well switch to a leaner laptop which interacts with your mothership.

FYI, Im getting increasing satisfaction from Gemini - so my RAM needs should be 
shrinking considerably. 

Also, because of the Guix Linode cookbook (thanks guys!) I even got around to 
pushing out a Gemini capsule.
=> 
https://guix.gnu.org/en/cookbook/en/html_node/Running-Guix-on-a-Linode-Server.html#Running-Guix-on-a-Linode-Server

Im really pleased that Guix is getting a grip on how to manage open hardware 
and more FOSS centric infrastructure.

Thanks for the pointer re Luke Leighton, i hope to investigate that down the 
road. Also, curious about the intersection between the MNT Reform team and 
Amiga hardware (extensions?).


Kind regards,


Jonathan


August 29, 2021 9:10 PM, "Joshua Branson"  wrote:

> "Jonathan McHugh"  writes:
> 
>> I hope you are enjoying the mechanical keyboard, it seems great!
> 
> The MNT reform does seem like my dream laptop. I do want a mechanical
> keyboard. What's the max RAM on the reform? I thought it was 4GB?
> Sounds pretty low...
> 
> Though I do like what Luke Leighton is doing with the power SOC/GPU.
> 
>> 
>> Jonathan McHugh
>> indieterminacy@libre.brussels
>> 
>> August 17, 2021 7:24 PM, "Christine Lemmer-Webber"  
>> wrote:
>> 
>>> Hi! Well my MNT Reform arrived. I'd like to start putting Guix on it
>>> but I'm kind of low on time right now...
>>> 
>>> I wonder if anyone else has started making progress towards this?
>>> 
>>> What I'd love: a tutorial that says "here are the steps to make an sd
>>> card you can boot your reform with"!
>>> 
>>> Christopher Lemmer Webber writes:
>> 
>> I'm very excited to see the MNT Reform launch:
>> 
>> https://www.crowdsupply.com/mnt/reform
>> https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>> 
>> Completely hackable laptop; all the designs (that are possible) are
>> libre, and you can even 3d print to replace many of the parts.
> 
> --
> Joshua Branson (jab in #guix)
> Sent from Emacs and Gnus
> https://gnucode.me
> https://video.hardlimit.com/accounts/joshua_branson/video-channels
> https://propernaming.org
> "You can have whatever you want, as long as you help
> enough other people get what they want." - Zig Ziglar

Re: Guix on the MNT Reform

[Joshua Branson]

"Jonathan McHugh"  writes:

> I hope you are enjoying the mechanical keyboard, it seems great!
>

The MNT reform does seem like my dream laptop.  I do want a mechanical
keyboard.  What's the max RAM on the reform?  I thought it was 4GB?
Sounds pretty low...

Though I do like what Luke Leighton is doing with the power SOC/GPU.

> 
> Jonathan McHugh
> indieterminacy@libre.brussels
>
> August 17, 2021 7:24 PM, "Christine Lemmer-Webber"  
> wrote:
>
>> Hi! Well my MNT Reform arrived. I'd like to start putting Guix on it
>> but I'm kind of low on time right now...
>>
>> I wonder if anyone else has started making progress towards this?
>>
>> What I'd love: a tutorial that says "here are the steps to make an sd
>> card you can boot your reform with"!
>>
>> Christopher Lemmer Webber writes:
>>
>>> I'm very excited to see the MNT Reform launch:
>>>
>>> https://www.crowdsupply.com/mnt/reform
>>> https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>>>
>>> Completely hackable laptop; all the designs (that are possible) are
>>> libre, and you can even 3d print to replace many of the parts.
>>>
>

--
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Guix on the MNT Reform

[Jonathan McHugh]

I hope you are enjoying the mechanical keyboard, it seems great!


Jonathan McHugh
indieterminacy@libre.brussels

August 17, 2021 7:24 PM, "Christine Lemmer-Webber"  
wrote:

> Hi! Well my MNT Reform arrived. I'd like to start putting Guix on it
> but I'm kind of low on time right now...
> 
> I wonder if anyone else has started making progress towards this?
> 
> What I'd love: a tutorial that says "here are the steps to make an sd
> card you can boot your reform with"!
> 
> Christopher Lemmer Webber writes:
> 
>> I'm very excited to see the MNT Reform launch:
>> 
>> https://www.crowdsupply.com/mnt/reform
>> https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>> 
>> Completely hackable laptop; all the designs (that are possible) are
>> libre, and you can even 3d print to replace many of the parts.
>> 
>> However my impression is that running Guix on ARM is not necessarily
>> straightforward. I haven't tried it yet.
>> 
>> Most important specs:
>> 
>> CPU: NXP/Freescale i.MX8MQ with 4x ARM Cortex-A53 cores (1.5 GHz),
>> 1x Cortex-M4F core. CPU and RAM are on exchangeable SO-DIMM sized
>> module.
>> RAM: 4GB LPDDR4 memory
>> GPU: Vivante GC7000Lite GPU with mainline Linux drivers and OpenGL
>> 2.1, ES 2.0
>> 
>> (My other main worry is: that's pretty light on RAM these days...!
>> But hey, maybe incentive for me to cut the fat in the programs I use a
>> bit more...)
>> 
>> I am thinking of getting one and running Guix on it. It would be nice
>> to know that I wouldn't be alone. :) Anyone else planning to get one
>> and joing me on the journey on maybe the most hacker-oriented laptop
>> ever?
>> 
>> - Chris

Re: Guix on the MNT Reform

[Fredrik Salomonsson]

Hi Chris,

Christine Lemmer-Webber  writes:

> Hi!  Well my MNT Reform arrived.  I'd like to start putting Guix on it
> but I'm kind of low on time right now...

I got mine last week!

> I wonder if anyone else has started making progress towards this?

> What I'd love: a tutorial that says "here are the steps to make an sd
> card you can boot your reform with"!

I'm planning to start hacking on that once I've found a NVMe that works.
The XPG SX8200 Pro 1TB I bought for it had serious issues with access
times. Next up is to buy a WD Blue SN550 1TB and hopefully that will
work.

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Guix on the MNT Reform

[Christine Lemmer-Webber]

Hi!  Well my MNT Reform arrived.  I'd like to start putting Guix on it
but I'm kind of low on time right now...

I wonder if anyone else has started making progress towards this?

What I'd love: a tutorial that says "here are the steps to make an sd
card you can boot your reform with"!


Christopher Lemmer Webber writes:

> I'm very excited to see the MNT Reform launch:
>
>   https://www.crowdsupply.com/mnt/reform
>   https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>
> Completely hackable laptop; all the designs (that are possible) are
> libre, and you can even 3d print to replace many of the parts.
>
> However my impression is that running Guix on ARM is not necessarily
> straightforward.  I haven't tried it yet.
>
> Most important specs:
>
> CPU: NXP/Freescale i.MX8MQ with 4x ARM Cortex-A53 cores (1.5 GHz),
>   1x Cortex-M4F core. CPU and RAM are on exchangeable SO-DIMM sized
>   module.
> RAM: 4GB LPDDR4 memory
> GPU: Vivante GC7000Lite GPU with mainline Linux drivers and OpenGL
>   2.1, ES 2.0
>
> (My other main worry is: that's pretty light on RAM these days...!
> But hey, maybe incentive for me to cut the fat in the programs I use a
> bit more...)
>
> I am thinking of getting one and running Guix on it.  It would be nice
> to know that I wouldn't be alone. :)  Anyone else planning to get one
> and joing me on the journey on maybe the most hacker-oriented laptop
> ever?
>
>  - Chris

Re: Guix on the MNT Reform

[Fredrik Salomonsson]

Hi Andreas,

Andreas Enge  writes:

> Are there other Guix users who ordered such a machine?

I was debating it back and forth after I saw the first email from
Christopher. And a week or so before they reached their goal I took the
plunge and ordered one. Should be a fun laptop to hack on.


-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Guix on the MNT Reform

[Andreas Enge]

On Thu, Sep 03, 2020 at 12:22:27AM +0200, Andreas Enge wrote:
> On Fri, May 08, 2020 at 11:06:04AM -0400, Christopher Lemmer Webber wrote:
> > I'm very excited to see the MNT Reform launch:
> thanks for bringing it to my attention! It looks quite exciting indeed.

And I just ordered one through work. Judging by the postings on Mastodon,
it looks like it will be delivered on time, still this year.

Are there other Guix users who ordered such a machine?

Andreas

Re: Guix on the MNT Reform

[Andreas Enge]

Hello Chris,

On Fri, May 08, 2020 at 11:06:04AM -0400, Christopher Lemmer Webber wrote:
> I'm very excited to see the MNT Reform launch:

thanks for bringing it to my attention! It looks quite exciting indeed.

> However my impression is that running Guix on ARM is not necessarily
> straightforward.  I haven't tried it yet.

I have been using it on a Novena (which has the "predecessor" board i.MX6,
a 32 bit architecture, and does feel very slow; I am assuming the new board
will be much faster), and on the Overdrive, which we use as a build server. 
Guix as a package manager is easy, but I am not very knowledgeable on how to
install the complete system.

>From what I understand, they use a stock Linux 5.7.0 kernel and publish
a kernel config file; we should be able to produce this for Guix with
linux-libre.

> CPU: NXP/Freescale i.MX8MQ with 4x ARM Cortex-A53 cores (1.5 GHz),
>   1x Cortex-M4F core. CPU and RAM are on exchangeable SO-DIMM sized
>   module.
> RAM: 4GB LPDDR4 memory
> GPU: Vivante GC7000Lite GPU with mainline Linux drivers and OpenGL
>   2.1, ES 2.0
> (My other main worry is: that's pretty light on RAM these days...!
> But hey, maybe incentive for me to cut the fat in the programs I use a
> bit more...)

There is a project to develop an LS1028A module with two A72 cores and
up to 16 GB RAM:
   https://nlnet.nl/project/MNT-Reform/
It is expected to be more expensive and to not be available before next year.
So maybe it will be possible to upgrade, depending on how long the adventure
will last - I was a bit disappointed that the Novena has been a one-shot
experience. And there is the EOMA68, which has not materialised.

Oh, and one big drawback: The HDMI output requires a proprietary firmware
blob. Given that I am using my laptop mainly for working attached to a
large screen, that is a big problem.

Since you posted your message, there has been a librelounge podcast, which
I have not yet listened to:
   https://librelounge.org/episodes/39-mnt-reform-with-lukas-hartmann.html

Andreas

Re: Guix on the MNT Reform

[Christopher Lemmer Webber]

Simon Josefsson writes:

> Christopher Lemmer Webber  writes:
>
>> I'm very excited to see the MNT Reform launch:
>>
>>   https://www.crowdsupply.com/mnt/reform
>>   https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>>
>> Completely hackable laptop; all the designs (that are possible) are
>> libre, and you can even 3d print to replace many of the parts.
>
> It looks quite expensive.  Did you look at the Pinebook Pro?
>
> https://www.pine64.org/pinebook-pro/
> https://store.pine64.org/?product=14%e2%80%b3-pinebook-pro-linux-laptop-64gb-emmc-iso-keyboard-estimated-dispatch-in-october-2019
>
> I have ordered their Rockpro64 single-board computer to start Guix
> experimentation on it.  It is an arm64 platform.
>
> https://store.pine64.org/?product=rockpro64-4gb-single-board-computer
>
> /Simon

The Pinebook Pro is definitely amazingly cheap.

The MNT Reform is trying to aim for something else though: something
easily repairable and continuable by the community.

Re: Guix on the MNT Reform

[John Soo]

Hey there,

I am definitely interested in the Reform. Can we see if we can work out 
something in advance? The ship date is tentatively in December 2020.

- John

Re: Guix on the MNT Reform

[Leo Famulari]

On Fri, May 08, 2020 at 11:52:51AM -0700, Vagrant Cascadian wrote:
> On the plus side, the A53 cores are immune to most spectre/meltdown
> attacks!

Yes, a mixed blessing, to be sure! Cortex-A53 is an in-order CPU design.

Re: Guix on the MNT Reform

[Vagrant Cascadian]

On 2020-05-08, Christopher Lemmer Webber wrote:
> I'm very excited to see the MNT Reform launch:
>
>   https://www.crowdsupply.com/mnt/reform
>   https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
...
> Most important specs:
>
> CPU: NXP/Freescale i.MX8MQ with 4x ARM Cortex-A53 cores (1.5 GHz),
>   1x Cortex-M4F core. CPU and RAM are on exchangeable SO-DIMM sized
>   module.

The A53 cores are going to seem quite slow for guix, I would guess.
I've run guix on a pinebook and pine64+ which also have quad-core A53
(although from a different vendor and less RAM) and the CPU was quite
slow...

On the plus side, the A53 cores are immune to most spectre/meltdown
attacks!


> RAM: 4GB LPDDR4 memory
> GPU: Vivante GC7000Lite GPU with mainline Linux drivers and OpenGL
>   2.1, ES 2.0
>
> (My other main worry is: that's pretty light on RAM these days...!
> But hey, maybe incentive for me to cut the fat in the programs I use a
> bit more...)

4GB is fairly useable with guix on the Pinebook Pro, though it has some
faster CPU cores as well.


> I am thinking of getting one and running Guix on it.  It would be nice
> to know that I wouldn't be alone. :)  Anyone else planning to get one
> and joing me on the journey on maybe the most hacker-oriented laptop
> ever?

It's very tempting, but I have too many barely working experimental
laptops already... and the price tag is a bit high. That the various
parts are upgradable, at least in theory, is quite nice!

I'd be curious what the power consumption profile is like at idle and
full load...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix on the MNT Reform

[Ekaitz Zarraga]

‐‐‐ Original Message ‐‐‐
On Friday, May 8, 2020 5:06 PM, Christopher Lemmer Webber 
 wrote:

> I'm very excited to see the MNT Reform launch:
>
> https://www.crowdsupply.com/mnt/reform
> https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>
> Completely hackable laptop; all the designs (that are possible) are
> libre, and you can even 3d print to replace many of the parts.
>
> However my impression is that running Guix on ARM is not necessarily
> straightforward. I haven't tried it yet.
>
> Most important specs:
>
> CPU: NXP/Freescale i.MX8MQ with 4x ARM Cortex-A53 cores (1.5 GHz),
> 1x Cortex-M4F core. CPU and RAM are on exchangeable SO-DIMM sized
> module.
> RAM: 4GB LPDDR4 memory
> GPU: Vivante GC7000Lite GPU with mainline Linux drivers and OpenGL
> 2.1, ES 2.0
>
> (My other main worry is: that's pretty light on RAM these days...!
> But hey, maybe incentive for me to cut the fat in the programs I use a
> bit more...)
>
> I am thinking of getting one and running Guix on it. It would be nice
> to know that I wouldn't be alone. :) Anyone else planning to get one
> and joing me on the journey on maybe the most hacker-oriented laptop
> ever?
>
> -   Chris

Hey Chris,

It's a great project, I've been checking the schematics and stuff myself and I 
liked it a lot. It's a great reference design to build on top of.
I can't afford one atm but I can do my best to help you play with it.
I'm really interested on if it's able to run Guix and I'd like to know about 
your experience with it.

Please keep me posted on your journey!

Best,
Ekaitz

Re: Guix on the MNT Reform

[Simon Josefsson]

Christopher Lemmer Webber  writes:

> I'm very excited to see the MNT Reform launch:
>
>   https://www.crowdsupply.com/mnt/reform
>   https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>
> Completely hackable laptop; all the designs (that are possible) are
> libre, and you can even 3d print to replace many of the parts.

It looks quite expensive.  Did you look at the Pinebook Pro?

https://www.pine64.org/pinebook-pro/
https://store.pine64.org/?product=14%e2%80%b3-pinebook-pro-linux-laptop-64gb-emmc-iso-keyboard-estimated-dispatch-in-october-2019

I have ordered their Rockpro64 single-board computer to start Guix
experimentation on it.  It is an arm64 platform.

https://store.pine64.org/?product=rockpro64-4gb-single-board-computer

/Simon


signature.asc
Description: PGP signature

Guix on the MNT Reform

[Christopher Lemmer Webber]

I'm very excited to see the MNT Reform launch:

  https://www.crowdsupply.com/mnt/reform
  https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live

Completely hackable laptop; all the designs (that are possible) are
libre, and you can even 3d print to replace many of the parts.

However my impression is that running Guix on ARM is not necessarily
straightforward.  I haven't tried it yet.

Most important specs:

CPU: NXP/Freescale i.MX8MQ with 4x ARM Cortex-A53 cores (1.5 GHz),
  1x Cortex-M4F core. CPU and RAM are on exchangeable SO-DIMM sized
  module.
RAM: 4GB LPDDR4 memory
GPU: Vivante GC7000Lite GPU with mainline Linux drivers and OpenGL
  2.1, ES 2.0

(My other main worry is: that's pretty light on RAM these days...!
But hey, maybe incentive for me to cut the fat in the programs I use a
bit more...)

I am thinking of getting one and running Guix on it.  It would be nice
to know that I wouldn't be alone. :)  Anyone else planning to get one
and joing me on the journey on maybe the most hacker-oriented laptop
ever?

 - Chris