openmoko dfu-util improvements (patch & questions)
sandro-openmoko at niftylight.de
Wed Apr 7 20:52:15 CEST 2010
Am Mittwoch, 7. April 2010 19:07:54 schrieb Stefan Schmidt:
> 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,
> > > > > 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
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
> > > > 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.
> > 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.
Tel.: +49-8141-315 99 00
Telefax: +49-8141-315 99 01
Geschäftsleitung: D.Hiepler / S.Gießl
Handelsregister: Amtsgericht München - HRB Nr. 175748
More information about the devel