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

[Tom Rini]

On Wed, Nov 03, 2021 at 10:45:11AM -0600, Simon Glass wrote:
> 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.

I think because it wasn't clear enough at the time how to say "just use
the dtb given to us as-is".

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

I mean the case where U-Boot is provided the device tree to use, by
whatever external and non-U-Boot means.  I keep saying "source of truth"
as a way to clarify that the correct and only required device tree is
given to us at run time.  If U-Boot needs to know something, it's
already provided there.  If it's not there, we don't need to know it.
This is also why there's not a reason to normally build a device tree
in U-Boot since it will not be used.  And if we aren't building it, we
don't need it in the source tree either since it's going to introduce
confusion.  Quoted in part or referenced under doc/ ?  OK, that can make
sense in some cases.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211103/4d75d50e/attachment.sig>