openmoko dfu-util improvements (patch & questions)

Wed Apr 7 20:52:15 CEST 2010

Am Mittwoch, 7. April 2010 19:07:54 schrieb Stefan Schmidt:
> Hello.
> 
> On Sun, 2010-04-04 at 06:11, Sandro Giessl wrote:
> > Am Sonntag, 4. April 2010 03:42:17 schrieb Harald Welte:
> > > On Sat, Apr 03, 2010 at 11:36:37PM +0200, Stefan Schmidt wrote:
> > > > > DFU_GETSTATUS ignores bwPollTimeout but does hardcoded usleep(5000)
> > > > > when doing DFU download:
> > > > > This is a show-stoper for us, since this delay is too short and
> > > > > results in libusb 'Broken pipe' errors.
> > > > > A patch implementing proper timeout handling is attached.
> > > >
> > > > Nice to see other people using it.
> > >
> > > I sporadically get reports from other people using it for various
> > > different devices, too.
> 
> Good to know. Next to your u-boot patches I know at least one other
>  bootloader implementing DFU. Barebox, ealier called u-boot-v2. I would
>  think that they are also using dfu-utils as host counterpart, but I don't
>  know for sure.

I've seen at least one other bootloader using dfu-utils, 
http://code.google.com/p/leaflabs/

> > > > > My question is, do you see a chance in getting these things
> > > > > upstream?  Since some distros are shipping slightly different SVN
> > > > > revisions, do you plan a real dfu-util release any time soon?
> > > >
> > > > As Paul already pointed out the biggest problem is that we don't have
> > > > a real maintainer for it. I think Harald is way to busy with other
> > > > things and nobody stepped up to take care of fixing problems going
> > > > forward to a real release.
> > >
> > > This is correct.  I don't mind bumping the version number and
> > > announcing something as an official release, if that is something
> > > people want me to do.  But I don't have all the various devices that
> > > people (want to) use dfu-util with, and thus it's hard for me to tell
> > > what works where.
> >
> > It's what stated in the header of sam7dfu.c which motivates me to merge
> > changes directly into dfu-util, instead doing some quick hacks and
> > creating yet another dfu-programmer:
> > "This is supposed to be a "real" DFU implementation, just as specified in
> > the USB DFU 1.0 Spec."
> 
> Yes, it was the main motivation.
> 
> > Since it's not feasible to test any device out in the wild, the focus
> > should be set on a closer spec conformity + occasional quirks and special
> > handling based on idVendor/idProduct/bcdDevice.
> 
> I agree.
> 
> > As long as it *is* an option to not only continue in OM-bug-fixing mode
> > I'm more than happy.
> 
> It is. Personally I feel that dfu-utils is really a separate project from
>  the rest of the OM platform. See more below.
> 
> > > There are multiple different options:
> > >
> > > 1) separate it from openmoko and create its own repository and
> > >    mailinglist, run it as a standalone project
> > >
> > > 2) simply giving anyone who's stepping up to maintain it the committ
> > >    access in the openmoko repository and continue to point to this
> > >    mailing list for patch submission and discussion
> >
> > If you really don't have the time I will be glad to look after it
> > occasionally.  You may call it maintainership, but I would still prefer
> > to have some of the OM developers looking over my shoulder, pointing out
> > possible flaws or OM-incompatibilities.
> 
> I can do this for you. Will test your patch tomorrow or friday and let you
>  know if it breaks anything for my diferent OM devices. Quite likely that
>  we need the quirk to keep it working with the u-boot versions shipped on
>  the devices.

Cool, thank you.

> > It's up to you... I currently prefer 2) with the emphasis to be open for
> > other parties (e.g. also their legacy device specific quirks) interested
> > in DFU, too.
> 
> The decision depends on how much patches we will get. If its only 3 or 4
> patches I can just go ahead and commit them. If more parties join the show
>  and starting to contribute I would prefer to move it over to a separate
>  project. Giving it more visibility outside of OM, moving to a git
>  repository and starting more frequent releases.
>
> Harald, could you host such a project? I know your infrastructure works
>  well and I'm already familiar with it. dfu-utils.org is also still
>  available. ;)
> 
> Speaking about releases we should really do one. Sandro, how much
>  oustanding patches do you have to make it working fine with your hardware?
>
> I'm trying to understand if we should better make a stable release now with
>  a known-good setup for OM devices and another one when your stuff is in
>  and settled or if we should wait for landing it into the first release
>  because it only brings small changes.

From our side it's more like 3 or 4 patches, including
dfu-file suffix handling,
- must-have changes to get our own DFU to work,
- a statemachine for more robust state tracking (not changing much of the 
current upload/download method),
- better error-handling/-recovery,
- and hopefully some interface for handling quirks allowing it being fully 
backwards compatible.

I will send them to the list for proposal ASAP.

Personally I would prefer doing the release a few days later with at least our 
must-have fixes in, but not breaking any OM stuff would be important of 
course...

> > > > The download part is quite stable I think, at least on the Openmoko
> > > > phones and I already heard from people that it shoudl also detect
> > > > various BT devices. The last time I tested upload was broken though.
> > >
> > > As far as I remember, this was a problem inside u-boots DFU
> > > implementation and not the host utility.
> 
> Ah, thanks for letting me know. So someone interested could fix the DFU
>  upload and the DFU timout setting in u-boot. Volunteers? :)
> 
> > > > Hmm, this is no longer only sam7 related. Seems like a historical
> > > > fragment from the pre-OM days. (Some of the code was already used on
> > > > the OpenPCD project).
> > >
> > > yes, and somebody should probably test if it still works with openpcd
> > > at some point before making a release...
> 
> I don't have one around. So that would be either you or I would need access
>  to the hardware.
> 
> > > > Aehm, I don't think 2 lines of code change plus three lines comments
> > > > justify the copyright addition of two people...
> > >
> > > For credits, we can start a CONTRIBUTERS file or something along those
> > > lines.  But I agree with Stefan. It is even legally wrong: A trivial
> > > change like this does not constitue a copyrightable work and thus there
> > > should be no copyright statement of the respective authors
> >
> > Sure, you are right. Of course there are some bigger changes that need to
> > be cleaned up and integrated some time, so I wasn't actually thinking
> > about how ridiculous this might look in conjunction with this single
> > usleep diff. :)
> 
> heh, no worries. :)
> 
> I would say we start a CONTRIBUTORS file once we commit your patch. After
>  more code changes people would move into AUTHORS as well.

Ok.

> > I don't have an OM phone for testing, therefore it would be neccessary to
> > document its quirks and/or someone verifying that nothing breaks in case
> > of openmoko/u-boot.
> 
> I can take care of this. Better spent your time on your other projects. :)

Nice to hear about this.

Best regards,
Sandro

-- 
┌─────────────────────────────────┐
  niftylight GmbH

  Sandro Gießl
  Lämmerweide 12a
  D-82256 Fürstenfeldbruck
  Germany

  Tel.:    +49-8141-315 99 00
  Telefax: +49-8141-315 99 01
  WWW:     http://niftylight.de
└─────────────────────────────────┘

Geschäftsleitung: D.Hiepler / S.Gießl
Handelsregister: Amtsgericht München - HRB Nr. 175748