8 files changed, 199 insertions, 7 deletions
diff --git a/doc/README.marvell b/doc/README.marvell
index 6fc5ac8a409..6f05ad4cb16 100644
--- a/doc/README.marvell
+++ b/doc/README.marvell
@@ -43,8 +43,11 @@ Build Procedure
         In order to prevent this, the required device-tree MUST be set during compilation.
         All device-tree files are located in ./arch/arm/dts/ folder.
 
-	For other DB boards (MacchiatoBin, EspressoBin and 3700 DB board) compile u-boot with
-	just default device-tree from defconfig using:
+	For the EspressoBin board with populated eMMC device use
+		# make DEVICE_TREE=armada-3720-espressobin-emmc
+
+	For other DB boards (MacchiatoBin, EspressoBin without soldered eMMC and 3700 DB board)
+	compile u-boot with just default device-tree from defconfig using:
 
 		# make
 
diff --git a/doc/README.socfpga b/doc/README.socfpga
index cae0ef1a214..4d73398eb97 100644
--- a/doc/README.socfpga
+++ b/doc/README.socfpga
@@ -16,9 +16,9 @@ controller support within SOCFPGA
 #define CONFIG_SYS_MMC_MAX_BLK_COUNT	256
 -> Using smaller max blk cnt to avoid flooding the limited stack in OCRAM
 
---------------------------------------------------
-Generating the handoff header files for U-Boot SPL
---------------------------------------------------
+---------------------------------------------------------------------
+Cyclone 5 / Arria 5 generating the handoff header files for U-Boot SPL
+---------------------------------------------------------------------
 
 This text is assuming quartus 16.1, but newer versions will probably work just fine too;
 verified with DE1_SOC_Linux_FB demo project (https://github.com/VCTLabs/DE1_SOC_Linux_FB).
@@ -32,7 +32,7 @@ Rebuilding your Quartus project
 
 Choose one of the follwing methods, either command line or GUI.
 
-Using the comaand line
+Using the command line
 ~~~~~~~~~~~~~~~~~~~~~~
 
 First run the embedded command shell, using your path to the Quartus install:
@@ -147,3 +147,32 @@ Note: file sizes will differ slightly depending on the selected board.
 
 Now your board is ready for full mainline support including U-Boot SPL.
 The Preloader will not be needed any more.
+
+----------------------------------------------------------
+Arria 10 generating the handoff header files for U-Boot SPL
+----------------------------------------------------------
+
+A header file for inclusion in a devicetree for Arria10 can be generated
+by the qts-filter-a10.sh script directly from the hps_isw_handoff/hps.xml
+file generated during the FPGA project compilation.  The header contains
+all PLL, clock, pinmux, and bridge configurations required.
+
+Please look at the socfpga_arria10_socdk_sdmmc-u-boot.dtsi for an example
+that includes use of the generated handoff header.
+
+Devicetree header generation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The qts-filter-a10.sh script can process the compile time genetated hps.xml
+to create the appropriate devicetree header.
+
+
+  $ ./arch/arm/mach-socfpga/qts-filter-a10.sh \
+        <hps_xml> \
+        <output_file>
+
+    hps_xml      - hps_isw_handoff/hps.xml from Quartus project
+    output_file  - Output filename and location for header file
+
+The script generates a single header file names <output_file> that should
+be placed in arch/arm/dts.
diff --git a/doc/develop/global_data.rst b/doc/develop/global_data.rst
new file mode 100644
index 00000000000..9e7c8a24da0
--- /dev/null
+++ b/doc/develop/global_data.rst
@@ -0,0 +1,53 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Global data
+===========
+
+Globally required fields are held in the global data structure. A pointer to the
+structure is available as symbol gd. The symbol is made available by the macro
+%DECLARE_GLOBAL_DATA_PTR.
+
+Register pointing to global data
+--------------------------------
+
+On most architectures the global data pointer is stored in a register.
+
++------------+----------+
+| ARC        | r25      |
++------------+----------+
+| ARM 32bit  | r9       |
++------------+----------+
+| ARM 64bit  | x18      |
++------------+----------+
+| M68000     | d7       |
++------------+----------+
+| MicroBlaze | r31      |
++------------+----------+
+| NDS32      | r10      |
++------------+----------+
+| Nios II    | gp       |
++------------+----------+
+| PowerPC    | r2       |
++------------+----------+
+| RISC-V     | gp (x3)  |
++------------+----------+
+| SuperH     | r13      |
++------------+----------+
+
+The sandbox, x86, and Xtensa are notable exceptions.
+
+Clang for ARM does not support assigning a global register. When using Clang
+gd is defined as an inline function using assembly code. This adds a few bytes
+to the code size.
+
+Binaries called by U-Boot are not aware of the register usage and will not
+conserve gd. UEFI binaries call the API provided by U-Boot and may return to
+U-Boot. The value of gd has to be saved every time U-Boot is left and restored
+whenever U-Boot is reentered. This is also relevant for the implementation of
+function tracing. For setting the value of gd function set_gd() can be used.
+
+Global data structure
+---------------------
+
+.. kernel-doc:: include/asm-generic/global_data.h
+   :internal:
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 98a95ad434c..89e80eab945 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -9,4 +9,5 @@ Develop U-Boot
 
    coccinelle
    crash_dumps
+   global_data
    logging
diff --git a/doc/index.rst b/doc/index.rst
index fd9f10f28e4..68a083b16ba 100644
--- a/doc/index.rst
+++ b/doc/index.rst
@@ -109,6 +109,13 @@ Android-specific features available in U-Boot.
 
    android/index
 
+Command line
+------------
+.. toctree::
+   :maxdepth: 2
+
+   pstore.rst
+
 Indices and tables
 ==================
 
diff --git a/doc/pstore.rst b/doc/pstore.rst
new file mode 100644
index 00000000000..8427d8fd97a
--- /dev/null
+++ b/doc/pstore.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+PStore command
+==============
+
+Design
+------
+
+Linux PStore and Ramoops modules (Linux config options PSTORE and PSTORE_RAM)
+allow to use memory to pass data from the dying breath of a crashing kernel to
+its successor. This command allows to read those records from U-Boot command
+line.
+
+Ramoops is an oops/panic logger that writes its logs to RAM before the system
+crashes. It works by logging oopses and panics in a circular buffer. Ramoops
+needs a system with persistent RAM so that the content of that area can survive
+after a restart.
+
+Ramoops uses a predefined memory area to store the dump.
+
+Ramoops parameters can be passed as kernel parameters or through Device Tree,
+i.e.::
+
+    ramoops.mem_address=0x30000000 ramoops.mem_size=0x100000 ramoops.record_size=0x2000 ramoops.console_size=0x2000 memmap=0x100000$0x30000000
+
+The same values should be set in U-Boot to be able to retrieve the records.
+This values can be set at build time in U-Boot configuration file, or at runtime.
+U-Boot automatically patches the Device Tree to pass the Ramoops parameters to
+the kernel.
+
+The PStore configuration parameters are:
+
+======================= ==========
+ Name                   Default
+======================= ==========
+CMD_PSTORE_MEM_ADDR
+CMD_PSTORE_MEM_SIZE     0x10000
+CMD_PSTORE_RECORD_SIZE  0x1000
+CMD_PSTORE_CONSOLE_SIZE 0x1000
+CMD_PSTORE_FTRACE_SIZE  0x1000
+CMD_PSTORE_PMSG_SIZE    0x1000
+CMD_PSTORE_ECC_SIZE     0
+======================= ==========
+
+Records sizes should be a power of 2.
+The memory size and the record/console size must be non-zero.
+
+Multiple 'dump' records can be stored in the memory reserved for PStore.
+The memory size has to be larger than the sum of the record sizes, i.e.::
+
+    MEM_SIZE >= RECORD_SIZE * n + CONSOLE_SIZE + FTRACE_SIZE + PMSG_SIZE
+
+Usage
+-----
+
+Generate kernel crash
+~~~~~~~~~~~~~~~~~~~~~
+
+For test purpose, you can generate a kernel crash by setting reboot timeout to
+10 seconds and trigger a panic::
+
+    $ sudo sh -c "echo 1 > /proc/sys/kernel/sysrq"
+    $ sudo sh -c "echo 10 > /proc/sys/kernel/panic"
+    $ sudo sh -c "echo c > /proc/sysrq-trigger"
+
+Retrieve logs in U-Boot
+~~~~~~~~~~~~~~~~~~~~~~~
+
+First of all, unless PStore parameters as been set during U-Boot configuration
+and match kernel ramoops parameters, it needs to be set using 'pstore set', e.g.::
+
+    => pstore set 0x30000000 0x100000 0x2000 0x2000
+
+Then all available dumps can be displayed
+using::
+
+    => pstore display
+
+Or saved to an existing directory in an Ext2 or Ext4 partition, e.g. on root
+directory of 1st partition of the 2nd MMC::
+
+    => pstore save mmc 1:1 /
diff --git a/doc/sphinx/cdomain.py b/doc/sphinx/cdomain.py
index cf13ff3a656..cbac8e608dc 100644
--- a/doc/sphinx/cdomain.py
+++ b/doc/sphinx/cdomain.py
@@ -48,7 +48,10 @@ major, minor, patch = sphinx.version_info[:3]
 
 def setup(app):
 
-    app.override_domain(CDomain)
+    if (major == 1 and minor < 8):
+        app.override_domain(CDomain)
+    else:
+        app.add_domain(CDomain, override=True)
 
     return dict(
         version = __version__,
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index d4afd755e9f..a3455889ed9 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -386,6 +386,20 @@ that might be used by the target needs to be signed with 'required' keys.
 
 This happens automatically as part of a bootm command when FITs are used.
 
+For Signed Configurations, the default verification behavior can be changed by
+the following optional property in /signature node in U-Boot's control FDT.
+
+- required-mode: Valid values are "any" to allow verified boot to succeed if
+the selected configuration is signed by any of the 'required' keys, and "all"
+to allow verified boot to succeed if the selected configuration is signed by
+all of the 'required' keys.
+
+This property can be added to a binary device tree using fdtput as shown in
+below examples::
+
+	fdtput -t s control.dtb /signature required-mode any
+	fdtput -t s control.dtb /signature required-mode all
+
 
 Enabling FIT Verification
 -------------------------