[U-Boot] [PATCH 1/8] doc: dfu: tftp: README entry for TFTP extension of DFU

[Tormod Volden]

On Mon, Jul 20, 2015 at 9:17 PM, Joe Hershberger wrote:
> On Mon, Jul 20, 2015 at 1:59 PM, Lukasz Majewski wrote:
>>> >> Is thor not faster than DFU?
>>> >
>>> > Yes, it is. However, DFU is standardized (which is despite of its
>>> > low speed its huge advantage) - thor not.
>>> >
>>> >>
>>> >> It seems like DFU should support a bulk endpoint if performance is
>>> >> an issue, right?
>>> >
>>> > Yes, it should, but such modification would be not compliant with
>>> > the standard.
>>>
>>> Who is the standards body? Can they accept suggestions for the next
>>> revision? Is it worth trying to improve the standard?
>>
>> The last revision of DFU standard is from 2006 with Greg KH being a
>> notable USB committee board member :-)
>>
>> I've asked him about the possibility to revise the standard but he
>> replied that chances are small since Linux Foundation is not part
>> of the USB standard committee anymore.
>
> That's a shame. Oh well.

As a dfu-util maintainer I should not encourage breaking the standard
:) but it happened that ST made their own twist to the standard
("DfuSe") for their own purposes. I added support for this to dfu-util
instead of making a new separate tool since much code could be shared,
and I still think that made sense. A good part of dfu-util usage today
is on DfuSe devices, and the added exposure and contributions are
helpful for non-DfuSe devices also. So if not too intrusive changes
are needed and there are people willing to code and test I would be
happy to accept it in dfu-util.

For background, the use of only control endpoints in the DFU standard
was there to keep everything as simple as possible and allow
implementations on the simplest of microcontrollers. Nowadays more
advanced microcontroller devices often use for instance USB mass
storage emulation for firmware updates, wanting to avoid any special
tools or drivers on the host, however this approach also has issues,
especially between various host platforms.

>>> >>That would be more efficient than emulating Ethernet.
>>> >
>>> > To be more precise - I've combined the ability to use Ethernet with
>>> > DFU flashing backend.
>>> >
>>> > In this way boards only equipped with ETH can (re)use DFU code to
>>> > flash data (on MMC, NAND, filesystems, RAM, etc).
>>>
>>> Yes, that's very good. I was simply talking about the "BONUS" where
>>> emulated Ethernet over USB is used. In that case it would be more
>>> efficient to actually have a raw bulk endpoint supported by DFU.
>>
>> Yes, it would. Unfortunately I think that it would be very hard to
>> revise the DFU standard.
>>
>> ETH over USB can be used on devices equipped only with USB (like
>> trats/trats2 devel mobile phones). In that way DFU speed would increase.
>
> Sure. Sounds good.

This is a nice workaround, although I don't know how easy it is to use
for common users, and if it gives much speed penalty compared to raw
bulk endpoints. Whether it makes sense to develop the latter also
depends on how interesting updates over USB (from a host computer)
will be for the uboot userbase or if e.g. pluggable mass storage
devices (and the device as USB host) will be more popular.

Regards,
Tormod