Eric Lee / smarc-uboot | Embedian Git Server

Commit 57310be619b009bd7df804702d1bad724bc87430

Authored by Breno Lima 2018-09-21 05:01:43 +0800

Committed by Ye Li 2018-10-09 14:06:36 +0800

Exists in smarc_8mm-imx_v2018.03_4.14.98_2.0.0_ga and in 5 other branches

MLK-19722-4 doc: imx: mkimage: reorganize i.MX mkimage documentation

The following documents describe the image type used by the mkimage
tool to generate U-Boot images for i.MX devices.

- README.imximage
- README.mxsimage

Move all mkimage related document to doc/imx/mkimage for a better
directory structure.

Signed-off-by: Breno Lima <breno.lima@nxp.com>

Showing 4 changed files with 409 additions and 409 deletions Side-by-side Diff

doc/imx/README.imximage
doc/imx/README.mxsimage
doc/imx/mkimage/README.imximage
doc/imx/mkimage/README.mxsimage

doc/imx/README.imximage

View file @ 57310be

1		----------------------------------------------
2		-Imximage Boot Image generation using mkimage
3		----------------------------------------------
4		-
5		-This document describes how to set up a U-Boot image that can be booted
6		-by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot
7		-mode.
8		-
9		-These processors can boot directly from NAND, SPI flash and SD card flash
10		-using its internal boot ROM support. MX6 processors additionally support
11		-boot from NOR flash and SATA disks. All processors can boot from an internal
12		-UART, if booting from device media fails.
13		-Booting from NOR flash does not require to use this image type.
14		-
15		-For more details refer Chapter 2 - System Boot and section 2.14
16		-(flash header description) of the processor's manual.
17		-
18		-Command syntax:
19		---------------
20		-./tools/mkimage -l <mx u-boot_file>
21		- to list the imx image file details
22		-
23		-./tools/mkimage -T imximage \
24		- -n <board specific configuration file> \
25		- -e <execution address> -d <u-boot binary> <output image file>
26		-
27		-For example, for the mx51evk board:
28		-./tools/mkimage -n ./board/freescale/mx51evk/imximage.cfg \
29		- -T imximage -e 0x97800000 \
30		- -d u-boot.bin u-boot.imx
31		-
32		-You can generate directly the image when you compile u-boot with:
33		-
34		-$ make u-boot.imx
35		-
36		-The output image can be flashed on the board SPI flash or on a SD card.
37		-In both cases, you have to copy the image at the offset required for the
38		-chosen media devices (0x400 for both SPI flash or SD card).
39		-
40		-Please check Freescale documentation for further details.
41		-
42		-Board specific configuration file specifications:
43		--------------------------------------------------
44		-1. This file must present in the $(BOARDDIR) and the name should be
45		- imximage.cfg (since this is used in Makefile).
46		-2. This file can have empty lines and lines starting with "#" as first
47		- character to put comments.
48		-3. This file can have configuration command lines as mentioned below,
49		- any other information in this file is treated as invalid.
50		-
51		-Configuration command line syntax:
52		----------------------------------
53		-1. Each command line is must have two strings, first one command or address
54		- and second one data string
55		-2. Following are the valid command strings and associated data strings:-
56		- Command string data string
57		- -------------- -----------
58		- IMXIMAGE_VERSION 1/2
59		- 1 is for mx25/mx35/mx51 compatible,
60		- 2 is for mx53/mx6 compatible,
61		- others is invalid and error is generated.
62		- This command need appear the fist before
63		- other valid commands in configuration file.
64		-
65		- BOOT_OFFSET value
66		-
67		- This command is parallel to BOOT_FROM and
68		- is preferred over BOOT_FROM.
69		-
70		- value: Offset of the image header, this
71		- value shall be set to one of the
72		- values found in the file:
73		- arch/arm/include/asm/\
74		- mach-imx/imximage.cfg
75		- Example:
76		- BOOT_OFFSET FLASH_OFFSET_STANDARD
77		-
78		- BOOT_FROM nand/spi/sd/onenand/nor/sata
79		-
80		- This command is parallel to BOOT_OFFSET and
81		- is to be deprecated in favor of BOOT_OFFSET.
82		-
83		- Example:
84		- BOOT_FROM spi
85		-
86		- CSF value
87		-
88		- Total size of CSF (Command Sequence File)
89		- used for Secure Boot/ High Assurance Boot
90		- (HAB).
91		-
92		- Using this command will populate the IVT
93		- (Initial Vector Table) CSF pointer and adjust
94		- the length fields only. The CSF itself needs
95		- to be generated with Freescale tools and
96		- 'manually' appended to the u-boot.imx file.
97		-
98		- The CSF is then simply concatenated
99		- to the u-boot image, making a signed bootloader,
100		- that the processor can verify
101		- if the fuses for the keys are burned.
102		-
103		- Further infos how to configure the SOC to verify
104		- the bootloader can be found in the "High
105		- Assurance Boot Version Application Programming
106		- Interface Reference Manual" as part of the
107		- Freescale Code Signing Tool, available on the
108		- manufacturer's website.
109		-
110		- Example:
111		- CSF 0x2000
112		-
113		- DATA type address value
114		-
115		- type: word=4, halfword=2, byte=1
116		- address: physycal register address
117		- value: value to be set in register
118		- All values are in in hexadecimal.
119		- Example (write to IOMUXC):
120		- DATA 4 0x73FA88a0 0x200
121		-
122		-The processor support up to 60 register programming commands for IMXIMAGE_VERSION 1
123		-and 220 register programming commands for IMXIMAGE_VERSION 2.
124		-An error is generated if more commands are found in the configuration file.
125		-
126		-3. All commands are optional to program.
127		-
128		-Setup a SD Card for booting
129		---------------------------------
130		-
131		-The following example prepare a SD card with u-boot and a FAT partition
132		-to be used to stored the kernel to be booted.
133		-I will set the SD in the most compatible mode, setting it with
134		-255 heads and 63 sectors, as suggested from several documentation and
135		-howto on line (I took as reference the preparation of a SD Card for the
136		-Beagleboard, running u-boot as bootloader).
137		-
138		-You should start clearing the partitions table on the SD card. Because
139		-the u-boot image must be stored at the offset 0x400, it must be assured
140		-that there is no partition at that address. A new SD card is already
141		-formatted with FAT filesystem and the partition starts from the first
142		-cylinder, so we need to change it.
143		-
144		-You can do all steps with fdisk. If the device for the SD card is
145		-/dev/mmcblk0, the following commands make the job:
146		-
147		-1. Start the fdisk utility (as superuser)
148		- fdisk /dev/mmcblk0
149		-
150		-2. Clear the actual partition
151		-
152		-Command (m for help): o
153		-
154		-3. Print card info:
155		-
156		-Command (m for help): p
157		-Disk /dev/mmcblk0: 1981 MB, 1981284352 bytes
158		-
159		-In my case, I have a 2 GB card. I need the size to set later the correct value
160		-for the cylinders.
161		-
162		-4. Go to expert mode:
163		-
164		-Command (m for help): x
165		-
166		-5. Set card geometry
167		-
168		-Expert command (m for help): h
169		-Number of heads (1-256, default 4): 255
170		-
171		-Expert command (m for help): s
172		-Number of sectors (1-63, default 16): 63
173		-Warning: setting sector offset for DOS compatiblity
174		-
175		-We have set 255 heads, 63 sector. We have to set the cylinder.
176		-The value to be set can be calculated with:
177		-
178		- cilynder = <total size> / <heads> / <sectors> / <blocksize>
179		-
180		-in this example,
181		- 1981284352 / 255 / 63 / 512 = 239.x = 239
182		-
183		-
184		-Expert command (m for help): c
185		-Number of cylinders (1-1048576, default 60032): 239
186		-
187		-6. Leave the expert mode
188		-Expert command (m for help): r
189		-
190		-7. Set up a partition
191		-
192		-Now set a partition table to store the kernel or whatever you want. Of course,
193		-you can set additional partitions to store rootfs, data, etc.
194		-In my example I want to set a single partition. I must take care
195		-to not overwrite the space where I will put u-boot.
196		-
197		-Command (m for help): n
198		-Command action
199		- e extended
200		- p primary partition (1-4)
201		-p
202		-Partition number (1-4): 1
203		-First cylinder (1-239, default 1): 3
204		-Last cylinder, +cylinders or +size{K,M,G} (3-239, default 239): +100M
205		-
206		-Command (m for help): p
207		-
208		-Disk /dev/mmcblk0: 1967 MB, 1967128576 bytes
209		-255 heads, 63 sectors/track, 239 cylinders
210		-Units = cylinders of 16065 * 512 = 8225280 bytes
211		-Disk identifier: 0xb712a870
212		-
213		- Device Boot Start End Blocks Id System
214		-/dev/mmcblk0p1 3 16 112455 83 Linux
215		-
216		-I have set 100MB, leaving the first 2 sectors free. I will copy u-boot
217		-there.
218		-
219		-8. Write the partition table and exit.
220		-
221		-Command (m for help): w
222		-The partition table has been altered!
223		-
224		-Calling ioctl() to re-read partition table.
225		-
226		-9. Copy u-boot.imx on the SD card
227		-
228		-I use dd:
229		-
230		-dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2
231		-
232		-This command copies the u-boot image at the address 0x400, as required
233		-by the processor.
234		-
235		-Now remove your card from the PC and go to the target. If evrything went right,
236		-the u-boot prompt should come after power on.
237		-
238		-------------------------------------------------
239		-Author: Stefano babic <sbabic@denx.de>

