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

[Jonas Karlman]

Hi Tom,

On 2025-04-03 23:56, Tom Rini wrote:
> 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?
> 

The commit b13408021d36 ("boot: pxe: Use bootm_...() functions where
possible") contains the change from using current do_booti() from
cmd/booti.c to use the bootm based booti_run().

do_booti() from cmd/booti.c was not migrated to use the new booti_run()
and thus continue to use a 10x multiple of the kernel_comp_size env var
as the size for decompression buffer.

However the bootm based booti_run() instead use SYS_BOOTM_LEN as the
size for decompression buffer, so this is a change for extlinux boot
that should not affect when the booti cmd in a boot script.

Additionally the booti cmd should probably have been converted to use
the bootm base booti_run() in this series. As-is there is two different
handing for booti in next.

Regards,
Jonas