I think nixos-hardware is a great call, but I was wondering if there’s a good place on the MNT website too? Do they have some form of community docs?
I finally got unblocked and made some progress on this, but it’s till not great news. I have two ISOs, one is @MartiniMoe’s and the other the one I built on a pocket. My pocket has up-to-date firmware (20251118), but trying to load from either live image (on the pocket) errors when trying to read from MMC with SPL: failed to boot from all boot devices:
41ce typ 24/09/06-09:51:11,fwver: v1.18
ch0 ttot10
ch0 ttot10
ch1 ttot10
ch2 ttot10
ch3 ttot10
ch0 ttot18
LPDDR4, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
ch1 ttot16
channel[1] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
ch2 ttot18
channel[2] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
ch3 ttot16
channel[3] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
Manufacturer ID:0xff
DQS rds:l0,l0
CH0 RX Vref:34.8%, TX Vref:13.2%,13.2%
DQ rds:h2 l0 h2 h1 h2 h2 l0 l0, h1 h1 h2 h5 h2 h1 h2 h3
DQS rds:h1,l0
CH1 RX Vref:35.2%, TX Vref:13.2%,13.2%
DQ rds:h3 h4 h1 h1 h3 h3 h3 h1, h4 h1 h3 h2 h2 h3 h4 h1
DQS rds:l0,h1
CH2 RX Vref:39.0%, TX Vref:13.2%,13.2%
DQ rds:h2 h1 h3 h1 h3 h3 h3 h6, h2 h2 h2 h2 h4 h1 h5 h2
DQS rds:l0,h1
CH3 RX Vref:37.3%, TX Vref:13.2%,13.2%
DQ rds:h2 h4 h2 h3 h3 h2 h3 h2, h6 h5 h4 h4 h5 h1 h6 h4
stride=0x2, ddr_config=0x4
hash ch_mask0-1 0x20 0x40, bank_mask0-3 0xa00 0x1400 0x2800 0x0, rank_mask0 0x401000
change to F1: 528MHz
ch0 ttot10
ch1 ttot10
ch2 ttot10
ch3 ttot10
change to F2: 1068MHz
ch0 ttot12
ch1 ttot12
ch2 ttot12
ch3 ttot12
change to F3: 1560MHz
ch0 ttot14
ch1 ttot14
ch2 ttot14
ch3 ttot14
change to F0: 2112MHz
ch0 ttot18
ch1 ttot18
ch2 ttot18
ch3 ttot16
out
U-Boot SPL 2024.10 (Jan 01 1980 - 00:00:00 +0000)
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
ERROR ### Please RESET the board
I’m building the images, flashing them to a microsd, then verifying that they can be mounted. Here’s the partition info from fdisk:
❯ sudo fdisk /dev/sda -x
Disk /dev/sda: 29.54 GiB, 31719424000 bytes, 61952000 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 441999A8-2256-4D48-AAE2-658CDC5AA573
First usable LBA: 2048
Last usable LBA: 61951966
Alternative LBA: 61951999
Partition entries starting LBA: 2
Allocated partition entries: 128
Partition entries ending LBA: 33
Device Start End Sectors Type-UUID UUID Name Attrs
/dev/sda1 32768 4106239 4073472 0FC63DAF-8483-4772-8E79-3D69D8477DE4 0EDC91A3-5CD6-43F0-87E5-AC9E545DE578 LegacyBIOSBootable
And the card itself seems to have everything in the right locations (is extlinux.conf supposed to be at /boot/extlinux/extlinux.conf?)
❯ ls -lisah /run/media/stites/NIXOS_ROOT/{*/,}*
1795 1.4G -r--r--r-- 1 root root 1.4G Dec 31 1969 /run/media/stites/NIXOS_ROOT/nix-store.squashfs
/run/media/stites/NIXOS_ROOT/boot:
total 16K
13 4.0K drwxr-xr-x 4 root root 4.0K Dec 31 1969 .
2 4.0K drwxr-xr-x 4 root root 4.0K Dec 31 1979 ..
14 4.0K drwxr-xr-x 2 root root 4.0K Dec 31 1969 extlinux
16 4.0K drwxr-xr-x 3 root root 4.0K Dec 31 1969 nixos
/run/media/stites/NIXOS_ROOT/boot/extlinux:
total 12K
14 4.0K drwxr-xr-x 2 root root 4.0K Dec 31 1969 .
13 4.0K drwxr-xr-x 4 root root 4.0K Dec 31 1969 ..
15 4.0K -rw-r--r-- 1 root root 646 Dec 31 1969 extlinux.conf
/run/media/stites/NIXOS_ROOT/boot/nixos:
total 84M
16 4.0K drwxr-xr-x 3 root root 4.0K Dec 31 1969 .
13 4.0K drwxr-xr-x 4 root root 4.0K Dec 31 1969 ..
18 4.0K dr-xr-xr-x 41 root root 4.0K Dec 31 1969 j49vilxnwr1800jfz48w4jpdk6k2mabv-linux-6.19.6-mnt-reform-dtbs
17 60M -r--r--r-- 1 root root 62M Dec 31 1969 j49vilxnwr1800jfz48w4jpdk6k2mabv-linux-6.19.6-mnt-reform-Image
1794 24M -r--r--r-- 1 root root 24M Dec 31 1969 k091kzvsls5nwfw6v3ajd798gv736vik-initrd-linux-6.19.6-mnt-reform-initrd
The only other thing I can think of is that these are very old reforms that haven’t been updated… so maybe my u-boot version is really old? I am currently on version `U-Boot 2024.10`[1], but I’m not sure I’m even getting to u-boot with the current error.
Any help here would be appreciated!
[1]: actually, I think this is in the ballpark of correct, the the reform-rk3588-uboot repo uses collabora’s uboot, last updated in 2024
There are wikis as part of every gitlab project on source.mnt.re. I can also mark posts in this discourse as a wiki.
That error should only happen sometimes and will probably go away once you power cycle the board. Can you confirm?
Yes. Your problem is not extlinux.conf according to your output.
You are in u-boot. But u-boot sometimes fails to read from mmc.
Can you confirm that you can boot the latest official Debian-based system images?
1 Like
Is that linux-firmware? I ask because linux-firmware gets a new release every month. Current is 20260410: https://search.nixos.org/packages?query=linux-firmware
That error should only happen sometimes and will probably go away once you power cycle the board. Can you confirm?
It doesn’t go away, unfortunately. That said, this boots my debian image just fine.
For the Debian-based system images, I am seeing: `U-Boot 2024.10 MNT Pocket Reform with RCORE RK3588 Module 2026-01-28-g424c714eb247-dirty (Jan 27 2026 - 22:55:37 +0000)` in the u-boot output. From a terminal:
$ uname -a
Linux tmp 6.19.8-mnt-reform-arm64 #1 SMP PREEMPT Debian 6.19.8-1+reform20260321T104947Z (2026-03-2 aarch64 GNU/Linux
Is that linux-firmware? I ask because linux-firmware gets a new release every month. Current is 20260410: https://search.nixos.org/packages?query=linux-firmware
No, this is the mnt reform firmware listed by Gnome Firmware (“MNT Research Pocket Reform System Controller 1.0” and “MNT Research Pocket Reform Image 1.0”). I’m not sure what version debian builds, but for the nix flake I am pinned to 25.11. Building a nixos-unstableimage gives me this error:
error: The option `fileSystems."/iso".fsType' was accessed but has no value defined. Try setting the option.
I would assume vanilla linux-firmware works on the Pocket too, but as I do not have a Pocket I am not certain.
With regard to the no value defined-error: can you try to set fileSystems.”/iso”.fsType to the filesystem of that iso, or even leave out the definition forfileSystems.”/iso” entirely? You’ll want to start with 26.05 on your Pocket as support for 25.11 ends in June.
And while I’m adding to this topic I might as well provide an alternative way of installing NixOS on unsupported (by NixOS installer) hardware:
Boot the original Debian that came with the Pocket.
Install nix with sudo apt install nix-bin
Configure nix with echo ‘extra-experimental-features = flakes nix-command’ | sudo tee -a /etc/nix/nix.conf
Start a shell with utilities to install NixOS (add tools for the filesystem of your choice):
nix shell -- nixpkgs#{coreutils-full,dosfstools,f2fs-tools,fscrypt-experimental,gitMinimal,gptfdisk,nixos-install-tools,util-linux,vim}
Create filesystems for / and /boot, mount them under /mnt and /mnt/boot, create a config with nixos-generate-config --root /mnt, edit /mnt/etc/nixos/*.nix, and install into /mnt with nixos-install
1 Like
Did you upgrade your u-boot on emmc after January 27 this year? If not, then this suggests that you have no u-boot on your emmc and then rk3588 will load u-boot from sd-card. At that point, your problem might be a broken u-boot. Try flashing a known-working u-boot image to your sd-card, for example the one which you see working right now to boot Debian.
Looks like it was me not having flashed the bootloader to emmc! I guess I knew you needed to do that step, but doing it didn’t really register 
. I got @MartiniMoe’s image to work (thank you!) but I had some trouble getting my own unstable/26.05pre image working and am hitting a black screen.
I’m noticing that there the kernel is different for @MartiniMoe’s image (tagged 26.05pre) vs the one I built yesterday, so there are a couple more things for me to try. I also had to modify @leif’s code to set the fsType (to "vfat”), which seemed… incorrect.
Edit:
Just a quick followup (no need to ping everyone). It looks like my modifications to nixos-hardware are, in fact, a problem and setting fsType = "vfat"is problematic for getting a working 26.05 image. I would love some help building an up-to-date image, but for anyone else who runs into this issue, pinning to 25.11 is good enough to get something local working. I assume that there is just an issue with the live image format and actually installing NixOS with 26.05 should be fine (that will happen next).
If you are experimenting with u-boot, then I would recommend not flashing it to emmc but leaving it empty. With an empty emmc, rk3588 will read u-boot from the sd-card. If you every have a broken bootloader on the sd-card, flashing a different one using another device is easy. If you flash a broken u-boot to emmc, then recovery becomes tricky because you no longer can boot the pocket reform to fix your emmc.
Anyone here upgraded to NixOS 26.05 with the rk3588? For me it doesn’t boot anymore now 
will have to investigate, maybe on the weekend…
// Okay so this was just an issue with gdm v50 which does not work anymore when not having also gnome installed. I switched to greetd and everything is fine now
wanted to give an update on audio stuff. I was able to add the alsa ucm configurations to swap between headphones and speaker this way:
{ ... }:
let
pocket-reform-rk3588-ucm-conf = with pkgs; alsa-ucm-conf.overrideAttrs {
reformtools = fetchGit {
url = "https://source.mnt.re/reform/reform-tools.git";
rev = "81a7be0a0a1a4012028c78b7e969fdd250949237";
};
postInstall = ''
cp -R $reformtools/audio/ucm2.conf.d/* $out/share/alsa/ucm2/conf.d
'';
};
in {
...
environment.sessionVariables.ALSA_CONFIG_UCM2 = "${pocket-reform-rk3588-ucm-conf}/share/alsa/ucm2";
...
}
EDIT: New (added.
Hello NixOS maintainers! We will soon be switching the way we carry MNT patches. In reform-debian-packages it was directories with patch files. We will be switching to a git repository of linux-stable with one branch per stable version we care about with MNT patches at the tip as regular git commits. Is this making things easier or harder for NixOS maintenance? Do NixOS kernel maintainers prefer us shipping the patches as directories full of patch files or would you like to consume a real git repository with commits in it?
1 Like
Hey there, thanks for this!
I was just wondering, since I am again facing this issue recently. Do you ever have the problem that Keyboard and Trackball stop working some seconds after boot? I had this issue some month ago, then it somehow went away and now I am having it again. I am really lost at debugging this and seem to be the only one affected? 
Hi josch! Thanks for the heads up. To be honest I am not sure right now how this affects us Have to look into how the kernel is built with the existing config for the classic reform.
Maybe @bpye is also affected by this change?
For devices for which kernel patches are provided I (as a user) much prefer a patched git repository as that requires one to just follow that repository instead of an ever changing list of patches.
For example for a Raspberry Pi (I do not own an MNT yet) using a downstream git kernel repository with addition commits in NixOS looks like:
{
boot = {
# kernelPackages = pkgs.linuxPackages_latest;
kernelPackages =
let
kernel_pkg =
{ buildLinux, ... }@args:
buildLinux (
args
// rec {
defconfig = "bcm2711_defconfig";
ignoreConfigErrors = true;
modDirVersion = version;
src = fetchGit {
url = "https://github.com/raspberrypi/linux.git";
ref = "rpi-7.2.y";
rev = "48599d5d6403fd9680b2f5582a7b7b17a0c9d018";
};
version = "7.2.0-v8";
}
// (args.argsOverride or { })
);
kernel = pkgs.callPackage kernel_pkg { };
in
lib.recurseIntoAttrs (pkgs.linuxPackagesFor kernel);
kernelParams = [ "video=HDMI-A-1:3840×2160@30D" ];
kernelPatches = [
{
extraConfig = ''
DRM_XE n
'';
name = "rpi4-config";
patch = null;
}
];
};
}
So IMHO the change you propose would work very well for us NixOS users.
edit: thanks for asking @josch !
1 Like
that is very strange! I haven’t had that problem. maybe a poor connection in the hardware?
I was thinking it is probably more of a software issue because it always happens some seconds after logging in, while for example the entering of the LUKS passphrase always works. When I look at dmesg over ssh it does not show any messages when this happens 
The only patch that is a bit of a hassle is the dts patch which is created in the build script. But yes a git repo (or tar ball) would make maintaining easier.
@josch Do you mean this repo Reform / linux · GitLab · MNT Source ?
The installer build should be fixed with mnt/reform: Support systemd in installer by leifhelm · Pull Request #2062 · NixOS/nixos-hardware · GitHub (if you use the nixpkgs version mentioned in the PR)