Hi Tom,
On Wed, 3 Nov 2021 at 09:56, Tom Rini trini@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.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@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.ozog@linaro.org wrote:
On Wed, 27 Oct 2021 at 16:08, Simon Glass sjg@chromium.org wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog francois.ozog@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