[PATCH v6 00/25] fdt: Make OF_BOARD a boolean option

[Tom Rini]

On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:

[huge snip]
> > There's things that need to be cleaned up because we have some small
> > number of platforms that went off and did their own thing.  But largely
> > yes, things make sense to me.  We have:
> > - We embedded the device tree that will configure U-Boot, because there
> >   is no way for the hardware to have provided us one.
> > - We do not embed the device tree that will configure U-Boot, because
> >   there is already one present in memory for us to use.
> >
> > Then we have the developer option of:
> > - We embedded the device tree that will configure U-Boot, because we're
> >   developing something.
> 
> Yes, agreed those are the cases. To me this needs to be a run-time choice.

But it's not possible.  That's the problem we keep going around and
around about.  People keep raising real life examples where you cannot
make a run time choice between "device tree we're passed at run time"
and "device tree we're compiled with".

And it's not helpful.  It is ALWAYS the case that we know that we want
to override the run time device tree with our own, because it's a
developer developing things or it's a user / production case where we
must use the provided tree.  NOT doing that is what leads to madness
like we see for example on Pi where if we don't use the passed tree we
still need to copy X/Y/Z out of it.

> > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should
> > > provide a way to do that? But what is driving that desire?
> >
> > I'm looking for ways to convince you that we do not need to include a
> > device tree in the binary.  There's a growing set of devices where the
> > device tree exists with the device.  If it's missing, that's a huge
> > fatal error we can't do all that much about.  If we need to do something
> > to that device tree for U-Boot, yes, fine, we should make it straight
> > forward for the developer to do that.  But that's not the common case!
> 
> Well we could add another Kconfig which tells U-Boot not to include a
> devicetree in u-boot.bin, if that would resolve this?
> 
> I just want to make sure that we always build the devicetrees and that
> it is easy for a knowledgeable dev to switch over to use them, without
> spelunking through dozens of other projects to discover the secret DT
> that no one will tell us about.

Should we demand better documentation for boards?  Yes.  But it's still
a valid case to have zero device trees for a given platform in-tree.
Xen is an example of this.  QEMU is an example of this.  Platforms need
to work without adding special tweaks for us.  Maybe that means some
features can't be tested in QEMU-as-virtual-platform and only in
QEMU-faithfully-emulating-specific-physical-platforms.

> > I guess another part of the problem is that historically almost all
> > platforms were in the first case I list above, no run time provided
> > device tree, so we took the kernel one and added our bindings to it.
> > Now we're being bit by the growing number of platforms that are the
> > second case, and how do we get our properties in there, and which ones
> > even make sense to do that for.
> 
> I think upstreaming the bindings is the solution there. I've made a
> start, but we need to make progress with this series and all the other
> things in flight. I think a lot of people want U-Boot to not have a
> devicetree source files in it for ARMv8 platforms. I am strongly
> opposed to that. I've laid out my reasons very clearly in the past. I
> think this is a good summary:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html

Yes, there are some ARMv8 platforms we will have to have the source
files to, in tree, because they won't come to us at run time.  But
others we won't for practical reasons, namely that we can't statically
provide something that exists dynamically without massive duplication of
code or just taking things from that passed to us tree.

> I believe I have been consistent in this although with all the
> discussion I'm really not sure anymore.

Yes, everyone has been consistent in these discussions.

> The problem is that various people have various views about how U-Boot
> should work with devicetree. I strongly believe that until we have
> bindings upstream, a central repo for DTs with easy downloading for
> builds, automated validation, among other things, we must maintain the
> devicetree in U-Boot. Just from the POV of energy expended, I do not
> want to be arguing with the Linaro folks about what U-Boot is allowed
> to do every month for the next two years. I'd rather set out the stall
> now and then deal with the problems it causes from that perspective.

The problems of the last going on 12 years won't be solved instantly.
The conflict as I see it is that you're insisting that all platforms
must have statically usable device trees, and I (and I believe others)
are saying that's unreasonable in cases where the trees are dynamic at
heart, lets just ensure we have good enough documentation for them,
which we don't today.

To be clear and pick an example, I don't want Pi dts files in U-Boot,
but, OK, it's an easy enough case to sync them up and so long as we
aren't yet at the "now we pick at run time between compiled in or passed
to us dtb", I can accept them in tree, but not in the resulting binary
for OF_CONTROL=y.  But as the Xen folks have also noted, there's no
reasonable tree to include there.  It does need to be better documented
how to fire it up however, in our sources.

-- 
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/20211204/aa808172/attachment.sig>