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
