diff --git a/board/ti/dra7xx/README b/board/ti/dra7xx/README
deleted file mode 100644
index 533da01..0000000
--- a/board/ti/dra7xx/README
+++ /dev/null
@@ -1,26 +0,0 @@
-Summary
-=======
-
-This document covers various features of the 'dra7xx_evm' build and some
-related uses.
-
-eMMC boot partition use
-=======================
-
-It is possible, depending on SYSBOOT configuration to boot from the eMMC
-boot partitions using (name depending on documentation referenced)
-Alternative Boot operation mode or Boot Sequence Option 1/2.  In this
-example we load MLO and u-boot.img from the build into DDR and then use
-'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to
-set boot0 as the boot device.
-U-Boot # setenv autoload no
-U-Boot # usb start
-U-Boot # dhcp
-U-Boot # mmc dev 1 1
-U-Boot # tftp ${loadaddr} dra7xx/MLO
-U-Boot # mmc write ${loadaddr} 0 100
-U-Boot # tftp ${loadaddr} dra7xx/u-boot.img
-U-Boot # mmc write ${loadaddr} 300 400
-U-Boot # mmc bootbus 1 2 0 2
-U-Boot # mmc partconf 1 1 1 0
-U-Boot # mmc rst-function 1 1
diff --git a/board/ti/ks2_evm/README b/board/ti/ks2_evm/README
deleted file mode 100644
index ff0ec5a..0000000
--- a/board/ti/ks2_evm/README
+++ /dev/null
@@ -1,194 +0,0 @@
-U-Boot port for Texas Instruments Keystone II EVM boards
-========================================================
-
-Author: Murali Karicheri <m-karicheri2@ti.com>
-
-This README has information on the U-Boot port for K2HK, K2E, and K2L EVM boards.
-Documentation for this board can be found at
-http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
-https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
-https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
-
-The K2HK board is based on Texas Instruments Keystone2 family of SoCs: K2H, K2K.
-More details on these SoCs are available at company websites
- K2K: http://www.ti.com/product/tci6638k2k
- K2H: http://www.ti.com/product/tci6638k2h
-
-The K2E SoC details are available at
- http://www.ti.com/lit/ds/symlink/66ak2e05.pdf
-
-The K2L SoC details are available at
- http://www.ti.com/lit/ds/symlink/tci6630k2l.pdf
-
-The K2G SoC details are available at
- http://www.ti.com/lit/ds/symlink/66ak2g02.pdf
-
-Board configuration:
-====================
-
-Some of the peripherals that are configured by U-Boot
-+------+-------+-------+-----------+-----------+-------+-------+----+
-|      |DDR3   |NAND   |MSM SRAM   |ETH ports  |UART   |I2C    |SPI |
-+------+-------+-------+-----------+-----------+-------+-------+----+
-|K2HK  |2      |512MB  |6MB	   |4(2)       |2      |3      |3   |
-|K2E   |4      |512MB  |2MB	   |8(2)       |2      |3      |3   |
-|K2L   |2      |512MB  |2MB	   |4(2)       |4      |3      |3   |
-|K2G   |2      |256MB  |1MB	   |1          |1      |1      |1   |
-+------+-------+-------+-----------+-----------+-------+-------+----+
-
-There are only 2 eth port installed on the boards.
-
-There are separate PLLs to drive clocks to Tetris ARM and Peripherals.
-To bring up SMP Linux on this board, there is a boot monitor
-code that will be installed in MSMC SRAM. There is command available
-to install this image from U-Boot.
-
-The port related files can be found at following folders
- keystone2 SoC related files: arch/arm/cpu/armv7/keystone/
- EVMs board files: board/ti/k2s_evm/
-
-Board configuration files:
-include/configs/k2hk_evm.h
-include/configs/k2e_evm.h
-include/configs/k2l_evm.h
-include/configs/k2g_evm.h
-
-As U-Boot is migrating to Kconfig there is also board defconfig files
-configs/k2e_evm_defconfig
-configs/k2hk_evm_defconfig
-configs/k2l_evm_defconfig
-configs/k2g_evm_defconfig
-
-Supported boot modes:
- - SPI NOR boot
- - AEMIF NAND boot (K2E, K2L and K2HK)
- - UART boot
- - MMC boot (Only on K2G)
-
-Supported image formats:
- - u-boot.bin: for loading and running u-boot.bin through
-		Texas Instruments code composure studio (CCS) and for UART boot.
- - u-boot-spi.gph: gpimage for programming SPI NOR flash for SPI NOR boot
- - MLO: gpimage for programming NAND flash for NAND boot, MMC boot.
-
-Build instructions:
-===================
-Examples for k2hk, for k2e, k2l and k2g just replace k2hk prefix accordingly.
-Don't forget to add CROSS_COMPILE.
-
-To build u-boot.bin, u-boot-spi.gph, MLO:
-  >make k2hk_evm_defconfig
-  >make
-
-Load and Run U-Boot on keystone EVMs using CCS
-=========================================
-
-Need Code Composer Studio (CCS) installed on a PC to load and run u-boot.bin
-on EVM. See instructions at below link for installing CCS on a Windows PC.
-http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Getting_Started#
-Installing_Code_Composer_Studio
-Use u-boot.bin from the build folder for loading and running U-Boot binary
-on EVM. Follow instructions at
-K2HK http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup
-K2E  http://processors.wiki.ti.com/index.php/EVMK2E_Hardware_Setup
-K2L  http://processors.wiki.ti.com/index.php/TCIEVMK2L_Hardware_Setup
-K2G  http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup
-
-to configure SW1 dip switch to use "No Boot/JTAG DSP Little Endian Boot Mode"
-and Power ON the EVM.  Follow instructions to connect serial port of EVM to
-PC and start TeraTerm or Hyper Terminal.
-
-Start CCS on a Windows machine and Launch Target
-configuration as instructed at http://processors.wiki.ti.com/index.php/
-MCSDK_UG_Chapter_Exploring#Loading_and_Running_U-Boot_on_EVM_through_CCS.
-The instructions provided in the above link uses a script for
-loading the U-Boot binary on the target EVM. Instead do the following:-
-
-1. Right click to "Texas Instruments XDS2xx USB Emulator_0/CortexA15_1 core (D
-   is connected: Unknown)" at the debug window (This is created once Target
-   configuration is launched) and select "Connect Target".
-2. Once target connect is successful, choose Tools->Load Memory option from the
-   top level menu. At the Load Memory window, choose the file u-boot.bin
-   through "Browse" button and click "next >" button. In the next window, enter
-   Start address as 0xc000000, choose Type-size "32 bits" and click "Finish"
-   button.
-3. Click View -> Registers from the top level menu to view registers window.
-4. From Registers, window expand "Core Registers" to view PC. Edit PC value
-   to be 0xc000000. From the "Run" top level menu, select "Free Run"
-5. The U-Boot prompt is shown at the Tera Term/ Hyper terminal console as
-   below and type any key to stop autoboot as instructed :=
-
-U-Boot 2014.04-rc1-00201-gc215b5a (Mar 21 2014 - 12:47:59)
-
-I2C:   ready
-Detected SO-DIMM [SQR-SD3T-2G1333SED]
-DRAM:  1.1 GiB
-NAND:  512 MiB
-Net:   K2HK_EMAC
-Warning: K2HK_EMAC using MAC address from net device
-, K2HK_EMAC1, K2HK_EMAC2, K2HK_EMAC3
-Hit any key to stop autoboot:  0
-
-SPI NOR Flash programming instructions
-======================================
-U-Boot image can be flashed to first 512KB of the NOR flash using following
-instructions:
-
-1. Start CCS and run U-Boot as described above.
-2. Suspend Target. Select Run -> Suspend from top level menu
-   CortexA15_1 (Free Running)"
-3. Load u-boot-spi.gph binary from build folder on to DDR address 0x87000000
-   through CCS as described in step 2 of "Load and Run U-Boot on K2HK/K2E/K2L
-   EVM using CCS", but using address 0x87000000.
-4. Free Run the target as described earlier (step 4) to get U-Boot prompt
-5. At the U-Boot console type following to setup U-Boot environment variables.
-   setenv addr_uboot 0x87000000
-   setenv filesize <size in hex of u-boot-spi.gph rounded to hex 0x10000>
-   run burn_uboot_spi
-   Once U-Boot prompt is available, Power OFF the EVM. Set the SW1 dip switch
-   to "SPI Little Endian Boot mode" as per instruction at
-   http://processors.wiki.ti.com/index.php/*_Hardware_Setup.
-6. Power ON the EVM. The EVM now boots with U-Boot image on the NOR flash.
-
-AEMIF NAND Flash programming instructions
-======================================
-U-Boot image can be flashed to first 1024KB of the NAND flash using following
-instructions:
-
-1. Start CCS and run U-Boot as described above.
-2. Suspend Target. Select Run -> Suspend from top level menu
-   CortexA15_1 (Free Running)"
-3. Load MLO binary from build folder on to DDR address 0x87000000
-   through CCS as described in step 2 of "Load and Run U-Boot on K2HK EVM
-   using CCS", but using address 0x87000000.
-4. Free Run the target as described earlier (step 4) to get U-Boot prompt
-5. At the U-Boot console type following to setup U-Boot environment variables.
-   setenv filesize <size in hex of MLO rounded to hex 0x10000>
-   run burn_uboot_nand
-   Once U-Boot prompt is available, Power OFF the EVM. Set the SW1 dip switch
-   to "ARM NAND Boot mode" as per instruction at
-   http://processors.wiki.ti.com/index.php/*_Hardware_Setup.
-6. Power ON the EVM. The EVM now boots with U-Boot image on the NAND flash.
-
-Load and Run U-Boot on keystone EVMs using UART download
-========================================================
-
-Open BMC and regular UART terminals.
-
-1. On the regular UART port start xmodem transfer of the u-boot.bin
-2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM
-   BMC> bootmode #4
-   MBC> reboot
-3. When xmodem is complete you should see the U-Boot starts on the UART port
-
-Load and Run U-Boot on K2G EVMs using MMC
-========================================================
-
-Open BMC and regular UART terminals.
-
-1. Set the SW3 dip switch to "ARM MMC Boot mode" as per instruction at
-   http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup
-2. Create SD card partitions as per steps given in Hardware Setup Guide.
-3. Copy MLO to Boot Partition.
-4. Insert SD card and Power on the EVM.
-   The EVM now boots with U-Boot image from SD card.
diff --git a/doc/README.ti-secure b/doc/README.ti-secure
deleted file mode 100644
index 27c0eaa..0000000
--- a/doc/README.ti-secure
+++ /dev/null
@@ -1,226 +0,0 @@
-README on how boot images are created for secure TI devices
-
-CONFIG_TI_SECURE_DEVICE:
-Secure TI devices require a boot image that is authenticated by ROM
-code to function. Without this, even JTAG remains locked and the
-device is essentially useless. In order to create a valid boot image for
-a secure device from TI, the initial public software image must be signed
-and combined with various headers, certificates, and other binary images.
-
-Information on the details on the complete boot image format can be obtained
-from Texas Instruments. The tools used to generate boot images for secure
-devices are part of a secure development package (SECDEV) that can be
-downloaded from:
-
-	http://www.ti.com/mysecuresoftware (login required)
-
-The secure development package is access controlled due to NDA and export
-control restrictions. Access must be requested and granted by TI before the
-package is viewable and downloadable. Contact TI, either online or by way
-of a local TI representative, to request access.
-
-Booting of U-Boot SPL
-=====================
-
-	When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process
-	requires the presence and use of these tools in order to create a
-	viable boot image. The build process will look for the environment
-	variable TI_SECURE_DEV_PKG, which should be the path of the installed
-	SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or
-	if it is defined but doesn't point to a valid SECDEV package, a
-	warning is issued during the build to indicate that a final secure
-	bootable image was not created.
-
-	Within the SECDEV package exists an image creation script:
-
-	${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
-
-	This is called as part of the SPL/u-boot build process. As the secure
-	boot image formats and requirements differ between secure SOC from TI,
-	the purpose of this script is to abstract these details as much as
-	possible.
-
-	The script is basically the only required interface to the TI SECDEV
-	package for creating a bootable SPL image for secure TI devices.
-
-	Invoking the script for AM33xx Secure Devices
-	=============================================
-
-	create-boot-image.sh \
-		<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
-
-	<IMAGE_FLAG> is a value that specifies the type of the image to
-	generate OR the action the image generation tool will take. Valid
-	values are:
-		SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
-		X-LOADER - Generates an image for non-XIP flash
-		MLO - Generates an image for SD/MMC/eMMC media
-		2ND - Generates an image for USB, UART and Ethernet
-		XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
-
-	<INPUT_FILE> is the full path and filename of the public world boot
-	loaderbinary file (depending on the boot media, this is usually
-	either u-boot-spl.bin or u-boot.bin).
-
-	<OUTPUT_FILE> is the full path and filename of the final secure
-	image. The output binary images should be used in place of the standard
-	non-secure binary images (see the platform-specific user's guides and
-	releases notes for how the non-secure images are typically used)
-	u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
-	u-boot-spl_HS_X-LOADER - boot image for NAND or SD/MMC/eMMC rawmode
-	u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC media
-	u-boot-spl_HS_2ND - boot image for USB, UART and Ethernet
-	u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI Xip flash
-
-	<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
-	<INPUT_FILE>
-
-	Invoking the script for AM43xx Secure Devices
-	=============================================
-
-	create-boot-image.sh \
-		<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
-
-	<IMAGE_FLAG> is a value that specifies the type of the image to
-	generate OR the action the image generation tool will take. Valid
-	values are:
-		SPI_X-LOADER - Generates an image for SPI flash (byte
-			swapped)
-		XIP_X-LOADER - Generates a single stage u-boot for
-			NOR/QSPI XiP
-		ISSW - Generates an image for all other boot modes
-
-	<INPUT_FILE> is the full path and filename of the public world boot
-	loaderbinary file (depending on the boot media, this is usually
-	either u-boot-spl.bin or u-boot.bin).
-
-	<OUTPUT_FILE> is the full path and filename of the final secure
-	image. The output binary images should be used in place of the standard
-	non-secure binary images (see the platform-specific user's guides and
-	releases notes for how the non-secure images are typically used)
-	u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
-	u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
-	u-boot-spl_HS_ISSW - boot image for all other boot media
-
-	<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
-	<INPUT_FILE>
-
-	Invoking the script for DRA7xx/AM57xx Secure Devices
-	====================================================
-
-	create-boot-image.sh \
-		<IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
-
-	<IMAGE_TYPE> is a value that specifies the type of the image to
-	generate OR the action the image generation tool will take. Valid
-	values are:
-		X-LOADER - Generates an image for NOR or QSPI boot modes
-		MLO - Generates an image for SD/MMC/eMMC boot modes
-		ULO - Generates an image for USB/UART peripheral boot modes
-
-	<INPUT_FILE> is the full path and filename of the public world boot
-	loader binary file (for this platform, this is always u-boot-spl.bin).
-
-	<OUTPUT_FILE> is the full path and filename of the final secure image.
-	The output binary images should be used in place of the standard
-	non-secure binary images (see the platform-specific user's guides
-	and releases notes for how the non-secure images are typically used)
-	u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC. This image is
-		copied to a file named MLO, which is the name that
-		the device ROM bootloader requires for loading from
-		the FAT partition of an SD card (same as on
-		non-secure devices)
-	u-boot-spl_HS_ULO - boot image for USB/UART peripheral boot modes
-	u-boot-spl_HS_X-LOADER - boot image for all other flash memories
-		including QSPI and NOR flash
-
-	<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
-	<INPUT_FILE>
-
-	Invoking the script for Keystone2 Secure Devices
-	================================================
-
-	create-boot-image.sh \
-		<UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED>
-
-	<UNUSED> is currently ignored and reserved for future use.
-
-	<INPUT_FILE> is the full path and filename of the public world boot
-	loader binary file (only u-boot.bin is currently supported on
-	Keystone2 devices, u-boot-spl.bin is not currently supported).
-
-	<OUTPUT_FILE> is the full path and filename of the final secure image.
-	The output binary images should be used in place of the standard
-	non-secure binary images (see the platform-specific user's guides
-	and releases notes for how the non-secure images are typically used)
-	u-boot_HS_MLO - signed and encrypted boot image that can be used to
-		boot from all media. Secure boot from SPI NOR flash is not
-		currently supported.
-
-	Invoking the script for K3 Secure Devices
-	=========================================
-
-	The signing steps required to produce a bootable SPL image on secure
-	K3 TI devices are the same as those performed on non-secure devices.
-	The only difference is the key is not checked on non-secure devices so
-	a dummy key is used when building U-Boot for those devices. For secure
-	K3 TI devices simply use the real hardware key for your device. This
-	real key can be set with the Kconfig option "K3_KEY". The environment
-	variable TI_SECURE_DEV_PKG is also searched for real keys when the
-	build targets secure devices.
-
-Booting of Primary U-Boot (u-boot.img)
-======================================
-
-	The SPL image is responsible for loading the next stage boot loader,
-	which is the main u-boot image. For secure TI devices, the SPL will
-	be authenticated, as described above, as part of the particular
-	device's ROM boot process. In order to continue the secure boot
-	process, the authenticated SPL must authenticate the main u-boot
-	image that it loads.
-
-	The configurations for secure TI platforms are written to make the boot
-	process use the FIT image format for the u-boot.img (CONFIG_SPL_FRAMEWORK
-	and CONFIG_SPL_LOAD_FIT). With these configurations the binary
-	components that the SPL loads include a specific DTB image and u-boot
-	image. These DTB image may be one of many available to the boot
-	process. In order to secure these components so that they can be
-	authenticated by the SPL as they are loaded from the FIT image,	the
-	build procedure for secure TI devices will secure these images before
-	they are integrated into the FIT image. When those images are extracted
-	from the FIT image at boot time, they are post-processed to verify that
-	they are still secure. The outlined security-related SPL post-processing
-	is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which
-	must be enabled for the secure boot scheme to work. In order to allow
-	verifying proper operation of the secure boot chain in case of successful
-	authentication messages like "Authentication passed" are output by the
-	SPL to the console for each blob that got extracted from the FIT image.
-
-	The exact details of the how the images are secured is handled by the
-	SECDEV package. Within the SECDEV package exists a script to process
-	an input binary image:
-
-	${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh
-
-	This is called as part of the u-boot build process. As the secure
-	image formats and requirements can differ between the various secure
-	SOCs from TI, this script in the SECDEV package abstracts these
-	details. This script is essentially the only required interface to the
-	TI SECDEV package for creating a u-boot.img image for secure TI
-	devices.
-
-	The SPL/u-boot code contains calls to dedicated secure ROM functions
-	to perform the validation on the secured images. The details of the
-	interface to those functions is shown in the code. The summary
-	is that they are accessed by invoking an ARM secure monitor call to
-	the device's secure ROM (fixed read-only-memory that is secure and
-	only accessible when the ARM core is operating in the secure mode).
-
-	Invoking the secure-binary-image script for Secure Devices
-	==========================================================
-
-	secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>
-
-	<INPUT_FILE> is the full path and filename of the input binary image
-
-	<OUTPUT_FILE> is the full path and filename of the output secure image.
diff --git a/doc/SPI/README.ti_qspi_am43x_test b/doc/SPI/README.ti_qspi_am43x_test
deleted file mode 100644
index 8fbf10b..0000000
--- a/doc/SPI/README.ti_qspi_am43x_test
+++ /dev/null
@@ -1,76 +0,0 @@
-Testing details-
-----------------
-
-This doc simply illustrated the testing details of qspi flash
-driver with Macronix M25L51235 flash device.
-
-The test includes
-- probing the flash device
-- erasing the flash device
-- Writing to flash
-- Reading the contents of the flash.
-
-Test Log
---------
-
-Hit any key to stop autoboot:  0
-U-Boot# sf probe 0
-SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 64 MiB, mapped at 30000000
-U-Boot# sf erase 0 0x80000
-SF: 524288 bytes @ 0x0 Erased: OK
-U-Boot# mw 81000000 0xdededede 0x40000
-U-Boot# sf write 81000000 0 0x40000
-SF: 262144 bytes @ 0x0 Written: OK
-U-Boot# sf read 82000000 0 0x40000
-SF: 262144 bytes @ 0x0 Read: OK
-U-Boot# md 0x82000000
-82000000: dededede dededede dededede dededede    ................
-82000010: dededede dededede dededede dededede    ................
-82000020: dededede dededede dededede dededede    ................
-82000030: dededede dededede dededede dededede    ................
-82000040: dededede dededede dededede dededede    ................
-82000050: dededede dededede dededede dededede    ................
-82000060: dededede dededede dededede dededede    ................
-82000070: dededede dededede dededede dededede    ................
-82000080: dededede dededede dededede dededede    ................
-82000090: dededede dededede dededede dededede    ................
-820000a0: dededede dededede dededede dededede    ................
-820000b0: dededede dededede dededede dededede    ................
-820000c0: dededede dededede dededede dededede    ................
-820000d0: dededede dededede dededede dededede    ................
-820000e0: dededede dededede dededede dededede    ................
-820000f0: dededede dededede dededede dededede    ................
-U-Boot# md 0x82010000
-82010000: dededede dededede dededede dededede    ................
-82010010: dededede dededede dededede dededede    ................
-82010020: dededede dededede dededede dededede    ................
-82010030: dededede dededede dededede dededede    ................
-82010040: dededede dededede dededede dededede    ................
-82010050: dededede dededede dededede dededede    ................
-82010060: dededede dededede dededede dededede    ................
-82010070: dededede dededede dededede dededede    ................
-82010080: dededede dededede dededede dededede    ................
-82010090: dededede dededede dededede dededede    ................
-820100a0: dededede dededede dededede dededede    ................
-820100b0: dededede dededede dededede dededede    ................
-820100c0: dededede dededede dededede dededede    ................
-820100d0: dededede dededede dededede dededede    ................
-820100e0: dededede dededede dededede dededede    ................
-820100f0: dededede dededede dededede dededede    ................
-U-Boot# md 0x82030000
-82030000: dededede dededede dededede dededede    ................
-82030010: dededede dededede dededede dededede    ................
-82030020: dededede dededede dededede dededede    ................
-82030030: dededede dededede dededede dededede    ................
-82030040: dededede dededede dededede dededede    ................
-82030050: dededede dededede dededede dededede    ................
-82030060: dededede dededede dededede dededede    ................
-82030070: dededede dededede dededede dededede    ................
-82030080: dededede dededede dededede dededede    ................
-82030090: dededede dededede dededede dededede    ................
-820300a0: dededede dededede dededede dededede    ................
-820300b0: dededede dededede dededede dededede    ................
-820300c0: dededede dededede dededede dededede    ................
-820300d0: dededede dededede dededede dededede    ................
-820300e0: dededede dededede dededede dededede    ................
-820300f0: dededede dededede dededede dededede    ................
diff --git a/doc/SPI/README.ti_qspi_dra_test b/doc/SPI/README.ti_qspi_dra_test
deleted file mode 100644
index e89f535..0000000
--- a/doc/SPI/README.ti_qspi_dra_test
+++ /dev/null
@@ -1,47 +0,0 @@
--------------------------------------------------
-   Simple steps used to test the QSPI at U-Boot
--------------------------------------------------
-
-For #1, build the patched U-Boot and load MLO/u-boot.img
-
-----------------------------------
-Boot from another medium like MMC
-----------------------------------
-
-U-Boot# mmc dev 0
-mmc0 is current device
-U-Boot# fatload mmc 0 0x82000000 MLO
-reading MLO
-55872 bytes read in 8 ms (6.7 MiB/s)
-U-Boot# fatload mmc 0 0x83000000 u-boot.img
-reading u-boot.img
-248600 bytes read in 19 ms (12.5 MiB/s)
-
---------------------------------------------------
-Commands to erase/write u-boot/mlo to flash device
---------------------------------------------------
-U-Boot# sf probe 0
-SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
-U-Boot# sf erase 0 0x10000
-SF: 65536 bytes @ 0x0 Erased: OK
-U-Boot# sf erase 0x20000 0x10000
-SF: 65536 bytes @ 0x20000 Erased: OK
-U-Boot# sf erase 0x30000 0x10000
-SF: 65536 bytes @ 0x30000 Erased: OK
-U-Boot# sf erase 0x40000 0x10000
-SF: 65536 bytes @ 0x40000 Erased: OK
-U-Boot# sf erase 0x50000 0x10000
-SF: 65536 bytes @ 0x50000 Erased: OK
-U-Boot# sf erase 0x60000 0x10000
-SF: 65536 bytes @ 0x60000 Erased: OK
-U-Boot# sf write 82000000 0 0x10000
-SF: 65536 bytes @ 0x0 Written: OK
-U-Boot# sf write 83000000 0x20000 0x60000
-SF: 393216 bytes @ 0x20000 Written: OK
-
-For #2, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
-on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
-then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
-find a U-Boot image header at offset 0x20000 (set in the config file)
-and proceeds to load that image using the U-Boot image payload offset/size
-from the header. It will then start U-Boot.
diff --git a/doc/SPI/README.ti_qspi_flash b/doc/SPI/README.ti_qspi_flash
deleted file mode 100644
index 5cc1fd0..0000000
--- a/doc/SPI/README.ti_qspi_flash
+++ /dev/null
@@ -1,47 +0,0 @@
-QSPI U-Boot support
-------------------
-
-Host processor is connected to serial flash device via qpsi
-interface. QSPI is a kind of spi module that allows single,
-dual and quad read access to external spi devices. The module
-has a memory mapped interface which provide direct interface
-for accessing data form external spi devices.
-
-The one QSPI in the device is primarily intended for fast booting
-from Quad SPI flash devices.
-
-Usecase
--------
-
-MLO/u-boot.img will be flashed from SD/MMC to the flash device
-using serial flash erase and write commands. Then, switch settings
-will be changed to qspi boot. Then, the ROM code will read MLO
-from the predefined location in the flash, where it was flashed and
-execute it after storing it in SDRAM. Then, the MLO will read
-u-boot.img from flash and execute it from SDRAM.
-
-SPI mode
--------
-SPI mode uses mtd spi framework for transfer and reception of data.
-Can be used in:
-1. Normal mode: use single pin for transfers
-2. Dual Mode: use two pins for transfers.
-3. Quad mode: use four pin for transfer
-
-Memory mapped read mode
------------------------
-In this, SPI controller is configured using configuration port and then
-controller is switched to memory mapped port for data read.
-
-Driver
-------
-drivers/qspi/ti_qspi.c
-    - Newly created file which is responsible for configuring the
-	qspi controller and also for providing the low level api which
-	is responsible for transferring the datas from host controller
-	to flash device and vice versa.
-
-Testing
--------
-A seperated file named README.dra_qspi_test has been created which gives all the
-details about the commands required to test qspi at U-Boot level.
diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst
index 3332d51..2ba651e 100644
--- a/doc/board/ti/am335x_evm.rst
+++ b/doc/board/ti/am335x_evm.rst
@@ -43,6 +43,180 @@
 `include/configs/ti_am335x_common.h` and `include/configs/am335x_evm.h` as the
 migration to Kconfig is not yet complete.
 
+Secure Boot
+-----------
+
+.. secure_boot_include_start_config_ti_secure_device
+
+Secure TI devices require a boot image that is authenticated by ROM
+code to function. Without this, even JTAG remains locked and the
+device is essentially useless. In order to create a valid boot image for
+a secure device from TI, the initial public software image must be signed
+and combined with various headers, certificates, and other binary images.
+
+Information on the details on the complete boot image format can be obtained
+from Texas Instruments. The tools used to generate boot images for secure
+devices are part of a secure development package (SECDEV) that can be
+downloaded from:
+
+	http://www.ti.com/mysecuresoftware (login required)
+
+The secure development package is access controlled due to NDA and export
+control restrictions. Access must be requested and granted by TI before the
+package is viewable and downloadable. Contact TI, either online or by way
+of a local TI representative, to request access.
+
+.. secure_boot_include_end_config_ti_secure_device
+
+.. secure_boot_include_start_spl_boot
+
+1. Booting of U-Boot SPL
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process
+requires the presence and use of these tools in order to create a
+viable boot image. The build process will look for the environment
+variable TI_SECURE_DEV_PKG, which should be the path of the installed
+SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or
+if it is defined but doesn't point to a valid SECDEV package, a
+warning is issued during the build to indicate that a final secure
+bootable image was not created.
+
+Within the SECDEV package exists an image creation script:
+
+.. prompt:: bash
+   :prompts: $
+
+   ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
+
+This is called as part of the SPL/u-boot build process. As the secure
+boot image formats and requirements differ between secure SOC from TI,
+the purpose of this script is to abstract these details as much as
+possible.
+
+The script is basically the only required interface to the TI SECDEV
+package for creating a bootable SPL image for secure TI devices.
+
+.. prompt:: bash
+   :prompts: $
+
+   create-boot-image.sh \
+		<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
+
+.. secure_boot_include_end_spl_boot
+
+<IMAGE_FLAG> is a value that specifies the type of the image to
+generate OR the action the image generation tool will take. Valid
+values are:
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 0
+
+   * - PI_X-LOADER
+     - Generates an image for SPI flash (byte swapped)
+   * - X-LOADER
+     - Generates an image for non-XIP flash
+   * - MLO
+     - Generates an image for SD/MMC/eMMC media
+   * - 2ND
+     - Generates an image for USB, UART and Ethernet
+   * - XIP_X-LOADER
+     - Generates a single stage u-boot for NOR/QSPI XiP
+
+<INPUT_FILE> is the full path and filename of the public world boot
+loaderbinary file (depending on the boot media, this is usually
+either u-boot-spl.bin or u-boot.bin).
+
+<OUTPUT_FILE> is the full path and filename of the final secure
+image. The output binary images should be used in place of the standard
+non-secure binary images (see the platform-specific user's guides and
+releases notes for how the non-secure images are typically used)
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 0
+
+   * - u-boot-spl_HS_SPI_X-LOADER
+     - byte swapped boot image for SPI flash
+   * - u-boot-spl_HS_X-LOADER
+     - boot image for NAND or SD/MMC/eMMC rawmode
+   * - u-boot-spl_HS_MLO
+     - boot image for SD/MMC/eMMC media
+   * - u-boot-spl_HS_2ND
+     - boot image for USB, UART and Ethernet
+   * - u-boot_HS_XIP_X-LOADER
+     - boot image for NOR or QSPI Xip flash
+
+<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+<INPUT_FILE>
+
+.. secure_boot_include_start_primary_u_boot
+
+2. Booting of Primary U-Boot (u-boot.img)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The SPL image is responsible for loading the next stage boot loader,
+which is the main u-boot image. For secure TI devices, the SPL will
+be authenticated, as described above, as part of the particular
+device's ROM boot process. In order to continue the secure boot
+process, the authenticated SPL must authenticate the main u-boot
+image that it loads.
+
+The configurations for secure TI platforms are written to make the boot
+process use the FIT image format for the u-boot.img (CONFIG_SPL_FRAMEWORK
+and CONFIG_SPL_LOAD_FIT). With these configurations the binary
+components that the SPL loads include a specific DTB image and u-boot
+image. These DTB image may be one of many available to the boot
+process. In order to secure these components so that they can be
+authenticated by the SPL as they are loaded from the FIT image,	the
+build procedure for secure TI devices will secure these images before
+they are integrated into the FIT image. When those images are extracted
+from the FIT image at boot time, they are post-processed to verify that
+they are still secure. The outlined security-related SPL post-processing
+is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which
+must be enabled for the secure boot scheme to work. In order to allow
+verifying proper operation of the secure boot chain in case of successful
+authentication messages like "Authentication passed" are output by the
+SPL to the console for each blob that got extracted from the FIT image.
+
+The exact details of the how the images are secured is handled by the
+SECDEV package. Within the SECDEV package exists a script to process
+an input binary image:
+
+.. prompt:: bash
+   :prompts: $
+
+   ${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh
+
+This is called as part of the u-boot build process. As the secure
+image formats and requirements can differ between the various secure
+SOCs from TI, this script in the SECDEV package abstracts these
+details. This script is essentially the only required interface to the
+TI SECDEV package for creating a u-boot.img image for secure TI
+devices.
+
+The SPL/u-boot code contains calls to dedicated secure ROM functions
+to perform the validation on the secured images. The details of the
+interface to those functions is shown in the code. The summary
+is that they are accessed by invoking an ARM secure monitor call to
+the device's secure ROM (fixed read-only-memory that is secure and
+only accessible when the ARM core is operating in the secure mode).
+
+Invoking the secure-binary-image script for Secure Devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. prompt:: bash
+   :prompts: $
+
+   secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>
+
+<INPUT_FILE> is the full path and filename of the input binary image
+
+<OUTPUT_FILE> is the full path and filename of the output secure image.
+
+.. secure_boot_include_end_primary_u_boot
+
 NAND
 ----
 
@@ -52,41 +226,53 @@
 have been configured correctly for the board. All images are first loaded
 into memory, then written to NAND.
 
-Step-1: Building u-boot for NAND boot
-	Set following CONFIGxx options for NAND device.
-	CONFIG_SYS_NAND_PAGE_SIZE	number of main bytes in NAND page
-	CONFIG_SYS_NAND_OOBSIZE		number of OOB bytes in NAND page
-	CONFIG_SYS_NAND_BLOCK_SIZE	number of bytes in NAND erase-block
-	CFG_SYS_NAND_ECCPOS		ECC map for NAND page
-	CONFIG_NAND_OMAP_ECCSCHEME	(refer doc/README.nand)
+1. Building u-boot for NAND boot
 
-Step-2: Flashing NAND via MMC/SD
+.. list-table:: CONFIGxx options for NAND device
+   :widths: 25 25
+   :header-rows: 1
 
-.. code-block:: text
+   * - Config
+     - Description
+   * - CONFIG_SYS_NAND_PAGE_SIZE
+     - number of main bytes in NAND page
+   * - CONFIG_SYS_NAND_OOBSIZE
+     - number of OOB bytes in NAND page
+   * - CONFIG_SYS_NAND_BLOCK_SIZE
+     - number of bytes in NAND erase-block
+   * - CFG_SYS_NAND_ECCPOS
+     - ECC map for NAND page
+   * - CONFIG_NAND_OMAP_ECCSCHEME
+     - (refer doc/README.nand)
 
-	# select BOOTSEL to MMC/SD boot and boot from MMC/SD card
-	U-Boot # mmc rescan
-	# erase flash
-	U-Boot # nand erase.chip
-	U-Boot # env default -f -a
-	U-Boot # saveenv
-	# flash MLO. Redundant copies of MLO are kept for failsafe
-	U-Boot # load mmc 0 0x82000000 MLO
-	U-Boot # nand write 0x82000000 0x00000 0x20000
-	U-Boot # nand write 0x82000000 0x20000 0x20000
-	U-Boot # nand write 0x82000000 0x40000 0x20000
-	U-Boot # nand write 0x82000000 0x60000 0x20000
-	# flash u-boot.img
-	U-Boot # load mmc 0 0x82000000 u-boot.img
-	U-Boot # nand write 0x82000000 0x80000 0x60000
-	# flash kernel image
-	U-Boot # load mmc 0 0x82000000 uImage
-	U-Boot # nand write 0x82000000 ${nandsrcaddr} ${nandimgsize}
-	# flash filesystem image
-	U-Boot # load mmc 0 0x82000000 filesystem.img
-	U-Boot # nand write 0x82000000 ${loadaddress} 0x300000
+2. Flashing NAND via MMC/SD
 
-Step-3: Set BOOTSEL pin to select NAND boot, and POR the device.
+.. prompt:: bash
+   :prompts: =>
+
+   # select BOOTSEL to MMC/SD boot and boot from MMC/SD card
+   mmc rescan
+   # erase flash
+   nand erase.chip
+   env default -f -a
+   saveenv
+   # flash MLO. Redundant copies of MLO are kept for failsafe
+   load mmc 0 0x82000000 MLO
+   nand write 0x82000000 0x00000 0x20000
+   nand write 0x82000000 0x20000 0x20000
+   nand write 0x82000000 0x40000 0x20000
+   nand write 0x82000000 0x60000 0x20000
+   # flash u-boot.img
+   load mmc 0 0x82000000 u-boot.img
+   nand write 0x82000000 0x80000 0x60000
+   # flash kernel image
+   load mmc 0 0x82000000 uImage
+   nand write 0x82000000 ${nandsrcaddr} ${nandimgsize}
+   # flash filesystem image
+   load mmc 0 0x82000000 filesystem.img
+   nand write 0x82000000 ${loadaddress} 0x300000
+
+3. Set BOOTSEL pin to select NAND boot, and POR the device.
 	The device should boot from images flashed on NAND device.
 
 
@@ -107,16 +293,34 @@
 
 The recommended layout in this case is:
 
-.. code-block:: text
+.. list-table:: eMMC Recommended Layout
+   :widths: 25 25 50
+   :header-rows: 1
 
-	MMC BLOCKS      |--------------------------------| LOCATION IN BYTES
-	0x0000 - 0x007F : MBR or GPT table               : 0x000000 - 0x020000
-	0x0080 - 0x00FF : ARGS or FDT file               : 0x010000 - 0x020000
-	0x0100 - 0x01FF : SPL.backup1 (first copy used)  : 0x020000 - 0x040000
-	0x0200 - 0x02FF : SPL.backup2 (second copy used) : 0x040000 - 0x060000
-	0x0300 - 0x06FF : U-Boot                         : 0x060000 - 0x0e0000
-	0x0700 - 0x08FF : U-Boot Env + Redundant         : 0x0e0000 - 0x120000
-	0x0900 - 0x28FF : Kernel                         : 0x120000 - 0x520000
+   * - MMC Blocks
+     - Description
+     - Location in bytes
+   * - 0x0000 - 0x007F
+     - MBR or GPT table
+     - 0x000000 - 0x020000
+   * - 0x0080 - 0x00FF
+     - ARGS or FDT file
+     - 0x010000 - 0x020000
+   * - 0x0100 - 0x01FF
+     - SPL.backup1 (first copy used)
+     - 0x020000 - 0x040000
+   * - 0x0200 - 0x02FF
+     - SPL.backup2 (second copy used)
+     - 0x040000 - 0x060000
+   * - 0x0300 - 0x06FF
+     - U-Boot
+     - 0x060000 - 0x0e0000
+   * - 0x0700 - 0x08FF
+     - U-Boot Env + Redundant
+     - 0x0e0000 - 0x120000
+   * - 0x0900 - 0x28FF
+     - Kernel
+     - 0x120000 - 0x520000
 
 Note that when we run 'spl export' it will prepare to boot the kernel.
 This includes relocation of the uImage from where we loaded it to the entry
@@ -130,27 +334,28 @@
 write garbage into the area, you must delete it from the partition table
 first.
 
-.. code-block:: text
+.. prompt:: bash
+   :prompts: =>
 
-	# Ensure we are able to talk with this mmc device
-	U-Boot # mmc rescan
-	U-Boot # tftp 81000000 am335x/MLO
-	# Write to two of the backup locations ROM uses
-	U-Boot # mmc write 81000000 100 100
-	U-Boot # mmc write 81000000 200 100
-	# Write U-Boot to the location set in the config
-	U-Boot # tftp 81000000 am335x/u-boot.img
-	U-Boot # mmc write 81000000 300 400
-	# Load kernel and device tree into memory, perform export
-	U-Boot # tftp 81000000 am335x/uImage
-	U-Boot # run findfdt
-	U-Boot # tftp ${fdtaddr} am335x/${fdtfile}
-	U-Boot # run mmcargs
-	U-Boot # spl export fdt 81000000 - ${fdtaddr}
-	# Write the updated device tree to MMC
-	U-Boot # mmc write ${fdtaddr} 80 80
-	# Write the uImage to MMC
-	U-Boot # mmc write 81000000 900 2000
+   # Ensure we are able to talk with this mmc device
+   mmc rescan
+   tftp 81000000 am335x/MLO
+   # Write to two of the backup locations ROM uses
+   mmc write 81000000 100 100
+   mmc write 81000000 200 100
+   # Write U-Boot to the location set in the config
+   tftp 81000000 am335x/u-boot.img
+   mmc write 81000000 300 400
+   # Load kernel and device tree into memory, perform export
+   tftp 81000000 am335x/uImage
+   run findfdt
+   tftp ${fdtaddr} am335x/${fdtfile}
+   run mmcargs
+   spl export fdt 81000000 - ${fdtaddr}
+   # Write the updated device tree to MMC
+   mmc write ${fdtaddr} 80 80
+   # Write the uImage to MMC
+   mmc write 81000000 900 2000
 
 Falcon Mode: FAT SD cards
 -------------------------
@@ -161,28 +366,30 @@
 afterwards) along with a Falcon Mode aware MLO and the FAT partition has
 already been created and marked bootable:
 
