blob: 9ed6f65e599383f837cc611e43d2c05a659b956c [file] [log] [blame]
Marian Balakowicz3310c542008-03-12 12:13:13 +01001U-boot new uImage source file format (bindings definition)
2==========================================================
3
4Author: Marian Balakowicz <m8@semihalf.com>
5
61) Introduction
7---------------
8
9Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new
10booting method which requires that hardware description is available to the
11kernel in the form of Flattened Device Tree.
12
13Booting with a Flattened Device Tree is much more flexible and is intended to
14replace direct passing of 'struct bd_info' which was used to boot pre-FDT
15kernels.
16
17However, U-boot needs to support both techniques to provide backward
18compatibility for platforms which are not FDT ready. Number of elements
19playing role in the booting process has increased and now includes the FDT
20blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
21in the system memory and passed to bootm as a arguments. Some of them may be
22missing: FDT is not present for legacy platforms, ramdisk is always optional.
23Additionally, old uImage format has been extended to support multi sub-images
24but the support is limited by simple format of the legacy uImage structure.
25Single binary header 'struct image_header' is not flexible enough to cover all
26possible scenarios.
27
28All those factors combined clearly show that there is a need for new, more
29flexible, multi component uImage format.
30
31
322) New uImage format assumptions
33--------------------------------
34
35a) Implementation
36
37Libfdt has been selected for the new uImage format implementation as (1) it
38provides needed functionality, (2) is actively maintained and developed and
39(3) increases code reuse as it is already part of the U-boot source tree.
40
41b) Terminology
42
43This document defines new uImage structure by providing FDT bindings for new
44uImage internals. Bindings are defined from U-boot perspective, i.e. describe
45final form of the uImage at the moment when it reaches U-boot. User
46perspective may be simpler, as some of the properties (like timestamps and
47hashes) will need to be filled in automatically by the U-boot mkimage tool.
48
49To avoid confusion with the kernel FDT the following naming convention is
50proposed for the new uImage format related terms:
51
52FIT - Flattened uImage Tree
53
54FIT is formally a flattened device tree (in the libfdt meaning), which
55conforms to bindings defined in this document.
56
57.its - image tree source
58.itb - image tree blob
59
60c) Image building procedure
61
62The following picture shows how the new uImage is prepared. Input consists of
63image source file (.its) and a set of data files. Image is created with the
64help of standard U-boot mkimage tool which in turn uses dtc (device tree
Masahiro Yamada61ffc172013-09-13 20:28:21 +090065compiler) to produce image tree blob (.itb). Resulting .itb file is the
Marian Balakowicz3310c542008-03-12 12:13:13 +010066actual binary of a new uImage.
67
68
69tqm5200.its
70+
Wolfgang Denk438a4c12008-03-26 11:48:46 +010071vmlinux.bin.gz mkimage + dtc xfer to target
Marian Balakowicz3310c542008-03-12 12:13:13 +010072eldk-4.2-ramdisk --------------> tqm5200.itb --------------> bootm
Wolfgang Denk438a4c12008-03-26 11:48:46 +010073tqm5200.dtb /|\
74... |
75 'new uImage'
Marian Balakowicz3310c542008-03-12 12:13:13 +010076
77 - create .its file, automatically filled-in properties are omitted
78 - call mkimage tool on a .its file
79 - mkimage calls dtc to create .itb image and assures that
80 missing properties are added
81 - .itb (new uImage) is uploaded onto the target and used therein
82
83
84d) Unique identifiers
85
86To identify FIT sub-nodes representing images, hashes, configurations (which
87are defined in the following sections), the "unit name" of the given sub-node
88is used as it's identifier as it assures uniqueness without additional
89checking required.
90
91
923) Root node properties
93-----------------------
94
95Root node of the uImage Tree should have the following layout:
96
97/ o image-tree
98 |- description = "image description"
99 |- timestamp = <12399321>
100 |- #address-cells = <1>
101 |
102 o images
103 | |
104 | o img@1 {...}
105 | o img@2 {...}
106 | ...
107 |
108 o configurations
109 |- default = "cfg@1"
110 |
111 o cfg@1 {...}
112 o cfg@2 {...}
113 ...
114
115
116 Optional property:
117 - description : Textual description of the uImage
118
119 Mandatory property:
120 - timestamp : Last image modification time being counted in seconds since
121 1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.
122
123 Conditionally mandatory property:
124 - #address-cells : Number of 32bit cells required to represent entry and
125 load addresses supplied within sub-image nodes. May be omitted when no
126 entry or load addresses are used.
127
128 Mandatory node:
129 - images : This node contains a set of sub-nodes, each of them representing
130 single component sub-image (like kernel, ramdisk, etc.). At least one
131 sub-image is required.
132
133 Optional node:
134 - configurations : Contains a set of available configuration nodes and
135 defines a default configuration.
136
137
1384) '/images' node
139-----------------
140
141This node is a container node for component sub-image nodes. Each sub-node of
142the '/images' node should have the following layout:
143
144 o image@1
145 |- description = "component sub-image description"
146 |- data = /incbin/("path/to/data/file.bin")
147 |- type = "sub-image type name"
148 |- arch = "ARCH name"
149 |- os = "OS name"
150 |- compression = "compression name"
151 |- load = <00000000>
152 |- entry = <00000000>
153 |
154 o hash@1 {...}
155 o hash@2 {...}
156 ...
157
158 Mandatory properties:
159 - description : Textual description of the component sub-image
160 - type : Name of component sub-image type, supported types are:
161 "standalone", "kernel", "ramdisk", "firmware", "script", "filesystem",
Masahiro Yamada09b72d62014-01-16 11:05:23 +0900162 "flat_dt".
Marian Balakowicz3310c542008-03-12 12:13:13 +0100163 - data : Path to the external file which contains this node's binary data.
164 - compression : Compression used by included data. Supported compressions
165 are "gzip" and "bzip2". If no compression is used compression property
166 should be set to "none".
167
168 Conditionally mandatory property:
169 - os : OS name, mandatory for type="kernel", valid OS names are: "openbsd",
170 "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix", "solaris", "irix",
171 "sco", "dell", "ncr", "lynxos", "vxworks", "psos", "qnx", "u_boot",
Peter Tyserf5ed9e32008-09-08 14:56:49 -0500172 "rtems", "unity", "integrity".
Marian Balakowicz3310c542008-03-12 12:13:13 +0100173 - arch : Architecture name, mandatory for types: "standalone", "kernel",
174 "firmware", "ramdisk" and "fdt". Valid architecture names are: "alpha",
175 "arm", "i386", "ia64", "mips", "mips64", "ppc", "s390", "sh", "sparc",
Thomas Chou1117cbf2010-05-28 10:56:50 +0800176 "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200".
Marian Balakowicz3310c542008-03-12 12:13:13 +0100177 - entry : entry point address, address size is determined by
178 '#address-cells' property of the root node. Mandatory for for types:
179 "standalone" and "kernel".
180 - load : load address, address size is determined by '#address-cells'
181 property of the root node. Mandatory for types: "standalone" and "kernel".
182
183 Optional nodes:
184 - hash@1 : Each hash sub-node represents separate hash or checksum
185 calculated for node's data according to specified algorithm.
186
187
1885) Hash nodes
189-------------
190
191o hash@1
192 |- algo = "hash or checksum algorithm name"
193 |- value = [hash or checksum value]
194
195 Mandatory properties:
196 - algo : Algorithm name, supported are "crc32", "md5" and "sha1".
197 - value : Actual checksum or hash value, correspondingly 4, 16 or 20 bytes
198 long.
199
200
2016) '/configurations' node
202-------------------------
203
204The 'configurations' node is optional. If present, it allows to create a
205convenient, labeled boot configurations, which combine together kernel images
206with their ramdisks and fdt blobs.
207
208The 'configurations' node has has the following structure:
209
210o configurations
211 |- default = "default configuration sub-node unit name"
212 |
213 o config@1 {...}
214 o config@2 {...}
215 ...
216
217
218 Optional property:
219 - default : Selects one of the configuration sub-nodes as a default
220 configuration.
221
222 Mandatory nodes:
223 - configuration-sub-node-unit-name : At least one of the configuration
224 sub-nodes is required.
225
226
2277) Configuration nodes
228----------------------
229
230Each configuration has the following structure:
231
232o config@1
233 |- description = "configuration description"
234 |- kernel = "kernel sub-node unit name"
235 |- ramdisk = "ramdisk sub-node unit name"
236 |- fdt = "fdt sub-node unit-name"
237
238
239 Mandatory properties:
240 - description : Textual configuration description.
241 - kernel : Unit name of the corresponding kernel image (image sub-node of a
242 "kernel" type).
243
244 Optional properties:
245 - ramdisk : Unit name of the corresponding ramdisk image (component image
246 node of a "ramdisk" type).
247 - fdt : Unit name of the corresponding fdt blob (component image node of a
248 "fdt type").
249
250The FDT blob is required to properly boot FDT based kernel, so the minimal
251configuration for 2.6 FDT kernel is (kernel, fdt) pair.
252
253Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
254'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
255not* be specified in a configuration node.
256
257
2588) Examples
259-----------
260
Bartlomiej Sieka43142e82008-03-20 23:10:19 +0100261Please see doc/uImage.FIT/*.its for actual image source files.