On Tue, Oct 11, 2011 at 6:37 AM, Peter Stuge <pe...@stuge.se> wrote: >> + AC_CHECK_HEADERS([libusb-1.0/libusb.h],[], >> + [AC_MSG_ERROR([libusb.h is required to build some OpenOCD driver(s)])]) > > Please use pkg-config. > > pkg-config(1) http://linux.die.net/man/1/pkg-config mentions the > autoconf macro to use: > > PKG_CHECK_MODULES(VARIABLE-PREFIX,MODULES[,ACTION-IF-FOUND,[ACTION-IF-NOT-FOUND]]) > > as well as the added variables that will be available. Suggest use: > > PKG_CHECK_MODULES([LIBUSB1], [libusb-1.0 >= 1.0.8])
Please also consider where pkg_config is usually not available, like in the case of MinGW under Windows. >> @@ -1426,7 +1425,7 @@ static struct jlink* jlink_usb_open() >> >> #if IS_WIN32 == 0 >> >> - usb_reset(dev); >> + libusb_reset_device(devh); > > Unsure. libusb_reset_device() shouldn't really need to be used in the > common case.. I remember this was necessary last time some of us were testing OpenOCD with J-Link. On the other hand, this may well be not necessary now but the best is to look at Segger J-Link utility and see if it issues a reset in the beginning or not. > (Also, libusb-1.0 works to some degree on Windows.) http://www.libusb.org/wiki/windows_backend#KnownRestrictions libusb_reset_device() does not work with the current WinUSB backend for libusb-1.0 Windows. The following codes are obviously hacky but you can see that any changes in these codes deserve great scrutiny. /* BE ***VERY CAREFUL*** ABOUT MAKING CHANGES IN THIS * AREA!!!!!!!!!!! The behavior of libusb is not completely * consistent across Windows, Linux, and Mac OS X platforms. * The actions taken in the following compiler conditionals may * not agree with published documentation for libusb, but were * found to be necessary through trials and tribulations. Even * little tweaks can break one or more platforms, so if you do * make changes test them carefully on all platforms before * committing them! */ #if IS_WIN32 == 0 usb_reset(dev); #if IS_DARWIN == 0 int timeout = 5; /* reopen jlink after usb_reset * on win32 this may take a second or two to re-enumerate */ int retval; while ((retval = jtag_usb_open(vids, pids, &dev)) != ERROR_OK) { usleep(1000); timeout--; if (!timeout) { break; } } if (ERROR_OK != retval) return NULL; #endif #endif >> @@ -1460,27 +1459,46 @@ static struct jlink* jlink_usb_open() > .. >> + dev = libusb_get_device(devh); >> + struct libusb_config_descriptor *config; >> + libusb_get_config_descriptor(dev, 0, &config); >> + >> + const struct libusb_interface *inter; >> + const struct libusb_interface_descriptor *interdesc; >> + const struct libusb_endpoint_descriptor *epdesc; >> + >> + for(int i=0; i<(int)config->bNumInterfaces; i++) >> + for(int j=0; j<inter->num_altsetting; j++) >> + for(int k=0; k<(int)interdesc->bNumEndpoints; k++) > > Is this necessary? Aren't the endpoint addresses always the same? No, not always the same. > Or does the driver support so many jlink devices with so many different > USB interface variants that there's no way to get around it? That is right, there are different version of J-Link with different endpoints configuration. > I'm thinking a little about how to best get your work into OpenOCD. > > I think the best way is to start with one driver, and send a patch > that changes only that one driver over to use libusb-1.0, but leaves > the existing ones untouched. This means that you may need to create > some duplicated functionality outside the driver, for drivers which > use libusb-1.0, but I think this is OK, it will not likely be any > significant amount of code, so be fairly quick to create, and not > take much place. Once it is in place, you and others can more easily > work on moving other drivers to libusb-1.0 in parallel. It's not at > all necessary that you are the only doing that work. I agree with this approach. UrJtag can be a reference as well, since it support either libusb-1.0, libusb-0.x/libusb-win32, or mix. It also supports either libftdi-1.0 or libftdi-0.x. http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=tree -- Xiaofan _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
