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

[Simon Glass]

Hi Tom,

On Wed, 27 Oct 2021 at 13:25, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote:
> > 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.
>
> That we have to have so many separate rpi build targets, and can't just
> use rpm_arm64 and add rpi_arm32 is not a good feature.  The various rpi
> configs that use CONFIG_OF_EMBED are on your list of things that need to
> be cleaned up, yes?

Yes, it should use CONFIG_OF_SEPARATE. It think it didn't for
historical reasons, but not sure why.

>
> > 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.
>
> What I don't understand here is why or how U-Boot is supposed to become
> the source of truth for device trees.  The general goal is that the
> device tree be something that actually comes along on the hardware,
> because it's stable enough and correct enough that it's not going to be
> changed from one OS kernel release to the next.  That should be where
> the correct and true tree comes from, the device itself.

Is that the confusion here? I am not saying that U-Boot becomes the
'source of truth' (horrible term). Where did that idea come from?

By hardware you mean firmware, I think. If you are developing
firmware, you need control of the devicetree. It is part of the
firmware.

Regards,
Simon