How to Fix CPU Cores Stuck at Low Frequency (Throttled on Boot) on the Radxa Dragon Q8B

Causes

Missing default thermal trip in early kernel device trees — The Dragon Q8B's SC8280XP device tree originally shipped without a fallback thermal trip point. Radxa's own kernel fix (pull request #581, "add default thermal trip") states plainly: "Without the fallback trip, cpu4-7 are throttled on boot." In practice this means the four Kryo Gold cores (and in some builds the Prime cores) can be pinned at a low frequency from the moment the board powers on, no matter the workload or temperature — a freshly booted Q8B that feels sluggish in every task is the classic symptom.
"Fake battery" power-reporting bug in the firmware/thermal stack — Radxa's kernel PR #569 ("Remove fake battery & fix core throttle") removed a battery emulation hack that was interfering with the PMIC's power and thermal accounting. When the emulated battery state confused the thermal/power governor, the SoC would refuse to raise core frequency to its 3.0 GHz Prime / 2.4 GHz Gold ceiling, so the board ran at a fraction of its rated performance even with light loads.
No heatsink or fan on a 5nm flagship SoC — The Snapdragon 8cx Gen 3 is a 29+ TOPS, 3.0 GHz octa-core part designed for laptops with active cooling. Running the Q8B bare (no heatsink) or in a sealed enclosure lets the thermal zone hit its trip point quickly; the kernel then clamps frequency to keep die temperature in check. The Q8B's 100 x 75 mm board has mounting holes for heatsinks/fans, and Radxa explicitly manages external cooling via the rsetup "Thermal governor" option.
An under-spec or failing 20V PD power adapter — The Q8B boots from a 20V USB-C PD input and Radxa recommends a 3A-or-higher 20V adapter (the Radxa PD 65W unit is the reference). A weak adapter that sags under load, a long thin USB-C cable, or a PD source stuck at a lower voltage makes the PMIC report brownout conditions, and the firmware throttles the CPU to protect the board — the cores then sit at low frequency under any sustained load.
Outdated kernel or SPI boot firmware — The thermal-trip and fake-battery fixes landed in Radxa's kernel tree after the first Q8B images shipped. If you are running the factory image from the first weeks of the Q8B launch, you may be on a kernel that predates both fixes (6.x-qcom builds before the SC8280XP Dragon patches), so the throttle-on-boot behavior persists until you update the kernel and, where needed, the SPI boot firmware.

How to Fix

Confirm the cores are actually stuck at low frequency — Log in (default credentials are radxa / radxa) and check the live frequencies of all 8 cores: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq (values are in kHz — a healthy idle Q8B should show the cores dropping to the low idle state, but under a load like stress-ng --cpu 8 the Prime cores should climb toward 3000000 and the Gold cores toward 2400000). If every core is pinned far below those numbers even under load, you are seeing the throttle-on-boot bug. Also check sensors to confirm the board isn't genuinely overheating (above ~85-90°C).
Update the kernel via rsetup (not raw apt) — Radxa's docs are explicit that apt update && apt upgrade directly "might lead to incomplete updates or system issues" on Radxa OS. Instead run sudo rsetup, choose System → System Update, and let it pull the current Radxa kernel. This is what delivers the SC8280XP Dragon fixes (default thermal trip, fake-battery removal) to your board. Reboot afterward and re-run the frequency check from step 1 — this alone resolves the throttle-on-boot behavior for most users.
Add proper cooling and set the thermal governor — Install a heatsink (the Q8B has heatsink mounting points) and, for sustained loads, a fan. Then run sudo rsetup → Hardware → Thermal governor and pick a governor that matches your cooling: power_allocator or step_wise for fan-cooled setups, or check the current governor at cat /sys/class/thermal/thermal_zone*/policy. With the fallback trip fixed in the kernel, a well-cooled Q8B should hold Prime cores near 3.0 GHz under load instead of clamping early.
Verify the power supply and cable — Use a 20V PD adapter rated 3A or higher (Radxa's PD 65W adapter is the recommended reference). Swap in a short, thick USB-C PD cable — long or thin cables drop voltage under load and trigger throttling. If you are powering the board from the DC pins instead, confirm the supply is a stable 12-20V source rated for the board's peak draw (the 8cx Gen 3 can pull 15-25W under load). Re-test the frequency ramp with stress-ng --cpu 8 while watching scaling_cur_freq.
Switch the CPU governor if the schedutil default misbehaves — Some early Q8B images shipped with the kernel unable to ramp frequencies correctly under the default schedutil governor. If cores stay low under load despite good thermals and power, switch to performance or ondemand for a test: echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor. If that restores full frequency, either keep it or apply it persistently via a systemd service — and note it in any bug report to Radxa, since a correctly working schedutil should not need this workaround.
Update the SPI boot firmware via EDL if kernel updates don't help — If the throttle persists after a kernel update and clean power/cooling checks, the SPI boot firmware may be from an early build with the power-reporting bug. Download the latest SPI Boot Firmware (BIOS) from the Dragon Q8B Resource Downloads page, enter EDL mode (hold the onboard EDL button, connect a 20V PD adapter, release the button), verify the board appears as 05c6:9008 in lsusb, and flash with the provided EDL tool. Reboot and re-test frequencies.
Contact Radxa support if the board still won't ramp up — If you are on the current kernel and SPI firmware, with a proper 65W-class 20V supply, a heatsink/fan, and the cores still pinned at low frequency under load, the PMIC or power delivery on the board itself may be faulty. Open a thread in the Dragon Q8B section of the Radxa forum (forum.radxa.com) with your kernel version (uname -r), the output of the scaling_cur_freq check under stress-ng, and the sensors output — Radxa engineers actively triage Dragon-series reports there, and hardware faults are covered under warranty.