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 7BF77C433EF for ; Wed, 13 Oct 2021 15:39:20 +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 D9E0F61154 for ; Wed, 13 Oct 2021 15:39:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D9E0F61154 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 AC8DA83431; Wed, 13 Oct 2021 17:39:17 +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="iLdfp3Z3"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2173383581; Wed, 13 Oct 2021 17:39:15 +0200 (CEST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 4DF8F83373 for ; Wed, 13 Oct 2021 17:39:09 +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-qt1-x82b.google.com with SMTP id i1so2911766qtr.6 for ; Wed, 13 Oct 2021 08:39:09 -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=Xe8wPPJQmg6M+yvbPR5AaZCoPMKDBuzlANUUcNPCDhc=; b=iLdfp3Z3ptfHpnBf7JY5ClDy19SgWDRIYvd7dKhkHVoAjUoc2CTWZ2YQSyiBxAJfkb IkABXobTSW5B5EKVFkDmbotlgeJGz0d17NHKu1t5B1AJCosnjal1EE/w3+eZthM5HoVb vqAHGkJkLddaGuaJQ2skPCYbzbU3yBAj2WvFU= 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=Xe8wPPJQmg6M+yvbPR5AaZCoPMKDBuzlANUUcNPCDhc=; b=8MTw1Oef6bXxChdMnsicv3Tts5MxqeoTGUPpYM97Ut2HN1TXNzsMGW/7xlP1O+32C7 IEE7mbQQfryoI56WlHRTSM6p0xhcT3ClYKGUXNqZznzV5lprDodiTx5uZtNVLXpHBSjl 9yTym0dyibjftXp7bK/7OG1O9HDqZxQ3t6fM+B6zBjpvqNPaa+Q038VgGMerJzezN5Yi j9QNIoOiN3N9C3PBTbiEOavTibp4Wc8oa3hkvHPGIMJvfzU8h+DevImyGzPgs+YB/Bmu On8rrlOWLc3vk4FIenYNR2pR+Bhj6hTbO/hUZrzyKyYpwtGEKnDU2EkscmTSLbO/oF5z 3kCw== X-Gm-Message-State: AOAM5339VrP8jEVp6y+zBvcpbcA0ri5ORYdMPyGqRvpBqGFc3AtF4xMI N2QPSbLhFreb07VHnz+FXyKgDg== X-Google-Smtp-Source: ABdhPJxXHqmKAjxwJR/wBhabEeylLDodkzrtZtU6ZGflZ5gg20V8N93soFBgojm1NkpuvNUD2LZnww== X-Received: by 2002:a05:622a:1992:: with SMTP id u18mr19833538qtc.111.1634139547972; Wed, 13 Oct 2021 08:39:07 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-e98d-c49f-f596-1fb5.res6.spectrum.com. [2603:6081:7b01:cbda:e98d:c49f:f596:1fb5]) by smtp.gmail.com with ESMTPSA id a3sm8873793qta.48.2021.10.13.08.39.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 08:39:06 -0700 (PDT) Date: Wed, 13 Oct 2021 11:39:05 -0400 From: Tom Rini To: =?iso-8859-1?Q?Fran=E7ois?= Ozog Cc: Bin Meng , Mark Kettenis , Rick Chen , Simon Glass , bill.mills@linaro.org, ilias.apalodimas@linaro.org, marcel.ziswiler@toradex.com, seanga2@gmail.com, u-boot@lists.denx.de, xypron.glpk@gmx.de Subject: Re: [PATCH v3 3/3] RFC: doc: Add documentation about devicetree usage Message-ID: <20211013153905.GV7964@bill-the-cat> References: <20210910211737.GB12964@bill-the-cat> <561450ac28c24b92@bloch.sibelius.xs4all.nl> <20210910224448.GD12964@bill-the-cat> <20210918131816.GM8579@bill-the-cat> <20211013125539.GK7964@bill-the-cat> <20211013133004.GM7964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FRnlOPVounx9/Gmj" 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 --FRnlOPVounx9/Gmj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Splitting my replies up ] On Wed, Oct 13, 2021 at 04:45:50PM +0200, Fran=C3=A7ois Ozog wrote: > Le mer. 13 oct. 2021 =C3=A0 15:30, Tom Rini a =C3=A9= crit : >=20 > > On Wed, Oct 13, 2021 at 03:12:02PM +0200, Fran=C3=A7ois Ozog wrote: > > > Le mer. 13 oct. 2021 =C3=A0 14:55, Tom Rini a = =C3=A9crit : > > > > > > > On Wed, Oct 13, 2021 at 10:15:02AM +0200, Fran=C3=A7ois Ozog wrote: > > > > > Le sam. 18 sept. 2021 =C3=A0 15:18, Tom Rini = a > > =C3=A9crit : > > > > > > > > > > > On Sat, Sep 18, 2021 at 03:38:45AM -0600, Simon Glass wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Fri, 10 Sept 2021 at 16:44, Tom Rini > > wrote: > > > > > > > > > > > > > > > > On Sat, Sep 11, 2021 at 12:09:40AM +0200, Mark Kettenis wro= te: > > > > > > > > > > Date: Fri, 10 Sep 2021 17:17:37 -0400 > > > > > > > > > > From: Tom Rini > > > > > > > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 11:12:20PM +0200, Mark Kettenis > > wrote: > > > > > > > > > > > > Date: Fri, 10 Sep 2021 08:34:20 -0400 > > > > > > > > > > > > From: Tom Rini > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 10:38:17AM +0200, Heinrich > > > > Schuchardt > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/9/21 10:10 PM, Simon Glass wrote: > > > > > > > > > > > > > > At present some of the ideas and techniques beh= ind > > > > > > devicetree in U-Boot > > > > > > > > > > > > > > are assumed, implied or unsaid. Add some > > documentation > > > > to > > > > > > cover how > > > > > > > > > > > > > > devicetree is build, how it can be modified and= the > > > > rules > > > > > > about using > > > > > > > > > > > > > > the various CONFIG_OF_... options. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > > Reviewed-by: Marcel Ziswiler < > > > > marcel.ziswiler@toradex.com> > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > > > > - Fix typos linst suppled receive EFL > > > > > > > > > > > > > > - Drop 'and' before 'self-defeating' > > > > > > > > > > > > > > - Reword mention of control of QEMU's devicetree > > > > generation > > > > > > > > > > > > > > - Add mention of dropping CONFIG_OF_BOARD > > > > > > > > > > > > > > - Clarify the 'Once this bug is fixed' paragrap= h a > > bit > > > > > > > > > > > > > > - Expand ways that CONFIG_OF_PRIOR_STAGE can > > support > > > > the > > > > > > U-Boot devicetree > > > > > > > > > > > > > > - Add a note at the top explaining that his pat= ch > > > > covers > > > > > > 'now', not 'future' > > > > > > > > > > > > > > - Add note 'Note: Some boards use a devicetree = in > > > > U-Boot > > > > > > which does not match' > > > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > > > - Fix typos per Sean (thank you!) and a few oth= ers > > > > > > > > > > > > > > - Add a 'Use of U-Boot /config node' section > > > > > > > > > > > > > > - Drop mention of dm-verity since that actually > > uses > > > > the > > > > > > kernel cmdline > > > > > > > > > > > > > > - Explain that OF_BOARD will still work after t= hese > > > > > > changes (in > > > > > > > > > > > > > > 'Once this bug is fixed...' paragraph) > > > > > > > > > > > > > > - Expand a bit on the reason why the 'Current > > > > situation' > > > > > > is bad > > > > > > > > > > > > > > - Clarify in a second place that Linux and U-Bo= ot > > use > > > > the > > > > > > same devicetree > > > > > > > > > > > > > > in 'To be clear, while U-Boot...' > > > > > > > > > > > > > > - Expand on why we should have rules for other > > > > projects in > > > > > > > > > > > > > > 'Devicetree in another project' > > > > > > > > > > > > > > - Add a comment as to why devicetree in U-Boot = is > > not > > > > 'bad > > > > > > design' > > > > > > > > > > > > > > - Reword 'in-tree U-Boot devicetree' to 'device= tree > > > > source > > > > > > in U-Boot' > > > > > > > > > > > > > > - Rewrite 'Devicetree generated on-the-fly in > > another > > > > > > project' to cover > > > > > > > > > > > > > > points raised on v1 > > > > > > > > > > > > > > - Add 'Why does U-Boot have its nodes and > > properties?' > > > > > > > > > > > > > > - Add 'Why not have two devicetrees?' > > > > > > > > > > > > > > > > > > > > > > > > > > > > doc/develop/index.rst | 1 + > > > > > > > > > > > > > > doc/develop/package/devicetree.rst | 583 > > > > > > +++++++++++++++++++++++++++++ > > > > > > > > > > > > > > doc/develop/package/index.rst | 1 + > > > > > > > > > > > > > > 3 files changed, 585 insertions(+) > > > > > > > > > > > > > > create mode 100644 > > doc/develop/package/devicetree.rst > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/doc/develop/index.rst > > > > b/doc/develop/index.rst > > > > > > > > > > > > > > index 83c929babda..d5ad8f9fe53 100644 > > > > > > > > > > > > > > --- a/doc/develop/index.rst > > > > > > > > > > > > > > +++ b/doc/develop/index.rst > > > > > > > > > > > > > > @@ -36,6 +36,7 @@ Packaging > > > > > > > > > > > > > > :maxdepth: 1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > package/index > > > > > > > > > > > > > > + package/devicetree > > > > > > > > > > > > > > > > > > > > > > > > > > > > Testing > > > > > > > > > > > > > > ------- > > > > > > > > > > > > > > diff --git a/doc/develop/package/devicetree.rst > > > > > > b/doc/develop/package/devicetree.rst > > > > > > > > > > > > > > new file mode 100644 > > > > > > > > > > > > > > index 00000000000..b1bd310d906 > > > > > > > > > > > > > > --- /dev/null > > > > > > > > > > > > > > +++ b/doc/develop/package/devicetree.rst > > > > > > > > > > > > > > @@ -0,0 +1,583 @@ > > > > > > > > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Updating the devicetree > > > > > > > > > > > > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Note: This documentation describes how things = are > > > > today, > > > > > > mostly, with some > > > > > > > > > > > > > > +mention of things that need to be fixed. It is= not > > > > > > intended to point the way to > > > > > > > > > > > > > > +what might be done in the future. That should = be > > the > > > > > > subject of discussions on > > > > > > > > > > > > > > +the mailing list. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +U-Boot uses devicetree for runtime configurati= on > > and > > > > > > storing required blobs or > > > > > > > > > > > > > > +any other information it needs to operate. It = is > > > > possible > > > > > > to update the > > > > > > > > > > > > > > +devicetree separately from actually building > > U-Boot. > > > > This > > > > > > provides a good degree > > > > > > > > > > > > > > +of control and flexibility for firmware that u= ses > > > > U-Boot > > > > > > in conjunction with > > > > > > > > > > > > > > +other project. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +There are many reasons why it is useful to mod= ify > > the > > > > > > devicetree after building > > > > > > > > > > > > > > +it: > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +- Configuration can be changed, e.g. which UART > > to use > > > > > > > > > > > > > > +- A serial number can be added > > > > > > > > > > > > > > +- Public keys can be added to allow image > > verification > > > > > > > > > > > > > > +- Console output can be changed (e.g. to select > > > > serial or > > > > > > vidconsole) > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +This section describes how to work with > > devicetree to > > > > > > accomplish your goals. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +See also :doc:`../devicetree/control` for a ba= sic > > > > summary > > > > > > of the available > > > > > > > > > > > > > > +features. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Devicetree source > > > > > > > > > > > > > > +----------------- > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Every board in U-Boot must include a devicetree > > > > > > sufficient to build and boot > > > > > > > > > > > > > > +that board on suitable hardware (or emulation). > > This > > > > is > > > > > > specified using the > > > > > > > > > > > > > > +`CONFIG DEFAULT_DEVICE_TREE` option. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Current situation (August 2021) > > > > > > > > > > > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +As an aside, at present U-Boot allows > > > > > > `CONFIG_DEFAULT_DEVICE_TREE` to be empty, > > > > > > > > > > > > > > +e.g. if `CONFIG_OF_BOARD` or > > `CONFIG_OF_PRIOR_STAGE` > > > > are > > > > > > used. This has > > > > > > > > > > > > > > +unfortunately created an enormous amount of > > confusion > > > > and > > > > > > some wasted effort. > > > > > > > > > > > > > > +This was not intended and this bug will be fix= ed > > soon. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Some of the problems created are: > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +- It is not obvious that the devicetree is com= ing > > from > > > > > > another project > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +- There is no way to see even a sample devicet= ree > > for > > > > > > these platform in U-Boot, > > > > > > > > > > > > > > + so it is hard to know what is going on, e.g. > > which > > > > > > devices are typically > > > > > > > > > > > > > > + present > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +- The other project may not provide a way to > > support > > > > > > U-Boot's requirements for > > > > > > > > > > > > > > + devicetree, such as the /config node. Note: = On > > the > > > > > > U-Boot mailing list, this > > > > > > > > > > > > > > + was only discovered after weeks of discussion > > and > > > > > > confusion > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +- For QEMU specifically, consulting two QEMU > > source > > > > files > > > > > > is required, for which > > > > > > > > > > > > > > + there are no references in U-Boot > > documentation. The > > > > > > code is generating a > > > > > > > > > > > > > > + devicetree, with some control from command-l= ine > > > > args, > > > > > > but it is not clear > > > > > > > > > > > > > > + how to add properties required by U-Boot. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Specifically on the changes in U-Boot: > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +- `CONFIG_OF_BOARD` was added in rpi_patch_ for > > > > Raspberry > > > > > > Pi, which does have > > > > > > > > > > > > > > + an in-tree devicetree, but this feature has > > since > > > > been > > > > > > used for boards that > > > > > > > > > > > > > > + don't > > > > > > > > > > > > > > +- `CONFIG_OF_PRIOR_STAGE` was added in bcm_pat= ch_ > > as > > > > part > > > > > > of a larger Broadcom > > > > > > > > > > > > > > + change with a tag indicating it only affected > > one > > > > > > board, so the change in > > > > > > > > > > > > > > + behaviour was not noticed at the time. It has > > since > > > > > > been used by RISC-V qemu > > > > > > > > > > > > > > + boards. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Note: It is not clear that we actually need bo= th > > of > > > > > > these. Possibly > > > > > > > > > > > > > > +`CONFIG_OF_BOARD` can be dropped. > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +Once this bug is fixed, CONFIG_OF_BOARD and > > > > > > CONFIG_OF_PRIOR_STAGE will override > > > > > > > > > > > > > > > > > > > > > > > > > > What does "bug" refer to? Above you describe the > > current > > > > > > design not a bug. > > > > > > > > > > > > > > > > > > > > > > > > The bug is that we have two options to provide > > seemingly > > > > the > > > > > > same > > > > > > > > > > > > functionality. Is there a functional difference > > between > > > > > > CONFIG_OF_BOARD > > > > > > > > > > > > and CONFIG_OF_PRIOR_STAGE ? > > > > > > > > > > > > > > > > > > > > > > With CONFIG_OF_BOARD there is a function that returns= the > > > > > > pointer to > > > > > > > > > > > the DTB, so you can do all sort of things with it. > > > > > > > > > > > > > > > > > > > > > > With CONFIG_OF_PRIOR_STAGE there is a variable that y= ou > > need > > > > to > > > > > > set in > > > > > > > > > > > low-level code to point at the DTB and there is a > > pre-defined > > > > > > function > > > > > > > > > > > that returns that pointer. > > > > > > > > > > > > > > > > > > > > > > CONFIG_OF_BOARD is more flexible than > > CONFIG_OF_PRIOR_STAGE, > > > > but > > > > > > if > > > > > > > > > > > the only thing you want to do is to pass on a DTB tha= t is > > > > passed > > > > > > in a > > > > > > > > > > > CPU register to U-Boot then CONFIG_OF_PRIOR_STAGE is > > probably > > > > > > easier > > > > > > > > > > > to use. > > > > > > > > > > > > > > > > > > > > > > I'm not convinced there is a bug here. > > > > > > > > > > > > > > > > > > > > Thanks for explaining. Couldn't CONFIG_OF_PRIOR_STAGE = be > > > > > > rewritten as > > > > > > > > > > an implementation of CONFIG_OF_BOARD, possibly at the s= ame > > or > > > > less > > > > > > > > > > overall code size? That I think is the potential bug. > > > > > > > > > > > > > > > > > > Probably a little bit more code: > > > > > > > > > > > > > > > > > > void * > > > > > > > > > board_fdt_blob_setup(void) > > > > > > > > > { > > > > > > > > > return (void *)(uintptr_t)prior_stage_fdt_address; > > > > > > > > > } > > > > > > > > > > > > > > > > Tiny bit more. Probably worth doing to make the choices > > clearer on > > > > > > > > which to select when? Bin, Rick, thoughts on this since ri= scv > > is > > > > the > > > > > > > > main user of CONFIG_OF_PRIOR_STAGE at this point? > > > > > > > > > > > > > > Bin, Rick? > > > > > > > > > > > > > > What is the prior stage in the RISC-V stage? Could we get it = to > > set > > > > up > > > > > > > a bloblist? Then we can add a devicetree in there, with the > > option to > > > > > > > add more things in future. > > > > > > > > > > > > I'm suggesting we don't need to do anything upstream of us, just > > rework > > > > > > things to use the other hook for "provided a DTB by caller, use > > it", so > > > > > > that we have a single hook for that. > > > > > > > > > > What was the rationale in posting in kernel.org ( > > > > > > > > > > > https://lore.kernel.org/all/20211003125134.2.I7733f5a849476e908cc51f0c7= 1b8a594337fbbdf@changeid/ > > > > > ) and not in U-Boot knowing there is still no consensus on the big > > > > picture ? > > > > > > > > Well, because we need to get our bindings reviewed and made officia= l, > > > > and that looked like a reasonable place and choice to start with? v2 > > > > cc'd a different set of lists, at Rob's suggestion. > > > > > > making it =E2=80=9C Official=E2=80=9D does not necessarily mean in th= e Linux DT. What > > would > > > you think with a hardware description file that comes with U-Boot, > > > > No? A project-specific binding is only valid within the project. So > > unless it's a linux,foo binding it's not "Linux DT", it's generic. Part > > of the point in pushing this up for real review is that IF we want to be > > passed this information then it needs to be a real official and reviewed > > binding. And that process in turn meanings convincing other (generally > > skeptical) people it's a good idea. And maybe that it should take a > > more generic approach. > > > > > LinuxBoot and EDK2 config options ? No need for Linux to know about t= hose > > > U-Boot internal config? Why would those U-Boot elements be passed dow= n to > > > any OS ? > > > > I don't see the harm? >=20 > U-Boot per say does not define a standardized contract handover to OS. > Multiboot, AVB, Linux and UEFi do. I disagree. Linux, in general / looking forward, is trying to not have N ad-hoc per-architecture entry points. Even as I understand it (and I might have some of the exact terminology wrong, sorry) on x86_64, grub/systemd-boot/etc on UEFI systems (the modern, and even not so modern these days, norm) can set things up such that the kernel is launched by UEFI. Just like it would do for Free/Open/NetBSD or Windows. That standard defined in parts by UEFI and ACPI where who shall provide what. And sometimes that means "here's the standard way to add some info to the ACPI tables". I'll admit I don't know how exactly on the x86_64 world information gets passed around between the secure/non-secure world and all of those other fun challenge that we're talking about here. Looking at https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html it's certainly written as a specification, but I don't know off-hand how widely it's used right now. Assuming AVB in this context means Android Verified Boot, well, I guess at this point I'm now going to fail to not make this joke: https://xkcd.com/927/ > It makes sense to expose some stuff > related to the contract in the DT, added by the relevant =E2=80=9Ccontrac= t manager=E2=80=9D > in U-Boot. Should one want to define further VBE for instance with > information that is useful to OS, then it make sense to have VBE > information exposes. > Exposing information by U-Boot for its own consumption is like an > information leak: something that is part of a non existing ABI that can > create bad legacy. I think Rob's feedback on Simon's thread is helpful here, and the information in question possibly more belongs strictly under the /chosen node where this kind of information is already present. I would encourage you to chime in on the thread there. --=20 Tom --FRnlOPVounx9/Gmj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFm/ZUACgkQFHw5/5Y0 tywoWgv/eRZXBd+KQfmjSNRevEPHovAJECiJq7gzeC++ddXVkJVGRji8Cm+Q0NVE hQhOLWcaOwzM6t3vZsXsx4XlrKQvEDIUsfqL3EnFGmEc4JplaAey3eyu1E1lC3qW lL/kS9D4n5l3mkCANoL661xxuWLTeCl7o/quqrEUxWUa07KrkYkOCSnS0g2TX5zY OxkZJhmnw+uN3KpjcusrwIcnkZUjUkGLbuTqpijO2STGIYL0EUIK8b5qWI+0REfm OzLS1HCsHI+qVSFR5+i4VxlcfX7I+nS6fTaGYUSIwtdRWj2E/l6Expag9v/1iMkL xqTO8nHyl5YSJoSPV8HVLtuEuDh2FmC2URFDxMpEu/YI4femJzdwwrCsnSTn9tw2 wLxEyH2Wz/u3ndsEjkac3OtmO5TRaX/tgL30eDFZFWVQc59gfgNbxe5ZbueFUzDB M7Sed+Ncxy4ZKvjNMeUOMbNqCMNbV0wCyEqXX6K35kSCAremuKgPSHpnEGlEpJS6 Gt/SPBrs =42yn -----END PGP SIGNATURE----- --FRnlOPVounx9/Gmj--