My "crude" fix was just to comment out 1740 and that works but only if we
get rid of the reset on line 1718 also. After that reset Linux appears to
re-call set_configuration, or the reset itself is the problem.
I don't know about lightweight reset, what I saw on the USB snoop was that
the set_configuration was the issue. I wrote test code to walk through the
initialization using PyUSB and immediately after set_configuration, it
would hang. The reset on line 1718 also as a byproduct caused a USB control
packet with set_configuration had the same effect.
Most of this discussion is about whether we can get rid of
set_configuration, and it appears we can for all or almost all cases.
However, the current code also has a block #if IS_WIN == 0 that tries to
reset the device, presumably to help recover it into a known state. I had
to #if 0 that block out as well.
Is there a #define that tells us that we are using libusb-0.1? If so, we
could add a conditional compile to only do set_configuration on windows and
when using libusb-0.1.
For the reset however, perhaps the safest thing is to base it on either the
magic serial number or a specific TCL flag or something.
On Thu, Sep 11, 2014 at 3:13 AM, Xiaofan Chen <[email protected]> wrote:
> On Thu, Sep 11, 2014 at 4:15 PM, Paul Fertser <[email protected]> wrote:
> > On Thu, Sep 11, 2014 at 04:01:33PM +0800, Xiaofan Chen wrote:
> >> 1738 /* usb_set_configuration required under win32 */
> >> 1739 struct jtag_libusb_device *udev = jtag_libusb_get_device(devh);
> >> +++ #if IS_WIN32 == 1
> >> 1740 jtag_libusb_set_configuration(devh, 0);
> >> +++ #endif
> >> 1741 jtag_libusb_claim_interface(devh, 0);
> >
> > But what if libusbK driver will be made to work exactly like Linux's
> > generic usb code one day? Shouldn't it be possible to express the idea
> > "set the configuration if needed, but do not reset the device!" in
> > libusb-1.0 API in an OS-agnostic way?
>
> Actually that is the way currently in libusb-1.0 implementation
> tries to do, maybe with the exception of Windows (and probably NetBSD as
> well
> but there is no developer for NetBSD anyway, I tried the OpenBSD
> code under NetBSD and it worked and that was why it was added).
>
> I will ask in the libusb mailing list about the Windows implementation.
> From the code, it does seem to generate I/O and may cause problem.
>
> https://github.com/libusb/libusb/blob/master/libusb/os/windows_usb.c
>
> * from http://msdn.microsoft.com/en-us/library/ms793522.aspx: "The port
> driver
> * does not currently expose a service that allows higher-level drivers to
> set
> * the configuration."
> */
> static int windows_set_configuration(struct libusb_device_handle
> *dev_handle, int config)
> {
> struct windows_device_priv *priv = _device_priv(dev_handle->dev);
> int r = LIBUSB_SUCCESS;
> if (config >= USB_MAXCONFIG)
> return LIBUSB_ERROR_INVALID_PARAM;
> r = libusb_control_transfer(dev_handle, LIBUSB_ENDPOINT_OUT |
> LIBUSB_REQUEST_TYPE_STANDARD | LIBUSB_RECIPIENT_DEVICE,
> LIBUSB_REQUEST_SET_CONFIGURATION, (uint16_t)config,
> 0, NULL, 0, 1000);
> if (r == LIBUSB_SUCCESS) {
> priv->active_config = (uint8_t)config;
> }
> return r;
> }
>
> > I personally would prefer to not
> > bother at all with libusb-0.1 specific issues.
>
> I actually agree with you as well. But maybe some people still
> use OpenSolaris (?) (but who cares?).
>
> If the developers agree to remove libusb-0.1 API support,
> I think that will be a good move.
>
> > I do not see any issues
> > with libusb-win32 backend mentioned at [1], probably jlink will work
> > ok with it?
> >
> > [1] https://github.com/libusb/libusb/wiki/Windows
>
> It might work. The main issues are with USB Composite Device
> https://github.com/libusbx/libusbx/issues?q=libusb-win32+is%3Aopen
> https://github.com/libusbx/libusbx/issues?q=libusb0.sys+is%3Aopen
>
> But one of the issue is not related to USB Composite Device.
> https://github.com/libusbx/libusbx/issues/87
>
>
> --
> Xiaofan
>
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
