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

[François Ozog]

Hi Simon

Le sam. 4 déc. 2021 à 18:35, Simon Glass <sjg at chromium.org> a écrit :

> Hi François,
>
> On Sat, 4 Dec 2021 at 09:55, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le sam. 4 déc. 2021 à 16:21, Simon Glass <sjg at chromium.org> a écrit :
> >>
> >> 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?
> >>
> >> >
> >> > 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.
> >> >
> >> > 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.
> >
> > there is no question that U-Boot can have its properties specified in
> Device Tree.
>
> I am pretty sure you were on the other side of that fence at some
> point. I know quite a few others that still are.
>
> > What we may not agree in is how those properties make it to U-Boot.
>
> Yes but that is just the next step along in my progression in that
> email ('why can't we just...' to 'this is how U-Boot works'). From
> memory there are 3 more steps.
>
> >>
> >>
> >>
> >> >
> >> > > 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.
> >
> > A V7 with empty device trees (except with comments to explain why they
> are empty and how to force one for dev purposes) for platforms that provide
> U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can
> propose a better way forward. If we build consensus on the feature aspect
> of the patch set I will be able to dedicate some time on the documentation
> part as I thought it was useless to check those until we agree on the
> functional part.
>
> That's the status quo, so it doesn't resolve any of my concerns,
> sorry. I suggest:
>
You make progress on various front that can get consensus in a number of
your patches, so it it not status quo.

>
> - Check in all the DTs we can get (e.g. from Linux), and build them

doesn’t change anytime. RPI4 DT in the kernel is not be used anyways.

>
> - Use an empty one if we cannot find it, and ask the maintainer to add
> docs and deal with it
> - For QEMU arm and QEMU RISC-V (i.e. the 'virt' case), use a base one
> that works with the base QEMU config
>
> We then have the follow-ons that Tom and I have discussed, e.g. the
> Kconfig option that Mark mentioned.
>
> That will clear up all the confusion and provide a baseline for how DT
> is dealt with in U-Boot.
>
> We should then continue on the path towards upstreaming bindings,
> syncing DT with Linux, validation, removing them from U-Boot if we can
> automatically download them all from somewhere, etc.
>
> The thing is, I think people are more aligned on the eventual goal
> than on this series.

I’d interested to know that. Should we ask +1, -1, -2 for the patches?

> My concern is that without this series, it will
> continue to be crazy-town and no one will be able to find anything
> without manual effort. For those of us who deal with more than one
> platform, this is an important point.
>
> Regards,
> Simon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog