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

[Wolfgang Denk]

Dear Stefan Schmidt,

In message <20111106170219.GB20104 at excalibur.local> you wrote:
> 
> > 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.
...
> All bound to the USB spec and hardware for using the spec in a
> standard compliant way.

Yes, indeed.

But I feel you stick way too close to this spec, and are not trying to
abstract awway the low level details a bit.

Yes, this spec was written by the USB forum, and they did not even
attempt to look over the rim of their plates.  But does that mean we
all have to do the same?  I'm not willing to accept such a narrow
view.

Let's - just as a gedankenexperiment - assume our task was to
implement a solution that provides similar capabilities as DFU, but
must work over serial line, Ethernet, Bluetooth, Infrared, whatever.
Assume we thing DFU could be used as base, but we need to find a way
to move the USB related things into the USB layer, while things like
the state machine, the requests, device status, state transitions,
etc. are generic enough.

Yes, the DFU File Suffix contains fields that map nicely to USB
devices - but what prevents us to provide similar data on non-USB
media, too?  We just need to make sure that th code which handles this
allows to plug in handlers for other transfer media.


> 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

I'm not sure what exactly you want to tell me here.

My idea is that of an implementation that is split into a generic and
a device specific part.  If implemented corectly, the combination of
the generic part with the USB specific part would be strictly
conformant to the DFU spec.

Of course, the combination of for example the DFU generic part with an
Ethernet network interface would not be conformant to the DFU spec,
but it would be something that works in a very similar way.  And that
would most probably be better than inventing yet another download
method.

> 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.

That's the status quo.  Agreed.  Bit this can be changed, extended.
Or not?

> 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

I disagree here.  DFU is different in a number of aspects, and you
know this very well.

> 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.

I'm not sure what your exact argument is here. I'm not the one asking
for DFU support. I would be happy to use TFTP over Ethenret over USB.
We're actually doing this in some products.

> 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.

Agreed. And if it's becoming more popular, it might even be a good
idea to think about a less restricted implementation, which opens new
oportunites.


Yes, I think we should strive for such a separation of USB transport
layer and protocol implementation / state machine / command interface.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
While money can't buy happiness, it certainly lets  you  choose  your
own form of misery.