Merge branch '2021-12-23-make-OF_BOARD-a-boolean' into next

Merge v8 of Simon's series to make CONFIG_OF_BOARD a boolean option.
Quoting him:

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 were covered in another patch[1], since
removed from this series.

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 would allow
rpi3, for example, to run with the devicetree provided by the prior
bootloader.

This series makes this change, adding various missing devicetree files
(and placeholders) to make the build work.

To make the 'prior stage' side of things more deterministic, a new
OF_HAS_PRIOR_STAGE is added, which cannot be disabled by updated a board's
defconfig. This should help to prevent mistakes.

It also adds a run-time message showing where the devicetree came from,
as well as warnings if the board's expected flow is not being used. This
comes originally from the 'standard passage' series, which depends on
this series.

It also provides a few qemu clean-ups discovered along the way. The
qemu-riscv64_spl problem is fixed.

Please see [2] for discussion on the v6 series.

I put Heinrich's Tested-by tag[3] for the series onto the three devicetree
patches (ARM and RISC-V) that I think it most affects. It isn't possible
to apply a tag to a whole series at present and in any case there are
changes in v7.

This series is available at u-boot-dm/ofb-working

[1] https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
[2] https://lore.kernel.org/u-boot/20211205133207.GW1220664@bill-the-cat/T/#mcd8c0258827fbc1bb3000b7ff9ba0929df1ddcb2
[3] https://lore.kernel.org/u-boot/[email protected]/raw

1 files changed, 8 insertions, 26 deletions

diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index 10389a52c4b..3e063d1f86c 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -232,26 +232,6 @@ You can use other, more specific CONFIG options - see 'Automatic .dtsi
 inclusion' below.
 
 
-Using binman with OF_BOARD
---------------------------------------------
-
-Normally binman is used with a board configured with OF_SEPARATE or OF_EMBED.
-This is a typical scenario where a device tree source that contains the binman
-node is provided in the arch/<arch>/dts directory for a specific board.
-
-However for a board configured with OF_BOARD, no device tree blob is provided
-in the U-Boot build phase hence the binman node information is not available.
-In order to support such use case, a new Kconfig option BINMAN_STANDALONE_FDT
-is introduced, to tell the build system that a standalone device tree blob
-containing binman node is explicitly required.
-
-Note there is a Kconfig option BINMAN_FDT which enables U-Boot run time to
-access information about binman entries, stored in the device tree in a binman
-node. Generally speaking, this option makes sense for OF_SEPARATE or OF_EMBED.
-For the other OF_CONTROL methods, it's quite possible binman node is not
-available as binman is invoked during the build phase, thus this option is not
-turned on by default for these OF_CONTROL methods.
-
 Access to binman entry offsets at run time (symbols)
 ----------------------------------------------------
 
@@ -810,12 +790,14 @@ Binman will search for the following files in arch/<arch>/dts::
 
 U-Boot will only use the first one that it finds. If you need to include a
 more general file you can do that from the more specific file using #include.
-If you are having trouble figuring out what is going on, you can uncomment
-the 'warning' line in scripts/Makefile.lib to see what it has found::
-
-   # Uncomment for debugging
-   # This shows all the files that were considered and the one that we chose.
-   # u_boot_dtsi_options_debug = $(u_boot_dtsi_options_raw)
+If you are having trouble figuring out what is going on, you can use
+`DEVICE_TREE_DEBUG=1` with your build::
+
+   make DEVICE_TREE_DEBUG=1
+   scripts/Makefile.lib:334: Automatic .dtsi inclusion: options:
+     arch/arm/dts/juno-r2-u-boot.dtsi arch/arm/dts/-u-boot.dtsi
+     arch/arm/dts/armv8-u-boot.dtsi arch/arm/dts/armltd-u-boot.dtsi
+     arch/arm/dts/u-boot.dtsi ... found: "arch/arm/dts/juno-r2-u-boot.dtsi"
 
 
 Updating an ELF file