[PATCH v5 02/26] doc: Add documentation about devicetree usage

Wed Oct 27 22:13:08 CEST 2021

Hi Tom

Le mer. 27 oct. 2021 à 21:48, Tom Rini <trini at konsulko.com> a écrit :

> On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote:
> > Hi Simon,
> >
> > On Wed, 27 Oct 2021 at 16:13, Simon Glass <sjg at chromium.org> wrote:
> >
> > > Hi François,
> > >
> > > On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog at linaro.org>
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg at chromium.org> wrote:
> > > >>
> > > >> Hi François,
> > > >>
> > > >> On Tue, 26 Oct 2021 at 08:31, François Ozog <
> francois.ozog at linaro.org>
> > > wrote:
> > > >> >
> > > >> > Hi Simon,
> > > >> >
> > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg at chromium.org>
> wrote:
> > > >> >>
> > > >> >> At present some of the ideas and techniques behind 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.
> > > >> >>
> > >
> > > [..]
> > >
> > > >> >> +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
> everything
> > > 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
> anything.
> > > 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
> devicetree
> > > 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
> would
> > > 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
> for
> > > 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
> these
> > > 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
> concatenated,
> > > 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
> files
> > > 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/index.html
> > > > Bindings:
> > > > for FCONF:
> > >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html
> > > > for FF-A:
> > >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
> > > > For chain-of-trust:
> > >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.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?

may be none.  The DT may contain only secure devices and devices for which
there are no Linux drivers (clocks or others).
I am not sure “secure device” is clear. This is a device that is separated
by hardware methods to be only accessible by EL3, secure ELx. So even if
you have secure mmio range you can’t access it from normal world at all.

>
>
> --
> Tom
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog