incompatible device trees between u-boot and linux

[Mark Kettenis]

> Date: Wed, 25 Aug 2021 18:12:20 +0300
> From: Vladimir Oltean <olteanv at gmail.com>
> 
> On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> > > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I noticed that there is a fallback to the u-boot device tree
> > > > > for linux (esp. EFI boot) if no other device tree was found,
> > > > > see [1]. It seems this is working fine for imx devices, for
> > > > > example, where you can just boot a stock installer iso via
> > > > > EFI. It will just work and it is quite a nice feature as a
> > > > > fallback.
> > > > >
> > > > > Now for the layerscape architecture, the ls1028a in my case,
> > > > > things are more difficult because the bindings differ
> > > > > between u-boot and linux - one which comes to mind is DSA
> > > > > and ethernet.
> > > > >
> > > > > Which begs the general question, is it encouraged to have
> > > > > both bindings diverge? To me it seems, that most bindings in
> > > > > u-boot are ad-hoc and there is no real review or alignment
> > > > > but just added as needed, which is ok if they are local to
> > > > > u-boot. But since they are nowadays passed to linux (by
> > > > > default!) I'm not so sure anymore.
> > > > >
> > > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi
> > > > > looks like they should (could?) be shared between linux and
> > > > > u-boot.
> > > > >
> > > > > -michael
> > > > >
> > > > > [1]
> > > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> > > >
> > > > The U-Boot device tree is supposed to be able to be passed on
> > > > to Linux and Just Work.  The bindings are not supposed to be
> > > > different between the two (except for when we take the binding
> > > > while it's being hashed out upstream BUT THEN RESYNCED).
> > >
> > > You might need to spell that out a bit clearer.
> > >
> > > You are saying that both U-Boot and Linux are allowed to have
> > > their own custom properties (like 'u-boot,dm-spl' for U-Boot,
> > > and 'managed = "in-band-status"' for Linux), as long as the
> > > device tree files themselves are in sync, and the subset of the
> > > device tree blob understood by Linux (i.e. the U-Boot blob sans
> > > the U-Boot specifics) is compatible with the Linux DT blob?
> >
> > I don't know what about the Linux example makes it Linux specific.  But
> > yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> > by Linux.  The whole reason we have the -u-boot.dtsi automatic drop-in
> > logic (as much as it can be used is that device trees are device trees
>         ^
>         I don't think this parenthesis ever closes...
> 
> > and describe the hardware and developers don't need to write a device
> > tree for Linux and a device tree for U-Boot and a device tree for
> > FreeBSD and ...  So yes, you're supposed to use the device tree for a
>                 ^
>                 so I never get the answer to "the whole reason is...".
> 
> > platform and it works here and there and every where.
> 
> The fact that only Linux uses it makes it Linux specific.

Huh?  Other OSes use device trees as well on various platforms.  There
are (somewhat) linux-specific properties in those device trees in the
"linux," namespace.

For OpenBSD we don't maintain our own set of device trees.  Instead we
rely on the device tree provided by U-Boot and distribute device trees
built from the Linux tree as an alternative that users can install if
the U-Boot device tree is a bit behind.

> > > To expand even further on that, it means we should put 'managed
> > > = "in-band-status"' in U-Boot, which is a Linux phylink device
> > > tree property, even if U-Boot does not use phylink?
> >
> > We should be able to drop in the device trees from Linux and use them.
> > Custodians should be re-syncing them periodically.  Some are, even.
> 
> Are you ready to take up device tree bindings for PTP timers, PCIe root
> complex event collectors, cascaded interrupt controllers, things which
> U-Boot will never ever need to support?

The policy is that U-Boot uses a verbatim copy of the device tree
source files from Linux (.dts and .dtsi files) and augments that
device tree if necessary by using a *-u-boot.dts files that ideally
only add properties in the "u-boot," namespace.

That policy isn't always followed though.  In some cases support for
certain hardware is added to U-Boot early, before "official" DT
bindings have been established.  These should be replaced with the
"official" device tree from Linux as soon as possible, but that
doesn't always happen in a timely fashion.

Unfortunately what happens quite often is that hardware vendors
provide patches with preliminary bindings from their own Linux fork
before their devices are fully supported in the mainline Linux tree.

What also happens is that the DT bindings in mainline Linux evolve
over time.  Sometimes there is a good reason for that, but in other
cases maintainers seem to be a little bit too eager to "clean things"
up in a way that breaks backwards compatibility.

> At least in Linux there is a policy to not add device tree nodes that do
> not have drivers. Is the same policy not true for U-Boot? At least your
> ./scripts/checkpatch.pl does have the same "check for DT compatible
> documentation" section as Linux. You might consider removing it if you
> want people to not strip the DTs they submit to U-Boot.

There is no such policy in U-Boot.  And even in Linux the devicetree
maintainers seem to be willing to accept DT bindings and nodes for
things that have a driver elsewhere.

> And why do we even maintain the device tree bindings in Linux at
> all?  It seems rather counter-productive for both ends to do that,
> if it is expected that the kernel works with DT blobs provided by
> third parties too, and if all third parties need to resync with it
> (there are other boot loaders too beyond U-Boot, and other kernels
> beyond Linux). Somehow it doesn't feel right for the reference to be
> the Linux kernel. Maybe this is something that needs to be brought
> up with higher-level Linux maintainers.

IMHO it would be a good idea if the device trees would be maintained
in a separate source tree from the Linux kernel.

> I have no problem at all with structuring the device tree in the same
> way in U-Boot as in Linux, as long as that proves to not be a foolish
> endeavor.

As I said above, U-Boot should simply use a verbatim copy of the Linux
device tree.