doc/uImage.FIT/source_file_format.txt

   1 U-boot new uImage source file format (bindings definition)
   2 ==========================================================
   3
   4 Author: Marian Balakowicz <m8@semihalf.com>
   5
   6 1) Introduction
   7 ---------------
   8
   9 Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new
  10 booting method which requires that hardware description is available to the
  11 kernel in the form of Flattened Device Tree.
  12
  13 Booting with a Flattened Device Tree is much more flexible and is intended to
  14 replace direct passing of 'struct bd_info' which was used to boot pre-FDT
  15 kernels.
  16
  17 However, U-boot needs to support both techniques to provide backward
  18 compatibility for platforms which are not FDT ready. Number of elements
  19 playing role in the booting process has increased and now includes the FDT
  20 blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
  21 in the system memory and passed to bootm as a arguments. Some of them may be
  22 missing: FDT is not present for legacy platforms, ramdisk is always optional.
  23 Additionally, old uImage format has been extended to support multi sub-images
  24 but the support is limited by simple format of the legacy uImage structure.
  25 Single binary header 'struct image_header' is not flexible enough to cover all
  26 possible scenarios.
  27
  28 All those factors combined clearly show that there is a need for new, more
  29 flexible, multi component uImage format.
  30
  31
  32 2) New uImage format assumptions
  33 --------------------------------
  34
  35 a) Implementation
  36
  37 Libfdt has been selected for the new uImage format implementation as (1) it
  38 provides 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
  41 b) Terminology
  42
  43 This document defines new uImage structure by providing FDT bindings for new
  44 uImage internals. Bindings are defined from U-boot perspective, i.e. describe
  45 final form of the uImage at the moment when it reaches U-boot. User
  46 perspective may be simpler, as some of the properties (like timestamps and
  47 hashes) will need to be filled in automatically by the U-boot mkimage tool.
  48
  49 To avoid confusion with the kernel FDT the following naming convention is
  50 proposed for the new uImage format related terms:
  51
  52 FIT     - Flattened uImage Tree
  53
  54 FIT is formally a flattened device tree (in the libfdt meaning), which
  55 conforms to bindings defined in this document.
  56
  57 .its    - image tree source
  58 .itb    - image tree blob
  59
  60 c) Image building procedure
  61
  62 The following picture shows how the new uImage is prepared. Input consists of
  63 image source file (.its) and a set of data files. Image is created with the
  64 help of standard U-boot mkimage tool which in turn uses dtc (device tree
  65 compiler) to produce image tree blob (.itb).  Resulting .itb file is the
  66 actual binary of a new uImage.
  67
  68
  69 tqm5200.its
  70 +
  71 vmlinux.bin.gz     mkimage + dtc               xfer to target
  72 eldk-4.2-ramdisk  --------------> tqm5200.itb --------------> bootm
  73 tqm5200.dtb                          /|\
  74 ...                                   |
  75                                  'new uImage'
  76
  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
  84 d) Unique identifiers
  85
  86 To identify FIT sub-nodes representing images, hashes, configurations (which
  87 are defined in the following sections), the "unit name" of the given sub-node
  88 is used as it's identifier as it assures uniqueness without additional
  89 checking required.
  90
  91
  92 3) Root node properties
  93 -----------------------
  94
  95 Root 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
 138 4) '/images' node
 139 -----------------
 140
 141 This node is a container node for component sub-image nodes. Each sub-node of
 142 the '/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",
 162     "flat_dt".
 163   - 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",
 172     "rtems", "unity", "integrity".
 173   - 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",
 176     "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200".
 177   - 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
 188 5) Hash nodes
 189 -------------
 190
 191 o 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
 201 6) '/configurations' node
 202 -------------------------
 203
 204 The 'configurations' node is optional. If present, it allows to create a
 205 convenient, labeled boot configurations, which combine together kernel images
 206 with their ramdisks and fdt blobs.
 207
 208 The 'configurations' node has has the following structure:
 209
 210 o 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
 227 7) Configuration nodes
 228 ----------------------
 229
 230 Each configuration has the following structure:
 231
 232 o 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
 250 The FDT blob is required to properly boot FDT based kernel, so the minimal
 251 configuration for 2.6 FDT kernel is (kernel, fdt) pair.
 252
 253 Older, 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
 255 not* be specified in a configuration node.
 256
 257
 258 8) Examples
 259 -----------
 260
 261 Please see doc/uImage.FIT/*.its for actual image source files.