Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]