This post is for those who wonder how the different SoMs supported by MNT compare against each other in term of how much power they draw. This is not a post about “this is the battery runtime for workload X”. I wanted to help people with deciding whether they should switch their SoM if they are concerned about the battery runtime of their unit after switching out the CPU. Any comparison of power draw between two SoMs requires an identical setup for each tested SoM. Since I’m in the privileged position of having most of the SoMs supported by MNT at home, it was long on my TODO list to perform this comparison. I’m unfortunately unable to compare with the Raspberry Pi CM4.
Test setup
To perform these tests, I tried to create a setup based on motherboard 3.0 with the least amount of external influence as possible. Since keyboard, trackball, display, SSD and wifi are random power hogs, they were all disconnected during my tests. This will make the batteries last insanely long but it was not my goal to test the battery runtime of a complete setup but to compare the power draw of different SoMs against each other. If you want numbers for a specific setup, anybody in the community can give you real-world numbers. For these tests we assume: the remaining hardware (like the LPC itself) is only a small and constant consumer.
Keep in mind that even after unplugging nearly everything, the tests are still not really “fair”. For example, you cannot unplug the wifi/bt module from A311D. The results are likely still only a ballpark estimate.
Tests were performed with a minimal system image containing the latest packages but without any GUI packages using the --quick option. Nearly no user-space processes are running in the background. The only running processes are: systemd, cron, dbus, network-manager, wpa_supplicant, login, agetty, sshd and bash. I did not try to tweak any power saving features in software because the goal was not to squeeze as much juice out as possible but to provide a mostly equal test-bed.
To measure power draw, I measured how long the eight 2200 mAh cells lasted for each experiment. I could’ve measured power draw from AC but I thought that providing my results in “battery runtime” rather than “Watts” would make it possible to draw conclusions more directly. The hope is also that running this “measurement” for effectively half a day each would result in less random fluctuations than a measurement of consumed Wh over a much shorter timeframe. This does of course assume that the battery cells do not significantly degrade in their capacity over the course of the tests.
I only performed each test once. I live in a small household and it’s not possible to hog the living room table for as much time as it would need to do more rigorous testing.
I used my Pocket Reform (thank you @WickedShell 
) to log the data. Logging on the device directly would not allow to reliably record the last few measurements before the unit shuts off due to power loss. I would’ve liked to collect the data via serial to avoid spending power on both the ethernet hardware as well as the networking stack in software. Unfortunately it turns out that the Pocket Reform is able to charge the batteries of the classic Reform via USB-C and that would of course significantly skew the runtime measurements.
For each experiment, I ran the following script over SSH and redirected the output to a file on the Pocket:
while sleep 10; do
printf "%s %s %s %s %s\n" \
"$(date +%s)" \
"$(cat /sys/devices/virtual/thermal/thermal_zone0/temp)" \
"$(cat /sys/bus/spi/drivers/reform2_lpc/spi1.0/power_supply/BAT0/charge_now)" \
"$(cat /sys/bus/spi/drivers/reform2_lpc/spi1.0/power_supply/BAT0/voltage_now)" \
"$(cat /sys/bus/spi/drivers/reform2_lpc/spi1.0/cells)"
done
Unfortunately, the output of /cells is buggy. Fix here. Unfortunately, the output of /charge_now is unreliable as well. Attempts at making it better here. Luckily, the interesting value is behind /voltage_now.
The script is also logs the temperature but there is no sense in comparing that because a different heatsink was used each time and some tests (A311D and RK3588) were even performed without any heatsink. I logged the temperature mainly to make sure that temperatures would not rise to a level where the CPU would throttled itself. This happens for example at 85 °C for RK3588.
Another problem I found during my tests is that LS1028A with kernels after 6.8 fail to init eMMC and SD-card. U-Boot manages but the kernel fails. This needs investigation but for that reason I performed the tests for LS1028A with kernel 6.8 instead of using the latest system image.
Each experiment was run twice. Once without any load and once with maximum load, simulated by the stress utility with the -c argument set to the number of physical cores.
Results
Overall ten tests were performed. Two test for each of the five SoMs I have. One test with minimum load and one test with maximum load.
You can find the raw data as well as the R script for the plots shown below here: Johannes Schauer Marin Rodrigues / reform-2025-som-comparison · GitLab
Above graph plots the total runtime in hours for each SoM for maximum load on the left and for minimum load on the right.
This graph shows the same information as the graph before it but the data is now arranged by SoM and not grouped by the tested scenario.
For completeness, here are the discharge voltage curves:
I am unable to explain the outliers in the data for a311d.
Lastly, I understand that the runtimes are completely unrealistic and can only be achieved by removing keyboard, trackball, display, SSD and wifi. To give an idea how much of the battery life is consumed by the remaining components, I also measured the runtime for RK3588 under minimum load with keyboard and trackball and then with keyboard, trackball and display. Again, no special measures were performed in software to reduce the energy consumption of either of these components. This means that the keyboard V4 has the purple backlight on and the screen is on with default brightness showing the framebuffer console. Lets look at the results:
| Scenario | Runtime |
|---|---|
| no keyboard+trackball, no screen (the value from above) | 11.9 hours |
| keyboard+trackball but no screen | 8.1 hours |
| keyboard+trackball+screen | 4.7 hours |
This means that having keyboard and trackball attached eats up 3.8 hours of battery runtime. Probably due to the keyboard backlight. I’ll leave it up to other motivated souls to investigate this further and possibly improve on the status quo. It should not be surprising that turning the screen on eats another 3.4 hours of runtime.
Conclusion
I think this shows (again) that there really is no one-size-fits-all.
RK3588 has a similar power draw compared to the others but provides an order of magnitude more raw computation speed. But if you don’t need to browse javascript-heavy websites but need a long battery runtime, then A311D is better. A311D is also for you if you want integrated bluetooth for which you need an external USB dongle with RK3588.
So you look at A311D and you like how long it makes your laptop last but then you realize that the video you want to watch with your bluetooth headphones is encoded in 60fps 1080p for which A311D is too slow to decode without significant frame drops (it works with 30fps but youtube uses 60 fps for all its 1080p content). And you have to live without one of the PCI lanes (RK3588 has some to spare).
Then you’d like to suspend your system. Sorry, neither A311D nor RK3588 can do that. Then you’d like to have display support already during u-boot. Again no dice. If you want either of this, then i.mx8mq is your SoM of choice. It’s slower than A311D but comes with a hardware video decoder so now you can watch your 1080p videos while having your kernel compile on all cores without frame drops. But then you open a web browser and dream of the raw power of RK3588 again…
You are a friend of open hardware I heard? Sorry, none of the SoMs I mentioned in this conclusion so far qualify. LS1028A does but also draws the most power, so it’s not a good option if you want to be very mobile and its CPU is again too slow for 1080p video decode in case you thought about using it as a media-center PC.
Acknowledgements
I hope this article was able to help you decide a bit better. Thanks to MNT for building this amazing platform for us! Thanks go also:
- to Debian for sponsoring my RK3588 classic Reform
- to @WickedShell for the Pocket Reform with which it was very comfortable to log and plan the test setups while my other machines were completely disassembled
- to @serpent for lending me their LS1028A while mine is still in repair with MNT
- to @doctorhoo for their i.mx8mq board
- to @grimmware for their i.mx8m+ board
- my family who endured an unusable living room table for over a week
Pictures
The photo above shows my general test setup. In the center is the unit under test (RK3588 in this case). Without any load, RK3588 apparently needs no heatsink and still does not exceed 55 °C. The only cable to the unit is the ethernet cable connected to the Pocket Reform which shows the output of the script running on the RK3588 in the center over SSH. Between classic Reform and Pocket, in the lower right corner, is a RP2040 connected to a box with four rechargable AA batteries. I used that contraption to switch the unit on even with no keyboard connected. I was asked why I would not use the keyboard to power it on and then disconnect the keyboard before starting the test but where would be the fun in that? In the top left is another classic Reform with i.MX8MQ waiting to be removed for getting tested. Besides it in a cardboard box is the LS1028A.
The photo above shows a close-up of the classic Reform case housing motherboard 3.0 and the battery packs with eight 2200 mAh LiFePO4 cells in them. The LPC connector has a cable still connected to my RP2040 (not seen in the photo). The motherboard has the LS1028A plugged into it, currently without heatsink mounted. In the background the imx8mq and a311d are waiting.
While gutting my other machines for their SoMs, I had a small panic moment when neither A311D (top left) nor i.MX8MQ (bottom right) would show anything on the display. The system would boot fine otherwise (with lots of errors in dmesg though) but display would remain dark. I managed to fix this in the end without really figuring out what the problem was. My hunch is, that I didn’t plug the DSI cable in correctly. My fingers don’t work well anymore.
The photo above has the A311D plugged into the testbed. Having no heatsink installed is no problem without load. Even without a heatsink, the temperature did not exceed 35 °C. This is reflected in the crazy runtime which the A311D was able to achieve.
Unfortunately, this did not work so well when running the A311D with maximum load. Trying to do so would let temperatures easily exceed 90 °C even with a heatsink mounted. I used active cooling in this setup which was able to keep temperatures below 55 °C. The fan is of course not powered by the Reform itself but by an external 12 V power supply. In the front-left of the photo is a random i.mx8mq, in the back one can see the LS1028A. This was the last test I performed and you can see the table became more and more messy in the process.
A rare sight above: the i.MX8M+ not in a Pocket Reform but in a motherboard 3.0 inside a classic Reform chassis. This setup worked because @minute luckily also provided a device tree for the classic Reform with this SoM. The display does not work (only backlight) with tons of errors in dmesg. Luckily, for these tests we don’t care about the display and serial worked.
