Hi Tom, On Wed, 27 Oct 2021 at 13:25, Tom Rini <tr...@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.o...@linaro.org> > > wrote: > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass <s...@chromium.org> wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog <francois.o...@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
