1. 24 Jan, 2021 1 commit
  2. 23 Jan, 2021 18 commits
  3. 22 Jan, 2021 8 commits
    • Martin Hundebøll's avatar
      tools: env: return error if ubi_update_start() fails · 09779488
      Martin Hundebøll authored
      The UBI_IOCVOLUP ioctl can fail if exclusive access to the volume isn't
      obtained. If this happens, the flush operation doesn't return error,
      leaving the caller without knowledge of missing flush.
      Fix this by forwarding the error (-1) from ubi_update_start().
      Fixes: 34255b92 ("tools: env: Add support for direct read/write UBI volumes")
      Signed-off-by: default avatarMartin Hundebøll <martin@geanix.com>
    • Joel Stanley's avatar
      mkimage: Move padding commands outside of FIT_SIGNATURE · 603e26f7
      Joel Stanley authored
      These commands were disabled when CONFIG_FIT_SIGNATURE is disabled, but
      they do not depend on crypto support so they can be unconditionally
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
    • Joel Stanley's avatar
      image-fit: Fix FIT_CIPHER linking · 93af80f3
      Joel Stanley authored
      When CONFIG_FIT_CIPHER=y and CONFIG_FIT_SIGNATURE=n is there is no
      implementation of image_get_host_blob for mkimage/dumpimage:
       /usr/bin/ld: tools/common/image-cipher.o: in function `fit_image_decrypt_data':
       image-cipher.c:(.text+0x9a): undefined reference to `image_get_host_blob'
      Move the implementation to a common file so it can be shaed between
      image-cipher.c and image-fit-sig.c.
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
    • Joel Stanley's avatar
      tools/Makefile: FIT_CIPHER requires libssl · 5d40d5f1
      Joel Stanley authored
      If CONFIG_FIT_CIPHER is enabled without CONFIG_FIT_SIGNATURE then
      mkimage/dumpimage will fail to link:
       /usr/bin/ld: tools/common/image-cipher.o: in function `fit_image_decrypt_data':
       image-cipher.c:(.text+0x9a): undefined reference to `image_get_host_blob'
       /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x10): undefined reference to `EVP_aes_128_cbc'
       /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x40): undefined reference to `EVP_aes_192_cbc'
       /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x70): undefined reference to `EVP_aes_256_cbc'
       /usr/bin/ld: tools/lib/aes/aes-encrypt.o: in function `image_aes_encrypt':
       aes-encrypt.c:(.text+0x22): undefined reference to `EVP_CIPHER_CTX_new'
       /usr/bin/ld: aes-encrypt.c:(.text+0x6f): undefined reference to `EVP_EncryptInit_ex'
       /usr/bin/ld: aes-encrypt.c:(.text+0x8d): undefined reference to `EVP_EncryptUpdate'
       /usr/bin/ld: aes-encrypt.c:(.text+0xac): undefined reference to `EVP_CIPHER_CTX_free'
       /usr/bin/ld: aes-encrypt.c:(.text+0xf2): undefined reference to `EVP_EncryptFinal_ex'
       collect2: error: ld returned 1 exit status
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
    • Philippe Reynes's avatar
      tools: image-host: add support for several sub-images · edfeba75
      Philippe Reynes authored
      The propoerty sign-images points to images in the configuration
      node. But thoses images may references severals "sub-images" (for
      example for images loadable). This commit adds the support of
      severals sub-images.
      Signed-off-by: default avatarPhilippe Reynes <philippe.reynes@softathome.com>
    • Philippe Reynes's avatar
      tools: image-host: clean function fit_config_get_hash_list · 5a4116f1
      Philippe Reynes authored
      This commit creates a function fit_config_add_hash that will be
      used in the next commit to support several 'sub-images'.
      Signed-off-by: default avatarPhilippe Reynes <philippe.reynes@softathome.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
    • Alexandru Gagniuc's avatar
      doc: FIT image: Clarify format and simplify syntax · 4afc4f37
      Alexandru Gagniuc authored
      ** 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>
    • Tom Rini's avatar
  4. 21 Jan, 2021 11 commits
  5. 20 Jan, 2021 2 commits