Hi Victor,
On 12/17/25 5:09 PM, Victor Krawiec wrote:
[You don't often get email from [email protected]. 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@fe320000: 1, mmc@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@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 '[email protected]':
[2025-12-17 17:31:45.650] 1 extlinux ready mmc 1
[email protected] /boot/extlinux/extlinux.conf
[2025-12-17 17:31:45.655] ** Booting bootflow
'[email protected]_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]
