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

[Jonas Karlman]

Hi Simon,

On 2025-04-04 00:30, Simon Glass wrote:
> Hi Jonas,
> 
> On Fri, 4 Apr 2025 at 09:57, Jonas Karlman <jonas at 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.

Regards,
Jonas

> 
> do_booti() calls bootm_run_states() without the BOOTM_STATE_LOADOS
> state in the mask, so I wonder why (as it seems) bootm_run_states() is
> calling bootm_load_os()*
> 
> So from what I can tell it is loading the OS once in booti_start() and
> again in bootm_load_os(). If so, I don't know why.
> 
> In any case, honouring CONFIG_SYS_BOOTM_LEN for loaded files is the
> correct behaviour, so yes, I think we should increase that limit. For
> now, we could add the check to the booti command, since it might be a
> while before I get back to refactoring/removing that (now-unneeded)
> code.
> 
> Regards,
> Simon
> 
> * It should be possible to remove booti_start() now that bootm
> supports booti decompression properly, but I left that for another
> day.
> 
>>
>> Regards,
>> Jonas
>>