diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.SPL | 2 | ||||
| -rw-r--r-- | doc/README.TPL | 45 | ||||
| -rw-r--r-- | doc/README.atmel_pmecc | 14 | ||||
| -rw-r--r-- | doc/README.fdt-control | 3 | ||||
| -rw-r--r-- | doc/README.imximage | 30 | ||||
| -rw-r--r-- | doc/README.mpc85xx-sd-spi-boot | 81 | ||||
| -rw-r--r-- | doc/README.mxc_hab | 48 | ||||
| -rw-r--r-- | doc/README.mxsimage | 165 | ||||
| -rw-r--r-- | doc/README.scrapyard | 7 |
9 files changed, 372 insertions, 23 deletions
diff --git a/doc/README.SPL b/doc/README.SPL index ac9a2137c..312a6a612 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.TPL b/doc/README.TPL new file mode 100644 index 000000000..1df03b958 --- /dev/null +++ b/doc/README.TPL @@ -0,0 +1,45 @@ +Generic TPL framework +===================== + +Overview +-------- + +TPL---Third Program Loader. + +Due to the SPL on some boards(powerpc mpc85xx) has a size limit and cannot +be compatible with all the external device(e.g. DDR). So add a tertiary +program loader (TPL) to enable a loader stub loaded by the code from the +SPL. It loads the final uboot image into DDR, then jump to it to begin +execution. Now, only the powerpc mpc85xx has this requirement and will +implemente it. + +Keep consistent with SPL, with this framework almost all source files for a +board can be reused. No code duplication or symlinking is necessary anymore. + +How it works +------------ + +There has been a directory TOPDIR/spl which contains only a Makefile. The +Makefile is shared by SPL and TPL. + +The object files are built separately for SPL/TPL and placed in the +directory spl/tpl. The final binaries which are generated are +u-boot-{spl|tpl}, u-boot-{spl|tpl}.bin and u-boot-{spl|tpl}.map. + +During the TPL build a variable named CONFIG_TPL_BUILD is exported in the +make environment and also appended to CPPFLAGS with -DCONFIG_TPL_BUILD. + +The SPL options are shared by SPL and TPL, the board config file should +determine which SPL options to choose based on whether CONFIG_TPL_BUILD +is set. Source files can be compiled for TPL with options choosed in the +board config file. + +For example: + +spl/Makefile: +LIBS-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/libcommon.o + +CONFIG_SPL_LIBCOMMON_SUPPORT is defined in board config file: +#ifdef CONFIG_TPL_BUILD +#define CONFIG_SPL_LIBCOMMON_SUPPORT +#endif diff --git a/doc/README.atmel_pmecc b/doc/README.atmel_pmecc index b483744ea..41f3bd786 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.fdt-control b/doc/README.fdt-control index 4b290609f..86bae6816 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -119,8 +119,7 @@ file into board/<vendor>/dts/<name>.dts This should include your CPU or SOC's device tree file, placed in -arch/<arch>/dts, and then make any adjustments required. The name of this -is CONFIG_ARCH_DEVICE_TREE.dts. +arch/<arch>/dts, and then make any adjustments required. If CONFIG_OF_EMBED is defined, then it will be picked up and built into the U-Boot image (including u-boot.bin). diff --git a/doc/README.imximage b/doc/README.imximage index 802eb90f1..dcda2005a 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.mpc85xx-sd-spi-boot b/doc/README.mpc85xx-sd-spi-boot new file mode 100644 index 000000000..d5043ccb6 --- /dev/null +++ b/doc/README.mpc85xx-sd-spi-boot @@ -0,0 +1,81 @@ +---------------------------------------- +Booting from On-Chip ROM (eSDHC or eSPI) +---------------------------------------- + +boot_format is a tool to write SD bootable images to a filesystem and build +SD/SPI images to a binary file for writing later. + +When booting from an SD card/MMC, boot_format puts the configuration file and +the RAM-based U-Boot image on the card. +When booting from an EEPROM, boot_format generates a binary image that is used +to boot from this EEPROM. + +Where to get boot_format: +======================== + +you can browse it online at: +http://git.freescale.com/git/cgit.cgi/ppc/sdk/boot-format.git/ + +Building +======== + +Run the following to build this project + + $ make + +Execution +========= + +boot_format runs under a regular Linux machine and requires a super user mode +to run. Execute boot_format as follows. + +For building SD images by writing directly to a file system on SD media: + + $ boot_format $config u-boot.bin -sd $device + +Where $config is the included config.dat file for your platform and $device +is the target block device for the SD media on your computer. + +For build binary images directly a local file: + + $ boot_format $config u-boot.bin -spi $file + +Where $file is the target file. Also keep in mind the u-boot.bin file needs +to be the u-boot built for your particular platform and target media. + +Example: To generate a u-boot.bin for a P1022DS booting from SD, run the +following in the u-boot repository: + + $ make P1022DS_SDCARD + +Configuration Files +=================== + +Below are the configuration files to be used with a particular platform. Keep +in mind that some of these config files are tied to the platforms DDR speed. +Please see the SoC reference manual for more documentation. + +P1022DS config_sram_p1022ds.dat +P2020DS config_sram_p2020ds.dat +P2010DS config_sram_p2020ds.dat +P1020RDB config_ddr2_1g_p1020rdb_533M.dat +P1020RDB config_ddr2_1g_p1020rdb_667M.dat +P2020RDB config_ddr2_1g_p2020rdb_800M.dat +P2020RDB config_ddr2_1g_p2020rdb_667M.dat +P2020RDB config_ddr3_1gb_64bit_p2020rdb_pc.dat +P2010RDB config_ddr3_1gb_64bit_p2020rdb_pc.dat +P1020RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat +P1011RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat +P1010RDB config_ddr3_1gb_p1010rdb_800M.dat +P1014RDB config_ddr3_1gb_p1014rdb_800M.dat +P1021RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat +P1012RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat +P1022DS config_ddr3_2gb_p1022ds.dat +P1013DS config_ddr3_2gb_p1022ds.dat +P1024RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat +P1013RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat +P1025RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat +P1016RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat +P1020UTM config_ddr3_1gb_p1_p2_rdb_pc_800M.dat +P1020MBG config_ddr3_1gb_p1_p2_rdb_pc_800M.dat +MPC8536DS config_ddr2_512m_mpc8536ds_667M.dat diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab new file mode 100644 index 000000000..97f8b7d74 --- /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 000000000..88a2caf3e --- /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. diff --git a/doc/README.scrapyard b/doc/README.scrapyard index a0f1fa30f..87b1dfecd 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -11,9 +11,10 @@ easily if here is something they might want to dig for... Board Arch CPU Commit Removed Last known maintainer/contact ================================================================================================= -Alaska8220 powerpc mpc8220 - - -Yukon8220 powerpc mpc8220 - - -sorcery powerpc mpc8220 - - +CANBT powerpc 405CR - - Matthias Fuchs <matthias.fuchs@esd.eu> +Alaska8220 powerpc mpc8220 d6ed322 2013-05-11 +Yukon8220 powerpc mpc8220 d6ed322 2013-05-11 +sorcery powerpc mpc8220 d6ed322 2013-05-11 smdk6400 arm arm1176 52587f1 2013-04-12 Zhong Hongbo <bocui107@gmail.com> ns9750dev arm arm926ejs 4cfc611 2013-02-28 Markus Pietrek <mpietrek@fsforth.de> AMX860 powerpc mpc860 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de> |