doc/imx/README.mxsimage

View file @ 57310be

1		-Freescale i.MX233/i.MX28 SB image generator via mkimage
2		-=======================================================
3		-
4		-This tool allows user to produce SB BootStream encrypted with a zero key.
5		-Such a BootStream is then bootable on i.MX23/i.MX28.
6		-
7		-Usage -- producing image:
8		-=========================
9		-The mxsimage tool is targeted to be a simple replacement for the elftosb2 .
10		-To generate an image, write an image configuration file and run:
11		-
12		- mkimage -A arm -O u-boot -T mxsimage -n <path to configuration file> \
13		- <output bootstream file>
14		-
15		-The output bootstream file is usually using the .sb file extension. Note
16		-that the example configuration files for producing bootable BootStream with
17		-the U-Boot bootloader can be found under arch/arm/boot/cpu/arm926ejs/mxs/
18		-directory. See the following files:
19		-
20		- mxsimage.mx23.cfg -- This is an example configuration for i.MX23
21		- mxsimage.mx28.cfg -- This is an example configuration for i.MX28
22		-
23		-Each configuration file uses very simple instruction semantics and a few
24		-additional rules have to be followed so that a useful image can be produced.
25		-These semantics and rules will be outlined now.
26		-
27		-- Each line of the configuration file contains exactly one instruction.
28		-- Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 .
29		-- The configuration file is a concatenation of blocks called "sections" and
30		- optionally "DCD blocks" (see below), and optional flags lines.
31		- - Each "section" is started by the "SECTION" instruction.
32		- - The "SECTION" instruction has the following semantics:
33		-
34		- SECTION u32_section_number [BOOTABLE]
35		- - u32_section_number :: User-selected ID of the section
36		- - BOOTABLE :: Sets the section as bootable
37		-
38		- - A bootable section is one from which the BootROM starts executing
39		- subsequent instructions or code. Exactly one section must be selected
40		- as bootable, usually the one containing the instructions and data to
41		- load the bootloader.
42		-
43		- - A "SECTION" must be immediatelly followed by a "TAG" instruction.
44		- - The "TAG" instruction has the following semantics:
45		-
46		- TAG [LAST]
47		- - LAST :: Flag denoting the last section in the file
48		-
49		- - After a "TAG" unstruction, any of the following instructions may follow
50		- in any order and any quantity:
51		-
52		- NOOP
53		- - This instruction does nothing
54		-
55		- LOAD u32_address string_filename
56		- - Instructs the BootROM to load file pointed by "string_filename" onto
57		- address "u32_address".
58		-
59		- LOAD IVT u32_address u32_IVT_entry_point
60		- - Crafts and loads IVT onto address "u32_address" with the entry point
61		- of u32_IVT_entry_point.
62		- - i.MX28-specific instruction!
63		-
64		- LOAD DCD u32_address u32_DCD_block_ID
65		- - Loads the DCD block with ID "u32_DCD_block_ID" onto address
66		- "u32_address" and executes the contents of this DCD block
67		- - i.MX28-specific instruction!
68		-
69		- FILL u32_address u32_pattern u32_length
70		- - Starts to write memory from addres "u32_address" with a pattern
71		- specified by "u32_pattern". Writes exactly "u32_length" bytes of the
72		- pattern.
73		-
74		- JUMP [HAB] u32_address [u32_r0_arg]
75		- - Jumps onto memory address specified by "u32_address" by setting this
76		- address in PT. The BootROM will pass the "u32_r0_arg" value in ARM
77		- register "r0" to the executed code if this option is specified.
78		- Otherwise, ARM register "r0" will default to value 0x00000000. The
79		- optional "HAB" flag is i.MX28-specific flag turning on the HAB boot.
80		-
81		- CALL [HAB] u32_address [u32_r0_arg]
82		- - See JUMP instruction above, as the operation is exactly the same with
83		- one difference. The CALL instruction does allow returning into the
84		- BootROM from the executed code. U-Boot makes use of this in it's SPL
85		- code.
86		-
87		- MODE string_mode
88		- - Restart the CPU and start booting from device specified by the
89		- "string_mode" argument. The "string_mode" differs for each CPU
90		- and can be:
91		- i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH
92		- JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1
93		- i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH
94		- JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1
95		-
96		- - An optional "DCD" blocks can be added at the begining of the configuration
97		- file. Note that the DCD is only supported on i.MX28.
98		- - The DCD blocks must be inserted before the first "section" in the
99		- configuration file.
100		- - The DCD block has the following semantics:
101		-
102		- DCD u32_DCD_block_ID
103		- - u32_DCD_block_ID :: The ID number of the DCD block, must match
104		- the ID number used by "LOAD DCD" instruction.
105		-
106		- - The DCD block must be followed by one of the following instructions. All
107		- of the instructions operate either on 1, 2 or 4 bytes. This is selected by
108		- the 'n' suffix of the instruction:
109		-
110		- WRITE.n u32_address u32_value
111		- - Write the "u32_value" to the "u32_address" address.
112		-
113		- ORR.n u32_address u32_value
114		- - Read the "u32_address", perform a bitwise-OR with the "u32_value" and
115		- write the result back to "u32_address".
116		-
117		- ANDC.n u32_address u32_value
118		- - Read the "u32_address", perform a bitwise-AND with the complement of
119		- "u32_value" and write the result back to "u32_address".
120		-
121		- EQZ.n u32_address u32_count
122		- - Read the "u32_address" at most "u32_count" times and test if the value
123		- read is zero. If it is, break the loop earlier.
124		-
125		- NEZ.n u32_address u32_count
126		- - Read the "u32_address" at most "u32_count" times and test if the value
127		- read is non-zero. If it is, break the loop earlier.
128		-
129		- EQ.n u32_address u32_mask
130		- - Read the "u32_address" in a loop and test if the result masked with
131		- "u32_mask" equals the "u32_mask". If the values are equal, break the
132		- reading loop.
133		-
134		- NEQ.n u32_address u32_mask
135		- - Read the "u32_address" in a loop and test if the result masked with
136		- "u32_mask" does not equal the "u32_mask". If the values are not equal,
137		- break the reading loop.
138		-
139		- NOOP
140		- - This instruction does nothing.
141		-
142		- - An optional flags lines can be one of the following:
143		-
144		- DISPLAYPROGRESS
145		- - Enable boot progress output form the BootROM.
146		-
147		-- If the boot progress output from the BootROM is enabled, the BootROM will
148		- produce a letter on the Debug UART for each instruction it started processing.
149		- Here is a mapping between the above instructions and the BootROM output:
150		-
151		- H -- SB Image header loaded
152		- T -- TAG instruction
153		- N -- NOOP instruction
154		- L -- LOAD instruction
155		- F -- FILL instruction
156		- J -- JUMP instruction
157		- C -- CALL instruction
158		- M -- MODE instruction
159		-
160		-Usage -- verifying image:
161		-=========================
162		-
163		-The mxsimage can also verify and dump contents of an image. Use the following
164		-syntax to verify and dump contents of an image:
165		-
166		- mkimage -l <input bootstream file>
167		-
168		-This will output all the information from the SB image header and all the
169		-instructions contained in the SB image. It will also check if the various
170		-checksums in the SB image are correct.

