Hi Quentin, On Mon, Sep 21, 2026 at 7:27 PM Quentin Schulz <[email protected]> wrote: > > Hi Alexey, > > On 9/18/26 12:52 PM, Alexey Charkov wrote: > > print_decomp_msg() names the image it is about to unpack, which drags > > uimage_type[] and its strings into any phase that links image_decomp(). > > That is about 2.5KB, measured on a Rockchip RK3576 SPL, spent on one line > > of progress output in a phase built for size. > > > > Name it "image" there instead. U-Boot proper is unchanged. > > > > Would it make sense to also print the hex/dec value image type stored in > the type parameter? Considering we have: > ## Checking hash(es) for Image u-boot ... sha256+ OK > Uncompressing image to 800000 > we know which image we're trying to uncompress so maybe this isn't so > important (provided you have access to the original u-boot.itb and know > you can run mkimage -l on it).
In fact, we aren't even parsing the image type by default in SPL, except in limited cases defined by CONFIG_IS_ENABLED(FPGA) || (CONFIG_IS_ENABLED(OS_BOOT) && CONFIG_IS_ENABLED(DECOMPRESSION)), so printing the numeric type value won't be helpful most of the time. > I tried reverting only this patch in the series and I get > Uncompressing Invalid Image to 800000 > which is a bit odd since we actually should have a known type instead of > invalid image (standalone program is what we have for U-Boot proper). So > it wouldn't actually help to print the hex/dec value and would even be > more confusing to the user (well, except if we fix this type being of > unexpected value). It would have been "Unknown Image", had I not been overzealous replacing the initialization values in patch 5, as mentioned in that patch's thread. IMO "Unknown Image" carries about the same descriptive power as "image" alone though. Best regards, Alexey
