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. 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 :) > > 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. > [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'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
