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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7066CC433EF for ; Wed, 27 Oct 2021 19:48:16 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id AACE660F5A for ; Wed, 27 Oct 2021 19:48:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AACE660F5A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6182882127; Wed, 27 Oct 2021 21:48:13 +0200 (CEST) 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="aYOv4+O6"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 91A0D82127; Wed, 27 Oct 2021 21:48:11 +0200 (CEST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 28A2080F3B for ; Wed, 27 Oct 2021 21:48:06 +0200 (CEST) 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-qk1-x735.google.com with SMTP id r15so3584928qkp.8 for ; Wed, 27 Oct 2021 12:48:06 -0700 (PDT) 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=Wvf9iTfKUzoF14Sbs3uf7A4GuN9cNPHko25WeQu9n/0=; b=aYOv4+O6j4Vbh10bB/LLR2M9mepuAJ+nW1F/G9OHTHFsk84uruyd6c1/AtiBIwHRp/ Tk6eT1itw7lG61U/E1mXv1M+7zmvHQMRW9H/gc+MGchFIbUSFh3rP6Ak/uOu0SnZLJ/G aIdnAU7jZuNbIt7bJ7J0xZMzI7mQF3QMq+SOE= 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=Wvf9iTfKUzoF14Sbs3uf7A4GuN9cNPHko25WeQu9n/0=; b=k2/2MmyyuEK32ezZyfHO00TJB7L6236sni0NiX/k9U4I+HN0/t05/IommdY3QgZTtz egqQRqS6S97MLLzcjNxc2ch5JR8r4DnkS4aIfl/LGiJC5I8q9lh/8svQzASs9H8uunC5 lBwD0FR6jr7C7dk4b7NAfIdpI5rr/tdAgunLjvB6OiUhRpFI0Vms4KBdHg9TjT32+I4M bxcf6j4VUrG/SrDrF5OsAVQBjF5S8i1OMlxPGl+vlVvJDocRmRRsoEZQvtqgtlFPgduS XT0byMBfy3qiL2sUq3gRk3gEuYI23MA5W/zw/8mHOdudWgroHFRVgi2/RERDCLrRkFwa fhdQ== X-Gm-Message-State: AOAM532yjGk9nhM653//omz3mIyT9RkNPT89a2iHukroE39NtOG4rWSO F/6RQpSU6Aap23YeQcsZMIgMrg== X-Google-Smtp-Source: ABdhPJy2Kx8Me3DodaNwRCRcOePhkWk0s3t2GDlDg6hxtWdyZMK+j5vYXBUAaFoz0m1tR8MXUaMDSA== X-Received: by 2002:a37:ecb:: with SMTP id 194mr26539123qko.254.1635364085000; Wed, 27 Oct 2021 12:48:05 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-0044-6cb5-81ac-bb0c.res6.spectrum.com. [2603:6081:7b01:cbda:44:6cb5:81ac:bb0c]) by smtp.gmail.com with ESMTPSA id t21sm553159qta.93.2021.10.27.12.48.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Oct 2021 12:48:04 -0700 (PDT) Date: Wed, 27 Oct 2021 15:48:02 -0400 From: Tom Rini To: =?iso-8859-1?Q?Fran=E7ois?= Ozog Cc: Simon Glass , U-Boot Mailing List , Mark Kettenis , Heinrich Schuchardt , Ilias Apalodimas , Sean Anderson , Marcel Ziswiler Subject: Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage Message-ID: <20211027194802.GM8284@bill-the-cat> References: <20211026002344.405160-1-sjg@chromium.org> <20211026002344.405160-3-sjg@chromium.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/0D4jGRsNl8cPNu/" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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 --/0D4jGRsNl8cPNu/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2021 at 05:38:28PM +0200, Fran=E7ois Ozog wrote: > Hi Simon, >=20 > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: >=20 > > Hi Fran=E7ois, > > > > On Tue, 26 Oct 2021 at 09:57, Fran=E7ois Ozog > > wrote: > > > > > > > > > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > >> > > >> Hi Fran=E7ois, > > >> > > >> On Tue, 26 Oct 2021 at 08:31, Fran=E7ois Ozog > > wrote: > > >> > > > >> > Hi Simon, > > >> > > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > > >> >> > > >> >> At present some of the ideas and techniques behind devicetree in > > U-Boot > > >> >> are assumed, implied or unsaid. Add some documentation to cover h= ow > > >> >> devicetree is build, how it can be modified and the rules about u= sing > > >> >> the various CONFIG_OF_... options. > > >> >> > > > > [..] > > > > >> >> +Why not have two devicetrees? > > >> >> +----------------------------- > > >> >> + > > >> >> +Setting aside the argument for restricting U-Boot from having its > > own nodes and > > >> >> +properties, another idea proposed is to have two devicetrees, one > > for the > > >> >> +U-Boot-specific bits (here called `special`) and one for everyth= ing > > else (here > > >> >> +called `linux`). > > >> >> + > > >> >> +On the positive side, it might quieten the discussion alluded to= in > > the section > > >> >> +above. But there are many negatives to consider and many open > > questions to > > >> >> +resolve. > > >> >> + > > >> >> +- **Bindings** - Presumably the special devicetree would have its > > own bindings. > > >> >> + It would not be necessary to put a `u-boot,` prefix on anythin= g. > > People coming > > >> >> + across the devicetree source would wonder how it fits in with = the > > Linux > > >> >> + devicetree. > > >> >> + > > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > devicetree. This > > >> >> + would need to be expanded to support two trees. Features which > > need to access > > >> >> + both (such as a device driver which reads the special devicetr= ee > > to get some > > >> >> + configuration info) could become quite confusing to read and > > write. > > >> >> + > > >> >> +- **Merging** - Can the two devicetree be merged if a platform > > desires it? If > > >> >> + so, how is this managed in tooling? Does it happen during the > > build, in which > > >> >> + case they are not really separate at all. Or does U-Boot merge > > them at > > >> >> + runtime, in which case this adds time and memory? > > >> >> + > > >> >> +- **Efficiency** - A second device tree adds more code and more > > code paths. It > > >> >> + requires that both be made available to the code in U-Boot, e.= g. > > via a > > >> >> + separate pointer or argument or API. Overall the separation wo= uld > > certainly > > >> >> + not speed up U-Boot, nor decrease its size. > > >> >> + > > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > > pieces needed for > > >> >> + U-Boot for a particular board. Would we use these same files f= or > > the special > > >> >> + devicetree? > > >> >> + > > >> >> +- **Complexity** - Two devicetrees complicates the build system > > since it must > > >> >> + build and package them both. Errors must be reported in such a > > way that it > > >> >> + is obvious which one is failing. > > >> >> + > > >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > > driver model > > >> >> + are currently placed in the nodes they relate to. How would th= ese > > tags > > >> >> + reference a node that is in a separate devicetree? What extra > > validation would > > >> >> + be needed? > > >> >> + > > >> >> +- **Storage** - How would the two devicetrees be stored in the > > image? At present > > >> >> + we simply concatenate the U-Boot binary and the devicetree. We > > could add the > > >> >> + special devicetree before the Linux one, so two are concatenat= ed, > > but it is > > >> >> + not pretty. We could use binman to support more complex > > arrangements, but only > > >> >> + some boards use this at present, so it would be a big change. > > >> >> + > > >> >> +- **API** - How would another project provide two devicetree fil= es > > to U-Boot at > > >> >> + runtime? Presumably this would just be too painful. But if it > > doesn't, it > > >> >> + would be unable to configure run-time features of U-Boot during > > the boot. > > >> >> + > > >> >> +- **Confusion** - No other project has two devicetrees. U-Boot > > would be in the > > >> >> + unfortunate position of having to describe this fact to new > > users, along with > > >> >> + the (arguably contrived) reason for the arrangement. > > >> >> + > > >> > > > >> > False: > > >> > 1) projects in trustedfirmware.org are built to have multiple FDT > > objects, some for "dynamic" configuration purposes. > > >> > > >> Can you provided a link and I can update this. > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/ind= ex.html > > > Bindings: > > > for FCONF: > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fco= nf_properties.html > > > for FF-A: > > https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manif= est-binding.html > > > For chain-of-trust: > > https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-bindi= ng.html > > > > > > For some code: > > > > > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/= fiptool/tbbr_config.c > > > From there you can wander and see how dynamic config sections of the = FIP > > can contain component specific DTs. > > > U-Boot "private" DT could be securely stored in NT_FW_CONFIG section. > > > > OK I can mention that TF-A supports multiple devicetrees if you like, > > but I'm not sure we are talking about the same thing. > > If I take a possible scenario: OP-TEE to deal with 3 different device > trees: > - the one that will be passed to the OS and for which it may want to do > some fixups > - the one that it is using to run (it may have secure devices that are > entirely not visible to any normal world OS) What relationship does this device tree that OP-TEE is using itself bear to the one is will pass to the OS? --=20 Tom --/0D4jGRsNl8cPNu/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmF5rO4ACgkQFHw5/5Y0 tyxgwQv/VFroaHVzOuDyszvs8shvKb9hChmRyGX2pIRaIFb7Y6kbHxLGXmqyaSOE dNBC6geGo6vaBuLwMCKEV8H3PEIdMfoRlMikAThmXe7dxBzqhYYkjOIoFR791VkO c3qi6tD/b6/9e+qCcFnlibXFq3L5AVkSJ92Jagpr6g7dO/BPU+y0laRwiT+bi8en LuqG4A8+DiMfXpEvWMOEPUfofE/LyFKnCPOEFx3k69zAEXyZjAzgLYxd0eAWqpFw 39OI/fYD67CSDGMz+gZ+TCLpg9ZYb2nEnTLPZHzlr0MTW83NdNk+/aYx91Bcmp1u pvdAF+LOO3J+X0rGJER9pDU6LB+2jXCwO5SHFC5BjBkdROQ/VYpw6AKIiazTyUBV 36nE5lsGNKSDdHhGx0+L4tPaL158fmG1eYf433OpAvE70K56fuWX/HmK/ClfYuMR +uevHqcR/xJdOmxuRnFToHQRB8nP2hmlXIMqXl15h0HJ2ePKn2qlFgLm5M5yNM4I yCxCZwtr =21kX -----END PGP SIGNATURE----- --/0D4jGRsNl8cPNu/--