1. 20 Oct, 2013 2 commits
  2. 07 Oct, 2013 1 commit
  3. 20 Sep, 2013 1 commit
  4. 28 Aug, 2013 1 commit
  5. 26 Aug, 2013 1 commit
  6. 19 Aug, 2013 1 commit
    • Wolfgang Denk's avatar
      SPDX-License-Identifier: fixing some problematic GPL-2.0 files · bcd4d4eb
      Wolfgang Denk authored
      
      
      Unlike the other patches in this series so far, this commit fixes a
      ambiguity in the license terms for some OMAP files:  the code was
      originally derived from the Linux kernel sources, where it was clearly
      marked as GPL-2.0 (i. e. without the "or later" part), but the U-Boot
      version had a GPL-2.0+ file header added, apparently without
      permission / relicensing from the original authors of the code.
      
      Insert a GPL-2.0 SPDX-License-Identifier to fix this.
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      cc: Tom Rix <Tom.Rix@windriver.com>
      Cc: Tom Rini <trini@ti.com>
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      Acked-by: default avatarTom Rini <trini@ti.com>
      bcd4d4eb
  7. 26 Jul, 2013 1 commit
  8. 24 Jul, 2013 1 commit
  9. 02 Jul, 2013 1 commit
  10. 10 Jun, 2013 14 commits
  11. 06 Jun, 2013 1 commit
    • Tom Rini's avatar
      am33xx/omap4+: Move SRAM_SCRATCH_SPACE_ADDR to <asm/arch/omap.h> · edfcf85a
      Tom Rini authored
      
      
      The location of valid scratch space is dependent on SoC, so move that
      there.  On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR.  On
      am33xx/ti814x we want to use what the ROM defines as "public stack"
      which is the area after our defined download image space.  Correct the
      comment about and location of CONFIG_SPL_TEXT_BASE.
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      edfcf85a
  12. 05 Jun, 2013 1 commit
  13. 10 May, 2013 6 commits
    • SRICHARAN R's avatar
      ARM: OMAP: Cleanup boot parameters usage · 4a0eb757
      SRICHARAN R authored
      
      
      The boot parameters are read from individual variables
      assigned for each of them. This been corrected and now
      they are stored as a part of the global data 'gd'
      structure. So read them from 'gd' instead.
      Signed-off-by: default avatarSricharan R <r.sricharan@ti.com>
      [trini: Add igep0033 hunk]
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      4a0eb757
    • SRICHARAN R's avatar
      ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common · f92f2277
      SRICHARAN R authored
      
      
      These defines are same across OMAP4/5. So move them to
      omap_common.h. This is required for the patches that
      follow.
      Signed-off-by: default avatarSricharan R <r.sricharan@ti.com>
      f92f2277
    • SRICHARAN R's avatar
      ARM: OMAP: Make omap_boot_parameters common across socs · 76db5b8f
      SRICHARAN R authored
      
      
      omap_boot_parameters is same and defined for each
      soc. So move this to a common place to reuse it
      across socs.
      Signed-off-by: default avatarSricharan R <r.sricharan@ti.com>
      76db5b8f
    • Lokesh Vutla's avatar
      ARM: OMAP5: Fix warm reset with USB cable connected · 0b1b60c7
      Lokesh Vutla authored
      
      
      Warm reset on OMAP5 freezes when USB cable is connected.
      Fix requires PRM_RSTTIME.RSTTIME1 to be programmed
      with the time for which reset should be held low for the
      voltages and the oscillator to reach stable state.
      
      There are 3 parameters to be considered for calculating
      the time, which are mostly board and PMIC dependent.
      -1- Time taken by the Oscillator to shut + restart
      -2- PMIC OTP times
      -3- Voltage rail ramp times, which inturn depends on the
      PMIC slew rate and value of the voltage ramp needed.
      
      In order to keep the code in u-boot simple, have a way
      for boards to specify a pre computed time directly using
      the 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'
      option. If boards fail to specify the time, use a default
      as specified by 'CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC' instead.
      Using the default value translates into some ~22ms and should work in
      all cases.
      However in order to avoid this large delay hiding other bugs,
      its recommended that all boards look at their respective data
      sheets and specify a pre computed and optimal value using
      'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'
      
      In order to help future board additions to compute this
      config option value, add a README at doc/README.omap-reset-time
      which explains how to compute the value. Also update the toplevel
      README with the additional option and pointers to
      doc/README.omap-reset-time.
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      [rnayak@ti.com: Updated changelog and added the README]
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      0b1b60c7
    • Lubomir Popov's avatar
      OMAP5: I2C: Set I2C_BUS_MAX to 5 to enable I2C4 and I2C5 · 2335b653
      Lubomir Popov authored
      
      
      I2C4 and I2C5 are utilized on all known OMAP5 hardware platforms.
      In order to be able to select one of these buses however, I2C_BUS_MAX
      has to be set to 5; do this here.
      
      Please note that for working bus selection, a fix to the i2c driver
      is required as well (subject of a separate patch).
      Signed-off-by: default avatarLubomir Popov <lpopov@mm-sol.com>
      2335b653
    • Lubomir Popov's avatar
      OMAP5: I2C: Add I2C4 and I2C5 bases · aebe7ff2
      Lubomir Popov authored
      
      
      I2C4 and I2C5 are utilized on all known OMAP5 hardware platforms.
      The I2C4 and I2C5 base addresses were however not defined; do this
      here.
      Signed-off-by: default avatarLubomir Popov <lpopov@mm-sol.com>
      aebe7ff2
  14. 08 Apr, 2013 2 commits
    • Tom Rini's avatar
      OMAP3/4/5/AM33xx: Correct logic for checking FAT or RAW MMC · c3d2c24f
      Tom Rini authored
      
      
      In the case of booting from certain peripherals, such as UART, we must
      not see what the device descriptor says for RAW or FAT mode because in
      addition to being nonsensical, it leads to a hang.  This is why we have
      a test currently for the boot mode being within range.  The problem
      however is that on some platforms we get MMC2_2 as the boot mode and not
      the defined value for MMC2, and in others we get the value for MMC2_2.
      This is required to fix eMMC booting on omap5_uevm.
      
      Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on
      classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC).
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      c3d2c24f
    • Lokesh Vutla's avatar
      arm: omap4: Fix SDRAM AUTO DETECTION · d3d82e9f
      Lokesh Vutla authored
      Commit "86021143
      
       omap: emif: configure emif only when required"
      breaks SDRAM_AUTO_DETECTION.
      The issue is dmm_init() depends on emif_sizes[](SDRAM Auto detection)
      done in do_sdram_init(). The above commit moves dmm_init() above
      do_sdram_init() because of which dmm_init() uses uninitialized
      emif_sizes[].
      So instead of using global emif_sizes[], get sdram details locally
      and calculate emif sizes.
      Reported-by: default avatarMichael Cashwell <mboards@prograde.net>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      d3d82e9f
  15. 11 Mar, 2013 6 commits