Why are the platform-dependent choices for building an MNT Debian image encoded in this shell script, in terms of engineering trade-offs? The notional alternative is a Debian (Pure) Blend with per-platform ConfigPackages or meta-packages. I don’t know enough about Debian (or, indeed, Linux) to understand how these approaches should be compared.
To elaborate: the linked mkimage.sh script carefully maps distribution and hardware choices to a list of arguments to mmdebstrap, which creates a root filesytem. Then mkimage.sh writes that filesystem to an image file and installs u-boot on it. Obviously this works (I am happily running these images right now!) and has the advantage that only a few(?) files define the MNT Debian system after reform-tools and patching the kernel is taken into account.
Alternately, could the Debian MNT system be assembled by making one distinct metapackage per platform? So, e.g., installing the notional “mnt-pocket-rk3588” metapackage would pull in reform-tools and all other relevant dependencies, with the specific choices for pocket-rk3588 encoded in a config package.
Clearly it would require additional work/overhead to maintain separate Debian packages for each MNT platform. On the other hand, this might allow the mkimage.sh script to be much simpler. So, two questions:
Why was the current layout chosen (handling platform-specific configuration in a single mkimage script) instead of the platform-specific metapackage approach?
How close is “MNT Debian” to being a (pure) blend? Is it feasible in principle to make it a pure blend, for at least some platforms? As far as I can tell, reform-tools and reform-desktop-* are (meta)packages in Debian, which makes it “close” to a (pure?) blend. Is it that MNT needs to distribute a patched kernel from their own repositories?
It’s even better: the root partition of the MNT system images is identical independent of the platform and the /boot partition could be identical if it were not for supporting ancient u-boot versions. This is how we can ship the reform-system-any images which work on all the MNT platforms. The contents of the images is governed by a single meta-package called reform-desktop-full. There is no need for platform-specific metapackages because the content of the rootfs is identical.
We do not need a platform-specific meta-package. The rootfs is identical across all platforms. Unfortunately, creating a rootfs is more than what can be done in a binary package and that’s why we still need a script. A lot of magic though is gone from this script since the reform-desktop-full metapackage exists.
Yes, that is mostly it. We need help (yours?) to upstream the MNT specific changes into Linux proper. Only then can we create a pure blend. Nearly everything else is (as you observed) in Debian today. It is mostly the kernel that’s missing.
This is indeed even better than I’d hoped for! Thank you. I am slowly improving my understanding of the image build process. Couple more questions about that:
What are the main locations where $SYSIMAGE is used to determine machine-specifics? I see: lines 700 and 848 of mkimage.sh, where it pulls a matching config file out of reform-tools. It also looks like $SYSIMAGE is used to set distribution-support flags. Am I missing anything?
A few files (reform-firstboot-premount, reform-firstboot-hook, reform-firstboot.service, reform-mkimage-hook)are written directly into mkimage.sh, but it seems they do not differ based on $SYSIMAGE or other parameters of mkimage.sh. Why are they written inside mkimage.sh ?
I have some time coming up over the holidays so I am trying to find something helpful to do for MNT and/or Debian with my rudimentary skills. Answers might be “learn how to upstream patches to the kernel” or “work on rk3588 hibernation support”. To see what’s feasible, let me ask:
Are all kernel patches collected in MNT Debian linux package? For example, the linux/patches6.16 subdirectory.
Selfishly, I’d like to improve support for the rk3588 pocket. Does the subdirectory rk3588-mnt-reform2/ apply to pocket as well?
Many patches in the MNT “linux” package are authored by Collabora employees and already submitted to the linux kernel mailing list. Picking one of the shortest patches, drm-rockchip-vop2-Add-clock-resets, this was submitted to the linux kernel mailing list in 2024, with most recent activity in July 2025. Does the following workflow make sense:
Rename those constants as requested by Heiko Stübner (who maintains Rockchip support in the Linux kernel)
Test on my MNT pocket to make sure this doesn’t break anything and the patch applies cleanly to the most recent kernel
Contact Detlev Casanova (the Collabora employee who authored that patch) to check that I haven’t messed anything up and offer help re-submitting
Or, does it make more sense to try and work on this Collabora repository that is devoted to improving Rockchip support upstream?
Finally, where is the best place to get extensive documentation for RK3588 to support these efforts? Ideally documentation that could help with my “get hibernation working” project, too.
Sorry for the very long post, I am just getting started on understanding kernel/OS level development.
Can you rephrase your question? What do you ultimately want to achieve? $SYSIMAGE is just a variable name which the script uses to determine what platform-specific features to work on. You can see all locations where it’s used by searching in mkimage.sh.
The files are tiny and by having them embedded in mkimage.sh I do not need to open a different editor tab to make changes to them. It also keeps the repository root directory free of clutter.
Yes. All kernel patches on top of vanilla Debian Linux are in the linux subdirectory of the reform-debian-packages repository.
Yes.
The workflow you suggest is independent on whether you work on the Reform kernel or upstream kernel with collabora patches. I suppose though that for faster iteration, it will be more comfortable to work with a git clone of the collabora rockchip-3588 linux repository and build from that because it will allow you to build a much more minimal kernel than the full Debian kernel which can take hours to compile depending on your machine. For development, you may want to build from git with a much more minimal config targeted at your specific machine instead.
About helping with the patch I think that contacting patch authors by mail and asking for how to best contribute is a good way forward.
I cannot give you help with finding documentation because I’m not a kernel person or hardware person in general. My expertise is on the OS-level. But maybe it would be a good idea to try and join the #mnt-reform irc channel where most recently @minute already managed to build a small monolithic kernel which has working suspend. This repository has some scripts which automate the patching of an upstream kernel with the Reform patches:
In general, upstreaming patches is very much appreciated. Thank you!
