Merge tag 'v2022.01-rc4' into next

Prepare v2022.01-rc4

8 files changed, 136 insertions, 9 deletions

diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 584ef0a7e1..7c24e29410 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -65,7 +65,8 @@ can be enabled with the following command line parameters:
 
 - To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.::
 
-    -drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci -device ide-drive,drive=mydisk,bus=ahci.0
+    -drive if=none,file=disk.img,format=raw,id=mydisk \
+    -device ich9-ahci,id=ahci -device ide-drive,drive=mydisk,bus=ahci.0
 
 - To add an Intel E1000 network adapter, pass e.g.::
 
@@ -75,10 +76,14 @@ can be enabled with the following command line parameters:
 
     -device usb-ehci,id=ehci
 
-- To add a NVMe disk, pass e.g.::
+- To add an NVMe disk, pass e.g.::
 
     -drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo
 
+- To add a random number generator, pass e.g.::
+
+    -device virtio-rng-pci
+
 These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well.
 
 Enabling TPMv2 support
diff --git a/doc/board/highbank/highbank.rst b/doc/board/highbank/highbank.rst
new file mode 100644
index 0000000000..654ef8a026
--- /dev/null
+++ b/doc/board/highbank/highbank.rst
@@ -0,0 +1,78 @@
+Calxeda Highbank/Midway board support
+=====================================
+
+The Calxeda ECX-1000 ("Highbank") and ECX-2000 ("Midway") were ARM based
+servers, providing high-density cluster systems. A single motherboard could
+host between 12 and 48 nodes, each with their own quad-core ARMv7
+processor, private DRAM and peripherals, connected through a high-bandwith
+and low-latency "fabric" network. Multiple motherboards could be connected
+together, to extend this fabric.
+
+For the purpose of U-Boot we just care about a single node, this can be
+used as a single system, just using the fabric to connect to some Ethernet
+network. Each node boots on its own, either from a local hard disk, or
+via the network.
+
+The earlier ECX-1000 nodes ("Highbank") contain four ARM Cortex-A9 cores,
+a Cortex-M3 system controller, three 10GBit/s MACs and five SATA
+controllers. The DRAM is limited to 4GB.
+
+The later ECX-2000 nodes ("Midway") use four Cortex-A15 cores, alongside
+two Cortex-A7 management cores, and support up to 32GB of DRAM, while
+keeping the other peripherals.
+
+For the purpose of U-Boot those two SoCs are very similar, so we offer
+one build target. The subtle differences are handled at runtime.
+Calxeda as a company is long defunct, and the remaining systems are
+considered legacy at this point.
+
+Bgilding U-Boot
+---------------
+There is only one defconfig to cover both systems::
+
+    $ make highbank_defconfig
+    $ make
+
+This will create ``u-boot.bin``, which could become part of the firmware update
+package, or could be chainloaded by the existing U-Boot, see below for more
+details.
+
+Boot process
+------------
+Upon powering up a node (which would be controlled by some BMC style
+management controller on the motherboard), the system controller ("ECME")
+would start and do some system initialisation (fabric registration,
+DRAM init, clock setup). It would load the device tree binary, some secure
+monitor code (``a9boot``/``a15boot``) and a U-Boot binary from SPI flash
+into DRAM, then power up the actual application cores (ARM Cortex-A9/A15).
+They would start executing ``a9boot``/``a15boot``, registering the PSCI SMC
+handlers, then dropping into U-Boot, but in non-secure state (HYP mode on
+the A15s).
+
+U-Boot would act as a mere loader, trying to find some ``boot.scr`` file on
+the local hard disks, or reverting to PXE boot.
+
+Updating U-Boot
+---------------
+The U-Boot binary is loaded from SPI flash, which is controlled exclusively
+by the ECME. This can be reached via IPMI using the LANplus transport protocol.
+Updating the SPI flash content requires vendor specific additions to the
+IPMI protocol, support for which was never upstreamed to ipmitool or
+FreeIPMI. Some older repositories for `ipmitool`_, the `pyipmi`_ library and
+a Python `management script`_ to update the SPI flash can be found on Github.
+
+A simpler and safer way to get an up-to-date U-Boot running, is chainloading
+it via the legacy U-Boot::
+
+    $ mkimage -A arm -O u-boot -T standalone -C none -a 0x8000 -e 0x8000 \
+      -n U-Boot -d u-boot.bin u-boot-highbank.img
+
+Then load this image file, either from hard disk, or via TFTP, from the
+existing U-Boot, and execute it with bootm::
+
+    => tftpboot 0x8000 u-boot-highbank.img
+    => bootm
+
+.. _`ipmitool`: https://github.com/Cynerva/ipmitool
+.. _`pyipmi`: https://pypi.org/project/pyipmi/
+.. _`management script`: https://github.com/Cynerva/cxmanage
diff --git a/doc/board/highbank/index.rst b/doc/board/highbank/index.rst
new file mode 100644
index 0000000000..b6975ca496
--- /dev/null
+++ b/doc/board/highbank/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Highbank
+========
+
+.. toctree::
+   :maxdepth: 2
+
+   highbank
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 74ea33e081..13f4db848e 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -16,6 +16,7 @@ Board-specific doc
    coreboot/index
    emulation/index
    google/index
