~funderscore blog cgit wiki get in touch
aboutsummaryrefslogtreecommitdiff
blob: b2b1e42bd7303260e3c5437f98fd75dcab852fd9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
.. SPDX-License-Identifier: GPL-2.0+

Flattened Image Tree (FIT) Format
=================================

Introduction
------------

The number of elements playing a role in the kernel booting process has
increased over time and now typically includes the devicetree, kernel image and
possibly a ramdisk image. Generally, all must be placed in the system memory and
booted together.

For firmware images a similar process has taken place, with various binaries
loaded at different addresses, such as ARM's ATF, OpenSBI, FPGA and U-Boot
itself.

FIT provides a flexible and extensible format to deal with this complexity. It
provides support for multiple components. It also supports multiple
configurations, so that the same FIT can be used to boot multiple boards, with
some components in common (e.g. kernel) and some specific to that board (e.g.
devicetree).

Terminology
~~~~~~~~~~~

This document defines FIT by providing FDT (Flat Device Tree) bindings. These
describe the final form of the FIT at the moment when it is used. The user
perspective may be simpler, as some of the properties (like timestamps and
hashes) are filled in automatically by the U-Boot mkimage tool.

To avoid confusion with the kernel FDT the following naming convention is used:

FIT
    Flattened Image Tree

FIT is formally a flattened devicetree (in the libfdt meaning), which conforms
to bindings defined in this document.

.its
    image tree source

.itb
    flattened image tree blob

Image-building procedure
~~~~~~~~~~~~~~~~~~~~~~~~

The following picture shows how the FIT is prepared. Input consists of
image source file (.its) and a set of data files. Image is created with the
help of standard U-Boot mkimage tool which in turn uses dtc (device tree
compiler) to produce image tree blob (.itb). The resulting .itb file is the
actual binary of a new FIT::

    tqm5200.its
    +
    vmlinux.bin.gz     mkimage + dtc               xfer to target
    eldk-4.2-ramdisk  --------------> tqm5200.itb --------------> boot
    tqm5200.dtb                          /|\
                                          |
                                     'new FIT'

Steps:

#. Create .its file, automatically filled-in properties are omitted

#. Call mkimage tool on a .its file

#. mkimage calls dtc to create .itb image and assures that
   missing properties are added

#. .itb (new FIT) is uploaded onto the target and used therein


Unique identifiers
~~~~~~~~~~~~~~~~~~

To identify FIT sub-nodes representing images, hashes, configurations (which
are defined in the following sections), the "unit name" of the given sub-node
is used as it's identifier as it assures uniqueness without additional
checking required.


External data
~~~~~~~~~~~~~

FIT is normally built initially with image data in the 'data' property of each
image node. It is also possible for this data to reside outside the FIT itself.
This allows the 'FDT' part of the FIT to be quite small, so that it can be
loaded and scanned without loading a large amount of data. Then when an image is
needed it can be loaded from an external source.

External FITs use 'data-offset' or 'data-position' instead of 'data'.

The mkimage tool can convert a FIT to use external data using the `-E` argument,
optionally using `-p` to specific a fixed position.

It is often desirable to align each image to a block size or cache-line size
(e.g. 512 bytes), so that there is no need to copy it to an aligned address when
reading the image data. The mkimage tool provides a `-B` argument to support
this.

Root-node properties
--------------------

The root node of the FIT should have the following layout::

    / o image-tree
        |- description = "image description"
        |- timestamp = <12399321>
        |- #address-cells = <1>
        |
        o images
        | |
        | o image-1 {...}
        | o image-2 {...}
        | ...
        |
        o configurations
          |- default = "conf-1"
          |
          o conf-1 {...}
          o conf-2 {...}
          ...

Optional property
~~~~~~~~~~~~~~~~~

description
    Textual description of the FIT

Mandatory property
~~~~~~~~~~~~~~~~~~

