Add submodule dependency filesHEADmaster

Change-Id: Iaf8d18082d3991dec7c0ebbea540f092188eb4ec

8 files changed, 1014 insertions, 0 deletions

diff --git a/roms/u-boot/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt b/roms/u-boot/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
new file mode 100644
index 000000000..bbe489714
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
@@ -0,0 +1,34 @@
+[Header]
+    Version = 4.2
+    Hash Algorithm = sha256
+    Engine Configuration = 0
+    Certificate Format = X509
+    Signature Format = CMS
+    Engine = CAAM
+
+[Install SRK]
+    # Index of the key location in the SRK table to be installed
+    File = "../crts/SRK_1_2_3_4_table.bin"
+    Source index = 0
+
+[Install CSFK]
+    # Key used to authenticate the CSF data
+    File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Install Key]
+    # Key slot index used to authenticate the key to be installed
+    Verification index = 0
+    # Target key slot in HAB key store where key will be installed
+    Target Index = 2
+    # Key to install
+    File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate Data]
+    # Key slot index used to authenticate the image data
+    Verification index = 2
+    # Authenticate Start Address, Offset, Length and file
+    Blocks = 0x80800000 0x00000000 0x80EEA020 "zImage", \
+	     0x83800000 0x00000000 0x8380B927 "imx7d-sdb.dtb", \
+	     0x84000000 0x00000000 0x840425B8 "uTee-7dsdb"
diff --git a/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
new file mode 100644
index 000000000..39986243e
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
@@ -0,0 +1,32 @@
+[Header]
+    Version = 4.2
+    Hash Algorithm = sha256
+    Engine Configuration = 0
+    Certificate Format = X509
+    Signature Format = CMS
+    Engine = CAAM
+
+[Install SRK]
+    # Index of the key location in the SRK table to be installed
+    File = "../crts/SRK_1_2_3_4_table.bin"
+    Source index = 0
+
+[Install CSFK]
+    # Key used to authenticate the CSF data
+    File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Install Key]
+    # Key slot index used to authenticate the key to be installed
+    Verification index = 0
+    # Target key slot in HAB key store where key will be installed
+    Target Index = 2
+    # Key to install
+    File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate Data]
+    # Key slot index used to authenticate the image data
+    Verification index = 2
+    # Authenticate Start Address, Offset, Length and file
+    Blocks =  0x877ff400 0x00000000 0x0009ec00 "u-boot-dtb.imx"
diff --git a/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
new file mode 100644
index 000000000..cdb34bcf7
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
@@ -0,0 +1,23 @@
+[Header]
+    Version = 4.2
+    Hash Algorithm = sha256
+    Engine Configuration = 0
+    Certificate Format = X509
+    Signature Format = CMS
+    Engine = CAAM
+
+[Install SRK]
+    # Index of the key location in the SRK table to be installed
+    File = "../crts/SRK_1_2_3_4_table.bin"
+    Source index = 0
+
+[Install NOCAK]
+    File = "../crts/SRK1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Authenticate Data]
+    # Key slot index 0 used to authenticate the image data
+    Verification index = 0
+    # Authenticate Start Address, Offset, Length and file
+    Blocks =  0x877ff400 0x00000000 0x0009ec00 "u-boot-dtb.imx"
diff --git a/roms/u-boot/doc/imx/habv4/guides/encrypted_boot.txt b/roms/u-boot/doc/imx/habv4/guides/encrypted_boot.txt
new file mode 100644
index 000000000..e2b435749
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/guides/encrypted_boot.txt
@@ -0,0 +1,43 @@
+1. Setup U-Boot Image for Encrypted Boot
+----------------------------------------
+An authenticated U-Boot image is used as starting point for
+Encrypted Boot. The image is encrypted by i.MX Code Signing
+Tool (CST). The CST replaces only the image data of
+u-boot-dtb.imx with the encrypted data. The Initial Vector Table,
+DCD, and Boot data, remains in plaintext.
+
+The image data is encrypted with a Encryption Key (DEK).
+Therefore, this key is needed to decrypt the data during the
+booting process. The DEK is protected by wrapping it in a Blob,
+which needs to be appended to the U-Boot image and specified in
+the CSF file.
+
+The DEK blob is generated by an authenticated U-Boot image with
+the dek_blob cmd enabled. The image used for DEK blob generation
+needs to have the following configurations enabled in Kconfig:
+
+CONFIG_IMX_HAB=y
+CONFIG_CMD_DEKBLOB=y
+
+Note: The encrypted boot feature is only supported by HABv4 or
+greater.
+
+The dek_blob command then can be used to generate the DEK blob of
+a DEK previously loaded in memory. The command is used as follows:
+
+dek_blob <DEK address> <Output Address> <Key Size in Bits>
+example: dek_blob 0x10800000 0x10801000 192
+
+The resulting DEK blob then is used to construct the encrypted
+U-Boot image. Note that the blob needs to be transferred back
+to the host.Then the following commands are used to construct
+the final image.
+
+cat u-boot-dtb.imx csf-u-boot.bin > u-boot-signed.imx
+objcopy -I binary -O binary --pad-to <blob_dst> --gap-fill=0x00 \
+    u-boot-signed.imx u-boot-signed-pad.bin
+cat u-boot-signed-pad.imx DEK_blob.bin > u-boot-encrypted.imx
+
+    NOTE: u-boot-signed.bin needs to be padded to the value
+    equivalent to the address in which the DEK blob is specified
+    in the CSF.
diff --git a/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
new file mode 100644
index 000000000..53f71fbc3
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
@@ -0,0 +1,427 @@
+         +=======================================================+
+         +   i.MX6, i.MX7 U-Boot Secure Boot guide using HABv4   +
+         +=======================================================+
+
+1. HABv4 secure boot process
+-----------------------------
+
+This document describes a step-by-step procedure on how to sign and securely
+boot an U-Boot image for non-SPL targets. It is assumed that the reader is
+familiar with basic HAB concepts and with the PKI tree generation.
+
+Details about HAB can be found in the application note AN4581[1] and in the
+introduction_habv4.txt document.
+
+1.1 Building a u-boot-dtb.imx image supporting secure boot
+-----------------------------------------------------------
+
+The U-Boot provides support to secure boot configuration and also provide
+access to the HAB APIs exposed by the ROM vector table, the support is
+enabled by selecting the CONFIG_IMX_HAB option.
+
+When built with this configuration, the U-Boot provides extra functions for
+HAB, such as the HAB status logs retrievement through the hab_status command
+and support for extending the root of trust.
+
+The U-Boot also correctly pads the final image by aligning to the next 0xC00
+address, so the CSF signature data generated by CST can be concatenated to
+image.
+
+The diagram below illustrate a signed u-boot-dtb.imx image layout:
+
+            ------- +-----------------------------+ <-- *start
+                ^   |      Image Vector Table     |
+                |   +-----------------------------+ <-- *boot_data
+                |   |          Boot Data          |
+                |   +-----------------------------+ <-- *dcd
+                |   |          DCD Table          |
+                |   +-----------------------------+
+         Signed |   |           Padding           |
+          Data  |   +-----------------------------+ <-- *entry
+                |   |                             |
+                |   |                             |
+                |   |       u-boot-dtb.bin        |
+                |   |                             |
+                |   |                             |
+                |   +-----------------------------+
+                v   |           Padding           |
+            ------- +-----------------------------+ <-- *csf
+                    |                             |
+                    | Command Sequence File (CSF) |
+                    |                             |
+                    +-----------------------------+
+                    |      Padding (optional)     |
+                    +-----------------------------+
+
+1.2 Enabling the secure boot support
+-------------------------------------
+
+The first step is to generate an U-Boot image supporting the HAB features
+mentioned above, this can be achieved by adding CONFIG_IMX_HAB to the
+build configuration:
+
+- Defconfig:
+
+  CONFIG_IMX_HAB=y
+
+- Kconfig:
+
+  ARM architecture -> Support i.MX HAB features
+
+1.3 Creating the CSF description file
+--------------------------------------
+
+The CSF contains all the commands that the HAB executes during the secure
+boot. These commands instruct the HAB on which memory areas of the image
+to authenticate, which keys to install, use and etc.
+
+CSF examples are available under doc/imx/habv4/csf_examples/ directory.
+
+A build log containing the "Authenticate Data" parameters is available after
+the U-Boot build, the example below is a log for mx7dsabresd_defconfig target:
+
+- mkimage build log:
+
+  $ cat u-boot-dtb.imx.log
+
+  Image Type:   Freescale IMX Boot Image
+  Image Ver:    2 (i.MX53/6/7 compatible)
+  Mode:         DCD
+  Data Size:    667648 Bytes = 652.00 KiB = 0.64 MiB
+  Load Address: 877ff420
+  Entry Point:  87800000
+  HAB Blocks:   0x877ff400 0x00000000 0x0009ec00
+                ^^^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^
+                |          |          |
+                |          |          ------- (1)
+                |          |
+                |          ------------------ (2)
+                |
+                ----------------------------- (3)
+
+  (1)   Size of area in file u-boot-dtb.imx to sign.
+        This area should include the IVT, the Boot Data the DCD
+        and the U-Boot itself.
+  (2)   Start of area in u-boot-dtb.imx to sign.
+  (3)   Start of area in RAM to authenticate.
+
+- In "Authenticate Data" CSF command users can copy and past the output
+  addresses:
+
+  Block = 0x877ff400 0x00000000 0x0009ec00 "u-boot-dtb.imx"
+
+1.4 Signing the U-Boot binary
+------------------------------
+
+The CST tool is used for singing the U-Boot binary and generating a CSF binary,
+users should input the CSF description file created in the step above and
+should receive a CSF binary, which contains the CSF commands, SRK table,
+signatures and certificates.
+
+- Create CSF binary file:
+
+  $ ./cst -i csf_uboot.txt -o csf_uboot.bin
+
+- Append CSF signature to the end of U-Boot image:
+
+  $ cat u-boot-dtb.imx csf_uboot.bin > u-boot-signed.imx
+
+The u-boot-signed.imx is the signed binary and should be flashed into the boot
+media.
+
+- Flash signed U-Boot binary:
+
+  $ sudo dd if=u-boot-signed.imx of=/dev/sd<x> bs=1K seek=1 && sync
+
+1.5 Programming SRK Hash
+-------------------------
+
+As explained in AN4581[1] and in introduction_habv4.txt document the SRK Hash
+fuse values are generated by the srktool and should be programmed in the
+SoC SRK_HASH[255:0] fuses.
+
+Be careful when programming these values, as this data is the basis for the
+root of trust. An error in SRK Hash results in a part that does not boot.
+
+The U-Boot fuse tool can be used for programming eFuses on i.MX SoCs.
+
+- Dump SRK Hash fuses values in host machine:
+
+  $ hexdump -e '/4 "0x"' -e '/4 "%X""\n"' SRK_1_2_3_4_fuse.bin
+  0x20593752
+  0x6ACE6962
+  0x26E0D06C
+  0xFC600661
+  0x1240E88F
+  0x1209F144
+  0x831C8117
+  0x1190FD4D
+
+- Program SRK_HASH[255:0] fuses, using i.MX6 series as example:
+
+  => fuse prog 3 0 0x20593752
+  => fuse prog 3 1 0x6ACE6962
+  => fuse prog 3 2 0x26E0D06C
+  => fuse prog 3 3 0xFC600661
+  => fuse prog 3 4 0x1240E88F
+  => fuse prog 3 5 0x1209F144
+  => fuse prog 3 6 0x831C8117
+  => fuse prog 3 7 0x1190FD4D
+
+The table below lists the SRK_HASH bank and word according to the i.MX device:
+
+    +-------------------+---------------+---------------+---------------+
+    |                   |  i.MX6 Series |    i.MX7D/S   |    i.MX7ULP   |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[31:00]   | bank 3 word 0 | bank 6 word 0 | bank 5 word 0 |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[63:32]   | bank 3 word 1 | bank 6 word 1 | bank 5 word 1 |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[95:64]   | bank 3 word 2 | bank 6 word 2 | bank 5 word 2 |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[127:96]  | bank 3 word 3 | bank 6 word 3 | bank 5 word 3 |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[159:128] | bank 3 word 4 | bank 7 word 0 | bank 5 word 4 |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[191:160] | bank 3 word 5 | bank 7 word 1 | bank 5 word 5 |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[223:192] | bank 3 word 6 | bank 7 word 2 | bank 5 word 6 |
+    +-------------------+---------------+---------------+---------------+
+    | SRK_HASH[255:224] | bank 3 word 7 | bank 7 word 3 | bank 5 word 7 |
+    +-------------------+---------------+---------------+---------------+
+
+1.6 Verifying HAB events
+-------------------------
+
+The next step is to verify that the signature attached to U-Boot is
+successfully processed without errors. HAB generates events when processing
+the commands if it encounters issues.
+
+The hab_status U-Boot command call the hab_report_event() and hab_status()
+HAB API functions to verify the processor security configuration and status.
+This command displays any events that were generated during the process.
+
+Prior to closing the device users should ensure no HAB events were found, as
+the example below:
+
+- Verify HAB events:
+
+  => hab_status
+
+  Secure boot disabled
+
+  HAB Configuration: 0xf0, HAB State: 0x66
+  No HAB Events Found!
+
+1.6.1 Verifying HAB events in i.MX7ULP
+---------------------------------------
+
+When booting i.MX7ULP in low power or dual boot modes the M4 binary is
+authenticated by an independent HAB in M4 ROM code using a
+different SRK key set.
+
+The U-Boot provides a M4 option in hab_status command so users can retrieve
+M4 HAB failure and warning events.
+
+- Verify HAB M4 events:
+
+  => hab_status m4
+
+  Secure boot disabled
+
+  HAB Configuration: 0xf0, HAB State: 0x66
+  No HAB Events Found!
+
+As HAB M4 API cannot be called from A7 core the command is parsing the M4 HAB
+persistent memory region, M4 software should not modify this reserved region.
+
+Details about HAB persistent memory region can be found in AN12263[2].
+
+1.7 Closing the device
+-----------------------
+
+After the device successfully boots a signed image without generating any HAB
+events, it is safe to close the device. This is the last step in the HAB
+process, and is achieved by programming the SEC_CONFIG[1] fuse bit.
+
+Once the fuse is programmed, the chip does not load an image that has not been
+signed using the correct PKI tree.
+
+- Program SEC_CONFIG[1] fuse, using i.MX6 series as example:
+
+  => fuse prog 0 6 0x00000002
+
+The table below list the SEC_CONFIG[1] bank and word according to the i.MX
+device:
+
+             +--------------+-----------------+------------+
+             |    Device    |  Bank and Word  |    Value   |
+             +--------------+-----------------+------------+
+             | i.MX6 Series |  bank 0 word 6  | 0x00000002 |
+             +--------------+-----------------+------------+
+             | i.MX7D/S     |  bank 1 word 3  | 0x02000000 |
+             +--------------+-----------------+------------+
+             | i.MX7ULP     |  bank 29 word 6 | 0x80000000 |
+             +--------------+-----------------+------------+
+
+1.8 Completely secure the device
+---------------------------------
+
+Additional fuses can be programmed for completely secure the device, more
+details about these fuses and their possible impact can be found at AN4581[1].
+
+- Program SRK_LOCK, using i.MX6 series as example:
+
+  => fuse prog 0 0 0x4000
+
+- Program DIR_BT_DIS, using i.MX6 series as example:
+
+  => fuse prog 0 6 0x8
+
+- Program SJC_DISABLE, using i.MX6 series as example:
+
+  => fuse prog 0 6 0x100000
+
+- JTAG_SMODE, using i.MX6 series as example:
+
+  => fuse prog 0 6 0xC00000
+
+The table below list the SRK_LOCK, DIR_BT_DIS, SJC_DISABLE, and JTAG_SMODE bank
+and word according to the i.MX device:
+
+              +--------------+---------------+------------+
+              |    Device    | Bank and Word |   Value    |
+              +--------------+---------------+------------+
+              |                  SRK_LOCK                 |
+              +-------------------------------------------+
+              | i.MX6 Series | bank 0 word 0 | 0x00004000 |
+              +--------------+---------------+------------+
+              | i.MX7D/S     | bank 0 word 0 | 0x00000200 |
+              +--------------+---------------+------------+
+              | i.MX7ULP     | bank 1 word 1 | 0x00000080 |
+              +--------------+---------------+------------+
+              |                 DIR_BT_DIS                |
+              +-------------------------------------------+
+              | i.MX6 Series | bank 0 word 6 | 0x00000008 |
+              +--------------+---------------+------------+
+              | i.MX7D/S     | bank 1 word 3 | 0x08000000 |
+              +--------------+---------------+------------+
+              | i.MX7ULP     | bank 1 word 1 | 0x00002000 |
+              +--------------+---------------+------------+
+              |                 SJC_DISABLE               |
+              +-------------------------------------------+
+              | i.MX6 Series | bank 0 word 6 | 0x00100000 |
+              +--------------+---------------+------------+
+              | i.MX7D/S     | bank 1 word 3 | 0x00200000 |
+              +--------------+---------------+------------+
+              | i.MX7ULP     | bank 1 word 1 | 0x00000020 |
+              +--------------+---------------+------------+
+              |                 JTAG_SMODE                |
+              +-------------------------------------------+
+              | i.MX6 Series | bank 0 word 6 | 0x00C00000 |
+              +--------------+---------------+------------+
+              | i.MX7D/S     | bank 1 word 3 | 0x00C00000 |
+              +--------------+---------------+------------+
+              | i.MX7ULP     | bank 1 word 1 | 0x000000C0 |
+              +--------------+---------------+------------+
+
+2. Extending the root of trust
+-------------------------------
+
+The High Assurance Boot (HAB) code located in the on-chip ROM provides an
+Application Programming Interface (API) making it possible to call back
+into the HAB code for authenticating additional boot images.
+
+The U-Boot supports this feature and can be used to authenticate the Linux
+Kernel Image.
+
+The process of signing an additional image is similar to the U-Boot.
+The diagram below illustrate the zImage layout:
+
+            ------- +-----------------------------+ <-- *load_address
+                ^   |                             |
+                |   |                             |
+                |   |                             |
+                |   |                             |
+                |   |           zImage            |
+         Signed |   |                             |
+          Data  |   |                             |
+                |   |                             |
+                |   +-----------------------------+
+                |   |    Padding Next Boundary    |
+                |   +-----------------------------+ <-- *ivt
+                v   |     Image Vector Table      |
+            ------- +-----------------------------+ <-- *csf
+                    |                             |
+                    | Command Sequence File (CSF) |
+                    |                             |
+                    +-----------------------------+
+                    |     Padding (optional)      |
+                    +-----------------------------+
+
+2.1 Padding the image
+----------------------
+
+The zImage must be padded to the next boundary address (0x1000), for instance
+if the image size is 0x649920 it must be padded to 0x64A000.
+
+The tool objcopy can be used for padding the image.
+
+- Pad the zImage:
+
+  $ objcopy -I binary -O binary --pad-to 0x64A000 --gap-fill=0x00 \
+	zImage zImage_pad.bin
+
+2.2 Generating Image Vector Table
+----------------------------------
+
+The HAB code requires an Image Vector Table (IVT) for determining the image
+length and the CSF location. Since zImage does not include an IVT this has
+to be manually created and appended to the end of the padded zImage, the
+script genIVT.pl in script_examples directory can be used as reference.
+
+- Generate IVT:
+
+  $ genIVT.pl
+
+Note: The load Address may change depending on the device.
+
+- Append the ivt.bin at the end of the padded zImage:
+
+  $ cat zImage_pad.bin ivt.bin > zImage_pad_ivt.bin
+
+2.3 Signing the image
+----------------------
+
+A CSF file has to be created to sign the image. HAB does not allow to change
+the SRK once the first image is authenticated, so the same SRK key used in
+U-Boot must be used when extending the root of trust.
+
+CSF examples are available in ../csf_examples/additional_images/
+directory.
+
+- Create CSF binary file:
+
+  $ ./cst --i csf_additional_images.txt --o csf_zImage.bin
+
+- Attach the CSF binary to the end of the image:
+
+  $ cat zImage_pad_ivt.bin csf_zImage.bin > zImage_signed.bin
+
+2.4 Verifying HAB events
+-------------------------
+
+The U-Boot includes the hab_auth_img command which can be used for
+authenticating and troubleshooting the signed image, zImage must be
+loaded at the load address specified in the IVT.
+
+- Authenticate additional image:
+
+  => hab_auth_img <Load Address> <Image Size> <IVT Offset>
+
+If no HAB events were found the zImage is successfully signed.
+
+References:
+[1] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
+ HABv4" - Rev 2.
+[2] AN12263: "HABv4 RVT Guidelines and Recommendations" - Rev 0.
diff --git a/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
new file mode 100644
index 000000000..fde0f27ef
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
@@ -0,0 +1,181 @@
+      +===============================================================+
+      +  i.MX6, i.MX7 U-Boot HABv4 Secure Boot guide for SPL targets  +
+      +===============================================================+
+
+1. HABv4 secure boot process
+-----------------------------
+
+This document is an addendum of mx6_mx7_secure_boot.txt guide describing a
+step-by-step procedure on how to sign and securely boot an U-Boot image for
+SPL targets.
+
+Details about HAB can be found in the application note AN4581[1] and in the
+introduction_habv4.txt document.
+
+1.1 Building a SPL target supporting secure boot
+-------------------------------------------------
+
+The U-Boot provides Second Program Loader (SPL) support which generates two
+final images, SPL and U-Boot proper. The HABv4 can be used to authenticate
+both binaries.
+
+Out of reset the ROM code authenticates the SPL which is responsible for
+initializing essential features such as DDR, UART, PMIC and clock
+enablement. Once the DDR is available, the SPL code loads the U-Boot proper
+image to its specific execution address and call the HAB APIs to extend the
+root of trust.
+
+The U-Boot provides support to secure boot configuration and also provide
+access to the HAB APIs exposed by the ROM vector table, the support is
+enabled by selecting the CONFIG_IMX_HAB option.
+
+When built with this configuration the U-Boot correctly pads the final SPL
+image by aligning to the next 0xC00 address, so the CSF signature data
+generated by CST can be concatenated to the image.
+
+The U-Boot also append an Image Vector Table (IVT) in the final U-Boot proper
+binary (u-boot-ivt.img) so it can be used by HAB API in a post ROM stage.
+
+The diagram below illustrate a signed SPL image layout:
+
+            ------- +-----------------------------+ <-- *start
+                ^   |      Image Vector Table     |
+                |   +-----------------------------+ <-- *boot_data
+                |   |          Boot Data          |
+                |   +-----------------------------+
+         Signed |   |           Padding           |
+          Data  |   +-----------------------------+ <-- *entry
+                |   |                             |
+                |   |            SPL              |
+                |   |                             |
+                |   +-----------------------------+
+                v   |           Padding           |
+            ------- +-----------------------------+ <-- *csf
+                    |                             |
+                    | Command Sequence File (CSF) |
+                    |                             |
+                    +-----------------------------+
+                    |      Padding (optional)     |
+                    +-----------------------------+
+
+The diagram below illustrate a signed u-boot-ivt.img image layout:
+
+            ------- +-----------------------------+ <-- *load_address
+                ^   |                             |
+                |   |                             |
+                |   |         u-boot.img          |
+         Signed |   |                             |
+          Data  |   |                             |
+                |   +-----------------------------+
+                |   |    Padding Next Boundary    |
+                |   +-----------------------------+ <-- *ivt
+                v   |     Image Vector Table      |
+            ------- +-----------------------------+ <-- *csf
+                    |                             |
+                    | Command Sequence File (CSF) |
+                    |                             |
+                    +-----------------------------+
+                    |     Padding (optional)      |
+                    +-----------------------------+
+
+1.2 Enabling the secure boot support
+-------------------------------------
+
+The first step is to generate an U-Boot image supporting the HAB features
+mentioned above, this can be achieved by adding CONFIG_IMX_HAB to the
+build configuration:
+
+- Defconfig:
+
+  CONFIG_IMX_HAB=y
+
+- Kconfig:
+
+  ARM architecture -> Support i.MX HAB features
+
+1.3 Creating the CSF description file
+--------------------------------------
+
+The CSF contains all the commands that the HAB executes during the secure
+boot. These commands instruct the HAB code on which memory areas of the image
+to authenticate, which keys to install, use and etc.
+
+CSF examples are available under doc/imx/habv4/csf_examples/ directory.
+
+Build logs containing the "Authenticate Data" parameters are available after
+the U-Boot build, the example below is a log for mx6sabresd_defconfig target:
+
+- SPL build log:
+
+  $ cat SPL.log
+  Image Type:   Freescale IMX Boot Image
+  Image Ver:    2 (i.MX53/6/7 compatible)
+  Mode:         DCD
+  Data Size:    69632 Bytes = 68.00 KiB = 0.07 MiB
+  Load Address: 00907420
+  Entry Point:  00908000
+  HAB Blocks:   0x00907400 0x00000000 0x0000ec00
+
+- u-boot-ivt.img build log:
+
+  $ cat u-boot-ivt.img.log
+  Image Name:   U-Boot 2019.01-00003-g78ee492eb3
+  Created:      Mon Jan 14 17:58:10 2019
+  Image Type:   ARM U-Boot Firmware with HABv4 IVT (uncompressed)
+  Data Size:    458688 Bytes = 447.94 KiB = 0.44 MiB
+  Load Address: 17800000
+  Entry Point:  00000000
+  HAB Blocks:   0x177fffc0   0x0000   0x0006e020
+
+As explained in section above the SPL is first authenticated by the ROM code
+and the root of trust is extended to the U-Boot image, hence two CSF files are
+necessary to completely sign a bootloader image.
+
+In "Authenticate Data" CSF command users can copy and past the output
+addresses, the csf_uboot.txt can be used as example:
+
+- In csf_SPL.txt:
+
+  Block = 0x00907400 0x00000000 0x0000ec00 "SPL"
+
+- In csf_uboot-ivt.txt:
+
+  Block = 0x177fffc0 0x0000 0x0006e020 "u-boot-ivt.img"
+
+1.4 Signing the images
+-----------------------
+
+The CST tool is used for singing the U-Boot binary and generating a CSF binary,
+users should input the CSF description file created in the step above and
+receive a CSF binary, which contains the CSF commands, SRK table, signatures
+and certificates.
+
+- Create SPL CSF binary file:
+
+  $ ./cst -i csf_SPL.txt -o csf_SPL.bin
+
+- Append CSF signature to the end of SPL image:
+
+  $ cat SPL csf_SPL.bin > SPL-signed
+
+- Create U-Boot proper CSF binary file:
+
+  $ ./cst -i csf_uboot-ivt.txt -o csf_uboot-ivt.bin
+
+- Append CSF signature to the end of U-Boot proper image:
+
+  $ cat u-boot-ivt.img csf_uboot-ivt.bin > u-boot-signed.img
+
+The bootloader is signed and can be flashed into the boot media.
+
+1.5 Closing the device
+-----------------------
+
+The procedure for closing the device is similar as in Non-SPL targets, for a
+complete procedure please refer to section "1.5 Programming SRK Hash" in
+mx6_mx7_secure_boot.txt document available under doc/imx/habv4/guides/
+directory.
+
+References:
+[1] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
+ HABv4" - Rev 2.
diff --git a/roms/u-boot/doc/imx/habv4/introduction_habv4.txt b/roms/u-boot/doc/imx/habv4/introduction_habv4.txt
new file mode 100644
index 000000000..25711bbe9
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/introduction_habv4.txt
@@ -0,0 +1,262 @@
+          +=======================================================+
+          +     i.MX Secure and Encrypted Boot using HABv4        +
+          +=======================================================+
+
+1. Introduction
+----------------
+
+The i.MX family of applications processors provides the High Assurance Boot
+(HAB) feature in the on-chip ROM. The ROM is responsible for loading the
+initial program image (U-Boot) from the boot media and HAB enables the ROM
+to authenticate and/or decrypt the program image by using cryptography
+operations.
+
+This feature is supported in i.MX 50, i.MX 53, i.MX 6, i.MX 7 series and
+ i.MX 8M, i.MX 8MM devices.
+
+Step-by-step guides are available under doc/imx/habv4/guides/ directory,
+users familiar with HAB and CST PKI tree generation should refer to these
+documents instead.
+
+1.1 The HABv4 Secure Boot Architecture
+---------------------------------------
+
+The HABv4 secure boot feature uses digital signatures to prevent unauthorized
+software execution during the device boot sequence. In case a malware takes
+control of the boot sequence, sensitive data, services and network can be
+impacted.
+
+The HAB authentication is based on public key cryptography using the RSA
+algorithm in which image data is signed offline using a series of private
+keys. The resulting signed image data is then verified on the i.MX processor
+using the corresponding public keys. The public keys are included in the CSF
+binary and the SRK Hash is programmed in the SoC fuses for establishing the
+root of trust.
+
+The diagram below illustrate the secure boot process overview:
+
+          Host PC + CST                             i.MX + HAB
+          +----------+                             +----------+
+     ---> |  U-Boot  |                             | Compare  |
+     |    +----------+                             +----------+
+     |          |                                     ^    ^
+     |          v                         Reference  /      \  Generated
+     |    +----------+                      Hash    /        \   Hash
+     |    |   Hash   |  Private                    /          \
+     |    +----------+    Key                     /            \
+     |          |          |                +----------+  +----------+
+     |          v          |                |  Verify  |  |   Hash   |
+     |    +----------+     |                +----------+  +----------+
+     |    |   Sign   |  <---      SRK            ^            ^
+     |    +----------+            HASH            \          /
+     |          |                  |          CSF  \        /   U-Boot
+     |          v                  v                \      /
+     |    +----------+        +----------+        +----------+
+     |    |  U-Boot  |        |          |        |  U-Boot  |
+     ---> |     +    | -----> |   i.MX   | -----> |     +    |
+          |    CSF   |        |          |        |    CSF   |
+          +----------+        +----------+        +----------+
+
+The U-Boot image to be programmed into the boot media needs to be properly
+constructed i.e. it must contain a proper Command Sequence File (CSF).
+
+The CSF is a binary data structure interpreted by the HAB to guide
+authentication process, this is generated by the Code Signing Tool[1].
+The CSF structure contains the commands, SRK table, signatures and
+certificates.
+
+Details about the Secure Boot and Code Signing Tool (CST) can be found in
+the application note AN4581[2] and in the secure boot guides.
+
+1.2 The HABv4 Encrypted Boot Architecture
+------------------------------------------
+
+The HAB Encrypted Boot feature available in CAAM supported devices adds an
+extra security operation to the bootloading sequence. It uses cryptographic
+techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used
+by unauthorized users. This mechanism protects the U-Boot code residing on
+flash or external memory and also ensures that the final image is unique
+per device.
+
+The process can be divided into two protection mechanisms. The first mechanism
+is the bootloader code encryption which provides data confidentiality and the
+second mechanism is the digital signature, which authenticates the encrypted
+image.
+
+Keep in mind that the encrypted boot makes use of both mechanisms whatever the
+order is (sign and then encrypt, or encrypt and then sign), both operations
+can be applied on the same region with exception of the U-Boot Header (IVT,
+boot data and DCD) which can only be signed, not encrypted.
+
+The diagram below illustrate the encrypted boot process overview:
+
+     Host PC + CST                                      i.MX + HAB
+     +------------+                                  +--------------+
+     |   U-Boot   |                                  |    U-Boot    |
+     +------------+                                  +--------------+
+            |                                                ^
+            |                                                |
+            v         DEK                            +--------------+
+     +------------+    |                       ----> |    Decrypt   |
+     |   Encrypt  | <---                       |     +--------------+
+     +------------+                        DEK |             ^
+            |                                  |             |
+            |       Private                    |             |
+            v         Key                  +------+   +--------------+
+     +------------+    |                   | CAAM |   | Authenticate |
+     |    Sign    | <---                   +------+   +--------------+
+     +------------+            DEK             ^             ^
+            |                + OTPMK       DEK  \           /  U-Boot
+            |                   |          Blob  \         /   + CSF
+            v                   v                 \       /
+     +------------+       +----------+          +------------+
+     | Enc U-Boot |       |          |          | Enc U-Boot |
+     |   + CSF    | ----> |   i.MX   | -------> |   + CSF    |
+     | + DEK Blob |       |          |          | + DEK Blob |
+     +------------+       +----------+          +------------+
+            ^                   |
+            |                   |
+            ---------------------
+                   DEK Blob
+                    (CAAM)
+
+The Code Signing Tool automatically generates a random AES Data Encryption Key
+(DEK) when encrypting an image. This key is used in both encrypt and decrypt
+operations and should be present in the final image structure encapsulated
+by a CAAM blob.
+
+The OTP Master Key (OTPMK) is used to encrypt and wrap the DEK in a blob
+structure. The OTPMK is unique per device and can be accessed by CAAM only.
+To further add to the security of the DEK, the blob is decapsulated and
+decrypted inside a secure memory partition that can only be accessed by CAAM.
+
+During the design of encrypted boot using DEK blob, it is necessary to inhibit
+any modification or replacement of DEK blob with a counterfeit one allowing
+execution of malicious code. The PRIBLOB setting in CAAM allows secure boot
+software to have its own private blobs that cannot be decapsulated or
+encapsulated by any other user code, including any software running in trusted
+mode.
+
+Details about DEK Blob generation and PRIBLOB setting can be found in the
+encrypted boot guide and application note AN12056[3] .
+
+2. Generating a PKI tree
+-------------------------
+
+The first step is to generate the private keys and public keys certificates.
+The HAB architecture is based in a Public Key Infrastructure (PKI) tree.
+
+The Code Signing Tools package contains an OpenSSL based key generation script
+under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI
+tree containing up to 4 Super Root Keys (SRK) as well as their subordinated
+IMG and CSF keys.
+
+A new PKI tree can be generated by following the example below:
+
+- Generating 2048-bit PKI tree on CST v3.1.0:
+
+  $ ./hab4_pki_tree.sh
+  ...
+  Do you want to use an existing CA key (y/n)?: n
+  Do you want to use Elliptic Curve Cryptography (y/n)?: n
+  Enter key length in bits for PKI tree: 2048
+  Enter PKI tree duration (years): 5
+  How many Super Root Keys should be generated? 4
+  Do you want the SRK certificates to have the CA flag set? (y/n)?: y
+
+The diagram below illustrate the PKI tree:
+
+                                +---------+
+                                |   CA    |
+                                +---------+
+                                     |
+                                     |
+            ---------------------------------------------------
+            |               |                 |               |
+            |               |                 |               |
+            v               v                 v               v
+       +--------+       +--------+       +--------+       +--------+
+       |  SRK1  |       |  SRK2  |       |  SRK3  |       |  SRK4  |
+       +--------+       +--------+       +--------+       +--------+
+         /    \           /    \           /    \           /    \
+        v      v         v      v         v      v         v      v
+     +----+  +----+   +----+  +----+   +----+  +----+   +----+  +----+
+     |CSF1|  |IMG1|   |CSF2|  |IMG2|   |CSF3|  |IMG3|   |CSF4|  |IMG4|
+     +----+  +----+   +----+  +----+   +----+  +----+   +----+  +----+
+
+After running the script users can check the private keys under keys/ directory
+and their respective X.509v3 public key certificates under crts/ directory.
+Those files will be used during the signing and authentication process.
+
+2.1 Generating a fast authentication PKI tree
+----------------------------------------------
+
+Starting in HAB v4.1.2 users can use a single SRK key to authenticate the both
+CSF and IMG contents. This reduces the number of key pair authentications that
+must occur during the ROM/HAB boot stage, thus providing a faster boot process.
+
+The script hab4_pki_tree.sh is also able to generate a Public Key Infrastructure
+(PKI) tree which only contains SRK Keys, users should not set the CA flag when
+generating the SRK certificates.
+
+- Generating 2048-bit fast authentication PKI tree on CST v3.1.0:
+
+  $ ./hab4_pki_tree.sh
+  ...
+  Do you want to use an existing CA key (y/n)?: n
+  Do you want to use Elliptic Curve Cryptography (y/n)?: n
+  Enter key length in bits for PKI tree: 2048
+  Enter PKI tree duration (years): 5
+  How many Super Root Keys should be generated? 4
+  Do you want the SRK certificates to have the CA flag set? (y/n)?: n
+
+The diagram below illustrate the PKI tree generated:
+
+                             +---------+
+                             |   CA    |
+                             +---------+
+                                  |
+                                  |
+         ---------------------------------------------------
+         |               |                 |               |
+         |               |                 |               |
+         v               v                 v               v
+    +--------+       +--------+       +--------+       +--------+
+    |  SRK1  |       |  SRK2  |       |  SRK3  |       |  SRK4  |
+    +--------+       +--------+       +--------+       +--------+
+
+2.2 Generating a SRK Table and SRK Hash
+----------------------------------------
+
+The next step is to generated the SRK Table and its respective SRK Table Hash
+from the SRK public key certificates created in one of the steps above.
+
+In the HAB architecture, the SRK Table is included in the CSF binary and the
+SRK Hash is programmed in the SoC SRK_HASH[255:0] fuses.
+
+On the target device during the authentication process the HAB code verify the
+SRK Table against the SoC SRK_HASH fuses, in case the verification success the
+root of trust is established and the HAB code can progress with the image
+authentication.
+
+The srktool can be used for generating the SRK Table and its respective SRK
+Table Hash.
+
+- Generating SRK Table and SRK Hash in Linux 64-bit machines:
+
+  $ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \
+	SRK_1_2_3_4_fuse.bin -d sha256 -c \
+	SRK1_sha256_2048_65537_v3_ca_crt.pem,\
+	SRK2_sha256_2048_65537_v3_ca_crt.pem,\
+	SRK3_sha256_2048_65537_v3_ca_crt.pem,\
+	SRK4_sha256_2048_65537_v3_ca_crt.pem
+
+The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further
+steps as explained in HAB guides available under doc/imx/habv4/guides/
+directory.
+
+References:
+[1] CST: i.MX High Assurance Boot Reference Code Signing Tool.
+[2] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
+ HABv4" - Rev 2.
+[3] AN12056: "Encrypted Boot on HABv4 and CAAM Enabled Devices" - Rev. 1
diff --git a/roms/u-boot/doc/imx/habv4/script_examples/genIVT.pl b/roms/u-boot/doc/imx/habv4/script_examples/genIVT.pl
new file mode 100644
index 000000000..84a4fcb16
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/script_examples/genIVT.pl
@@ -0,0 +1,12 @@
+#! /usr/bin/perl -w
+use strict;
+open(my $out, '>:raw', 'ivt.bin') or die "Unable to open: $!";
+print $out pack("V", 0x412000D1); # Signature
+print $out pack("V", 0x80800000); # Load Address (*load_address)
+print $out pack("V", 0x0); # Reserved
+print $out pack("V", 0x0); # DCD pointer
+print $out pack("V", 0x0); # Boot Data
+print $out pack("V", 0x80EEA000); # Self Pointer (*ivt)
+print $out pack("V", 0x80EEA020); # CSF Pointer (*csf)
+print $out pack("V", 0x0); # Reserved
+close($out);