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

[Simon Glass]

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?

I am not talking about disabling OF_BOARD, just making it *possible* to do so.

Regards,
Simon