The Mystery Deepens: GNU Radio on Intel-Mac

GNU Radio
1

  • I can easily show on our brand new 20" Intel-iMac that a
    “recent” (Wednesday) SVN checkout of GNU Radio will compile, check,
    and install, but USB transport doesn’t work. On a similarly equipped
    PPC-Mac, USB transport does function (albeit slowly in comparison,
    maybe 1/2 the speed, w/ the Intel-iMac maxing out at 32 M-Bytes/s -
    which is good news for those moving to Intel-Macs).

  • I can also show on the same computer that a compile on a MacBook
    Pro (MBP) dated (checked out on) July 13 does allow for USB transport.

  • GNU Radio uses dynamic libraries, and one of those is LIBUSB (for
    the USB transport), and the installed version of LIBUSB was just
    performed this week from version 0.1.12 - the same as what’s
    installed on the MBP.

  • By changing a link in /usr from “local_old” (for the MBP compile
    from July 13) to “local_new” to the compile I did this week, the USB
    transport will either work or not (respectively). The “facts” thus
    far lead (past tense) me to believe that it was a change in GNU
    Radio’s software.

  • I then retrieved an archive of the actual source code for the
    “local_old” install from the MBP and dropped it onto the Intel-iMac.
    I then made everything anew from that codebase (from July 13, which
    worked before) … and … drum roll please … it DID NOT work!
    This now leads me to believe it was the change in XCode from 2.3 to
    2.4 (released August 11, which would be about the time folk started
    noticing oddness).

Since 2.3 is compatible with the Intel-Mac’s, I will revert the
install back to 2.3 to check out this theory (likely early next
week). Yet even more as testing goes further. - MLD

2

Hi Michael

I have XCode 2.2.1 on my macbook and the USRP is not working. I agree,
this is very, very strange…

Thomas

3

Thanks Michael, I am still on XCode 2.3 and will now definitely refrain
from upgrading, for now. I can probably be talked into deliberately
breaking my working MBP install by upgrading for testing purposes.

Cheers,
Jan

4

As long as you have the XCode 2.3 disk image, you can always
downgrade back when you’re done. There is an “uninstaller” provided
on the disk image; you’ll (for some unknown reason) need to reboot
after either the uninstall or the reinstall. Your trying 2.4 would
certainly add an interesting data point to the investigation. - MLD

5

I tested on my macbook with XCode 2.3. I installed libusb 0.1.12_0
with darwinports and got the latest GNURadio code. Starting the
benchmark_usb.py failed as before. So no luck here.

That’s good to know … I certainly won’t update the MacBook Pro
(MBP) to 2.4 just yet.

I’ve done more testing and am getting closer. I’ll email again once
I have a better handle one the actual issue(s). Right now, I can say
with -certainty- that it’s something to do with the USRP Firmware
(generated file: …/usrp/firmware/src/usrp2/std.ihx ) and SDCC, but
not LIBUSB; it might also involve XCode (gcc and related developer
tools), but that relationship is not yet clearly defined. I’m trying
to get access to the “working” MBP for further testing on its
specific installed toolbase. More as the investigation continues. - MLD

6

I tested on my macbook with XCode 2.3. I installed libusb 0.1.12_0
with darwinports and got the latest GNURadio code. Starting the
benchmark_usb.py failed as before. So no luck here.

Thomas

7

Intel-Mac users: Could you try something for me? I’ve attached a
file, which you would (1) extract: tar jxf std_ihx_works.tar.bz2; (2)
then move/copy into ${gnu_radio_prefix}/share/usrp/rev2/ and …/
rev4 . Then go into …/usrp/host/apps (any since July 13, 2006,
doesn’t matter as far as I can tell) and (make sure a USRP is
attached and powered up, then) try test_usrp_standard_tx and
test_usrp_standard_rx (with your favorite options). For me, this
works on both a MacBook Pro and 20" Intel-iMac.

This file is created by …/usrp/firmware/src/usrp2 by SDCC
compilation. The Intel-Mac compiled version of SDCC 2.6 has a bus
error during compiling “usb_common.c”, and even when I “overcome”
that error the file it produces (std.ihx) still doesn’t work. The
file I attached was created on July 13 on a MacBook Pro running (I
think) XCode 2.3 and (I know) DarwinPorts’ compiled and installed
SDCC 2.4.0 with my manual fix to get SDCC to compile. Compiling SDCC
2.4 (manually, since DarwinPorts no longer supports that version) on
the Intel-iMac doesn’t change the result of “std.ihx” compilation
(meaning the file “std.ihx” is exactly the same whether using the
July 13 code or a current SVN checkout. This implies to me that the
USRP’s firmware code for creating “std.ihx” hasn’t changed since July
13, and hence it’s not the USRP code which is an issue, but rather
the way SDCC is interpreting that code).

I will hopefully have access to the -known working- MacBook Pro
tomorrow to figure out what’s installed on it, and if I can recreate
SDCC 2.4 which seems to work, and if so what the deal is which is
breaking SDCC (or whatever the issue is, which still eludes me).

In the mean time, if anyone has thoughts of where else I could direct
my efforts on this front, I’d appreciate them. I’m truly at a loss
as to -how- SDCC can mess things up so royally. Others have
suggested an endianness problem … I really don’t know.

Thanks in advance for you assistance! - MLD

8

I’ve had a reply from 1 person that the “std.ihx” file -does- allow
the Intel-Mac to work properly with the USRP<->USB<->GR transports.
So I have kept experimenting, and come up with more statistics, but
maybe not any better knowledge of the underlying issue. Basically,
most statistics point to problems with XCode 2.4 for Intel-Mac; yet
some folks don’t have functionality using XCode 2.2.1 or 2.3, so
that’s not everything.

In the mean time, if you have an Intel-Mac and want to use GNU Radio,
you can download a -known working- pre-compiled version of SDCC
(2.4.0) for Intel-Mac’s from my GNU Radio WWW area (it’s about 1.88 MB).

< http://www.nd.edu/~mdickens/GNURadio/ >

Here are the added “statistics”:

  • I can recompile SDCC 2.4.0 (via DarwinPorts, with no updates for
    along time so it things SDCC 2.4.0 is current) on the -previously
    working- MacBook Pro (MBP) using XCode 2.4, and it no longer works.
    This is “good” since it confirms that XCode is an issue as I’ve been
    suspecting.

  • The “std.ihx” file can be moved from a PPC Mac or elsewhere, since
    it represents code to be uploaded to the FPGA (I assume). Hence the
    easiest way to get things going on the Intel-Mac is to do a current
    SVN checkout on both that computer and some other non-Intel-Mac
    computer, then compile and install both, then move the file
    “{gr_prefix}/share/usrp/rev2/std.ihx” from the non-Intel-Mac to the
    Intel-Mac.

  • I can make a tarball of (already working on the MBP) SDCC 2.4.0,
    move it to the 20" iMac, untar and install it (into /opt/local …
    careful), and that install now works.

  • I can compile SDCC on the iMac using XCode 2.3 and it won’t create
    a “good” std.ihx file. This again points to XCode not compiling SDCC
    correctly, since clearly SDCC is functional and the original code is
    the same.