Rockchip RK3399 SOC is very slow

[Victor Krawiec]

Hello Quentin,

Thanks for your answer.

On 12/17/25 18:02, Quentin Schulz wrote: 
> Is Rockchip's fork actually running at a different frequency? I will bet that not.

Thanks to the code you pointed to me in clk_rk3399.c I was able to check in Rockchip's fork. They are using 816MHz. So it is a bit faster but it does not explain such a difference.

> We default to 600MHz for both the LITTLE and big clusters on RK3399 as far as I remember. I believe it's because it's the default frequency of the cores and so, if we have booted into U-Boot it means the power is stable enough and at the proper clock frequency. Can't confirm, it was a long time ago I looked at that. c.f. drivers/clk/rockchip/clk_rk3399.c rk3399_configure_cpu_l and rk3399_configure_cpu_b and specifically PLL_DIVISORS in apll_b_600_cfg and apll_l_600_cfg. One of the issues we have is that this driver is the same for all variants of RK3399 and they don't all have the same OPPs (OP1, RK3399K, RK3399T, ...) except for the default which has worked nicely until now it seems.
> 
> The issue is that you need to configure the regulator for the LITTLE and/or big clusters to what is required for the higher frequency to work reliably. We don't have cpufreq support in U-Boot so it'll essentially be stuck to one OPP at this time. If for some reason you're running at that OPP for a long time and you don't have appropriate cooling, we also do not have thermal devfreq for the CPU which means it won't slow down to not burn itself. Therefore, only the HW thermal limit will kill the CPU (usually around 115°C if I remember correctly). When you change the frequency of a clock used by other devices, you need to make sure the other ones aren't modified in a way it breaks other devices (which is something the clock subsystem hopefully should be doing for you, but I don't know if it's as advanced as in the Linux kernel).
 
I was afraid messing with CPU frequency would be too complicated and risky. Thanks for confirming this.

> If you want something fast, you can also look into falcon boot, which skips U-Boot proper entirely and loads a FIT from SPL with the Linux kernel (you also need TF-A in it). I haven't done this as it limits what you can do with the board and we're selling SoM with BSP, not final products so we don't know how it'll be used, better have something casting a wider net and have less to support customers.

I will definitely look into this. I knew about falcon boot but I did not use it because one of my goal was also to display a splashcreen. We make music instruments so having direct feedback on the screen at power up is nice. But anyway since the splashcreen appears after 7 seconds using U-Boot proper I might try falcon and display the splashscreen in Linux.

> You can check also if you have enabled everything that makes your devices go fast enough. If you're using eMMC, does it support HS200/HS400/HS400-ES? If yes, did you enable support in U-Boot for it? In the Device Tree? Same for SD card with SDR-104, etc...

I am using eMMC with HS400-ES. "mmc info" displays the correct settings but I will double check the configuration.

> On RK3399 Puma, with master, it takes slightly more than 5 seconds to jump into the kernel by loading everything from SD card (so, typically slower than eMMC), see the log at the end of the mail. I have not optimized the defconfig for speed right now. Note that I'm using baudrate 115200 which is much slower than Rockchip's typical default of 1500000, so it probably is at least a few hundreds of ms faster with that baudrate.

I could probably reduce the boot time with some optimisation. I already saved few hundreads of milliseconds removing CONFIG_NET.
But 5 seconds is still 3 seconds more than the vendor fork. I really wonder how to explain such a difference, since the CPU frequency is not entirely to blame. And on the vendor fork I'm not optimizing anything.

> You can see from the logs that BL31 takes 1.5 seconds to jump back to U-Boot proper... that's something you need to optimize in TF-A directly. I guess you can disable bootflow/distroboot and avoid a bunch of device probing and configuration.
> 
> You can disable what you don't need and optimize away. We have CONFIG_BOOTSTAGE + CONFIG_CMD_BOOSTAGE that may help you figuring out what is taking the most time I believe?
> 
> There are easier steps to take than go play with higher CPU OPPs right now I think, so start with that or identify places where we can improve?

Thanks a lot for all the leads. I'll keep you updated on the results.

Best,
Victor