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).
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).
Cheers,
Quentin
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Alexey Charkov <[email protected]>
---
boot/image.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/boot/image.c b/boot/image.c
index 185d52ba492f..a7dc69e858ad 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -416,7 +416,12 @@ void image_print_contents(const void *ptr)
static void print_decomp_msg(int comp_type, int type, bool is_xip,
ulong load)
{
- const char *name = genimg_get_type_name(type);
+ /*
+ * The image-type table and its strings cost about 2.5KB, which is a
+ * lot to spend on a progress message in a phase built for size.
+ */
+ const char *name = IS_ENABLED(CONFIG_XPL_BUILD) ? "image" :
+ genimg_get_type_name(type);
/* Shows "Loading Kernel Image" for example */
if (comp_type == IH_COMP_NONE)
