USRP Hardware Driver and USRP Manual  Version:
UHD and USRP Manual

Comparative features list

The E320 is a 2-channel transmitter/receiver based on the AD9361 transceiver IC. It is a monolithic board with one AD9361 and provides two RF channels.

  • TX band: 47 MHz to 6.0 GHz
  • RX band: 70 MHz to 6.0 GHz
  • 56 MHz of instantaneous bandwidth
  • 2 RX DDC chains in FPGA
  • 2 TX DUC chain in FPGA
  • Hardware Capabilities:
    • Single SFP+ Transceivers (can be used with 1 GigE, 10 GigE, and Aurora)
    • External PPS input
    • External 10 MHz input
    • Internal GPSDO for timing, location, and 10 MHz reference clock + PPS
    • External GPIO Connector with UHD API control
    • External USB Connection for built-in JTAG debugger and serial console
    • Xilinx Zynq SoC with dual-core ARM Cortex A9 (Speedgrade 3) and Kintex-7 FPGA (XC7Z045)
  • Software Capabilities:
  • FPGA Capabilities:
    • RFNoC capability


The Zynq CPU/FPGA and host operating system

The main CPU of the E320 is a Xilinx Zynq SoC XC7Z045. It is both a dual-core ARM Cortex A9 CPU and Kintex-7 FPGA on a single die. The CPU is clocked at 1GHz (speedgrade 3).

The programmable logic (PL, or FPGA) section of the SoC is responsible for handling all sampling data, the 1/10 GigE network connections, and any other high-speed utility such as custom RFNoC logic. The processing system (PS, or CPU) is running a custom-build OpenEmbedded-based Linux operating system. The OS is responsible for all the device and peripheral management, such as running MPM (see section The Module Peripheral Manager (MPM) Architecture), configuring the network interfaces, running local UHD sessions, etc.

It is possible to connect to the host OS either via SSH or serial console (see sections SSH connection and Serial connection, respectively).

The STM32 microcontroller

The STM32 microcontroller controls various low-level features of the E320 series motherboard: It controls the power sequencing, reads out fan speeds and some of the temperature sensors. It is connected to the Zynq via an I2C bus.

It is possible to log into the STM32 using the serial interface (see Connecting to the microcontroller). This will allow certain low-level controls, such as remote power cycling should the CPU have become unresponsive for whatever reason.

The SD card

The E320 uses a micro SD card as its main storage. The entire root file system (Linux kernel, libraries) and any user data are stored on this SD card.

The SD card is partitioned into four partitions:

  1. Boot partition (contains the bootloader). This partition usually does not require any modifications.
  2. A data partition, mounted in /data. This is the only partition that is not erased during file system updates.
  1. Two identical system partitions (root file systems). These contain the operating system and the home directory (anything mounted under / that is not the data or boot partition). The reason there are two of these is to enable remote updates: An update running on one partition can update the other one without any effect to the currently running system. Note that the system partitions are erased during updates and are thus unsuitable for permanently storing information.

Note: It is possible to access the currently inactive root file system by mounting it. After logging into the device using serial console or SSH (see the following two sections), run the following commands:

$ mkdir temp
$ mount /dev/mmcblk0p3 temp
$ ls temp # You are now accessing the idle partition:
bin   data  etc   lib         media  proc  sbin  tmp    usr
boot  dev   home  lost+found  mnt    run   sys   uboot  var

The device node in the mount command will likely differ, depending on which partition is currently already mounted.

Getting started

This will run you through the first steps relevant to getting your USRP E320 up and running. Note: This guide was creating on an Ubuntu machine, and other distributions or OS's may have different names/methods.

Assembling the E320

Unlike the X300 or N200 series, there is no assembly of required since it is a monolithic board.


  • Connect power and network
  • Read security settings
  • Connect clocking (if required)

Updating the file system

Before doing any major work with a newly acquired USRP E320, it is recommended to update the file system. For the OEM/Board-only version of E320, the SD card is physically accessible and filesystem update can be accomplished directly by using Mender or externally by manually writing an image onto a micro SD card and inserting it. For the enclosure version of E320, Mender update is required as there is no direct physical access to the device. For details on using Mender, see Section Mender: Remote update capability .

Manual updating is simply loading an image on the micro SD card. The first step in that process is to obtain an image.

