first of all I love my new little power house of a pocket reform and the customizeability. I’ve upgraded the batteries and changed the key switches so far.
But one problem that I’ve had since assembly is occasional surprise restarts. I’ve also had “freezes” which I now is almost certain was just the keyboard crashing, but those are mostly gone now. I still get the surprise restarts. I’m a very comfortable Linux user and have tried to look into any error messages related to the restarts but with standard config the logs, as is custom, shows nothing.
At one of the reboots, which I also took a picture of, it looked like it tried to resume from suspend but timed out when trying to access the disk, that time I ended up in initramfs instead of a proper reboot.
Any hint or idea on how I should solve this or just get the logs to show anything? Or is this kernel in debug mode territory?
(I’m running full disk encryption on the 1 TB disk which you buy with the pocket. If that is relevant.)
I don’t have a solution to share yet, but just wanted to say I have seen the same issue and am also running full disk encryption on the 1 TB.
I have not been able to catch it since upgrading to the latest firmware + reform tools, but I will share here if I do see it again with more information.
Hi, minute is currently investigating this very issue. They were able to reproduce a brownout which happens when cells are at about 3.3 V and the system is under load.
Until a fix has been found, workarounds are to:
not get the battery too low
not run compute intense tasks at low battery
reduce keyboard and/or display brightness when on low battery
I’m sure that minute will post an update on the situation once they have a solution that they are happy with. You can read details in the IRC logs of the past few days.
I saw that problem on here somewhere and on the git, but I’m not sure that is it. I’ll try to document the specifics in the future to make sure I’m remembering correctly though. I really hope it’s the same problem and wish them all luck in finding the solution, I do very much love the Pocket and looking forward for the Next.
But I’ve got this while charging with maybe 8% screen brightness and only LibreWolf (Firefox) open showing a plain HTML page. Or when I plugged in the charger while watching old 360p rips with all things set as dim as visible in complete darkness. To mention the ones I remember.
The keyboard backlight is usually what is eating the most power unless I’ve lowered it after boot. I’m never drawing more than maybe 0,7 A (1,12 A with keyboard on default).
Anyway sounds like I’ll have to make another try at connecting to the IRC.
There used to be issues that looked somewhat similar but they were fixed in recent versions of the sysctl and keyboard firmware. Make sure you have version 20251001 or later.
Thank you for reporting this issue and the details. It is weird that this is popping up more often in the last few weeks. Our own @holo_memory also has this issue since we upgraded his Pocket Reform to Display V2 and a yet unreleased revision of RCORE (but that has only small layout changes, nothing functional), but I also updated the sysctl firmware from something pre-20251001 to 20251001, and then to the latest build from a few days ago. We’re trying quite intensively to find the cause(s) for this.
as @minute just said, we’ve been running tests on my pocket reform for days now and we’ll continue until we find the cause. i’m optimistic we know more soon
I don’t know if this is related, but I experience a sudden poweroff (brownout?) only when I specifically run whisperx on my a311d Pocket Reform without being plugged into usb power. It works fine (if slowly) plugged in. Have been meaning to investigate but never got around to it, mentioning it here in case it’s a useful lead. Here’s an example invocation:
./venv/bin/whisperx --compute_type int8 --language en -f json example.wav --output_dir out/
I installed it with pip. You may need a somewhat long wav file with speech in it to reproduce.
On the side note, with firmware 20251001, I noticed that keyboard backlight does not go off when the screen goes to sleep and be locked. Would this be related?
Just an input. Thanks.
shigeru@mntpr-0:~$ sudo reform-check
I: Contents of /proc/device-tree/model: MNT Pocket Reform with i.MX8MP Module
I: `uname -a` output: Linux mntpr-0 6.16.9-mnt-reform-arm64 #1 SMP PREEMPT Debian 6.16.9-1+reform20250910T145641Z (2025-09-1 aarch64 GNU/Linux
I: Version of linux-image-mnt-reform-arm64: 6.16.9-1+reform20250910T145641Z
I: Version of reform-tools: 1.79-1+reform20250926T072932Z+1
I: Version of system image: System Image v4: 2024-08-20
I: To retrieve the latest sysctl and keyboard firmware versions either install libxmlb-utils or install curl, xz-utils and libxml2-utils
I: Version of system controller firmware: "20251001"
I: Version of keyboard firmware: "20251001"
I: probably booting via /boot/boot.scr (/boot/extlinux/extlinux.conf does not exist)
I: Mount source of /: /dev/reformvg/root (LVM vg 'reformvg' on LUKS device 'reform_crypt' on SSD)
I: Mount source of /boot: /dev/mmcblk2p1 (eMMC)
I: the following files differ from how they are shipped by reform-tools (ignore /var/lib/alsa/asound.state):
??5?????? /var/lib/alsa/asound.state
I: eMMC contains the latest u-boot version 2025-01-12
@aaa@computergripe RK3588 processor? Sway or GNOME? Does it happen on battery or power supply or both? How often approximately?
@deianara that’s interesting, even if on another processor module. Which is normally pretty low power so that’s extra strange. Even happens at 100% (lets say over 90%) battery?
@shigeru well, it’s not impossible. The keyboard backlight drains a lot of power and the automatic backlight dim is gone from the firmware because something was wrong with the timer anyway and I rather want to move to a software solution (makes sense to integrate with desktop environment).
Currently I think we are seeing two different issues that look very similar:
Brownout due to voltage dip with high current use on battery (not happening on power supply), probably now happening more often because of keyboard backlight no longer auto-dimming and more people on RK3588.
Unknown CPU/GPU/??? crash possibly related to longer video playback. Could also be something else, non-obvious.
For 1., I’m currently thinking in the short term about some power management strategies of dynamically limiting keyboard + screen backlight and if necessary, CPU/GPU power profile depending on battery charge / power supply plugged in or not. In parallel I’m doing more diagnoses of the power rails in hardware to see if something should be boosted or could need more capacitance.
For 2., we’re still trying to isolate the cause by doing many tests.
With my Pocket Reform I experience unexpected reboots on battery power, usually starting at around 50-60% battery, sometimes more. Also, every once in a while I am experiencing keyboard crashes.
On every boot, I get some error messages like the one below (sometimes other about the usb device):
[ 4.196859] panel-mnt-pocket-reform fde30000.dsi.0: error -ENOENT: cannot get reset-gpios 0
[ 4.196893] panel-mnt-pocket-reform fde30000.dsi.0: error -ENOENT: cannot get dcdc-en-gpio 0
RK3588 processor, Sway, always has happened on power supply for me.
I’ve seen it 3 times, latest was earlier today when my battery was around 73% while plugged in which was the highest battery %age it had happened at. I had been using firefox heavily at least 2/3 times that it happened, but I do not think I was playing any video.
I’ve been using my pocket “docked” into an external monitor and peripherals (keyboard, mouse, headphones), and my keyboard backlight and display are both off when it’s in this docked state.
I can try testing it out more on battery power and monitor my power usage when docked more closely, but I have a feeling my problem might land closer to 2.
pocket reform is being charged (100%), there’s a mouse connected and an external monitor (turned off though). yesterday, i turned the keyboard backlight off and set the display brightness to “low”. i had a video looping the whole time and it was running for 6 hours without any issues. i shut it down (bedtime ). in the morning at 10:15, i repeated the exact same test. it’s now 17:30 and it’s still running, no resets, nothing.
all of the other tests (display at high brightness, keyboard backlight high and medium and low brightness, no wi-fi) led to a reset. so maybe i’m onto something but i can’t say for sure yet.
edit: btw i’m running sway, rcore v2, display v2. i watch videos with the mpv player.
Also had a crash a few mins ago:
was watching a vid via mpv, connected to power, external monitor attached (but i also had these reboots without any connected devices)
Like always, nothing unusual in the logs/journal, seems to me like the power is just gone for a short time. i had htop open, cause these restarts happen sth around once a day, the only thing i saw there was that the cpu temp was around 75 (my other guess was that it maybe gets to hot and kills itself xD)
Oh and i had these crashes with an older firmware as well, yfi. I updated to latest a few days ago via fwupdmgr, to test if its gets better.
edit: did run stress with full cpu/memory load for a few mins.. didnt crash ^^v
Many thanks to everyone reporting data here. Could you do an experiment: do you have 2 extra little M2 screws? You could borrow 2 from the bottom plate which has plenty. RCORE has 2 gold plated screw holes and there are matching threads on the motherboard. Could you fasten RCORE to these threads (make sure it’s plugged in cleanly and the holes are not misaligned, and don’t force the screws if there is resistance!). I want to make sure that intermittent or non optimal contact of the module isn’t the reason for this.
Can you also check that the two cables on the motherboard going to the charger module (green and black) are as firmly pushed in as possible? And also on the charger module side? (In the bottom half of the device).
With the firmware 20251001, when booting up and prompted for the LUKS pass phrase, I may have to wait several seconds before typing in order to get it captured properly with the first try. When I type in as soon as prompted, it rejects input.
BTW I noticed today after many torture tests that my personal Pocket Reform’s cells have pillowed a bit already. This explains the brownout resets under load at least for my personal system. These cells are already quite old though and have seen many cycles. I know though that some people with “random” resets have relatively new machines.
). in the morning at 10:15, i repeated the exact same test. it’s now 17:30 and it’s still running, no resets, nothing.