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

Wed Nov 3 18:36:02 CET 2021

> From: Simon Glass <sjg at chromium.org>
> Date: Wed, 3 Nov 2021 10:45:42 -0600
> 
> 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.

I'm looking at this from the perspective of the Apple M1.  But please
no.  That would only tempt users to flip the switch resulting in a
non-bootable system.

> If not, there is no way to use the U-Boot deivcetree.

There is no way to use the U-Boot devicetree on these boards, because
it is incomplete.  And the code to fill in the missing bits lives
somewhere else.

> I cannot build it in-tree. I cannot make U-Boot use it. It's just a mess.

Correct.  So putting the device tree in the U-Boot repository makes no sense.

> 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?

Of course not.  The repository that contains the DT sources will have
the infrastructure to do that for you.

> 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.

And the way I test things is that I build the device tree, load it
together with the U-Boot binary into m1n1 over serial or USB and run it.

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

Maybe because you're continuously telling is we're doing it wrong and
must do it your way?

> What is so wrong with having a devicetree in U-Boot for building?

This sounds like you want to make having a devicetree in the actual
U-Boot a hard requirement.  And that makes no sense to me for the
Apple M1 systems.

> 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.

They're not special; just different.