1. 12 11月, 2019 1 次提交
    • S
      binman: tegra: Adjust symbol calculation depending on end-at-4gb · 7c150136
      Simon Glass 提交于
      A recent change adjusted the symbol calculation to work on x86 but broke
      it for Tegra. In fact this is because they have different needs.
      
      On x86 devices the code is linked to a ROM address and the end-at-4gb
      property is used for the image. In this case there is no need to add the
      base address of the image, since the base address is already built into
      the offset and image-pos properties.
      
      On other devices we must add the base address since the offsets start at
      zero.
      
      In addition the base address is currently added to the 'offset' and 'size'
      values. It should in fact only be added to 'image-pos', since 'offset' is
      relative to its parent and 'size' is not actually an address. This code
      should have been adjusted when support for 'image-pos' and 'size' was
      added, but it was not.
      
      To correct these problems:
      - move the code that handles adding the base address to section.py, which
        can check the end-at-4gb property and which property
        (offset/size/image-pos) is being read
      - add the base address only when needed (only for image-pos and not if the
        image uses end-at-4gb)
      - add a note to the documentation
      - add a separate test to cover x86 behaviour
      
      Fixes: 15c981cc (binman: Correct symbol calculation with non-zero image base)
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      7c150136
  2. 02 11月, 2019 3 次提交
  3. 15 10月, 2019 17 次提交
  4. 29 7月, 2019 8 次提交
    • S
      binman: Add command-line support for replacing entries · a6cb9950
      Simon Glass 提交于
      Add a 'replace' command to binman to permit entries to be replaced, either
      individually or all at once (using a filter).
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      a6cb9950
    • S
      binman: Support replacing data in a cbfs · eb0f4a4c
      Simon Glass 提交于
      At present binman cannot replace data within a CBFS since it does not
      allow rewriting of the files in that CBFS. Implement this by using the
      new WriteData() method to handle the case.
      
      Add a header to compressed data so that the amount of compressed data can
      be determined without reference to the size of the containing entry. This
      allows the entry to be larger that the contents, without causing errors in
      decompression. This is necessary to cope with a compressed device tree
      being updated in such a way that it shrinks after the entry size is
      already set (an obscure case). It is not used with CBFS since it has its
      own metadata for this. Increase the number of passes allowed to resolve
      the position of entries, to handle this case.
      
      Add a test for this new logic.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      eb0f4a4c
    • S
      binman: Place Intel descriptor at image start · 27145fd3
      Simon Glass 提交于
      The Intel descriptor must always appear at the start of an (x86) image,
      so it is supposed to position itself there always. However there is no
      explicit test for this. Add one and fix a bug introduced by the recent
      change to adjust Entry to read the node in a separate call.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      27145fd3
    • S
      binman: Support shrinking a entry after packing · 61ec04f9
      Simon Glass 提交于
      Sometimes an entry may shrink after it has already been packed. In that
      case we must repack the items. Of course it is always possible to just
      leave the entry at its original size and waste space at the end. This is
      what binman does by default, since there is the possibility of the entry
      changing size every time binman calculates its contents, thus causing a
      loop.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      61ec04f9
    • S
      binman: Allow updating entries that change size · 51014aab
      Simon Glass 提交于
      So far we don't allow entries to change size when repacking. But this is
      not very useful since it is common for entries to change size after an
      updated binary is built, etc.
      
      Add support for this, respecting the original offset/size/alignment
      constraints of the image layout. For this to work the original image
      must have been created with the 'allow-repack' property.
      
      This does not support entry types with sub-entries such as files and
      CBFS, but it does support sections.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      51014aab
    • S
      binman: Add more tests for image header position · eba1f0cc
      Simon Glass 提交于
      The positioning does not currently work correctly if at the end of an
      image with no fixed size. Also if the header is in the middle of an image
      it can cause a gap in the image since the header position is normally at
      the image end, so entries after it are placed after the end of the image.
      
      Fix these problems and add more tests to cover these cases.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      eba1f0cc
    • S
      binman: Add info to allow safely repacking an image later · 12bb1a99
      Simon Glass 提交于
      At present it is not possible to discover the contraints to repacking an
      image (e.g. maximum section size) since this information is not preserved
      from the original image description.
      
      Add new 'orig-offset' and 'orig-size' properties to hold this. Add them to
      the main device tree in the image.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      12bb1a99
    • S
      binman: Support updating entries in an existing image · 10f9d006
      Simon Glass 提交于
      While it is useful and efficient to build images in a single pass from a
      unified description, it is sometimes desirable to update the image later.
      
      Add support for replace an existing file with one of the same size. This
      avoids needing to repack the file. Support for more advanced updates will
      come in future patches.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      10f9d006
  5. 25 7月, 2019 11 次提交