help needed with dfu-util issue on Freerunner

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

help needed with dfu-util issue on Freerunner

Tormod Volden
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-util 0.8) does not recognize the DFU interface on the Freerunner
when one alternative interface is specified to be programmed. However,
all DFU alternative interfaces are listed when running dfu-util -l.

It is not known if this problem occurs if the interface is specified
by its number instead of its name. This is one simple test to perform,
i.e. run use -a 6 instead of -a rootfs.

It has not been verified if the interface is recognized when using -a
6 or -a rootfs as a filter when simply listing interfaces, that is:
dfu-util -a 6 -l

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.

It would be a pity to drop support for the Freerunner, and I think it
is a simple bug to fix once we get someone with the hardware to test
it out.

Please also see
http://lists.gnumonks.org/pipermail/dfu-util/2014-July/000519.html

Best regards,
Tormod

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: help needed with dfu-util issue on Freerunner

Paul Fertser
Hi,

Tormod Volden <[hidden email]> writes:
> I am trying to find someone who is willing to try some debugging of
> dfu-util on their OpenMoko Freerunner.

Ok, will try it with NOR u-boot now.

One unrelated issue I've noticed so far is that libusb-1.0 detection is
not working properly on my Gentoo. The reason is that libusb_init()
function is actually present with -lusb (libusb-1.0.9) so pkg-config
test never runs, so CFLAGS are not set properly.

IMHO you should just switch to pkg-config for all the systems. FreeBSD
already provides an appropriate .pc file in base for quite some time,
and for earlier versions users can just add USB_CFLAGS and USB_LIBS to
the ./configure invocation manually. Windows users can install
pkg-config-lite. For crosscompiling something like [1] can be
used. OpenOCD does it this way and so far it seems like everybody's
happy enough with it:

http://sourceforge.net/p/openocd/code/ci/master/tree/configure.ac

[1] http://sourceforge.net/p/openocd/code/ci/master/tree/contrib/cross-build.sh
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[hidden email]

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: help needed with dfu-util issue on Freerunner

Paul Fertser
In reply to this post by Tormod Volden
Tormod Volden <[hidden email]> 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.

The reason is that initially freerunner's u-boot is in runtime mode, so
alt_name comparison fails the first time probe_devices() is invoked, so
dfu-util has no chance to continue and reset it from runtime to dfu
mode. A patch inline.

PS: regarding configure.ac, it's my strong enough impression that
MAINTAINER_MODE macro should be removed from there, it only adds
confusion and never does anything useful IMHO.

From 7af120685753890c6e8f0db1984c4665e4266b5d Mon Sep 17 00:00:00 2001
From: Paul Fertser <[hidden email]>
Date: Sun, 10 Aug 2014 14:22:15 +0400
Subject: [PATCH] dfu_util: ignore alt_index/alt_name specification in runtime
 mode

When the device is in runtime mode it needs to be reset first into DFU
mode for the list of alternate settings to appear, so unless it's
already in the right mode, matching on alt setting number or name
should be skipped.

Signed-off-by: Paul Fertser <[hidden email]>
---
 src/dfu_util.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/dfu_util.c b/src/dfu_util.c
index bb40e94..cc92c19 100644
--- a/src/dfu_util.c
+++ b/src/dfu_util.c
@@ -189,13 +189,17 @@ found_dfu:
  int dfu_mode;
 
  intf = &uif->altsetting[alt_idx];
- if (match_iface_alt_index > -1 && match_iface_alt_index != alt_idx)
- continue;
+
  if (intf->bInterfaceClass != 0xfe ||
     intf->bInterfaceSubClass != 1)
  continue;
 
  dfu_mode = (intf->bInterfaceProtocol == 2);
