linux-kernel - Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231207143814.GD15521@pendragon.ideasonboard.com>
Date:   Thu, 7 Dec 2023 16:38:14 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Chen-Yu Tsai <wenst@...omium.org>
Cc:     Simon Glass <sjg@...omium.org>,
        linux-arm-kernel@...ts.infradead.org,
        Masahiro Yamada <masahiroy@...nel.org>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>,
        U-Boot Mailing List <u-boot@...ts.denx.de>,
        Nicolas Schier <nicolas@...sle.eu>,
        Tom Rini <trini@...sulko.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Jonathan Corbet <corbet@....net>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Terrell <terrelln@...com>, Will Deacon <will@...nel.org>,
        linux-doc@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, workflows@...r.kernel.org
Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 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.
> > 
> > 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
> 
> We'd also be interested in some customization, though in a different way.
> We imagine having a rule file that says X compatible string should map
> to A base DTB, plus B and C DTBO for the configuration section. The base
> DTB would carry all common elements of some device, while the DTBOs
> carry all the possible second source components, like different display
> panels or MIPI cameras for instance. This could drastically reduce the
> size of FIT images in ChromeOS by deduplicating all the common stuff.

Do you envision the "mapping" compatible string mapping to a config
section in the FIT image, that would bundle the base DTB and the DTBOs ?

> > 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 ?
> 
> [...]
> 
> ChenYu

-- 
Regards,

Laurent Pinchart