« Previous - Version 38/43 (diff) - Next » - Current version
Elvis Dowson, 07/14/2010 08:48 am


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. You can always find the latest released versions at http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries . To build your own firmware you will need to install the Microblaze tools http://gnuradio.org/tools. To build the FPGA yourself you'll need to use the full (pay) version of Xilinx ISE 10.1.03.

Some SD Cards shipped in Nov and Dec of 2009 (Blue, 2GB Patriot brand) will not work. Go to http://ettus.com/flash for more details on how to get a replacement.

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

The SD card does NOT contain a filesystem, and you will NOT be able to read or write it using normal tools.

To change the firmware and FPGA code, 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:

  1. Build the firmware by running make in the gnuradio/usrp2 directory
  2. Insert the SD card into the card reader, and the card reader into a USB port on your computer
  3. Run
    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:

  1. Build (requires proprietary tools) or download the FPGA bitstream. The current version as of 7th May 2010 is u2_rev3-rel-20100507.bin. It can be downloaded from http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries
  2. Insert the SD card into your card reader.
  3. Run
    sudo u2_flash_tool --dev=/dev/XXXX -t fpga u2_rev3.bin -w

To find out what XXXX is, you can 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
    

Which firmware should I use with my USRP2?

For the USRP2 + WBX combination use the txrx_wbx_raw_eth_20100608.bin firmware. The default firmware that comes with the USRP2 SD card needs to be replaced with the txrx_wbx firmware to work the WBX module, with the SMA connector connected to the TX/RX port on the WBX module.

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.

What Gigabit Ethernet Interface do you suggest?

The first question to answer is how you want to attach the gigabit ethernet interface to the computer:

PCI Express (also known as PCIe) Strongly suggested, as it is the fastest interface commonly available.
PCI Plain old PCI is 32 bits wide and 33 MHz. This is not really fast enough to handle the full USRP2 capabilities, but will work for most users. 64 Bit and/or 66 MHz variations of PCI would be better, but are not very common.
PCI-X This is NOT the same as PCI Express. It is faster than plain PCI, and so is preferable to it, but is not very common.
USB 2.0 This is simply nowhere near fast enough for our purposes and its use is strongly discouraged. If you wish to use USB 2.0, we suggest using it with the USRP1.
PCMCIA/CardBUS CardBUS is a plain old PCI bus with a PCMCIA card form factor. See PCI above.
ExpressCard ExpressCard is PCI Express in a card form factor. These should work fine as long as the drivers exist for your card. Some of these cards (perhaps all) will cause the kernel to "oops", or crash your whole machine, if you pull them out while in operation, so be careful.

Most Gigabit Ethernet interfaces built onto a motherboard or into a laptop are either PCI Express (mostly newer systems) or plain PCI (older systems).

For further info, see USRP2GigEReports

When transmitting, my USRP2 runs for a little while and then dies. What is wrong?

Your Ethernet interface is not autonegotiating flow control properly. You can force the correct settings on your ethernet card by running the following command:

ethtool -A eth0 rx on

You should replace "eth0" with the ethernet interface you are actually using, usually eth0 or eth1. You will probably need to run this command every time you boot, and will probably need to run it as root.

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
# cd /opt
# tar xzvf <path-to-tarball>

Then add /opt/microblaze/bin to PATH ( export PATH=$PATH:/opt/microblaze/bin ) and you're good to go.

NOTE -- This may not work on Fedora 10 x64_64. See below.

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.)

On Fedora 10, you will need to install compat-gcc-34-3.4.6-9.x86_64 and then run the build commands like this:

$ CC=/usr/bin/x86_64-redhat-linux-gcc34 /bin/bash ./build_binutils.sh
$ CC=/usr/bin/x86_64-redhat-linux-gcc34 /bin/bash ./build_gcc.sh

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.

To enable real-time scheduling for non-root users, edit /etc/security/limits.conf and add this line:

@usrp  - rtprio 50

make sure that your user is a member of group usrp, then logout and back in.

How do I use the DBSRX receive daughterboard with the USRP2?

In order to use the DBSRX receive daughterboard with the USRP2, you will need to modify the the DBSRX hardware and reprogram its eeprom. Here are instruction for how to do so.