Skip to content
  • Alexandru Gagniuc's avatar
    doc: FIT image: Clarify format and simplify syntax · 4afc4f37
    Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
    
    
    ** Introduction
    
    There are currently four ways to load an OS image with u-boot
      1. SPL -> u-boot -> bootm
      2. SPL blue falcon mode
      3. "Basic" FIT image (CONFIG_LOAD_FIT)
      4. "Full-featured" FIT image (CONFIG_LOAD_FIT_FULL)
    
    These four code paths were developed independently, and share very
    little code. (3) and (4), behave very differently, are littered with
    special cases. They even have different DTS syntax and properties.
    
    The cause of this divergence is that the FIT format specification
    leaves a number of things open to interpretation. The purpose of this
    change is to enable the reduction of code size, duplication, and
    complexity by updating and streamlining the FIT format.
    
    We are only marginally concerned with backwards compatibility, because
    we don't have inter-compatibility. For example, CONFIG_LOAD_FIT is
    able to load images that CONFIG_LOAD_FIT_FULL won't. This is a direct
    result of the incompatible syntax between the two implementations.
    
    Ideally, these changes would enable "simple" FIT to be a subset of the
    "full" fit implementation, and share most code. These changes should
    also eliminate the need for falcon mode (although we are not
    advocating for the removal of falcon mode at this time).
    
    ** Description of changes
    
     * The "configurations" node is now mandatory
    
    Guessing how to load components based on their "os" and "type" invites
    confusion and superfluous heuristics. Instead, require each FIT image
    to be explicit on how components should be loaded.
    
     * Eliminate "ramdisk", "setup", "standalone", and "fpga" properties
    
    Having too many special purpose properties requires special-casing
    FIT loading code. When a special property can be handled by another
    property, it is redundant.
     - A "ramdisk" is identical to a loadable. Thus ramdisk images should
       be placed under "loadables".
     - A "setup" node can be achieved by using a "kernel" or "firmware"
       property instead.
     - "standalone" is used for u-boot nodes. The correct property to use
       in this case is "firmware".
     - "fpga" is a loadable
    
     * Prioritize control between "firmware" and "kernel"
    
    "firmware" and "kernel" are special nodes in that control is passed
    to the "entry-point" of the image. Both can be present, for example,
    an OP-TEE firmware with a linux kernel. When both are present,
    control is passed to the "firmware" image.
    
    ** Further generalizations (not included herein)
    
    The "firmware" and "kernel" properties could be generalized as a
    "next-boot-stage", or similar name. This "next" stage would be special
    in that it is both executable, and is the stage that is passed
    control. For example, "next-stage" could be an op-tee image, with
    linux as a loadable, or a u-boot image.
    
    Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
    4afc4f37