timestamp
    Last image modification time being counted in seconds since
    1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.

Conditionally mandatory property
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#address-cells
    Number of 32bit cells required to represent entry and
    load addresses supplied within sub-image nodes. May be omitted when no
    entry or load addresses are used.

Mandatory nodes
~~~~~~~~~~~~~~~

images
    This node contains a set of sub-nodes, each of them representing
    single component sub-image (like kernel, ramdisk, etc.). At least one
    sub-image is required.

configurations
    Contains a set of available configuration nodes and
    defines a default configuration.


'/images' node
--------------

This node is a container node for component sub-image nodes. Each sub-node of
the '/images' node should have the following layout::

    o image-1
        |- description = "component sub-image description"
        |- data = /incbin/("path/to/data/file.bin")
        |- type = "sub-image type name"
        |- arch = "ARCH name"
        |- os = "OS name"
        |- compression = "compression name"
        |- load = <00000000>
        |- entry = <00000000>
        |
        o hash-1 {...}
        o hash-2 {...}
        ...

Mandatory properties
~~~~~~~~~~~~~~~~~~~~

description
    Textual description of the component sub-image

type
    Name of component sub-image type. Supported types are:

    ====================  ==================
    Sub-image type        Meaning
    ====================  ==================
    invalid               Invalid Image
    aisimage              Davinci AIS image
    atmelimage            ATMEL ROM-Boot Image
    copro                 Coprocessor Image}
    fdt_legacy            legacy Image with Flat Device Tree
    filesystem            Filesystem Image
    firmware              Firmware
    firmware_ivt          Firmware with HABv4 IVT }
    flat_dt               Flat Device Tree
    fpga                  FPGA Image }
    gpimage               TI Keystone SPL Image
    imx8image             NXP i.MX8 Boot Image
    imx8mimage            NXP i.MX8M Boot Image
    imximage              Freescale i.MX Boot Image
    kernel                Kernel Image
    kernel_noload         Kernel Image (no loading done)
    kwbimage              Kirkwood Boot Image
    lpc32xximage          LPC32XX Boot Image
    mtk_image             MediaTek BootROM loadable Image }
    multi                 Multi-File Image
    mxsimage              Freescale MXS Boot Image
    omapimage             TI OMAP SPL With GP CH
    pblimage              Freescale PBL Boot Image
    pmmc                  TI Power Management Micro-Controller Firmware
    ramdisk               RAMDisk Image
    rkimage               Rockchip Boot Image }
    rksd                  Rockchip SD Boot Image }
    rkspi                 Rockchip SPI Boot Image }
    script                Script
    socfpgaimage          Altera SoCFPGA CV/AV preloader
    socfpgaimage_v1       Altera SoCFPGA A10 preloader
    spkgimage             Renesas SPKG Image }
    standalone            Standalone Program
    stm32image            STMicroelectronics STM32 Image }
    sunxi_egon            Allwinner eGON Boot Image }
    sunxi_toc0            Allwinner TOC0 Boot Image }
    tee                   Trusted Execution Environment Image
    ublimage              Davinci UBL image
    vybridimage           Vybrid Boot Image
    x86_setup             x86 setup.bin
    zynqimage             Xilinx Zynq Boot Image }
    zynqmpbif             Xilinx ZynqMP Boot Image (bif) }
    zynqmpimage           Xilinx ZynqMP Boot Image }
    ====================  ==================

compression
    Compression used by included data. If no compression is used, the
    compression property should be set to "none". If the data is compressed but
    it should not be uncompressed by the loader (e.g. compressed ramdisk), this
    should also be set to "none".

    Supported compression types are:

    ====================  ==================
    Compression type      Meaning
    ====================  ==================
    none                  uncompressed
    bzip2                 bzip2 compressed
    gzip                  gzip compressed
    lz4                   lz4 compressed
    lzma                  lzma compressed
    lzo                   lzo compressed
    zstd                  zstd compressed
    ====================  ==================

