Hi Alexey, On 2026-07-13T10:02:41, Alexey Charkov <[email protected]> wrote:
> 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 picking this up - building the stub from source is the right direction and the JTAG analysis of what the magic write actually does is great. I share Jonas' concern about the final patch baking a source-tree path and SoC-specific load addresses into mkimage (more on that patch). Since the image-packaging logic for Rockchip is already moving towards binman, I suspect the right long-term home for this is a binman entry type (or an extension of the existing mkimage etype) which passes the stub and its parameters explicitly. Failing that, the stub path and load addresses should at least be provided on the mkimage command line so the tool stays generic. What do you think? > Jonas Karlman (7): > rockchip: mkimage: Split size_and_off and size_and_nimage This series reworks a lot of the image-layout logic in the tool (header sizing, offset alignment, up to four embedded images) but there is no test coverage for the Rockchip image format, so regressions in the existing v1/v2 formats would go unnoticed. Please can you add some tests, e.g. a pytest which builds images with one, two and four input files and checks the listing output? The new -l output added in patches 2 and 3 makes this easy to do. A note in doc/board/rockchip/rockchip.rst about the RK3576 SD-card situation and the new stub would also be useful, since people currently carrying the vendor boost blob will want to know it is no longer needed. > This aims to upstream Jonas Karlman's long-standing patch series fixing > the boot from SDMMC on RK3576 OK, looking forward to the two of you getting this landed! Regards, Simon
