[PATCH 1/2] scripts/make_fit: Support an initial ramdisk

[Tom Rini]

On Mon, Sep 22, 2025 at 09:14:55AM +0200, Ahmad Fatoum wrote:
> Hello Simon,
> 
> On 19.09.25 23:09, Simon Glass wrote:
> > FIT (Flat Image Tree) allows an ramdisk to be included in each
> > configuration. Add support for this to the script.
> > 
> > This feature is not available via 'make image.fit' since the ramdisk
> > likely needs to be built separately anyway, e.g. using modules from
> > the kernel build.
> 
> AFAIK the kernel supports multiple concatenated separately compressed
> initramfs just fine, so it may still be useful to add a target which
> builds a cpio with all modules inside and the rest can be then
> concatenated.
> 
> What do you think?
> 
> > +        fsw.property_string('compression', args.compress)
> 
> compression should be none as the kernel would take of decompression.
> 
> Both U-Boot and barebox should warn about ramdisk compression property
> that is != "none".

Agreed. In U-Boot we've been handling this correctly since:

commit bddd985734653c366c8da073650930fb2e9b5003
Author: Julius Werner <jwerner at chromium.org>
Date:   Fri Aug 2 15:52:28 2019 -0700

    fit: Do not automatically decompress ramdisk images
    
    The Linux ramdisk should always be decompressed by the kernel itself,
    not by U-Boot. Therefore, the 'compression' node in the FIT image should
    always be set to "none" for ramdisk images, since the only point of
    using that node is if you want U-Boot to do the decompression itself.
    
    Yet some systems populate the node to the compression algorithm used by
    the kernel instead. This used to be ignored, but now that we support
    decompression of all image types it becomes a problem. Since ramdisks
    should never be decompressed by U-Boot anyway, this patch adds a special
    exception for them to avoid these issues. Still, setting the
    'compression' node like that is wrong in the first place, so we still
    want to print out a warning so that third-party distributions doing this
    can notice and fix it.
    
    Signed-off-by: Julius Werner <jwerner at chromium.org>
    Reviewed-by: Heiko Schocher <hs at denx.de>
    Tested-by: Heiko Schocher <hs at denx.de>
    Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250922/f549f1ff/attachment.sig>