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