From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D07CEC4167B for ; Thu, 7 Dec 2023 21:31:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oYBXP8ppJqQFZZpO8SIFLyUF1wIlCVJl9HwdBGjktqY=; b=Eko7n75nc7kq2J pczxIeFLTaosV0ioB3kt+Y20wbRpWz4OqtL24MdM+DlVDurqQfcitEC3Cq1e8acqa2EYqRxt8gcHF OFW8qiUrTN0To0ctwAcL7SW5D5fsXJ5s8Lq9WXZkiAL9taBRptoiOV5Dn08XQkotveY0MKK1L3+rt gmold2HBlAXg1gRvk/3MLjUF0F/Vn3F/R9onPtryS2BNwSsC7WS/UKah3if1T22S9iosEngg6TbIm pzkknNPLPYUrjAPJ6wsHCfuP51n55JAl1VOS2HOTJaBgoXVFiLiokfRsuvDh1RSVEx0lvo2jU9jcz 8wacAAF6yI6GLjs9oNoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rBLxO-00E0yM-1h; Thu, 07 Dec 2023 21:30:54 +0000 Received: from perceval.ideasonboard.com ([213.167.242.64]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rBLxL-00E0tj-0X for linux-arm-kernel@lists.infradead.org; Thu, 07 Dec 2023 21:30:52 +0000 Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id DD5862B09; Thu, 7 Dec 2023 22:30:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1701984605; bh=++YvcrFz66sxa8xgV41El02Yomhcy3SFgFNd1nuRnT4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qjHo/ZRz7cMTAzyVsUjZpcWDuOQmvhscaXDaYQ1RRBxxdyqH8SRbU5uNzfrbQMi68 6U2jlkEY6KjCvzx5NSH+v9u2KvUGSz2YDo8ysALpNEtSSHkFqEFJW1ZpberVVdlgFl ceq0o2I/6kI1tIn+iHWmMCoAXdpRoWFSsl8IoTGw= Date: Thu, 7 Dec 2023 23:30:52 +0200 From: Laurent Pinchart To: Simon Glass Cc: Chen-Yu Tsai , linux-arm-kernel@lists.infradead.org, Masahiro Yamada , Ahmad Fatoum , U-Boot Mailing List , Nicolas Schier , Tom Rini , Catalin Marinas , Jonathan Corbet , Nathan Chancellor , Nick Terrell , Will Deacon , 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 Message-ID: <20231207213052.GD25616@pendragon.ideasonboard.com> References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org> <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com> <20231207143814.GD15521@pendragon.ideasonboard.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231207_133051_371088_80195963 X-CRM114-Status: GOOD ( 48.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Dec 07, 2023 at 01:52:53PM -0700, Simon Glass wrote: > On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart wrote: > > 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 ? > > It is great to see all this discussion! I did send a proposal to the > U-Boot ML about extensions but it was mixed up with other things, so > I'll start a new thread. > > For now, I am really just waiting for this to be applied, before > talking too much about future possibilities. Sure, I don't see any reason to delay this series until you have fixed everybody's system images problems :-) -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel