[PATCH v6 00/25] fdt: Make OF_BOARD a boolean option

[Tom Rini]

On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 2 Dec 2021 at 09:38, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
> > > Hi Simon
> > >
> > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg at chromium.org> a écrit :
> > >
> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > > there are only three ways to obtain a devicetree:
> > > >
> > > >    - OF_SEPARATE - the normal way, where the devicetree is built and
> > > >       appended to U-Boot
> > > >    - OF_EMBED - for development purposes, the devicetree is embedded in
> > > >       the ELF file (also used for EFI)
> > > >    - OF_BOARD - the board figures it out on its own
> > > >
> > > > The last one is currently set up so that no devicetree is needed at all
> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > > > don't even provide instructions on how to boot on the board.
> > > >
> > > > The problems with this approach are documented in another patch in this
> > > > series: "doc: Add documentation about devicetree usage"
> > > >
> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > > > can obtain its devicetree at runtime, even it is has a devicetree built
> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > > > caller may have a better idea about the hardware available in the machine.
> > > > This is the case with a few QEMU boards, for example.
> > > >
> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > > > option, available with either OF_SEPARATE or OF_EMBED.
> > > >
> > > > This series makes this change, adding various missing devicetree files
> > > > (and placeholders) to make the build work.
> > > >
> > > > Note: If board maintainers are able to add their own patch to add the
> > > > files, some patches in this series can be dropped.
> > > >
> > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > qemu-riscv64_spl problem is fixed.
> > > >
> > > > [1]
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >
> > > > Changes in v6:
> > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > - Expand the commit message based on comments
> > > > - Expand the commit message based on comments
> > >
> > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > not in favor of this new version either.
> > > If you make a version without « fake DTs » as you name them, there are good
> > > advances in the documentation and other areas that would be better in
> > > mainline….
> > > If I am the only one thinking this way and the patch can be accepted, I
> > > would love there is a warning in capital letters at the top of the DTS fake
> > > files that explains the intent of this fake DT, the possible outcomes of
> > > not using the one provided by the platform and the right way of dealing
> > > with DTs for the platform.
> >
> > This is the part that I too am still unhappy about.  I do not want
> > reference or fake or whatever device trees in the U-Boot source tree.
> > We should be able to _remove_ the ones we have, that are not required,
> > with doc/board/...rst explaining how to get / view one.  Not adding
> > more.
> 
> I understand you don't like it and that others don't as well. I wish
> it had not come to this.
> 
> However we are only talking about 10 boards, three of which don't even
> have a devicetree anywhere I can find.
> 
> I think on balance this is a substantial clean-up. I am happy to add
> whatever caveats and documentation people want to clarify what is
> going on here. I'm happy to look at future options where the
> devicetree is hosted elsewhere, so long as it is trivial to build it
> within U-Boot for development purposes.
> 
> I'll also note that the bootstd series shows the devicetree source:
> 
> Core:  246 devices, 88 uclasses, devicetree: board
> 
> But for now, I still feel this is the best path forward.

I'm not sure how to proceed here.  The reviews are rather strongly
against the "include a device tree that won't be used".  The use case of
"but for development someone might need to modify the device tree" is
handled by platforms documenting where / how to get the real one.  We
should even update the Kconfig help to note that if you enable this your
board docs MUST explain where the device tree can be seen (or have some
legal reason you think it's OK to not...).

And yes, we're "only" talking about 10 platforms, which include things
like the "everyone" has one Pi family, the extraordinarily flexible (and
so easy for the reference device tree to be very wrong) QEMU families
and then platforms that are including a dts in-tree now because they
were told that was required.

How about adjusting the make logic so that if a tree isn't found, we use
a dummy minimal valid dts file?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211202/e76b51a8/attachment.sig>