doc/imx/mkimage/README.imximage

Diff comments View file @ 57310be

	1	+---------------------------------------------
	2	+Imximage Boot Image generation using mkimage
	3	+---------------------------------------------
	4	+
	5	+This document describes how to set up a U-Boot image that can be booted
	6	+by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot
	7	+mode.
	8	+
	9	+These processors can boot directly from NAND, SPI flash and SD card flash
	10	+using its internal boot ROM support. MX6 processors additionally support
	11	+boot from NOR flash and SATA disks. All processors can boot from an internal
	12	+UART, if booting from device media fails.
	13	+Booting from NOR flash does not require to use this image type.
	14	+
	15	+For more details refer Chapter 2 - System Boot and section 2.14
	16	+(flash header description) of the processor's manual.
	17	+
	18	+Command syntax:
	19	+--------------
	20	+./tools/mkimage -l <mx u-boot_file>
	21	+ to list the imx image file details
	22	+
	23	+./tools/mkimage -T imximage \
	24	+ -n <board specific configuration file> \
	25	+ -e <execution address> -d <u-boot binary> <output image file>
	26	+
	27	+For example, for the mx51evk board:
	28	+./tools/mkimage -n ./board/freescale/mx51evk/imximage.cfg \
	29	+ -T imximage -e 0x97800000 \
	30	+ -d u-boot.bin u-boot.imx
	31	+
	32	+You can generate directly the image when you compile u-boot with:
	33	+
	34	+$ make u-boot.imx
	35	+
	36	+The output image can be flashed on the board SPI flash or on a SD card.
	37	+In both cases, you have to copy the image at the offset required for the
	38	+chosen media devices (0x400 for both SPI flash or SD card).
	39	+
	40	+Please check Freescale documentation for further details.
	41	+
	42	+Board specific configuration file specifications:
	43	+-------------------------------------------------
	44	+1. This file must present in the $(BOARDDIR) and the name should be
	45	+ imximage.cfg (since this is used in Makefile).
	46	+2. This file can have empty lines and lines starting with "#" as first
	47	+ character to put comments.
	48	+3. This file can have configuration command lines as mentioned below,
	49	+ any other information in this file is treated as invalid.
	50	+
	51	+Configuration command line syntax:
	52	+---------------------------------
	53	+1. Each command line is must have two strings, first one command or address
	54	+ and second one data string
	55	+2. Following are the valid command strings and associated data strings:-
	56	+ Command string data string
	57	+ -------------- -----------
	58	+ IMXIMAGE_VERSION 1/2
	59	+ 1 is for mx25/mx35/mx51 compatible,
	60	+ 2 is for mx53/mx6 compatible,
	61	+ others is invalid and error is generated.
	62	+ This command need appear the fist before
	63	+ other valid commands in configuration file.
	64	+
	65	+ BOOT_OFFSET value
	66	+
	67	+ This command is parallel to BOOT_FROM and
	68	+ is preferred over BOOT_FROM.
	69	+
	70	+ value: Offset of the image header, this
	71	+ value shall be set to one of the
	72	+ values found in the file:
	73	+ arch/arm/include/asm/\
	74	+ mach-imx/imximage.cfg
	75	+ Example:
	76	+ BOOT_OFFSET FLASH_OFFSET_STANDARD
	77	+
	78	+ BOOT_FROM nand/spi/sd/onenand/nor/sata
	79	+
	80	+ This command is parallel to BOOT_OFFSET and
	81	+ is to be deprecated in favor of BOOT_OFFSET.
	82	+
	83	+ Example:
	84	+ BOOT_FROM spi
	85	+
	86	+ CSF value
	87	+
	88	+ Total size of CSF (Command Sequence File)
	89	+ used for Secure Boot/ High Assurance Boot
	90	+ (HAB).
	91	+
	92	+ Using this command will populate the IVT
	93	+ (Initial Vector Table) CSF pointer and adjust
	94	+ the length fields only. The CSF itself needs
	95	+ to be generated with Freescale tools and
	96	+ 'manually' appended to the u-boot.imx file.
	97	+
	98	+ The CSF is then simply concatenated
	99	+ to the u-boot image, making a signed bootloader,
	100	+ that the processor can verify
	101	+ if the fuses for the keys are burned.
	102	+
	103	+ Further infos how to configure the SOC to verify
	104	+ the bootloader can be found in the "High
	105	+ Assurance Boot Version Application Programming
	106	+ Interface Reference Manual" as part of the
	107	+ Freescale Code Signing Tool, available on the
	108	+ manufacturer's website.
	109	+
	110	+ Example:
	111	+ CSF 0x2000
	112	+
	113	+ DATA type address value
	114	+
	115	+ type: word=4, halfword=2, byte=1
	116	+ address: physycal register address
	117	+ value: value to be set in register
	118	+ All values are in in hexadecimal.
	119	+ Example (write to IOMUXC):
	120	+ DATA 4 0x73FA88a0 0x200
	121	+
	122	+The processor support up to 60 register programming commands for IMXIMAGE_VERSION 1
	123	+and 220 register programming commands for IMXIMAGE_VERSION 2.
	124	+An error is generated if more commands are found in the configuration file.
	125	+
	126	+3. All commands are optional to program.
	127	+
	128	+Setup a SD Card for booting
	129	+--------------------------------
	130	+
	131	+The following example prepare a SD card with u-boot and a FAT partition
	132	+to be used to stored the kernel to be booted.
	133	+I will set the SD in the most compatible mode, setting it with
	134	+255 heads and 63 sectors, as suggested from several documentation and
	135	+howto on line (I took as reference the preparation of a SD Card for the
	136	+Beagleboard, running u-boot as bootloader).
	137	+
	138	+You should start clearing the partitions table on the SD card. Because
	139	+the u-boot image must be stored at the offset 0x400, it must be assured
	140	+that there is no partition at that address. A new SD card is already
	141	+formatted with FAT filesystem and the partition starts from the first
	142	+cylinder, so we need to change it.
	143	+
	144	+You can do all steps with fdisk. If the device for the SD card is
	145	+/dev/mmcblk0, the following commands make the job:
	146	+
	147	+1. Start the fdisk utility (as superuser)
	148	+ fdisk /dev/mmcblk0
	149	+
	150	+2. Clear the actual partition
	151	+
	152	+Command (m for help): o
	153	+
	154	+3. Print card info:
	155	+
	156	+Command (m for help): p
	157	+Disk /dev/mmcblk0: 1981 MB, 1981284352 bytes
	158	+
	159	+In my case, I have a 2 GB card. I need the size to set later the correct value
	160	+for the cylinders.
	161	+
	162	+4. Go to expert mode:
	163	+
	164	+Command (m for help): x
	165	+
	166	+5. Set card geometry
	167	+
	168	+Expert command (m for help): h
	169	+Number of heads (1-256, default 4): 255
	170	+
	171	+Expert command (m for help): s
	172	+Number of sectors (1-63, default 16): 63
	173	+Warning: setting sector offset for DOS compatiblity
	174	+
	175	+We have set 255 heads, 63 sector. We have to set the cylinder.
	176	+The value to be set can be calculated with:
	177	+
	178	+ cilynder = <total size> / <heads> / <sectors> / <blocksize>
	179	+
	180	+in this example,
	181	+ 1981284352 / 255 / 63 / 512 = 239.x = 239
	182	+
	183	+
	184	+Expert command (m for help): c
	185	+Number of cylinders (1-1048576, default 60032): 239
	186	+
	187	+6. Leave the expert mode
	188	+Expert command (m for help): r
	189	+
	190	+7. Set up a partition
	191	+
	192	+Now set a partition table to store the kernel or whatever you want. Of course,
	193	+you can set additional partitions to store rootfs, data, etc.
	194	+In my example I want to set a single partition. I must take care
	195	+to not overwrite the space where I will put u-boot.
	196	+
	197	+Command (m for help): n
	198	+Command action
	199	+ e extended
	200	+ p primary partition (1-4)
	201	+p
	202	+Partition number (1-4): 1
	203	+First cylinder (1-239, default 1): 3
	204	+Last cylinder, +cylinders or +size{K,M,G} (3-239, default 239): +100M
	205	+
	206	+Command (m for help): p
	207	+
	208	+Disk /dev/mmcblk0: 1967 MB, 1967128576 bytes
	209	+255 heads, 63 sectors/track, 239 cylinders
	210	+Units = cylinders of 16065 * 512 = 8225280 bytes
	211	+Disk identifier: 0xb712a870
	212	+
	213	+ Device Boot Start End Blocks Id System
	214	+/dev/mmcblk0p1 3 16 112455 83 Linux
	215	+
	216	+I have set 100MB, leaving the first 2 sectors free. I will copy u-boot
	217	+there.
	218	+
	219	+8. Write the partition table and exit.
	220	+
	221	+Command (m for help): w
	222	+The partition table has been altered!
	223	+
	224	+Calling ioctl() to re-read partition table.
	225	+
	226	+9. Copy u-boot.imx on the SD card
	227	+
	228	+I use dd:
	229	+
	230	+dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2
	231	+
	232	+This command copies the u-boot image at the address 0x400, as required
	233	+by the processor.
	234	+
	235	+Now remove your card from the PC and go to the target. If evrything went right,
	236	+the u-boot prompt should come after power on.
	237	+
	238	+------------------------------------------------
	239	+Author: Stefano babic <sbabic@denx.de>

