public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes
Date: Tue, 21 Feb 2017 14:58:17 +0200	[thread overview]
Message-ID: <87mvdfwviu.fsf@linux.intel.com> (raw)
In-Reply-To: <20170221125802.59dee61e@jawa>


Hi,

Lukasz Majewski <lukma@denx.de> writes:
>> Lukasz Majewski <lukma@denx.de> writes:
>> >> >  >> drivers/usb/gadget/f_dfu.c | 2 +- 
>> >> >  >> 1 file changed, 1 insertion(+), 1 deletion(-) 
>> >> >  >> 
>> >> >  >> diff --git a/drivers/usb/gadget/f_dfu.c
>> >> >  >> b/drivers/usb/gadget/f_dfu.c index 8e7c981657..64cdfa7c98
>> >> >  >> 100644 --- a/drivers/usb/gadget/f_dfu.c 
>> >> >  >> +++ b/drivers/usb/gadget/f_dfu.c 
>> >> >  >> @@ -159,7 +159,7 @@ static void
>> >> >  >> dnload_request_complete(struct usb_ep *ep, struct
>> >> >  >> usb_request *req) int ret; 
>> >> >  >> 
>> >> >  >> ret = dfu_write(dfu_get_entity(f_dfu->altsetting), req->buf, 
>> >> >  >> - req->length, f_dfu->blk_seq_num); 
>> >> >  >> + req->actual, f_dfu->blk_seq_num); 
>> >> >
>> >> >  DFU driver queues a request to USB controller. Per the gadget
>> >> > API req->length contains maximum amount of data to be 
>> >> >  transmitted. req->actual is written by USB controller with the
>> >> > actual amount of data that we transmitted. 
>> >> >
>> >> >  In the case of IN (TX), upon completion req->length and
>> >> > req->actual should always be equal (unless errors show up, etc) 
>> >> >
>> >> >  In the case of OUT (RX), upon completion req->actual MAY BE less
>> >> > than req->length and that's not an error. Say host sent us a
>> >> > short packet which causes early termination of transfer. 
>> >> >
>> >> >  With that in mind, let's consider the situation where we're
>> >> > receiving data from host using DFU. Let's assume that we have a
>> >> > 4096 byte buffer for transfers and we're receiving a binary
>> >> > that's 7679 bytes in size. 
>> >> >
>> >> >  Here's what we will do (pseudo-code): 
>> >> >
>> >> >  int remaining = 7679; 
>> >> >  char buf[4096]; 
>> >> >
>> >> >  while (remaining) { 
>> >> >  req->length = 4096; 
>> >> >  req->buf = buf; 
>> >> >  usb_ep_queue(req); 
>> >> >
>> >> >  /* wait for completion */ 
>> >> >
>> >> >  remaining -= req->actual; 
>> >> >
>> >> >  dfu_write(buf, req->length); /* this is the error */ 
>> >> >  } 
>> >> >
>> >> >  Can you see here that in the last packet we will write 4096
>> >> > bytes when we should write only 3583? 
>> >> >
>> >> > In principle you are right. I need to check if this change will
>> >> > not introduce regressions.
>> >> >
>> >> > Can you share your use case?
>> >> 
>> >> Intel Edison running v2017.03-rc1 + patches (see [1]), flashing
>> >> u-boot.bin over DFU (see [2] for details). Without $subject, image
>> >> has to be aligned to 4096 bytes as below:
>> >> 
>> >> $ dd if=u-boot.bin of=u-boot-4k.bin bs=4k seek=1 && truncate -s
>> >> %4096 u-boot-4k.bin
>> >> 
>> >> With $subject, I don't need truncate. We still need the 4096 byte
>> >> of zeroes in the beginning of the image for other reasons (which I
>> >> really don't know why at this point).
>> >> 
>> >> [1] https://github.com/andy-shev/u-boot/tree/edison
>> >> [2] https://communities.intel.com/message/435516#435516
>> >> 
>> >
>> > Ok. I will check this. Thanks for pointing out :-)
>> 
>> Any updates here? I'd like to send Tangier Soc and Intel Edison Board
>> support but I kinda depend on this patch making upstream. I can resend
>> as part of the "add intel edison" series.
>> 
>> Let me know
>
> I'm setting up /test/py/dfu now on BBB. I will let you know by EOD.

Here's what I used for testing:

#!/usr/bin/env ruby

$errors = 0
$success = 0
$total = 0

$initial_size = 64
$max_size = 8 * 1024 * 1024 # 8MiB
$current_size = $initial_size

def create_file(size)
  `dd if=/dev/zero of=file.bin bs=#{size} count=1 > /dev/null 2>&1`
end

def send_file(size)
  `dfu-util -v -d 8087:0a99 -D file.bin > /dev/null 2>&1`
end

def transmit(size)
  create_file(size)
  send_file(size)
end

def transmit_and_check(size)
  transmit(size)

  if $?.success?
       $success += 1
       print "."
  else
       $errors += 1
       print "F"
  end

  $total += 1
end

while $current_size <= $max_size do
  transmit_and_check($current_size - 1)
  transmit_and_check($current_size)
  transmit_and_check($current_size + 1)

  $current_size *= 2
end

puts "\n"
puts "Test Done"
puts "Successes: #{$success}"
puts "Failures:  #{$errors}"
puts "Total:     #{$total}"

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170221/ca59e706/attachment-0001.sig>

  reply	other threads:[~2017-02-21 12:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <de749db9-9d5c-4777-b4e9-2c0dd1840cb8@email.android.com>
2017-02-13 11:42 ` [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes Felipe Balbi
2017-02-13 13:41   ` Lukasz Majewski
2017-02-13 15:02     ` Andy Shevchenko
2017-02-21 11:17     ` Felipe Balbi
2017-02-21 11:58       ` Lukasz Majewski
2017-02-21 12:58         ` Felipe Balbi [this message]
2017-02-21 13:21           ` Lukasz Majewski
2017-02-21 15:46             ` Felipe Balbi
2017-02-21 22:31               ` Lukasz Majewski
2017-02-22  9:21                 ` Felipe Balbi
2017-02-10 16:32 Andy Shevchenko
2017-02-10 17:50 ` Marek Vasut
2017-02-13 10:42   ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvdfwviu.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox