[PATCH 3/3] imx8qm_mek: Increase CONFIG_SYS_BOOTM_LEN to 64MB

[Tom Rini]

On Mon, Aug 30, 2021 at 03:05:32PM +0000, Marcel Ziswiler wrote:
> On Mon, 2021-08-30 at 14:18 +0200, Marek Vasut wrote:
> > On 8/30/21 1:11 PM, Oleksandr Suvorov wrote:
> > > On Sun, Aug 29, 2021 at 10:55 PM Marek Vasut <marex at denx.de> wrote:
> > > > 
> > > > On 8/29/21 9:39 PM, Oleksandr Suvorov wrote:
> > > > > The BSP platform LmP supports the board NXP iMX8QM MEK. The
> > > > > kernel size in LmP exceeds 32Mb. Increase the maximum size
> > > > > of an uncompressed kernel to fix the following error:
> > > > >       Uncompressing Kernel Image
> > > > >       Error: inflate() returned -5
> > > > >       Image too large: increase CONFIG_SYS_BOOTM_LEN
> > > > >       Must RESET board to recover
> > > > > 
> > > > 
> > > > Maybe we should increase the default for arm64 instead ? 8 MiB is too small.
> > > 
> > > I completely agree if NXP doesn't have objections.
> > > @Peng Fan Do you mind?
> > 
> > Increase it for all of arm64 , or all of U-Boot even. This has nothing 
> > to do with NXP.
> 
> In general, I agree. However, in practice this can have devastating effects on stuff as discussed here:
> 
> https://marc.info/?l=u-boot&m=162999598824381

In that yes, if we allow for larger kernels to be loaded, we also need
to ensure platforms use sane relocation values, it also needs to be
considered.  But even if we have CONFIG_SYS_BOOTM_LEN set large, unless
we then also disable device tree / initrd relocation, we don't have a
silent problem?

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