+   highbank/index
    intel/index
    kontron/index
    microchip/index
diff --git a/doc/board/microchip/mpfs_icicle.rst b/doc/board/microchip/mpfs_icicle.rst
index c71c2f3cab..a4b10c6bd7 100644
--- a/doc/board/microchip/mpfs_icicle.rst
+++ b/doc/board/microchip/mpfs_icicle.rst
@@ -20,6 +20,7 @@ The support for following drivers are already enabled:
 2. Microchip Clock Driver.
 3. Cadence MACB ethernet driver for networking support.
 4. Cadence MMC Driver for eMMC/SD support.
+5. Microchip I2C Driver.
 
 Booting from eMMC using HSS
 ---------------------------
@@ -214,7 +215,8 @@ GPT partition.
 Booting
 ~~~~~~~
 
-You should see the U-Boot prompt on UART0.
+You should see the U-Boot prompt on UART1.
+(Note: UART0 is reserved for HSS)
 
 Sample boot log from MPFS Icicle Kit
 ''''''''''''''''''''''''''''''''''''
@@ -451,7 +453,8 @@ copied payload and Linux image.
 
     sudo dd if=<payload_binary> of=/dev/sdX2 bs=512
 
-You should see the U-Boot prompt on UART0.
+You should see the U-Boot prompt on UART1.
+(Note: UART0 is reserved for HSS)
 
 GUID type
 ~~~~~~~~~
diff --git a/doc/board/sifive/unmatched.rst b/doc/board/sifive/unmatched.rst
index 6b024f07f6..b52a1f690c 100644
--- a/doc/board/sifive/unmatched.rst
+++ b/doc/board/sifive/unmatched.rst
@@ -534,3 +534,34 @@ Sample boot log from HiFive Unmatched board
 	OpenEmbedded nodistro.0 unmatched ttySIF0
 
 	unmatched login:
+
+
+Booting from SPI
+----------------
+
+Use Building steps from "Booting from uSD using U-Boot SPL" section.
+
+Partition the SPI in Linux via mtdblock.  The partition types here are
+"HiFive Unleashed FSBL", "HiFive Unleashed BBL", and "U-Boot environment"
+for partitions one through three respectively.
+
+.. code-block:: none
+
+	sgdisk --clear -a 1 \
+	    --new=1:40:2087     --change-name=1:spl   --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
+	    --new=2:2088:10279  --change-name=2:uboot --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
+	    --new=3:10280:10535 --change-name=3:env   --typecode=3:3DE21764-95BD-54BD-A5C3-4ABE786F38A8 \
+	    /dev/mtdblock0
+
+Write U-boot SPL and U-boot to their partitions.
+
+.. code-block:: none
+
+	dd if=u-boot-spl.bin of=/dev/mtdblock0 bs=4096 seek=5 conv=sync
+	dd if=u-boot.itb  of=/dev/mtdblock0 bs=4096 seek=261 conv=sync
+
+Power off the board.
+
+Change DIP switches MSEL[3:0] to 0110.
+
+Power up the board.
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index f17138f5c7..a3e2656ab8 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -620,12 +620,12 @@ EFI_DRIVER_BINDING_PROTOCOL implementation for the UEFI drivers.
 
 A linker created list is used to keep track of the UEFI drivers. To create an
 entry in the list the UEFI driver uses the U_BOOT_DRIVER macro specifying
-UCLASS_EFI as the ID of its uclass, e.g::
+UCLASS_EFI_LOADER as the ID of its uclass, e.g::
 
     /* Identify as UEFI driver */
     U_BOOT_DRIVER(efi_block) = {
         .name  = "EFI block driver",
-        .id    = UCLASS_EFI,
+        .id    = UCLASS_EFI_LOADER,
         .ops   = &driver_ops,
     };
 
@@ -651,8 +651,8 @@ UEFI block IO driver
 The UEFI block IO driver supports devices exposing the EFI_BLOCK_IO_PROTOCOL.
 
 When connected it creates a new U-Boot block IO device with interface type
-IF_TYPE_EFI, adds child controllers mapping the partitions, and installs the
-EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on these. This can be used together with the
+IF_TYPE_EFI_LOADER, adds child controllers mapping the partitions, and installs
+the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on these. This can be used together with the
 software iPXE to boot from iSCSI network drives [4].
 
 This driver is only available if U-Boot is configured with::
diff --git a/doc/usage/fdt_overlays.rst b/doc/usage/fdt_overlays.rst
index ea39713434..7f113edae3 100644
--- a/doc/usage/fdt_overlays.rst
+++ b/doc/usage/fdt_overlays.rst
@@ -102,7 +102,7 @@ Manually Loading and Applying Overlays
 
 ::
 
-    => fdtaddr $fdtaddr
+    => fdt addr $fdtaddr
 
 4. Grow it enough so it can encompass all applied overlays