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 _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
