summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorTom Rini <trini@ti.com>2013-09-06 20:25:35 -0400
committerTom Rini <trini@ti.com>2013-09-06 20:25:35 -0400
commit47f75cf2e1d8648e3438630f3a4bddf9b5caa25d (patch)
tree1d0f8f8943d44245381f255a059e258c696bc5a8 /doc
parent1affd4d4a3fe512050e1ad1636d9360c670da531 (diff)
parent68e1747f9c0506159e8ecc9a4feb58e9c65a7b39 (diff)
downloadu-boot-imx-47f75cf2e1d8648e3438630f3a4bddf9b5caa25d.zip
u-boot-imx-47f75cf2e1d8648e3438630f3a4bddf9b5caa25d.tar.gz
u-boot-imx-47f75cf2e1d8648e3438630f3a4bddf9b5caa25d.tar.bz2
Merge branch 'master' of git://git.denx.de/u-boot-arm
Diffstat (limited to 'doc')
-rw-r--r--doc/README.SPL2
-rw-r--r--doc/README.atmel_pmecc14
-rw-r--r--doc/README.imximage30
-rw-r--r--doc/README.mxc_hab48
-rw-r--r--doc/README.mxsimage165
5 files changed, 241 insertions, 18 deletions
diff --git a/doc/README.SPL b/doc/README.SPL
index ac9a213..312a6a6 100644
--- a/doc/README.SPL
+++ b/doc/README.SPL
@@ -67,7 +67,7 @@ CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o)
CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/nand_spl_load.o)
CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
-
+CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o)
Normally CPU is assumed to be the same between the SPL and normal
u-boot build. However it is possible to specify a different CPU for
diff --git a/doc/README.atmel_pmecc b/doc/README.atmel_pmecc
index b483744..41f3bd7 100644
--- a/doc/README.atmel_pmecc
+++ b/doc/README.atmel_pmecc
@@ -19,17 +19,6 @@ To use PMECC in this driver, the user needs to set:
It can be 2, 4, 8, 12 or 24.
2. The PMECC sector size: CONFIG_PMECC_SECTOR_SIZE.
It only can be 512 or 1024.
- 3. The PMECC index lookup table's offsets in ROM code: CONFIG_PMECC_INDEX_TABLE_OFFSET.
- In the chip datasheet section "Boot Stragegies", you can find
- two Galois Field Table in the ROM code. One table is for 512-bytes
- sector. Another is for 1024-byte sector. Each Galois Field includes
- two sub-table: indext table & alpha table.
- In the beginning of each Galois Field Table is the index table,
- Alpha table is in the following.
- So the index table's offset is same as the Galois Field Table.
-
- Please set CONFIG_PMECC_INDEX_TABLE_OFFSET correctly according the
- Galois Field Table's offset base on the sector size you used.
Take AT91SAM9X5EK as an example, the board definition file likes:
@@ -38,7 +27,4 @@ Take AT91SAM9X5EK as an example, the board definition file likes:
#define CONFIG_ATMEL_NAND_HW_PMECC 1
#define CONFIG_PMECC_CAP 2
#define CONFIG_PMECC_SECTOR_SIZE 512
-#define CONFIG_PMECC_INDEX_TABLE_OFFSET 0x8000
-NOTE: If you use 1024 as the sector size, then need set 0x10000 as the
- CONFIG_PMECC_INDEX_TABLE_OFFSET
diff --git a/doc/README.imximage b/doc/README.imximage
index 802eb90..dcda200 100644
--- a/doc/README.imximage
+++ b/doc/README.imximage
@@ -15,9 +15,6 @@ Booting from NOR flash does not require to use this image type.
For more details refer Chapter 2 - System Boot and section 2.14
(flash header description) of the processor's manual.
-This implementation does not use at the moment the secure boot feature
-of the processor. The image is generated disabling all security fields.
-
Command syntax:
--------------
./tools/mkimage -l <mx u-boot_file>
@@ -86,6 +83,33 @@ Configuration command line syntax:
Example:
BOOT_FROM spi
+ CSF value
+
+ Total size of CSF (Command Sequence File)
+ used for Secure Boot/ High Assurance Boot
+ (HAB).
+
+ Using this command will populate the IVT
+ (Initial Vector Table) CSF pointer and adjust
+ the length fields only. The CSF itself needs
+ to be generated with Freescale tools and
+ 'manually' appended to the u-boot.imx file.
+
+ The CSF is then simply concatenated
+ to the u-boot image, making a signed bootloader,
+ that the processor can verify
+ if the fuses for the keys are burned.
+
+ Further infos how to configure the SOC to verify
+ the bootloader can be found in the "High
+ Assurance Boot Version Application Programming
+ Interface Reference Manual" as part of the
+ Freescale Code Signing Tool, available on the
+ manufacturer's website.
+
+ Example:
+ CSF 0x2000
+
DATA type address value
type: word=4, halfword=2, byte=1
diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab
new file mode 100644
index 0000000..97f8b7d
--- /dev/null
+++ b/doc/README.mxc_hab
@@ -0,0 +1,48 @@
+High Assurance Boot (HAB) for i.MX6 CPUs
+
+To authenticate U-Boot only by the CPU there is no code required in
+U-Boot itself. However, 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 Initial Vector Table contains a pointer to the CSF. Please see
+doc/README.imximage for how to prepare u-boot.imx.
+
+The CSF itself is being generated by Freescale HAB tools.
+
+mkimage will output additional information about "HAB Blocks"
+which can be used in the Freescale tooling to authenticate U-Boot
+(entries in the CSF file).
+
+Image Type: Freescale IMX Boot Image
+Image Ver: 2 (i.MX53/6 compatible)
+Data Size: 327680 Bytes = 320.00 kB = 0.31 MB
+Load Address: 177ff420
+Entry Point: 17800000
+HAB Blocks: 177ff400 00000000 0004dc00
+ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
+ | | |
+ | | -------- (1)
+ | |
+ | ------------------- (2)
+ |
+ --------------------------- (3)
+
+(1) Size of area in file u-boot.imx to sign
+ This area should include the IVT, the Boot Data the DCD
+ and U-Boot itself.
+(2) Start of area in u-boot.imx to sign
+(3) Start of area in RAM to authenticate
+
+CONFIG_SECURE_BOOT currently enables only an additional command
+'hab_status' in U-Boot to retrieve the HAB status and events. This
+can be useful while developing and testing HAB.
+
+Commands to generate a signed U-Boot using Freescale HAB tools:
+cst --o U-Boot_CSF.bin < U-Boot.CSF
+objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 \
+ U-Boot_CSF.bin U-Boot_CSF_pad.bin
+cat u-boot.imx U-Boot_CSF_pad.bin > u-boot-signed.imx
+
+NOTE: U-Boot_CSF.bin needs to be padded to the value specified in
+the imximage.cfg file.
diff --git a/doc/README.mxsimage b/doc/README.mxsimage
new file mode 100644
index 0000000..88a2caf
--- /dev/null
+++ b/doc/README.mxsimage
@@ -0,0 +1,165 @@
+Freescale i.MX233/i.MX28 SB image generator via mkimage
+=======================================================
+
+This tool allows user to produce SB BootStream encrypted with a zero key.
+Such a BootStream is then bootable on i.MX23/i.MX28.
+
+Usage -- producing image:
+=========================
+The mxsimage tool is targeted to be a simple replacement for the elftosb2 .
+To generate an image, write an image configuration file and run:
+
+ mkimage -A arm -O u-boot -T mxsimage -n <path to configuration file> \
+ <output bootstream file>
+
+The output bootstream file is usually using the .sb file extension. Note
+that the example configuration files for producing bootable BootStream with
+the U-Boot bootloader can be found under arch/arm/boot/cpu/arm926ejs/mxs/
+directory. See the following files:
+
+ mxsimage.mx23.cfg -- This is an example configuration for i.MX23
+ mxsimage.mx28.cfg -- This is an example configuration for i.MX28
+
+Each configuration file uses very simple instruction semantics and a few
+additional rules have to be followed so that a useful image can be produced.
+These semantics and rules will be outlined now.
+
+- Each line of the configuration file contains exactly one instruction.
+- Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 .
+- The configuration file is a concatenation of blocks called "sections" and
+ optionally "DCD blocks" (see below).
+ - Each "section" is started by the "SECTION" instruction.
+ - The "SECTION" instruction has the following semantics:
+
+ SECTION u32_section_number [BOOTABLE]
+ - u32_section_number :: User-selected ID of the section
+ - BOOTABLE :: Sets the section as bootable
+
+ - A bootable section is one from which the BootROM starts executing
+ subsequent instructions or code. Exactly one section must be selected
+ as bootable, usually the one containing the instructions and data to
+ load the bootloader.
+
+ - A "SECTION" must be immediatelly followed by a "TAG" instruction.
+ - The "TAG" instruction has the following semantics:
+
+ TAG [LAST]
+ - LAST :: Flag denoting the last section in the file
+
+ - After a "TAG" unstruction, any of the following instructions may follow
+ in any order and any quantity:
+
+ NOOP
+ - This instruction does nothing
+
+ LOAD u32_address string_filename
+ - Instructs the BootROM to load file pointed by "string_filename" onto
+ address "u32_address".
+
+ LOAD IVT u32_address u32_IVT_entry_point
+ - Crafts and loads IVT onto address "u32_address" with the entry point
+ of u32_IVT_entry_point.
+ - i.MX28-specific instruction!
+
+ LOAD DCD u32_address u32_DCD_block_ID
+ - Loads the DCD block with ID "u32_DCD_block_ID" onto address
+ "u32_address" and executes the contents of this DCD block
+ - i.MX28-specific instruction!
+
+ FILL u32_address u32_pattern u32_length
+ - Starts to write memory from addres "u32_address" with a pattern
+ specified by "u32_pattern". Writes exactly "u32_length" bytes of the
+ pattern.
+
+ JUMP [HAB] u32_address [u32_r0_arg]
+ - Jumps onto memory address specified by "u32_address" by setting this
+ address in PT. The BootROM will pass the "u32_r0_arg" value in ARM
+ register "r0" to the executed code if this option is specified.
+ Otherwise, ARM register "r0" will default to value 0x00000000. The
+ optional "HAB" flag is i.MX28-specific flag turning on the HAB boot.
+
+ CALL [HAB] u32_address [u32_r0_arg]
+ - See JUMP instruction above, as the operation is exactly the same with
+ one difference. The CALL instruction does allow returning into the
+ BootROM from the executed code. U-Boot makes use of this in it's SPL
+ code.
+
+ MODE string_mode
+ - Restart the CPU and start booting from device specified by the
+ "string_mode" argument. The "string_mode" differs for each CPU
+ and can be:
+ i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH
+ JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1
+ i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH
+ JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1
+
+ - An optional "DCD" blocks can be added at the begining of the configuration
+ file. Note that the DCD is only supported on i.MX28.
+ - The DCD blocks must be inserted before the first "section" in the
+ configuration file.
+ - The DCD block has the following semantics:
+
+ DCD u32_DCD_block_ID
+ - u32_DCD_block_ID :: The ID number of the DCD block, must match
+ the ID number used by "LOAD DCD" instruction.
+
+ - The DCD block must be followed by one of the following instructions. All
+ of the instructions operate either on 1, 2 or 4 bytes. This is selected by
+ the 'n' suffix of the instruction:
+
+ WRITE.n u32_address u32_value
+ - Write the "u32_value" to the "u32_address" address.
+
+ ORR.n u32_address u32_value
+ - Read the "u32_address", perform a bitwise-OR with the "u32_value" and
+ write the result back to "u32_address".
+
+ ANDC.n u32_address u32_value
+ - Read the "u32_address", perform a bitwise-AND with the complement of
+ "u32_value" and write the result back to "u32_address".
+
+ EQZ.n u32_address u32_count
+ - Read the "u32_address" at most "u32_count" times and test if the value
+ read is zero. If it is, break the loop earlier.
+
+ NEZ.n u32_address u32_count
+ - Read the "u32_address" at most "u32_count" times and test if the value
+ read is non-zero. If it is, break the loop earlier.
+
+ EQ.n u32_address u32_mask
+ - Read the "u32_address" in a loop and test if the result masked with
+ "u32_mask" equals the "u32_mask". If the values are equal, break the
+ reading loop.
+
+ NEQ.n u32_address u32_mask
+ - Read the "u32_address" in a loop and test if the result masked with
+ "u32_mask" does not equal the "u32_mask". If the values are not equal,
+ break the reading loop.
+
+ NOOP
+ - This instruction does nothing.
+
+- If the verbose output from the BootROM is enabled, the BootROM will produce a
+ letter on the Debug UART for each instruction it started processing. Here is a
+ mapping between the above instructions and the BootROM verbose output:
+
+ H -- SB Image header loaded
+ T -- TAG instruction
+ N -- NOOP instruction
+ L -- LOAD instruction
+ F -- FILL instruction
+ J -- JUMP instruction
+ C -- CALL instruction
+ M -- MODE instruction
+
+Usage -- verifying image:
+=========================
+
+The mxsimage can also verify and dump contents of an image. Use the following
+syntax to verify and dump contents of an image:
+
+ mkimage -l <input bootstream file>
+
+This will output all the information from the SB image header and all the
+instructions contained in the SB image. It will also check if the various
+checksums in the SB image are correct.