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

[Simon Glass]

Hi Mark,

On Sat, 4 Dec 2021 at 09:09, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Sat, 4 Dec 2021 08:20:55 -0700
> >
> > Hi Tom,
> >
> > On Sat, 4 Dec 2021 at 06:52, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > 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".
> >
> > 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?
>
> Try it on your M1 Mac.

I have tested this series on a Mac Mini and it works fine.

You cannot run U-Boot by itself, of course, since it needs m1n1. Also
m1n1 fixes up the DT. I'm not sure exactly what changes it makes, as I
don't even have a serial console on the machine at present. But in any
case, I can easily iterate on U-Boot on this platform with U-Boot
building the DTs. It certainly meets my requirements at present.

>
> > > 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.
>
> You are cheating.  If you dump the device tree passed to U-Boot (or
> the OS) and don't change anything in the configuration of whatever is
> passing U-Boot that device tree this is likely to work fine.  But it
> won't work in general.

I didn't say it would. What are you getting at?

Can you please try to test my series so you get the hang of what it is
actually doing?

>
> > > > > > 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.
> >
> > 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.
>
> No, Apple M1 and Raspberry Pi 4 also fall into that case.  And I
> suspect at least some of the other boards that currently defined
> OF_BOARD fall into this category.  So rather than changing the meaning
> of OF_BOARD, how about introducing another Kconfig option that
> indicates that switching to a device tree built into U-Boot is ok?
> You could use that to implement the runtime switching that you desire.
> This would prevent confusing users with options that result in making
> their systems unusable.

Yes Tom and I have already discussed doing that, along with various
other measures to avoid people doing the wrong thing.

>
> > > > > 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.
>
> No Raspberry Pi (all models) and Apple M1 are also dynamic.  And there
> are probably a few more that I'm not familliar with.  We've explain
> how these are dynamic in this thread and earlier discussions many
> times already, but I can do it again if you need me to.

So long as the DT is available in U-Boot and we can do development
there, I am happy. It is when it comes from somewhere else and we need
to do investigation just to be able to figure it out, I am not happy.

[..]

Regards,
Simon