Rockchip RK3399 SOC is very slow

Wed Dec 17 18:02:28 CET 2025

Hi Victor,

On 12/17/25 5:09 PM, Victor Krawiec wrote:
> [You don't often get email from victor.krawiec at arturia.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello U-Boot community,
> 
> I recently moved from Rockchip's vendor U-Boot to mainline U-Boot. I noticed that the boot time on RK3399 is very slow compared to the vendor version. It takes around 8 seconds from power up to kernel start while the vendor one takes 2 seconds.
> 
> In README.rockchip "Future work" section it is written "Run CPU at full speed (code exists but we only see ~60 DMIPS maximum)" which implies that the current mainline implementation lacks CPU configuration to make it fast.
> 

Is Rockchip's fork actually running at a different frequency? I will bet 
that not.

> I'm very interested in a fix for this problem. The vendor Rockchip tree is based on U-Boot 2017 and its getting more and more difficult to use it.
> 
> Therefore I have some questions to start working on this topic:
> - Could anyone point me in which part of the code to start digging for a potential fix ? Is it related to the PMIC or another subsystem ?

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).

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.

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...

> - Has anyone tried to fix this problem and if yes why was the development abandoned ?
> 

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.

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?

Cheers,
Quentin

[2025-12-17 17:31:42.073] U-Boot TPL 2026.01-rc4-00036-g5ae0219650f7 
(Dec 17 2025 - 17:25:03)
[2025-12-17 17:31:42.173] Channel 0: DDR3, 666MHz
[2025-12-17 17:31:42.173] BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 
Size=2048MB
[2025-12-17 17:31:42.178] Channel 1: DDR3, 666MHz
[2025-12-17 17:31:42.178] BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 
Size=2048MB
[2025-12-17 17:31:42.184] 256B stride
[2025-12-17 17:31:42.199] Trying to boot from BOOTROM
[2025-12-17 17:31:42.199] Returning to boot ROM...
[2025-12-17 17:31:42.341]
[2025-12-17 17:31:42.341] U-Boot SPL 2026.01-rc4-00036-g5ae0219650f7 
(Dec 17 2025 - 17:25:03 +0100)
[2025-12-17 17:31:42.346] Trying to boot from MMC2
[2025-12-17 17:31:42.396] ## Checking hash(es) for config config-1 ... OK
[2025-12-17 17:31:42.416] ## Checking hash(es) for Image atf-1 ... 
sha256+ OK
[2025-12-17 17:31:42.512] ## Checking hash(es) for Image u-boot ... 
sha256+ OK
[2025-12-17 17:31:42.531] ## Checking hash(es) for Image fdt-1 ... 
sha256+ OK
[2025-12-17 17:31:42.547] ## Checking hash(es) for Image atf-2 ... 
sha256+ OK
[2025-12-17 17:31:42.565] ## Checking hash(es) for Image atf-3 ... 
sha256+ OK
[2025-12-17 17:31:42.587] ## Checking hash(es) for Image atf-4 ... 
sha256+ OK
[2025-12-17 17:31:42.598] load_simple_fit: Skip load 'atf-5': image size 
is 0!
[2025-12-17 17:31:42.761] NOTICE:  BL31: 
v2.13.0(release):v2.13.0-1145-g6251d6ed1
[2025-12-17 17:31:42.761] NOTICE:  BL31: Built : 10:54:48, Nov 11 2025
[2025-12-17 17:31:44.136]
[2025-12-17 17:31:44.136]
[2025-12-17 17:31:44.136] U-Boot 2026.01-rc4-00036-g5ae0219650f7 (Dec 17 
2025 - 17:25:03 +0100)
[2025-12-17 17:31:44.139]
[2025-12-17 17:31:44.239] SoC: Rockchip rk3399
[2025-12-17 17:31:44.239] Reset cause: POR
[2025-12-17 17:31:44.239] Model: Theobroma Systems RK3399-Q7 SoM
[2025-12-17 17:31:44.245] DRAM:  4 GiB (total 3.9 GiB)
[2025-12-17 17:31:44.336] PMIC:  RK808
[2025-12-17 17:31:44.358] Core:  311 devices, 31 uclasses, devicetree: 
separate
[2025-12-17 17:31:44.358] MMC:   mmc at fe320000: 1, mmc at fe330000: 0
[2025-12-17 17:31:44.374] Loading Environment from MMC... Reading from 
MMC(1)... OK
[2025-12-17 17:31:44.648] In:    serial
[2025-12-17 17:31:44.648] Out:   serial
[2025-12-17 17:31:44.648] Err:   serial
[2025-12-17 17:31:44.648] Model: Theobroma Systems RK3399-Q7 SoM
[2025-12-17 17:31:44.652] Net:   eth0: ethernet at fe300000
[2025-12-17 17:31:44.738] Hit any key to stop autoboot:  0
[2025-12-17 17:31:44.738] Scanning for bootflows in all bootdevs
[2025-12-17 17:31:44.744] Seq  Method       State   Uclass    Part  Name 
                      Filename
[2025-12-17 17:31:44.749] ---  -----------  ------  --------  ---- 
------------------------  ----------------
[2025-12-17 17:31:44.760] Scanning global bootmeth 'efi_mgr':
[2025-12-17 17:31:44.760] Cannot persist EFI variables without system 
partition
[2025-12-17 17:31:44.978]   0  efi_mgr      ready   (none)       0  <NULL>
[2025-12-17 17:31:44.984] ** Booting bootflow '<NULL>' with efi_mgr
[2025-12-17 17:31:44.999] Loading Boot0000 'mmc 1' failed
[2025-12-17 17:31:44.999] Loading Boot0001 'mmc 0' failed
[2025-12-17 17:31:45.004] EFI boot manager: Cannot load any image
[2025-12-17 17:31:45.004] Boot failed (err=-14)
[2025-12-17 17:31:45.010] Scanning bootdev 'mmc at fe320000.bootdev':
[2025-12-17 17:31:45.650]   1  extlinux     ready   mmc          1 
mmc at fe320000.bootdev.part /boot/extlinux/extlinux.conf
[2025-12-17 17:31:45.655] ** Booting bootflow 
'mmc at fe320000.bootdev.part_1' with extlinux
[2025-12-17 17:31:45.660] 1:    rk3399-puma-haikou
[2025-12-17 17:31:45.660] Retrieving file: /boot/Image
[2025-12-17 17:31:47.068] append: root=/dev/mmcblk1p1 rw rootwait
[2025-12-17 17:31:47.068] Retrieving file: 
/boot/rk3399-puma-haikou-video-demo.dtb
[2025-12-17 17:31:47.088] ## Flattened Device Tree blob at 12000000
[2025-12-17 17:31:47.088]    Booting using the fdt blob at 0x12000000
[2025-12-17 17:31:47.095] Working FDT set to 12000000
[2025-12-17 17:31:47.100]    Loading Device Tree to 00000000f4ebe000, 
end 00000000f4ed1065 ... OK
[2025-12-17 17:31:47.105] Working FDT set to f4ebe000
[2025-12-17 17:31:47.119]
[2025-12-17 17:31:47.119] Starting kernel ...
[2025-12-17 17:31:47.119]
[2025-12-17 17:31:47.900] [    0.000000] Booting Linux on physical CPU 
0x0000000000 [0x410fd034]