1. 24 Feb, 2016 1 commit
    • 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
  2. 07 Sep, 2015 2 commits
  3. 25 Feb, 2015 1 commit
  4. 18 Dec, 2014 1 commit
  5. 02 Sep, 2014 1 commit
    • Lukasz Majewski's avatar
      dfu: Provide means to find difference between dfu-util -e and -R · 1cc03c5c
      Lukasz Majewski authored
      This commit provides distinction between DFU device detach and reset.
      The -R behavior is preserved with proper handling of the dfu-util's -e
      switch, which detach the DFU device.
      
      By running dfu-util -e; one can force device to finish the execution of
      dfu command on target and execute some other scripted commands.
      
      Moreover, some naming has been changed - the dfu_reset() method now is known
      as dfu_detach(). New name better reflects the purpose of the code.
      
      It was also necessary to increase the number of usb_gadget_handle_interrupts()
      calls since we also must wait for detection of the USB reset event.
      
      Example usage:
      1. -e (detach) switch
       dfu-util -a0 -D file1.bin;dfu-util -a3 -D uImage;dfu-util -e
      
       access to u-boot prompt.
      
      2. -R (reset) switch
       dfu-util -a0 -D file1.bin;dfu-util -R -a3 -D uImage
      
       target board reset
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Reviewed-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarStephen Warren <swarren@nvidia.com>
      1cc03c5c
  6. 09 Aug, 2014 5 commits
    • Stephen Warren's avatar
      dfu: add SF backend · 6f12ebf6
      Stephen Warren authored
      This allows SPI Flash to be programmed using DFU.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      6f12ebf6
    • Stephen Warren's avatar
      dfu: add free_entity() to struct dfu_entity · cb7bd2e0
      Stephen Warren authored
      This allows the backend to free any resources allocated during the
      relevant dfu_fill_entity_*() call. This will soon be used by the
      SF backend.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      cb7bd2e0
    • Stephen Warren's avatar
      dfu: allow backend to specify a maximum buffer size · 7ac1b410
      Stephen Warren authored
      CONFIG_SYS_DFU_DATA_BUF_SIZE may be large to allow for FAT/ext layouts
      to transfer large files. However, this means that individual write
      operations will take a long time. Allow backends to specify a maximum
      buffer size, so that each write operation is limited to a smaller data
      block. This prevents the DFU protocol from timing out when e.g. writing
      to SPI flash. I would guess that NAND might benefit from setting this
      value too, but I can't test that.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      7ac1b410
    • Stephen Warren's avatar
      dfu: defer parsing of device string to IO backend · dd64827e
      Stephen Warren authored
      Devices are not all identified by a single integer. To support
      this, defer the parsing of the device string to the IO backed, so that
      it can apply the appropriate rules.
      
      SPI devices are specified as controller:chip_select. SPI/SF support will
      be added soon.
      
      MMC devices can also be specified as controller[.hwpart][:partition] in
      many commands, although we don't support that syntax in DFU.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      dd64827e
    • Stephen Warren's avatar
      dfu: fix some issues with reads/uploads · 0e285b50
      Stephen Warren authored
      DFU read support appears to rely upon dfu->read_medium() updating the
      passed-by-reference len parameter to indicate the remaining size
      available for reading.
      
      dfu_read_medium_mmc() never does this, and the implementation of
      dfu_read_medium_nand() will only work if called just once; it hard-codes
      the value to the total size of the NAND device irrespective of read
      offset.
      
      I believe that overloading dfu->read_medium() is confusing. As such,
      this patch introduces a new function dfu->get_medium_size() which can
      be used to explicitly find out the medium size, and nothing else.
      dfu_read() is modified to use this function to set the initial value for
      dfu->r_left, rather than attempting to use the side-effects of
      dfu->read_medium() for this purpose.
      
      Due to this change, dfu_read() must initially set dfu->b_left to 0, since
      no data has been read.
      
      dfu_read_buffer_fill() must also be modified not to adjust dfu->r_left
      when simply copying data from dfu->i_buf_start to the upload request
      buffer. r_left represents the amount of data left to be read from HW.
      That value is not affected by the memcpy(), but only by calls to
      dfu->read_medium().
      
      After this change, I can read from either a 4MB or 1.5MB chunk of a 4MB
      eMMC boot partion with CONFIG_SYS_DFU_DATA_BUF_SIZE==1MB. Without this
      change, attempting to do that would result in DFU read returning no data
      at all due to r_left never being set.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      0e285b50
  7. 14 May, 2014 1 commit
    • Lukasz Majewski's avatar
      dfu: mmc: Provide support for eMMC boot partition access · c8151b4a
      Lukasz Majewski authored
      Before this patch it was only possible to access the default eMMC HW
      partition. By partition selection I mean the access to eMMC via the
      ext_csd[179] register programming.
      
      It sometimes happens that it is necessary to write to other partitions.
      This patch adds extra attribute to "raw" sub type of the dfu_alt_info
      environment variable (e.g. boot-mmc.bin raw 0x0 0x200 mmcpart 1;)
      
      It saves the original boot value and restores it after storing the file.
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      c8151b4a
  8. 08 May, 2014 1 commit
  9. 05 May, 2014 2 commits
  10. 23 Mar, 2014 2 commits
    • Heiko Schocher's avatar
      usb: dfu: introduce dfuMANIFEST state · 001a8319
      Heiko Schocher authored
      on nand flash using ubi, after the download of the new image into
      the flash, the "rest" of the nand sectors get erased while flushing
      the medium. With current u-boot version dfu-util may show:
      
      Starting download: [##################################################] finished!
      state(7) = dfuMANIFEST, status(0) = No error condition is present
      unable to read DFU status
      
      as get_status is not answered while erasing sectors, if erasing
      needs some time.
      
      So do the following changes to prevent this:
      
      - introduce dfuManifest state
        According to dfu specification
        ( http://www.usb.org/developers/devclass_docs/usbdfu10.pdf ) section 7:
        "the device enters the dfuMANIFEST-SYNC state and awaits the solicitation
         of the status report by the host. Upon receipt of the anticipated
         DFU_GETSTATUS, the device enters the dfuMANIFEST state, where it
         completes its reprogramming operations."
      
      - when stepping into dfuManifest state, sending a PollTimeout
        DFU_MANIFEST_POLL_TIMEOUT in ms, to the host, so the host
        (dfu-util) waits the PollTimeout before sending a get_status again.
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      001a8319
    • Heiko Schocher's avatar
      usb, dfu: extract flush code into seperate function · a2199afe
      Heiko Schocher authored
      move the flushing code into an extra function dfu_flush(),
      so it can be used from other code.
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      a2199afe
  11. 18 Dec, 2013 2 commits
  12. 20 Oct, 2013 2 commits
  13. 24 Sep, 2013 5 commits
    • Lukasz Majewski's avatar
      usb:g_dnl:dfu: Download gadget and DFU function code clean up · a6921adc
      Lukasz Majewski authored
      The download gadget code and DFU function lacks of proper declarations
      for the case when a target board wants to use only one of available usb
      functions.
      
      Moreover the relevant declarations have been moved to consistent
      localization (like <dfu.h>).
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Cc: Marek Vasut <marex@denx.de>
      a6921adc
    • Afzal Mohammed's avatar
      dfu: ram support · a9479f04
      Afzal Mohammed authored
      DFU spec mentions it as a method to upgrade firmware (software stored
      in writable non-volatile memory). It also says other potential uses of
      DFU is beyond scope of the spec.
      
      Here such a beyond the scope use is being attempted - directly pumping
      binary images from host via USB to RAM. This facility is a developer
      centric one in that it gives advantage over upgrading non-volatile
      memory for testing new images every time during development and/or
      testing.
      
      Directly putting image onto RAM would speed up upgrade process. This and
      convenience was the initial thoughts that led to doing this, speed
      improvement over MMC was only 1 second though - 6 sec on RAM as opposed
      to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
      DFU framework to avoid multiple copy for ram (if worth) may help, and
      on other platforms and other boot media like NAND maybe improvement
      would be higher.
      
      And for a platform that doesn't yet have proper DFU suppport for
      non-volatile media's, DFU to RAM can be used.
      
      Another minor advantage would be to increase life of mmc/nand as it
      would be less used during development/testing.
      
      usage: <image name> ram <start address> <size>
      eg. kernel ram 0x81000000 0x1000000
      
      Downloading images to RAM using DFU is not something new, this is
      acheived in openmoko also.
      
      DFU on RAM can be used for extracting RAM contents to host using dfu
      upload. Perhaps this can be extended to io for squeezing out register
      dump through usb, if it is worth.
      Signed-off-by: default avatarAfzal Mohammed <afzal.mohd.ma@gmail.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      Cc: Gerhard Sittig <gsi@denx.de>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      Acked-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Acked-by: default avatarHeiko Schocher <hs@denx.de>
      a9479f04
    • Afzal Mohammed's avatar
      dfu: unify mmc/nand read/write ops enum · 5a127c84
      Afzal Mohammed authored
      MMC and NAND independently defines same enumerators for read/write.
      Unify them by defining enum in dfu header. RAM support that is being
      added newly also can make use of it.
      Signed-off-by: default avatarAfzal Mohammed <afzal.mohd.ma@gmail.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      Acked-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      Acked-by: default avatarHeiko Schocher <hs@denx.de>
      5a127c84
    • Lukasz Majewski's avatar
      dfu: Extract common DFU code to handle "dfu_alt_info" environment variable · 765c5ae5
      Lukasz Majewski authored
      New dfu_init_env_entities() function has been extracted from cmd_dfu.c and
      stored at dfu core.
      
      This is a dfu centric code, so it shall be processed in the core.
      
      Change-Id: I756c5de922fa31399d8804eaadc004ee98844ec2
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Tested-by: default avatarHeiko Schocher <hs@denx.de>
      765c5ae5
    • Lukasz Majewski's avatar
      dfu: Make maximum DFU file size equal to default DFU data buffer · 7a813d5b
      Lukasz Majewski authored
      Up till now the DFU maximum file size (to be written to e.g. eMMC)
      was different from the DFU data buffer size. It caused errors when
      one buffer was smaller than data to be written.
      
      Now, the maximum DFU file size is equal to default DFU buffer size.
      In spite of this, user is still able to manually adjust those default
      values.
      
      Change-Id: Ied75d0f7b59588ebd79dae9a22af801d36622216
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      7a813d5b
  14. 26 Aug, 2013 1 commit
  15. 29 Jul, 2013 1 commit
  16. 24 Jul, 2013 1 commit
  17. 30 Jun, 2013 1 commit
    • Heiko Schocher's avatar
      dfu: make data buffer size configurable · e7e75c70
      Heiko Schocher authored
      Dfu transfer uses a buffer before writing data to the
      raw storage device. Make the size (in bytes) of this buffer
      configurable through environment variable "dfu_bufsiz".
      Defaut value is configurable through CONFIG_SYS_DFU_DATA_BUF_SIZE
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      Cc: Tom Rini <trini@ti.com>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      Acked-by: default avatarTom Rini <trini@ti.com>
      e7e75c70
  18. 10 Apr, 2013 3 commits
  19. 08 Apr, 2013 1 commit
  20. 01 Sep, 2012 1 commit