🚀 Developer Update: Increasing Clock Rates for Performance Gains on the XU MINI M

Hey everyone!

I’ve been working hard on a project that’s all about pushing hardware performance to the next level for the XU Mini M. It's a nice little distraction for me just before I go on holiday, I have a soft spot for mini handhelds. ❤️

I’m focusing on increasing the clock rates on the Rockchip RK3562 based system . For those who aren’t familiar with this, clock rates essentially control how fast your device's processor works. By increasing these rates, we can unlock better performance—but it’s not without its challenges.

The device shipped with a firmware and kernel based on the Anbernic 351v, which means that clocks speeds were limited to what that device uses. In addition to this, we have no kernel sources, so we can't simply build our own kernel to fix these speed issues.

🎯 What I’m Trying to Achieve

My goal is to increase the clock rates on the device by modifying the kernel code directly. More specifically, I’m targeting the rockchip_adjust_power_scale & rockchip_pll_clk_scale_to_rate functions.

These function calculates the clock rate for the system’s Phase-Locked Loop (PLL), which is responsible for stabilizing and scaling the clock frequency. If we can successfully adjust the value returned by this function, we can effectively overclock the system, leading to performance improvements in CPU-heavy tasks.

I started with a simple idea: increase the returned clock rate by modifying the device tree to add extra frequencies to the cpu0-opp-table. However, I quickly realized that this would require some low-level modification of the system's kernel, the modification of the dtb file was not enough.

🛠️ What I’ve Done So Far

• Reverse Engineering the Kernel with Ghidra: I began by decompiling the kernel using Ghidra. This gave me access to the assembly code for the functions. From here, I could see that the function retrieves the current clock rate from a memory address and returns it directly. It's not without its challenges, disassembled code is really difficult to read, and doesn't retain much, if any, of the original variables and function names from source.

• Modified rockchip_pll_clk_scale_to_rate: We remove some checks for unsupported OPP entries. This is what allowed me to unlock 1.6GHz on the CPU, 900MHz on the GPU, and 1GHz on the memory.

  Before:

After:

• Updated the device tree: Added the appropriate entries to the CPU, GPU, MEM OPP tables, adjusting frequencies where required.

  

• Adjusted analog sticks: The stick defaults had a high deadzone value and was prone to cardinal snapping. This is now reduced.

⚠️ What Hasn’t Worked

• Inserting New Instructions: Ghidra’s patching tools are limited, and I couldn’t insert new assembly instructions into the kernel. This means that more complex calculations (like multiplying the clock rate by a percentage) are difficult to implement directly.

• Further Scaling: Scaling beyond 1.6Ghz CPU speed, I am still trying to figure out where the actual CLK values are defined in the kernel, so we can start tackling this.

🔍 Next Steps

• Go on holiday! I'll be back soon.

• Once back, I'll start tackling the remaining speed issues, but we're in a much better place now.

• Start porting GammaOS Core to this device once the clock speed issues are sorted.

💡 Conclusion

While this project has been challenging, I’m excited by the progress so far. Overclocking is a delicate process, and every small gain brings us closer to unlocking the full potential of our hardware. I’ll keep you updated on my progress, and I hope to have a more refined solution soon.

My work so far has been shared with the community, and you'll see this in the PlumOS custom firmware: https://github.com/game-de-it/plumOS

Thank you for your support, and stay tuned for more updates!