Merge branch 'next'

Signed-off-by: Tom Rini <trini@konsulko.com>

14 files changed, 435 insertions, 283 deletions

diff --git a/doc/README.fec_mxc b/doc/README.fec_mxc
index 9ca6ac2fb5..d17dfb676f 100644
--- a/doc/README.fec_mxc
+++ b/doc/README.fec_mxc
@@ -7,11 +7,6 @@ CONFIG_FEC_MXC
 CONFIG_MII
 	Must be defined if CONFIG_FEC_MXC is defined.
 
-CONFIG_FEC_XCV_TYPE
-	Defaults to MII100 for 100 Base-tx.
-	RGMII selects 1000 Base-tx reduced pin count interface.
-	RMII selects 100 Base-tx reduced pin count interface.
-
 CONFIG_FEC_MXC_SWAP_PACKET
 	Forced on iff MX28.
 	Swaps the bytes order of all words(4 byte units) in the packet.
diff --git a/doc/README.semihosting b/doc/README.semihosting
deleted file mode 100644
index f382d0131e..0000000000
--- a/doc/README.semihosting
+++ /dev/null
@@ -1,38 +0,0 @@
-SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2014 Broadcom Corporation.
- */
-
-Semihosting is ARM's way of having a real or virtual target communicate
-with a host or host debugger for basic operations such as file I/O,
-console I/O, etc. Please see
-http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Bgbjjgij.html for more information.
-
-For developing on armv8 virtual fastmodel platforms, semihosting is a
-valuable tool since it allows access to image/configuration files before
-eMMC or other NV media are available.
-
-There are two main ARM virtual Fixed Virtual Platform (FVP) models,
-Versatile Express (VE) FVP and BASE FVP (See
-http://www.arm.com/products/tools/models/fast-models/foundation-model.php)
-The initial vexpress64 u-boot board created here runs on the VE virtual
-platform using the license-free Foundation_v8 simulator. Fortunately,
-the Foundation_v8 simulator also supports the BASE_FVP model which
-companies can purchase licenses for and contain much more functionality.
-So we can, in u-boot, run either model by either using the VE FVP (default),
-or turning on CONFIG_BASE_FVP for the more full featured model.
-
-Rather than create a new armv8 board similar to armltd/vexpress64, add
-semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING
-and CONFIG_BASE_FVP both set. Also reuse the existing board config file
-vexpress_aemv8.h but differentiate the two models by the presence or
-absence of CONFIG_BASE_FVP. This change is tested and works on both the
-Foundation and Base fastmodel simulators.
-
-The semihosting code adds a command:
-
-  smhload <image> <address> [env var]
-
-That will load an image from the host filesystem into RAM at the specified
-address and optionally store the load end address in the specified
-environment variable.
diff --git a/doc/arch/arm64.rst b/doc/arch/arm64.rst
index 80498f6f6b..7c0713504c 100644
--- a/doc/arch/arm64.rst
+++ b/doc/arch/arm64.rst
@@ -18,7 +18,8 @@ Notes
    classical firmware (like initial hardware setup, CPU errata workarounds
    or SMP bringup). U-Boot can be entered in EL2 when its main purpose is
    that of a boot loader. It can drop to lower exception levels before
-   entering the OS.
+   entering the OS. For ARMv8-R it is recommened to enter at S-EL1, as for this
+   architecture there is no S-EL3.
 
 2. U-Boot for arm64 is compiled with AArch64-gcc. AArch64-gcc
    use rela relocation format, a tool(tools/relocate-rela) by Scott Wood
diff --git a/doc/board/armltd/vexpress64.rst b/doc/board/armltd/vexpress64.rst
index d87b1c38f5..a7f771d266 100644
--- a/doc/board/armltd/vexpress64.rst
+++ b/doc/board/armltd/vexpress64.rst
@@ -6,6 +6,7 @@ Arm Versatile Express
 The vexpress_* board configuration supports the following platforms:
 
  * FVP_Base_RevC-2xAEMvA
+ * FVP_BaseR_AEMv8R
  * Juno development board
 
 Fixed Virtual Platforms
diff --git a/doc/board/nxp/index.rst b/doc/board/nxp/index.rst
index 63956287c5..4514b8951b 100644
--- a/doc/board/nxp/index.rst
+++ b/doc/board/nxp/index.rst
@@ -13,6 +13,7 @@ NXP Semiconductors
    imx8qxp_mek
    imxrt1020-evk
    imxrt1050-evk
+   ls1046ardb
    mx6sabreauto
    mx6sabresd
    mx6ul_14x14_evk
diff --git a/doc/board/nxp/ls1046ardb.rst b/doc/board/nxp/ls1046ardb.rst
new file mode 100644
index 0000000000..35465d0061
--- /dev/null
+++ b/doc/board/nxp/ls1046ardb.rst
@@ -0,0 +1,193 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+LS1046ARDB
+==========
+
+The LS1046A Reference Design Board (RDB) is a high-performance computing,
+evaluation, and development platform that supports the QorIQ LS1046A
+LayerScape Architecture processor. The LS1046ARDB provides SW development
+platform for the Freescale LS1046A processor series, with a complete
+debugging environment. The LS1046A RDB is lead-free and RoHS-compliant.
+
+LS1046A SoC Overview
+--------------------
+Please refer arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc for LS1046A
+SoC overview.
+
+LS1046ARDB board Overview
+-------------------------
+- SERDES1 Connections, 4 lanes supporting:
+
+  - Lane0: 10GBase-R with x1 RJ45 connector
+  - Lane1: 10GBase-R Cage
+  - Lane2: SGMII.5
+  - Lane3: SGMII.6
+
+- SERDES2 Connections, 4 lanes supporting:
+
+  - Lane0: PCIe1 with miniPCIe slot
+  - Lane1: PCIe2 with PCIe x2 slot
+  - Lane2: PCIe3 with PCIe x4 slot
+  - Lane3: SATA
+
+- DDR Controller
+
+  - 8GB 64bits DDR4 SDRAM. Support rates of up to 2133MT/s
+
+- IFC/Local Bus
+
+  - One 512 MB NAND flash with ECC support
+  - CPLD connection
+
+- USB 3.0
+
+  - one Type A port, one Micro-AB port
+
+- SDHC: connects directly to a full SD/MMC slot
+- DSPI: 64 MB high-speed flash Memory for boot code and storage (up to 108MHz)
+- 4 I2C controllers
+- UART
+
+  - Two 4-pin serial ports at up to 115.2 Kbit/s
+  - Two DB9 D-Type connectors supporting one Serial port each
+
+- ARM JTAG support
+
+Memory map from core's view
+----------------------------
+
+================== ================== ================ =====
+Start Address      End Address        Description      Size
+================== ================== ================ =====
+``0x00_0000_0000`` ``0x00_000F_FFFF`` Secure Boot ROM  1M
+``0x00_0100_0000`` ``0x00_0FFF_FFFF`` CCSRBAR          240M
+``0x00_1000_0000`` ``0x00_1000_FFFF`` OCRAM0           64K
+``0x00_1001_0000`` ``0x00_1001_FFFF`` OCRAM1           64K
+``0x00_2000_0000`` ``0x00_20FF_FFFF`` DCSR             16M
+``0x00_7E80_0000`` ``0x00_7E80_FFFF`` IFC - NAND Flash 64K
+``0x00_7FB0_0000`` ``0x00_7FB0_0FFF`` IFC - CPLD       4K
+``0x00_8000_0000`` ``0x00_FFFF_FFFF`` DRAM1            2G
+``0x05_0000_0000`` ``0x05_07FF_FFFF`` QMAN S/W Portal  128M
+``0x05_0800_0000`` ``0x05_0FFF_FFFF`` BMAN S/W Portal  128M
+``0x08_8000_0000`` ``0x09_FFFF_FFFF`` DRAM2            6G
+``0x40_0000_0000`` ``0x47_FFFF_FFFF`` PCI Express1     32G
+``0x48_0000_0000`` ``0x4F_FFFF_FFFF`` PCI Express2     32G
+``0x50_0000_0000`` ``0x57_FFFF_FFFF`` PCI Express3     32G
+================== ================== ================ =====
+
+QSPI flash map
+--------------
+
+================== ================== ================== =====
+Start Address      End Address        Description        Size
+================== ================== ================== =====
+``0x00_4000_0000`` ``0x00_400F_FFFF`` RCW + PBI          1M
+``0x00_4010_0000`` ``0x00_402F_FFFF`` U-Boot             2M
+``0x00_4030_0000`` ``0x00_403F_FFFF`` U-Boot Env         1M
+``0x00_4040_0000`` ``0x00_405F_FFFF`` PPA                2M
+``0x00_4060_0000`` ``0x00_408F_FFFF`` Secure boot header 3M
+                                      + bootscript
+``0x00_4090_0000`` ``0x00_4093_FFFF`` FMan ucode         256K
+``0x00_4094_0000`` ``0x00_4097_FFFF`` QE/uQE firmware    256K
+``0x00_4098_0000`` ``0x00_40FF_FFFF`` Reserved           6M
+``0x00_4100_0000`` ``0x00_43FF_FFFF`` FIT Image          48M
+================== ================== ================== =====
+
+Booting Options
+---------------
+
+NB: The reference manual documents the RCW source with the *least-significant
+bit first*.
+
+QSPI boot
+^^^^^^^^^
+
+This is the default. ``{ SW5[0:8], SW4[0] }`` should be ``0010_0010_0``.
+
+SD boot and eMMC boot
+^^^^^^^^^^^^^^^^^^^^^
+
+``{ SW5[0:8], SW4[0] }`` should be ``0010_0000_0``. eMMC is selected only if
+there is no SD card in the slot.
+
+.. _ls1046ardb_jtag:
+
+JTAG boot
+^^^^^^^^^
+
+To recover a bricked board, or to perform initial programming, the ls1046
+supports using two hard-coded Reset Configuration Words (RCWs). Unfortunately,
+this configuration disables most functionality, including the uarts and ethernet.
+However, the SD/MMC and flash controllers are still functional. To get around
+the lack of a serial console, we will use ARM semihosting instead. When
+enabled, OpenOCD will interpret certain instructions as calls to the host
+operating system. This allows U-Boot to use the console, read/write files, or
+run arbitrary commands (!).
+
+When configuring U-Boot, ensure that ``CONFIG_SEMIHOSTING``,
+``CONFIG_SPL_SEMIHOSTING``, and ``CONFIG_SEMIHOSTING_SERIAL`` are enabled.
+``{ SW5[0:8], SW4[0] }`` should be ``0100_1111_0``. Additionally, ``SW4[7]``
+should be set to ``0``. Connect to the "console" USB connector on the front of
+the enclosure.
+
+Create a new file called ``u-boot.tcl`` (or whatever you choose) with the
+following contents::
+
+    # Load the configuration for the LS1046ARDB
+    source [find board/nxp_rdb-ls1046a.cfg]
+    # Initialize the scan chain
+    init
+    # Stop the processor
+    halt
+    # Enable semihosting
+    arm semihosting enable
+    # Load U-Boot SPL
+    load_image spl/u-boot-spl 0 elf
+    # Start executing SPL at the beginning of OCRAM
+    resume 0x10000000
+
+Then, launch openocd like::
+
+    openocd -f u-boot.tcl
+
+You should see the U-boot SPL banner followed by the banner for U-Boot proper
+in the output of openocd. The CMSIS-DAP adapter is slow, so this can take a
+long time. If you don't see it, something has gone wrong. After a while, you
+should see the prompt. You can load an image using semihosting by running::
+
+    => load hostfs - $loadaddr <name of file>
+
+Note that openocd's terminal is "cooked," so commands will only be sent to
+U-Boot when you press enter, and all commands will be echoed twice.
+Additionally, openocd will block when waiting for input, ignoring gdb, JTAG
+events, and Ctrl-Cs. To make openocd process these events, just hit enter.
+
+Using an external JTAG adapter
+""""""""""""""""""""""""""""""
+
+The CMSIS-DAP adapter can be rather slow. To speed up booting, use an external
+JTAG adapter. The following examples assume you are using a J-Link, though any
+adapter supported by OpenOCD will do. Ensure that ``SW4[7]`` is ``1``. Attach
+your jtag adapter to J22. Modify ``u-boot.tcl`` and replace the first two lines
+with the following::
+
+    # Load the J-Link configuration (or whatever your adapter is)
+    source [find interface/jlink.cfg]
+    # Use JTAG, since the J-Link also supports SWD
+    transport select jtag
+    # The reset pin resets the whole CPU
+    reset_config srst_only
+    # Load the LS1046A config
+    source [find target/ls1046a.cfg]
+
+You can proceed as normal through the rest of the steps above. I got a speedup
+of around 100x by using a J-Link.
+
+Debug UART
+----------
+
+To enable the debug UART, enable the following config options::
+
+    CONFIG_DEBUG_UART_NS16550=y
+    CONFIG_DEBUG_UART_BASE=0x21c0500
+    CONFIG_DEBUG_UART_CLOCK=300000000
diff --git a/doc/develop/event.rst b/doc/develop/event.rst
new file mode 100644
index 0000000000..6951ec97e7
--- /dev/null
+++ b/doc/develop/event.rst
@@ -0,0 +1,66 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Events
+======
+
+U-Boot supports a way for various events to be handled by interested
+subsystems. This provide a generic way to handle 'hooks' like setting up the
+CPUs after driver model is active, or reading a partition table after a new
+block device is probed.
+
+Rather than using weak functions and direct calls across subsystemss, it is
+often easier to use an event.
+
+An event consists of a type (e.g. EVT_DM_POST_INIT) and some optional data,
+in `union event_data`. An event spy can be creasted to watch for events of a
+particular type. When the event is created, it is sent to each spy in turn.
+
+
+Declaring a spy
+---------------
+
+To declare a spy, use something like this::
+
+    static int snow_setup_cpus(void *ctx, struct event *event)
+    {
+        /* do something */
+        return 0;
+    }
+    EVENT_SPY(EVT_DM_POST_INIT, snow_setup_cpus);
+
+Your function is called when EVT_DM_POST_INIT is emitted, i.e. after driver
+model is inited (in SPL, or in U-Boot proper before and after relocation).
+
+
+Debugging
+---------
+
+To assist with debugging events, enable `CONFIG_EVENT_DEBUG` and
+`CONFIG_CMD_EVENT`. The :doc:`../usage/cmd/event` command can then be used to
+provide a spy list.
+
+It is also possible to list spy information from the U-Boot executable,, using
+the `event_dump.py` script::
+
+    $ scripts/event_dump.py /tmp/b/sandbox/u-boot
+    Event type            Id                              Source location
+    --------------------  ------------------------------  ------------------------------
+    EVT_MISC_INIT_F       f:sandbox_misc_init_f           arch/sandbox/cpu/start.c:125
+
+This shows each event spy in U-Boot, along with the event type, function name
+(or ID) and source location.
+
+Note that if `CONFIG_EVENT_DEBUG` is not enabled, the event ID is missing, so
+the function is shown instead (with an `f:` prefix as above). Since the ID is
+generally the same as the function name, this does not matter much.
+
+The event type is decoded by the symbol used by U-Boot for the event linker
+list. Symbols have the form::
+
+    _u_boot_list_2_evspy_info_2_EVT_MISC_INIT_F
+
+so the event type can be read from the end. To manually list spy information
+in an image, use $(CROSS_COMPILE)nm::
+
+    nm u-boot |grep evspy |grep list
+    00000000002d6300 D _u_boot_list_2_evspy_info_2_EVT_MISC_INIT_F
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 93ebfa485f..2e6d6c302a 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -17,6 +17,7 @@ Implementation
    distro
    driver-model/index
    environment
+   event
    global_data
    logging
    makefiles
diff --git a/doc/develop/python_cq.rst b/doc/develop/python_cq.rst
index 3f99f1d9c0..1e209ff197 100644
--- a/doc/develop/python_cq.rst
+++ b/doc/develop/python_cq.rst
@@ -77,4 +77,15 @@ If the pylint version is updated in CI, this may result in needing to regenerate
 `scripts/pylint.base`.
 
 
+Checking for errors
+-------------------
+
+If you only want to check for pylint errors, use::
+
+   PYTHONPATH=/path/to/scripts/dtc/pylibfdt/ make pylint_err
+
+This will show only pylint errors. Note that you must set PYTHONPATH to point
+to the pylibfdt directory build by U-Boot (typically the sandbox_spl board). If
+you have used `make qcheck` then it sill be in `board-sandbox_spl`.
+
 .. _`PEP 8`: https://www.python.org/dev/peps/pep-0008/
diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt b/doc/device-tree-bindings/arm/arm,scmi.txt
index 92572eabb5..0a7886da24 100644
--- a/doc/device-tree-bindings/arm/arm,scmi.txt
+++ b/doc/device-tree-bindings/arm/arm,scmi.txt
@@ -1,234 +1,2 @@
-System Control and Management Interface (SCMI) Message Protocol
-----------------------------------------------------------
-
-The SCMI is intended to allow agents such as OSPM to manage various functions
-that are provided by the hardware platform it is running on, including power
-and performance functions.
-
-This binding is intended to define the interface the firmware implementing
-the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control
-and Management Interface Platform Design Document")[0] provide for OSPM in
-the device tree.
-
-Required properties:
-
-The scmi node with the following properties shall be under the /firmware/ node.
-
-- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports,
-	  or "linaro,scmi-optee" for OP-TEE transport.
-- mboxes: List of phandle and mailbox channel specifiers. It should contain
-	  exactly one or two mailboxes, one for transmitting messages("tx")
-	  and another optional for receiving the notifications("rx") if
-	  supported.
-- shmem : List of phandle pointing to the shared memory(SHM) area as per
-	  generic mailbox client binding.
-- #address-cells : should be '1' if the device has sub-nodes, maps to
-	  protocol identifier for a given sub-node.
-- #size-cells : should be '0' as 'reg' property doesn't have any size
-	  associated with it.
-- arm,smc-id : SMC id required when using smc or hvc transports
-- linaro,optee-channel-id : Channel specifier required when using OP-TEE
-	  transport.
-
-Optional properties:
-
-- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
-
-See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
-about the generic mailbox controller and client driver bindings.
-Mailbox doorbell is used as a mechanism to alert the presence of a
-messages and/or notification.
-
-Each protocol supported shall have a sub-node with corresponding compatible
-as described in the following sections. If the platform supports dedicated
-communication channel for a particular protocol, properties shall be present
-in the sub-node corresponding to that protocol. These properties are:
-- mboxes, mbox-names and shmem for mailbox transport
-- arm,smc-id and shmem for smc/hvc transport
-- linaro,optee-channel-id and possibly shmem for OP-TEE transport
-
-Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding uses the common clock binding[1].
-
-Required properties:
-- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
-
-Power domain bindings for the power domains based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding for the SCMI power domain providers uses the generic power
-domain binding[2].
-
-Required properties:
- - #power-domain-cells : Should be 1. Contains the device or the power
-			 domain ID value used by SCMI commands.
-
-Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
-------------------------------------------------------------
-An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
-and should be always positioned as a root regulator.
-It does not support any current operation.
-
-SCMI Regulators are grouped under a 'regulators' node which in turn is a child
-of the SCMI Voltage protocol node inside the desired SCMI instance node.
-
-This binding uses the common regulator binding[6].
-
-Required properties:
- - reg : shall identify an existent SCMI Voltage Domain.
-
-Sensor bindings for the sensors based on SCMI Message Protocol
---------------------------------------------------------------
-SCMI provides an API to access the various sensors on the SoC.
-
-Required properties:
-- #thermal-sensor-cells: should be set to 1. This property follows the
-			 thermal device tree bindings[3].
-
-			 Valid cell values are raw identifiers (Sensor ID)
-			 as used by the firmware. Refer to  platform details
-			 for your implementation for the IDs to use.
-
-Reset signal bindings for the reset domains based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding for the SCMI reset domain providers uses the generic reset
-signal binding[5].
-
-Required properties:
- - #reset-cells : Should be 1. Contains the reset domain ID value used
-		  by SCMI commands.
-
-SRAM and Shared Memory for SCMI
--------------------------------
-
-A small area of SRAM is reserved for SCMI communication between application
-processors and SCP.
-
-The properties should follow the generic mmio-sram description found in [4]
-
-Each sub-node represents the reserved area for SCMI.
-
-Required sub-node properties:
-- reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
-	       shared memory
-
-[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/power/power-domain.yaml
-[3] Documentation/devicetree/bindings/thermal/thermal.txt
-[4] Documentation/devicetree/bindings/sram/sram.yaml
-[5] Documentation/devicetree/bindings/reset/reset.txt
-[6] Documentation/devicetree/bindings/regulator/regulator.yaml
-
-Example:
-
-sram@50000000 {
-	compatible = "mmio-sram";
-	reg = <0x0 0x50000000 0x0 0x10000>;
-
-	#address-cells = <1>;
-	#size-cells = <1>;
-	ranges = <0 0x0 0x50000000 0x10000>;
-
-	cpu_scp_lpri: scp-shmem@0 {
-		compatible = "arm,scmi-shmem";
-		reg = <0x0 0x200>;
-	};
-
-	cpu_scp_hpri: scp-shmem@200 {
-		compatible = "arm,scmi-shmem";
-		reg = <0x200 0x200>;
-	};
-};
-
-mailbox@40000000 {
-	....
-	#mbox-cells = <1>;
-	reg = <0x0 0x40000000 0x0 0x10000>;
-};
-
-firmware {
-
-	...
-
-	scmi {
-		compatible = "arm,scmi";
-		mboxes = <&mailbox 0 &mailbox 1>;
-		mbox-names = "tx", "rx";
-		shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		scmi_devpd: protocol@11 {
-			reg = <0x11>;
-			#power-domain-cells = <1>;
-		};
-
-		scmi_dvfs: protocol@13 {
-			reg = <0x13>;
-			#clock-cells = <1>;
-		};
-
-		scmi_clk: protocol@14 {
-			reg = <0x14>;
-			#clock-cells = <1>;
-		};
-
-		scmi_sensors0: protocol@15 {
-			reg = <0x15>;
-			#thermal-sensor-cells = <1>;
-		};
-
-		scmi_reset: protocol@16 {
-			reg = <0x16>;
-			#reset-cells = <1>;
-		};
-
-		scmi_voltage: protocol@17 {
-			reg = <0x17>;
-
-			regulators {
-				regulator_devX: regulator@0 {
-					reg = <0x0>;
-					regulator-max-microvolt = <3300000>;
-				};
-
-				regulator_devY: regulator@9 {
-					reg = <0x9>;
-					regulator-min-microvolt = <500000>;
-					regulator-max-microvolt = <4200000>;
-				};
-
-				...
-			};
-		};
-	};
-};
-
-cpu@0 {
-	...
-	reg = <0 0>;
-	clocks = <&scmi_dvfs 0>;
-};
-
-hdlcd@7ff60000 {
-	...
-	reg = <0 0x7ff60000 0 0x1000>;
-	clocks = <&scmi_clk 4>;
-	power-domains = <&scmi_devpd 1>;
-	resets = <&scmi_reset 10>;
-};
-
-thermal-zones {
-	soc_thermal {
-		polling-delay-passive = <100>;
-		polling-delay = <1000>;
-					/* sensor ID */
-		thermal-sensors = <&scmi_sensors0 3>;
-		...
-	};
-};
+See Binding in Linux documentation:
+Documentation/devicetree/bindings/firmware/arm,scmi.yaml
diff --git a/doc/usage/cmd/bootmenu.rst b/doc/usage/cmd/bootmenu.rst
index 1f094ad6ed..1016ac8ceb 100644
--- a/doc/usage/cmd/bootmenu.rst
+++ b/doc/usage/cmd/bootmenu.rst
@@ -88,8 +88,3 @@ To run the bootmenu at startup add these additional settings::
     CONFIG_AUTOBOOT_KEYED=y
     CONFIG_BOOTDELAY=30
     CONFIG_AUTOBOOT_MENU_SHOW=y
-
-When you intend to use the bootmenu on a color frame buffer console,
-make sure to additionally define::
-
-    CONFIG_CFB_CONSOLE_ANSI=y
diff --git a/doc/usage/cmd/event.rst b/doc/usage/cmd/event.rst
new file mode 100644
index 0000000000..47c900d17e
--- /dev/null
+++ b/doc/usage/cmd/event.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+event command
+=============
+
+Synopsis
+--------
+
+::
+
+    event list
+
+Description
+-----------
+
+The event command provides spy list.
+
+This shows the following information:
+
+Seq
+    Sequence number of the spy, numbered from 0
+
+Type
+    Type of the spy, both as a number and a label. If `CONFIG_EVENT_DEBUG` is
+    not enabled, the label just shows `(unknown)`.
+
+Function
+    Address of the function to call
+
+ID
+    ID string for this event, if `CONFIG_EVENT_DEBUG` is enabled. Otherwise this
+    just shows `?`.
+
+
+See :doc:`../../develop/event` for more information on events.
+
+Example
+-------
+
+::
+
+    => event list
+    Seq  Type                              Function  ID
+      0  7   misc_init_f               55a070517c68  ?
+
+Configuration
+-------------
+
+The event command is only available if CONFIG_CMD_EVENT=y.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 8a54d9cb03..f457bffc2c 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -11,6 +11,7 @@ Use U-Boot
    netconsole
    partitions
    cmdline
+   semihosting
 
 Shell commands
 --------------
@@ -29,6 +30,7 @@ Shell commands
    cmd/cbsysinfo
    cmd/conitrace
    cmd/echo
+   cmd/event
    cmd/exception
    cmd/extension
    cmd/exit
diff --git a/doc/usage/semihosting.rst b/doc/usage/semihosting.rst
new file mode 100644
index 0000000000..6a280b455e
--- /dev/null
+++ b/doc/usage/semihosting.rst
@@ -0,0 +1,107 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2014 Broadcom Corporation.
+
+Semihosting
+===========
+
+Semihosting is ARM's way of having a real or virtual target communicate
+with a host or host debugger for basic operations such as file I/O,
+console I/O, etc. Please see `Arm's semihosting documentation
+<https://developer.arm.com/documentation/100863/latest/>`_ for more
+information.
+
+Platform Support
+----------------
+
+Versatile Express
+^^^^^^^^^^^^^^^^^
+
+For developing on armv8 virtual fastmodel platforms, semihosting is a
+valuable tool since it allows access to image/configuration files before
+eMMC or other NV media are available.
+
+There are two main ARM virtual Fixed Virtual Platform (FVP) models,
+`Versatile Express (VE) FVP and BASE FVP
+<http://www.arm.com/products/tools/models/fast-models/foundation-model.php>`_.
+The initial vexpress64 u-boot board created here runs on the VE virtual
+platform using the license-free Foundation_v8 simulator. Fortunately,
+the Foundation_v8 simulator also supports the BASE_FVP model which
+companies can purchase licenses for and contain much more functionality.
+So we can, in U-Boot, run either model by either using the VE FVP (default),
+or turning on ``CONFIG_BASE_FVP`` for the more full featured model.
+
+Rather than create a new armv8 board similar to ``armltd/vexpress64``, add
+semihosting calls to the existing one, enabled with ``CONFIG_SEMIHOSTING``
+and ``CONFIG_BASE_FVP`` both set. Also reuse the existing board config file
+vexpress_aemv8.h but differentiate the two models by the presence or
+absence of ``CONFIG_BASE_FVP``. This change is tested and works on both the
+Foundation and Base fastmodel simulators.
+
+QEMU
+^^^^
+
+Another ARM emulator which supports semihosting is `QEMU
+<https://www.qemu.org/>`_. To enable semihosting, enable
+``CONFIG_SERIAL_PROBE_ALL`` when configuring U-Boot, and use
+``-semihosting`` when invoking QEMU. Adding ``-nographic`` can also be
+helpful. When using a semihosted serial console, QEMU will block waiting
+for input. This will cause the GUI to become unresponsive. To mitigate
+this, try adding ``-nographic``. For more information about building and
+running QEMU, refer to the :doc:`board documentation
+<../board/emulation/qemu-arm>`.
+
+OpenOCD
+^^^^^^^
+
+Any ARM platform can use semihosting with an attached debugger. One such
+debugger with good support for a variety of boards and JTAG adapters is
+`OpenOCD <https://openocd.org/>`_. Semihosting is not enabled by default,
+so you will need to enable it::
+
+    $ openocd -f <your board config> -c init -c halt -c \
+          'arm semihosting enable' -c resume
+
+Note that enabling semihosting can only be done after attaching to the
+board with ``init``, and must be done while the CPU is halted. For a more
+extended example, refer to the :ref:`LS1046ARDB docs <ls1046ardb_jtag>`.
+
+Loading files
+-------------
+
+The semihosting code adds a "semihosting filesystem"::
+
+  load hostfs - <address> <image>
+
+That will load an image from the host filesystem into RAM at the specified
+address. If you are using U-Boot SPL, you can also use ``BOOT_DEVICE_SMH``
+which will load ``CONFIG_SPL_FS_LOAD_PAYLOAD_NAME``.
+
+Host console
+------------
+
+U-Boot can use the host's console instead of a physical serial device by
+enabling ``CONFIG_SERIAL_SEMIHOSTING``. If you don't have
+``CONFIG_DM_SERIAL`` enabled, make sure you disable any other serial
+drivers.
+
+Migrating from ``smhload``
+--------------------------
+
+If you were using the ``smhload`` command, you can migrate commands like::
+
+    smhload <file> <address> [<end var>]
+
+to a generic load command like::
+
+    load hostfs - <address> <file>
+
+The ``load`` command will set the ``filesize`` variable with the size of
+the file. The ``fdt chosen`` command has been updated to take a size
+instead of an end address. If you were adding the initramfs to your device
+tree like::
+
+    fdt chosen <address> <end var>
+
+you can now run::
+
+    fdt chosen <address> $filesize