My machine came in August and has random resets; I don’t know how many (full equivalent) cycles are on these batteries, but I’m guessing not more than a few dozen.
I’ve screwed the carrier board down and checked all of the battery cables (to the charger board, from the charger board to the motherboard on both ends). I’m considering adding a small capacitor or two on the motherboard near the battery power entry.
Mine came mid September.
Gonna screw down the board tonight ^^
I’ve got mine a couple of months at most.
I haven’t had time to double check all connections and screw down the board yet but I smacked it quite hard for a bit and it didn’t blink. But I’m more concerned about the large battery mod I made, copying josh, when it comes to connection issues. As I had to solder together the battery wires with extensions (not my best work) and then crimp and put on the connectors. But I’m pretty sure I’ve checked and double checked all that.
So far since starting this thread I’ve not had a single restart. The one big change I’ve done is to complete the sudo fwupdtool upgrade with an external keyboard attached as the pocket keyboard didn’t recover after update the other tries and I had to do a hard reset (switch on the side). But an important detail: I haven’t had time to use it much this week either. It did survive over the night with max keyboard brightness (red) and locked screen (swaylock) plugged in to a charger though.
small update from me:
I screwed down the board yesterday, a few mins ago i had a brown out again with no external device attached except my charger. system was in idle, battery at 100%
Just out of curiosity. Can it be an SSD-related matter?
@R1ck (and others who have this issue at the moment) could you make a ticket on https://support.mnt.re (Problem with Pocket Reform → Other) and reference this discussion here, I would like to send you a charger board v2 and some new battery cells to see if that fixes the issue for you.
Just another datapoint:
I got a replacement v1 charger board and am running with this pristine board. Had a brownout today while charging with gnome, emacs, external display - so possibly not related to about to fail charger boards?
Is this with the same batteries as before?
I have larger batteries (8Ah each), and after the installation in order to re-adjust the controller I (as josch advised) turned off the software protection for the low charge. It is off since then. Yet, initially it was like “turn it off if the battery is low”.
Eventually I can see warnings from the OS like “the battery is below 6%” for 2-3 seconds, while the LED display demonstrates the real battery level (far more than 6%).
Maybe it is somehow connected to the issue we are discussing?
This was the same batteries as before. LCD v2.
Update: we reproduced the issue today on @holo_memory’s Pocket Reform on battery, even if the charger board and the batteries seemed visually fine. I was able to trigger it reliably with a combination of high brightnesses, CPU, GPU and SSD disk load (with WD SSD). It was fine at first until around 60% battery, and in the end it was reproducible by just high brightness + searching something in the GNOME Apps overview/search, which probably caused a CPU, GPU and disk spike all at the same time.
We then immediately swapped his charger board v1 for a charger board v2 prototype board without changing anything else, and the issue was no longer reproducible even if I tried quite hard. The new charger board’s gauge estimated the remaining charge at 15% while it was 30% with v1, I believe this is just because it hadn’t calibrated yet, though.
In any case, seeing the direct effect of changing the charger board version and nothing else was very clear.
I also think that the issue on AC power is still caused by the charger board, even if that’s unintuitive. It’s because all power, even from AC, has to pass through the charger chip, and if it has a hiccup, power is cut momentarily.
We set up a batch of charger board v2s, and the main components will arrive at JLC in around 2 weeks, and then we can kick off the batch production and mail these to anyone who experiences the issue, free under warranty and we’ll also offer the boards at lowest possible cost in our shop in parallel.
Woa, you people really are the best at taking care of your customers! I recently fixed my big laptop (8 years old, broken screen), but whenever it goes beyond my repair skills, the replacement will surely be from mnt reform!
update from me: after i got home yesterday i wanted to start pocket reform and the keyboard didn’t turn on. (weird. i wonder what was going on) i used the standby switch to powercycle and it was active again. i wasn’t satisfied with the gnome configurations, so i went back to sway and had my usual setup for watching tv shows (external monitor, mpv, keyboard default brightness, display brightness at 10% or so, USB-A mouse (with adapter), batteries at 100% and charging) after about 2 hours, pocket restarted. it’s very strange because this didn’t happen since i last posted here. so i don’t know if it’s still the same issue or a different one. (i would assume it’s still the same) we did some changes since my last post:
i don’t know if @minute installed another update though. anyway, the new charger board v2 didn’t fix my initial issue, sadly.
While we know how to fix the main battery/charger board related power issue, I’m curious if the remaining issue (hard to reproduce, but I’ll set up a pocket farm to hopefully make the problem surface more quickly) is related to CPU or GPU frequency scaling. If you’re affected by the issue, could you try the following:
sudo apt install tuned tuned-ppd
sudo tuned-adm profile throughput-performance
That will lock the CPUs at highest possible frequency instead of constantly changing (until thermal throttling forces the frequency lower).
Optimally, for this test, you can also lock the GPU to a frequency (for example here, the maximum):
sudo su
cd /sys/class/devfreq/fb000000.gpu
echo userspace > governor
echo 1000000000 > min_freq
Does the issue still occur then, and if yes more often or roughly the same frequency (no change)?
I wrote a quick data logger tool that you can run to help me get closer to the reason(s) for the reboots (apart from charger module issues). Please run this tool in a terminal at the start of your session and just keep it running in the background. It will log a lot of data to a timestamp log in /var/log/reform-crashland. This can be 100s of MB per day, so feel free to clean out uninteresting logs. I wanted to cover a lot of area at the beginng until we see more specific hints of what conditions influence the problem.
Installation:
sudo apt install sysstat drm-info
wget -O reform-crashland "https://source.mnt.re/reform/reform-tools/-/raw/crashland/bin/reform-crashland?inline=false"
chmod 755 reform-crashland
sudo mv reform-crashland /usr/local/bin/reform-crashland
Running:
sudo /usr/local/bin/reform-crashland
If you are someone who experiences spurios reboots on RK3588 that don’t seem low battery related, I’d be grateful if you could run this tool and, if a crash reboot occurs, send me the latest logfile that was generated. You’re also welcome to upload it here in the thread, but please check if any personal data ended up in it before (in “top” process names for example). Or you can email the log to lukas at mntre dot com.
I will run this, and will report back! Thanks so much for the effort in solving this issue @minute! 
Ok! I’m currently participating in the pocket farm!
I get this:
ERROR: Can’t get value of subfeature in0_input: Can’t read
Is that important for your data collection?
Another thing I don’t know if related, it might, as it also involves a brown-out: when I reboot it waits a bit to stop all the services, and then says “watchdog did not stop” and has a brown-out to reboot. No idea if this is somewhat related but I wanted to mention.
Shouldn’t be a problem.
We just discovered a strange thing: with some u-boot/TFA versions, arm64 cryptography instructions are missing. You can check the output of “cat /proc/cpuinfo” to see if it includes “aes pmull sha1 sha2” or not. If not, you should update u-boot like this:
sudo reform-flash-uboot emmc
It’s unlikely that this affects the reset issues, but a significant difference between my test system and some others. In any case, missing AES could cause slower disk operations when using disk encryption.