+
+ if (dfu_mode &&
+    match_iface_alt_index > -1 && match_iface_alt_index != alt_idx)
+ continue;
+
  if (dfu_mode) {
  if ((match_vendor_dfu >= 0 && match_vendor_dfu != desc->idVendor) ||
     (match_product_dfu >= 0 && match_product_dfu != desc->idProduct)) {
@@ -228,7 +232,8 @@ found_dfu:
  strcpy(serial_name, "UNKNOWN");
  libusb_close(devh);
 
- if (match_iface_alt_name != NULL && strcmp(alt_name, match_iface_alt_name))
+ if (dfu_mode &&
+    match_iface_alt_name != NULL && strcmp(alt_name, match_iface_alt_name))
  continue;
 
  if (dfu_mode) {
--
1.8.3.2

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: help needed with dfu-util issue on Freerunner

Tormod Volden
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.
>
> The reason is that initially freerunner's u-boot is in runtime mode, so
> alt_name comparison fails the first time probe_devices() is invoked, so
> dfu-util has no chance to continue and reset it from runtime to dfu
> mode. A patch inline.

Hi Paul,

Thanks a lot for investigating this! I am Cc'ing the dfu-util list and
preferably we move the conversation there.

So the freerunner does not list the alternate interfaces in runtime
mode? This is actually fine according to the DFU standard, but I
expected it to list them also in runtime mode. I had seen dfu-util -l
list them in earlier reports, but maybe the freerunner was already in
dfu mode in those cases and I missed that.

Can I ask you the favour to send me a lsusb -v dump both from runtime
and dfu mode? it would be good to keep for reference and we have a
device-logs folder for this.

Your patch looks fine, but I would appreciate testing from others on
the dfu-list who have devices that do the runtime/dfu mode switching
and use the alternate name/number matching.

(Paul's original post with patch can be seen non-garbled here:
http://lists.openmoko.org/pipermail/devel/2014-August/007296.html)

>
> PS: regarding configure.ac, it's my strong enough impression that
> MAINTAINER_MODE macro should be removed from there, it only adds
> confusion and never does anything useful IMHO.

I just searched a little for AM_MAINTAINER_MODE and I that see it has
been debated a lot. Looks like some recommend
AM_MAINTAINER_MODE([disabled]). Would that help? I don't know if it is
needed by some distributors, this could be cargo-cult for what I know.

Best regards,
Tormod


>
> From 7af120685753890c6e8f0db1984c4665e4266b5d Mon Sep 17 00:00:00 2001
> From: Paul Fertser <[hidden email]>
> Date: Sun, 10 Aug 2014 14:22:15 +0400
> Subject: [PATCH] dfu_util: ignore alt_index/alt_name specification in runtime
>  mode
>
> When the device is in runtime mode it needs to be reset first into DFU
> mode for the list of alternate settings to appear, so unless it's
> already in the right mode, matching on alt setting number or name
> should be skipped.
>
> Signed-off-by: Paul Fertser <[hidden email]>
> ---
>  src/dfu_util.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/src/dfu_util.c b/src/dfu_util.c
> index bb40e94..cc92c19 100644
> --- a/src/dfu_util.c
> +++ b/src/dfu_util.c
> @@ -189,13 +189,17 @@ found_dfu:
>                                 int dfu_mode;
>
>                                 intf = &uif->altsetting[alt_idx];
> -                               if (match_iface_alt_index > -1 && match_iface_alt_index != alt_idx)
> -                                       continue;
> +
>                                 if (intf->bInterfaceClass != 0xfe ||
>                                     intf->bInterfaceSubClass != 1)
>                                         continue;
>
>                                 dfu_mode = (intf->bInterfaceProtocol == 2);
> +
> +                               if (dfu_mode &&
> +                                   match_iface_alt_index > -1 && match_iface_alt_index != alt_idx)
> +                                       continue;
> +
>                                 if (dfu_mode) {
>                                         if ((match_vendor_dfu >= 0 && match_vendor_dfu != desc->idVendor) ||
>                                             (match_product_dfu >= 0 && match_product_dfu != desc->idProduct)) {
> @@ -228,7 +232,8 @@ found_dfu:
>                                         strcpy(serial_name, "UNKNOWN");
>                                 libusb_close(devh);
>
> -                               if (match_iface_alt_name != NULL && strcmp(alt_name, match_iface_alt_name))
> +                               if (dfu_mode &&
> +                                   match_iface_alt_name != NULL && strcmp(alt_name, match_iface_alt_name))
>                                         continue;
>
>                                 if (dfu_mode) {
> --
> 1.8.3.2

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: help needed with dfu-util issue on Freerunner

Paul Fertser
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 dfu-util version with known-to-be-broken openmoko support
would be a real SHAME :/

> Can I ask you the favour to send me a lsusb -v dump both from runtime
> and dfu mode? it would be good to keep for reference and we have a
> device-logs folder for this.

Attached.

> > PS: regarding configure.ac, it's my strong enough impression that
> > MAINTAINER_MODE macro should be removed from there, it only adds
> > confusion and never does anything useful IMHO.
>
> I just searched a little for AM_MAINTAINER_MODE and I that see it has
> been debated a lot. Looks like some recommend
> AM_MAINTAINER_MODE([disabled]). Would that help? I don't know if it is
> needed by some distributors, this could be cargo-cult for what I know.

Basically, non-maintainer mode means that autoconf doesn't create
rules to regenerate configure when configure.ac is changed. It's
supposed to benefit users who do not have autoconf installed but I can
hardly see how it can be so. If a user modifies configure.ac, he or
she clearly wants to have configure regenerated, so it's better to
have an error because of missing autoconf than to have the changes
silently ignored. So my conclusion was that the maintainer mode macro
should be removed altogether; this was done for OpenOCD about a year
ago, and the results were positive (consistent rules, less confusion).

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[hidden email]

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel

freerunner-nor-uboot-runtime.txt (6K) Download Attachment
freerunner-nor-uboot-dfu.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: help needed with dfu-util issue on Freerunner

Tormod Volden
On Sun, Aug 10, 2014 at 2:06 PM, Paul Fertser <[hidden email]> 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 dfu-util version with known-to-be-broken openmoko support
> would be a real SHAME :/
>
>> Can I ask you the favour to send me a lsusb -v dump both from runtime
>> and dfu mode? it would be good to keep for reference and we have a
>> device-logs folder for this.
>
> Attached.
>
>> > PS: regarding configure.ac, it's my strong enough impression that
>> > MAINTAINER_MODE macro should be removed from there, it only adds
>> > confusion and never does anything useful IMHO.
>>
>> I just searched a little for AM_MAINTAINER_MODE and I that see it has
>> been debated a lot. Looks like some recommend
>> AM_MAINTAINER_MODE([disabled]). Would that help? I don't know if it is
>> needed by some distributors, this could be cargo-cult for what I know.
>
> Basically, non-maintainer mode means that autoconf doesn't create
> rules to regenerate configure when configure.ac is changed. It's
> supposed to benefit users who do not have autoconf installed but I can
> hardly see how it can be so. If a user modifies configure.ac, he or
> she clearly wants to have configure regenerated, so it's better to
> have an error because of missing autoconf than to have the changes
> silently ignored. So my conclusion was that the maintainer mode macro
> should be removed altogether; this was done for OpenOCD about a year
> ago, and the results were positive (consistent rules, less confusion).
>

Thanks! I have pushed all this to git master.

Best regards,
Tormod

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: help needed with dfu-util issue on Freerunner

Paul Fertser
On Sun, Aug 10, 2014 at 02:50:04PM +0200, Tormod Volden wrote:
> Thanks! I have pushed all this to git master.

Thank you for your continued effort on dfu-util and also stm32flash :)

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[hidden email]

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Loading...