On Mon, Sep 21, 2026 at 6:42 PM Quentin Schulz <[email protected]> wrote: > > Hi Alexey, > > On 9/21/26 4:27 PM, Alexey Charkov wrote: > > Hi Quentin, > > > > On Mon, Sep 21, 2026 at 5:14 PM Quentin Schulz <[email protected]> > > wrote: > >> > >> Hi Alexey, > >> > >> On 9/18/26 12:52 PM, Alexey Charkov wrote: > >>> SPL knows about multiple compression algorithms, but only two are > >>> hand-rolled into the simple FIT loading code, in spite of a nice ready > >>> made helper already being available right there. > >>> > >>> Generalize the compressed FIT handling code to accept any compression > >>> algorithm compiled into the SPL, and fix up the SPL_ZSTD linkage which > >>> requires xxhash in the SPL but which was absent to date. > >>> > >>> While here, also extend binman to support passing a compression level via > >>> its image templates, which helps squeeze additional ~15% size savings in > >>> my testing with Zstd level 19 without impacting decompression speed. > >>> > >>> This is done with Rockchip RK3576 in mind, so a small Rockchip image > >>> template refactor is included. > >>> > >>> CI passes all green: > >>> https://git.u-boot-project.org/u-boot/contributors/alchark/u-boot/-/pipelines/1319 > >>> > >> > >> Doesn't work on my PX30 Ringneck for any of the supported compression > >> algorithms (didn't check lzma as I'm daily driving Fedora and it doesn't > >> have lzma_alone binary). > >> > >> Doesn't work on my RK3399 Puma as well (couldn't check zstd, SPL was too > >> big and overlapped with U-Boot FIT, note that Puma is special in that it > >> only allows (256-32)KiB for SPL, due to backward compatibility with > >> older versions of U-Boot that had U-Boot FIT located at offset 256KiB). > > > > That's interesting. Does it work without my series though? With Gzip. > > > > It also doesn't work without your series. > > > If it doesn't, the first thing I'd check is overlapping memory regions > > for the compressed data and the ultimate load address of any of the > > binaries involved. > > > > Would you mind sharing your resulting FIT structure that binman > > produced for the failing boards, including all the ATF segments? > > > > BL31 for both come from upstream TF-A, seemingly from v2.13.0 (according > to strings build/rk3399/release/bl31/bl31.elf | grep -E '^v'). > > ringneck-px30_defconfig + CONFIG_ROCKCHIP_UBOOT_COMP_GZIP=y > > $ mkimage -l build/ringneck/u-boot.itb > Truncated file > FIT description: FIT image for U-Boot with bl31 (TF-A) > Created: Mon Sep 21 17:29:13 2026 > Image 0 (u-boot) > Description: U-Boot > Created: Mon Sep 21 17:29:13 2026 > Type: Standalone Program > Compression: gzip compressed > Data Size: 315656 Bytes = 308.26 KiB = 0.30 MiB > Architecture: AArch64 > Load Address: 0x00800000 > Entry Point: 0x00800000
Right, so your decompression buffer at SYS_LOAD_ADDR is only 0x800 bytes behind the uncompressed U-Boot load address, so the decompression output almost immediately overwrites its own source and fails. Can you please try setting CONFIG_SYS_LOAD_ADDR to something further up? It just needs to clear the TF-A and the uncompressed U-Boot proper region, so the kernel/fdt/ramdisk addresses U-Boot itself uses shouldn't matter, as the SPL's decompression buffer would have already been discarded by the time those are used. Best regards, Alexey
