Summary
I am running NextUI v6.10.0 on my TrimUI Brick. On the Brick, the CPU is pinned at 2.0GHz at the main menu and restored to 2.0GHz on every return from a game. This runs counter to the documented "dynamic CPU speed scaling keeps your device cool" feature and results in unnecessary surface heat during normal use.
Root Cause
The Brick kernel only compiles in the userspace cpufreq governor. available_governors does not exist as a sysfs node. This means the only effective lever is scaling_setspeed. Both tg5040.sh and launch.sh set CPU_SPEED_PERF=2000000 and write it to scaling_setspeed at boot and on every minarch exit, pinning the device at full clock regardless of load.
Observed Frequencies
- Menu (stock): 2000000
- Menu (after changing
CPU_SPEED_PERF to 1008000 in both files): 408000
- NES gameplay with
minarch_cpu_speed = Auto: 1608000
- NES gameplay with
minarch_cpu_speed = Medium: 1200000
The menu drop from 2000000 to 408000 is a significant thermal improvement for a device that spends most of its time at the menu or in light emulation.
Suggested Fix
Lower the default CPU_SPEED_PERF value in launch.sh to something appropriate for menu use (816000 or 1008000 seems reasonable), and consider whether the post-minarch restore to CPU_SPEED_PERF is necessary or whether a lower idle frequency would serve better there too.
Additionally, minarch_cpu_speed = Auto selecting 1608000 for NES on the Brick may be worth reviewing since Medium (1200000) appears to run NES without issue in initial (admittedly limited) testing.
Happy to provide any additional data if helpful. Thanks for all the hard work here, all!
Summary
I am running NextUI v6.10.0 on my TrimUI Brick. On the Brick, the CPU is pinned at 2.0GHz at the main menu and restored to 2.0GHz on every return from a game. This runs counter to the documented "dynamic CPU speed scaling keeps your device cool" feature and results in unnecessary surface heat during normal use.
Root Cause
The Brick kernel only compiles in the
userspacecpufreq governor.available_governorsdoes not exist as a sysfs node. This means the only effective lever isscaling_setspeed. Bothtg5040.shandlaunch.shsetCPU_SPEED_PERF=2000000and write it toscaling_setspeedat boot and on every minarch exit, pinning the device at full clock regardless of load.Observed Frequencies
CPU_SPEED_PERFto 1008000 in both files): 408000minarch_cpu_speed = Auto: 1608000minarch_cpu_speed = Medium: 1200000The menu drop from 2000000 to 408000 is a significant thermal improvement for a device that spends most of its time at the menu or in light emulation.
Suggested Fix
Lower the default
CPU_SPEED_PERFvalue inlaunch.shto something appropriate for menu use (816000 or 1008000 seems reasonable), and consider whether the post-minarch restore toCPU_SPEED_PERFis necessary or whether a lower idle frequency would serve better there too.Additionally,
minarch_cpu_speed = Autoselecting 1608000 for NES on the Brick may be worth reviewing since Medium (1200000) appears to run NES without issue in initial (admittedly limited) testing.Happy to provide any additional data if helpful. Thanks for all the hard work here, all!