Hi Alexey, On 2026-09-18T10:52:27, Alexey Charkov <[email protected]> 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. The approach looks right to me. Do you have buildman size numbers for a board which enables only SPL_GZIP with SPL_LOAD_FIT? Until now the image_decomp() call was dropped at compile time on those boards, so they pick up that function and its messages for the first time. I suspect the growth is small, with the first patch helping, but please can you put the numbers in the cover letter? > 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. The tests don't quite match this. Nothing in the series actually runs zstd_decompress() in SPL, so the green CI run cannot tell us whether the heap is big enough there. See my comments on patches 8 and 9. A gzip case would be worthwhile too, since that path changes from calling gunzip() directly to going through image_decomp() with a different output limit. > This is done with Rockchip RK3576 in mind, so a small Rockchip image > template refactor is included. Quentin's failures on PX30 and RK3399 come from the staging buffer at CONFIG_SYS_LOAD_ADDR overlapping the load address of U-Boot proper, e.g. ringneck-px30 has it only 0x800 above the text base (as you say below). That predates your series, but the last patch now offers the choice on every Rockchip board, and on quite a few of them the result is an inflate error with no hint as to the cause. I think the series should include a patch which makes the loader detect that the staging region overlaps the destination and report it clearly, even if that can only be done once the decompressed size is known. What do you think? Regards, Simon
