[PATCH v2 3/3] RFC: doc: Add documentation about devicetree usage

Simon Glass sjg at chromium.org
Fri Sep 3 10:53:46 CEST 2021


Hi,

On Mon, 30 Aug 2021 at 08:48, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Aug 30, 2021 at 04:30:55PM +0200, Heinrich Schuchardt wrote:
> >
> >
> > On 8/28/21 6:46 PM, 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 how
> > > devicetree is build, how it can be modified and the rules about using
> > > the various CONFIG_OF_... options.
>
> I feel like I should emphasize that this is "document what we have
> today" at least as much, if not more-so, than "document what we want to
> move to tomorrow".
>
> In that this highlights some design disagreements that need to be
> settled, good.  But lets perhaps start separate threads on those areas?

Yes, my intent was to do document what is there today. That was
Heinrich's request before applying the revert.

Except that as I mention at the top, the QEMU business needs sorting
out soon as it is perverting things in various strange ways and has
sent EFI done another blind alley (the first was supporting non-DM
code).

Actually it seems that even this patch has produced some confusion so
clearly some don't even see the status quo in the same way.

[..]

> > > +
> > > +This means that there is a basic devicetree build in the U-Boot tree, for
> > > +build-testing, consistency and documentation purposes, but at runtime U-Boot can
> > > +accept its devicetree from another source.
> > > +
> > > +To be clear, while U-Boot has its own copy of the devicetree source for each
> > > +board, this must match the Linux source, perhaps with some u-boot.dtsi
> > > +additions. The intent here is not to create a separate binding, just to provide
> > > +a representative devicetree in U-Boot.
> >
> > For many boards we lag far behind Linux' device-tree.
>
> Which is a huge problem that needs to be fixed.  The intention has never
> been to "commit and forget".

Exactly. Heinrich, surely you are not suggesting that we should ignore this?

>
> [snip]
> > > +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it
> > > +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging
> > > +the firmware, the U-Boot devicetree may in fact be left out if it can be
> > > +guaranteed that it will receive one from another project.
> > > +
> > > +In this case, the devicetree in the other project must track U-Boot's use of
> > > +device tree, for the following reasons:
> >
> > Currently it is Linux that sets the standards not U-Boot.
>
> Well no, Linux isn't supposed to set "the standard" here either.  It's
> OS-agnostic.

Right.

>
> > U-Boot can apply an overlay to the devicetree provided by the prior boot
> > stage. We should not try to force any U-Boot specific stuff onto other
> > projects.
>
> We should, when applicable, submit our bindings upstream just like any
> other project.  We also want to make sure that when we do so, we hold
> ourselves to a high standard.

I wonder if should just try just try that again, just to see what
happens. I vaguely remember the UART clock thing from many years ago,
being told that we should just probe the whole clock driver and then
have a debug UART...

But it really isn't up to Linux to refuse to accept U-Boot bindings,
IMO. U-Boot has much right to u-boot, as Linux does to linux,

>
> > > +- U-Boot only has one devicetree. See `Why not have two devicetrees?`_.
> > > +- For a consistent firmware build, decisions made in early stages should be
> > > +  communicated to later ones at runtime. For example, if the serial console is
> > > +  enabled in an early stage, it should be enabled in U-Boot too.
> > > +- U-Boot is quite capable of managing its own copy of the devicetree. If
> > > +  another project wants to bypass this (often for good reason), it is reasonable
> > > +  that it should take on the (fairly small) requirements that U-Boot features
> > > +  that rely on devicetree are still available
> > > +- The point here is not that *U-Boot needs this extra node*, or *U-Boot needs
> > > +  to have this public key*. These features are present in U-Boot in service of
> > > +  the entire firmware system. If the U-Boot features are used, but cannot be
> > > +  supported in the normal way, then there is pressure to implement these
> > > +  features in other ways. In the end, we would have a different mechanism for
> > > +  every other project that uses U-Boot. This introduces duplicate ways of doing
> > > +  the same thing, needlessly increases the complexity of the U-Boot source code,
> > > +  forces authors to consider parallel implementations when writing new features,
> > > +  makes U-Boot harder to test, complicates documentation and confuses the
> > > +  runtime flow of U-Boot. If every board did things its own way rather than
> > > +  contributing to the common code, U-Boot would lose a lot of its cross-platform
> > > +  value.
> >
> > This paragraph is incomprehensible for me.
> >
> > If both the prior boot stage and U-Boot comply to the standards set by
> > Linux we are fine. Any U-Boot quirks should be kept out of other projects.
>
> It's not the "Linux" device tree.  It's the device tree for the system.

Yes, the whole system, and U-Boot is an important part of it.

Regards,
Simon


More information about the U-Boot mailing list