1. 05 Apr, 2017 1 commit
    • Peng Fan's avatar
      MLK-12883 usb: limit USB_MAX_XFER_BLK to 256 · 0716cc14
      Peng Fan authored
      For Some USB mass storage devices, such as:
      "
       - Kingston DataTraveler 2.0 001D7D06CF09B04199C7B3EA
       - Class: (from Interface) Mass Storage
       - PacketSize: 64  Configurations: 1
       - Vendor: 0x0930  Product 0x6545 Version 1.16
      "
      When `usb read 0x80000000 0 0x2000`, we met
      "EHCI timed out on TD - token=0x80008d80".
      
      The devices does not support scsi VPD page, we are not able
      to get the maximum transfer length for READ(10)/WRITE(10).
      
      So we limit this to 256 blocks as READ(6).
      Signed-off-by: default avatarPeng Fan <peng.fan@nxp.com>
      (cherry picked from commit df0052575b2bc9d66ae73584768e1a457ed5d914)
      0716cc14
  2. 17 Jan, 2017 1 commit
  3. 23 Sep, 2016 1 commit
  4. 17 May, 2016 3 commits
  5. 22 Mar, 2016 2 commits
  6. 14 Mar, 2016 6 commits
  7. 21 Jan, 2016 1 commit
  8. 14 Jan, 2016 1 commit
  9. 07 Jan, 2016 1 commit
  10. 03 Nov, 2015 1 commit
  11. 23 Oct, 2015 1 commit
  12. 11 Sep, 2015 1 commit
  13. 21 Jul, 2015 1 commit
  14. 18 Apr, 2015 7 commits
  15. 14 Apr, 2015 2 commits
  16. 08 Nov, 2014 1 commit
  17. 27 Oct, 2014 1 commit
  18. 24 Jul, 2013 1 commit
  19. 26 Jun, 2013 1 commit
    • Sascha Silbe's avatar
      Fix block device accesses beyond 2TiB · ff8fef56
      Sascha Silbe authored
      With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type,
      which is required to represent block numbers for storage devices that
      exceed 2TiB (the block size usually is 512B), e.g. recent hard drives.
      
      For some obscure reason, the current U-Boot code uses lbaint_t for the
      number of blocks to read (a rather optimistic estimation of how RAM
      sizes will evolve), but not for the starting address. Trying to access
      blocks beyond the 2TiB boundary will simply wrap around and read a
      block within the 0..2TiB range.
      
      We now use lbaint_t for block start addresses, too. This required
      changes to all block drivers as the signature of block_read(),
      block_write() and block_erase() in block_dev_desc_t changed.
      Signed-off-by: default avatarSascha Silbe <t-uboot@infra-silbe.de>
      ff8fef56
  20. 05 May, 2013 2 commits
  21. 01 May, 2013 1 commit
  22. 17 Dec, 2012 1 commit
  23. 04 Nov, 2012 1 commit
    • Kim Phillips's avatar
      common/misc: sparse fixes · 199adb60
      Kim Phillips authored
      command.c:44:38: error: bad constant expression
      dlmalloc.c:1468:2: warning: Using plain integer as NULL pointer
      dlmalloc.c:1468:5: warning: Using plain integer as NULL pointer
      dlmalloc.c:2176:12: warning: Using plain integer as NULL pointer
      dlmalloc.c:2179:31: warning: Using plain integer as NULL pointer
      dlmalloc.c:2382:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2436:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2582:31: warning: Using plain integer as NULL pointer
      dlmalloc.c:2585:17: warning: Using plain integer as NULL pointer
      dlmalloc.c:2646:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2659:19: warning: Using plain integer as NULL pointer
      dlmalloc.c:2692:19: warning: Using plain integer as NULL pointer
      dlmalloc.c:2707:19: warning: Using plain integer as NULL pointer
      dlmalloc.c:2708:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2786:31: warning: Using plain integer as NULL pointer
      dlmalloc.c:2801:12: warning: Using plain integer as NULL pointer
      dlmalloc.c:2801:22: warning: Using plain integer as NULL pointer
      dlmalloc.c:2926:27: warning: Using plain integer as NULL pointer
      dlmalloc.c:2928:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2929:12: warning: Using plain integer as NULL pointer
      dlmalloc.c:3075:14: warning: Using plain integer as NULL pointer
      hush.c:292:14: warning: symbol 'last_return_code' was not declared. Should it be static?
      hush.c:293:5: warning: symbol 'nesting_level' was not declared. Should it be static?
      hush.c:2175:20: warning: Using plain integer as NULL pointer
      hush.c:2175:34: warning: Using plain integer as NULL pointer
      hush.c:2210:41: warning: Using plain integer as NULL pointer
      hush.c:2216:45: warning: Using plain integer as NULL pointer
      hush.c:2249:25: warning: Using plain integer as NULL pointer
      hush.c:2332:13: warning: symbol 'new_pipe' was not declared. Should it be static?
      hush.c:2390:5: warning: symbol 'reserved_word' was not declared. Should it be static?
      hush.c:2927:5: warning: symbol 'parse_stream' was not declared. Should it be static?
      hush.c:3127:6: warning: symbol 'mapset' was not declared. Should it be static?
      hush.c:3133:6: warning: symbol 'update_ifs_map' was not declared. Should it be static?
      hush.c:3161:5: warning: symbol 'parse_stream_outer' was not declared. Should it be static?
      hush.c:3295:34: warning: Using plain integer as NULL pointer
      hush.c:3631:5: warning: symbol 'do_showvar' was not declared. Should it be static
      image.c:1282:29: warning: Using plain integer as NULL pointer
      image.c:1315:41: warning: Using plain integer as NULL pointer
      image.c:1330:25: warning: Using plain integer as NULL pointer
      image.c:1706:25: warning: Using plain integer as NULL pointer
      main.c:510:10: warning: symbol 'hist_num' was not declared. Should it be static?
      main.c:512:5: warning: symbol 'hist_list' was not declared. Should it be static?
      main.c:513:6: warning: symbol 'hist_lines' was not declared. Should it be static?
      usb_storage.c:195:6: warning: symbol 'usb_show_progress' was not declared. Should it be static?
      usb_storage.c:440:48: warning: Using plain integer as NULL pointer
      usb_storage.c:503:5: warning: symbol 'usb_stor_BBB_comdat' was not declared. Should it be static?
      usb_storage.c:551:5: warning: symbol 'usb_stor_CB_comdat' was not declared. Should it be static?
      usb_storage.c:629:55: warning: Using plain integer as NULL pointer
      usb_storage.c:620:5: warning: symbol 'usb_stor_CBI_get_status' was not declared. Should it be static?
      usb_storage.c:675:43: warning: Using plain integer as NULL pointer
      usb_storage.c:668:5: warning: symbol 'usb_stor_BBB_clear_endpt_stall' was not declared. Should it be static?
      usb_storage.c:679:5: warning: symbol 'usb_stor_BBB_transport' was not declared. Should it be static?
      usb_storage.c:801:5: warning: symbol 'usb_stor_CB_transport' was not declared. Sh
      xyzModem.c:104:1: warning: symbol 'CYGACC_COMM_IF_GETC_TIMEOUT' was not declared. Should it be static?
      xyzModem.c:122:1: warning: symbol 'CYGACC_COMM_IF_PUTC' was not declared. Should it be static?
      xyzModem.c:169:1: warning: symbol 'parse_num' was not declared. Should it be stat
      
      note: hush.c's nesting_level deleted because not used.
      Signed-off-by: default avatarKim Phillips <kim.phillips@freescale.com>
      199adb60
  24. 22 Oct, 2012 1 commit
    • Gabe Black's avatar
      usb: Support the CONFIG_SYS_64BIT_LBA option · e81e79ed
      Gabe Black authored
      usb_storage wouldn't compile when the CONFIG_SYS_64BIT_LBA option is
      turned on because the used fixed size data types in their exported
      functions when they should have used lbaint_t for the block count
      parameter. That meant that when the sizes happened to be the same, when
      using a 28 bit LBA, the driver would build, but when it wasn't, a 48 bit
      LBA, things broke.
      
      This change adjusts the signatures to use the right type and makes small
      adjustments in the affected functions.
      Signed-off-by: default avatarGabe Black <gabeblack@chromium.org>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarMarek Vasut <marex@denx.de>
      e81e79ed