1. 07 Sep, 2017 1 commit
  2. 02 Aug, 2017 1 commit
  3. 10 Dec, 2016 4 commits
  4. 15 Jun, 2016 1 commit
  5. 04 May, 2016 3 commits
  6. 24 Mar, 2016 1 commit
  7. 14 Aug, 2015 1 commit
  8. 12 Jun, 2015 1 commit
  9. 06 May, 2015 1 commit
  10. 08 Jan, 2015 1 commit
  11. 18 Oct, 2014 1 commit
  12. 27 May, 2014 1 commit
  13. 01 Apr, 2014 1 commit
  14. 27 Feb, 2014 1 commit
  15. 25 Feb, 2014 1 commit
  16. 19 Feb, 2014 1 commit
    • Vadim Bendebury's avatar
      SD card support in SDHCI driver · 5b6ef73f
      Vadim Bendebury authored
      
      
      The SDHCI driver is being modified and refactored to support both eMMC
      and SD media. While debugging SD card operations it was discovered,
      that the host controller behaves differently when communicating with
      the SD cards.
      
      One of the fundamental differences between eMMC and SD is that SD
      cards allow arbitrary power of 2 block sizes for data transfers,
      whereas eMMC devices support only single fixed block size.
      
      Furthermore, even though the SDHCI controller specification describes
      the block count register as follows:
      
        "This register is enabled when Block Count Enable in the Transfer
         Mode register is set to 1 and is valid only for multiple block
         transfers."
      
      in reality. for single block SD card data transfers the controller
      Block Count register must be set to 1, if it is not - the following
      multiblock transfer times out.
      
      The CD card presence logic is modified to match Rambi hardware.
      
      BUG=chrome-os-partner:24396
      TEST=manual
          . with these modifications Rambi successfully boots from both eMMC
            and SD card.
      
      Change-Id: Ic58fd40c08802b72f15003f5c0fae2c4cc14ca7c
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/185890
      
      Reviewed-by: default avatarStefan Reinauer <reinauer@chromium.org>
      5b6ef73f
  17. 15 Feb, 2014 1 commit
    • Vadim Bendebury's avatar
      Add console command for storage debugging · b6d379aa
      Vadim Bendebury authored
      
      
      This adds a console command to aid in depthcharge storage subsystem
      debugging.
      
      The actual console command name is 'storage', it is further qualified
      by several subcommands:
      
        'init'
      
      Accepts no arguments, initializes storage subsystem, based on the set
      of block device controllers registered in the board initialization
      file.
      
        'show'
      
      Accepts no arguments, prints out the list of initialized devices with
      their name. Each device gets assigned a number, which is used as the
      reference by other storage subcommands.
      
      The 'default' device in the list is marked by the asterisk in the
      first column, after initialization device zero is the default device.
      This can be changed by the 'dev' subcommand.
      
       'dev'
      
      Accepts a single argument - the number of the device as reported by
      the 'show' command above. Future storage subcommands will operate on
      the device set by the 'dev' subcommand.
      
       'read <base blk> <num blks> <dest addr>'
      
      Read data from the default storage device, starting at block <base
      blk>, read <num blks> blocks total, placing result in memory at <dest
      addr>.
      
      BUG=chromium:338061
      TEST=manual
      
         rambi: sto init
         Added USB disk 4.
         *  0: SDHCI fixed
            1: USB disk 4
            2: SDHCI card
         3 devices total
         rambi: sto dev 1
         USB disk 4
         rambi: sto show
            0: SDHCI fixed
         *  1: USB disk 4
           2: SDHCI card
         3 devices total
         rambi: md.b 0x11000000
         11000000: fa 31 c0 8e d8 8e d0 bc 00 7c 89 e6 06 57 8e c0    .1.......|...W..
         11000010: fb fc bf 00 06 b9 00 01 f3 a5 ea 1f 06 00 00 52    ...............R
         11000020: 52 b4 41 bb aa 55 31 c9 30 f6 f9 cd 13 72 13 81    R.A..U1.0....r..
         11000030: fb 55 aa 75 0d d1 e9 73 09 66 c7 06 47 07 b4 42    .U.u...s.f..G..B
         rambi: sto read 0x5000 1 0x11000000
         rambi: md.b 0x11000000
         11000000: 43 48 52 4f 4d 45 4f 53 02 00 00 00 01 00 00 00    CHROMEOS........
         11000010: b8 04 00 00 00 00 00 00 a0 02 00 00 00 00 00 00    ................
         11000020: 00 02 00 00 00 00 00 00 78 02 00 00 00 00 00 00    ........x.......
         11000030: 48 02 00 00 00 00 00 00 40 00 00 00 00 00 00 00    H.......@.......
      
      Change-Id: Iae0ce3890999c91ae65f28c69c7441fb35b3fe09
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/184601
      
      Reviewed-by: default avatarStefan Reinauer <reinauer@chromium.org>
      b6d379aa
  18. 14 Jan, 2014 1 commit
  19. 04 Dec, 2013 2 commits
  20. 07 Nov, 2013 2 commits
    • Vadim Bendebury's avatar
      Add SDHCI ADMA support · 1172af42
      Vadim Bendebury authored
      
      
      This change adds support for Advanced DMA (ADMA), a feature available
      on contemporary SDHCI controllers. It is not conditionally compiled
      in, the capability is detected at run time and used if available.
      
      The implementation is following "SD Host Controller Simplified
      Specification, Version 3.00, February 25, 2011".
      
      Controllers supporting ADMA also support automated generation of the
      CMD12 (stop multiblock transfer) command. The mmc layer is being
      modified not to issue this command when SDHCI controller is used.
      
      BUG=chrome-os-partner:22580
      TEST=manual
      
        - tested on Rambi in depthcharge, initializing the controller and
          printing out an eMMC block
      
        - tested identical changes on Bayley Bay in u-boot, extensively
          reading and writing long blocks of data (including the complete
          kernel).
      
      Change-Id: I55f34e7dde118bd67ac6f53e46e0ce4775ec76ef
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/175987
      
      Reviewed-by: default avatarHung-Te Lin <hungte@chromium.org>
      1172af42
    • Vadim Bendebury's avatar
      sdhci: fix bugs introduced with the recent SDHCI driver addition · 57c3462b
      Vadim Bendebury authored
      
      
      Some code accessing hardware was inadvertently left behind in the
      new_...() function. Another problem is that host capabilities were not
      properly copied from the controller structure to the interface
      structure.
      
      While we are at it, also remove an unused field of the SdhciHost
      structure.
      
      BUG=chrome-os-partner:22580
      TEST=manual
        . tested with the upcoming patch applied, verified that SDHCI
          controller works.
      
      Change-Id: I329f13ff785de9aa7ed6dc1996f00784b0193eb3
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/176025
      
      Reviewed-by: default avatarHung-Te Lin <hungte@chromium.org>
      57c3462b
  21. 05 Nov, 2013 1 commit
    • Vadim Bendebury's avatar
      pci_sdhci: do not touch hardware in new_pci_sdhci_host · 824f9c00
      Vadim Bendebury authored
      
      
      To comply with depthcharge conventions, the interface new_XXX()
      function and functions it invokes are not supposed to touch the
      hardware. Modify the SDHCI controller driver to meet the requirement.
      
      src/drivers/storage/pci_sdhci.c:new_pci_sdhci_host() and
      src/drivers/storage/sdhci.c:add_sdhci() are being split into two
      parts, one running before after the update() method is called.
      
      The SdhciHost structure is enhanced to store the parameters and a new
      callback and PciSdhciHost structure is added to represent PCI based
      SDHCI interface.
      
      BUG=chrome-os-partner:22580
      TEST=manual
         . with some test code verified that the eMMC device is still
           accessible on Bayley bay and Rambi
      
      Change-Id: I9b9e8f7d9e9874fd6d7f83eddbfd2585dc0a8c0e
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/175560
      824f9c00
  22. 01 Nov, 2013 2 commits
    • Vadim Bendebury's avatar
      Integrate SDHCI driver into depthcharge. · 2e6b21fd
      Vadim Bendebury authored
      
      
      This change modifies the sdhci driver as follows:
      
        - drops unused SDMA code (the new controllers use ADMA, niot yet
          implemented).
        - modify structure names to match changes in depthcharge (camal case
          instead of underscores)
        - make new structure names match depthcharge coding style
        - account for different device/controllir/interface structures
          encapsulation
        - use modified constant names
        - bring in from u-boot a few missing functions
        - account for different driver API (add sdhci_update())
      
      This also adds a wrapper which discovers the PCI devices and calls
      the SDHCI entry point with it. This in fact violates depthcharge
      convention which requires that new_host...() functions do not touch
      hardware. This will be modified in an upcoming CL.
      
      BUG=chrome-os-partner:22580
      TEST=manual
        . with these changes, the upcoming board file change and a test
          modification of the main() function, the eMMC device gets
          initialized and allows to read the first sector of the kernel.
      
      Change-Id: I1ace24f0f4befe139670bb5d68b22104b489301d
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/175164
      
      Reviewed-by: default avatarHung-Te Lin <hungte@chromium.org>
      2e6b21fd
    • Vadim Bendebury's avatar
      Copy u-boot implementation of the SDHCI driver. · 41828cee
      Vadim Bendebury authored
      
      
      This is an as is copy of the ToT Chrome OS u-boot tree. This code
      obviously is not even attempted to be compiled.
      
      This copy will make examining the porting changes somewhat easier
      (albeit not much, as the previously copied u-boot code has been
      heavily modified both in structure and in style).
      
      BUG=chrome-os-partner:22580
      TEST=none
      
      Change-Id: I03f8ab816cf4afa0505b5c257f148fafd7afc862
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/175191
      
      Reviewed-by: default avatarGabe Black <gabeblack@chromium.org>
      41828cee