Hi Alexey, On 7/13/2026 2:47 PM, Alexey Charkov wrote: > On Mon, Jul 13, 2026 at 2:44 PM Jonas Karlman <[email protected]> wrote: >> >> 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]/ > > Oops, here I am again, missing things already reviewed on the ML. My > changes, though, are only concerning the very last patch in the series > (which hadn't been sent out back then), and I haven't touched the > other code in any way.
Hehe, no worries, I was planning on trying to get an updated version (without rk3576 parts) out later this week. As stated on IRC [3], I was planing to first focus on TPL refactoring and a few RK35xx clock fixes. > Would you like to give the mkimage-related patches another go then, > and then we bring in the boost.bin changes on top? I'm also happy to > help incorporating Quentin's feedback if you'd like, although I don't > know if that enters "too many cooks" territory :) I can try to get the mkimage related patches another go later this week. Have some other improvements/fixes I noticed while playing around with other SoCs, or that where not ready when initial series was sent. However, I think the boost patch you included (without mkimage parts) could be sent as a standalone patch. The resulting .bin-file should work as a replacement for the vendor boost blob. [3] https://libera.catirclogs.org/linux-rockchip/2026-07-10#40172912; > >>> 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. > > Having everything in binman sounds neat, but on the other hand the > current mkimage-based approach seems to work fine, so why fix what's > not (yet?) broken? :) > > For RK3576 that would mostly mean "reimplement mkimage in binman", > from what I can see, as we still need to give the boot ROM the > combined idbloader header it's built for and which mkimage produces. Initially I was more thinking of wrapping the mkimage etype and passing some rkcommon specific parameters to mkimage, not sure that is even possible. Using hardcoded parameters in rkcommon seem like a bad idea and something we should avoid if possible, especially now that other SoCs also may need similar workarounds or parameters/flags. I am torn, will try to fix remaining review remarks in a v2 of the mkimage preparation series. How we should best handle parameters will likely be a discussion for later or be a follow up on that. At least that was my plan for a v2, skip the last patch in v1 and only focus on the cleanup and adding support for using 4 KiB blocks, together with some local patches that e.g. add support for reading signed images. > >> [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. > > Rockchip's boost.bin blob does exactly the same thing as your > assembly, plus setting UFS power mode parameters - and that's it. > Power mode parameters at pre-TPL stage don't make any meaningful > difference in any of the workloads I tried, so I'm not even sure why > that part is included. So yes, using their blob and their tool should > work too, but that doesn't count in the context of mainline IMO :) I was more thinking something like a RK3576MINIALL-mmc.ini with [CHIP_NAME] NAME=RK3576 [VERSION] MAJOR=1 MINOR=100 [CODE471_OPTION] NUM=2 Path1=arch/arm/mach-rockchip/rk3576/rk3576-boost.bin Path2=mkimage-in-simple-bin.mkimage-rockchip-tpl Sleep=1 [CODE472_OPTION] NUM=1 Path1=mkimage-in-simple-bin.mkimage-u-boot-spl [LOADER_OPTION] NUM=3 LOADER1=FlashBoost LOADER2=FlashData LOADER3=FlashBoot FlashBoost=arch/arm/mach-rockchip/rk3576/rk3576-boost.bin FlashData=mkimage-in-simple-bin.mkimage-rockchip-tpl FlashBoot=mkimage-in-simple-bin.mkimage-u-boot-spl [DOWNLOADBOOT1_PARAM] LOAD_ADDR=0x3FFC0000 FLAG=0x0 [LOADER1_PARAM] LOAD_ADDR=0x3FFC0000 FLAG=0x0 [LOADER2_PARAM] LOAD_ADDR=0x3FF81000 FLAG=0x0 [OUTPUT] PATH=u-boot-rockchip-loader.bin IDB_PATH=u-boot-rockchip-idblock.bin [SYSTEM] NEWIDB=true ALIGN=8 [FLAG] CREATE_IDB=true 471_RC4_OFF=true RC4_OFF=true CRC_OFF=true and then running something like ../rkbin/tools/boot_merger RK3576MINIALL-mmc.ini after a successful build of a rk3576 defconfig target to get a u-boot-rockchip-idblock.bin that should be in correct format as idbloader.img. This idblock.bin and u-boot.itb could be used together instead of u-boot-rockchip.bin to have working SD-card boot. This still uses vendor tools and the vendor TPL blob but remaining is mainline U-Boot. At least an option until mkimage parts are ready. Regards, Jonas > >>> 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 :-) > > Cutting down magic in this world, one memory store instruction at a time :-D > > Best regards, > Alexey
