Commit 57310be619b009bd7df804702d1bad724bc87430

Authored by Breno Lima
Committed by Ye Li
1 parent 27373a1723

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 Inline Diff

doc/imx/README.imximage
1 --------------------------------------------- File was deleted
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>
240 1 ---------------------------------------------
doc/imx/README.mxsimage
1 Freescale i.MX233/i.MX28 SB image generator via mkimage File was deleted
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.
171 1 Freescale i.MX233/i.MX28 SB image generator via mkimage
doc/imx/mkimage/README.imximage
File was created 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>
240
doc/imx/mkimage/README.mxsimage
File was created 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.
171