Hello.
On Sat, 2011-11-05 at 16:33, Wolfgang Denk wrote:
In message 000601cc9abe$4f544bd0$edfce370$%p@samsung.com you wrote:
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