On Mon, 2021-08-30 at 13:46 -0400, Tom Rini wrote: > 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 <ma...@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.
Exactly. > 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? Well, I am not saying we should NOT increase CONFIG_SYS_BOOTM_LEN. I am just cautioning that this may cause further issue resp. might require further adjustments down the road.