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 > <[email protected]> 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 <[email protected]> > > > > > > Reviewed-by: Tom Rini <[email protected]> > > > > > > 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/[email protected]/). > 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
signature.asc
Description: PGP signature
