dfu-util: Support for DFU ST extensions (DfuSe)
stefan at datenfreihafen.org
Thu Oct 6 13:29:53 CEST 2011
On Wed, 2011-10-05 at 21:52, Tormod Volden wrote:
> The code for supporting ST Microelectronics DFU extensions (DfuSe) is
> now ready. It can be found in the dfuse-libusb-1.0 branch of
> https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util - I
> recommend fetching it and viewing it with for instance "git instaweb"
> instead of reading the commits on gitorious because they list the
> commits out of commit order (I think they appear by author date and I
> did some rebasing).
Many many thanks for this. I will review this in the week after the
20th. I'm finishing my diploma thesis right now and barely have spare
cycles to read mail. But be assured that this and your other patches
are on my high priority list after the thesis drop off. :)
> The code has been tested on several devices:
> - DSO Nano pocket oscilloscope, whose IAP loader is based on STM32 USB
> FS Device Library 1.0.
> This was my original target application and many DSO Nano owners on
> Linux or Mac have happily been using the early code. ST only provides
> their own Windows loader application...
> - Custom device using the DFU example in STM32 USB FS Device Library 3.1.0.
> - STM32F107 which has a DFU boot loader in ROM (thanks Uwe Bonnes for
> testing this!)
> - STM32F105 was tested on an earlier version of the code (thanks
> Sebastian Pfeiffer)
> One question is if you prefer to merge my tree or just add the final
> files (there are just small changes to main.c the rest is separate
> files). My git history reflects the development from early hacks and
> some back and forth changes and parallel development with master and
> libusb-1.0 branches over time so they will mess up the "main" history.
> On the other hand there is some explanations in the commit logs that
> might help people understand things - ideally the code would be
> self-explaining though. I am not sure what is the best way, I
> originally thought I would submit the final files, but merging is part
> of the power of git also...
> My branch does not include updated documentation and man pages, I can
> add this after the merge. I can also add more inline code
> documentation at a later point.
> Finally there are some outstanding patches that I have submitted for
> the master branch. These are not needed for the DfuSe merge, but the
> last in the list will currently not merge cleanly against the DfuSe
> branch, so it should either be refreshed and applied after merging, or
> I am happy to rebase the DfuSe branch after the patch has been applied
> to master, to avoid merge conflicts. Actually, since that patch might
> need some testing, I'd suggest to put it on hold. The rest is
> relatively safe to apply.
> 55ae521 main: Make descriptor helper functions more generic
> 3d60f5b dfu-util.1: --device option never needed hex prefix
> 5d6e5a8 main: Move DFU state transition blocks together
> Looking forward to your comments and to finally make the DfuSe support
More information about the devel