CM4: Getting Started

DevTerm
1

[WIP] Getting Started Guide for the DevTerm RPi Compute Module 4

For all of us who are a happy sys admin of our very own DevTerm with the CM4, this beginner guide summarises all additions and best practices from the community.

1. Install “DevTerm CM4 OS 64-bit”

2. Patch boot to use on-board antenna

  • add at the bottom of /boot/config.txt:
    dtparam=ant2 Forum Thread

3. Update OS
3.1 Fix DevTerm Thermal Printer Update error as suggested in this Forum Thread

sudo apt update
sudo apt remove devterm-thermal-printer-cups  devterm-thermal-printer -y
sudo apt install -y devterm-thermal-printer-cups  devterm-thermal-printer 
sudo reboot

4. Install Gearbox update
5. Install keyboard firmware update

6. Install improved fan controller

Additional cool stuff:

WIP = Work in Progress
lastly updated: 2023-04-09

9 Likes
2

Hey guys,
I’m working on this guide for myself and all new users.
From reading the forum I now, that many geniuses here developed/improved many tools and I try to summarise it to build something like an up-to-date best practice guide.

It’s a work in progress and I definitely don’t have a full overview. So, if you have infos on any of the listed things or have any other tips and links, that would be great.

3

Can you help me to understand the difference/current status with respect to the CM4 of these 3 threads:

What would be a good fit for the CM4 guide?

1 Like
4

The keyboard’s firmware is not related to the DevTerm’s main processor, so it’s not CM4 specific (or CM3, A04, A06, etc). The keyboard works just like any USB peripheral (you can plug it into your computer and use it).

I personally think the trackball is janky because of the firmware. I tried fixing it but got limited results. I intended to release my custom firmware as a binary, but I got busy with other things.

Please try reading my topic and feel free to contact me via DMs if you have any questions :slight_smile:

1 Like
5

There’s an antenna fix that seems to be needed.

2 Likes
6

Also, there is apparently no need for the python-based fan controller that also ships with A06, A04, R1. For Raspberry Pi CM4 it sounds like the built in fan control can be used, but the devterm package should be removed, and settings adjusted as mentioned here:

Edit: I tried this on mine, and while doing the test to toggle the gpio pin and check if the fan works, does work, the fan doesn’t seem to turn on when the CPU gets hotter than the value I set in the pi config. Not sure what, if anything, I’ve done wrong.

EDIT:
Maybe I just needed to reboot, but the fan actually does seem to be working now, when it gets above the temperature threshold.

1 Like
7

Overclocking is also an option. I’ve tried over_voltage=6 and arm_freq=2000 as described here, and it seems stable. Under heavy load (100% on all 4 CPUs) it never got above 74°C and I didn’t see any throttling.

https://www.jeffgeerling.com/blog/2020/overclocking-raspberry-pi-compute-module-4

2 Likes
8

Uh nice!
I will add it to the post!
Do you by any chance have the ability to measure the power consumption and compare it?

I would be interested to have a “performance switch”, where we can tune down the CPU to preserve power for longer battery or over clock for extra boost.

9

I don’t have a way to measure power consumption in terms of voltage, but I guess I could find some kind of battery monitor/logger and run it on battery until it runs dry. Doing that with different CPU frequency settings would provide a comparison. My batteries are not new, but they should be in pretty good shape and fairly representative.

Any suggestions for a battery monitor/logger, and I suppose something to run to keep the system busy until it drains the battery? :slight_smile:

Ok, for logging, I think I can use the excellent work done here. I just checked and the script works on devterm as well as gameshell, so I should be able to log voltage, battery capacity, and current over time. I just need to come up with something that taxes the CPU and drains power fairly quickly. Suggestions welcome!

1 Like
10

The antenna fix made it worse for me.
Wi-Fi reception was bad before, and this made it worse :smile:
I deleted the line again.

Can anyone confirm my experience?

1 Like
11

Measuring power draw is a constant headache for me.
I really which we can have a good tool for it.

Looking foreword for your results!

12

Just to clarify, your wifi still works, it’s just the reception that got worse with the “fix”, right? Mine doesn’t show up at all, which I suspect is due to the printer driver (which also doesn’t work). So I’m hoping when I roll it back and stop it from updating it might fix the wifi too, but I’ll also try toggling that fix off and see if it helps.

Right now, I’ve been running a battery drain test with the CPU at 2GHz. I used that script I linked to above, and set it to log every 5 minutes. I turned the screen brightness all the way up, and I ran a freshly compiled version of the latest MAME emulating Space Lords (just in the attract mode – I wasn’t playing). I turned the volume down in MAME shortly after starting the test though, as it was starting to get annoying. The only other thing I had plugged in was a USB ethernet dongle, and I had a putty terminal connected with btop running so I could easily check how it was doing. Anyhow, while it won’t be perfect, I figure this will be a reproducible and pretty similar test to run with different CPU frequencies. It just drained the battery a few minutes ago, so I’ll charge up and prepare for a second run with different CPU frequency settings.

