[PATCH v5 00/29] pxe: Precursor series for supporting read_all() in extlinux / PXE

[Tom Rini]

On Thu, Apr 03, 2025 at 10:57:24PM +0200, Jonas Karlman 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?

Ugh. I thought the decompression buffer, which we would be just lmb'ing,
was some multiple of the compressed image. Can you please bisect down to
which commit in the series broke this?

-- 
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/20250403/e1920d18/attachment.sig>