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

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.

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

[1] https://docs.flipper.net/one/hardware/rk3576/boot-rom#normal-boot-from-persistent-storage

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

Best regards,
Alexey