doc/imx/mkimage/README.mxsimage

Diff comments View file @ 57310be

	1	+Freescale i.MX233/i.MX28 SB image generator via mkimage
	2	+=======================================================
	3	+
	4	+This tool allows user to produce SB BootStream encrypted with a zero key.
	5	+Such a BootStream is then bootable on i.MX23/i.MX28.
	6	+
	7	+Usage -- producing image:
	8	+=========================
	9	+The mxsimage tool is targeted to be a simple replacement for the elftosb2 .
	10	+To generate an image, write an image configuration file and run:
	11	+
	12	+ mkimage -A arm -O u-boot -T mxsimage -n <path to configuration file> \
	13	+ <output bootstream file>
	14	+
	15	+The output bootstream file is usually using the .sb file extension. Note
	16	+that the example configuration files for producing bootable BootStream with
	17	+the U-Boot bootloader can be found under arch/arm/boot/cpu/arm926ejs/mxs/
	18	+directory. See the following files:
	19	+
	20	+ mxsimage.mx23.cfg -- This is an example configuration for i.MX23
	21	+ mxsimage.mx28.cfg -- This is an example configuration for i.MX28
	22	+
	23	+Each configuration file uses very simple instruction semantics and a few
	24	+additional rules have to be followed so that a useful image can be produced.
	25	+These semantics and rules will be outlined now.
	26	+
	27	+- Each line of the configuration file contains exactly one instruction.
	28	+- Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 .
	29	+- The configuration file is a concatenation of blocks called "sections" and
	30	+ optionally "DCD blocks" (see below), and optional flags lines.
	31	+ - Each "section" is started by the "SECTION" instruction.
	32	+ - The "SECTION" instruction has the following semantics:
	33	+
	34	+ SECTION u32_section_number [BOOTABLE]
	35	+ - u32_section_number :: User-selected ID of the section
	36	+ - BOOTABLE :: Sets the section as bootable
	37	+
	38	+ - A bootable section is one from which the BootROM starts executing
	39	+ subsequent instructions or code. Exactly one section must be selected
	40	+ as bootable, usually the one containing the instructions and data to
	41	+ load the bootloader.
	42	+
	43	+ - A "SECTION" must be immediatelly followed by a "TAG" instruction.
	44	+ - The "TAG" instruction has the following semantics:
	45	+
	46	+ TAG [LAST]
	47	+ - LAST :: Flag denoting the last section in the file
	48	+
	49	+ - After a "TAG" unstruction, any of the following instructions may follow
	50	+ in any order and any quantity:
	51	+
	52	+ NOOP
	53	+ - This instruction does nothing
	54	+
	55	+ LOAD u32_address string_filename
	56	+ - Instructs the BootROM to load file pointed by "string_filename" onto
	57	+ address "u32_address".
	58	+
	59	+ LOAD IVT u32_address u32_IVT_entry_point
	60	+ - Crafts and loads IVT onto address "u32_address" with the entry point
	61	+ of u32_IVT_entry_point.
	62	+ - i.MX28-specific instruction!
	63	+
	64	+ LOAD DCD u32_address u32_DCD_block_ID
	65	+ - Loads the DCD block with ID "u32_DCD_block_ID" onto address
	66	+ "u32_address" and executes the contents of this DCD block
	67	+ - i.MX28-specific instruction!
	68	+
	69	+ FILL u32_address u32_pattern u32_length
	70	+ - Starts to write memory from addres "u32_address" with a pattern
	71	+ specified by "u32_pattern". Writes exactly "u32_length" bytes of the
	72	+ pattern.
	73	+
	74	+ JUMP [HAB] u32_address [u32_r0_arg]
	75	+ - Jumps onto memory address specified by "u32_address" by setting this
	76	+ address in PT. The BootROM will pass the "u32_r0_arg" value in ARM
	77	+ register "r0" to the executed code if this option is specified.
	78	+ Otherwise, ARM register "r0" will default to value 0x00000000. The
	79	+ optional "HAB" flag is i.MX28-specific flag turning on the HAB boot.
	80	+
	81	+ CALL [HAB] u32_address [u32_r0_arg]
	82	+ - See JUMP instruction above, as the operation is exactly the same with
	83	+ one difference. The CALL instruction does allow returning into the
	84	+ BootROM from the executed code. U-Boot makes use of this in it's SPL
	85	+ code.
	86	+
	87	+ MODE string_mode
	88	+ - Restart the CPU and start booting from device specified by the
	89	+ "string_mode" argument. The "string_mode" differs for each CPU
	90	+ and can be:
	91	+ i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH
	92	+ JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1
	93	+ i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH
	94	+ JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1
	95	+
	96	+ - An optional "DCD" blocks can be added at the begining of the configuration
	97	+ file. Note that the DCD is only supported on i.MX28.
	98	+ - The DCD blocks must be inserted before the first "section" in the
	99	+ configuration file.
	100	+ - The DCD block has the following semantics:
	101	+
	102	+ DCD u32_DCD_block_ID
	103	+ - u32_DCD_block_ID :: The ID number of the DCD block, must match
	104	+ the ID number used by "LOAD DCD" instruction.
	105	+
	106	+ - The DCD block must be followed by one of the following instructions. All
	107	+ of the instructions operate either on 1, 2 or 4 bytes. This is selected by
	108	+ the 'n' suffix of the instruction:
	109	+
	110	+ WRITE.n u32_address u32_value
	111	+ - Write the "u32_value" to the "u32_address" address.
	112	+
	113	+ ORR.n u32_address u32_value
	114	+ - Read the "u32_address", perform a bitwise-OR with the "u32_value" and
	115	+ write the result back to "u32_address".
	116	+
	117	+ ANDC.n u32_address u32_value
	118	+ - Read the "u32_address", perform a bitwise-AND with the complement of
	119	+ "u32_value" and write the result back to "u32_address".
	120	+
	121	+ EQZ.n u32_address u32_count
	122	+ - Read the "u32_address" at most "u32_count" times and test if the value
	123	+ read is zero. If it is, break the loop earlier.
	124	+
	125	+ NEZ.n u32_address u32_count
	126	+ - Read the "u32_address" at most "u32_count" times and test if the value
	127	+ read is non-zero. If it is, break the loop earlier.
	128	+
	129	+ EQ.n u32_address u32_mask
	130	+ - Read the "u32_address" in a loop and test if the result masked with
	131	+ "u32_mask" equals the "u32_mask". If the values are equal, break the
	132	+ reading loop.
	133	+
	134	+ NEQ.n u32_address u32_mask
	135	+ - Read the "u32_address" in a loop and test if the result masked with
	136	+ "u32_mask" does not equal the "u32_mask". If the values are not equal,
	137	+ break the reading loop.
	138	+
	139	+ NOOP
	140	+ - This instruction does nothing.
	141	+
	142	+ - An optional flags lines can be one of the following:
	143	+
	144	+ DISPLAYPROGRESS
	145	+ - Enable boot progress output form the BootROM.
	146	+
	147	+- If the boot progress output from the BootROM is enabled, the BootROM will
	148	+ produce a letter on the Debug UART for each instruction it started processing.
	149	+ Here is a mapping between the above instructions and the BootROM output:
	150	+
	151	+ H -- SB Image header loaded
	152	+ T -- TAG instruction
	153	+ N -- NOOP instruction
	154	+ L -- LOAD instruction
	155	+ F -- FILL instruction
	156	+ J -- JUMP instruction
	157	+ C -- CALL instruction
	158	+ M -- MODE instruction
	159	+
	160	+Usage -- verifying image:
	161	+=========================
	162	+
	163	+The mxsimage can also verify and dump contents of an image. Use the following
	164	+syntax to verify and dump contents of an image:
	165	+
	166	+ mkimage -l <input bootstream file>
	167	+
	168	+This will output all the information from the SB image header and all the
	169	+instructions contained in the SB image. It will also check if the various
	170	+checksums in the SB image are correct.