-.. code-block:: text
+.. prompt:: bash
+   :prompts: =>
 
-	U-Boot # mmc rescan
-	# Load kernel and device tree into memory, perform export
-	U-Boot # load mmc 0:1 ${loadaddr} uImage
-	U-Boot # run findfdt
-	U-Boot # load mmc 0:1 ${fdtaddr} ${fdtfile}
-	U-Boot # run mmcargs
-	U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
+   mmc rescan
+   # Load kernel and device tree into memory, perform export
+   load mmc 0:1 ${loadaddr} uImage
+   run findfdt
+   load mmc 0:1 ${fdtaddr} ${fdtfile}
+   run mmcargs
+   spl export fdt ${loadaddr} - ${fdtaddr}
 
 This will print a number of lines and then end with something like:
 
-.. code-block:: text
+.. code-block:: bash
 
-           Using Device Tree in place at 80f80000, end 80f85928
-           Using Device Tree in place at 80f80000, end 80f88928
+   Using Device Tree in place at 80f80000, end 80f85928
+   Using Device Tree in place at 80f80000, end 80f88928
 
 So then you:
 
-.. code-block:: text
+.. prompt:: bash
+   :prompts: =>
 
-        U-Boot # fatwrite mmc 0:1 0x80f80000 args 8928
+   fatwrite mmc 0:1 0x80f80000 args 8928
 
 Falcon Mode: NAND
 -----------------
