---
title: "Funding application to improve Debian support of the MNT Reform open hardware laptop"
author: "Johannes Schauer Marin Rodrigues"
date: "2024-07-28"
output:
  tufte::tufte_handout:
    keep_tex: true
    extra_dependencies:
      babel: english
---

```{r reform-single-2023, echo=FALSE, fig.margin=TRUE, out.width='100%', fig.cap='MNT Reform open hardware laptop. Copyright MNT Research GmbH CC BY-SA 2.0'}
knitr::include_graphics("reform-single-2023.jpg")
```

# Preface

In this document I'd like to apply for Debian funds to be spent on an MNT
Reform laptop.  My goal is to be able to efficiently perform maintenance and
development tasks targeting that laptop with the end-goal of being able to
install and run vanilla Debian on the device and have it be supported by me
during the life-time of future Debian stable releases.

The initial trigger for this funding request was a private conversation with
Andreas Tille, originating from his mail to `debian-project` about a potential
RISC-V module for the Framework laptop in June
2024^[https://lists.debian.org/ZnGtiJAU2jP_Go1x@an3as.eu]. Andreas suggested I
create a more formal write-up which is what you are now seeing in front of you.
Thank you Andreas, for this opportunity.

# Why is the MNT Reform relevant for Debian?

I believe that free software needs free hardware. I have been trying to run
Debian on free hardware since my first baby steps with Debian during the times
of the Openmoko GTA01 Neo 1973 for which I was maintaining custom Debian images
(with our own user interface called PyNeo) between 2007 and 2010. This is also
what ultimately got me into Debian via emdebian (the bootstrapping and
cross-building team back then), into a Google Summer of Code with them in 2012,
a master thesis on Debian dependencies in 2013, made me rewrite `multistrap` in
2017 and create `mmdebstrap` the year after. All the while I was accumulating
what became a growing graveyard of hardware which was more or less able to run
Debian GNU/Linux. It is not hard to find enthusiastic communities of people out
there who create their own devices under an open hardware license and with the
spirit of development in the open just as we practice it in Debian. What is
hard to find is a device which is more than something to tinker with during
weekends. What I was seeking was a device which I could use as my main
computing platform without looking back. There are manufacturers who produce
hardware which is usable as a daily driver but their idea of an open platform
is comparable to the open-ness of Android. Yes, you may get CAD files or even
schematics and they may even be distributed under an open license but you are
still 100% reliant on the manufacturer to produce the hardware for you because
its design requires industrial production methods that are not attainable for
independent makers.

```{r jacqueline, echo=FALSE, fig.margin=TRUE, out.width='100%', fig.cap='Hand-soldered MNT Reform with custom purple PCBs and USB-C charging. Copyright @jacqueline@chaos.social CC0'}
knitr::include_graphics("jacqueline.jpg")
```

```{r PC020009, echo=FALSE, fig.margin=TRUE, out.width='100%', fig.cap='My own 3D print of the MNT Reform main box on an Ultimaker S3'}
knitr::include_graphics("PC020009.JPG")
```

The MNT Reform is what I think is the only open hardware laptop right now which
is both usable as a daily driver and which implements the spirit of open-ness
as we are all used to from free software projects: development in the open and
the ability to reproduce everything "at home". The latter has for example been
shown by jacqueline who re-created the Reform innards and hand-soldered them on
her own custom purple PCBs as can be seen in Figure \@ref(fig:jacqueline). If
you like, you can also 3D print the main body of the laptop on your 3D printer
at home (see Figure \@ref(fig:PC020009)). The former can be seen from how the
device is developed by MNT. The 3D models and KiCAD files of all components (in
case of the LS1028A or Kintex-7 module) are stored in git. If you like, you can
download the altium files and get the CPU module manufactured yourself. All the
changes that are made by MNT are immediately visible as git commits. This also
holds for hardware that MNT didn't even release yet. If you are curious about
the "Reform Next", a slimmer version of the MNT Reform, you can download 3D stl
models of the current version of its case as well as kicad files of the current
revision of its PCBs right now^[https://source.mnt.re/reform/reform-next]. If I
want to submit fixes to their hardware or their software or their
documentation, then I can do so by submitting a merge request on their gitlab.
This is how I started my journey with MNT: I had a lot to criticize about how
they were building their Debian packages and system images and filed merge
requests with my improvements.

I do not want to throw shade on companies like Framework. Them releasing PCB
schematics and 3D CAD models to the public under an open license is a huge
step up compared to the status-quo in the laptop market. I just consider what
MNT does yet another step up in terms of open and reproducible development
of hardware:

> "What works for me is to say, you can clone this thing.
> If we go out of business, you can still make one."
>
> `r tufte::quote_footer('--- Lukas F. Hartmann^[https://mntre.com/reform-irc-logs/2024-06-18.log.html#t19:34:19]')`

The fact that the publicly available git repositories of MNT do not only
contain everything required to re-create the laptop but are also at the same
time the exclusive development repositories by MNT itself reflects the way we
are used to develop software in Debian. Instead of irregular dumps of our
source code without a real way to contribute and interact as it is done for
"open source" projects like Android, we want our main repositories be publicly
available and interactable and share all progress we make with the public. To
my knowledge, the MNT Reform is the only readily available open hardware laptop
which is mature enough such that it can be used as a daily driver and which
implements this idea of open-ness and hardware freedom. It thus, in my eyes,
deserves the attention of the Debian project as the free hardware we want our
free operating system to run on perfectly.

# What work will be enabled by granting this request?

```{r P1050059, echo=FALSE, fig.margin=TRUE, out.width='100%', fig.cap='Playing Blizzard\'s StarCraft: Terran mission 3: "Desperate Alliance" on the MNT Reform using box64'}
knitr::include_graphics("P1050059.JPG")
```

My work with the MNT Reform lead to a few new packages in Debian, like for
example the video player `clapper` which allows hardware accelerated video
decoding or the `box64` emulator which allows one to run x86 binaries on ARM.
Even on comparatively slow ARM processors, this allows playback of 1080p@60
h264 video or playing Starcraft (see Figure \@ref(fig:P1050059)) and Stardew
Valley (40 hours in networked multiplayer with my partner on a Thinkpad),
respectively.  But maintaining these packages does not require the actual
hardware for 99% of their maintenance tasks. On the other hand there are some
areas where access to an MNT Reform is not only required, but which require
destructive access to it.

```{r d-i, echo=FALSE, fig.margin=TRUE, out.width='100%', fig.cap='The partition setup of the Debian installar running on the MNT Reform with imx8mq'}
knitr::include_graphics("d-i.jpg")
```

For example, Figure \@ref(fig:d-i) shows debian-installer running on my MNT
Reform. This works in principle but I'd like to improve on the current
experience, support other CPU modules and make sure that there are no
regressions over time. For example, users reported to me, that d-i works fine
with the kernel from Debian bookworm but with the kernel from
bookworm-backports, the screen does not work with the imx8mq. This is
something that I have to investigate on the actual hardware (this is not
something that QEMU can emulate).

Furthermore, there was a recent change in debian-installer which broke
`flash-kernel` from configuring the correct device tree which means that the
installed system fails to boot. To test and fix this, I need to actually finish
the installation on the device but that would destroy my existing installation,
making creating a fix for this very tricky.

```{r P2060098, echo=FALSE, fig.margin=TRUE, out.width='100%', fig.cap='LS1028A powered by ATX PSU and a full-size PCI-E connector to test external graphics cards'}
knitr::include_graphics("P2060098.JPG")
```

To make some of these maintenance tasks more manageable, I created what I call
the "MNT Board Reform" in Figure \@ref(fig:P2060098). This is my old motherboard
(which has a broken audio chip) with the LS1028A CPU module on it. It is
powered by an ATX power supply and is switched on by a Raspberry Pi Pico RP2040
which is sending the appropriate commands to the motherboard firmware (this
would otherwise be the task of the keyboard). I can use this setup to test
installing Debian using d-i via a serial connection over UART. But this system
does not have a display (so I cannot test the problem with the screen not
coming on), it does not have keyboard or trackball attached to it (so I cannot
test their interaction with it or test new firmware versions), it does not have
the battery boards attached (so I cannot for example test the recent
regressions of the battery plugin in
waybar^[https://github.com/Alexays/Waybar/issues/3482]) and since its audio
chip is broken, I cannot do tests involving audio playback either (some custom
alsa and pulseaudio configurations are required for sound to work).

The current functionality was mostly created when I still had my old Thinkpad
as my main machine and the MNT Reform as a disposable second machine that I
could use to tinker with as it contained no relevant data. Now that the Reform
became my main laptop, more and more bugs start appearing which I have a hard
time fixing as I rely on other users gathering all the data for me. I can no
longer reproduce their issues as that would often mean that I have to
re-install my machine or perform steps which would risk breaking my
installation by accident.

Having a dedicated machine to tinker with would again allow me to improve my
work on Debian installer, resume maintaining it long-term, fix the scripts
contained in the `reform-tools` package involving flashing firmware or disk
images to eMMC or NVMe and create and test new scripts. My concrete TODO list
is:

 - upload `reform-tools` package to Debian main
 - create and upload a `reform-firmware` package to Debian main
 - `debian-installer` support in main
 - fix the `reform-setup-wizard` package so that it can transition to testing
 - integration into `openqa.debian.net` (Phil Hands already helped me with that)
 - create a firmware flashing tool using rescue media (Chris Hofstaedtler already assisted me with that)

All of these components above involve destructive low-level operations on the
hardware. I would feel much more confident in being able to maintain all of
these components long-term and develop new utilities, had I access to a
dedicated machine to test all of this on.

# Why should I be the recipient of this funding?

```{r PA302061, echo=FALSE, fig.margin=TRUE, out.width='100%', fig.cap='My MNT Reform with customizations'}
knitr::include_graphics("PA302061.JPG")
```

As may be apparent by now, I'm a massive fan of the Reform and how MNT, the
company behind it, is approaching the subject of open hardware, open
development and interaction with the community. Figure \@ref(fig:PA302061) shows
my MNT Reform with the imx8mq and several modifications like an integrated USB
UART adapter, a radio transceiver, a UMTS modem and an additional TRRS jack.
After looking for an open hardware device which can run Debian and which can be
my daily driver instead of just a device to tinker on for over 17 years, the
MNT Reform is what I have been dreaming of and more.  According to my NVMe
drive, my MNT Reform has been in operation for a total of 13171 hours or 549
days. I cannot imagine to loose interest in this platform for the years to
come.

```{r gitlab, echo=FALSE, out.width='100%', fig.cap='My activity on the https://source.mnt.re gitlab instance of MNT over the past year'}
knitr::include_graphics("gitlab.png")
```

I have essentially taken over the Debian integration and development of related
tools for the MNT Reform which is also reflected in the credit section of the
latest version of the MNT Reform
handbook^[https://mntre.com/reform2/handbook/credits.html]. Since I started
using the Reform at the end of 2021 I am the main contributor for the
`reform-tools` repository (62% of all commits), the `reform-debian-packages`
repository (71% of all commits) and the `reform-system-image` repository (44%
of all commits). I have direct commit access to the MNT repositories and can
only think of positive interaction with MNT regarding my contributions. My
regular tasks include bug fixes, rebasing of the Linux kernel patch stack each
time a new version gets uploaded to unstable by the Debian kernel team, adding
support for new platforms to the tooling and (as all the software is built
against Debian unstable) file bugs in the Debian bts once they affect us. One
major example for this was a `binutils` bug which made the Linux kernel
unbootable but only on `arm64`. This bug was first found by the MNT
community^[https://bugs.debian.org/1074112].

I am the sole maintainer of [reform.debian.net](https://reform.debian.net)
(hosting is kindly provided by the provided by the debian.net
team^[https://wiki.debian.org/Teams/DebianNet]) which provides a Debian package
repository, bootable disk images and debian-installer images for the MNT Reform
but (in contrast to the content provided by MNT) built against Debian stable
(and backports) and signed with my GPG key. All my work is bit-by-bit
reproducible, all scripts producing the content can be run locally without
requiring superuser privileges (making use of my packages `mmdebstrap` and
`sbuild`) and are cross-buildable from `amd64`.  My work thus directly benefits
other Debian teams like the cross-building and reproducible-builds team. For
example as part of my work for reform.d.n I found a bug which violates the
principle that the package name/version/architecture triplet uniquely
identifies a package in Debian^[https://bugs.debian.org/1072205].

I am also deeply involved with the community on the
forums^[https://community.mnt.re/] where I have so far read over three thousand
posts and created over 470 posts of my own (compared to about 500 posts from
Lukas), receiving over 500 "likes" for my content. Same goes for IRC where,
according to the logs^[https://mntre.com/reform-irc-logs/] I have contributed
22% of all messages (compared to 23% posts from Lukas). At Mini DebConf Berlin
2024 I gave a lightning talk^[https://mister-muffin.de/p/JlVD.pdf] about my
software work for the MNT Reform and met other Debian Reform owners (Martin
Borgert) as well as plenty Reform-curious folks.

# Remaining Challenges

Some of the CPU modules available for the Reform (like the imx8mq) require
proprietary firmware. Unfortunately, the license of these firmware files makes
them even non-distributable by nonfree^[https://bugs.debian.org/1035055]. I
have contacted the Linux NXP team about this issue and hope that NXP can grant
a license exception to
Debian^[https://lore.kernel.org/r/all/172079266731.2928366.7031846226118749814@localhost/].

# Funding Application

I hereby ask for funding of an MNT Reform laptop with a Rockchip RK3588 module
in it with the purpose of carrying out above outlined development tasks over
the course of the next Debian stable release and hopefully beyond. The cost for
that is 1,400.00 EUR^[https://shop.mntre.com/products/mnt-reform].
