[PATCH 2/4] bootm: use CONFIG_SYS_BOOTM_LEN for IH_TYPE_KERNEL_NOLOAD decompression buffer

[Tom Rini]

On Thu, Jun 18, 2026 at 06:04:59PM +0800, Aristo Chen wrote:
> Hi Nora
> 
> On Thu, Jun 18, 2026 at 4:30 PM Nora Schiffer
> <nora.schiffer at ew.tq-group.com> wrote:
> >
> > On Wed, 2026-06-10 at 13:48 -0600, Tom Rini wrote:
> > > On Wed, Jun 10, 2026 at 11:01:23AM +0200, Nora Schiffer wrote:
> > >
> > > > CONFIG_SYS_BOOTM_LEN is passed to image_decomp(), so the same should be
> > > > used for the buffer allocation. Deriving a buffer size from the
> > > > compressed size if not possible, as the compression ratio may be
> > > > arbitrarily high for data with many repititions (for example ranges of
> > > > 0x00 or 0xff).
> > > >
> > > > Fixes: 69544c4fd8b1 ("bootm: Support kernel_noload with compression")
> > > > Signed-off-by: Nora Schiffer <nora.schiffer at ew.tq-group.com>
> > >
> > > Reviewed-by: Tom Rini <trini at konsulko.com>
> >
> >
> > Hi Tom,
> >
> > I saw you applied a different fix for the same issue to master. I think using
> > CONFIG_SYS_BOOTM_LEN is a better solution than trying to derive the buffer size
> > from the compressed size at all - isn't that pretty much what
> > CONFIG_SYS_BOOTM_LEN is for?
> 
> Previously Simon also suggested using the CONFIG_SYS_BOOTM_LEN in this
> thread(https://patchwork.ozlabs.org/project/uboot/patch/20260527150637.2850104-2-aristo.chen@canonical.com/).
> It was considered a follow-up at the moment, so maybe rebase (and keep
> the CONFIG_SYS_BOOTM_LEN) your patch on top of mine?

Yes, I took Aristo's series to the next branch (which predated Nora's
series). My only real concern right now is, certainly we must have had a
reason to not be using CONFIG_SYS_BOOTM_LEN here to start with. And
digging more, yes, we have platforms that have CONFIG_SYS_BOOTM_LEN far
larger than the malloc pool. That's why we did an estimate before. I had
missed that when I R-b'd Nora's patch.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260618/2e65ed5d/attachment.sig>