You might recall that I was considering a MNT Reform laptop to replace my crappy HP laptop a few months ago.
Well, I got no answer or information of any kind anywhere (not just here on Lemmy), but the idea kept going round and round in the back of my head. And now, 5 months later, I find myself having to upgrade Mint to Wilma on my hateful HP laptop soon, and I already dread rebooting to the console because Xorg is dead again, having to downgrade to a working version of the kernel again, fighting the AMDGPU driver again, making the super-flaky and completely terrible wifi-cum-bluetooth Realtek 8821CE adapter work halfway decently again…
I hate this laptop. In fact, I hate it so much that I finally pulled the trigger on the MNT Reform laptop. Hopefully it’ll get here before the need to upgrade becomes too pressing.
Stay tuned 🙂
I am curious how much work it will be to modify that Ubuntu image to fully work on the Reform. The audio chip and some other peripherals are on the mainboard, and need to be included in the device tree for the kernel to pick them up, so I would expect that at least some modifications of the image are needed.
It might already be enough to grab the device tree from the MNT gitlab, compile it, and put it in the boot partition for stuff to work. (You will likely also want to install the reform-tools - either from their gitlab or from their repository. They include a kernel module that is needed to get battery readout and to power off the laptop on shutdown.)
What helped me a lot while setting up the system was that I kept the SD card with the official (Debian Unstable) image around - every time something didn’t work, I could boot it up and check how the official image does it.
Well I don’t know how MNT will configure the Reform. I presume they’ll load the OS entirely in the eMMC flash. So my plan is to dual boot it - either the default OS in eMMC or Ubuntu in the NVMe SSD. That way I can go back and forth and see what works best. Once my mind is made up, if I decide to install Ubuntu in eMMC, I’ll back it it, blow it, transfer Ubuntu onto it and mount the NVMe SSD as /home. If I decide Ubuntu sucks, I’ll just wipe the SSD and use it as /home immediately.
At least in my case, the default OS came on an SD Card, and both, the M.2 SSD (which I had ordered together with the laptop) and the eMMC were empty. The manual contains a section about moving the OS to eMMC, so I guess that’s their default setup.
(In my case there’s an additional thing though: For the Banana Pi CM4 SoM the installation of u-boot into eMMC is officially not supported, as one would need a CM4 I/O board to erase it again, if anything goes wrong. I installed it there anyhow, and it’s working for me, but I did buy the I/O board beforehand as a precaution.)
Oh right okay. Yeah now that you mention it. I do seem to recall watching somebody’s video booting the reform from the SD card. Well then, that’s even better: I can just backup the SD card and reinstall over anything I’m not happy with.
I’m totally unfamiliar with how these things boot. I’m not even sure it’s more or less standardized between various SoMs. But I suppose it’s possible to select which device to boot from at some point or other after power-up. So maybe what I’ll do is follow the manual just to familiarize myself with the machine as MNT Research intended, then install Ubuntu on a SD card and boot off of that, until I’m happy enough with it and replace the default stuff on the eMMC with it.
I’m curious: why do you need an I/O board with the Banana Pi CM4? Do you need a JTAG or SWD port that the add-on board provides to program the flash if the updater gets hosed or something like that?
I haven’t looked at the schematics, so I am not certain which connection exactly would be needed. I only know that the Reform Mainboard and the Reform CM4 adapter don’t expose any way of writing to the eMMC other than booting the system first. The problem here is that the Banana Pi CM4 boot process first looks for a bootloader in eMMC, and only if it cannot find one there, tries the SD card. So, if one flashes a bootloader that gets recognized by the firmware, but that later fails to boot, one is stuck…
The I/O board on the other hand allows to connect to the CM4 via USB, and there is a weird, but supposedly working, procedure to erase the data in eMMC.
In any case, I now have a spare CM4 I/O board lying around, and if I ever choose to upgrade my Reform to the Rockchip SoM (or something even faster), I can then still use the CM4 as a small standalone PC.
Interesting… I’ll have to dive into all that at some point. Thanks!