=== What is the SD Card for? ===

The SD Card hold the FPGA configuration and microprocessor firmware. You can also store data on the rest of the card, but that is currently not implemented in the firware.

=== Is the SD Card necessary? ===

The USRP2 needs to have the SD card plugged in to operate. And the SD card needs to be programmed with a valid FPGA configuration and firmware build. Without this the USRP2 does nothing but sit there. The SD card is NOT optional. If you put it in the slot on the USRP2 and power up the USRP2, you should see all 6 LEDs flash, and 2 will remain on. If you don't, then the card is not programmed properly.

=== Does the SD Card come programmed? ===

The SD card that came with the USRP2 is preprogrammed with a build which was the latest at the time when it shipped. The plastic case the SD card came in is marked with the rev of the build on the card.

Many who received a USRP2 got one marked "9/22/08". That build no longer works with the latest host code in SVN, so you will need to update the firmware on the card.

=== How do I change the firmware and fpga code on the SD Card? ===

To do this you need an SD card programmer. These are available from Ettus Research, or at your local electronics store. Here are the steps to upgrade the firmware: {{{
sudo u2_flash_tool --dev=/dev/XXXX -t s/w usrp2/firmware/txrx.bin -w
}}}

• /dev/XXXX has to be replaced with the device for the SD card reader. If you get this wrong YOU CAN OVERWRITE YOUR WHOLE HARD DRIVE, so be careful. If you are not sure, DON'T DO ANYTHING. On my machine, the device is /dev/sdb, but it is likely to be different on your machine. Before doing this, it is a good idea to run "df" to make sure that the device you are about to use is not mounted.

Here are the steps to upgrade the FPGA code on the SD card: {{{
sudo u2_flash_tool --dev=/dev/XXXX -t fpga u2_rev3.bin -w
}}}

• Build (requires proprietary tools) or download the FPGA bitstream. The current version as of 1 December 2008 is u2_rev3.bin. It can be downloaded from [http://gnuradio.org/releases/usrp2-bin/trunk/].
• Insert the SD card into your card reader.
• Run

To find out what XXXX is, you can either goto [http://vic.gedris.org/linux-UsbMassStorage/] which tells you to do the
following steps to determine which device you would like to flash.

'''1.''' Install sg3-utils package {{{
$sudo apt-get update
$sudo apt-get install sg3-utils
}}}

'''2.''' List the raw scsi- devices on your system {{{
$sudo sg_scan i
}}}
'''3.''' Have a look at the list printed out, and determine which SCSI device is most likely your USB- card reader/writer.

'''4.''' Run sg_map to see what SCSI- device is associated with the USB sdcard r/w- device. {{{
$sudo sg_map
}}}

=== Does the USRP2 require its own ethernet port? Does it have to be gigabit? ===

It is strongly recommended that the USRP2 be connected directly to the host computer via gigabit ethernet. You can use a switch, but your system's main network connection should be separate. Also, operation at 10 or 100 mbps instead of 1 Gbps is not currently supported. The hardware is capable, but the current FPGA verilog code disables it for a variety of reasons.

=== Any hints for getting started? In particular, what needs to be done to talk to the usrp2 via the ethernet? ===

The first step is to update to the latest svn for the entire gnuradio tree, and get it all installed. Then, run:

{{{
find_usrps
}}}
in the usrp2/host/apps directory. You'll need to tell it which ethernet port to use if the USRP2 is not on eth0. The program should tell you if it found USRP2s.

=== What is a good basic app to test the USRP2 ===

Run

{{{
usrp2_fft.py
}}}
which is found in gr-utils and should also be installed in your path if you did a make install on the full tree. This will give you a basic spectrum analyzer display. Run {{{
usrp2_fft.py -h
}}}
for a list of options.

=== When I'm trying to look at more data than the computer can handle, the console prints "S" characters. What does that signify? Do O or U still apply as on the USRP1? ===

S means that the PC is seeing 2 successive packets which do not have 2 successive sequence numbers. This means that the host computer has dropped the packets in between. It is essentially the equivalent of an overrun. The USRP2 does not actually overrun, however, since it is not throttled by the host computer.

=== How do I compile the firmware for the aeMB RISC processor? ===

You'll need to download or build the gcc toolchain first. If you're on x86 or x86_64 linux, we've got a binary tarball that you can download and unpack into /opt.

==== Downloading and installing prebuilt x86 binary ====

$ wget http://gnuradio.org/tools/mb-gcc-4.1.1.gr2.i386.tar.gz

Once you've downloaded the tarball,

{{{
$ sudo bash

1. cd /opt
2. tar xzvf <path-to-tarball>
   }}}

Then add /opt/microblaze/bin to PATH and you're good to go.

==== Building the toolchain from source ====

If you want to build from source you'll need to download the EDK source and our patch, and compile away.
Note that compilation of the compiler fails if using gcc 4.3. We're not planning on fixing this bug. {{{
$ svn export http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch
$ wget http://gnuradio.org/tools/EDK101_GPL_GNU_src.tar.gz
$ tar -xzvf EDK101_GPL_GNU_src.tar.gz
$ patch -p1 <mb-gcc-4.1.1-gr-1.patch
$ cd Xilinx_EDK_GNU_10.1i/mb
$ /bin/bash ./build_binutils.sh
$ /bin/bash ./build_gcc.sh
$ cp -r release/lin/mb /opt/microblaze
}}}

