[U-Boot] [PATCH] dfu: initial implementation

[Stefan Schmidt]

Hello.

On Sat, 2011-11-05 at 16:33, Wolfgang Denk wrote:
> In message <000601cc9abe$4f544bd0$edfce370$%p at samsung.com> you wrote:
> > 
> > > > http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
> > 
> > DFU is part of USB; an extension to be precise, but an extension bound
> > so tightly to the design and philosophy of USB that it is rather
> > inconceivable to separate the two.
> 
> Could you please be so kind and explain which exact issues you see for
> such a separation?

As Andrzej pointed out the DFU spec is written by the USB forum and
one can see that there target are USB devices. Let me bring in some
facts from the spec.

One part that is not covered here is the DFU suffix mandatory for all
firmware files. It gets stripped from the flashing tool before sending
it to the device code and thus it was not covered here so far. This
suffix holds, among others, fields with the PID of VID of the USB
device. Only allowing to be flashed if the device has the correct IDs.
How would assign the USB IDs to a network based approach for example?

The core part, I understand, is the DFU state machine you are referring
to. This sate machine relies on the USB descriptors in run-time or DFU
mode. It is hardcoded wot USB descriptors using bDeviceClass,
bDeviceSubClass, idVendor and idProduct to name a few. (See p. 14, 15
of the 1.1 spec).

In the reconfiguration phase the spec mandates the host to issue a
DFU_DETACH request on the USB EP0 and then issuing an USB reset. (p.
17)

All bound to the USB spec and hardware for using the spec in a
standard compliant way.

> > > Eventually it should be possible to run this protocol over Ethernet or
> > > even over a serial line?
> > 
> > Of course there is no such a reason, provided we lay USB over Ethernet
> > or serial line first ;)
> 
> This is of course not intended.  I was thinking about a plain standard
> UDP based link.

As always in computers one could try to come up with solutions to
replace the USB hardcoded parts with something else for a UDP based
solution. Its just now longer compliant with the DFU spec. All DFU
flashing utils out there are only working over USB. All the windows
flash utils as well as dfu-programmer, a small dfu util from the bluez
project and also dfu-util. The last ones are using libusb for this.

The main point is that if you replace the USB related parts with
something else not much of DFU stays anymore. It would be a different
flashing procedure. And for systems with a network interface available
there are way better ways to flash it then DFU. Even TFP would be more
convenient for them. You are way more flexible with Ethernet here.

DFU was designed for really small devices with minimal software
originally. Best examples are Bluetooth and WiFi USB dongles which can
be flashed this way if they. Its just that it becomes more popular as
many consumer electronics device are coming with a USB port but no
Ethernet these days.

regards
Stefan Schmidt