data-size
    size of the data in bytes


Conditionally mandatory property
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

data
    Path to the external file which contains this node's binary data. Within
    the FIT this is the contents of the file. This is mandatory unless
    external data is used.

data-offset
    Offset of the data in a separate image store. The image store is placed
    immediately after the last byte of the device tree binary, aligned to a
    4-byte boundary. This is mandatory if external data is used, with an offset.

data-position
    Machine address at which the data is to be found. This is a fixed address
    not relative to the loading of the FIT. This is mandatory if external data
    used with a fixed address.

os
    OS name, mandatory for types "kernel". Valid OS names are:

    ====================  ==================
    OS name               Meaning
    ====================  ==================
    invalid               Invalid OS
    4_4bsd                4_4BSD
    arm-trusted-firmware  ARM Trusted Firmware
    dell                  Dell
    efi                   EFI Firmware
    esix                  Esix
    freebsd               FreeBSD
    integrity             INTEGRITY
    irix                  Irix
    linux                 Linux
    ncr                   NCR
    netbsd                NetBSD
    openbsd               OpenBSD
    openrtos              OpenRTOS
    opensbi               RISC-V OpenSBI
    ose                   Enea OSE
    plan9                 Plan 9
    psos                  pSOS
    qnx                   QNX
    rtems                 RTEMS
    sco                   SCO
    solaris               Solaris
    svr4                  SVR4
    tee                   Trusted Execution Environment
    u-boot                U-Boot
    vxworks               VxWorks
    ====================  ==================

arch
    Architecture name, mandatory for types: "standalone", "kernel",
    "firmware", "ramdisk" and "fdt". Valid architecture names are:

    ====================  ==================
    Architecture type     Meaning
    ====================  ==================
    invalid               Invalid ARCH
    alpha                 Alpha
    arc                   ARC
    arm64                 AArch64
    arm                   ARM
    avr32                 AVR32
    blackfin              Blackfin
    ia64                  IA64
    m68k                  M68K
    microblaze            MicroBlaze
    mips64                MIPS 64 Bit
    mips                  MIPS
    nds32                 NDS32
    nios2                 NIOS II
    or1k                  OpenRISC 1000
    powerpc               PowerPC
    ppc                   PowerPC
    riscv                 RISC-V
    s390                  IBM S390
    sandbox               Sandbox
    sh                    SuperH
    sparc64               SPARC 64 Bit
    sparc                 SPARC
    x86_64                AMD x86_64
    x86                   Intel x86
    xtensa                Xtensa
    ====================  ==================

entry
    entry point address, address size is determined by
    '#address-cells' property of the root node.
    Mandatory for types: "firmware", and "kernel".

load
    load address, address size is determined by '#address-cells'
    property of the root node.
    Mandatory for types: "firmware", and "kernel".

compatible
    compatible method for loading image.
    Mandatory for types: "fpga", and images that do not specify a load address.
    Supported compatible methods:

    ==========================  =========================================
    Compatible string           Meaning
    ==========================  =========================================
    u-boot,fpga-legacy          Generic fpga loading routine.
    u-boot,zynqmp-fpga-ddrauth  Signed non-encrypted FPGA bitstream for
                                Xilinx Zynq UltraScale+ (ZymqMP) device.
    u-boot,zynqmp-fpga-enc      Encrypted FPGA bitstream for Xilinx Zynq
                                UltraScale+ (ZynqMP) device.
    ==========================  =========================================

phase
    U-Boot phase for which the image is intended.

    "spl"
        image is an SPL image

    "u-boot"
        image is a U-Boot image

Optional nodes:

hash-1
    Each hash sub-node represents separate hash or checksum
    calculated for node's data according to specified algorithm.

signature-1
    Each signature sub-node represents separate signature
    calculated for node's data according to specified algorithm.


Hash nodes
----------

::

    o hash-1
        |- algo = "hash or checksum algorithm name"
        |- value = [hash or checksum value]

Mandatory properties
~~~~~~~~~~~~~~~~~~~~

algo
    Algorithm name. Supported algoriths and their value sizes are:

    ==================== ============ =========================================
    Sub-image type       Size (bytes) Meaning
    ==================== ============ =========================================
    crc16-ccitt          2            Cyclic Redundancy Check 16-bit
                                      (Consultative Committee for International
                                      Telegraphy and Telephony)
    crc32                4            Cyclic Redundancy Check 32-bit
    md5                  16           Message Digest 5 (MD5)
    sha1                 20           Secure Hash Algorithm 1 (SHA1)
    sha256               32           Secure Hash Algorithm 2 (SHA256)
    sha384               48           Secure Hash Algorithm 2 (SHA384)
    sha512               64           Secure Hash Algorithm 2 (SHA512)
    ==================== ============ =========================================

value
    Actual checksum or hash value.

Image-signature nodes
---------------------

::

    o signature-1
        |- algo = "algorithm name"
        |- key-name-hint = "key name"
        |- value = [hash or checksum value]


Mandatory properties
~~~~~~~~~~~~~~~~~~~~

_`FIT Algorithm`:

algo
    Algorithm name. Supported algoriths and their value sizes are shown below.
    Note that the hash is specified separately from the signing algorithm, so
    it is possible to mix and match any SHA algorithm with any signing
    algorithm. The size of the signature relates to the signing algorithm, not
    the hash, since it is the hash that is signed.

    ==================== ============ =========================================
    Sub-image type       Size (bytes) Meaning
    ==================== ============ =========================================
    sha1,rsa2048         256          SHA1 hash signed with 2048-bit
                                      Rivest–Shamir–Adleman algorithm
    sha1,rsa3072         384          SHA1 hash signed with 2048-bit RSA
    sha1,rsa4096         512          SHA1 hash signed with 2048-bit RSA
    sha1,ecdsa256        32           SHA1 hash signed with 256-bit  Elliptic
                                      Curve Digital Signature Algorithm
    sha256,...
    sha384,...
    sha512,...
    ==================== ============ =========================================

key-name-hint
    Name of key to use for signing. The keys will normally be in
    a single directory (parameter -k to mkimage). For a given key <name>, its
    private key is stored in <name>.key and the certificate is stored in
    <name>.crt.

sign-images
    A list of images to sign, each being a property of the conf
    node that contains then. The default is "kernel,fdt" which means that these
    two images will be looked up in the config and signed if present. This is
    used by mkimage to determine which images to sign.

The following properies are added as part of signing, and are mandatory:

value
    Actual signature value. This is added by mkimage.

hashed-nodes
    A list of nodes which were hashed by the signer. Each is
    a string - the full path to node. A typical value might be::

	hashed-nodes = "/", "/configurations/conf-1", "/images/kernel",
	    "/images/kernel/hash-1", "/images/fdt-1",
	    "/images/fdt-1/hash-1";

hashed-strings
    The start and size of the string region of the FIT that was hashed. The
    start is normally 0, indicating the first byte of the string table. The size
    indicates the number of bytes hashed as part of signing.

The following properies are added as part of signing, and are optional:

timestamp
    Time when image was signed (standard Unix time_t format)

signer-name
    Name of the signer (e.g. "mkimage")

signer-version
    Version string of the signer (e.g. "2013.01")

comment
    Additional information about the signer or image

padding
    The padding algorithm, it may be pkcs-1.5 or pss,
    if no value is provided we assume pkcs-1.5


'/configurations' node
----------------------

The 'configurations' node creates convenient, labeled boot configurations,
which combine together kernel images with their ramdisks and fdt blobs.

The 'configurations' node has the following structure::

    o configurations
        |- default = "default configuration sub-node unit name"
        |
        o config-1 {...}
        o config-2 {...}
        ...


Optional property
~~~~~~~~~~~~~~~~~

default
    Selects one of the configuration sub-nodes as a default configuration.

Mandatory nodes
~~~~~~~~~~~~~~~

configuration-sub-node-unit-name
    At least one of the configuration sub-nodes is required.

Optional nodes
~~~~~~~~~~~~~~

signature-1
    Each signature sub-node represents separate signature
    calculated for the configuration according to specified algorithm.


Configuration nodes
-------------------

Each configuration has the following structure::

    o config-1
        |- description = "configuration description"
        |- kernel = "kernel sub-node unit name"
        |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
        |- loadables = "loadables sub-node unit-name"
        |- script = "
        |- compatible = "vendor,board-style device tree compatible string"
        o signature-1 {...}

Mandatory properties
~~~~~~~~~~~~~~~~~~~~

description
    Textual configuration description.

kernel or firmware
    Unit name of the corresponding kernel or firmware
    (u-boot, op-tee, etc) image. If both "kernel" and "firmware" are specified,
    control is passed to the firmware image.

Optional properties
~~~~~~~~~~~~~~~~~~~

fdt
    Unit name of the corresponding fdt blob (component image node of a
    "fdt type"). Additional fdt overlay nodes can be supplied which signify
    that the resulting device tree blob is generated by the first base fdt
    blob with all subsequent overlays applied.

fpga
    Unit name of the corresponding fpga bitstream blob
    (component image node of a "fpga type").

loadables
    Unit name containing a list of additional binaries to be
    loaded at their given locations.  "loadables" is a comma-separated list
    of strings. U-Boot will load each binary at its given start-address and
    may optionally invoke additional post-processing steps on this binary based
    on its component image node type.

script
    The image to use when loading a U-Boot script (for use with the
    source command).

compatible
    The root compatible string of the U-Boot device tree that
    this configuration shall automatically match when CONFIG_FIT_BEST_MATCH is
    enabled. If this property is not provided, the compatible string will be
    extracted from the fdt blob instead. This is only possible if the fdt is
    not compressed, so images with compressed fdts that want to use compatible
    string matching must always provide this property.

The FDT blob is required to properly boot FDT based kernel, so the minimal
configuration for 2.6 FDT kernel is (kernel, fdt) pair.

Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
not* be specified in a configuration node.

Configuration-signature nodes
-----------------------------

::

    o signature-1
        |- algo = "algorithm name"
        |- key-name-hint = "key name"
        |- sign-images = "path1", "path2";
        |- value = [hash or checksum value]
        |- hashed-strings = <0 len>


Mandatory properties
~~~~~~~~~~~~~~~~~~~~

algo
    See `FIT Algorithm`_.

key-name-hint
    Name of key to use for signing. The keys will normally be in
    a single directory (parameter -k to mkimage). For a given key <name>, its
    private key is stored in <name>.key and the certificate is stored in
    <name>.crt.

The following properies are added as part of signing, and are mandatory:

value
    Actual signature value. This is added by mkimage.

The following properies are added as part of signing, and are optional:

timestamp
    Time when image was signed (standard Unix time_t format)

signer-name
    Name of the signer (e.g. "mkimage")

signer-version
    Version string of the signer (e.g. "2013.01")

comment
    Additional information about the signer or image

padding
    The padding algorithm, it may be pkcs-1.5 or pss,
    if no value is provided we assume pkcs-1.5



Examples
--------

Some example files are available here, showing various scenarios

.. toctree::
    :maxdepth: 1

    kernel
    kernel_fdt
    kernel_fdts_compressed
    multi
    multi_spl
    multi-with-fpga
    multi-with-loadables
    sec_firmware_ppa
    sign-configs
    sign-images
    uefi
    update3
    update_uboot

.. sectionauthor:: Marian Balakowicz <m8@semihalf.com>
.. sectionauthor:: External data additions, 25/1/16 Simon Glass <sjg@chromium.org>