From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="c8B/JvlL" Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AB8A1715 for ; Thu, 7 Dec 2023 12:53:14 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-9fa45e75ed9so157554866b.1 for ; Thu, 07 Dec 2023 12:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1701982392; x=1702587192; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oWIflf5hcpue6wGtlwNE/HkT4tbMsQSgIfDnrjtjjfg=; b=c8B/JvlL241AVApFlMOMEU71qJxiM19TKArDurZrBANlu7YBhDBXwSgkbfua/d8XtZ WfB9iTKD4UeUFE/1G8xm+4RNZWPdz87iSzi6rbarvzt1/pdZX4+ZJvEF8One39Dx8RGH iiFln6d4IqKX/xXVK6Rwv2ppGNiVpwEFRMGos= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701982392; x=1702587192; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oWIflf5hcpue6wGtlwNE/HkT4tbMsQSgIfDnrjtjjfg=; b=nHGGO/b6sBZbUDq5GwMbmdwivsT0hXT5XMUBtGc6J7m6zziCph5fgph8tCT7CAdHK4 iG7Yzm2GYA8PeNte4tTxY65lb4Mkhr9paVSL7aEli6OtHMzRt1v/U0xoWYvWgKtUpdY1 hw+9ZmYwCTRt8HBZYqZfMZXV0fQ86NWLk1W+b9JA2u34rm3jYo4/9OtnZgaPU+n7MUpB HD9arM3Kr0MY3wzybutRmn7TN1fxPEwqwgvEaFS6XakOuhvQ7VPutkLqoIu1cplg6ecf 7mA1dwVauyQYOSDfL8mdjXumGOWF4MIyrk196+nVj8pzRc3oVcfuXa7ohJW0at+Cta/Z hzEQ== X-Gm-Message-State: AOJu0YylbNGIR1UipxFW4z6Tn/kd1sJMoLqJZJE1LjYTzyIZxA7D/mFm sPJrXRBXAzMERP1LSnYozLda7/yLo5HD8V/0nyRIMA== X-Google-Smtp-Source: AGHT+IGlqecBeKpKJsPolkl+LHqMluq7H92QsuDLPCGLyyt/tYoOLIFC7+pQZSilRLUlakLEfiXMyZjPKdw0aG6O2m4= X-Received: by 2002:a17:907:2948:b0:a19:a19a:eac0 with SMTP id et8-20020a170907294800b00a19a19aeac0mr1471204ejc.121.1701982392232; Thu, 07 Dec 2023 12:53:12 -0800 (PST) Precedence: bulk X-Mailing-List: workflows@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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> In-Reply-To: <20231207143814.GD15521@pendragon.ideasonboard.com> From: Simon Glass Date: Thu, 7 Dec 2023 13:52:53 -0700 Message-ID: Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree To: Laurent Pinchart 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 Content-Type: text/plain; charset="UTF-8" Hi, 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. Regards, SImon