workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-arm-kernel@lists.infradead.org,
	 Masahiro Yamada <masahiroy@kernel.org>,
	Ahmad Fatoum <a.fatoum@pengutronix.de>,
	 U-Boot Mailing List <u-boot@lists.denx.de>,
	Nicolas Schier <nicolas@fjasle.eu>, Tom Rini <trini@konsulko.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Jonathan Corbet <corbet@lwn.net>,
	 Nathan Chancellor <nathan@kernel.org>,
	Nick Terrell <terrelln@fb.com>, Will Deacon <will@kernel.org>,
	 linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org,
	 linux-kernel@vger.kernel.org, workflows@vger.kernel.org
Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
Date: Mon, 4 Dec 2023 10:59:44 -0700	[thread overview]
Message-ID: <CAPnjgZ0XWDO90cq_h6V_EoOX+kmGLBRZwgT5RURCwQBQFONDYg@mail.gmail.com> (raw)
In-Reply-To: <20231203153401.GV8402@pendragon.ideasonboard.com>

Hi Laurent,

On Sun, 3 Dec 2023 at 08:33, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Simon,
>
> Thank you for the patch.
>
> On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
>
> FIT images are very useful, so I think this is a very welcome addition
> to the kernel build system. It can get tricky though: given the
> versatile nature of FIT images, there can't be any
> one-size-fits-them-all solution to build them, and striking the right
> balance between what makes sense for the kernel and the features that
> users may request will probably lead to bikeshedding. As we all love
> bikeshedding, I thought I would start selfishly, with a personal use
> case :-) This isn't a yak-shaving request though, I don't see any reason
> to delay merging this series.

OK, sounds good!

>
> Have you envisioned building FIT images with a subset of DTBs, or adding
> DTBOs ? Both would be fairly trivial extensions to this script by
> extending the supported command line arguments. It would perhaps be more
> difficult to integrate in the kernel build system though. This leads me
> to a second question: would you consider merging extensions to this
> script if they are not used by the kernel build system, but meant for
> users who manually invoke the script ? More generally, is the script
> meant to be used stand-alone as well, in which case its command line
> arguments need to remain backward-compatible, or do you see it as being
> internal to the kernel ?

The script as written is internal to the kernel, but I am sure it
could be expanded in some ways. I am waiting to see it merged before
worrying too much about what might happen in the future!

[..]

Regards,
Simon

  reply	other threads:[~2023-12-04 17:59 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-02  3:54 [PATCH v9 0/2] arm64: Add a build target for " Simon Glass
2023-12-02  3:54 ` [PATCH v9 2/2] arm64: boot: Support " Simon Glass
2023-12-03 15:34   ` Laurent Pinchart
2023-12-04 17:59     ` Simon Glass [this message]
2023-12-07 14:27     ` Chen-Yu Tsai
2023-12-07 14:38       ` Laurent Pinchart
2023-12-07 20:52         ` Simon Glass
2023-12-07 21:30           ` Laurent Pinchart
2023-12-09 13:13         ` Chen-Yu Tsai
2023-12-09 15:29           ` Laurent Pinchart
2023-12-09 16:31             ` Geert Uytterhoeven
2023-12-14  4:02               ` Chen-Yu Tsai
2023-12-14  6:12                 ` Masahiro Yamada
2023-12-14  7:33                   ` Masahiro Yamada
2023-12-29  6:38                     ` Simon Glass
2024-01-02  3:19                       ` Chen-Yu Tsai
2024-01-09 13:47                       ` Masahiro Yamada
2024-01-10  3:47                         ` Chen-Yu Tsai
2024-01-02 15:53                     ` Ahmad Fatoum
2024-01-09 14:33                     ` Rasmus Villemoes
2023-12-14  7:57                   ` Geert Uytterhoeven
2023-12-14 12:48                   ` Tom Rini
2023-12-05 11:48   ` Ahmad Fatoum
2023-12-06  3:54     ` Simon Glass
2023-12-08 11:49   ` Nicolas Schier
2023-12-13 12:13   ` Will Deacon
2024-01-02 23:46     ` Simon Glass
2024-01-09 14:01       ` Masahiro Yamada
2024-01-09 14:33         ` Tom Rini
2024-01-17 13:14           ` Simon Glass
2024-01-25 16:03             ` Simon Glass
2024-01-30  9:16               ` Masahiro Yamada
2024-01-31 22:02                 ` Rob Herring
2024-02-01  2:08                   ` Masahiro Yamada
2024-02-01 21:03                     ` Rob Herring
2024-02-02  5:37                       ` Masahiro Yamada
2024-02-02 16:00                   ` Simon Glass
2024-02-02 16:00                 ` 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=CAPnjgZ0XWDO90cq_h6V_EoOX+kmGLBRZwgT5RURCwQBQFONDYg@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=a.fatoum@pengutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nicolas@fjasle.eu \
    --cc=terrelln@fb.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=will@kernel.org \
    --cc=workflows@vger.kernel.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