It lasted slightly longer than 2 hours. Seemed like it ended pretty abruptly, going from 20% battery left to no power at the end, in less than 5 minutes.

I’m curious to see how it does at the default CPU frequency. It’s possible my batteries are starting to get old and not work as well too. I expected it to go longer than 2 hours, but it doesn’t mean much until I have something to compare.

Here’s the raw data. The format that script produces is voltage (which in my case ranged from 4.2 to 3.4), battery % capacity (100 → 20), battery current (I think the first reading might have still been plugged into USB power, oops!), and the time (which ran from 6:05pm to 8:15pm). My /boot/config.txt contained:

over_voltage=6
arm_freq=2000

script collected data:

4222000 100     3000    18:05
3942000 98      1956000 18:10
3920000 96      1970000 18:15
3908000 95      1973000 18:20
3902000 94      1990000 18:25
3898000 93      1968000 18:30
3886000 93      2004000 18:35
3880000 92      1984000 18:40
3867000 90      2006000 18:45
3850000 89      2016000 18:50
3830000 86      2034000 18:55
3804000 84      2070000 19:00
3780000 80      2052000 19:05
3756000 77      2080000 19:10
3733000 73      2096000 19:15
3714000 70      2097000 19:20
3694000 67      2112000 19:25
3678000 64      2133000 19:30
3661000 62      2103000 19:35
3643000 58      2161000 19:40
3623000 54      2151000 19:45
3604000 50      2162000 19:50
3582000 46      2180000 19:55
3559000 39      2176000 20:00
3536000 33      2213000 20:05
3513000 27      2183000 20:10
3488000 20      2210000 20:15

image
image805×600 13.1 KB

13

Regarding the Wi-Fi, yes that is correct.

For the rest:
You are amazing!
This is super super cool!
And a nice benchmark procedure indeed.

The battery drop off can be explained by the overall status of the battery, as you said.
The cell can’t hold the necessary voltage on the lower end as well as on the upper end, which is why it plummeted increasingly.

If we want to be truly scientific I guess this can impact the benchmark negatively, since a clocked down benchmark won’t stress the BAT that much and thereby might not trigger this “landslide” that much, but that’s very much nitpicking.
I have fresh batteries. Maybe I will try to verify your results.

1 Like
14

So, overclocked, I had 130 minutes of power. And at the default speed I had 170 minutes. I’m considering trying an underclocked speed too, I guess 1.0 Ghz? Let me know, and I can use the same setup.

Here’s a chart for both overclocked (2.0) and default (1.5). I’m not sure why there is a faster dropoff at the start for the default speed. The only difference in my test was I turned the volume down immediately for the default, and I waited 5-10min for the overclock because I didn’t realize how annoying it was going to be. :slight_smile: Otherwise, the task should have been the same.

image
image876×600 19.9 KB

And here’s the data. I converted the timestamps to minutes, for graphing purposes.

speed,voltage,battery,current,time
2.0GHz,4222000,100,3000,0
2.0GHz,3942000,98,1956000,5
2.0GHz,3920000,96,1970000,10
2.0GHz,3908000,95,1973000,15
2.0GHz,3902000,94,1990000,20
2.0GHz,3898000,93,1968000,25
2.0GHz,3886000,93,2004000,30
2.0GHz,3880000,92,1984000,35
2.0GHz,3867000,90,2006000,40
2.0GHz,3850000,89,2016000,45
2.0GHz,3830000,86,2034000,50
2.0GHz,3804000,84,2070000,55
2.0GHz,3780000,80,2052000,60
2.0GHz,3756000,77,2080000,65
2.0GHz,3733000,73,2096000,70
2.0GHz,3714000,70,2097000,75
2.0GHz,3694000,67,2112000,80
2.0GHz,3678000,64,2133000,85
2.0GHz,3661000,62,2103000,90
2.0GHz,3643000,58,2161000,95
2.0GHz,3623000,54,2151000,100
2.0GHz,3604000,50,2162000,105
2.0GHz,3582000,46,2180000,110
2.0GHz,3559000,39,2176000,115
2.0GHz,3536000,33,2213000,120
2.0GHz,3513000,27,2183000,125
2.0GHz,3488000,20,2210000,130
1.5GHz,4218000,100,8000,0
1.5GHz,3978000,92,1584000,5
1.5GHz,3955000,89,1651000,10
1.5GHz,3939000,88,1696000,15
1.5GHz,3932000,87,1697000,20
1.5GHz,3925000,86,1680000,25
1.5GHz,3919000,86,1702000,30
1.5GHz,3912000,85,1713000,35
1.5GHz,3906000,84,1712000,40
1.5GHz,3897000,83,1716000,45
1.5GHz,3885000,81,1712000,50
1.5GHz,3866000,79,1718000,55
1.5GHz,3845000,75,1747000,60
1.5GHz,3828000,72,1746000,65
1.5GHz,3806000,69,1750000,70
1.5GHz,3785000,65,1762000,75
1.5GHz,3765000,62,1777000,80
1.5GHz,3747000,58,1793000,85
1.5GHz,3727000,54,1824000,90
1.5GHz,3712000,51,1814000,95
1.5GHz,3697000,48,1799000,100
1.5GHz,3681000,45,1829000,105
1.5GHz,3667000,40,1824000,110
1.5GHz,3648000,35,1844000,115
1.5GHz,3633000,30,1826000,120
1.5GHz,3614000,25,1846000,125
1.5GHz,3593000,20,1875000,130
1.5GHz,3572000,16,1874000,135
1.5GHz,3554000,14,1890000,140
1.5GHz,3535000,12,1892000,145
1.5GHz,3512000,8,1904000,150
1.5GHz,3492000,6,1924000,155
1.5GHz,3474000,5,1943000,160
1.5GHz,3458000,4,1920000,165
1.5GHz,3439000,3,1954000,170
1 Like
15

So cool!

1 GHz is good.
I also would be interested in 800 MHz.
But I have no idea where the limits are reached of the RPi

16

wut cm4 has no cpufreq support?

17

I’m not sure what you mean. But yeah, my A06 core will change frequency on the fly based on the scheduler, and I can check it and verify with command line tools, or see it in htop/btop, etc.

But with the stock OS install, before I changed anything, on CM4 it always holds steady at whatever frequency it’s set at. So by default it was always showing 1.5Ghz, even if it was idling or not doing much. When I made the change mentioned above to test 2Ghz, it remained at that, regardless of what it was doing.

@jan-peter, regarding 1GHz or 800MHz, I looked around online and I didn’t see any solid or trustworthy examples of anyone actually underclocking their Pi 4 by changing arm_freq and over_voltage as everyone seems to do (and as I did) for overclocking. So far, this is the best info I’ve seen, but it seems rather trial and error driven and I’m not sure if changing the values could lead to damage, or other weirdness if things don’t match up properly. The weird thing is, they appear to keep the default arm_freq of 1.5 and just change a bunch of other frequency settings. It also appears that the GPU pulls a decent amount of power, perhaps even when it’s not being used much. So perhaps for CPU intensive tasks that aren’t dependent on graphics, my previous test runs might have lasted longer if I had tweaked the GPU settings (and maybe some of these other things?)

https://forums.raspberrypi.com/viewtopic.php?p=1712952&sid=43ac0013f9914c73b7be0368fde77221#p1712952

I felt more confident with overclocking, as there were plenty of examples of other people doing it online, and a consistent way to accomplish it. I’m much less confident about this. If anyone knows how to properly underclock and optimize battery life on a Pi 4, I’m open to suggestions, hopefully with proven examples. :wink: I might still try these settings I linked to, especially since it sounds like it worked, and they were able to still run web browsers with youtube, etc. So their device was still usable. Hmm.

1 Like
18

wow thanks for the heads up, I’ll see if I can fix that when my uConsole+cm4 arrives.

19

I ran the same test using the values I found at that link above. Note that CPU speed was still the default 1.5Ghz though. I’m not sure what the appropriate undervoltage value would be to go along with 1GHz, or 800MHz, so I decided not to risk it. (If I knew for sure it wouldn’t hurt anything, I guess I could use these values with 1000 or 800 and see how it goes.)

The values I added to config.txt were:

core_freq_min=150
gpu_freq_min=150
h264_freq_min=150
isp_freq_min=150
v3d_freq_min=150
over_voltage=-2
over_voltage_min=-4
over_voltage_sdram=-1

The result was an additional 20min of power beyond the defaults. So the results of the three tests (running MAME, Space Lords, with full display brightness, wifi off, and a USB ethernet dongle, with btop running in a putty terminal):
2.0GHz at 2 hours 10 minutes
1.5GHz at 2 hours 50 minutes (default)
1.5GHz with adjustments at 3 hours 10 minutes

I wish I had brand new batteries to test on, as I’m sure all these test would have gone longer. But hopefully they at least scaled appropriately since I was using the same batteries.

image
image986×600 26.9 KB

1 Like
20

That’s just so cool!

Maybe we can come up with a good, solid test script or something else easily reproduce able and I can run it on my set up with fresh batteries.
I sadly can’t find any details about my batteries, other than their name: samsung sdi 8 151 LJ1T