On Fri, Apr 04, 2025 at 11:32:12PM +0200, Jonas Karlman wrote: > Hi Simon, > > On 2025-04-04 00:30, Simon Glass wrote: > > Hi Jonas, > > > > On Fri, 4 Apr 2025 at 09:57, Jonas Karlman <jo...@kwiboo.se> wrote: > >> > >> Hi Tom and Simon, > >> > >> On 2025-03-19 00:21, Tom Rini wrote: > >>> On Wed, 05 Mar 2025 17:24:54 -0700, Simon Glass wrote: > >>> > >>>> This series includes some patches related to allowing read_all() to be > >>>> used with the extlinux / PXE bootmeths. > >>>> > >>>> These patches were split out from the stb4 series, since it will need to > >>>> have additional patches for LWIP, to avoid breaking PXE booting when > >>>> LWIP is used. > >>>> > >>>> [...] > >>> > >>> Applied to u-boot/next, thanks! > >> > >> This series broke booting a compressed arm64 defconfig Linux kernel > >> (without module loading) due to changes in decompression buffer length. > >> > >> My arm64 defconfig kernel (Image.gz) is ~24 MiB compressed and ~85 MiB > >> uncompressed. > >> > >> Before this series the decompression buffer was 10x the kernel_comp_size > >> and now it is instead limited by the SYS_BOOTM_LEN Kconfig symbol. > >> > >> A broken boot using current next branch: > >> > >> Retrieving file: /Image.gz > >> Retrieving file: /initramfs.cpio.gz > >> append: earlycon > >> cmd 'booti' states 1f1f addr_img '0x02080000' conf_ramdisk > >> '0x06000000:394d3c' conf_fdt '3df16350' images 000000003ffe53a0 > >> kernel data at 0x02080000, len = 0x00000000 (0) > >> load 2080000 start 2080000 len 0 ep 0 os 5 comp 1 > >> find_other type 2 os 5 > >> ## Flattened Device Tree blob at 3df16350 > >> Booting using the fdt blob at 0x3df16350 > >> Working FDT set to 3df16350 > >> load_os load 8000000 image_start 2080000 image_len 2000000 > >> Uncompressing Kernel Image to 8000000 > >> Error: inflate() returned -5 > >> Image too large: increase CONFIG_SYS_BOOTM_LEN > >> Must RESET board to recover > >> Resetting the board... > >> > >> Changing SYS_BOOTM_LEN from default 64 MiB to 128 MiB fixed the boot: > >> > >> Retrieving file: /Image.gz > >> Retrieving file: /initramfs.cpio.gz > >> append: earlycon > >> cmd 'booti' states 1f1f addr_img '0x02080000' conf_ramdisk > >> '0x06000000:394d3c' conf_fdt '3df16430' images 000000003ffe5480 > >> kernel data at 0x02080000, len = 0x00000000 (0) > >> load 2080000 start 2080000 len 0 ep 0 os 5 comp 1 > >> find_other type 2 os 5 > >> ## Flattened Device Tree blob at 3df16430 > >> Booting using the fdt blob at 0x3df16430 > >> Working FDT set to 3df16430 > >> load_os load 8000000 image_start 2080000 image_len 2000000 > >> Uncompressing Kernel Image to 8000000 > >> kernel loaded at 0x08000000, end = 0x0d3b5a00 > >> Loading Ramdisk to 3cb51000, end 3cee5d3c ... OK > >> Loading Device Tree to 000000003cb3f000, end 000000003cb509df ... OK > >> Working FDT set to 3cb3f000 > >> > >> Starting kernel ... > >> > >> Do we need to increase the default SYS_BOOTM_LEN for ARM64 now? > > > > Are you using the 'booti' command? Can you post a bit more console > > output or a script here as it isn't clear what boot command you are > > using? For now I'm going to assume booti > > Above was using an extlinux.conf with bootstd, not using the booti cmd. > > Use of booti cmd is not affected as it continue to use a 10x multiple > of the kernel_comp_size env var for buffer size. > > The change this series introduced was instead of the 10x multiple of > kernel_comp_size now use SYS_BOOTM_LEN for buffer size (320 vs 32 MiB). > > And because cmd/booti.c was not converted there is now two different > handling of this decompression buffer size. > > If the change to now use SYS_BOOTM_LEN was intended this need to be > changed as it has mostly been irrelevant for booting Linux on AArch64 > boards prior to this series.
We need to clean things up such that the path which is using 10x multiple (and we lmb_alloc an area iirc) is used in all cases. -- Tom
signature.asc
Description: PGP signature
