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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 6430 bytes --]

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@chromium.org> wrote:
> 
> > Hi François,
> >
> > On Tue, 26 Oct 2021 at 09:57, François Ozog <francois.ozog@linaro.org>
> > wrote:
> > >
> > >
> > >
> > > On Tue, 26 Oct 2021 at 17:27, Simon Glass <sjg@chromium.org> wrote:
> > >>
> > >> Hi François,
> > >>
> > >> On Tue, 26 Oct 2021 at 08:31, François Ozog <francois.ozog@linaro.org>
> > wrote:
> > >> >
> > >> > Hi Simon,
> > >> >
> > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass <sjg@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?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]