1. 01 Mar, 2016 1 commit
    • Sam Protsenko's avatar
      usb: gadget: composite: Correct recovery path for register · 8038f6d2
      Sam Protsenko authored
      
      
      In case when usb_composite_register() failed once (for whatever reason),
      it will fail further even if all conditions are correct. Example:
      
          => fastboot 2
          Invalid Controller Index
          couldn't find an available UDC
          g_dnl_register: failed!, error: -19
          exit not allowed from main input shell.
      
          => fastboot 0
          g_dnl_register: failed!, error: -22
          exit not allowed from main input shell.
      
      Despite that 0 is correct index for USB controller, "fastboot 0" command
      will fail, because "composite" structure wasn't cleared properly on
      previous fail (on "fastboot 2" command).
      
      This patch fixes that erroneous behavior, allowing us to use composite
      even after previous failure.
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      8038f6d2
  2. 24 Feb, 2016 2 commits
    • Steve Rae's avatar
      fastboot: update error and warning messages · a18c2706
      Steve Rae authored
      
      
      Fix the formatting in error messages, and demote one error message
      to a warning, as it is only informational.
      Signed-off-by: default avatarSteve Rae <srae@broadcom.com>
      a18c2706
    • Lukasz Majewski's avatar
      dfu: usb: f_dfu: Set deferred call for dfu_flush() function · fc18f8d1
      Lukasz Majewski authored
      
      
      This patch fixes situation when one would like to write large file into
      medium with the file system (fat, ext4, etc).
      This change sets file size limitation to the DFU internal buffer size.
      
      Since u-boot is not supporting interrupts and seek on file systems, it
      becomes challenging to store large file appropriately.
      
      To reproduce this error - create large file (around 26 MiB) and sent it
      to the target board.
      
      Lets examine the flow of USB transactions:
      
      0. DFU uses EP0 with 64B MPS [Max Packet Size]
      
      1. Send file - OUT (PC->target) - dat_26MiB.img is sent with 4096 B transactions
      
      2. Get status - OUT (PC->target) - wait for DFU_STATE_dfuDNLOAD_IDLE (0x05) sent
      				   from target board - IN transaction
      				   (target->PC)
      
      3. The whole file content is sent to target - OUT (PC->target) with ZLP [Zero
      					      Length Packet]
      
      Now the interesting part starts:
      
      4. OUT (PC->target) Setup transaction (request to share DFU state)
      
      5. IN (target->PC) - reply the current DFU state
      	- In the UDC driver the req->completion (with dfu_flush) is called
      	  after successful IN transfer.
      	- The dfu_flush() (called from req->completion callback) saves the
      	  whole file at once (u-boot doesn't support seek on fs).
      	  Such operation takes considerable time. When the file
      	  is large - e.g. 26MiB - this time may be more than 5 seconds.
      
      6. OUT (PC->target) - ZLP, is send in the same time when dfu_flush()
       writes data to eMMC memory.
       The dfu-util application has hard coded timeout on USB transaction
       completion set to 5 seconds (it uses libusb calls).
      
      When the file to store is large (e.g. 26 MiB) the time needed to write it
      may excess the dfu-util timeout and following error message will be displayed:
      "unable to read DFU status" on the HOST PC console.
      
      This change is supposed to leverage DFU's part responsible for storing files
      on file systems. Other DFU operations - i.e. raw/partition write to NAND and
      eMMC should work as before.
      
      The only functional change is the error reporting. When dfu_flush() fails
      the u-boot prompt will exit with error information and dfu-util application
      exits afterwards as well.
      
      Test HW:
      - Odroid XU3 (Exynos5433) - test with large file
      - Trats (Exynos4210) - test for regression - eMMC, raw,
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Reported-by: default avatarAlex Gdalevich <agdalevich@axion-biosystems.com>
      Tested-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarHeiko Schocher <hs@denx.de>
      fc18f8d1
  3. 06 Feb, 2016 1 commit
  4. 04 Feb, 2016 1 commit
  5. 19 Jan, 2016 1 commit
  6. 16 Jan, 2016 1 commit
  7. 15 Jan, 2016 1 commit
  8. 14 Jan, 2016 1 commit
    • Stephen Warren's avatar
      ums: support multiple LUNs at once · 02585eb3
      Stephen Warren authored
      
      
      Extend the ums command to accept a list of block devices. Each of these
      will be exported as a separate LUN. An example use-case would be:
      
      ums 0 mmc 0,0.1,0.2
      
      ... which would export LUNs for eMMC 0's user data, boot0, and boot1 HW
      partitions. This is useful since it allows the host access to everything
      on the eMMC without having to somehow stop the ums command from executing
      and restart it with different parameters.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      02585eb3
  9. 17 Dec, 2015 24 commits
  10. 20 Nov, 2015 1 commit
  11. 12 Nov, 2015 3 commits
    • Maxime Ripard's avatar
      fastboot: Implement NAND backend · bf8940d3
      Maxime Ripard authored
      
      
      So far the fastboot code was only supporting MMC-backed devices for its
      flashing operations (flash and erase).
      
      Add a storage backend for NAND-backed devices.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      bf8940d3
    • Maxime Ripard's avatar
      fastboot: Implement flashing session counter · 6c9e00ee
      Maxime Ripard authored
      
      
      The fastboot flash command that writes an image to a partition works in
      several steps:
      
      1 - Retrieve the maximum size the device can download through the
          "max-download-size" variable
      
      2 - Retrieve the partition type through the "partition-type:%s" variable,
          that indicates whether or not the partition needs to be erased (even
          though the fastboot client has minimal support for that)
      
      3a - If the image is smaller than what the device can handle, send the image
           and flash it.
      
      3b - If the image is larger than what the device can handle, create a
           sparse image, and split it in several chunks that would fit. Send the
           chunk, flash it, repeat until we have no more data to send.
      
      However, in the 3b case, the subsequent transfers have no particular
      identifiers, the protocol just assumes that you would resume the writes
      where you left it.
      
      While doing so works well, it also means that flashing two subsequent
      images on the same partition (for example because the user made a mistake)
      would not work withouth flashing another partition or rebooting the board,
      which is not really intuitive.
      
      Since we have always the same pattern, we can however maintain a counter
      that will be reset every time the client will retrieve max-download-size,
      and incremented after each buffer will be flashed, that will allow us to
      tell whether we should simply resume the flashing where we were, or start
      back at the beginning of the partition.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      6c9e00ee
    • Maxime Ripard's avatar
      fastboot: Move fastboot response functions to fastboot core · 3c8f98f5
      Maxime Ripard authored
      
      
      The functions and a few define to generate a fastboot message to be sent
      back to the host were so far duplicated among the users.
      
      Move them all to a common place.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      3c8f98f5
  12. 10 Nov, 2015 1 commit
    • Tom Rini's avatar
      Various Makefiles: Add SPDX-License-Identifier tags · da58dec8
      Tom Rini authored
      
      
      After consulting with some of the SPDX team, the conclusion is that
      Makefiles are worth adding SPDX-License-Identifier tags too, and most of
      ours have one.  This adds tags to ones that lack them and converts a few
      that had full (or in one case, very partial) license blobs into the
      equivalent tag.
      
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      da58dec8
  13. 03 Nov, 2015 2 commits
    • Michal Simek's avatar
      usb: udc: Fix warnings on 64-bit builds · f6fcebf5
      Michal Simek authored
      
      
      Cast u32 bit value to 64bit before recasting to 64bit pointer to avoid
      pointer from integer cast size mismatch warnings.
      
      Warning log:
      +../drivers/usb/gadget/udc/udc-core.c: In function
      ‘usb_gadget_unmap_request’:
      +../drivers/usb/gadget/udc/udc-core.c:68:19: warning: cast to pointer
      from integer of different size [-Wint-to-pointer-cast]
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
      f6fcebf5
    • Michal Simek's avatar
      usb: lthor: Specify correct parameter for sizeof type · 32191755
      Michal Simek authored
      
      
      This patch removes this warning:
        CC      drivers/usb/gadget/f_thor.o
      drivers/usb/gadget/f_thor.c: In function ‘thor_tx_data’:
      drivers/usb/gadget/f_thor.c:572:2: warning: format ‘%d’ expects argument
      of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
        debug("%s: dev->in_req->length:%d to_cpy:%d\n", __func__,
        ^
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
      32191755