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

4 files changed, 59 insertions, 3 deletions

diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 7c24e294100..16f66388eb1 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality:
 
 Additionally, a number of optional peripherals can be added to the PCI bus.
 
+See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
+the devicetree actually generated by QEMU.
+
 Building U-Boot
 ---------------
 Set the CROSS_COMPILE environment variable as usual, and run:
@@ -41,14 +44,15 @@ The minimal QEMU command line to get U-Boot up and running is:
 
 - For ARM::
 
-    qemu-system-arm -machine virt -bios u-boot.bin
+    qemu-system-arm -machine virt -nographic -bios u-boot.bin
 
 - For AArch64::
 
-    qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin
+    qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios u-boot.bin
 
 Note that for some odd reason qemu-system-aarch64 needs to be explicitly
-told to use a 64-bit CPU or it will boot in 32-bit mode.
+told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument
+ensures that output appears on the terminal. Use Ctrl-A X to quit.
 
 Additional persistent U-boot environment support can be added as follows:
 
diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst
index 4b8e104a215..3409fff8117 100644
--- a/doc/board/emulation/qemu-riscv.rst
+++ b/doc/board/emulation/qemu-riscv.rst
@@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for
 the VirtIO standard networking and block storage devices. It has CLINT, PLIC,
 16550A UART devices in addition to VirtIO and it also uses device-tree to pass
 configuration information to guest software. It implements RISC-V privileged
+
+See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
+the devicetree actually generated by QEMU.
 architecture spec v1.10.
 
 Building U-Boot
diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst
new file mode 100644
index 00000000000..c25c4fb053d
--- /dev/null
+++ b/doc/develop/devicetree/dt_qemu.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Devicetree in QEMU
+==================
+
+For QEMU on ARM, RISC-V and one PPC target, the devicetree is created on-the-fly
+by QEMU. It is intended for use in Linux but can be used by U-Boot also, so long
+as any nodes/properties needed by U-Boot are merged in.
+
+When `CONFIG_OF_BOARD` is enabled
+
+
+Obtaining the QEMU devicetree
+-----------------------------
+
+Where QEMU generates its own devicetree to pass to U-Boot tou can use
+`-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
+
+To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`,
+e.g.::
+
+    qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb
+
+    qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
+
+    qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb
+
+
+Merging in U-Boot nodes/properties
+----------------------------------
+
+Various U-Boot features require nodes and properties in the U-Boot devicetree
+and at present QEMU is unaware of these. To use these you must manually merge
+in the appropriate pieces.
+
+One way to do this is with dtc. This command runs dtc on each .dtb file in turn,
+to produce a text file. It drops the duplicate header on the qemu one. Then it
+joins them up and runs them through dtc to compile the output::
+
+    qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb
+    cat  <(dtc -I dtb qemu.dtb) <(dtc -I dtb  u-boot.dtb |grep -v /dts-v1/) |dtc - -o merged.dtb
+
+You can then run qemu with the merged devicetree, e.g.::
+
+    qemu-system-arm -machine virt -nographic -bios u-boot.bin -dtb merged.dtb
+
+Note that there seems to be a bug in some versions of qemu where the output of
+dumpdtb does not quite match what is provided to U-Boot.
diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst
index fa5db3eb76e..2edb69572dd 100644
--- a/doc/develop/devicetree/index.rst
+++ b/doc/develop/devicetree/index.rst
@@ -11,3 +11,4 @@ build-time and runtime configuration.
 
    intro
    control
+   dt_qemu