source_file_format.rst 22 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684
  1. .. SPDX-License-Identifier: GPL-2.0+
  2. Flattened Image Tree (FIT) Format
  3. =================================
  4. Introduction
  5. ------------
  6. The number of elements playing a role in the kernel booting process has
  7. increased over time and now typically includes the devicetree, kernel image and
  8. possibly a ramdisk image. Generally, all must be placed in the system memory and
  9. booted together.
  10. For firmware images a similar process has taken place, with various binaries
  11. loaded at different addresses, such as ARM's ATF, OpenSBI, FPGA and U-Boot
  12. itself.
  13. FIT provides a flexible and extensible format to deal with this complexity. It
  14. provides support for multiple components. It also supports multiple
  15. configurations, so that the same FIT can be used to boot multiple boards, with
  16. some components in common (e.g. kernel) and some specific to that board (e.g.
  17. devicetree).
  18. Terminology
  19. ~~~~~~~~~~~
  20. This document defines FIT by providing FDT (Flat Device Tree) bindings. These
  21. describe the final form of the FIT at the moment when it is used. The user
  22. perspective may be simpler, as some of the properties (like timestamps and
  23. hashes) are filled in automatically by the U-Boot mkimage tool.
  24. To avoid confusion with the kernel FDT the following naming convention is used:
  25. FIT
  26. Flattened Image Tree
  27. FIT is formally a flattened devicetree (in the libfdt meaning), which conforms
  28. to bindings defined in this document.
  29. .its
  30. image tree source
  31. .itb
  32. flattened image tree blob
  33. Image-building procedure
  34. ~~~~~~~~~~~~~~~~~~~~~~~~
  35. The following picture shows how the FIT is prepared. Input consists of
  36. image source file (.its) and a set of data files. Image is created with the
  37. help of standard U-Boot mkimage tool which in turn uses dtc (device tree
  38. compiler) to produce image tree blob (.itb). The resulting .itb file is the
  39. actual binary of a new FIT::
  40. tqm5200.its
  41. +
  42. vmlinux.bin.gz mkimage + dtc xfer to target
  43. eldk-4.2-ramdisk --------------> tqm5200.itb --------------> boot
  44. tqm5200.dtb /|\
  45. |
  46. 'new FIT'
  47. Steps:
  48. #. Create .its file, automatically filled-in properties are omitted
  49. #. Call mkimage tool on a .its file
  50. #. mkimage calls dtc to create .itb image and assures that
  51. missing properties are added
  52. #. .itb (new FIT) is uploaded onto the target and used therein
  53. Unique identifiers
  54. ~~~~~~~~~~~~~~~~~~
  55. To identify FIT sub-nodes representing images, hashes, configurations (which
  56. are defined in the following sections), the "unit name" of the given sub-node
  57. is used as it's identifier as it assures uniqueness without additional
  58. checking required.
  59. External data
  60. ~~~~~~~~~~~~~
  61. FIT is normally built initially with image data in the 'data' property of each
  62. image node. It is also possible for this data to reside outside the FIT itself.
  63. This allows the 'FDT' part of the FIT to be quite small, so that it can be
  64. loaded and scanned without loading a large amount of data. Then when an image is
  65. needed it can be loaded from an external source.
  66. External FITs use 'data-offset' or 'data-position' instead of 'data'.
  67. The mkimage tool can convert a FIT to use external data using the `-E` argument,
  68. optionally using `-p` to specific a fixed position.
  69. It is often desirable to align each image to a block size or cache-line size
  70. (e.g. 512 bytes), so that there is no need to copy it to an aligned address when
  71. reading the image data. The mkimage tool provides a `-B` argument to support
  72. this.
  73. Root-node properties
  74. --------------------
  75. The root node of the FIT should have the following layout::
  76. / o image-tree
  77. |- description = "image description"
  78. |- timestamp = <12399321>
  79. |- #address-cells = <1>
  80. |
  81. o images
  82. | |
  83. | o image-1 {...}
  84. | o image-2 {...}
  85. | ...
  86. |
  87. o configurations
  88. |- default = "conf-1"
  89. |
  90. o conf-1 {...}
  91. o conf-2 {...}
  92. ...
  93. Optional property
  94. ~~~~~~~~~~~~~~~~~
  95. description
  96. Textual description of the FIT
  97. Mandatory property
  98. ~~~~~~~~~~~~~~~~~~
  99. timestamp
  100. Last image modification time being counted in seconds since
  101. 1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.
  102. Conditionally mandatory property
  103. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  104. #address-cells
  105. Number of 32bit cells required to represent entry and
  106. load addresses supplied within sub-image nodes. May be omitted when no
  107. entry or load addresses are used.
  108. Mandatory nodes
  109. ~~~~~~~~~~~~~~~
  110. images
  111. This node contains a set of sub-nodes, each of them representing
  112. single component sub-image (like kernel, ramdisk, etc.). At least one
  113. sub-image is required.
  114. configurations
  115. Contains a set of available configuration nodes and
  116. defines a default configuration.
  117. '/images' node
  118. --------------
  119. This node is a container node for component sub-image nodes. Each sub-node of
  120. the '/images' node should have the following layout::
  121. o image-1
  122. |- description = "component sub-image description"
  123. |- data = /incbin/("path/to/data/file.bin")
  124. |- type = "sub-image type name"
  125. |- arch = "ARCH name"
  126. |- os = "OS name"
  127. |- compression = "compression name"
  128. |- load = <00000000>
  129. |- entry = <00000000>
  130. |
  131. o hash-1 {...}
  132. o hash-2 {...}
  133. ...
  134. Mandatory properties
  135. ~~~~~~~~~~~~~~~~~~~~
  136. description
  137. Textual description of the component sub-image
  138. type
  139. Name of component sub-image type. Supported types are:
  140. ==================== ==================
  141. Sub-image type Meaning
  142. ==================== ==================
  143. invalid Invalid Image
  144. aisimage Davinci AIS image
  145. atmelimage ATMEL ROM-Boot Image
  146. copro Coprocessor Image}
  147. fdt_legacy legacy Image with Flat Device Tree
  148. filesystem Filesystem Image
  149. firmware Firmware
  150. firmware_ivt Firmware with HABv4 IVT }
  151. flat_dt Flat Device Tree
  152. fpga FPGA Image }
  153. gpimage TI Keystone SPL Image
  154. imx8image NXP i.MX8 Boot Image
  155. imx8mimage NXP i.MX8M Boot Image
  156. imximage Freescale i.MX Boot Image
  157. kernel Kernel Image
  158. kernel_noload Kernel Image (no loading done)
  159. kwbimage Kirkwood Boot Image
  160. lpc32xximage LPC32XX Boot Image
  161. mtk_image MediaTek BootROM loadable Image }
  162. multi Multi-File Image
  163. mxsimage Freescale MXS Boot Image
  164. omapimage TI OMAP SPL With GP CH
  165. pblimage Freescale PBL Boot Image
  166. pmmc TI Power Management Micro-Controller Firmware
  167. ramdisk RAMDisk Image
  168. rkimage Rockchip Boot Image }
  169. rksd Rockchip SD Boot Image }
  170. rkspi Rockchip SPI Boot Image }
  171. script Script
  172. socfpgaimage Altera SoCFPGA CV/AV preloader
  173. socfpgaimage_v1 Altera SoCFPGA A10 preloader
  174. spkgimage Renesas SPKG Image }
  175. standalone Standalone Program
  176. stm32image STMicroelectronics STM32 Image }
  177. sunxi_egon Allwinner eGON Boot Image }
  178. sunxi_toc0 Allwinner TOC0 Boot Image }
  179. tee Trusted Execution Environment Image
  180. ublimage Davinci UBL image
  181. vybridimage Vybrid Boot Image
  182. x86_setup x86 setup.bin
  183. zynqimage Xilinx Zynq Boot Image }
  184. zynqmpbif Xilinx ZynqMP Boot Image (bif) }
  185. zynqmpimage Xilinx ZynqMP Boot Image }
  186. ==================== ==================
  187. compression
  188. Compression used by included data. If no compression is used, the
  189. compression property should be set to "none". If the data is compressed but
  190. it should not be uncompressed by the loader (e.g. compressed ramdisk), this
  191. should also be set to "none".
  192. Supported compression types are:
  193. ==================== ==================
  194. Compression type Meaning
  195. ==================== ==================
  196. none uncompressed
  197. bzip2 bzip2 compressed
  198. gzip gzip compressed
  199. lz4 lz4 compressed
  200. lzma lzma compressed
  201. lzo lzo compressed
  202. zstd zstd compressed
  203. ==================== ==================
  204. data-size
  205. size of the data in bytes
  206. Conditionally mandatory property
  207. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  208. data
  209. Path to the external file which contains this node's binary data. Within
  210. the FIT this is the contents of the file. This is mandatory unless
  211. external data is used.
  212. data-offset
  213. Offset of the data in a separate image store. The image store is placed
  214. immediately after the last byte of the device tree binary, aligned to a
  215. 4-byte boundary. This is mandatory if external data is used, with an offset.
  216. data-position
  217. Machine address at which the data is to be found. This is a fixed address
  218. not relative to the loading of the FIT. This is mandatory if external data
  219. used with a fixed address.
  220. os
  221. OS name, mandatory for types "kernel". Valid OS names are:
  222. ==================== ==================
  223. OS name Meaning
  224. ==================== ==================
  225. invalid Invalid OS
  226. 4_4bsd 4_4BSD
  227. arm-trusted-firmware ARM Trusted Firmware
  228. dell Dell
  229. efi EFI Firmware
  230. esix Esix
  231. freebsd FreeBSD
  232. integrity INTEGRITY
  233. irix Irix
  234. linux Linux
  235. ncr NCR
  236. netbsd NetBSD
  237. openbsd OpenBSD
  238. openrtos OpenRTOS
  239. opensbi RISC-V OpenSBI
  240. ose Enea OSE
  241. plan9 Plan 9
  242. psos pSOS
  243. qnx QNX
  244. rtems RTEMS
  245. sco SCO
  246. solaris Solaris
  247. svr4 SVR4
  248. tee Trusted Execution Environment
  249. u-boot U-Boot
  250. vxworks VxWorks
  251. ==================== ==================
  252. arch
  253. Architecture name, mandatory for types: "standalone", "kernel",
  254. "firmware", "ramdisk" and "fdt". Valid architecture names are:
  255. ==================== ==================
  256. Architecture type Meaning
  257. ==================== ==================
  258. invalid Invalid ARCH
  259. alpha Alpha
  260. arc ARC
  261. arm64 AArch64
  262. arm ARM
  263. avr32 AVR32
  264. blackfin Blackfin
  265. ia64 IA64
  266. m68k M68K
  267. microblaze MicroBlaze
  268. mips64 MIPS 64 Bit
  269. mips MIPS
  270. nds32 NDS32
  271. nios2 NIOS II
  272. or1k OpenRISC 1000
  273. powerpc PowerPC
  274. ppc PowerPC
  275. riscv RISC-V
  276. s390 IBM S390
  277. sandbox Sandbox
  278. sh SuperH
  279. sparc64 SPARC 64 Bit
  280. sparc SPARC
  281. x86_64 AMD x86_64
  282. x86 Intel x86
  283. xtensa Xtensa
  284. ==================== ==================
  285. entry
  286. entry point address, address size is determined by
  287. '#address-cells' property of the root node.
  288. Mandatory for types: "firmware", and "kernel".
  289. load
  290. load address, address size is determined by '#address-cells'
  291. property of the root node.
  292. Mandatory for types: "firmware", and "kernel".
  293. compatible
  294. compatible method for loading image.
  295. Mandatory for types: "fpga", and images that do not specify a load address.
  296. Supported compatible methods:
  297. ========================== =========================================
  298. Compatible string Meaning
  299. ========================== =========================================
  300. u-boot,fpga-legacy Generic fpga loading routine.
  301. u-boot,zynqmp-fpga-ddrauth Signed non-encrypted FPGA bitstream for
  302. Xilinx Zynq UltraScale+ (ZymqMP) device.
  303. u-boot,zynqmp-fpga-enc Encrypted FPGA bitstream for Xilinx Zynq
  304. UltraScale+ (ZynqMP) device.
  305. ========================== =========================================
  306. phase
  307. U-Boot phase for which the image is intended.
  308. "spl"
  309. image is an SPL image
  310. "u-boot"
  311. image is a U-Boot image
  312. Optional nodes:
  313. hash-1
  314. Each hash sub-node represents separate hash or checksum
  315. calculated for node's data according to specified algorithm.
  316. signature-1
  317. Each signature sub-node represents separate signature
  318. calculated for node's data according to specified algorithm.
  319. Hash nodes
  320. ----------
  321. ::
  322. o hash-1
  323. |- algo = "hash or checksum algorithm name"
  324. |- value = [hash or checksum value]
  325. Mandatory properties
  326. ~~~~~~~~~~~~~~~~~~~~
  327. algo
  328. Algorithm name. Supported algoriths and their value sizes are:
  329. ==================== ============ =========================================
  330. Sub-image type Size (bytes) Meaning
  331. ==================== ============ =========================================
  332. crc16-ccitt 2 Cyclic Redundancy Check 16-bit
  333. (Consultative Committee for International
  334. Telegraphy and Telephony)
  335. crc32 4 Cyclic Redundancy Check 32-bit
  336. md5 16 Message Digest 5 (MD5)
  337. sha1 20 Secure Hash Algorithm 1 (SHA1)
  338. sha256 32 Secure Hash Algorithm 2 (SHA256)
  339. sha384 48 Secure Hash Algorithm 2 (SHA384)
  340. sha512 64 Secure Hash Algorithm 2 (SHA512)
  341. ==================== ============ =========================================
  342. value
  343. Actual checksum or hash value.
  344. Image-signature nodes
  345. ---------------------
  346. ::
  347. o signature-1
  348. |- algo = "algorithm name"
  349. |- key-name-hint = "key name"
  350. |- value = [hash or checksum value]
  351. Mandatory properties
  352. ~~~~~~~~~~~~~~~~~~~~
  353. _`FIT Algorithm`:
  354. algo
  355. Algorithm name. Supported algoriths and their value sizes are shown below.
  356. Note that the hash is specified separately from the signing algorithm, so
  357. it is possible to mix and match any SHA algorithm with any signing
  358. algorithm. The size of the signature relates to the signing algorithm, not
  359. the hash, since it is the hash that is signed.
  360. ==================== ============ =========================================
  361. Sub-image type Size (bytes) Meaning
  362. ==================== ============ =========================================
  363. sha1,rsa2048 256 SHA1 hash signed with 2048-bit
  364. Rivest–Shamir–Adleman algorithm
  365. sha1,rsa3072 384 SHA1 hash signed with 2048-bit RSA
  366. sha1,rsa4096 512 SHA1 hash signed with 2048-bit RSA
  367. sha1,ecdsa256 32 SHA1 hash signed with 256-bit Elliptic
  368. Curve Digital Signature Algorithm
  369. sha256,...
  370. sha384,...
  371. sha512,...
  372. ==================== ============ =========================================
  373. key-name-hint
  374. Name of key to use for signing. The keys will normally be in
  375. a single directory (parameter -k to mkimage). For a given key <name>, its
  376. private key is stored in <name>.key and the certificate is stored in
  377. <name>.crt.
  378. sign-images
  379. A list of images to sign, each being a property of the conf
  380. node that contains then. The default is "kernel,fdt" which means that these
  381. two images will be looked up in the config and signed if present. This is
  382. used by mkimage to determine which images to sign.
  383. The following properies are added as part of signing, and are mandatory:
  384. value
  385. Actual signature value. This is added by mkimage.
  386. hashed-nodes
  387. A list of nodes which were hashed by the signer. Each is
  388. a string - the full path to node. A typical value might be::
  389. hashed-nodes = "/", "/configurations/conf-1", "/images/kernel",
  390. "/images/kernel/hash-1", "/images/fdt-1",
  391. "/images/fdt-1/hash-1";
  392. hashed-strings
  393. The start and size of the string region of the FIT that was hashed. The
  394. start is normally 0, indicating the first byte of the string table. The size
  395. indicates the number of bytes hashed as part of signing.
  396. The following properies are added as part of signing, and are optional:
  397. timestamp
  398. Time when image was signed (standard Unix time_t format)
  399. signer-name
  400. Name of the signer (e.g. "mkimage")
  401. signer-version
  402. Version string of the signer (e.g. "2013.01")
  403. comment
  404. Additional information about the signer or image
  405. padding
  406. The padding algorithm, it may be pkcs-1.5 or pss,
  407. if no value is provided we assume pkcs-1.5
  408. '/configurations' node
  409. ----------------------
  410. The 'configurations' node creates convenient, labeled boot configurations,
  411. which combine together kernel images with their ramdisks and fdt blobs.
  412. The 'configurations' node has the following structure::
  413. o configurations
  414. |- default = "default configuration sub-node unit name"
  415. |
  416. o config-1 {...}
  417. o config-2 {...}
  418. ...
  419. Optional property
  420. ~~~~~~~~~~~~~~~~~
  421. default
  422. Selects one of the configuration sub-nodes as a default configuration.
  423. Mandatory nodes
  424. ~~~~~~~~~~~~~~~
  425. configuration-sub-node-unit-name
  426. At least one of the configuration sub-nodes is required.
  427. Optional nodes
  428. ~~~~~~~~~~~~~~
  429. signature-1
  430. Each signature sub-node represents separate signature
  431. calculated for the configuration according to specified algorithm.
  432. Configuration nodes
  433. -------------------
  434. Each configuration has the following structure::
  435. o config-1
  436. |- description = "configuration description"
  437. |- kernel = "kernel sub-node unit name"
  438. |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
  439. |- loadables = "loadables sub-node unit-name"
  440. |- script = "
  441. |- compatible = "vendor,board-style device tree compatible string"
  442. o signature-1 {...}
  443. Mandatory properties
  444. ~~~~~~~~~~~~~~~~~~~~
  445. description
  446. Textual configuration description.
  447. kernel or firmware
  448. Unit name of the corresponding kernel or firmware
  449. (u-boot, op-tee, etc) image. If both "kernel" and "firmware" are specified,
  450. control is passed to the firmware image.
  451. Optional properties
  452. ~~~~~~~~~~~~~~~~~~~
  453. fdt
  454. Unit name of the corresponding fdt blob (component image node of a
  455. "fdt type"). Additional fdt overlay nodes can be supplied which signify
  456. that the resulting device tree blob is generated by the first base fdt
  457. blob with all subsequent overlays applied.
  458. fpga
  459. Unit name of the corresponding fpga bitstream blob
  460. (component image node of a "fpga type").
  461. loadables
  462. Unit name containing a list of additional binaries to be
  463. loaded at their given locations. "loadables" is a comma-separated list
  464. of strings. U-Boot will load each binary at its given start-address and
  465. may optionally invoke additional post-processing steps on this binary based
  466. on its component image node type.
  467. script
  468. The image to use when loading a U-Boot script (for use with the
  469. source command).
  470. compatible
  471. The root compatible string of the U-Boot device tree that
  472. this configuration shall automatically match when CONFIG_FIT_BEST_MATCH is
  473. enabled. If this property is not provided, the compatible string will be
  474. extracted from the fdt blob instead. This is only possible if the fdt is
  475. not compressed, so images with compressed fdts that want to use compatible
  476. string matching must always provide this property.
  477. The FDT blob is required to properly boot FDT based kernel, so the minimal
  478. configuration for 2.6 FDT kernel is (kernel, fdt) pair.
  479. Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
  480. 'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
  481. not* be specified in a configuration node.
  482. Configuration-signature nodes
  483. -----------------------------
  484. ::
  485. o signature-1
  486. |- algo = "algorithm name"
  487. |- key-name-hint = "key name"
  488. |- sign-images = "path1", "path2";
  489. |- value = [hash or checksum value]
  490. |- hashed-strings = <0 len>
  491. Mandatory properties
  492. ~~~~~~~~~~~~~~~~~~~~
  493. algo
  494. See `FIT Algorithm`_.
  495. key-name-hint
  496. Name of key to use for signing. The keys will normally be in
  497. a single directory (parameter -k to mkimage). For a given key <name>, its
  498. private key is stored in <name>.key and the certificate is stored in
  499. <name>.crt.
  500. The following properies are added as part of signing, and are mandatory:
  501. value
  502. Actual signature value. This is added by mkimage.
  503. The following properies are added as part of signing, and are optional:
  504. timestamp
  505. Time when image was signed (standard Unix time_t format)
  506. signer-name
  507. Name of the signer (e.g. "mkimage")
  508. signer-version
  509. Version string of the signer (e.g. "2013.01")
  510. comment
  511. Additional information about the signer or image
  512. padding
  513. The padding algorithm, it may be pkcs-1.5 or pss,
  514. if no value is provided we assume pkcs-1.5
  515. Examples
  516. --------
  517. Some example files are available here, showing various scenarios
  518. .. toctree::
  519. :maxdepth: 1
  520. kernel
  521. kernel_fdt
  522. kernel_fdts_compressed
  523. multi
  524. multi_spl
  525. multi-with-fpga
  526. multi-with-loadables
  527. sec_firmware_ppa
  528. sign-configs
  529. sign-images
  530. uefi
  531. update3
  532. update_uboot
  533. .. sectionauthor:: Marian Balakowicz <m8@semihalf.com>
  534. .. sectionauthor:: External data additions, 25/1/16 Simon Glass <sjg@chromium.org>