openmoko dfu-util improvements (patch & questions)

Stefan Schmidt stefan at datenfreihafen.org
Mon Apr 19 11:27:47 CEST 2010


Hello.

On Wed, 2010-04-07 at 20:52, Sandro Giessl wrote:
> Am Mittwoch, 7. April 2010 19:07:54 schrieb Stefan Schmidt:
> > 
> > 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/

Interesting.

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

I had some more thoughts about this the last days. This project is to useful to
bitrot in the Openmoko SVN.

- I'm stepping up as maintainer for it.
- Short term goal is to make a release in mai. Hopefully with Sandros patches
  in.
- After the release we will move into git and get our code hosted on a subdomain
  on Harald's infrstructure. (Perhaps dfu-util.gnumonks.org)
  This gives the project visibility behind the OM devices and flexibility from
  the hosting side. I just checked with Harald and he is able to host us and I'm
  already comfortable with his hosting infrstructure from other projects.
- My main focus is to keep it working with my OM devices
- Next to this I want to gradual improve support for other hardware I have
  access to.
- Patches for other hardware and fixes are of course more then welcome

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

Agreed. If we can get your patches in without breaking OM support I would like
to have them already in my first release. If this will not work out we can
schedule another release once they landed.

> > > > > 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? :)

This reminds me that I would need to add some more u-boot versions to my testing
matrix.

regards
Stefan Schmidt



More information about the devel mailing list