(Older directions at http://www.aeste.net/index.php?q=node/16. Doesn't include patch that reduces size of libgcc 64-bit support routines.)

=== Can you also provide details concerning the debug port? ===

The debug port is a standard Mictor connector which is often used with logic analyzers from Agilent and Tektronix. It has 2 clock pins and 32 data pins. All 34 of those are directly connected to the FPGA, so you can do whatever you want with them.

If you plug in a BasicRX (or LFRX) and a BasicTX (or LFTX), you will have an additional 32 bits of IO which can also be used for debugging. This gives a total of 64 bits plus 2 clocks for debug.

=== Is there a JTAG port? ===

Yes, there is a standard JTAG header on the board connected to the FPGA and a CPLD, but you may not need it. Since the FPGA is programmed from the SD Card by the bootstrapping CPLD, the main utility of the JTAG port is to reprogram the CPLD. You may be able to use the JTAG port with !ChipScope.

=== I would like to interface to the expansion port, and connect the USRP2 to a Virtex 5 SXT eval board. I am looking for any documentation concerning this port, especially how it is tied into the the FPGA, if that is the case. ===

The expansion port is pretty straightforward. It uses a serial-attached SCSI (mini-SAS) cable. The cable has 4 lanes. Each lane consists of 1 differential pair input and 1 differential pair output. All lanes are AC (capacitor) coupled. The 4 lanes are allocated as follows:

1 - High-speed SERDES, 2 gbps 8B10B encoded. This interface is handled by a TLK2701 from TI, and it connects to the FPGA. You should be able to connect this interface to the RocketIO GTP/GTX transceivers on the virtex 5. Also, see the usrp2/fpga/serdes directory in the SVN repository to see how we handle the interface and protocol, framing, and flow control.

2 - 10 MHz clock reference

3 - Digital IO, connected directly to LVDS IOs on the FPGA. We currently have this set up to do time syncing, but you can do whatever you like with it.

4 - Unused

=== Can the USRP2 be used by a non-root user? ===

The code that talks to the USRP2 uses raw socket access (SOCK_RAW) on the ethernet port. This allows the use of a custom ethertype rather than building on a higher level protocol like IP or UDP. The kernel does not allow anyone but root to use raw sockets. This is unlikely to change any time soon. Other tools that use raw sockets must also be run as root or are suid (like ping).

It is possible to allow suid access to the USRP2 by making usrp2_socket_opener suid root. This allows us to use the least privileges possible on all other programs, and usrp2_socket_opener is a nice short program that can easily be audited. Example:

{{{
sudo chmod u+s /usr/local/bin/usrp2_socket_opener
}}}

Note that if you do a make install again it may overwrite your usrp2_socket_opener, and then it won't have the permissions set anymore. You can avoid this by putting the suid copy in your ~/bin directory, which won't be overwritten every time.