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 7966AC433F5 for ; Fri, 14 Jan 2022 15:41:29 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 519718351F; Fri, 14 Jan 2022 16:41:27 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="Mf7klpCM"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9835483520; Fri, 14 Jan 2022 16:41:25 +0100 (CET) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E91A28350D for ; Fri, 14 Jan 2022 16:41:09 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x82f.google.com with SMTP id y17so11039443qtx.9 for ; Fri, 14 Jan 2022 07:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=S/3eS8Kkvzv4KZ30R2MdH1ZSnKXbXOaJRrQNXkVqIbo=; b=Mf7klpCMaNHtPlO5DCdKffDmQd2uyHB7nm84OH8CxDqL3MhriNQBlkhDa5Ut+be/cj nwK54vaTBJ1dQSZdGwRkMivvJc4SFNcMWdu49FH4rEr3BH771Wwc8mHbI6Y7sf1qpDcH LXQsapkN82xZrsUSHpDR0E60SqN/H40cp5Yik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=S/3eS8Kkvzv4KZ30R2MdH1ZSnKXbXOaJRrQNXkVqIbo=; b=PzDLCro3YaTBbyvqaucd4yhuRGKOYdDfjRh22ImrnYCkFOe1q02kL+/Y7UyDDgjC8j Ut4Eg5cpTvuwsmi65ru+nuWWRhhc1bw0pGoVD2M6PrqDHxEXSddhX1Dtgr69nw2SlK0H p6LXUtN9/Y7cOJGSpR4XLUD5S4vvKCnTRkHquPArAeoRKw25ClrG1mCN9NV1034h/hQJ z10Nnm+QEresveowUzNUvgKAlYepxpVz0kWYDJKygC9l0dAXDYncv7kXBGDlG0zOLu7Y AhUZOwNyGM9vQS1SknEGtDnORXOXDZEpsgk/gDVE+/FqLYwg9Yfs7pTWYnwOooD0Xv7u iNMw== X-Gm-Message-State: AOAM533Ysy+2/VhJnbSCMl5azZMOWP8+1lqA8CNZLyLFMmdZ3QmQGiuk m1DOOdGks7OCYMYyEKWploeaJw== X-Google-Smtp-Source: ABdhPJy3hO8IvgDoVCVk8pu7enZ2HpAIQiRIWa6WvVQXm2RgtuKMHwbyeV/oiiTdkXf51q/zoAbTug== X-Received: by 2002:ac8:590a:: with SMTP id 10mr8080818qty.186.1642174867002; Fri, 14 Jan 2022 07:41:07 -0800 (PST) Received: from bill-the-cat (2603-6081-7b01-cbda-9533-0c51-a891-732b.res6.spectrum.com. [2603:6081:7b01:cbda:9533:c51:a891:732b]) by smtp.gmail.com with ESMTPSA id n18sm4134844qtx.78.2022.01.14.07.41.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jan 2022 07:41:06 -0800 (PST) Date: Fri, 14 Jan 2022 10:41:04 -0500 From: Tom Rini To: Simon Glass Cc: u-boot@lists.denx.de, Alex Kiernan , Roman Kopytin , Rasmus Villemoes Subject: Re: [PATCH v2] introduce CONFIG_DEVICE_TREE_INCLUDES Message-ID: <20220114154104.GS9207@bill-the-cat> References: <20211121135251.3272738-1-rasmus.villemoes@prevas.dk> <297c0f18-a25b-d2e5-ef1c-535ccfce88c9@prevas.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/TRvNwC0MK56pCOd" Content-Disposition: inline In-Reply-To: <297c0f18-a25b-d2e5-ef1c-535ccfce88c9@prevas.dk> X-Clacks-Overhead: GNU Terry Pratchett 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.2 at phobos.denx.de X-Virus-Status: Clean --/TRvNwC0MK56pCOd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 14, 2022 at 09:30:29AM +0100, Rasmus Villemoes wrote: > Ping >=20 > On 21/11/2021 14.52, Rasmus Villemoes wrote: > > The build system already automatically looks for and includes an > > in-tree *-u-boot.dtsi when building the control .dtb. However, there > > are some things that are awkward to maintain in such an in-tree file, > > most notably the metadata associated to public keys used for verified > > boot. > >=20 > > The only "official" API to get that metadata into the .dtb is via > > mkimage, as a side effect of building an actual signed image. But > > there are multiple problems with that. First of all, the final U-Boot > > (be it U-Boot proper or an SPL) image is built based on a binary > > image, the .dtb, and possibly some other binary artifacts. So > > modifying the .dtb after the build requires the meta-buildsystem > > (Yocto, buildroot, whatnot) to know about and repeat some of the steps > > that are already known to and handled by U-Boot's build system, > > resulting in needless duplication of code. It's also somewhat annoying > > and inconsistent to have a .dtb file in the build folder which is not > > generated by the command listed in the corresponding .cmd file (that > > of course applies to any generated file). > >=20 > > So the contents of the /signature node really needs to be baked into > > the .dtb file when it is first created, which means providing the > > relevant data in the form of a .dtsi file. One could in theory put > > that data into the *-u-boot.dtsi file, but it's more convenient to be > > able to provide it externally: For example, when developing for a > > customer, it's common to use a set of dummy keys for development, > > while the consultants do not (and should not) have access to the > > actual keys used in production. For such a setup, it's easier if the > > keys used are chosen via the meta-buildsystem and the path(s) patched > > in during the configure step. And of course, nothing prevents anybody > > from having DEVICE_TREE_INCLUDES point at files maintained in git, or > > for that matter from including the public key metadata in the > > *-u-boot.dtsi directly and ignore this feature. > >=20 > > There are other uses for this, e.g. in combination with ENV_IMPORT_FDT > > it can be used for providing the contents of the /config/environment > > node, so I don't want to tie this exclusively to use for verified > > boot. > >=20 > > Reviewed-by: Simon Glass > > Signed-off-by: Rasmus Villemoes > > --- > > v2: rebase to current master, add paragraph to > > doc/develop/devicetree/control.rst as suggested by Simon. I've taken > > the liberty of keeping his R-b tag as this mostly just repeats what is > > in the Kconfig help text and commit message. > >=20 > > doc/develop/devicetree/control.rst | 18 ++++++++++++++++++ > > dts/Kconfig | 9 +++++++++ > > scripts/Makefile.lib | 3 +++ > > 3 files changed, 30 insertions(+) > >=20 > > diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetre= e/control.rst > > index 0e6f85d5af..ff008ba943 100644 > > --- a/doc/develop/devicetree/control.rst > > +++ b/doc/develop/devicetree/control.rst > > @@ -182,6 +182,24 @@ main file, in this order:: > > Only one of these is selected but of course you can #include another o= ne within > > that file, to create a hierarchy of shared files. > > =20 > > + > > +External .dtsi fragments > > +------------------------ > > + > > +Apart from describing the hardware present, U-Boot also uses its > > +control dtb for various configuration purposes. For example, the > > +public key(s) used for Verified Boot are embedded in a specific format > > +in a /signature node. > > + > > +As mentioned above, the U-Boot build system automatically includes a > > +*-u-boot.dtsi file, if found, containing U-Boot specific > > +quirks. However, some data, such as the mentioned public keys, are not > > +appropriate for upstream U-Boot but are better kept and maintained > > +outside the U-Boot repository. You can use CONFIG_DEVICE_TREE_INCLUDES > > +to specify a list of .dtsi files that will also be included when > > +building .dtb files. > > + > > + > > Relocation, SPL and TPL > > ----------------------- > > =20 > > diff --git a/dts/Kconfig b/dts/Kconfig > > index b7c4a2fec0..1f8debf1a8 100644 > > --- a/dts/Kconfig > > +++ b/dts/Kconfig > > @@ -131,6 +131,15 @@ config DEFAULT_DEVICE_TREE > > It can be overridden from the command line: > > $ make DEVICE_TREE=3D > > =20 > > +config DEVICE_TREE_INCLUDES > > + string "Extra .dtsi files to include when building DT control" > > + depends on OF_CONTROL > > + help > > + U-Boot's control .dtb is usually built from an in-tree .dts > > + file, plus (if available) an in-tree U-Boot-specific .dtsi > > + file. This option specifies a space-separated list of extra > > + .dtsi files that will also be used. > > + > > config OF_LIST > > string "List of device tree files to include for DT control" > > depends on SPL_LOAD_FIT || MULTI_DTB_FIT > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > > index 39f03398ed..4ab422c231 100644 > > --- a/scripts/Makefile.lib > > +++ b/scripts/Makefile.lib > > @@ -318,8 +318,11 @@ endif > > quiet_cmd_dtc =3D DTC $@ > > # Modified for U-Boot > > # Bring in any U-Boot-specific include at the end of the file > > +# And finally any custom .dtsi fragments specified with CONFIG_DEVICE_= TREE_INCLUDES > > cmd_dtc =3D mkdir -p $(dir ${dtc-tmp}) ; \ > > (cat $<; $(if $(u_boot_dtsi),echo '$(pound)include "$(u_boot_dtsi)"')= ) > $(pre-tmp); \ > > + $(foreach f,$(subst $(quote),,$(CONFIG_DEVICE_TREE_INCLUDES)), \ > > + echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ > > $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(p= re-tmp) ; \ > > $(DTC) -O dtb -o $@ -b 0 \ > > -i $(dir $<) $(DTC_FLAGS) \ Simon? --=20 Tom --/TRvNwC0MK56pCOd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHhmY0ACgkQFHw5/5Y0 tyxu7gv/b5bn6RIqd3+QT8U9Ham4AXxaQsnjzvOPYIMMw5+E1k+nu/nuA1VetTRW wRizjAQsYq/Dx4atr2Mq+sPbf2S2uv7BKDmqpSIF/r2Ur4SVVuCFrZ0C246DsBk0 3uEDTilnev6IfXefWxDqGGvSmAyWJbzn1MvsCVFWWMxB/U1swvc/IxE0DEufqyuQ bFWgxD1rAkbPKFUZhYIh01jtjAMgJ0VIqJBHTyf+M3ERfmXxQY2/XsslkRPM/kKs OWjxww5DTs8x5T3qmzTKkQRbgrosl+tYRDz1tZVl8569JgPU8XLYOwJsXMRSLvdf yQlo6ZZyjMlyfw4wZKW7IQQbQKNvAD7PcD4H9X0U2ch+gKISY/IJQAOPl22YtUEl ATjOp/fE3zfNx2xr7PnwZR7QEzpeZXqXMCBHFaboXECoZbKEE0mm81nxFzaAvlmk u2hjNhdx0kd0SamiETKdRWyt9h3YzSL6llnTTGr5cORKBo11W4qGMyZ4XVSOgmAj T5s/AYBn =5lhu -----END PGP SIGNATURE----- --/TRvNwC0MK56pCOd--