On Fri, Sep 18, 2026 at 11:12:08PM +0400, Alexey Charkov wrote: > Hi Quentin, > > On Fri, Sep 18, 2026 at 9:57 PM Quentin Schulz <[email protected]> > wrote: > > > > Hi Alexey, > > > > On 9/18/26 12:52 PM, Alexey Charkov wrote: > > > The dtsi infers how to compress from whichever SPL decompressor happens > > > to be enabled, so there is no way to ask for one in particular, turning > > > a decompressor on for something else silently changes the image, and the > > > conditional has to be updated with every new algorithm. > > > > > > > Thanks, this was something of an eye-sore to me for a while already :) > > > > > Move the selection to Kconfig instead, with proper help texts and support > > > for all available compression algorithms. Each choice enables the > > > decompressor that provides it, and carries the compression level. > > > > > > Signed-off-by: Alexey Charkov <[email protected]> > > > --- > > > arch/arm/dts/rockchip-u-boot.dtsi | 16 +++----- > > > arch/arm/mach-rockchip/Kconfig | 78 > > > +++++++++++++++++++++++++++++++++++++++ > > > 2 files changed, 84 insertions(+), 10 deletions(-) > > > > > > diff --git a/arch/arm/dts/rockchip-u-boot.dtsi > > > b/arch/arm/dts/rockchip-u-boot.dtsi > > > index 4ba6a87e78ab..a72b55cec05a 100644 > > > --- a/arch/arm/dts/rockchip-u-boot.dtsi > > > +++ b/arch/arm/dts/rockchip-u-boot.dtsi > > > @@ -11,14 +11,6 @@ > > > #define FIT_ARCH "arm" > > > #endif > > > > > > -#if defined(CONFIG_SPL_GZIP) > > > -#define FIT_UBOOT_COMP "gzip" > > > -#elif defined(CONFIG_SPL_LZMA) > > > -#define FIT_UBOOT_COMP "lzma" > > > -#else > > > -#define FIT_UBOOT_COMP "none" > > > -#endif > > > - > > > /* > > > * SHA256 should be enabled in SPL when signature validation is > > > involved, > > > * CRC32 should only be used for basic checksum validation of FIT > > > images. > > > @@ -61,11 +53,15 @@ > > > type = "standalone"; > > > os = "u-boot"; > > > arch = FIT_ARCH; > > > - compression = FIT_UBOOT_COMP; > > > + compression = CONFIG_ROCKCHIP_UBOOT_COMP; > > > load = <CONFIG_TEXT_BASE>; > > > entry = <CONFIG_TEXT_BASE>; > > > u-boot-nodtb { > > > - compress = FIT_UBOOT_COMP; > > > + compress = > > > CONFIG_ROCKCHIP_UBOOT_COMP; > > > +#if CONFIG_ROCKCHIP_UBOOT_COMP_LEVEL != 0 > > > + compress-level = > > > + > > > <CONFIG_ROCKCHIP_UBOOT_COMP_LEVEL>; > > > +#endif > > > > OK so the obvious question here is "why Rockchip-specific?". I > > appreciate you're mostly working with the RK3576 but I don't see why > > this (the kconfig symbol definition that happens later in this patch in > > arch/arm/mach-rockchip/Kconfig) needs to be Rockchip-specific, we have > > other architectures that are also building a FIT image with U-Boot > > proper in it, so I think it'd be nice to have this setting apply to all > > of them so that it's a more generic approach. > > The Kconfig selection itself is surely arch-agnostic, but I have no > idea if the handling of the resulting images will work out fine on > other architectures or what their constraints are, beyond what the > build system can tell me. Rockchip is the only one I can test, so I'd > rather start here :)
You don't need to implement it on other platforms, but yes, we should start this out generic-facing. That'll encourage someone else to look at what needs doing for another platform. [snip] > > > + ratio on offer, and by far the slowest to unpack. > > > + > > > +config ROCKCHIP_UBOOT_COMP_LZO > > > + bool "lzo" > > > + select SPL_LZO > > > + help > > > + Compress with LZO, run from the host 'lzop' binary. A poor ratio > > > in > > > + exchange for fast decompression. > > > + > > > +config ROCKCHIP_UBOOT_COMP_LZ4 > > > + bool "lz4" > > > + select SPL_LZ4 > > > + help > > > + Compress with LZ4, run from the host 'lz4' binary. The fastest to > > > + unpack and the worst ratio, so it suits a fast boot medium. > > > + > > > +config ROCKCHIP_UBOOT_COMP_ZSTD > > > + bool "zstd" > > > + select SPL_ZSTD > > > + help > > > + Compress with Zstandard, run from the host 'zstd' binary. Close to > > > + the LZMA ratio for a fraction of the time, but its decompressor > > > + wants around 94KB of SPL heap - see SPL_ZSTD. > > > > I don't like specifying numbers that aren't guaranteed to stay at that > > value. I understand the appeal to provide some number to give a rough > > idea of the size impact, so I don't think it needs to be a blocker, > > maybe Tom would have some opinion there, otherwise ignore this :) > > Tom acked a similar help text on the SPL_ZSTD option itself, but maybe > duplicating it all over the place is an overkill. Happy to distill it > in the next version. In this point, yes, perhaps the better answer is to not this stuff in documentation somewhere, rather than help text. -- Tom
signature.asc
Description: PGP signature
