Merge tag 'u-boot-imx-20200825' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

[platform/kernel/u-boot.git] / doc / uefi / uefi.rst

diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
index 4fda00d..07eb3f0 100644 (file)
--- a/doc/uefi/uefi.rst
+++ b/doc/uefi/uefi.rst
@@ -59,6 +59,10 @@ Below you find the output of an example session starting GRUB::
     120832 bytes read in 7 ms (16.5 MiB/s)
     => bootefi ${kernel_addr_r} ${fdt_addr_r}
 
+The bootefi command uses the device, the file name, and the file size
+(environment variable 'filesize') of the most recently loaded file when setting
+up the binary for execution. So the UEFI binary should be loaded last.
+
 The environment variable 'bootargs' is passed as load options in the UEFI system
 table. The Linux kernel EFI stub uses the load options as command line
 arguments.
@@ -169,11 +173,11 @@ Sign an image with one of the keys in "db" on your host
 Now in U-Boot install the keys on your board::
 
     fatload mmc 0:1 <tmpaddr> PK.auth
-    setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize PK
+    setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK
     fatload mmc 0:1 <tmpaddr> KEK.auth
-    setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize KEK
+    setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK
     fatload mmc 0:1 <tmpaddr> db.auth
-    setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize db
+    setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize db
 
 Set up boot parameters on your board::
 
@@ -188,16 +192,42 @@ on the sandbox
     cd <U-Boot source directory>
     pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
 
+UEFI binaries may be signed by Microsoft using the following certificates:
+
+* KEK: Microsoft Corporation KEK CA 2011
+  http://go.microsoft.com/fwlink/?LinkId=321185.
+* db: Microsoft Windows Production PCA 2011
+  http://go.microsoft.com/fwlink/p/?linkid=321192.
+* db: Microsoft Corporation UEFI CA 2011
+  http://go.microsoft.com/fwlink/p/?linkid=321194.
+
+Using OP-TEE for EFI variables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Instead of implementing UEFI variable services inside U-Boot they can
+also be provided in the secure world by a module for OP-TEE[1]. The
+interface between U-Boot and OP-TEE for variable services is enabled by
+CONFIG_EFI_MM_COMM_TEE=y.
+
+Tianocore EDK II's standalone management mode driver for variables can
+be linked to OP-TEE for this purpose. This module uses the Replay
+Protected Memory Block (RPMB) of an eMMC device for persisting
+non-volatile variables. When calling the variable services via the
+OP-TEE API U-Boot's OP-TEE supplicant relays calls to the RPMB driver
+which has to be enabled via CONFIG_SUPPORT_EMMC_RPMB=y.
+
+[1] https://optee.readthedocs.io/ - OP-TEE documentation
+
 Executing the boot manager
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The UEFI specification foresees to define boot entries and boot sequence via UEFI
-variables. Booting according to these variables is possible via::
+The UEFI specification foresees to define boot entries and boot sequence via
+UEFI variables. Booting according to these variables is possible via::
 
     bootefi bootmgr [fdt address]
 
-As of U-Boot v2018.03 UEFI variables are not persisted and cannot be set at
-runtime.
+As of U-Boot v2020.10 UEFI variables cannot be set at runtime. The U-Boot
+command 'efidebug' can be used to set the variables.
 
 Executing the built in hello world application
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~