On Sun, Aug 10, 2014 at 2:06 PM, Paul Fertser wrote:
> Hi,
>
> On Sun, Aug 10, 2014 at 01:47:08PM +0200, Tormod Volden wrote:
>> Thanks a lot for investigating this! I am Cc'ing the dfu-util list and
>> preferably we move the conversation there.
>
> Releasing a d
On Sun, Aug 10, 2014 at 12:26 PM, Paul Fertser wrote:
> Tormod Volden writes:
>> Further, it would be helpful to run dfu-util with gdb or another
>> debugger and step through the enumeration and matching of interfaces,
>> and see why the interface (name) is not recognized.
&
Hi Freerunner owners,
I am trying to find someone who is willing to try some debugging of
dfu-util on their OpenMoko Freerunner. We don't have anyone who can do
it on the dfu-util mailing list, so therefore I am asking here. The
latest git version (which otherwise is close to be released as
dfu-ut
On Mon, Sep 17, 2012 at 9:28 AM, Tommi Keisala wrote:
>
> And here's new patch with the changes in case you did not yet integrate this
> stuff.
Thanks a lot! Applied.
(I only massaged the help text a bit, to preserve the indentation of
the old options, these new ones are so long anyway it cannot
On Mon, Sep 17, 2012 at 7:27 AM, Tommi Keisala wrote:
> Good catch.
> Maybe it would be good idea to force user give proper address rather than
> defaulting to 0.
> I can't recall the reasoning for reading lmdfu_flash_address twice and now
> it seems quite silly.
> Maybe I should rewrite this part
On Tue, Jul 10, 2012 at 11:52 AM, Tommi Keisala wrote:
>
> Here is another try with fixes Tormod earlier suggested plus a change that
> make Stellaris prefix extension happen with different options between adding
> (-s address) and deleting (-T).
>
Hi Tommi,
While preparing to apply your patch, a
Hi Tommi,
Sorry for the long silence. Your latest patch looks good to me. I just
haven't had the time to do more about it, and I think the same goes
for Stefan. It is summer time and vacation time for many of us :)
Unless testing or further review detects any issues, you can count on
the patch bei
On Thu, Jul 5, 2012 at 7:40 AM, Tommi Keisala wrote:
>
> Yes you are correct. There is optional_argument option for getopt_long but
> that does not seem to work as I want it. And there seems to be a reason why
> it is implemented as it is. Anyhow I do not want to use it. So I added
> another option
On Tue, Jul 3, 2012 at 6:56 AM, Tommi Keisala wrote:
> Hi,
>
> After discussion over the weekend I brewed another patch that obsoletes the
> old one.
> So here's a new patch that adds TI Stellaris bootloader DFU prefix support
> for dfu-suffix tool.
> After binary image is prefixed (and suffixed) i
On Fri, Jun 29, 2012 at 2:12 PM, Tommi Keisala wrote:
> Hello,
>
> I guess this is the upstream mailing list for the dfu-util as well?
Hi Tommi,
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
infrastructure
(htt
On Mon, Jun 4, 2012 at 3:51 AM, Andrew Leech wrote:
> Hi,
> I'm just starting to use dfu-util to program some hardware based on the
> lpc3131 processor which has a built in dfu mode.
> My device is predominantly used on windows, but I've had reliability isuues
> with the dfu software that's supplie
On Sun, Apr 22, 2012 at 11:02 AM, Tormod Volden wrote:
> On Sun, Apr 22, 2012 at 12:07 AM, Tormod Volden wrote:
>> On Sat, Apr 21, 2012 at 11:01 PM, Stefan Schmidt wrote:
>>>
>>>> dfu-suffix: Check for availability of truncate() function
>>>
>>>
On Sun, Apr 22, 2012 at 12:07 AM, Tormod Volden wrote:
> On Sat, Apr 21, 2012 at 11:01 PM, Stefan Schmidt wrote:
>>
>>> dfu-suffix: Check for availability of truncate() function
>>
>> You happen to know which platforms are missing this?
>
> No, but I
gt;> dfu-suffix: New DFU suffix manipulation tool
>
>
>> Tormod Volden (21):
>> dfu_file: Verify that we could read the whole file
>> dfu_file: Return failure if CRC does not match
>> dfu-suffix: Print version before banner, and do it every time
22:38:28 +0200)
Stefan Schmidt (2):
dfu_file: Add function to generate and add a DFU suffix to a file
dfu-suffix: New DFU suffix manipulation tool
Tormod Volden (21):
dfu_file: Verify that we could read the whole
Hi,
I discovered MinGW.org today and that turns out to be the easiest way
to build Windows binaries of dfu-util, and even comfortably on a Linux
machine. It builds latest git of libusb without any issue, and after
fixing up my git tree dfu-util builds as well. I tested the resulting
(32-bit) dfu-ut
2012/4/15 Daniel Li:
> Tormod Volden，
>
> Well, I didn't get luck.
>
> So I have fixed my Celeron (Coppermine), which is 700MHz GenuineIntel
> processor. Re-install ubuntu 8.04.
>
> It's ok to flash the device now.
>
> If there is any good way to build d
On Wed, Apr 11, 2012 at 11:25 PM, Tormod Volden wrote:
> Hi,
> In the meantime, I have done the ID change, squash and rebase and
> pushed it here:
> http://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util/commits/master-patches
> and have started to add some patches on top of
On Wed, Mar 28, 2012 at 12:09 PM, Stefan Schmidt wrote:
>
>> >> > I did all changes based on your review in one commit:
>> >> > http://cgit.openezx.org/dfu-util/commit/?h=dfu-suffix
>> >>
>> >> I think you should rebase/squash the commits there before you pull
>> >> this into master.
>> >
>> > Sure
2012/4/7 Daniel Li:
> Hi all,
> Anyway, I have been sucessfully build dfu-util with cygwin, which has
> libusb1.0
Great to hear!
> But it can program the device, any idea about this issue? Why dfu-util can't
> open the device?
> $ ./dfu-util.exe -l
> dfu-util - (C) 2005-2008 by Weston Schmidt,
2012/4/7 Daniel Li:
> Hi all,
>
> I downloaded libusb-win32-bin-1.2.6.0.zip, and extract the only head file
> "lusb0_usb.h" and msvc library libusb.lib.
>
> As dfu-util uses libusb.h, I guess it's the only head file "lusb0_usb.h"
>
> But vc6 can't compile dfu-util sucessfully, see below log:
>
> A
2012/4/6 Daniel Li:
> Hi Tormod Volden，
>
>
> I have get windows dfu-util source and start to use vs2005 to build dfu-util.
> And got following compile error:
>
> 1>dfu.c
> 1>z:\openmoko\dfu-util\src\dfu.c(24) : fatal error C1083: Cannot open include
> file:
Hi Daniel,
Did you try the "windows" branch of the git repo?
http://cgit.openezx.org/dfu-util/log/?h=windows
What kind of compiler/environment did you try?
Once you have it built, there is the driver and libusb installation as
well. For libusb 1.0 on Windows, this might be the best reference:
htt
On Tue, Mar 27, 2012 at 5:10 PM, Stefan Schmidt wrote:
>> I got a reply from Leaflabs and they were going to test things. But
>> since then I haven't heard anything. At the minimum I would like a
>> confirmation from them on which USB ID's need to be quirked.
>
> I'm not in a rush with 0.6 here. St
On Wed, Mar 7, 2012 at 1:03 PM, Stefan Schmidt wrote:
>> http://forums.leaflabs.com/topic.php?id=1369
>
> Oh, pity. :(
>
>> I will work with Maple to get their firmware compliant, but I would
>> also like to add quirks to dfu-util so that their already shipped
>> firmware can work. The extent of th
Hi,
Let me first comment the 0.6 plan:
> Once this is in and no problems show up I would want to go for a 0.6
> release. If you, or anyone else, has some fixes around let me know.
I have just discovered that the Maple project ships broken firmware
(declares itself as 1.1a = dfuse but is really 1
On Mon, Dec 19, 2011 at 3:37 PM, Stefan Schmidt
wrote:
> Hello.
>
> On Mon, 2011-12-19 at 00:07, Tormod Volden wrote:
>> From: Tormod Volden
>>
>> Also remove unused debug code.
>>
>> Signed-off-by: Tormod Volden
>
> Applied and pushed this on
From: Tormod Volden
Also remove unused debug code.
Signed-off-by: Tormod Volden
---
Hi,
This patch, and two patches previously posted,
main: List alternate interfaces in DFU mode
main: Simplify --detach handling by reusing existing code
are also available on
https://gitorious.org/~tormod
From: Tormod Volden
in the case there are several and the user did not specify one.
This can be useful if the device does not expose its alternate
interfaces in run-time mode, but only in DFU mode.
Also adjusted a warning message to clarify that we do not set
the alternate interface in run
From: Tormod Volden
Thanks to Uwe Bonnes and Satz Klauer for pointing it out.
Also adjusted a couple of related diagnostic messages.
Signed-off-by: Tormod Volden
---
Uwe once actually sent me a patch for what Satz pointed out,
but it needed to be refreshed for the current code.
Cheers
From: Tormod Volden
Signed-off-by: Tormod Volden
---
src/dfuse.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/dfuse.c b/src/dfuse.c
index f091bda..c5807e0 100644
--- a/src/dfuse.c
+++ b/src/dfuse.c
@@ -1,5 +1,6 @@
/* This implements the ST Microsystems DFU
From: Tormod Volden
in the case there are several and the user did not specify one.
This can be useful if the device does not expose its alternate
interfaces in run-time mode, but only in DFU mode.
Also adjusted a warning message to clarify that we do not set
the alternate interface in run
From: Tormod Volden
Signed-off-by: Tormod Volden
---
Hi,
I have some issues with the recent --detach option addition:
* It duplicates the existing detach code
* It sends requests to an interface without claiming it first
* It resets the device without checking bitWillDetach
Can't we s
On Thu, Nov 10, 2011 at 8:10 AM, Satz Klauer wrote:
> Hi,
>
> according to
> http://wiki.openmoko.org/wiki/Dfu-util-windows#Porting_dfu-util_to_Windows
> I tried to compile dfu-util for Windows. Unfortunately it seems like
> it expects libusb1 while libusb-win32 seems to support API version 1.0
>
On Wed, Nov 2, 2011 at 4:14 PM, Tormod Volden wrote:
> 2011/11/2 Yohan PAINCHAUD:
>> Is this library supporting the DFU specification 1.1 ?
>>
>> I read in the mailing-list that the version 0.5 may support it, but not yet
>> tested? I saw that the DFU 1.1 has few
2011/11/2 Yohan PAINCHAUD:
> Is this library supporting the DFU specification 1.1 ?
>
> I read in the mailing-list that the version 0.5 may support it, but not yet
> tested? I saw that the DFU 1.1 has few attributes modified, as for example
> the Run-Time DFU Functional Descriptor, but in the 0.5
On Mon, Oct 31, 2011 at 10:09 AM, Stefan Schmidt wrote:
> Now for the review. I'm hapopy to see that they at least have choosen
> a different DFU version to distinguish DfuSe from standard DFU. I
> still need to get out the spec from the windows driver package to read
> up on it, but I trust you on
On Thu, Oct 27, 2011 at 12:38 AM, Stefan Schmidt
wrote:
> Di you try to do a git rebase -i on the branch and remove or squash
> some of the commits you want to get rid of? Due to the merges and your
> other changes I expect not all of the rebases will work. Maybe some
> will work out easily though
On Mon, Oct 24, 2011 at 6:42 PM, Stefan Schmidt
wrote:
> No problems showed up during my tests. All four patches have been
> applied and pushed.
Thanks for testing and applying!
> That only leaves the DfuSe branch outstanding for now. I peaked into
> it but did not really started reviewing yet.
On Mon, Oct 24, 2011 at 1:23 PM, Stefan Schmidt
wrote:
>> Right, there is the DfuSe support in the dfuse-libusb-1.0 branch
>> (updated since), then there are three patches in master-patches
>> branch:
>>
>> main: Make descriptor helper functions more generic
>>
>> dfu-util.1: --device opti
On Mon, Oct 24, 2011 at 12:05 PM, Stefan Schmidt
wrote:
> Hello.
>
> On Thu, 2011-10-06 at 13:29, Stefan Schmidt wrote:
>> On Wed, 2011-10-05 at 21:52, Tormod Volden wrote:
>> >
>> > The code for supporting ST Microelectronics DFU extensions (DfuSe) is
>> &g
Hi,
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 com
From: Tormod Volden
If the device has the bitWillDetach set it will detach and reattach
itself to the USB bus after receiving the DETACH request, and the
host computer should not issue a USB reset.
Also make sure the descriptor structures containing these
flags are initialized to zero, for the
On Sun, Sep 18, 2011 at 11:20 AM, Tormod Volden wrote:
> In fact there is not much difference between 1.0 and 1.1 so we can
> safely say we support both. There is the added bitWillDetach in 1.1
> that we might want to incorporate, by extending or replacing the
> final_reset option han
From: Tormod Volden
There is an extra DFU state check after the transfer size has been
determined. The order should not matter so move it around.
Signed-off-by: Tormod Volden
---
If you are already testing, please test this as well. Maybe this block
is not needed at all. I wonder if anyone is
On Sat, Sep 24, 2011 at 2:15 PM, Stefan Schmidt wrote:
>> It will also be very helpful to have the dfu-util -v -v ... output
>> from each device, so I can see which paths are being taken, and over
>> time reduce some cargo-cult. This should ideally be updated after each
>> release we make.
>
> Hmm,
On Sat, Sep 24, 2011 at 1:48 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> For the sake of reusability, do not refer to our dfu_if
> structures. This also makes it more clear what these functions
> are acting upon. Rename these functions slightly.
Oops, the renaming was alre
On Sat, Sep 24, 2011 at 12:50 PM, Stefan Schmidt wrote:
> I picked up your idea of keeping lsusb logs of the device in the git
> repo. A first patch that adds logs for all devices plus a short readme
> that describes what I know about the DFU device side implementations
> on this devices just hit t
From: Tormod Volden
Signed-off-by: Tormod Volden
---
It was like this even in the first code commit.
doc/dfu-util.1 |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/doc/dfu-util.1 b/doc/dfu-util.1
index e286cf2..c3aea4c 100644
--- a/doc/dfu-util.1
+++ b/doc
From: Tormod Volden
For the sake of reusability, do not refer to our dfu_if
structures. This also makes it more clear what these functions
are acting upon. Rename these functions slightly.
Signed-off-by: Tormod Volden
---
As you can see we use on the active configuration in some cases,
for
On Sat, Sep 24, 2011 at 12:50 PM, Stefan Schmidt wrote:
> I picked up your idea of keeping lsusb logs of the device in the git
> repo. A first patch that adds logs for all devices plus a short readme
> that describes what I know about the DFU device side implementations
> on this devices just hit t
From: Tormod Volden
Previously we only retrieved the DFU mode descriptor and only if the
user had not specified the transfer size option.
We will try to get the run-time mode descriptor as cached by libusb,
without asking the device (which would upset e.g. the Freerunner).
This way we can
On Mon, Sep 19, 2011 at 10:39 PM, mahendra panpalia
wrote:
> ANYONE PLEASE
> How to unsubscribe rhis list?
If the openmoko developers are tired of dfu-util discussions, we can
always move to a new list :)
However Mahendra, if you are not interested in openmoko either, follow
the link at the bott
On Mon, Sep 19, 2011 at 8:51 PM, Tormod Volden wrote:
>> Interesting I thought the bitWillDetach was the only addition in the
>> 1.1 spec. Seems I have to read it again to fresh up knowledge about
>> it. :)
>
> There is not really much to it, it is the class and prot
From: Tormod Volden
So that we can avoid asking the device about it. In particular
the Freerunner does not like too much enquiries.
---
Stefan (or someone with a Freerunner),
can you please test this patch against current master?
Please report back if it found the "cached USB_DT_DFU&qu
On Mon, Sep 19, 2011 at 6:58 PM, Stefan Schmidt wrote:
>> Thanks for testing! Interesting. So they do not provide a functional
>> descriptor at all? Can you please send me the sudo lsusb -v output
>> from these devices? Do you have access to their firmware code?
>
> lsusb output is attched.
Thanks
From: Tormod Volden
There is an extra DFU state check after the transfer size has been
determined. The order should not matter so move it around.
Signed-off-by: Tormod Volden
---
This is just to make the code cleaner and better structured.
It has been like this since the start of the git
From: Tormod Volden
It should exist both in run-time and DFU mode, and should
report the transfer size.
Also print out the device DFU version as reported by this
descriptor. For DFU 1.0 devices the descriptor does not contain
the version field, so set it to 1.00 if the field is missing.
Some
On Sat, Sep 17, 2011 at 6:40 PM, Stefan Schmidt wrote:
>
> Sadly this seems not to be the case. I gave this one a spin and it
> broke several devices for me. :(
>
> I don't have time to debug this the next days but should hopefully be
> able to do it end of next week. So I applied all but this patc
From: Tormod Volden
It should exist both in run-time and DFU mode, and should
report the transfer size.
Also print out the device DFU version as reported by the functional
descriptor. For DFU 1.0 devices the descriptor does not contain
the version field, so set it to 1.00 if the field is
From: Tormod Volden
Signed-off-by: Tormod Volden
---
Now that we have switched to libusb-1.0...
src/main.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/src/main.c b/src/main.c
index 0312603..819e26c 100644
--- a/src/main.c
+++ b/src/main.c
@@ -58,14 +58,6
From: Tormod Volden
USB IDs are always printed in hex and any 0x prefix makes it
just harder to read, recognize or cut and paste.
Signed-off-by: Tormod Volden
---
Also rather cosmetic.
src/main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/main.c b/src
From: Tormod Volden
Signed-off-by: Tormod Volden
---
Hi,
Another series of patches. This first primarly for cosmetics.
Tormod
src/main.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/main.c b/src/main.c
index 4a187b0..64c8d1a 100644
--- a
On Tue, Sep 6, 2011 at 7:48 PM, Stefan Schmidt wrote:
> What is the char count for the strings you get with the Dfuse device?
> Must be over 64 for sure as you hit this limitation, but are also over
> 128?
The Dfuse devices have no fixed length on this string, it depends on
the complexity of the m
On Tue, Sep 6, 2011 at 7:45 PM, Stefan Schmidt wrote:
>
> Curious how the Dfuse support will use it. :)
You don't want to know :) Actually the DfuSe devices report their
memory layout in this string!
Tormod
___
devel mailing list
devel@lists.openmoko.o
On Tue, Sep 6, 2011 at 7:34 PM, Stefan Schmidt wrote:
> All my devices here seem to signal the transfer size correctly. Would
> be nice if we could get rid of it long term. Maybe we should remove it
> after the next release and print out a warning if no size gets
> signalled from the device.
It al
From: Tormod Volden
The way we retrieve these strings we have to make sure the buffer
is big enough so we do not truncate the string.
A USB descriptor is limited to 255 bytes since its bLength field is
one byte wide. So it can theoretically contain 253 characters if
UTF-8 encoding is used. UTF
ed using UTF-16LE. USB 2.0
did specify that Unicode is to be used but it did not specify the
encoding."
On Wed, Aug 31, 2011 at 11:26 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> The way we retrieve these strings we just have to make sure the buffer
> is big enough to not
Stefan,
This and the other patches can also be pulled from or reviewed at
https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util in the
master-patches branch.
Tormod
On Thu, Sep 1, 2011 at 10:05 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> Make the --version output c
From: Tormod Volden
Make the --version output compatible with for instance help2man.
Print the version on normal invokation.
Also remove unreachable check for file name, getopt takes care of that.
Signed-off-by: Tormod Volden
---
v2: Move check for -D or -U before libusb initialisation. Drop
From: Tormod Volden
Make the --version output compatible with for instance help2man.
Also print the version on normal invokation.
Signed-off-by: Tormod Volden
---
What about this instead? It needed quite some reorganisation to avoid
using libusb (for instance by --list) before the command
On Thu, Sep 1, 2011 at 12:22 AM, Timo Juhani Lindfors
wrote:
> Ok, I was only thinking about shell scripts that might want to verify
> the version number in a programmatic way.
>
> Even help2man that generates man pages from --help output also wants
> --version to work.
Yes, that could be useful.
On Wed, Aug 31, 2011 at 11:39 PM, Timo Juhani Lindfors
wrote:
> Hi,
>
> Tormod Volden writes:
>> " -h --help\t\t\tPrint this help message\n"
>> - " -V --version\t\t\tPrint the version number\n"
>
> Why this change? It
From: Tormod Volden
Limit the scope of some variables, get rid of others.
Continue as soon as possible on non-match.
---
src/main.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/src/main.c b/src/main.c
index 9fbaed9..e547a05 100644
--- a/src/main.c
From: Tormod Volden
---
src/dfu.h |1 +
src/main.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/dfu.h b/src/dfu.h
index 6d2347a..9e6fda7 100644
--- a/src/dfu.h
+++ b/src/dfu.h
@@ -96,6 +96,7 @@ struct dfu_if {
u_int8_t configuration;
u_int8_t
From: Tormod Volden
---
src/main.c | 62 +--
1 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/src/main.c b/src/main.c
index e547a05..9146920 100644
--- a/src/main.c
+++ b/src/main.c
@@ -190,34 +190,47 @@ static int
From: Tormod Volden
---
A series of patches for dfu-util.
The alternate interface name features in 4/5/6 will be needed for the
upcoming DfuSE support. Slowly getting there...
Cheers,
Tormod
src/main.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a
From: Tormod Volden
It is not a variable. Eventually we should get rid of it. All
supported devices should report their preferred transfer size.
---
src/main.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/main.c b/src/main.c
index aaad39a..9fbaed9 100644
From: Tormod Volden
The way we retrieve these strings we just have to make sure the buffer
is big enough to not truncate the string. I do not know if the USB
protocol sets any limit to the string length. If not, a possible TODO
would be to add a warning if the returned string filled the buffer
On Wed, Aug 31, 2011 at 7:20 PM, Stefan Schmidt wrote:
> Patch looks fine. Just wondering if you hit any problems without the
> context being set? Or did you do the change based on the comment that
> the context needs to be set?
No, it was just to make it consistent. The context was being used som
From: Tormod Volden
Also call libusb_exit() before exiting.
Signed-off-by: Tormod Volden
---
dfu-util patch.
Tormod
src/main.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/src/main.c b/src/main.c
index 1d03704..5f57bee 100644
--- a
From: Tormod Volden
For this the verbose variable was made global.
---
This is for the libusb-1.0 branch.
Can be useful to verify proper parsing of DFU files etc.
Tormod
src/dfu_load.c |6 ++
src/main.c |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a
From: Tormod Volden
If a DFU file suffix is detected, it will be stripped off and
not sent to the device.
Signed-off-by: Tormod Volden
---
This is version 2 of the patch.
Tormod
src/dfu_load.c | 39 +--
src/dfu_load.h |4 ++--
src/main.c |4
This also missed the list. Patch version 2 will follow.
Tormod
On Tue, May 24, 2011 at 8:45 AM, Stefan Schmidt wrote:
> Hello.
>
> On Mon, 2011-05-23 at 23:35, Tormod Volden wrote:
>> On Mon, May 23, 2011 at 7:46 PM, Stefan Schmidt wrote:
>> >> - while (bytes_sen
From: Tormod Volden
The new dfu_file structure is used to keep track of the download (or
upload) file. parse_dfu_suffix() will parse an (already opened) file and
populate the struct members corresponding to the DFU suffix fields.
The commit also includes some verification of the suffix fields
By my mistake (gmail defaults to Reply-to) the below did not get to
list. New version of the patch will follow.
Tormod
On Tue, May 24, 2011 at 8:55 AM, Stefan Schmidt wrote:
> Hello.
>
> On Mon, 2011-05-23 at 23:11, Tormod Volden wrote:
>> On Mon, May 23, 2011 at 7:39 PM, Stefa
ged into master.
>
> I spent some time on this at the weekend. It actually did work before
> in the libusb-1.0 branch. Your commit that fixed your device broke it
> for the freerunner:
>
> commit 6329fc0886049e0eb50c51e88b7fc52f056b83d4
> Author: Tormod Volden
> Date: Thu Feb
From: Tormod Volden
The new dfu_file structure is used to keep track of the download (or
upload) file. parse_dfu_suffix() will parse an (already opened) file and
populate the struct members corresponding to the DFU suffix fields.
The commit also includes some verification of the suffix fields
From: Tormod Volden
If a DFU file suffix is detected, it will be stripped off and
not sent to the device.
The length of the suffix is available in file.suffixlen so it
can be used to calculate how much of the file is left to send.
For this the download function call interface is changed to
On Fri, May 20, 2011 at 4:25 PM, Stefan Schmidt wrote:
>> -static int parse_vendprod(struct usb_vendprod *vp, const char *str)
>> +static void parse_vendprod(u_int16_t *vendor, u_int16_t *product, const
>> char *str)
>> {
>> - unsigned long vend, prod;
>> const char *colon;
>>
>> +
From: Tormod Volden
---
src/dfu.h | 24
src/main.c | 24
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/src/dfu.h b/src/dfu.h
index be879af..4bf88e9 100644
--- a/src/dfu.h
+++ b/src/dfu.h
@@ -57,6 +57,16 @@
#define
From: Tormod Volden
Prepares for some future enhancements like file suffix parsing,
so we can avoid opening the same file several times.
Also pass dif structure instead of separate usb handle and interface
when we call upload and download functions. At this point we are only
dealing with one
From: Tormod Volden
Allow filtering on vendor ID or product ID alone. Examples:
-d 1234:(filter on vendor ID alone)
-d :5678(filter on product ID, less useful)
-d 1234:5678(full ID, like before)
Since there were already separate DFU_IFF_VENDOR and DFU_IF_PRODUCT
match
From: Tormod Volden
---
src/dfu.c |9 -
src/dfu.h |8
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/src/dfu.c b/src/dfu.c
index 4bb30f9..e473784 100644
--- a/src/dfu.c
+++ b/src/dfu.c
@@ -24,15 +24,6 @@
#include
#include "dfu.h"
-/* DF
From: Tormod Volden
First get_first_dfu_device() fills in the dev and dev_handle
members, but only after get_first_dfu_if() the whole interface
information is filled in.
Signed-off-by: Tormod Volden
---
This solves the "Found Runtime: [:]" issue I tried to address
in
On Wed, May 18, 2011 at 11:27 AM, Stefan Schmidt wrote:
> I have to agree here. Tere is something fishy going on with populated
> dif in combination with print_dfu_if().
>
> It keeps crashing at me while the dfu operations like upload download,
> etc are still working fine with the dif struct. Its
On Wed, May 18, 2011 at 11:23 AM, Stefan Schmidt wrote:
> The libusb-1.0 branch works now with my freerunner and the other
> devices I have. The problem was related to the fact that the
> freerunner starts in runtime mode and I had introduced a bug in this
> part.
>
> I guess your device is already
On Fri, Mar 11, 2011 at 11:37 PM, Tormod Volden wrote:
> Also wondering about your USB_REQ_DFU_DETACH extension. Can you not
> use a zero-length DNLOAD to enter dfuMANIFEST-WAIT-RESET?
OK, I think I understand why: Your device is manifestation tolerant,
so it does not use the
dfuMANIFES
On Wed, Mar 9, 2011 at 10:14 AM, Bernard Blackham wrote:
>> On Wed, 2011-03-09 at 16:49, Bernard Blackham wrote:
>> > The DFU spec says that bwPollTimeout is the amount of time that
>> > should pass between DFU_GETSTATUS requests. If the status is
>> > already good, we do not need to sleep as we wi
, Feb 3, 2011 at 11:12 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> The dif is used for search parameters, and later for keeping the
> interface parameters. If the vendor and product fields were not
> used for searching, they were also not filled out, and the user
> would
1 - 100 of 118 matches
Mail list logo
