Hi Alexey,
On 8/20/26 12:40 PM, Alexey Charkov wrote:
Hi Quentin,
On Wed, Aug 19, 2026 at 4:49 PM Quentin Schulz <[email protected]> wrote:
Hi Johan,
Please incorporate Jonas's comments made on the v6:
https://lore.kernel.org/u-boot/[email protected]/
This also applies to patches 2 and 4's content and commit titles/logs. I
won't repeat his review here.
On 8/15/26 3:08 PM, Johan Jonker wrote:
Add a back to ROM section to rockchip.rst
Correct Kconfig text.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
---
Changed V7:
Move under a 'Boot flow' heading
Remove "Some"
---
arch/arm/mach-rockchip/Kconfig | 16 ++++++++--------
doc/board/rockchip/rockchip.rst | 11 +++++++++++
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 1a2e7847c9e7..c1dbcce1e27c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -600,26 +600,26 @@ config ROCKCHIP_USB_UART
SoCs will enable this routing as a debug measure.
config SPL_ROCKCHIP_BACK_TO_BROM
- bool "SPL returns to bootrom"
+ bool "SPL returns to boot ROM"
default y if ROCKCHIP_RK3036
select ROCKCHIP_BROM_HELPER
select SPL_BOOTROM_SUPPORT
depends on SPL
help
- Rockchip SoCs have ability to load SPL & U-Boot binary. If enabled,
- SPL will return to the boot rom, which will then load the U-Boot
- binary to keep going on.
+ Rockchip SoCs have the ability to load a second loader binary
If I'm not mistaken, it can go back to BROM more than once? I vaguely
recall the maximum supported number of images in the rk header to be 4
from a discussion we had with Jonas but cannot find a source anymore :/
That's right, the RKNS image can have up to 4 entries. I've been
digging into RK3576 boot ROM quirks and can confirm from its behavior
that it checks for <= 4 when loading. I've also written up a separate
doc [1] on the behavior of the RK3576 specific ROM version, but I
don't know how well that generalizes to other SoC versions.
I think we need to split the docs between aarch32 and aarch64 at least.
I'm wondering whether we should have SoC-specific docs as well. We can
avoid docs duplication by making use of literalinclude directive.
I don't know if we should generalize the BootROM part as it's likely
going to be SoC-specific. E.g. RK3576 is the only (or one of very few)
Rockchip SoCs that has UFS support. It's also part of the RK35xx
subfamily that reads the SARADC channel 0 at boot to decide on which
boot media to try booting from. I'm assuming the secure boot part of it
may also be different. RK3399, PX30 and RK3588 all behave differently in
that regard so it wouldn't be far-fetched that SoCs in the same family
may also have different secure boot implementations.
Another interesting part that I discovered there is that the ROM looks
for the image header at multiple offsets into each storage device.
This can potentially enable failsafe fallbacks to guard against a
failed write or a corrupted image (e.g. write known-good copies into
higher-numbered slots, and only then write the fresh idbloader.img at
sector 64).
Yeah, this has been known for a few SoCs already. Barebox for example
uses this knowledge to do exactly what you suggested:
https://elixir.bootlin.com/barebox/v2026.07.0/source/arch/arm/mach-rockchip/bbu.c#L19
SPI on RK3399 for example looks at offset 0 and 64 (I know, because I
messed up a few times and flashed my image at offset 64 instead of (my)
expected offset 64 and it still booted TPL (and then broke because
U-Boot proper wasn't at the expected location IIRC).
I'm unsure whether the offsets are stable across SoCs.
It'd be nice to have a dump of the BootROM of all supported SoCs and
then get info from that, but that's something that's rarely done (and
likely even less so publicly shared).
[1]
https://docs.flipper.net/one/hardware/rk3576/boot-rom#normal-boot-from-persistent-storage
Thanks for sharing, I'm sure this will come in handy at some point :)
Maybe we should reword this to "have the ability to go back after SPL to
BootROM and have it load and execute the next binary in the image
(typically U-Boot proper)"?
+ after the SPL phase. If enabled, SPL will return to the boot ROM,
+ which will then load and execute the U-Boot binary.
config TPL_ROCKCHIP_BACK_TO_BROM
- bool "TPL returns to bootrom"
+ bool "TPL returns to boot ROM"
default y
select ROCKCHIP_BROM_HELPER if !ROCKCHIP_RK3066
select TPL_BOOTROM_SUPPORT
depends on TPL
help
- Rockchip SoCs have ability to load SPL & U-Boot binary. If enabled,
- SPL will return to the boot rom, which will then load the U-Boot
- binary to keep going on.
+ Rockchip SoCs have the ability to load a second loader binary
+ after the TPL phase. If enabled, TPL will return to the boot ROM,
+ which will then load and execute a SPL binary.
Maybe we should reword this to "have the ability to go back after TPL to
BootROM and have it load and execute the next binary in the image
(typically U-Boot SPL)"?
config ROCKCHIP_COMMON_BOARD
bool "Rockchip common board file"
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 5e16e860bfd5..d5945e805ba8 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -560,5 +560,16 @@ config-flash.ini:
PATH=RK30xxLoader_uboot.bin
+Boot flow
+---------
+
+Back to ROM
+^^^^^^^^^^^
+
+Rockchip SoCs have the ability to load a second loader binary.
+If enabled, the TPL/SPL code will return to the boot ROM, which will then
+load and execute a SPL or U-Boot binary.
Maybe we should reword this to "have the ability to go, after a binary's
been already loaded and executed, back to BootROM and have it load and
execute the next binary in the image (typically SPL/U-Boot proper)".
On RK3576 in particular, both the boost.bin (which fixes SD card boot)
and the DDR init (the closed-source TPL) return to the boot ROM, and
then the boot ROM loads the SPL (and optionally its payload) into RAM
and executes it. So "a second loader binary" sounds too narrow. I
would say something like:
Rockchip SoCs have the ability to return control to the boot ROM after
any loaded binary has completed execution. In this case the boot ROM
loads and executes the next binary in the image, which for different
SoC versions can be the DRAM trainer, the SPL, or any other payload.
I don't like the "different SoC versions" part as it isn't necessarily
specific to the SoC as far as I understood. It depends on what's next in
the image. If you're returning from SPL, the next image is likely going
to be proper. From TPL, likely SPL but could be VPL as well (though
nothing does that at the moment). With the SD boost stuff for RK3576,
and dboot/rboot for some newer SoCs, likely TPL from what I understood.
I wouldn't mention the U-Boot proper in the same row, as it normally
expects an FDT to work with, which the boot ROM won't provide (that's
the SPL's job).
On Rockchip, we have a u-boot.itb as after-SPL stage, which contains
TF-A, optionally OP-TEE OS, U-Boot proper (possibly compressed) and
device tree(s). I don't remember for sure which device tree is passed to
TF-A (as it's SPL loading and jumping to it, and SPL has a different FDT
than proper) but I think it's proper's as we read the device tree back
to insert in the kernel's FDT U-Boot's reserved memory nodes for at
least OP-TEE OS, which are inserted by OP-TEE OS in the FDT passed by
TF-A (passed by SPL).
I wouldn't focus too much on SPL_ROCKCHIP_BACK_TO_BROM as we only have
four boards selecting it: rock_defconfig (via a select in
ROCKCHIP_RK3188), phycore-rk3288_defconfig, popmetal-rk3288_defconfig
and rock2_defconfig. All rather ancient and I own none of them.
I would just omit U-Boot proper being loaded by BootROM as those boards
haven't seen any activity in the last few years aside from the switch to
OF_UPSTREAM Johan did. I'm assuming any new board will use
TPL_ROCKCHIP_BACK_TO_BROM so we should focus on documenting that.
Cheers,
Quentin
