[PATCH v1] bootm: teach handle_decomp_error() about the noload decompression buffer

Simon Glass sjg at chromium.org
Thu Jul 9 21:14:50 CEST 2026


Hi Aristo,

On 2026-07-05T14:51:22, Aristo Chen <aristo.chen at canonical.com> wrote:
> bootm: teach handle_decomp_error() about the noload decompression buffer
>
> For a compressed kernel_noload image, bootm_load_os() allocates a
> per-image decompression buffer of ALIGN(image_len * 8, SZ_1M) rather
> than the global CONFIG_SYS_BOOTM_LEN. When decompression fails on that
> path, handle_decomp_error() still prints
>
>     Image too large: increase CONFIG_SYS_BOOTM_LEN
>
> which is misleading: increasing CONFIG_SYS_BOOTM_LEN does not help
> because the smaller per-image buffer is the actual bound. Commit
> 2ff26c1e378d ("bootm: fix overflow of the noload kernel decompression
> buffer") worked around this by printing a follow-up note right after
> handle_decomp_error() returned, but the boot log then reads as two
> contradictory sentences.
>
> Introduce enum bootm_decomp_limit and pass it into
> handle_decomp_error() so the helper picks the right message in one
> place. For the noload path it now prints
>
> [...]
>
> boot/bootm.c | 39 ++++++++++++++++++++++++++++++---------
>  1 file changed, 30 insertions(+), 9 deletions(-)

> diff --git a/boot/bootm.c b/boot/bootm.c
> @@ -598,10 +614,15 @@ static int handle_decomp_error(int comp_type, size_t uncomp_size,
>               return BOOTM_ERR_UNIMPLEMENTED;
>
>       if ((comp_type == IH_COMP_GZIP && ret == Z_BUF_ERROR) ||
> -         uncomp_size >= buf_size)
> -             printf("Image too large: increase CONFIG_SYS_BOOTM_LEN\n");
> -     else
> +         uncomp_size >= buf_size) {
> +             if (limit == BOOTM_DECOMP_LIMIT_PER_IMAGE)
> +                     printf("Image too large for the kernel_noload buffer (%#lx bytes)\n",
> +                            (ulong)buf_size);

You could use %#zx and drop the ulong cast, since buf_size is size_t

Also, the enum is generic (BOOTM_DECOMP_LIMIT_PER_IMAGE) but the
message hard-codes kernel_noload. That's accurate today, but a generic
message (e.g. "Image too large for per-image decompression buffer")
would stay in sync if another caller appears. Either way is fine.

Reviewed-by: Simon Glass <sjg at chromium.org>

Regards,
Simon


More information about the U-Boot mailing list