From: Tom Rini <trini@konsulko.com>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: "Simon Glass" <sjg@chromium.org>,
linux-arm-kernel@lists.infradead.org,
"Chen-Yu Tsai" <wenst@chromium.org>,
"J . Neuschäfer" <j.ne@posteo.net>,
"Masahiro Yamada" <masahiroy@kernel.org>,
linux-kernel@vger.kernel.org,
"Pengutronix Kernel Team" <kernel@pengutronix.de>
Subject: Re: [PATCH 1/2] scripts/make_fit: Support an initial ramdisk
Date: Mon, 22 Sep 2025 07:58:04 -0600 [thread overview]
Message-ID: <20250922135804.GA124814@bill-the-cat> (raw)
In-Reply-To: <9cafbc70-7235-4e49-928c-4d68a57b7d46@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]
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@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@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Tested-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2025-09-22 13:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-19 21:09 [PATCH 1/2] scripts/make_fit: Support an initial ramdisk Simon Glass
2025-09-19 21:09 ` [PATCH 2/2] scripts/make_fit: Speed up operation Simon Glass
2025-09-22 7:14 ` [PATCH 1/2] scripts/make_fit: Support an initial ramdisk Ahmad Fatoum
2025-09-22 13:58 ` Tom Rini [this message]
2025-09-22 22:49 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250922135804.GA124814@bill-the-cat \
--to=trini@konsulko.com \
--cc=a.fatoum@pengutronix.de \
--cc=j.ne@posteo.net \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=sjg@chromium.org \
--cc=wenst@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox