[RFC 1/1] doc: Remove FIT documentation that is elsewhere

Sam Povilus sam.povilus at amd.com
Mon Jul 1 21:52:12 CEST 2024



On 6/18/2024 12:03 AM, Heinrich Schuchardt wrote:
> Caution: This message originated from an External Source. Use proper 
> caution when opening attachments, clicking links, or responding.
> 
> 
> On 6/17/24 22:20, Sam Povilus wrote:
>> FIT documentation is now a separate project, instead of having a
>> duplicate, we should point at the other project.
>>
>> Signed-off-by: Sam Povilus <sam.povilus at amd.com>
>> ---
>>   doc/usage/fit/index.rst              |  14 +-
>>   doc/usage/fit/source_file_format.rst | 682 +--------------------------
>>   2 files changed, 5 insertions(+), 691 deletions(-)
>>
>> diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
>> index bd25bd30b2..12a8c6fb16 100644
>> --- a/doc/usage/fit/index.rst
>> +++ b/doc/usage/fit/index.rst
>> @@ -4,16 +4,6 @@ Flat Image Tree (FIT)
>>   =====================
>>
>>   U-Boot uses Flat Image Tree (FIT) as a standard file format for 
>> packaging
>> -images that it it reads and boots. Documentation about FIT is 
>> available at
>> -doc/uImage.FIT
>> +images that it it reads and boots. Documentation about FIT is 
>> available in
>> +`the Flattened Image Tree project <https://fitspec.osfw.foundation/>`_.
>>
>> -.. toctree::
>> -    :maxdepth: 1
>> -
>> -    source_file_format
> 
> This is the only entry to be replaced by the external link.
> 
>> -    howto
>> -    x86-fit-boot
>> -    signature
>> -    verified-boot
>> -    beaglebone_vboot
>> -    overlay-fdt-boot
> 
> All of these files are staying around and must be kept linked.

I would argue that if this list is not being maintained, it is better to 
remove it than to try to keep it up to date. Maybe that should be a 
separate patch though?

> 
> Many links are missing here. The complete list should be:
> 
>      beaglebone_vboot
>      howto
>      kernel_fdt
>      kernel_fdts_compressed
>      kernel
>      multi
>      multi_spl
>      multi-with-fpga
>      multi-with-loadables
>      overlay-fdt-boot
>      sec_firmware_ppa
>      signature
>      sign-configs
>      sign-images
>      uefi
>      update3
>      update_uboot
>      verified-boot
>      x86-fit-boot
> 
> These other documents should be carefully redacted. E.g. howto.rst
> refers to the FIT file format as "the new uImage format".

I agree that it would be nice to take a pass through all this 
documentation and clean it up, but I think there is value in doing small 
cleanups as one has time.

> 
> Best regards
> 
> Heinrich
> 
>> diff --git a/doc/usage/fit/source_file_format.rst 
>> b/doc/usage/fit/source_file_format.rst
>> index b2b1e42bd7..0c44329a82 100644
>> --- a/doc/usage/fit/source_file_format.rst
>> +++ b/doc/usage/fit/source_file_format.rst
>> @@ -3,682 +3,6 @@
>>   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 at semihalf.com>
>> -.. sectionauthor:: External data additions, 25/1/16 Simon Glass 
>> <sjg at chromium.org>
>> +FIT format documentation has been moved to
>> +`a separate project <https://fitspec.osfw.foundation/>`_. Updates to the
>> +format/specification should be submitted there.
>> \ No newline at end of file
> 


More information about the U-Boot mailing list