From b2d96dc28ffb2acad250ffb551a442396db83f38 Mon Sep 17 00:00:00 2001 From: "Wu, Josh" Date: Wed, 3 Jul 2013 11:11:45 +0800 Subject: ARM: at91: atmel_nand: pmecc driver will select the galois table by sector size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Define the galois index table offset in chip head file. So user do not need to set by himself. Driver will set it correctly according to sector_size. Signed-off-by: Josh Wu Acked-by: Scott Wood [rebased on master] Signed-off-by: Andreas Bießmann --- doc/README.atmel_pmecc | 14 -------------- 1 file changed, 14 deletions(-) (limited to 'doc') diff --git a/doc/README.atmel_pmecc b/doc/README.atmel_pmecc index b483744ea5..41f3bd7860 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 -- cgit v1.2.1 From a09f96498bb2a31bb78388b5f094dc0e9295f86e Mon Sep 17 00:00:00 2001 From: Heiko Schocher Date: Mon, 19 Aug 2013 16:38:58 +0200 Subject: arm, spl: add watchdog library to SPL Signed-off-by: Heiko Schocher Cc: Tom Rini --- doc/README.SPL | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/README.SPL b/doc/README.SPL index ac9a2137c8..312a6a612e 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 -- cgit v1.2.1 From 0187c985aa870a74caeecd3bd10244322b7e4d99 Mon Sep 17 00:00:00 2001 From: Stefano Babic Date: Thu, 27 Jun 2013 11:42:38 +0200 Subject: tools: add support for setting the CSF into imximage Add support for setting the CSF (Command Sequence File) pointer which is used for HAB (High Assurance Boot) in the imximage by adding e.g. CSF 0x2000 in the imximage.cfg file. This will set the CSF pointer accordingly just after the padded data image area. The boot_data.length is adjusted with the value from the imximage.cfg config file. The resulting u-boot.imx can be signed with the FSL HAB tooling. The generated CSF block needs to be appended to the u-boot.imx. Signed-off-by: Stefano Babic --- doc/README.imximage | 30 +++++++++++++++++++++++++++--- doc/README.mxc_hab | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 3 deletions(-) create mode 100644 doc/README.mxc_hab (limited to 'doc') diff --git a/doc/README.imximage b/doc/README.imximage index 802eb90f1d..dcda2005af 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 @@ -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 0000000000..97f8b7d743 --- /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. -- cgit v1.2.1 From bce8837071617a13f8e28f60400ee826b3f8a308 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 26 Aug 2013 20:43:33 +0200 Subject: ARM: mxs: tools: Add mkimage support for MXS bootstream Add mkimage support for generating and verifying MXS bootstream. The implementation here is mostly a glue code between MXSSB v0.4 and mkimage, but the long-term goal is to rectify this and merge MXSSB with mkimage more tightly. Once this code is properly in U-Boot, MXSSB shall be deprecated in favor of mkimage-mxsimage support. Note that the mxsimage generator needs libcrypto from OpenSSL, I therefore enabled the libcrypto/libssl unconditionally. MXSSB: http://git.denx.de/?p=mxssb.git;a=summary The code is based on research presented at: http://www.rockbox.org/wiki/SbFileFormat Signed-off-by: Marek Vasut Cc: Tom Rini Cc: Fabio Estevam Cc: Stefano Babic Cc: Otavio Salvador --- doc/README.mxsimage | 165 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 165 insertions(+) create mode 100644 doc/README.mxsimage (limited to 'doc') diff --git a/doc/README.mxsimage b/doc/README.mxsimage new file mode 100644 index 0000000000..88a2caf3e6 --- /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 \ + + +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 + +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. -- cgit v1.2.1