@@ -193,14 +400,15 @@
 along with a Falcon Mode aware MLO written to the correct locations for
 booting and mtdparts have been configured correctly for the board:
 
-.. code-block:: text
+.. prompt:: bash
+   :prompts: =>
 
-	U-Boot # nand read ${loadaddr} kernel
-	U-Boot # load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
-	U-Boot # run nandargs
-	U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
-	U-Boot # nand erase.part u-boot-spl-os
-	U-Boot # nand write ${fdtaddr} u-boot-spl-os
+   nand read ${loadaddr} kernel
+   load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
+   run nandargs
+   spl export fdt ${loadaddr} - ${fdtaddr}
+   nand erase.part u-boot-spl-os
+   nand write ${fdtaddr} u-boot-spl-os
 
 USB device
 ----------
@@ -217,27 +425,35 @@
 device, so the user can easily configure their platform differently from
 the command line:
 
+.. prompt:: bash
+   :prompts: =>
+
+   dm tree
+
 .. code-block:: text
 
-	=> dm tree
-	 Class     Index  Probed  Driver                Name
-	-----------------------------------------------------------
-	[...]
-	misc          0  [ + ]   ti-musb-wrapper       |   |-- usb@47400000
-	usb           0  [ + ]   ti-musb-peripheral    |   |   |-- usb@47401000
-	ethernet      1  [ + ]   usb_ether             |   |   |   `-- usb_ether
-	bootdev       3  [   ]   eth_bootdev           |   |   |       `-- usb_ether.bootdev
-	usb           0  [   ]   ti-musb-host          |   |   `-- usb@47401800
+   Class     Index  Probed  Driver                Name
+  -----------------------------------------------------------
+  [...]
+  misc          0  [ + ]   ti-musb-wrapper       |   |-- usb@47400000
+  usb           0  [ + ]   ti-musb-peripheral    |   |   |-- usb@47401000
+  ethernet      1  [ + ]   usb_ether             |   |   |   `-- usb_ether
+  bootdev       3  [   ]   eth_bootdev           |   |   |       `-- usb_ether.bootdev
+  usb           0  [   ]   ti-musb-host          |   |   `-- usb@47401800
 
 Typically here any network command performed using the usb_ether
 interface would work, while using other gadgets would fail:
 
