Hi Lukasz,
Lukasz Majewski <lu...@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 -- balbi
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
