Skip to content
Snippets Groups Projects
  1. Aug 31, 2014
  2. Aug 30, 2014
  3. Aug 29, 2014
  4. Aug 25, 2014
    • Lokesh Vutla's avatar
      ARM: DRA: Enable VTT regulator · 7b922523
      Lokesh Vutla authored
      
      DRA7 evm REV G and later boards uses a vtt regulator for DDR3 termination
      and this is controlled by gpio7_11. Configuring gpio7_11.
      The pad A22(offset 0x3b4) is used by gpio7_11 on REV G and later boards,
      and left unused on previous boards, so it is safe enough to enable gpio
      on all DRA7 boards.
      
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      7b922523
    • Sricharan R's avatar
      ARM: DRA7: Enable software leveling for dra7 · f2a1b93b
      Sricharan R authored
      
      Currently hw leveling is enabled by default on DRA7/72.
      But the hardware team suggested to use sw leveling as hw leveling
      is not characterized and seen some test case failures.
      So enabling sw leveling on all DRA7 platforms.
      
      Signed-off-by: default avatarSricharan R <r.sricharan@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      f2a1b93b
    • Vitaly Andrianov's avatar
      keystone2: use EFUSE_BOOTROM information to configure PLLs · 61f66fd5
      Vitaly Andrianov authored
      
      This patch reads EFUSE_BOOTROM register to see the maximum supported
      clock for CORE and TETRIS PLLs and configure them accordingly.
      
      Acked-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarVitaly Andrianov <vitalya@ti.com>
      Signed-off-by: default avatarIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
      61f66fd5
    • pekon gupta's avatar
      board/ti/dra7xx: add support for parallel NOR · 9352697a
      pekon gupta authored
      This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
      The Flash device is connected to GPMC controller on chip-select[0] and accessed
      as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
      is CFI compatible.
      
      As multiple devices are share GPMC pins on this board, so following board
      settings are required to detect NOR device:
           SW5.1 (NAND_BOOTn) = OFF (logic-1)
           SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
           SW5.3 (eMMC_BOOTn) = OFF (logic-1)
           SW5.4 (QSPI_BOOTn) = OFF (logic-1)
      
      And also set appropriate SYSBOOT configurations:
           SW3.1 (SYSBOOT[ 8])= ON  (logic-1) /* selects SYS_CLK1 speed */
           SW3.2 (SYSBOOT[ 9])= OFF (logic-0) /* selects SYS_CLK1 speed */
           SW3.3 (SYSBOOT[10])= ON  (logic-1) /* wait-pin monitoring = enabled */
           SW3.4 (SYSBOOT[11])= OFF (logic-0) /* device type: Non Muxed */
           SW3.5 (SYSBOOT[12])= OFF (logic-0) /* device type: Non Muxed */
           SW3.6 (SYSBOOT[13])= ON  (logic-1) /* device bus-width: 1(x16) */
           SW3.7 (SYSBOOT[14])= OFF (logic-0) /* reserved */
           SW3.8 (SYSBOOT[15])= ON  (logic-1) /* reserved */
      
      Also, following changes are required to enable NOR Flash support in
      dra7xx_evm board profile:
      9352697a
  5. Aug 21, 2014
  6. Aug 20, 2014
  7. Aug 19, 2014
  8. Aug 18, 2014
  9. Aug 13, 2014
  10. Aug 12, 2014
    • Siarhei Siamashka's avatar
      sunxi: dram: Autodetect DDR3 bus width and density · bf4ca384
      Siarhei Siamashka authored
      
      In the case if the 'dram_para' struct does not specify the exact bus
      width or chip density, just use a trial and error method to find a
      usable configuration.
      
      Because all the major bugs in the DRAM initialization sequence are
      now hopefully fixed, it should be safe to re-initialize the DRAM
      controller multiple times until we get it configured right. The
      original Allwinner's boot0 bootloader also used a similar
      autodetection trick.
      
      The DDR3 spec contains the package pinout and addressing table for
      different possible chip densities. It appears to be impossible to
      distinguish between a single chip with 16 I/O data lines and a pair
      of chips with 8 I/O data lines in the case if they provide the same
      storage capacity. Because a single 16-bit chip has a higher density
      than a pair of equivalent 8-bit chips, it has stricter refresh timings.
      So in the case of doubt, we assume that 16-bit chips are used.
      Additionally, only Allwinner A20 has all A0-A15 address lines and
      can support densities up to 8192. The older Allwinner A10 and
      Allwinner A13 can only support densities up to 4096.
      
      We deliberately leave out DDR2, dual-rank configurations and the
      special case of a 8-bit chip with density 8192. None of these
      configurations seem to have been ever used in real devices. And no
      new devices are likely to use these exotic configurations (because
      only up to 2GB of RAM can be populated in any case).
      
      This DRAM autodetection feature potentially allows to have a single
      low performance fail-safe DDR3 initialiazation for a universal single
      bootloader binary, which can be compatible with all Allwinner
      A10/A13/A20 based devices (if the ifdefs are replaced with a runtime
      SoC type detection).
      
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      bf4ca384
    • Siarhei Siamashka's avatar
      sunxi: dram: Derive write recovery delay from DRAM clock speed · 935758b1
      Siarhei Siamashka authored
      
      The write recovery time is 15ns for all JEDEC DDR3 speed bins. And
      instead of hardcoding it to 10 cycles, it is possible to set tighter
      timings based on accurate calculations. For example, DRAM clock
      frequencies up to 533MHz need only 8 cycles for write recovery.
      
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      935758b1
Loading