Hi,
I followed the advice and switched to barebox. Now the pocket always starts with only the upper half of the screen visible. The first boot was o.k. But then I wanted to see the barebox options when interrupting the start by pressing “m”. After that every time I start the pocket it comes up with only half of the display. Should I return to u-boot?
RK3588
Display V2
Hi, yes, it’s the final issue I’m fixing right now. If you go back to u-boot in the meantime, it should be fine.
I just merged fixes for this issue, and the pipeline has passed and the packages are rolled out to the MNT Debian apt repo.
To update the drivers/kernel again:
sudo apt update
sudo apt install linux-image-mnt-reform-arm64 reform-tools
For barebox testing, I’ve also made a build of barebox that attempts the display hard reset via system controller, you can try it by flashing this version: https://source.mnt.re/reform/mnt-reform-barebox/-/jobs/23694/artifacts/raw/images/barebox-mnt-pocket-reform-rk3588.img
(The (destructive, only use when you know what you’re doing!) command for flashing this to eMMC on RK3588 Pocket Reform is: sudo dd if=barebox-mnt-pocket-reform-rk3588.img of=/dev/mmcblk0 seek=64)
I’ve got positive feedback from another user on IRC that these builds work for them (RK3588 Pocket Reform with Display V2).
Thank you! My now installed kernel is 7.1.7-1+reform20260810T183147Z (2026-08-10). Display is back in fulscreen!
I also flashed the latest barebox image and my pocket is still alive. There is a slight flickering when barebox starts, which stopps when the modules start loading.
Thanks a lot 
As I wrote a bit further up, I’m making a new System Image with the newest kernel patches, with extra fixes from tonight, fitting to your already updated firmware, and this just takes a while to build. I’ve now merged and rolled out the packages (this took several hours of CI pipelines), and now a System Image rebuild is running. Once this job is complete, you can flash it to a MicroSD card and this should boot normally with your firmware: build (#23695) · Jobs · Reform / reform-system-image · GitLab · MNT Source
As you wrote that you no longer want to use the device and want to replace the eMMC contents with the initial image/setup wizard, you were already on the right track with reform-flash-rescue. I’ve looked at its source and it pulls the latest build from the main branch of reform-system-image, so after my CI job is finished, it should do what you need.
There is a bug in the output above. With this you boot into 7.0.10 instead of 7.1.3. But you need the latter with the new firmware. This issue is fixed in barebox upstream:
@minute maybe the copy of barebox in the mnt-reform-barebox repository could be updated to a version which includes the change? Otherwise it apparently can happen that even though a user upgraded to the new kernel, they will still boot into the old kernel because bootloader entries are sorted by the order in which they are read from the filesystem.
--no-safety-check did not work for me, and I don’t see it mentioned in man fwupdmgr. I did need to bypass the battery charge check due to my battery reading empty. Here’s what worked for me:
sudo vim /etc/fwupd/fwupd.confIgnorePower=truesudo systemctl restart fwupdsudo fwupdmgr refresh && sudo fwupdmgr updatesudo vim /etc/fwupd/fwupd.conf, remove the line to restore the file to normalAlso, I used sudo dmesg -n 1 to temporarily turn off kernel messages on the console. Errors relating to the battery driver were flooding the screen.
My system:
Looks like that new image’s bmap file is broken:
It is not broken. You’re just using the wrong URL. The correct URL is: https://source.mnt.re/reform/reform-system-image/-/jobs/23695/artifacts/raw/pocket-reform-system-rk3588.img.gz
This is the URL of the “Download” link on the download page. The URL you’re trying is the webpage that contains the download link. If it’s any consolation, I too have flashed HTML pages as bootloaders in the past.
I installed the new tools, kernel, and firmware. The issues that I was seeing on the old firmware persists: the SC seems to go away (OLED menu - system status would show a blank line for the SC), and the battery status isn’t working and is being reported as 0 everywhere. Charger board v2, RK3588, Display v1.
But I just tried to confirm this again after a power cycle and now the device isn’t responsive, eek…tomorrow I guess I’ll open it up and check the cabling and try a charger bypass.
Hi, it’s possible that you only need to disconnect and reconnect the batteries. It can sometimes happen that the charger chip gets unhappy during a system controller firmware update and then hogs the I2C bus until it is power cycled (the standby switch can’t do that).
That seemed to have helped get the system to boot again and the SC seems more stable now, thanks for your hard work!
Great, thanks for reporting back!
I managed to upgrade successfully on trixie-backports (fw: 20260808, Linux: 7.1.3), but noticed a new issue pop up where the battery repeatedly starts and stops charging (which is concerning for battery health).
In order to rule out any issues specific to my trixie-backports installation, I flashed the latest system image and booted from the SD card and still observe this issue. A small excerpt from the logs - this repeats non-stop:
...
Aug 15 22:26:36 *** reform-power-daemon[770]: Power state changed to high (Charging / 70%).
Aug 15 22:26:38 *** reform-power-daemon[770]: Power state changed to low (Discharging / 70%).
Aug 15 22:26:39 *** reform-power-daemon[770]: Power state changed to high (Charging / 70%).
Aug 15 22:26:43 *** reform-power-daemon[770]: Power state changed to low (Discharging / 70%).
Aug 15 22:26:44 *** reform-power-daemon[770]: Power state changed to high (Charging / 70%).
Aug 15 22:26:45 *** reform-power-daemon[770]: Power state changed to low (Discharging / 70%).
...
After debugging a bit more, it turns out that this is specific to the power adapter that I use, and was able to stop the issue from happening by changing it. With the problematic power adapter, I also observe the battery cycling between charging and discharging on the OLED screen in the “Battery Status (b)” menu when the system is off.
Now, normally I would chalk this up to “a faulty power adapter”, BUT:
I have a fix for now (just use a different power adapter), but I did want to share in case anyone else observed this (so you know that changing a power adapter might solve the issue) and in case there was a firmware regression that was introduced with the latest update.
Also, may be completely unrelated by I do see these logs from the new mnt_sc driver which seem suspicious (but may be a red herring, as they do not happen with the charging/discharging flip flop, and happen regardless of the power adapter I use - if any):
Aug 15 22:14:59 *** kernel: mnt_sc spi1.0: mntsc: couldn't parse response: err undf
Aug 15 22:14:59 *** kernel: mnt_sc spi1.0: mntsc: couldn't parse response: err maxp
Hi, thank you for the details!
The mnt_sc warnings are harmless.
The start/stop thing is definitely a fw regression which I can fix, I just need to obtain such an Apple charger asap. BTW does that also happen when you try charging while the Pocket Reform is off?
Hard to say for sure, but I think so. If I plug in the power adapter and observe the “Battery Status (b)” menu, I see the discharge amperage cycle between low positive (~0.0x) and negative values (~[-1, -2]) when connected to my Apple power adapter. With my other working power adapter, I get a steady negative discharge amperage value (~[-1.7, -2]).
Hope this answers your question!
I’m finding that when my screen idles off it won’t light back up when I press a key or move the trackball. However, it does come back on if I use a keybind to manually adjust the brightness.
RK3588
I noticed that, too.
RK3588
Ediiiiiiiiiiiiiiiiiiiiii… Edit: That’s what I wanted to post when it just happened again:
I now notice that typed characters often are repeated several times. Also after waking up the desktop from screensaver (…not quite shure whether it’s related to that) the trackball becomes slow or unresponsive. I have to repeatedly reset usb and/or keyboard to bring it back to life. Or I attach an usb mouse to shut down the reform cleanly.
I’ve just fixed the backlight handling bugs related to lock/unlock (with display v2) in a new system controller firmware version, but I need to roll it out through LVFS now, which can take a few hours (or, if you know what you’re doing: https://source.mnt.re/reform/pocket-reform/-/jobs/23931/artifacts/browse/pocket-reform-sysctl-fw/build/ ).