Re: [PATCH v7 5/6] rockchip: doc: add back to ROM section

[Quentin Schulz <quentin.schulz@cherry.de>]

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 <quentin.schulz@cherry.de> wrote:
>>
>> Hi Johan,
>>
>> Please incorporate Jonas's comments made on the v6:
>> https://lore.kernel.org/u-boot/1e47521b-c3f2-4c62-86eb-51866b911968@kwiboo.se/
>>
>> 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 <jbx6244@gmail.com>
>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>> ---
>>>
>>> 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