Skip to content
This project is mirrored from https://github.com/u-boot/u-boot.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
  1. Mar 13, 2015
    • Nishanth Menon's avatar
      ARM: Introduce erratum workaround for 430973 · 5902f4ce
      Nishanth Menon authored
      
      
      430973: Stale prediction on replaced inter working branch causes
      	Cortex-A8 to execute in the wrong ARM/Thumb state
      Impacts: Every Cortex-A8 processors with revision lower than r2p1
      Work around: Set IBE to 1
      
      Based on ARM errata Document revision 20.0 (13 Nov 2010)
      
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Tested-by: default avatarMatt Porter <mporter@konsulko.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      5902f4ce
    • Nishanth Menon's avatar
      ARM: Introduce erratum workaround for 454179 · b45c48a7
      Nishanth Menon authored
      
      
      454179: Stale prediction may inhibit target address misprediction on
      	next predicted taken branch
      Impacts: Every Cortex-A8 processors with revision lower than r2p1
      Work around:  Set IBE and disable branch size mispredict to 1
      
      Also provide a hook for SoC specific handling to take place if needed.
      
      Based on ARM errata Document revision 20.0 (13 Nov 2010)
      
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Tested-by: default avatarMatt Porter <mporter@konsulko.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      b45c48a7
    • Nishanth Menon's avatar
      ARM: Introduce erratum workaround for 798870 · c616a0df
      Nishanth Menon authored
      
      
      Add workaround for Cortex-A15 ARM erratum 798870 which says
      "If back-to-back speculative cache line fills (fill A and fill B) are
      issued from the L1 data cache of a CPU to the L2 cache, the second
      request (fill B) is then cancelled, and the second request would have
      detected a hazard against a recent write or eviction (write B) to the
      same cache line as fill B then the L2 logic might deadlock."
      
      Implementations for SoC families such as Exynos, OMAP5/DRA7 etc
      will be widely different.
      
      Every SoC has slightly different manner of setting up access to L2ACLR
      and similar registers since the Secure Monitor handling of Secure
      Monitor Call(smc) is diverse. Hence an weak function is introduced
      which may be overriden to implement SoC specific accessor implementation.
      
      Based on ARM errata Document revision 18.0 (22 Nov 2013)
      
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Tested-by: default avatarMatt Porter <mporter@konsulko.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      c616a0df
  2. Mar 06, 2015
  3. Mar 04, 2015
    • Simon Glass's avatar
      arm: spl: Allow board_init_r() to run with a larger stack · db910353
      Simon Glass authored
      
      
      At present SPL uses a single stack, either CONFIG_SPL_STACK or
      CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
      environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
      point into SDRAM. They then set up SDRAM very early, before board_init_f(),
      so that the larger stack can be used.
      
      This is an abuse of lowlevel_init(). That function should only be used for
      essential start-up code which cannot be delayed. An example of a valid use is
      when only part of the SPL code is visible/executable, and the SoC must be set
      up so that board_init_f() can be reached. It should not be used for SDRAM
      init, console init, etc.
      
      Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
      address before board_init_r() is called in SPL.
      
      The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README.
      
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      For version 1:
      Acked-by: default avatarAlbert ARIBAUD <albert.u.boot@aribaud.net>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      Tested-by: default avatarBo Shen <voice.shen@atmel.com>
      Acked-by: default avatarBo Shen <voice.shen@atmel.com>
      Acked-by: default avatarHeiko Schocher <hs@denx.de>
      Tested-by: default avatarHeiko Schocher <hs@denx.de>
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      db910353
    • Stephen Warren's avatar
      ARM: tegra: support running in non-secure mode · 73c38934
      Stephen Warren authored
      
      
      When the CPU is in non-secure (NS) mode (when running U-Boot under a
      secure monitor), certain actions cannot be taken, since they would need
      to write to secure-only registers. One example is configuring the ARM
      architectural timer's CNTFRQ register.
      
      We could support this in one of two ways:
      1) Compile twice, once for secure mode (in which case anything goes) and
         once for non-secure mode (in which case certain actions are disabled).
         This complicates things, since everyone needs to keep track of
         different U-Boot binaries for different situations.
      2) Detect NS mode at run-time, and optionally skip any impossible actions.
         This has the advantage of a single U-Boot binary working in all cases.
      
      (2) is not possible on ARM in general, since there's no architectural way
      to detect secure-vs-non-secure. However, there is a Tegra-specific way to
      detect this.
      
      This patches uses that feature to detect secure vs. NS mode on Tegra, and
      uses that to:
      
      * Skip the ARM arch timer initialization.
      
      * Set/clear an environment variable so that boot scripts can take
        different action depending on which mode the CPU is in. This might be
        something like:
        if CPU is secure:
          load secure monitor code into RAM.
          boot secure monitor.
          secure monitor will restart (a new copy of) U-Boot in NS mode.
        else:
          execute normal boot process
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      73c38934
  4. Feb 25, 2015
  5. Feb 24, 2015
  6. Feb 17, 2015
  7. Feb 07, 2015
  8. Jan 30, 2015
  9. Jan 29, 2015
  10. Jan 16, 2015
  11. Jan 05, 2015
  12. Dec 18, 2014
    • Thierry Reding's avatar
      ARM: Implement non-cached memory support · 1dfdd9ba
      Thierry Reding authored
      
      
      Implement an API that can be used by drivers to allocate memory from a
      pool that is mapped uncached. This is useful if drivers would otherwise
      need to do extensive cache maintenance (or explicitly maintaining the
      cache isn't safe).
      
      The API is protected using the new CONFIG_SYS_NONCACHED_MEMORY setting.
      Boards can set this to the size to be used for the non-cached area. The
      area will typically be right below the malloc() area, but architectures
      should take care of aligning the beginning and end of the area to honor
      any mapping restrictions. Architectures must also ensure that mappings
      established for this area do not overlap with the malloc() area (which
      should remain cached for improved performance).
      
      While the API is currently only implemented for ARM v7, it should be
      generic enough to allow other architectures to implement it as well.
      
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      1dfdd9ba
    • Thierry Reding's avatar
      ARM: Implement non-cached memory support · ed710457
      Thierry Reding authored
      
      
      Implement an API that can be used by drivers to allocate memory from a
      pool that is mapped uncached. This is useful if drivers would otherwise
      need to do extensive cache maintenance (or explicitly maintaining the
      cache isn't safe).
      
      The API is protected using the new CONFIG_SYS_NONCACHED_MEMORY setting.
      Boards can set this to the size to be used for the non-cached area. The
      area will typically be right below the malloc() area, but architectures
      should take care of aligning the beginning and end of the area to honor
      any mapping restrictions. Architectures must also ensure that mappings
      established for this area do not overlap with the malloc() area (which
      should remain cached for improved performance).
      
      While the API is currently only implemented for ARM v7, it should be
      generic enough to allow other architectures to implement it as well.
      
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      ed710457
    • Steve Rae's avatar
      fastboot: handle flash write to GPT partitions · 0ff7e585
      Steve Rae authored
      
      
      Implement a feature to allow fastboot to write the downloaded image
      to the space reserved for the Protective MBR and the Primary GUID
      Partition Table.
      Additionally, prepare and write the Backup GUID Partition Table.
      
      Signed-off-by: default avatarSteve Rae <srae@broadcom.com>
      Tested-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      [Test HW: Exynos4412 - Trats2]
      0ff7e585
  13. Dec 08, 2014
  14. Dec 05, 2014
  15. Dec 04, 2014
  16. Nov 23, 2014
    • Masahiro Yamada's avatar
      hush: add CONFIG_HUSH_PARSER to Kconfig · 6c775090
      Masahiro Yamada authored
      
      
      The README file states that the macros beginning with "CONFIG_SYS_"
      depend on the hardware etc. and should not be meddled with if you do
      not what you're doing.
      We have already screwed up with this policy; we have given the prefix
      "CONFIG_SYS_" to many user-selectable configurations.
      Here, "CONFIG_SYS_HUSH_PARSER" is one of them.  Users can enable it
      if they want to use a more powerful command line parser, or disable it
      if they only need a simple one.
      
      This commit attempts to rename CONFIG_SYS_HUSH_PARSER to
      CONFIG_HUSH_PARSER and move it to Kconfig.
      
      Every board maintainer is expected to enable CONFIG_HUSH_PARSER
      (= add "CONFIG_HUSH_PARSER=y" to his defconfig file) and remove
      "#define CONFIG_SYS_HUSH_PARSER" from his header file.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      6c775090
    • Christian Gmeiner's avatar
      fs: make it possible to read the filesystem UUID · 59e890ef
      Christian Gmeiner authored
      
      
      Some filesystems have a UUID stored in its superblock. To
      allow using root=UUID=... for the kernel command line we
      need a way to read-out the filesystem UUID.
      
      changes rfc -> v1:
       - make the environment variable an option parameter. If not
         given, the UUID is printed out. If given, it is stored in the env
         variable.
       - corrected typos
       - return error codes
      
      changes v1 -> v2:
       - fix return code of do_fs_uuid(..)
       - document do_fs_uuid(..)
       - implement fs_uuid_unsuported(..) be more consistent with the
         way other optional functionality works
      
      changes v2 -> v3:
       - change ext4fs_uuid(..) to make use of #if .. #else .. #endif
         construct to get rid of unreachable code
      
      Hit any key to stop autoboot:  0
      => fsuuid
      fsuuid - Look up a filesystem UUID
      
      Usage:
      fsuuid <interface> <dev>:<part>
          - print filesystem UUID
      fsuuid <interface> <dev>:<part> <varname>
          - set environment variable to filesystem UUID
      
      => fsuuid mmc 0:1
      d9f9fc05-45ae-4a36-a616-fccce0e4f887
      => fsuuid mmc 0:2
      eb3db83c-7b28-499f-95ce-9e0bb21cda81
      => fsuuid mmc 0:1 uuid1
      => fsuuid mmc 0:2 uuid2
      => printenv uuid1
      uuid1=d9f9fc05-45ae-4a36-a616-fccce0e4f887
      => printenv uuid2
      uuid2=eb3db83c-7b28-499f-95ce-9e0bb21cda81
      =>
      
      Signed-off-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      59e890ef
  17. Nov 21, 2014
  18. Nov 17, 2014
  19. Nov 07, 2014
  20. Oct 27, 2014
  21. Oct 23, 2014
  22. Oct 22, 2014
  23. Oct 16, 2014
  24. Sep 25, 2014
    • York Sun's avatar
      driver/ddr: Restruct driver to allow standalone memory space · 1d71efbb
      York Sun authored
      
      
      U-boot has been initializing DDR for the main memory. The presumption
      is the memory stays as a big continuous block, either linear or
      interleaved. This change is to support putting some DDR controllers
      to separated space without counting into main memory. The standalone
      memory controller could use different number of DIMM slots.
      
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
      1d71efbb
  25. Sep 24, 2014
  26. Sep 23, 2014
  27. Sep 21, 2014
  28. Aug 30, 2014
    • Tom Rini's avatar
      cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images · d2b2ffe3
      Tom Rini authored
      
      
      The default format for arm64 Linux kernels is the "Image" format,
      described in Documentation/arm64/booting.txt.  This, along with an
      optional gzip compression on top is all that is generated by default.
      The Image format has a magic number within the header for verification,
      a text_offset where the Image must be run from, an image_size that
      includes the BSS and reserved fields.
      
      This does not support automatic detection of a gzip compressed image.
      
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      d2b2ffe3
  29. Aug 25, 2014
    • Heiko Schocher's avatar
      mtd, ubi, ubifs: resync with Linux-3.14 · ff94bc40
      Heiko Schocher authored
      
      
      resync ubi subsystem with linux:
      
      commit 455c6fdbd219161bd09b1165f11699d6d73de11c
      Author: Linus Torvalds <torvalds@linux-foundation.org>
      Date:   Sun Mar 30 20:40:15 2014 -0700
      
          Linux 3.14
      
      A nice side effect of this, is we introduce UBI Fastmap support
      to U-Boot.
      
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Sergey Lapin <slapin@ossfans.org>
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Joerg Krause <jkrause@posteo.de>
      ff94bc40
Loading