Hi Mark, On Wed, 27 Oct 2021 at 16:30, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > 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.
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
