Hi Tom, On Wed, 3 Nov 2021 at 09:56, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote: > > 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 :-) > > Well, wait, no, this is the point. You can just not update your board. > But that all of the users running a more recent release are now broken > is the problem. It's already an opt-in thing to use U-Boot on Pis and > if we make it even more annoying to be recent, there'll be even less > reason to use U-Boot over over the Pi+TianoCore if you want anything > more fancy that direct-to-Linux booting.
This is all totally in the weeds at this point. What are you referring to? I'm talking about turning off OF_BOARD in my private build of U-Boot so that it picks up the devicetree built with U-Boot. I thought that was what Mark was saying...? Regards, Simon
