summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/README.fdt-control6
-rw-r--r--doc/README.generic-board69
-rw-r--r--doc/README.ti-secure91
3 files changed, 98 insertions, 68 deletions
diff --git a/doc/README.fdt-control b/doc/README.fdt-control
index 29fd56a..2913fcb 100644
--- a/doc/README.fdt-control
+++ b/doc/README.fdt-control
@@ -33,12 +33,6 @@ the features of each board in the device tree file, and have a single
generic source base.
To enable this feature, add CONFIG_OF_CONTROL to your board config file.
-It is currently supported on ARM, x86 and Microblaze - other architectures
-will need to add code to their arch/xxx/lib/board.c file to locate the
-FDT. Alternatively you can enable generic board support on your board
-(with CONFIG_SYS_GENERIC_BOARD) if this is available (as it is for
-PowerPC). For ARM, Tegra and Exynos5 have device trees available for
-common devices.
What is a Flat Device Tree?
diff --git a/doc/README.generic-board b/doc/README.generic-board
index 734f1aa..6858c4d 100644
--- a/doc/README.generic-board
+++ b/doc/README.generic-board
@@ -5,29 +5,22 @@
# SPDX-License-Identifier: GPL-2.0+
#
-DEPRECATION NOTICE FOR arch/<arch>/lib/board.c
-
-For board maintainers: Please submit patches for boards you maintain before
-July 2014, to make them use generic board.
-
-For architecture maintainers: Please submit patches to remove your
-architecture-specific board.c file before October 2014.
-
-
Background
----------
-U-Boot has traditionally had a board.c file for each architecture. This has
-introduced quite a lot of duplication, with each architecture tending to do
+U-Boot traditionally had a board.c file for each architecture. This introduced
+quite a lot of duplication, with each architecture tending to do
initialisation slightly differently. To address this, a new 'generic board
-init' feature was introduced a year ago in March 2013 (further motivation is
+init' feature was introduced in March 2013 (further motivation is
provided in the cover letter below).
+All boards and architectures have moved to this as of mid 2016.
+
What has changed?
-----------------
-The main change is that the arch/<arch>/lib/board.c file is being removed in
+The main change is that the arch/<arch>/lib/board.c file is removed in
favour of common/board_f.c (for pre-relocation init) and common/board_r.c
(for post-relocation init).
@@ -36,55 +29,6 @@ fields which are common to all architectures. Architecture-specific fields
have been moved to separate structures.
-Supported Architectures
-------------------------
-
-If you are unlucky then your architecture may not support generic board.
-The following architectures are supported now:
-
- arc
- arm
- avr32
- blackfin
- m68k
- microblaze
- mips
- nios2
- powerpc
- sandbox
- x86
-
-If your architecture is not supported, you need to select
-HAVE_GENERIC_BOARD in arch/Kconfig
-and test it with a suitable board, as follows.
-
-
-Adding Support for your Board
------------------------------
-
-To enable generic board for your board, define CONFIG_SYS_GENERIC_BOARD in
-your board config header file.
-
-Test that U-Boot still functions correctly on your board, and fix any
-problems you find. Don't be surprised if there are no problems - generic
-board has had a reasonable amount of testing with common boards.
-
-
-DeadLine
---------
-
-Please don't take this the wrong way - there is no intent to make your life
-miserable, and we have the greatest respect and admiration for U-Boot users.
-However, with any migration there has to be a period where the old way is
-deprecated and removed. Every patch to the deprecated code introduces a
-potential breakage in the new unused code. Therefore:
-
-Boards or architectures not converted over to general board by the
-end of 2014 may be forcibly changed over (potentially causing run-time
-breakage) or removed.
-
-
-
Further Background
------------------
@@ -190,3 +134,4 @@ convenience.
Simon Glass, sjg@chromium.org
March 2014
+Updated after final removal, May 2016
diff --git a/doc/README.ti-secure b/doc/README.ti-secure
new file mode 100644
index 0000000..7fc9b9b
--- /dev/null
+++ b/doc/README.ti-secure
@@ -0,0 +1,91 @@
+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.
+
+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 secure TI devices.
+
+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 loader
+binary 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>
+
+<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
+ Note: ULO is not yet used by the u-boot build process
+
+<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_X-LOADER - boot image for all other flash memories
+ including QSPI and NOR flash