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

[Simon Glass]

Hi Ilias,

On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Simon,
>
> [...]
> > > [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.
> > >
>
> I am not convinced the case is "we are developing something".  The
> arguments for this are something along the lines of:
> 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide
> no DT so we need to include it.  With which I disagree.  The config option
> says "You must provide an external device tree" for a reason.

Where are you reading that? I'm lost.

OF_SEPARATE means it is not embedded in U-Boot but is attached to the end of it.

> 2. The DT's are  hard to find.  The 'hard to find' RPI DTs are in fact
> committed in the kernel. I am not sure about the rest, but honestly this
> isn't a convincing argument for me.

Great, so you've solved that one but even that was confusing for me,
as my patch should make clear. Every single board would be its own
special snowflake if we went that way.

So if they are in the kernel, we just need to put them in U-Boot too,
so problem solved. The auto-sync thing that I believe Rob is working
on will make things easy.

>
> What else are we gaining with it being a run time choice?  One of the

We are requiring a DT to be present in the U-Boot tree for
development, documentation and discoverability purposes. Devs can turn
OF_BOARD on and off as it suits them when iterating on a platform.

> things this approach does address, but we keep conveniently ignoring, is
> that it tries to preserve the current status quo.  You can go and add the
> special missing U-Boot nodes in those DT's.  So that would bypass problems
> if the bindings get NAK'ed.  But this is going to work against the
> fragmentation we are trying to resolve.

Well that's another reason why we need in-tree DTs at the moment. That
reason goes away once we have our bindings upstream and are able to do
what we need with DT there.

>
> > > 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".
> >
> > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > even added a test with it. What am I missing?

(I think my point there is made)

>
> IMHO 3b595da441cf is the commit that started the problem and tangled those
> 2 options.  Note that this support has been removed from the dragonboard
> later in 0204d1b56b2f ....

Yes it is one of them. There may be cases where we want to patch up
the DT that U-Boot builds. In fact OF_BOARD does not mean it came from
a prior stage. All sorts of things could be going on. We should not
conflate building a DT with OF_BOARD.

>
> >
> > >
> > > 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.
> >
> > Aren't you talking about the distro DT there, rather than the the one
> > on the boot disk? That is my reading of that patch. If we need to do
> > that sort of thing, it doesn't matter where the the cointrol DT comes
> > from. You are still going to have to do that sort of thing.
> >
> > It is not ALWAYS the case. I've shown you how easy it is to disable
> > OF_BOARD and still boot / iterate.
> >
> > >
> > > > > > 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.
>
> So the translation of this for me is:
> We have 2 discrete options (that can be cleaned up further) which choose
> either to embed or receive the DTB.  Let's tangle them and introduce a
> *new* third option to separate them if someone needs to.  Which makes no
> sense to me.

Embed is confusing because OF_EMBED means to link it into U-Boot (just
used for debugging)

I think this is the core of the problem. There are just lots of ideas
about how all of this should work. Please try out the series and see
if you find any problems. Then we can talk about actual issues rather
than things that might happen.

The two options you refer to are OF_SEPARATE and OF_BOARD. We will
perhaps have OF_PASSAGE at some point. We already have OF_EMBED.

To me, OF_BOARD and OF_PASSAGE are run-time things because they
indicate what we expect to happen at runtime. If something goes wrong,
we might still be able to print an error message, if we have a backup
DT.

But OF_BOARD and OF_PASSAGE are not related to the build itself. IMO
OF_BOARD is underspecified. One day I would like to move towards
defining these cases better, e.g.

- DT is passed in a register (rpi and apple_m1, stm32mp, RISC-V, qemu
RISC-V, bcmstb, Octeon, Xen)
- DT is at a fixed address (qemu, highbank, socrates, qemu ppc)
- DT is in a file (sandbox)

IMO many of these could all be handled with standard passage, i.e. in
a standard way.

>
> > >
> > > 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.
> >
> > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > case, I think. How about we create a special Kconfig for that case? We
> > need to make some progress here.
> >
> > >
> > > > > 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.
> >
> > So let's require that the static ones have the Linux DT in our tree
> > for now. The dynamic ones are just QEMU for ARM and Xen, I think. If
> > that's it then I can agree a special case for them, so long as we sort
> > out the docs for Xen.
> >
> > >
> > > > 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.
> >
> > I'd like to think more people accept that U-Boot is allowed its own
> > properties than did at the start.
> >
> > >
> > > > 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.
> >
> > I'm OK with us copying in the Linux devicetree and using that. But
> > OF_BOARD must be a run-time option and able to be disabled. The
> > devicetree must be built, so it is actually real. We can have a
> > separate OF_OMIT or something like that to omit the devicetree from
> > the output image, perhaps.
> >
> > All of the other things need to wait until we make progress with
> > devicetree bindings, validation,
> >
> > How can we make progress on this? We have different goals, as I have
> > explained, so we are not going to agree on everything.

Regards,
Simon