A low CPU frequency while an ArmSoM board is idle can be normal. Linux may adjust frequency as demand changes. To investigate a performance complaint, record the workload and frequency policy together instead of judging a single idle reading.
1. Record the environment
Note the board model, image filename, cooling setup, power supply and application. On the board, run:
uname -r
top
Observe the workload that actually feels slow, then press q to leave top. Record whether the problem happens immediately or only after sustained use.
ArmSoM’s system-information guide introduces process monitoring and frequency inspection.
2. Inspect the CPUFreq policies
On a kernel exposing CPUFreq through sysfs, run:
for policy in /sys/devices/system/cpu/cpufreq/policy*; do
[ -d "$policy" ] || continue
printf '\n%s\n' "$policy"
for field in related_cpus scaling_driver scaling_governor scaling_cur_freq scaling_min_freq scaling_max_freq; do
if [ -r "$policy/$field" ]; then
printf '%s: ' "$field"
cat "$policy/$field"
fi
done
done
Policies can cover multiple CPUs, so do not assume one independent setting per core. The frequency values above are in kHz. Depending on the driver, scaling_cur_freq may represent the last requested frequency rather than an exact hardware measurement. See the Linux CPUFreq documentation.
If no policies appear, report that result with the kernel version. It does not mean the CPU runs at zero frequency.
3. Compare idle and active readings
Run the policy check once at idle and again while reproducing the slow operation. Compare the governor, limits and affected CPU group. A single reading can miss short bursts, and a configured maximum is not a guarantee that every workload will continuously reach it.
Also record whether the operation is waiting for storage, network input, or another component. CPU frequency alone cannot explain every slow application.
4. Share enough detail for a comparison
Provide the exact workload or command, elapsed time, policy output, kernel version, and cooling and power details. Label any timings as measurements from your own setup.
The forum already has an RK3588 fixed-frequency discussion. Before changing policies, establish a baseline and check whether that older procedure applies to your current kernel and board.
The output in this guide is deliberately left to your device: no benchmark score or performance gain is implied.