1. 09 May, 2014 2 commits
  2. 18 Apr, 2014 2 commits
  3. 22 Mar, 2014 1 commit
    • Simon Glass's avatar
      patman: Use Patch-cc: instead of Cc: · 659c89da
      Simon Glass authored
      Add a new Patch-cc: tag which performs the service now provided by
      the Cc: tag. The Cc: tag is interpreted by git send-email but
      ignored by patman.
      So now:
        Cc: patman does nothing. (git send-email can cc patches)
        Patch-cc: patman Cc's patch and removes this tag from the patch
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  4. 21 Mar, 2014 5 commits
  5. 12 Mar, 2014 3 commits
    • Masahiro Yamada's avatar
      kbuild: rename SRCTREE to srctree · 01286329
      Masahiro Yamada authored
      Prior to Kbuild, $(TOPDIR) or $(SRCTREE) was used for
      pointing to the top of source directory.
      (No difference between the two.)
      In Kbuild style, $(srctree) is used for instead.
      This commit renames SRCTREE to srctree and deletes the
      defition of SRCTREE.
      Note that SRCTREE in scripts/kernel-doc, scripts/docproc.c,
      doc/DocBook/Makefile should be keep.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
    • Dustin Byford's avatar
      fw_env: correct writes to devices with small erase blocks · 4b774ff1
      Dustin Byford authored
      Some NOR flash devices have a small erase block size.  For example, the
      Micron N25Q512 can erase in 4K blocks.  These devices expose a bug in
      fw_env.c where flash_write_buf() incorrectly calculates bytes written
      and attempts to write past the environment sectors.  Luckily, a range
      check prevents any real damage, but this does cause fw_setenv to fail
      with an error.
      This change corrects the write length calculation.
      The bug was introduced with commit 56086921
       from 2008 and only affects
      configurations where the erase block size is smaller than the total
      environment data size.
      Signed-off-by: default avatarDustin Byford <dustin@cumulusnetworks.com>
    • Dustin Byford's avatar
      fw_env: calculate default number of env sectors · 23869bf8
      Dustin Byford authored
      The assumed number of environment sectors (always 1) leads to an
      incorrect top_of_range calculation in fw.env.c when a flash device has
      an erase block size smaller than the environment data size (number of
      environment sectors > 1).
      This change updates the default number of environment sectors to at
      least cover the size of the environment.
      Also corrected a false statement about the number of sectors column in
      Signed-off-by: default avatarDustin Byford <dustin@cumulusnetworks.com>
  6. 04 Mar, 2014 2 commits
  7. 25 Feb, 2014 1 commit
    • Masahiro Yamada's avatar
      kbuild: move asm-offsets.h rules to ./Kbuild · 6a44d806
      Masahiro Yamada authored
      Generate include/generated/generic-asm-offsets.h and
      include/generated/asm-offsets.h in ./Kbuild.
      This commit also changes the include guard.
      Before this commit, __ASM_OFFSETS_H__ was used for both of them.
      So we could not include generic-asm-offsets.h and asm-offsets.h
      at the same time.
      This commit renames the include guard of the former to
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
  8. 19 Feb, 2014 9 commits
  9. 13 Feb, 2014 1 commit
  10. 24 Jan, 2014 2 commits
  11. 20 Jan, 2014 1 commit
  12. 09 Jan, 2014 1 commit
    • Scott Wood's avatar
      arm64: Add tool to statically apply RELA relocations · 8137af19
      Scott Wood authored
      ARM64 uses the newer RELA-style relocations rather than the older REL.
      RELA relocations have an addend in the relocation struct, rather than
      expecting the loader to read a value from the location to be updated.
      While this is beneficial for ordinary program loading, it's problematic
      for U-Boot because the location to be updated starts out with zero,
      rather than a pre-relocation value.  Since we need to be able to run C
      code before relocation, we need a tool to apply the relocations at
      build time.
      In theory this tool is applicable to other newer architectures (mainly
      64-bit), but currently the only relocations it supports are for arm64,
      and it assumes a 64-bit little-endian target.  If the latter limitation
      is ever to be changed, we'll need a way to tell the tool what format
      the image is in.  Eventually this may be replaced by a tool that uses
      libelf or similar and operates directly on the ELF file.  I've written
      some code for such an approach but libelf does not make it easy to poke
      addresses by memory address (rather than by section), and I was
      hesitant to write code to manually parse the program headers and do the
      update outside of libelf (or to iterate over sections) -- especially
      since it wouldn't get test coverage on things like binaries with
      multiple PT_LOAD segments.  This should be good enough for now to let
      the manual relocation stuff be removed from the arm64 patches.
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      Signed-off-by: default avatarDavid Feng <fenghua@phytium.com.cn>
  13. 30 Dec, 2013 2 commits
  14. 17 Dec, 2013 1 commit
    • Marek Vasut's avatar
      ARM: mxs: tools: Fix errno handling in strtoul() invocation · 5b5a82eb
      Marek Vasut authored
      According to NOTE in strtoul(3), the errno must be zeroed before strtoul()
      is called. Zero the errno. The NOTE reads as such:
        Since strtoul() can legitimately return 0 or ULONG_MAX (ULLONG_MAX for
        strtoull()) on both success and failure, the calling program should set
        errno  to  0  before the call, and then determine if an error occurred
        by checking whether errno has a nonzero value after the call.
      This issue was detected on Fedora 19 with glibc 2.17 .
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Tom Rini <trini@ti.com>
  15. 16 Dec, 2013 1 commit
  16. 13 Dec, 2013 4 commits
    • Masahiro Yamada's avatar
      Makefile: Move some scripts imported from Linux · dd88ab32
      Masahiro Yamada authored
      We have some scripts imported from Linux Kernel:
      setlocalversion, checkstack.pl, checkpatch.pl, cleanpatch
      They are located under tools/ directory in U-Boot now.
      But they were originally located under scripts/ directory
      in Linux Kernel.
      This commit moves them to the original location.
      It is true that binutils-version.sh and dtc-version.sh
      do not originate in Linux Kernel, but they should
      be moved by analogy to gcc-version.sh.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
    • Guilherme Maciel Ferreira's avatar
      Add dumpimage, a tool to extract data from U-Boot images · a804b5ce
      Guilherme Maciel Ferreira authored
      Given a multi-file image created through the mkimage's -d option:
        $ mkimage -A x86 -O linux -T multi -n x86 -d vmlinuz:initrd.img:System.map \
        Image Name:   x86
        Created:      Thu Jul 25 10:29:13 2013
        Image Type:   Intel x86 Linux Multi-File Image (gzip compressed)
        Data Size:    13722956 Bytes = 13401.32 kB = 13.09 MB
        Load Address: 00000000
        Entry Point:  00000000
           Image 0: 4040128 Bytes = 3945.44 kB = 3.85 MB
           Image 1: 7991719 Bytes = 7804.41 kB = 7.62 MB
           Image 2: 1691092 Bytes = 1651.46 kB = 1.61 MB
      It is possible to perform the innverse operation -- extracting any file from
      the image -- by using the dumpimage's -i option:
        $ dumpimage -i multi.img -p 2 System.map
      Although it's feasible to retrieve "data files" from image through scripting,
      the requirement to embed tools such 'dd', 'awk' and 'sed' for this sole purpose
      is cumbersome and unreliable -- once you must keep track of file sizes inside
      the image. Furthermore, extracting data files using "dumpimage" tool is faster
      than through scripting.
      Signed-off-by: default avatarGuilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Guilherme Maciel Ferreira's avatar
      tools: moved code common to all image tools to a separated module. · f86ed6a8
      Guilherme Maciel Ferreira authored
      In order to avoid duplicating code and keep only one point of modification,
      the functions, structs and defines useful for "dumpimage" were moved from
      "mkimage" to a common module called "imagetool".
      This modification also weakens the coupling between image types (FIT, IMX, MXS,
      and so on) and image tools (mkimage and dumpimage). Any tool may initialize the
      "imagetool" through register_image_tool() function, while the image types
      register themselves within an image tool using the register_image_type()
                                                     +------|   fit_image   |
       +--------------+          +-----------+       |      +---------------+
       |    mkimage   |--------> |           | <-----+
       +--------------+          |           |              +---------------+
                                 | imagetool | <------------|    imximage   |
       +--------------+          |           |              +---------------+
       |  dumpimage   |--------> |           | <-----+
       +--------------+          +-----------+       |      +---------------+
                                                     +------| default_image |
                register_image_tool()           register_image_type()
      Also, the struct "mkimage_params" was renamed to "image_tool_params" to make
      clear its general purpose.
      Signed-off-by: default avatarGuilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Guilherme Maciel Ferreira's avatar
  17. 25 Nov, 2013 2 commits