To obtain the default micro SD card image for a specific version of UHD, install that version of UHD ( or later) on a host system with Internet access and run:

$ uhd_images_downloader -t e320 -t sdimg

The image will be downloaded to <UHD_INSTALL_DIR>/share/uhd/images/usrp_e320_fs.sdimg, where <UHD_INSTALL_DIR> is the UHD installation directory.

To load an image onto the micro SD card, connect the card to the host and run:

$ sudo dd if=<YOUR_IMAGE> of=/dev/<YOUR_SD_CARD> bs=1M

The <YOUR_IMAGE> is the path to the micro SD card image (i.e.<UHD_INSTALL_DIR>/share/uhd/images/usrp_e320_fs.sdimg).

The <YOUR_SD_CARD> device node depends on your operating system and which other devices are plugged in. Typical values are sdb or mmcblk0.

CAUTION: The Linux utility dd or bmap can cause unrecoverable data loss if the incorrect disk is selected, or if the parameters are input incorrectly. Ensure you have selected the correct input and output parameters for your system configuration.

The micro SD card used can be the original SD card shipped with the device or another one that is at least 16 GB in size.

Serial connection

It is possible to gain root access to the device using a serial terminal emulator. Most Linux, OSX, or other Unix flavours have a tool called 'screen' which can be used for this purpose, by running the following command:

$ sudo screen /dev/ttyUSB2 115200

In this command, we prepend 'sudo' to elevate user privileges (by default, accessing serial ports is not available to regular users), we specify the device node (in this case, /dev/ttyUSB2), and the baud rate (115200).

The exact device node depends on your operating system's driver and other USB devices that might be already connected. Modern Linux systems offer alternatives to simply trying device nodes; instead, the OS might have a directory of symlinks under /dev/serial/by-id:

$ ls /dev/serial/by-id

Note: Exact names depend on the host operating system version and may differ.

Every E320 device connected to USB will by default show up as four different devices. The devices labeled "USB_to_UART_Bridge_Controller" are the devices that offer a serial prompt. The one with the if01 suffix connects to Linux, whereas the one with if00 suffix connects to the STM32 microcontroller. If you have multiple E320 devices connected, you may have to try out multiple devices. In this case, to use this symlink instead of the raw device node address, modify the command above to:

$ sudo screen /dev/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A6C-if01-port0 115200

You should be presented with a shell prompt similar to the following:


On this prompt, you can enter any Linux command available. Using the default configuration, the serial console will also show all kernel log messages (unlike when using SSH, for example), and give access to the boot loader (U-boot prompt). This can be used to debug kernel or bootloader issues more efficiently than when logged in via SSH.

Connecting to the microcontroller

The STM32 microcontroller (which controls the power sequencing, among other things) also has a serial console available. To connect to the microcontroller, use the other UART device. In the example above:

$ sudo screen /dev/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0 115200

It provides a very simple prompt. The command 'help' will list all available commands. A direct connection to the microcontroller can be used to hard-reset the device without physically accessing it (i.e., emulating a power button press) and other low-level diagnostics.

SSH connection

The USRP E320 devices have two network connections: One SFP port, and an RJ-45 connector. The latter is by default configured by DHCP; by plugging it into into 1 Gigabit switch on a DHCP-capable network, it will get assigned an IP address and thus be accessible via ssh.

In case your network setup does not include a DHCP server, refer to the section Serial connection. A serial login can be used to assign an IP address manually.

After the device obtained an IP address you can log in from a Linux or OSX machine by typing:

$ ssh root@ni-e320-311FE00 # Replace with your actual device name!

Depending on your network setup, using a .local domain may work:

$ ssh root@ni-e320-311FE00.local

Of course, you can also connect to the IP address directly if you know it (or set it manually using the serial console).

Note: The device's hostname is derived from its serial number by default (ni-e320-<SERIAL>). You can change the hostname by modifying the /etc/hostname file and rebooting.

On Microsoft Windows, the connection can be established using a tool such as Putty, by selecting a username of root without password.

Like with the serial console, you should be presented with a prompt like the following:


Network Connectivity

The RJ45 port (eth0) comes up with a default configuration of DHCP, that will request a network address from your DHCP server (if available on your network).

The SFP+ (sfp0) port is configured with static address

The configuration for the sfp0 port is stored in /etc/systemd/networkd/

