[dfu-util] Support for TI Stellaris patch
lists.tormod at gmail.com
Sat Jun 30 12:22:50 CEST 2012
On Fri, Jun 29, 2012 at 2:12 PM, Tommi Keisala wrote:
> I guess this is the upstream mailing list for the dfu-util as well?
Yes, it is. I think we should create a separately dfu-util mailing
list, but I have been awaiting the outcome of the *.openmoko.org
reorganisation before bringing this up.
> I wrote a patch to make dfu-utils to support TI Stellaris controllers
> bootloader DFU mode.
> This add's prefix to the binary that
Some explanation got cut off here...
> First you add dfu-suffix to binary file with:
> dfu-suffix -p 0x00ff -v 0x1cbe -d 0x0000 -a image.bin
> Then you use patched dfu-util to actually flash that Stellaris chip with:
> dfu-util -m 0x2000 -D image.bin
> Where 0x2000 is the flash address you want the image to be written in the
On Fri, Jun 29, 2012 at 4:29 PM, Tommi Keisala wrote:
> On 06/29/2012 04:54 PM, Patryk Benderz wrote:
>> ...so, it wasn't possible to add prefix as described here?
> I guess it is possible to do another dfu-prefix utility and I will be happy
> to do that. But on the other hand I will also need to make changes to
> dfu-util for checking that correct prefix for the device exists (like it is
> having check for the suffix) in the image. Otherwise device device flash
> fails with weird error. Now that prefix is generated on the fly before
> flashing I can do proper error message.
So is the modified image file everything that is needed for these
devices? Then I suggest you add this prefix in the dfu-suffix tool
instead of in dfu-util.
Is there a way to identify these Stellaris devices over USB? Then we
could leave a check in dfu-util to make sure there is a prefix (and
suffix) in the image for those devices.
There is also the dimension of compatibility with the "standard" tools
for this device. If TI ships an official tool accepting a specific
file format, and most users exchange files in this format, it might
make sense for dfu-util to deal with this format and do whatever
trickery needed before/while talking to the device.
I guess the usual exchange format would be raw binary (with address
information handed over separately) or a complete "Stellaris" file
with prefix and suffix included? Would anyone distribute files with
suffix but not prefix?
> I also feel that it would be handy to have dfu-suffix functionality
> integrated into dfu-util.
On Fri, Jun 29, 2012 at 7:49 PM, Tommi Keisala wrote:
> On 06/29/2012 05:48 PM, Patryk Benderz wrote:
>> I totally agree. Would be much better if there was some switch in dfu-util
>> to generate prefixes, instead of separate binary. So this would involve
>> migration of code from one program to another, right?
I believe it was a deliberate design decision to keep dfu-util simple
as possible and focus on the communication with devices. Manipulating
files (without needing any interaction with a device) can be done in a
separate tool like dfu-suffix. This is maybe a cultural difference
between Windows style "my 600MB application is all you need" and
unix-style "small tools that do one thing well" :) BTW, this brings to
mind a TODO item for which patches would be very welcome: Separate out
functionality in a library with a well-thought API so that people can
easily build GUI's around the dfu-util "meat". A preliminary could be
to leave all file handling in main and pass firmware image array
pointers to the various download and suffix handling routines instead
of file handles. And device communication snippets dealing with
various state transitions. And so on...
> Correct. And dfu-suffix shares most of the code with dfu-util. I can take a
Of course they share headers and functions when possible. But that is
not an argument to merge them together.
> look on that when I get back to work on Monday morning. It would be great to
> get an opinion from the maintainers if they are willing to accept that kind
> of patch.
I would rather see device-specific prefix juggling added to
dfu-suffix. Unless Stefan approves your idea I would recommend you to
hold off working on a code merge.
The patch refers to an application note, but I was not able to find it
on DuckDuckGo, Google nor Bing. Can you please provide a link? More
information on the usual user pattern will also be good.
I have some comments on the patch, but until there is an agreement on
the architecture this can wait.
More information about the devel