Hi Marek,
On Friday, April 11, 2014 at 02:55:31 PM, Rob Herring wrote:
On Fri, Apr 11, 2014 at 2:14 AM, Bo Shen voice.shen@atmel.com wrote:
Hi Rob Herring,
I am just do a function testing on Atmel sama5d3xek board. And a small
comment as following.
Btw, do you test to transfer big size file. I try a file bigger than
100MiB, it will hang. However use DFU or RNDIS don't meet this issue.
How much RAM do you have? It will happily download into the end of RAM overwriting u-boot if loadsize is not set. DFU at least has its own buffer size configuration.
I really have to wonder ... why does android not use DFU
Unfortunately the DFU has its own limitations. The most notable one is using only EP0 for transmission. As a result the transmission speed is slow when compared with other solutions, which are using other EPs.
instead and instead forces us to take in yet another (fourth ? ... CDC ethernet, DFU, Thor, Fastboot)
A little explanation: 1. UMS (CDC Ethernet) - export the content of the whole flash. It should be regarded as a convenient debug option. It is somewhat clumsy to use dd if=/u-boot.bin of=/dev/sda1 .... to store u-boot.
2. DFU it is the standard - devised at 2004 - rather outdated now. It is slow but reliable - targeted to uC flashing.
3. Thor, fastboot - protocols devised to provide faster transmission rates (they use other EPs for transmission).
usb image download protocol someone invented without cooperating with the rest of the community on a common and functional solution? Sigh :'-(
I think, that this problem emerged because of the lack of DFU standard update - adding better checksumming and possibility for using other EPs would solve the problem.
In u-boot it is not a big problem, since we are using one backend (dfu_write()) to store data on the medium. Moreover common gadget code - g_dnl.c is available to reduce code duplication.
To add support for other gadget one needs to implement proper function (like f_thor.c, f_dfu.c, f_fastboot.c).
Best regards, Marek Vasut