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

[Tom Rini]

On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 3 Dec 2021 at 08:57, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 3 Dec 2021 at 07:55, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > >
> > > > > 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.
> > > >
> > > > Note that I can't run-time test this as the last patch fails to apply
> > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > and that's part of the unchanging context where things fail to apply).
> > >
> > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > -next and is at dm/ofb-working if you want to compare.
> >
> > I just fetch'd and built that instead, thanks.
> >
> > > > So, here's my first bit of confusion.  Today, I build for rpi_arm64 and
> > > > no dtb files are built.  I run this on my Pi 3 and everything works.
> > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > > u-boot.dtb have a Pi 4 dtb in them.  Should this even run now?
> > >
> > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > is basically the same as the situation with rpi3, except it uses
> > > OF_EMBED (need to fix...)
> >
> > OK, so my Pi 3 still boots on rpi_arm64, good.  But why did I embed a
> > rpi4 device tree to u-boot.bin ?  CONFIG_OF_BOARD=y is set in the
> > .config, so I'm telling it to use the run-time device tree.  It will
> > never ever use this dtb, under any circumstance, right?
> 
> That's right, unless you disable OF_BOARD and build U-Boot again.

And then it would fail to boot, because I'm on a 3, not a 4.

> Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> I didn't even know that...yet another example of the confusion of the
> current state.

So, I'm trying to use this example here to lead to what I think is a
reasonable compromise.  As you note, with CONFIG_OF_BOARD=y all of those
built trees, and the embedded tree, will not ever be used.  But it makes
the make logic a tiny bit easier to have some tree, not no tree.  Why
can't we:
- When CONFIG_OF_BOARD=y not build those trees as part of "all"
  (individual rules should still work).
- For linking, use an empty minimal valid dts.

Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration
to know what device tree you want it to even use if you disable
CONFIG_OF_BOARD.  You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is
correct, which is why it's unset currently.

Does this make sense?  If not, why not?  And I have thoughts about other
platforms too, but I want to stick with a fairly concrete example first.

-- 
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/20211203/ae84e7dd/attachment.sig>