[PATCH v5 00/26] fdt: Make OF_BOARD a boolean option

[Simon Glass]

Hi Tom,

On Wed, 3 Nov 2021 at 10:02, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote:
> > > From: Simon Glass <sjg at chromium.org>
> > > Date: Tue, 2 Nov 2021 19:20:51 -0600
> > >
> > > Hi Mark,
> > >
> > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > > >
> > > > > From: Simon Glass <sjg at chromium.org>
> > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600
> > > > >
> > > > > Hi François,
> > > > >
> > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog at linaro.org> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg at chromium.org> wrote:
> > > > > >>
> > > > > >> Hi François,
> > > > > >>
> > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.ozog at linaro.org> wrote:
> > > > > >> >
> > > > > >> > Hi Simon
> > > > > >> >
> > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable.
> > > > > >>
> > > > > >> I think we are going to have to disagree on this one. I actually used
> > > > > >> the qemu one in testing/development recently. We have to have a way to
> > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use
> > > > > >> cases, so far as I know.
> > > > > >
> > > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing.
> > > > > > I understand the advanced debug/development scenario you mention.
> > > > > > But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms.
> > > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot.
> > > > >
> > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone
> > > > > has noticed. U-Boot handles the build automatically. If you turn off
> > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is
> > > > > going on.
> > > >
> > > > Until.  The Raspberry Pi foundation releases a new firmware that
> > > > configures the hardware differently such that the addresses in the
> > > > U-Boot devicetree are wrong and nothing works anymore.  Can't speak
> > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3
> > > > as well as more recently on the rpi 4.
> > >
> > > So I update my SD card with a new private-binary bootloader and things
> > > stop working? I think I can narrow that one down :-)
> > >
> > > > > We can add a message to U-Boot indicating where the devicetree came
> > > > > from, perhaps? That might be useful given everything that is going on.
> > > > >
> > > > > As in this case, quite often in these discussions I struggle to
> > > > > understand what is behind the objection. Is it that your customers are
> > > > > demanding that devicetrees become private, secret data, not included
> > > > > in open-source projects? Or is it just the strange case of QEMU that
> > > > > is informing your thinking? I know of at least one project where the
> > > > > first-stage bootloader produces a devicetree and no one has the source
> > > > > for it. I believe TF-A was created for licensing reasons...so can you
> > > > > be a bit clearer about what the problem actually is? If a board is
> > > > > in-tree in U-Boot I would like it to have a devicetree there, at least
> > > > > until we have a better option. At the very least, it MUST be
> > > > > discoverable and it must be possible to undertake U-Boot development
> > > > > easily without a lot of messing around.
> > > >
> > > > How many people are there out there that work on U-Boot that don't
> > > > have a Linux source tree checked out?  Even I have several of those
> > > > lying around on my development systems and I am an OpenBSD developer ;).
> > >
> > > So it is OK to have the DT in Linux but not in U-Boot? I don't even
> > > know what to say that. How does that square with your point above?
> >
> > Ideally the DT's and DT binding would move out of the Linux tree and
> > into a repository of their own.  But until that is the case, the Linux
> > tree is the source of truth.
>
> Yes, and this is a long known and slowly in progress kinda-sorta thing.
> A few more people helping to review things, etc, are always appreciated
> by upstream.
>
> > > I am not talking about disabling OF_BOARD, just making it *possible*
> > > to do so.
> >
> > And I don't think it makes sense to do so on most boards that have
> > OF_BOARD in their config.
>
> It should probably close to never be done, unless it's some case where
> it's crazy-hard to update the device tree correctly for the platform.
> So it's not a problem on Pi as it's just on the FAT32 partition right
> there, it's not a problem on Apple M1 as ..however you do it.., and so
> on.
>
> I can almost hear the argument from here about "but I'm doing some work
> for U-Boot and need to add..." and that's where we need to figure out
> what to do next.  Yes, we likely need to have some bindings of our own,
> and developing those AND pushing them upstream will require iterating
> here.  So the developer point of view of how do I whack things to supply
> my own is valid.  But it's not the default use case.  The default use
> case is building the firmware that users rarely see, because their
> system boots to the OS and they get down to using their system.

I believe that OF_BOARD needs to become a runtime option. If not,
there is no way to use the U-Boot deivcetree. I cannot build it
in-tree. I cannot make U-Boot use it. It's just a mess. So we are
supposed to run dtc manually to ge tthe DT, then copy it manually,
then deal with the include files it needs and the C preprocessing it
needs for the bindings? Why make this so hard? It just makes no sense
to me.

We are making this 'odd' case into the main case. It isn't. If it
becomes it one day, I hope we are in a better place with devicetree.
Upstreaming bindings is one thing, but we need to develop and test,
first.

I really don't understand why this is generating so much discussion.
How can we get this moving?

What is so wrong with having a devicetree in U-Boot for building? Why
are these boards so special? And what problem does it cause? The only
one I have heard is confusion, which I think I have addressed.

Regards,
SImon