Merge branch 'next'

3 files changed, 71 insertions, 5 deletions

diff --git a/doc/develop/driver-model/bind.rst b/doc/develop/driver-model/bind.rst
index b19661b5fe..0d0d40734c 100644
--- a/doc/develop/driver-model/bind.rst
+++ b/doc/develop/driver-model/bind.rst
@@ -7,7 +7,7 @@ Binding/unbinding a driver
 This document aims to describe the bind and unbind commands.
 
 For debugging purpose, it should be useful to bind or unbind a driver from
-the U-boot command line.
+the U-Boot command line.
 
 The unbind command calls the remove device driver callback and unbind the
 device from its driver.
diff --git a/doc/develop/driver-model/fs_firmware_loader.rst b/doc/develop/driver-model/fs_firmware_loader.rst
index b0823700a9..149b8b436e 100644
--- a/doc/develop/driver-model/fs_firmware_loader.rst
+++ b/doc/develop/driver-model/fs_firmware_loader.rst
@@ -92,9 +92,9 @@ For example of getting DT phandle from /chosen and creating instance:
 	if (ret)
 		return ret;
 
-Firmware loader driver is also designed to support U-boot environment
+Firmware loader driver is also designed to support U-Boot environment
 variables, so all these data from FDT can be overwritten
-through the U-boot environment variable during run time.
+through the U-Boot environment variable during run time.
 
 For examples:
 
@@ -110,7 +110,7 @@ fw_ubi_volume:
 When above environment variables are set, environment values would be
 used instead of data from FDT.
 The benefit of this design allows user to change storage attribute data
-at run time through U-boot console and saving the setting as default
+at run time through U-Boot console and saving the setting as default
 environment values in the storage for the next power cycle, so no
 compilation is required for both driver and FDT.
 
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index ffe25ca231..6626ceec52 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -318,6 +318,33 @@ Run the following command
       --guid <image GUID> \
       <capsule_file_name>
 
+The UEFI specification does not define the firmware versioning mechanism.
+EDK II reference implementation inserts the FMP Payload Header right before
+the payload. It coutains the fw_version and lowest supported version,
+EDK II reference implementation uses these information to implement the
+firmware versioning and anti-rollback protection, the firmware version and
+lowest supported version is stored into EFI non-volatile variable.
+
+In U-Boot, the firmware versioning is implemented utilizing
+the FMP Payload Header same as EDK II reference implementation,
+reads the FMP Payload Header and stores the firmware version into
+"FmpStateXXXX" EFI non-volatile variable. XXXX indicates the image index,
+since FMP protocol handles multiple image indexes.
+
+To add the fw_version into the FMP Payload Header,
+add --fw-version option in mkeficapsule tool.
+
+.. code-block:: console
+
+    $ mkeficapsule \
+      --index <index> --instance 0 \
+      --guid <image GUID> \
+      --fw-version 5 \
+      <capsule_file_name>
+
+If the --fw-version option is not set, FMP Payload Header is not inserted
+and fw_version is set as 0.
+
 Performing the update
 *********************
 
@@ -330,7 +357,7 @@ bit in OsIndications variable with
 
     => setenv -e -nv -bs -rt -v OsIndications =0x0000000000000004
 
-Since U-boot doesn't currently support SetVariable at runtime, its value
+Since U-Boot doesn't currently support SetVariable at runtime, its value
 won't be taken over across the reboot. If this is the case, you can skip
 this feature check with the Kconfig option (CONFIG_EFI_IGNORE_OSINDICATIONS)
 set.
@@ -510,6 +537,45 @@ where signature.dts looks like::
             };
     };
 
+Anti-rollback Protection
+************************
+
+Anti-rollback prevents unintentional installation of outdated firmware.
+To enable anti-rollback, you must add the lowest-supported-version property
+to dtb and specify --fw-version when creating a capsule file with the
+mkeficapsule tool.
+When executing capsule update, U-Boot checks if fw_version is greater than
+or equal to lowest-supported-version. If fw_version is less than
+lowest-supported-version, the update will fail.
+For example, if lowest-supported-version is set to 7 and you run capsule
+update using a capsule file with --fw-version of 5, the update will fail.
+When the --fw-version in the capsule file is updated, lowest-supported-version
+in the dtb might be updated accordingly.
+
+To insert the lowest supported version into a dtb
+
+.. code-block:: console
+
+    $ dtc -@ -I dts -O dtb -o version.dtbo version.dts
+    $ fdtoverlay -i orig.dtb -o new.dtb -v version.dtbo
+
+where version.dts looks like::
+
+    /dts-v1/;
+    /plugin/;
+    &{/} {
+            firmware-version {
+                    image1 {
+                            image-type-id = "09D7CF52-0720-4710-91D1-08469B7FE9C8";
+                            image-index = <1>;
+                            lowest-supported-version = <3>;
+                    };
+            };
+    };
+
+The properties of image-type-id and image-index must match the value
+defined in the efi_fw_image array as image_type_id and image_index.
+
 Executing the boot manager
 ~~~~~~~~~~~~~~~~~~~~~~~~~~