Hi Alexey,

On 7/13/2026 12:02 PM, Alexey Charkov wrote:
> This aims to upstream Jonas Karlman's long-standing patch series fixing
> the boot from SDMMC on RK3576, which requires a hotfix to the boot ROM's
> global state area before any SDMMC reads are initiated to avoid clobbing
> the ROM's state and breaking the boot process.
> 
> The preparatory patches for the image tools are submitted verbatim from
> Jonas' version, while the "boost" code doing the actual hotfix is
> converted from using a pre-built tiny binary to a from-source build using
> the existing U-Boot build system.

Thanks for re-sending this, this should likely have been labeled v2 and
there are review comments on my original series [1] that should be
addressed.

I was planning on sending a v2 of the preparation series now that we
once again have an active maintainer for Rockchip, but unsure how to
handle that now :-)

[1] https://patch.msgid.link/[email protected]/

> From-source build also alleviates the problem with parallel out-of-tree
> builds, which could skip the pre-built binary but which always pick up the
> from-source build.

My original intent was to try and embed the generated code to possible
match what I did to support emmc boot with the amlimage format, see [2].

Building the boost blob ourself the way you do here seem like a better
option, however we should probably change to include the blob and
setting the required parameters using binman instead.

For e.g. RK3572 and RK3538 there may be dboot/rboot blobs needed prior
to ddr-init, along with choosing to load SPL to a different DRAM address.
So we should prepare for being able to pass parameters, how I do not yet
know, possible using a new rkimage etype in binman.

[2] https://patch.msgid.link/[email protected]/

> Tested on a number of RK3576 boards, including the Rockchip RK3576 EVB1,
> ArmSoM Sige5, FriendlyElec NanoPi M5, Luckfox Omni3576, Radxa Rock 4D and
> Flipper One, all of which fail to boot from SDMMC without this series but
> boot fine with it applied.

It has always been possible to boot from an SD-card if you compose an
alternative idbloader.img using boost+ddr blobs and u-boot-spl.bin from
U-Boot using the boot_merger tool from rkbin and write that and u-boot.itb
to the SD-card.

> I've also done some JTAG debugging of the boot process, and the single-
> word write which the boost binary performs to the SRAM at 0x3ff803b0
> appears to be relocating the base of the SDMMC IDMAC DMA descriptor buffer
> to the top of SRAM, which prevents large multi-page SDMMC reads from
> overrunning adjacent ROM state and thus breaking the boot process. A
> comment has been added to the boost code to reflect this.

Awesome, thanks for this information :-)

Regards,
Jonas

> 
> Signed-off-by: Alexey Charkov <[email protected]>
> ---
> Jonas Karlman (7):
>       rockchip: mkimage: Split size_and_off and size_and_nimage
>       rockchip: mkimage: Print image information for all embedded images
>       rockchip: mkimage: Print boot0 and boot1 parameters
>       rockchip: mkimage: Add option to change image offset alignment
>       rockchip: mkimage: Add support for up to 4 input files
>       rockchip: mkimage: Add option for image load address and flag
>       rockchip: mkimage: Add rk3576 align and sd-card workaround
> 
>  arch/arm/mach-rockchip/rk3576/Makefile       |  10 +
>  arch/arm/mach-rockchip/rk3576/rk3576-boost.c |  31 +++
>  tools/rkcommon.c                             | 290 
> +++++++++++++++++----------
>  tools/rkcommon.h                             |   2 -
>  4 files changed, 228 insertions(+), 105 deletions(-)
> ---
> base-commit: 6741b0dfb41dc82a284ab1cff4c58af6ef2f3f9c
> change-id: 20260713-rk3576-boost-58a5f47e74e3
> 
> Best regards,
> --  
> Alexey Charkov <[email protected]>
> 

Reply via email to