incompatible device trees between u-boot and linux

[Tom Rini]

On Wed, Aug 25, 2021 at 06:12:20PM +0300, Vladimir Oltean wrote:
> 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...

Ah, whoops.  Should have been "(as much as it can be used)" because it
does get #included instead in some cases, for reasons.

> 
> > 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.
> 
> > > 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?
> 
> 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.
> 
> 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.
> 
> 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.

DT is ABI is hardware description and OS-agnostic has been the rule for
10+ years.  If that's no longer the case, can someone please tell me?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210825/e86bd79e/attachment.sig>