+.. prompt:: bash
+   :prompts: =>
+
+   fastboot usb 0
+
 .. code-block:: text
 
-	=> fastboot usb 0
-	All UDC in use (1 available), use the unbind command
-	g_dnl_register: failed!, error: -19
-	exit not allowed from main input shell.
+  All UDC in use (1 available), use the unbind command
+  g_dnl_register: failed!, error: -19
+  exit not allowed from main input shell.
 
 As hinted by the primary error message, the only controller available
 (usb@47401000) is currently bound to the usb_ether driver, which makes
@@ -246,20 +462,25 @@
 use the unbind command specifying the class and index parameters (as
 shown above in the 'dm tree' output) to target the driver to unbind:
 
-.. code-block:: text
+.. prompt:: bash
+   :prompts: =>
 
-	=> unbind ethernet 1
+   unbind ethernet 1
 
 The output of the 'dm tree' command now shows the availability of the
 first USB device controller, the fastboot gadget will now be able to
 bind with it:
 
+.. prompt:: bash
+   :prompts: =>
+
+   dm tree
+
 .. code-block:: text
 
-	=> dm tree
-	 Class     Index  Probed  Driver                Name
-	-----------------------------------------------------------
-	[...]
-	misc          0  [ + ]   ti-musb-wrapper       |   |-- usb@47400000
-	usb           0  [   ]   ti-musb-peripheral    |   |   |-- usb@47401000
-	usb           0  [   ]   ti-musb-host          |   |   `-- usb@47401800
+  Class     Index  Probed  Driver                Name
+  -----------------------------------------------------------
+  [...]
+  misc          0  [ + ]   ti-musb-wrapper       |   |-- usb@47400000
+  usb           0  [   ]   ti-musb-peripheral    |   |   |-- usb@47401000
+  usb           0  [   ]   ti-musb-host          |   |   `-- usb@47401800
diff --git a/doc/board/ti/am43xx_evm.rst b/doc/board/ti/am43xx_evm.rst
new file mode 100644
index 0000000..543526c
--- /dev/null
+++ b/doc/board/ti/am43xx_evm.rst
@@ -0,0 +1,188 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Neha Malcom Francis <n-francis@ti.com>
+
+AM43xx Generation
+=================
+
+Secure Boot
+-----------
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_config_ti_secure_device
+   :end-before: .. secure_boot_include_end_config_ti_secure_device
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_spl_boot
+   :end-before: .. secure_boot_include_end_spl_boot
+
+<IMAGE_FLAG> is a value that specifies the type of the image to
+generate OR the action the image generation tool will take. Valid
+values are:
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 0
+
+   * - SPI_X-LOADER
+     - Generates an image for SPI flash (byte swapped)
+   * - XIP_X-LOADER
+     - Generates a single stage u-boot for NOR/QSPI XiP
+   * - ISSW
+     - Generates an image for all other boot modes
+
+<INPUT_FILE> is the full path and filename of the public world boot
+loaderbinary file (depending on the boot media, this is usually
+either u-boot-spl.bin or u-boot.bin).
+
+<OUTPUT_FILE> is the full path and filename of the final secure
+image. The output binary images should be used in place of the standard
+non-secure binary images (see the platform-specific user's guides and
+releases notes for how the non-secure images are typically used)
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 0
+
+   * - u-boot-spl_HS_SPI_X-LOADER
+     - byte swapped boot image for SPI flash
+   * - u-boot_HS_XIP_X-LOADER
+     - boot image for NOR or QSPI Xip flash
+   * - u-boot-spl_HS_ISSW
+     - boot image for all other boot media
+
+
+<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+<INPUT_FILE>
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_primary_u_boot
+   :end-before: .. secure_boot_include_end_primary_u_boot
+
+.. qspi_boot_support_include_start
+
+QSPI U-Boot support
+-------------------
+
+Host processor is connected to serial flash device via qpsi
+interface. QSPI is a kind of spi module that allows single,
+dual and quad read access to external spi devices. The module
+has a memory mapped interface which provide direct interface
+for accessing data form external spi devices.
+
+The one QSPI in the device is primarily intended for fast booting
+from Quad SPI flash devices.
+
+Usecase
+^^^^^^^
+
+MLO/u-boot.img will be flashed from SD/MMC to the flash device
+using serial flash erase and write commands. Then, switch settings
+will be changed to qspi boot. Then, the ROM code will read MLO
+from the predefined location in the flash, where it was flashed and
+execute it after storing it in SDRAM. Then, the MLO will read
+u-boot.img from flash and execute it from SDRAM.
+
+SPI mode
+^^^^^^^^
+
+SPI mode uses mtd spi framework for transfer and reception of data.
+Can be used in:
+
+ #. Normal mode: use single pin for transfers
+ #. Dual Mode: use two pins for transfers.
+ #. Quad mode: use four pin for transfer
+
+Memory mapped read mode
+^^^^^^^^^^^^^^^^^^^^^^^
+
+In this, SPI controller is configured using configuration port and then
+controller is switched to memory mapped port for data read.
+
+Driver
+^^^^^^
+
+drivers/qspi/ti_qspi.c
+    - File which is responsible for configuring the
+      qspi controller and also for providing the low level api which
+      is responsible for transferring the datas from host controller
+      to flash device and vice versa.
+
+.. qspi_boot_support_include_end
+
+Testing
+^^^^^^^
+
+These are the testing details of qspi flash driver with Macronix M25L51235
+flash device.
+
+The test includes
+ - probing the flash device
+ - erasing the flash device
+ - Writing to flash
+ - Reading the contents of the flash.
+
+Test Log
+
+.. code-block:: bash
+
+  Hit any key to stop autoboot:  0
+  => sf probe 0
+  SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 64 MiB, mapped at 30000000
+  => sf erase 0 0x80000
+  SF: 524288 bytes @ 0x0 Erased: OK
+  => mw 81000000 0xdededede 0x40000
+  => sf write 81000000 0 0x40000
+  SF: 262144 bytes @ 0x0 Written: OK
+  => sf read 82000000 0 0x40000
+  SF: 262144 bytes @ 0x0 Read: OK
+  => md 0x82000000
+  82000000: dededede dededede dededede dededede    ................
+  82000010: dededede dededede dededede dededede    ................
+  82000020: dededede dededede dededede dededede    ................
+  82000030: dededede dededede dededede dededede    ................
+  82000040: dededede dededede dededede dededede    ................
+  82000050: dededede dededede dededede dededede    ................
+  82000060: dededede dededede dededede dededede    ................
+  82000070: dededede dededede dededede dededede    ................
+  82000080: dededede dededede dededede dededede    ................
+  82000090: dededede dededede dededede dededede    ................
+  820000a0: dededede dededede dededede dededede    ................
+  820000b0: dededede dededede dededede dededede    ................
+  820000c0: dededede dededede dededede dededede    ................
+  820000d0: dededede dededede dededede dededede    ................
+  820000e0: dededede dededede dededede dededede    ................
+  820000f0: dededede dededede dededede dededede    ................
+  => md 0x82010000
+  82010000: dededede dededede dededede dededede    ................
+  82010010: dededede dededede dededede dededede    ................
+  82010020: dededede dededede dededede dededede    ................
+  82010030: dededede dededede dededede dededede    ................
+  82010040: dededede dededede dededede dededede    ................
+  82010050: dededede dededede dededede dededede    ................
+  82010060: dededede dededede dededede dededede    ................
+  82010070: dededede dededede dededede dededede    ................
+  82010080: dededede dededede dededede dededede    ................
+  82010090: dededede dededede dededede dededede    ................
+  820100a0: dededede dededede dededede dededede    ................
+  820100b0: dededede dededede dededede dededede    ................
+  820100c0: dededede dededede dededede dededede    ................
+  820100d0: dededede dededede dededede dededede    ................
+  820100e0: dededede dededede dededede dededede    ................
+  820100f0: dededede dededede dededede dededede    ................
+  => md 0x82030000
+  82030000: dededede dededede dededede dededede    ................
+  82030010: dededede dededede dededede dededede    ................
+  82030020: dededede dededede dededede dededede    ................
+  82030030: dededede dededede dededede dededede    ................
+  82030040: dededede dededede dededede dededede    ................
+  82030050: dededede dededede dededede dededede    ................
+  82030060: dededede dededede dededede dededede    ................
+  82030070: dededede dededede dededede dededede    ................
+  82030080: dededede dededede dededede dededede    ................
+  82030090: dededede dededede dededede dededede    ................
+  820300a0: dededede dededede dededede dededede    ................
+  820300b0: dededede dededede dededede dededede    ................
+  820300c0: dededede dededede dededede dededede    ................
+  820300d0: dededede dededede dededede dededede    ................
+  820300e0: dededede dededede dededede dededede    ................
+  820300f0: dededede dededede dededede dededede    ................
diff --git a/doc/board/ti/dra7xx_evm.rst b/doc/board/ti/dra7xx_evm.rst
new file mode 100644
index 0000000..4503b5e
--- /dev/null
+++ b/doc/board/ti/dra7xx_evm.rst
@@ -0,0 +1,139 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Neha Malcom Francis <n-francis@ti.com>
+
+DRA7xx Generation
+=================
+
+Secure Boot
+-----------
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_config_ti_secure_device
+   :end-before: .. secure_boot_include_end_config_ti_secure_device
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_spl_boot
+   :end-before: .. secure_boot_include_end_spl_boot
+
+<IMAGE_FLAG> is a value that specifies the type of the image to
+generate OR the action the image generation tool will take. Valid
+values are:
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 0
+
+   * - X-LOADER
+     - Generates an image for NOR or QSPI boot modes
+   * - MLO
+     - Generates an image for NOR or QSPI boot modes
+   * - ULO
+     - Generates an image for USB/UART peripheral boot modes
+
+<INPUT_FILE> is the full path and filename of the public world boot
+loaderbinary file (for this platform, this is always u-boot-spl.bin).
+
+<OUTPUT_FILE> is the full path and filename of the final secure image.
+The output binary images should be used in place of the standard
+non-secure binary images (see the platform-specific user's guides
+and releases notes for how the non-secure images are typically used)
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 0
+
+   * - u-boot-spl_HS_SPI_X-LOADER
+     - boot image for SD/MMC/eMMC. This image is
+       copied to a file named MLO, which is the name that
+       the device ROM bootloader requires for loading from
+       the FAT partition of an SD card (same as on
+       non-secure devices)
+   * - u-boot-spl_HS_ULO
+     - boot image for USB/UART peripheral boot modes
+   * - u-boot-spl_HS_X-LOADER
+     - boot image for all other flash memories
+       including QSPI and NOR flash
+
+<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+<INPUT_FILE>
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_primary_u_boot
+   :end-before: .. secure_boot_include_end_primary_u_boot
+
+eMMC Boot Partition Use
+-----------------------
+
+It is possible, depending on SYSBOOT configuration to boot from the eMMC
+boot partitions using (name depending on documentation referenced)
+Alternative Boot operation mode or Boot Sequence Option 1/2.  In this
+example we load MLO and u-boot.img from the build into DDR and then use
+'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to
+set boot0 as the boot device.
+
+.. prompt:: bash
+   :prompts: =>
+
+   setenv autoload no
+   usb start
+   dhcp
+   mmc dev 1 1
+   tftp ${loadaddr} dra7xx/MLO
+   mmc write ${loadaddr} 0 100
+   tftp ${loadaddr} dra7xx/u-boot.img
+   mmc write ${loadaddr} 300 400
+   mmc bootbus 1 2 0 2
+   mmc partconf 1 1 1 0
+   mmc rst-function 1 1
+
+.. include:: am43xx_evm.rst
+   :start-after: qspi_boot_support_include_start
+   :end-before: qspi_boot_support_include_end
+
+Testing
+^^^^^^^
+
+Build the patched U-Boot and load MLO/u-boot.img.
+
+Boot from another medium like MMC
+
+.. prompt:: bash
+
+  => mmc dev 0
+  mmc0 is current device
+  => fatload mmc 0 0x82000000 MLO
+  reading MLO
+  55872 bytes read in 8 ms (6.7 MiB/s)
+  => fatload mmc 0 0x83000000 u-boot.img
+  reading u-boot.img
+  248600 bytes read in 19 ms (12.5 MiB/s)
+
+Commands to erase/write u-boot/MLO to flash device
+
+.. prompt:: bash
+
+  => sf probe 0
+  SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
+  => sf erase 0 0x10000
+  SF: 65536 bytes @ 0x0 Erased: OK
+  => sf erase 0x20000 0x10000
+  SF: 65536 bytes @ 0x20000 Erased: OK
+  => sf erase 0x30000 0x10000
+  SF: 65536 bytes @ 0x30000 Erased: OK
+  => sf erase 0x40000 0x10000
+  SF: 65536 bytes @ 0x40000 Erased: OK
+  => sf erase 0x50000 0x10000
+  SF: 65536 bytes @ 0x50000 Erased: OK
+  => sf erase 0x60000 0x10000
+  SF: 65536 bytes @ 0x60000 Erased: OK
+  => sf write 82000000 0 0x10000
+  SF: 65536 bytes @ 0x0 Written: OK
+  => sf write 83000000 0x20000 0x60000
+  SF: 393216 bytes @ 0x20000 Written: OK
+
+Next, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
+on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
+then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
+find a U-Boot image header at offset 0x20000 (set in the config file)
+and proceeds to load that image using the U-Boot image payload offset/size
+from the header. It will then start U-Boot.
diff --git a/doc/board/ti/index.rst b/doc/board/ti/index.rst
index 89d537d..b9cdf23 100644
--- a/doc/board/ti/index.rst
+++ b/doc/board/ti/index.rst
@@ -7,4 +7,7 @@
    :maxdepth: 2
 
    am335x_evm
