> From: Simon Glass <s...@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.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.
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. > 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 ;).