For configuration please refer to the systemd-networkd manual pages

The factory settings are as follows:

eth0 (DHCP):




sfp0 (static):




Note: Care needs to be taken when editing these files on the device, since vi / vim sometimes generates undo files (e.g. /etc/systemd/networkd/, that systemd-networkd might accidentally pick up.

Note: Temporarily setting the IP addresses via ifconfig etc will only change the value until the next reboot or reload of the FPGA image.

Security-related settings

The E320 ships without a root password set. It is possible to ssh into the device by simply connecting as root, and thus gaining access to all subsystems. To set a password, run the command

$ passwd

on the device.

Updating the FPGA

Updating the FPGA follows the same procedure as other USRPs. Use the uhd_image_loader command line utility to upload a new FPGA image onto the device. The command can be run on the host to load the image via RJ-45 network connection or it can be run on the device.

A common reason to update the FPGA image is in the case of a UHD/FPGA compat number mismatch (for example, if UHD has been updated, and now expects a newer version of the FPGA than is on the device). In this case, simply run

$ uhd_images_downloader

to update the local cache of FPGA images. Then, run

$ uhd_image_loader --args type=e3xx,addr=ni-e320-311fe00

to update the FPGA using the default settings. Replace ni-e320-311fe00 in the addr with the correct device address. If a custom FPGA image is targeted for uploading, use the --fpga-path command line argument. Run

$ uhd_image_loader --help

to see a full list of command line options. Note that updating the FPGA image will force a reload of the FPGA, which will temporarily take down the SFP network interfaces (and temporary settings, such as applied via ifconfig on the command line, will be lost).

Using an E320 USRP from UHD

Like any other USRP, all E320 USRPs are controlled by the UHD software. To integrate a USRP E320 into your C++ application, you would generate a UHD device in the same way you would for any other USRP:

auto usrp = uhd::usrp::multi_usrp::make("type=e3xx");

For a list of which arguments can be passed into make(), see Section Device arguments.

Device arguments

Key Description Example Value
addr IPv4 address of primary SFP+ port to connect to. addr=
find_all When using broadcast, find all devices, even if unreachable via CHDR. find_all=1
master_clock_rate Master Clock Rate in Hz. Default is 16 MHz. master_clock_rate=30.72e6
serialize_init Force serial initialization of daughterboards. serialize_init=1
skip_dram Ignore DRAM FIFO block. Connect TX streamers straight into DUC or radio. skip_dram=1
skip_ddc Ignore DDC block. Connect Rx streamers straight into radio. skip_ddc=1
skip_duc Ignore DUC block. Connect Tx streamers or DRAM straight into radio. skip_duc=1
skip_init Skip the initialization process for the device. skip_init=1
ref_clk_freq Specify the external reference clock frequency, default is internal (20 MHz). ref_clk_freq=10e6
init_cals Specify the bitmask for initial calibrations of the RFIC. init_cals=BASIC
init_cals_timeout Timeout for initial calibrations in milliseconds. init_cals_timeout=45000
discovery_port Override default value for MPM discovery port. discovery_port=49700
rpc_port Override default value for MPM RPC port. rpc_port=49701
tracking_cals Specify the bitmask for tracking calibrations of the RFIC. tracking_cals=ALL

The sensor API

Like other USRPs, the E320 series has RF and motherboard sensors. When using uhd::usrp::multi_usrp, the following API calls are relevant to interact with the sensor API:

The following motherboard sensors are always available:

  • temp_internal: temperature (in C) of Temperature Sensor on board
  • temp_fpga: temperature (in C) of the FPGA die
  • temp_rf_channelA: temperature (in C) near power amplifier RF A
  • temp_rf_channelB: temperature (in C) near power amplifier RF B
  • temp_main_power: temperature (in C) near power supply
  • gps_locked: GPS lock
  • gps_time: GPS time in seconds sin ce the epch
  • gps_tpv: A TPV report from GPSd serialized as JSON
  • gps_sky: A SKY report from GPSd serialized as JSON
  • ref_locked: This will check that all the daughterboards have locked to the external/internal reference clock.
  • fan: get fan speed (in rpm)

Remote Management

Mender: Remote update capability

Mender is a third-party software that enables remote updating of the root file system without physically accessing the device (see also the Mender website). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Mender servers can be self-hosted, or hosted by Mender (see for pricing and availability).

When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted (note: every SD card comes with two separate root file system partitions, only one is ever used at a single time). Any data stored on that partition will be permanently lost. After updating that partition, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched (which presumably is in a working state). Another update can be launched now to correct the previous, failed update, until it works. See also Section The SD card.

To initiate an update from the device itself, download a Mender artifact containing the update itself. These are files with a .mender suffix.

Then run mender on the command line:

$ mender -rootfs /path/to/latest.mender

The artifact can also be stored on a remote server:

$ mender -rootfs

This procedure will take a while. After mender has logged a successful update, reboot the device:

$ reboot

If the reboot worked, and the device seems functional, commit the changes so the boot loader knows to permanently boot into this partition:

$ mender -commit

To identify the currently installed Mender artifact from the command line, the following file can be queried:

$ cat /etc/mender/artifact_info

If you are running a hosted server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is simple way to update groups of rack-mounted USRPs with custom file systems.

Salt: Remote configuration management and execution

Salt (also known as SaltStack, see Salt Website) is a Python-based tool for maintaining fleets of remote devices. It can be used to manage USRP E320 remotely for all types of settings that are not controlled by UHD. For example, if an operator would like to reset the root password on multiple devices, or install custom software, this tool might be a suitable choice.

Salt is a third-party project with its own documentation, which should be consulted for configuring it. However, the Salt minion is installed by default on every E320 device. To start it, simply log on to the device and run:

$ systemctl start salt-minion

To permanently enable it at every boot, run (this won't by itself launch the salt-minion):

$ systemctl enable salt-minion

To make use of Salt, both the device needs to be configured (the "minion") and, typically, a server to act as the Salt master. Refer to the Salt documentation on how to configure the minion and the master. A typical sequence to get started will look like this:

  1. Install the salt-master package on the server (e.g. by running apt install salt-master if the server is an Ubuntu system), and make sure the Salt master is running.
  2. Add the network address / hostname of that server to the /etc/salt/minion file on the device by editing the master: line.
  3. Launch the Salt minion on the USRP by running the command systemctl start salt-minion.
  4. The minion will try to connect to the master. You need to authorize the minion by running salt-key -a $hostname where $hostname is the name of the minion.
  5. Once the device is authorized, you can try various commands to see if the communication was established:

    $ [sudo] salt '*' ni-n3xx-$serial: True $ [sudo] salt '*' network.interfaces



    hwaddr: 02:00:03:11:fe:00 inet:


    address: xx.xx.xx.xx broadcast: xx.xx.xx.xx label: eth0 netmask: up: True


Theory of Operation

E320 is on the MPM architecture (see also: The Module Peripheral Manager (MPM) Architecture). Inside the Linux operating system running on the ARM cores, there is hardware daemon which needs to be active in order for the device to function as a USRP (it is enabled to run by default).

A large portion of hardware-specific setup is handled by the daemon.

Modifying and compiling UHD and MPM for the E320

E320 devices ship with all relevant software installed on the SD card. Updating UHD and/or MPM on the SD card is typically easiest done by updating the filesystem image (see Section Mender: Remote update capability). However, it is certainly possible to compile UHD and MPM by hand, e.g., in order to modify and try out changes without having to build entire filesystems in between. At Ettus R&D, this mode of operation is often used for rapid iteration cycles.

Compiling MPM natively

In general, compiling natively is not a recommended way of compiling code for the ARM processors. However, in the case of MPM, the amount of C++ code that needs to be compiled is very little, and a full compile of MPM will take a few minutes even on the device. First, you need to get a copy of the MPM source code onto your device. If you have an internet connection, you can use git to pull it directly from the Ettus repository (all commands are run on the device itself, inside the home directory):

$ git clone

You can also SSHFS it from another computer:

$ mkdir uhd # Create a new, empty directory called uhd
$ sshfs user@yourcomputer:src/uhd uhd # This will mount ~/src/uhd from the remote machine to ~/uhd on the device

Now, create a build directory and use the regular cmake/make procedure to kick off a build. It can be advantageous (especially for slow network connections) to create the build directory outside of the repository directory:

$ mkdir build_mpm
$ cd build_mpm # You are now in /home/root/build_mpm
$ cmake ../uhd/mpm
$ make -j2 install # This will take several minutes

Note that this overwrites your system MPM. You can install MPM to another location by specifying -DCMAKE_INSTALL_PREFIX, but make sure to update all of your paths appropriately.

If you prefer cross-compiling MPM the same way as UHD, refer to the following sections and adapt the instructions for UHD appropriately.

Obtaining an SDK

The recommended way to develop software for the E320 is to cross-compile. By running the compiles on a desktop or laptop computer, you will be able to speed up compile times considerably (compiling UHD natively for the E320 would take many hours).

SDKs are distributed along with other binaries. They contain a cross-compiler, a cross-linker, a cross-debugger, and all the libraries available on the device to mirror its environment.

To unpack the SDK, simply execute it after downloading it:

$ cd /usr/local/share/uhd/images # Change this to where your images are stored
$ ./

If this doesn't work, the executable permissions of the file might have been lost (this can occur with some versions of Python). In that case, add those permissions back before executing the .sh file:

$ chmod +x

Executing the .sh file will prompt you for an installation path. Please ensure you have sufficient disk space, as each of the SDKs may require several gigabytes of disk space (depending on the image flavor selected).

This will allow you to compile UHD as well as (depending on the image flavor) other software.

Please note, that while several toolchains can be installed in parallel, they have to be installed to different directories.

SDK Usage

Having installed the toolchain in the last step, in order to build software for your device open a new shell and type:

$ . $SDKPATH/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi

This will modify the PATH, CC, CXX etc, environment variables and allow you to compile software for your USRP E320 device. To verify all went well you can try:

$ $CC -dumpmachine

which should return 'arm-oe-linux-gnueabi'.

Building UHD

  1. Obtain the UHD source code via git or tarball
  2. Set up your environment as described in SDK Usage
  3. Type the following in the build directory (assuming a build in host/build):
     $ cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake -DCMAKE_INSTALL_PREFIX=/usr .. # Add any CMake options you desire
     $ make # You can run make -j12 to compile on 12 processes at once

Note: The UHD you are cross-compiling will not run on your host computer (the one where you're doing the development). Compiling UHD regularly on your host computer (with MPMD enabled) will allow you to talk to your E320.

Building GNU Radio

  1. Obtain the GNU Radio source code via git or tarball
  2. Set up your environment as described in SDK Usage
  3. Use the following commands to create a build directory, configure and compile gnuradio. You only need create the build directory once.
$ mkdir build-arm
$ cd build-arm
$ cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake \-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_GR_VOCODER=OFF -DENABLE_GR_ATSC=OFF \
-DENABLE_GR_DTV=OFF -DENABLE_DOXYGEN=OFF ../ # Append any CMake options you desire

Several GNU Radio components depend on running binaries built for the build machine during compile. These binaries can be built and used for cross compiling, but this is an advanced topic.

E320-specific Features

Front and Rear Panel

Like the USRP X300 and N310 series, E320 has connectors on both the front and back panel. The back panel holds the power connector, all network connections, USB connections for serial console (see Serial connection), JTAG and peripherals, and front-panel GPIO.

The front panel is used for all RF connections, SMA connectors for GPS antenna input, 10 MHz external clock reference.

The connectors are labeled RF A and RF B and are powered by the two channels of AD9361 RFIC.

FPGA Register Map

The following tables describe how FPGA registers are mapped into the PS. This is for reference only, most users will not even have to know about this table.

AXI Slave Address Range UIO Label Description
Slave 0 4000_0000 - 4000_3fff - Ethernet DMA SFP
Slave 1 4000_4000 - 4000_4fff misc-enet-regs Ethernet registers SFP
Slave 2 4001_0000 - 4001_3fff mboard-regs Motherboard control
Slave 3 4001_4000 - 4001_41ff dboard-regs Daughterboard control
E320 Register Map
AXI Slave Module Address Name Read/Write Description
Slave 0 axi_eth_dma 4000_0000 - 4000_4fff Ethernet DMA RW See Linux Driver
Slave 1 e320_mgt_io_core 4000_4000 PORT_INFO RO SFP port information
[31:24] COMPAT_NUM RO -
[23:18] 6'h0 RO -
[17] activity RO -
[16] link_up RO -
[15:8] mgt_protocol RO 0 - None, 1 - 1G, 2 - XG, 3 - Aurora
[7:0] PORTNUM RO -
e320_mgt_io_core 4000_4004 MAC_CTRL_STATUS RW Control 10gE and Aurora mac
[0] ctrl_tx_enable (PROTOCOL = "10GbE")RW-
[0] bist_checker_en (PROTOCOL = "Aurora")RW-
[1] bist_gen_en RW -
[2] bist_loopback_enRW -
[8:3] bist_gen_rate RW -
[9] phy_areset RW -
[10] mac_clear RW -
e320_mgt_io_core 4000_4008 PHY_CTRL_STATUS RW Phy reset control
e320_mgt_io_core 4000_400C MAC_LED_CTL RW Used by ethtool to indicate port
[1] identify_enable RW -
[0] identify_value RW -
mdio_master 4000_4010 MDIO_DATA RW -
4000_4014 MDIO_ADDR RW -
4000_4018 MDIO_OP RW -
e320_mgt_io_core 4000_4020 AURORA_OVERUNS RO -
eth_switch 4000_5000 MAC_LSB RW Device MAC LSB
4000_5004 MAC_MSB RW Device MAC MSB
4000_6000 IP RW Device IP
4000_6004 PORT1, PORT0 RW Device UDP port
eth_dispatch 4000_6008 [1] ndest, [0] bcastRW Enable Crossover
4000_600c [1] my_icmp_type, [0] my_icmp_code-
eth_switch 4000_6010 BRIDGE_MAC_LSB Bridge SFP ports in ARM
4000_6014 BRIDGE_MAC_MSB -
4000_6018 BRIDGE_IP -
4000_6020 BRIDGE_EN -
chdr_eth_framer 4000_6108 onwards LOCAL_DST_IP W Destination IP, MAC, UDP for Outgoing Packet for 256 SIDs
4000_6208 onwards LOCAL_DST_UDP_MAC_MSBW Destination MAC for outgoing packets (MSB)
4000_6308 onwards LOCAL_DST_MAC_LSBW Destination MAC for outgoing packets (LSB)
4000_7000 onwards REMOTE_DST_IP W Destination IP, MAC, UDP for Outgoing Packet for 16 local addrs
4000_7400 onwards REMOTE_DST_UDP_MAC_HIW Destination MAC (MSB)
4000_7800 onwards REMOTE_DST_MAC_LOW

Destination MAC (LSB)

Slave 2 e320_core 4001_0000 COMPAT_NUM R FPGA Compat Number
[31:16] Major RO -
[15:0] Minor RO -
4001_0004 DATESTAMP RO -
4001_0008 GIT_HASH RO -
4001_000C SCRATCH RO -
4001_0010 NUM_CE RO Number of Computation Engines (RFNoC Blocks)
4001_0014 NUM_IO_CE RO Number of fixed IO CEs - Radios + DMA Fifo
4001_0018 CLOCK_CTRL -
[0] pps select (internal 10 MHz)RWOne-hot encoded pps_select to use the internal PPS from GPSDO
[1] pps select (external 10 MHz)RWOne-hot encoded pps_select to use the external PPS.
[2] refclk_select (internal/external 10 MHz)RWrefclk_select=0 for internal (GPSDO) 10 MHz, refclk_sel=1 for external 10 MHz.
[11:0] FPGA temperatureRO -
4001_0020 BUS_CLK_RATE RO -
4001_0024 BUS_CLK_COUNT RO -
4001_0028 SFP_PORT_INFO RO Same as port_info register 0x4000_4000
4001_002C FP_GPIO_CTRL RW -
4001_0030 FP_GPIO_MASTER RW -
4001_0034 FP_GPIO_RADIO_SRC RW -
4001_0038 GPS_CTRL RW -
[0] GPS_PWR_EN RW Power on GPSDO
[1] GPS_RST_N RW -
4001_003C GPS_STATUS RO GPSDO Status
[0] GPS_LOCK RO Returns 1 if GPSDO is locked
4001_0040 DBOARD_CTRL RO -


axi_crossbar 4001_1010 XBAR_VERSION RO See crossbar kernel driver
4001_1014 XBAR_NUM_PORTS RO See crossbar kernel driver
4001_1018 LOCAL_ADDR RW See crossbar kernel driver
4001_1020 remote_offset WO XBAR settings reg
4001_1420 local_offset WO

XBAR settings reg

Slave 4 4001_40004001_41FFDaughterboard Registers- Don't exist now. TBD