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
