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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 70201C433F5 for ; Tue, 22 Mar 2022 13:19:15 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E0DEC83B0B; Tue, 22 Mar 2022 14:19:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id F134483B04; Tue, 22 Mar 2022 14:19:09 +0100 (CET) Received: from fudo.makrotopia.org (fudo.makrotopia.org [IPv6:2a07:2ec0:3002::71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 3773F83AFF for ; Tue, 22 Mar 2022 14:19:05 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=daniel@makrotopia.org Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.94.2) (envelope-from ) id 1nWePa-0002Ou-HO; Tue, 22 Mar 2022 14:18:58 +0100 Date: Tue, 22 Mar 2022 13:18:48 +0000 From: Daniel Golle To: Heinrich Schuchardt Cc: Simon Glass , Alexandru Gagniuc , Patrick Delaunay , u-boot@lists.denx.de Subject: Re: [PATCH] image-fdt: save name of FIT configuration in '/chosen' node Message-ID: References: <567cde68-f3f4-dcfc-89e3-f4d96b94f63a@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <567cde68-f3f4-dcfc-89e3-f4d96b94f63a@gmx.de> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Hi Heinrich, On Tue, Mar 22, 2022 at 09:29:54AM +0100, Heinrich Schuchardt wrote: > On 3/22/22 00:22, Daniel Golle wrote: > > It can be useful for the OS (Linux) to know which configuration has > > been chosen by U-Boot when launching a FIT image. > > Store the name of the FIT configuration node used in a new string > > attribute called 'bootconf' in the '/chosen' node in device tree. > > Please, point out where you want to use that information. I cannot see > that the Linux kernel will make any use of it. It can be useful when parsing FIT image in kernel, but can also be useful in userspace (via /sys/firmware/devicetree/base/chosen/bootconf). For OpenWrt I've written a uImage.FIT partition parser in order to allow a single type of firmware image containing kernel, dtb and rootfs to work accross all storage types (SPI-NOR/mtd, NAND/ubi, eMMC/block). I haven't yet submitted it upstream, exactly because some edges like selection of configuration would need to be discussed first. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/block/partitions/fit.c;h=89b5fb3454f0b69cdcfe53958169fb2a6f9c48a9;hb=HEAD However, it's doing the job for a bunch of OpenWrt boards already, incl. some popular devices https://openwrt.org/toh/linksys/e8450 (boots from SPI-NAND/ubi) https://openwrt.org/toh/sinovoip/bananapi_bpi-r64_v1.1 (can boot from SD Card, eMMC or SPI-NAND/ubi) Using uImage.FIT to store the squashfs besides kernel and dtb has several obvious advantages which are hard to obtain in any other way: * single image accross NOR/mtd, NAND/ubi and MMC/block devices * dynamically sized sub-partitions for kernel and rootfs * hash also for rootfs checked by U-Boot before launching kernel * images may include additional filesystems e.g. for localization or brandinge (hence the need to parse the boot configuration when mapping the 'filesystem' subimages into block partitions). > > > > > Signed-off-by: Daniel Golle > > --- > > boot/image-fdt.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/boot/image-fdt.c b/boot/image-fdt.c > > index 692a9ad3e4..4017bc94a6 100644 > > --- a/boot/image-fdt.c > > +++ b/boot/image-fdt.c > > @@ -601,6 +601,12 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob, > > goto err; > > } > > > > + /* Store name of configuration node as bootconf in /chosen node */ > > + if (images->fit_uname_cfg) > > + fdt_find_and_setprop(blob, "/chosen", "bootconf", > > + images->fit_uname_cfg, > > + strlen(images->fit_uname_cfg) + 1, 1); > > + > > We should not inject arbitrary properties into the device-tree. Where is > the property /chosen/bootconf defined in the Linux documentation or in > the device-tree specification? >From Linux Documenation (chosen.txt): "The chosen node does not represent a real device, but serves as a place for passing data between firmware and the operating system, like boot arguments." >From Device Tree specification (Release v0.3): "The /chosen node does not represent a real device in the system but describes parameters chosen or specified by the system firmware at run time." So to me it sounds like the right place for an additional attribute serving the above purpose. It could as well become an additional kernel cmdline argument in (ie. appended to 'bootargs' in '/chosen'), but that seemed more complex and harder to deal with. The name could be changed into something like 'denx,boot-configuration' if 'bootconf' is perceived to be too generic. Cheers Daniel