+   am43xx_evm
+   dra7xx_evm
+   ks2_evm
    k3
diff --git a/doc/board/ti/ks2_evm.rst b/doc/board/ti/ks2_evm.rst
new file mode 100644
index 0000000..0a78903
--- /dev/null
+++ b/doc/board/ti/ks2_evm.rst
@@ -0,0 +1,306 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Neha Malcom Francis <n-francis@ti.com>
+
+Keystone II EVM Generation
+==========================
+
+Summary
+-------
+
+This README has information on the U-Boot port for K2HK, K2E, and K2L EVM boards.
+Documentation for this board can be found at:
+
+ - http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
+ - https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
+ - https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
+
+The K2HK board is based on Texas Instruments Keystone2 family of SoCs: K2H, K2K.
+More details on these SoCs are available at company websites:
+
+K2K: http://www.ti.com/product/tci6638k2k
+K2H: http://www.ti.com/product/tci6638k2h
+
+The K2E SoC details are available at
+ http://www.ti.com/lit/ds/symlink/66ak2e05.pdf
+
+The K2L SoC details are available at
+ http://www.ti.com/lit/ds/symlink/tci6630k2l.pdf
+
+The K2G SoC details are available at
+ http://www.ti.com/lit/ds/symlink/66ak2g02.pdf
+
+Board Configuration
+-------------------
+
+Some of the peripherals that are configured by U-Boot
+
+.. list-table::
+   :widths: 10 10 10 10 10 10 10 10
+   :header-rows: 1
+
+   * -
+     - DDR3
+     - NAND
+     - MSM SRAM
+     - ETH Ports
+     - UART
+     - I2C
+     - SPI
+   * - K2HK
+     - 2
+     - 512MB
+     - 6MB
+     - 4(2)
+     - 2
+     - 3
+     - 3
+   * - K2E
+     - 4
+     - 512MB
+     - 2MB
+     - 8(2)
+     - 2
+     - 3
+     - 3
+   * - K2L
+     - 2
+     - 512MB
+     - 2MB
+     - 4(2)
+     - 4
+     - 3
+     - 3
+   * - K2G
+     - 2
+     - 256MB
+     - 1MB
+     - 1
+     - 1
+     - 1
+     - 1
+
+There are only 2 eth port installed on the boards.
+
+There are separate PLLs to drive clocks to Tetris ARM and Peripherals.
+To bring up SMP Linux on this board, there is a boot monitor
+code that will be installed in MSMC SRAM. There is command available
+to install this image from U-Boot.
+
+The port related files can be found at following folders:
+ - keystone2 SoC related files: arch/arm/cpu/armv7/keystone/
+ - EVMs board files: board/ti/k2s_evm/
+
+Board configuration files:
+ - include/configs/k2hk_evm.h
+ - include/configs/k2e_evm.h
+ - include/configs/k2l_evm.h
+ - include/configs/k2g_evm.h
+
+As U-Boot is migrating to Kconfig there is also board defconfig files
+ - configs/k2e_evm_defconfig
+ - configs/k2hk_evm_defconfig
+ - configs/k2l_evm_defconfig
+ - configs/k2g_evm_defconfig
+
+Supported boot modes:
+ - SPI NOR boot
+ - AEMIF NAND boot (K2E, K2L and K2HK)
+ - UART boot
+ - MMC boot (Only on K2G)
+
+Supported image formats:
+ - u-boot.bin: for loading and running u-boot.bin through Texas Instruments Code
+   Composer Studio (CCS) and for UART boot.
+ - u-boot-spi.gph: gpimage for programming SPI NOR flash for SPI NOR boot
+ - MLO: gpimage for programming NAND flash for NAND boot, MMC boot.
+
+Build Instructions
+------------------
+
+Examples for k2hk, for k2e, k2l and k2g just replace k2hk prefix accordingly.
+Don't forget to add CROSS_COMPILE.
+
+To build u-boot.bin, u-boot-spi.gph, MLO:
+
+.. prompt:: bash
+   :prompts: $
+
+   make k2hk_evm_defconfig
+   make
+
+Load and Run U-Boot on Keystone EVMs using CCS
+----------------------------------------------
+
+Need Code Composer Studio (CCS) installed on a PC to load and run u-boot.bin
+on EVM? See instructions at below link for installing CCS on a Windows PC.
+
+        `<http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Getting_Started#Installing_Code_Composer_Studio>`_
+
+Use u-boot.bin from the build folder for loading and running U-Boot binary
+on EVM. Follow instructions at:
+
+ - K2HK http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup
+ - K2E  http://processors.wiki.ti.com/index.php/EVMK2E_Hardware_Setup
+ - K2L  http://processors.wiki.ti.com/index.php/TCIEVMK2L_Hardware_Setup
+ - K2G  http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup
+
+to configure SW1 dip switch to use "No Boot/JTAG DSP Little Endian Boot Mode"
+and Power ON the EVM.  Follow instructions to connect serial port of EVM to
+PC and start TeraTerm or Hyper Terminal.
+
+Start CCS on a Windows machine and Launch Target configuration as instructed at
+
+        `<http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Loading_and_Running_U-Boot_on_EVM_through_CCS>`_
+
+The instructions provided in the above link uses a script for
+loading the U-Boot binary on the target EVM. Instead do the following:-
+
+#. Right click to "Texas Instruments XDS2xx USB Emulator_0/CortexA15_1 core (D
+   is connected: Unknown)" at the debug window (This is created once Target
+   configuration is launched) and select "Connect Target".
+#. Once target connect is successful, choose Tools->Load Memory option from the
+   top level menu. At the Load Memory window, choose the file u-boot.bin
+   through "Browse" button and click "next >" button. In the next window, enter
+   Start address as 0xc000000, choose Type-size "32 bits" and click "Finish"
+   button.
+#. Click View -> Registers from the top level menu to view registers window.
+#. From Registers, window expand "Core Registers" to view PC. Edit PC value
+   to be 0xc000000. From the "Run" top level menu, select "Free Run"
+#. The U-Boot prompt is shown at the Tera Term/ Hyper terminal console as
+   below and type any key to stop autoboot as instructed.
+
+.. code-block:: bash
+
+  U-Boot 2014.04-rc1-00201-gc215b5a (Mar 21 2014 - 12:47:59)
+
+  I2C:   ready
+  Detected SO-DIMM [SQR-SD3T-2G1333SED]
+  DRAM:  1.1 GiB
+  NAND:  512 MiB
+  Net:   K2HK_EMAC
+  Warning: K2HK_EMAC using MAC address from net device
+  , K2HK_EMAC1, K2HK_EMAC2, K2HK_EMAC3
+  Hit any key to stop autoboot:  0
+
+SPI NOR Flash Programming Instructions
+--------------------------------------
+
+U-Boot image can be flashed to first 512KB of the NOR flash using following
+instructions:
+
+1. Start CCS and run U-Boot as described above.
+2. Suspend Target. Select Run -> Suspend from top level menu
+   CortexA15_1 (Free Running)"
+3. Load u-boot-spi.gph binary from build folder on to DDR address 0x87000000
+   through CCS as described in step 2 of "Load and Run U-Boot on K2HK/K2E/K2L
+   EVM using CCS", but using address 0x87000000.
+4. Free Run the target as described earlier (step 4) to get U-Boot prompt
+5. At the U-Boot console type following to setup U-Boot environment variables.
+
+.. prompt:: bash
+   :prompts: =>
+
+   setenv addr_uboot 0x87000000
+   setenv filesize <size in hex of u-boot-spi.gph rounded to hex 0x10000>
+   run burn_uboot_spi
+
+Once U-Boot prompt is available, power off the EVM. Set the SW1 dip switch to
+"SPI Little Endian Boot mode" as per instruction at
+
+        `<http://processors.wiki.ti.com/index.php/*_Hardware_Setup>`_
+
+6. Power ON the EVM. The EVM now boots with U-Boot image on the NOR flash.
+
+AEMIF NAND Flash programming instructions
+-----------------------------------------
+
+U-Boot image can be flashed to first 1024KB of the NAND flash using following
+instructions:
+
+1. Start CCS and run U-Boot as described above.
+2. Suspend Target. Select Run -> Suspend from top level menu
+   CortexA15_1 (Free Running)"
+3. Load MLO binary from build folder on to DDR address 0x87000000
+   through CCS as described in step 2 of "Load and Run U-Boot on K2HK EVM
+   using CCS", but using address 0x87000000.
+4. Free Run the target as described earlier (step 4) to get U-Boot prompt
+5. At the U-Boot console type following to setup U-Boot environment variables.
+
+.. prompt:: bash
+   :prompts: =>
+
+   setenv filesize <size in hex of MLO rounded to hex 0x10000>
+   run burn_uboot_nand
+
+Once U-Boot prompt is available, Power OFF the EVM. Set the SW1 dip switch to
+"ARM NAND Boot mode" as per instruction at
+
+        `<http://processors.wiki.ti.com/index.php/>`_
+
+under Hardware Setup
+
+6. Power ON the EVM. The EVM now boots with U-Boot image on the NAND flash.
+
+Load and Run U-Boot on keystone EVMs using UART download
+--------------------------------------------------------
+
+Open BMC and regular UART terminals.
+
+1. On the regular UART port start xmodem transfer of the u-boot.bin
+2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM
+
+.. prompt:: bash
+
+   BMC> bootmode #4
+   MBC> reboot
+
+3. When xmodem is complete you should see the U-Boot starts on the UART port
+
+Load and Run U-Boot on K2G EVMs using MMC
+-----------------------------------------
+
+Open BMC and regular UART terminals.
+
+1. Set the SW3 dip switch to "ARM MMC Boot mode" as per instruction at
+
+        `<http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup>`_
+
+2. Create SD card partitions as per steps given in Hardware Setup Guide.
+3. Copy MLO to Boot Partition.
+4. Insert SD card and Power on the EVM.
+   The EVM now boots with U-Boot image from SD card.
+
+Secure Boot
+-----------
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_config_ti_secure_device
+   :end-before: .. secure_boot_include_end_config_ti_secure_device
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_spl_boot
+   :end-before: .. secure_boot_include_end_spl_boot
+
+<IMAGE_FLAG> is currently ignored and reserved for future use.
+
+<INPUT_FILE> is the full path and filename of the public world boot
+loader binary file (only u-boot.bin is currently supported on
+Keystone2 devices, u-boot-spl.bin is not currently supported).
+
+<OUTPUT_FILE> is the full path and filename of the final secure image.
+The output binary images should be used in place of the standard
+non-secure binary images (see the platform-specific user's guides
+and releases notes for how the non-secure images are typically used)
+
+.. list-table::
+   :widths: 10 20
+   :header-rows: 0
+
+   * - u-boot_HS_MLO
+     - signed and encrypted boot image that can be used to
+       boot from all media. Secure boot from SPI NOR flash is not
+       currently supported.
+
+.. include:: am335x_evm.rst
+   :start-after: .. secure_boot_include_start_primary_u_boot
+   :end-before: .. secure_boot_include_end_primary_u_boot