On Sun, Feb 27, 2011 at 11:39 PM, Almohanad F. [email protected]
I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue.
I’ve triedbitbaking Philip’s GNU Radio 3.2.1 recipe and the compilation
fails because of the libusb-0.1.12 link, more specifically the
“libusb-gnur.a” library. For some reason GCC is expecting the library to
have the “-fPIC” flag passed when building the library which doesn’t make
sense since it’s trying to link against a static library and not a shared
librar … it was complaining about an ARM_MOV or something like that
assembly command. To my understanding the libtool included in the libusb
should make sure that such confusion doesn’t happen which in using GCC 4.3
was not an issue but with the GCC 4.5 included in the new tree is an issue.
UHD uses libusb-1.0 and does not support libusb-0.1. Despite some
similarities in the API, version 1.0 is a complete rewrite there is no
compatibility or relation between versions. In that sense, the
gnuradio 3.2 recipe is completely unrelated to UHD.
I also tried incorporating the libusb fix against the GNU Radio GIT recipe
but the configure stage fails because gnuradio can’t find the
“USB_BULK_WRITE” function in the libusb library from libusb-0.1.12 which
when I looked is actually there. When I bypass the configure check for
USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio
3.2.1. I feel like the libusb-0.1.12 static library is corrupt for some
reason more specifically I think libtool might be the culprit.
If you are using libusb-0.1 and the gnuradio driver, you generally
don’t want to be using the mentioned libusb calls, which are
synchronous (slow). Normally, with libusb-0.1, the control and setup
functions go through libusb, while data flows through a separate OS
specific implementation - usbdevfs in the case of Linux. The only time
you should be seeing usb_bulk_write is when configure falls back to
the synchronous calls in the absence of any “fast” version. Now the
Linux implementation does have some evil bits, so perhaps this isn’t
I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might
explain why I can receive but I can’t write using the UHD driver. The
libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use
libusb-0.1.12? an older or newer version maybe? did it use a different
Again, usb_bulk_write and libusb-0.1.12 have no relation to UHD.
I need to find a way to pass the -fPIC flag to the configure stage of
libusb-0.1.12 unfortunately I can’t seem to find an easy way to do it and
I’m about to head out of town for a few days. Other than that doese anyone
have any suggestion?
In UHD with libusb-1.0, sends and receives are treated similarly (USB
is host driven) where pre-allocated buffers are submitted and
retrieved from the device. The difference is mainly in flags and
endpoint settings; the problem, IMO, is unlikely to be build related.
Of course, that doesn’t provide any insight into why this is only
coming up on the Beagle.
I’d like to recreate this issue on my newly setup E100, but, at the
moment, I’m not seeing any USB devices, and I think I just bricked my
FPGA. So I need to get a little bit more settled until I can try out
additional things. Perhaps later this week…