Introduction

14 June 2019: This post has been updated to the current REDHAWK version, 2.2.2, and Rocko.

In this post we’ll cover a little bit of OpenEmbedded (OE) as well as Geon’s progression towards a layer that can be used to build REDHAWK SDR 2.2.2 embedded platforms based on Geon’s meta-redhawk-sdr layer. Our test target is the Ettus Research E310.

If you’ve come for the buffet, keep reading. If you just want dessert, scroll past the first few sections to get to the build process or just the pre-build disk image.

If you need immediate support for building this target, with the current version of REDHAWK, please contact us.

What’s the Big Deal?

The usual paradigm for using some Devices with REDHAWK is to install a driver of some kind onto an Intel-based host capable of running REDHAWK and that driver. The driver then either connects to the hardware locally or across the netework and exposes it as a Device to the REDHAWK Domain. This is the usual paradigm if you’ve ever used the REDHAWK SDR USRP_UHD Device with the Ettus Research N210, as shown in the graphic here.

Also in the graphic above, the Ettus E310 is different in that it has a Linux operating system running locally with the UHD drivers present that you would normally install onto some other host. This gives us a great opportunity then to embed REDHAWK SDR, locally to the Ettus system hardware, while still exposting the exact same FrontEnd Interfaces 2.0 -compliant, REDHAWK SDR -compatible interface.

Not sold yet on why this is great?

These new platforms from Ettus and others are coming with embedded Linux distributions running on SoC cores that are wrapped in high-performance FPGA fabric. This means we can not only embed REDHAWK, but looking forward, we can also anticipate a time (very soon) when these small platforms are also very high-performance and flexible processors in our REDHAWK SDR Domains.

Overview

Over the last couple of years, a few of us have dabbled in various ways of installing REDHAWK onto an embedded platform. We’ve installed it on a couple of Raspberry Pi variants, a Beagle Bone Black, and a handful of Xilinx Zynq platforms all with success, but the process was invariably a manual one. Especially in the later case with PetaLinux being the bare-metal distribution of choice for Xilinx at the time, the process really begins with cross-compiling your own compilers, etc. before you ever get to the point of patching and compiling REDHAWK itself.

Naturally then when we got our hands on an Ettus Research E310, we started looking at ways to get REDHAWK SDR onto it since it’s a Zynq -based platform running Linux, and the REDHAWK SDR community already has a USRP_UHD FEI 2.0 compliant Device published.

The first question then is how does one either get or build the filesystem for the E310. Luckily (for all of us), the Ettus team provides a solid example of an OpenEmbedded -based build process, with several features, as part of their USRP manual. You can find the manual linked here. The next question then is how to get REDHAWK SDR 2.0 into a layer that works with that build process.

Ettus E310 + REDHAWK SDR

First I want to give a huge thanks to Philip Balister at Ettus Research (who doubles as a supporter of the OE community). Through his mentorship and their team’s clear design example, this effort was shaped into what it is now.

Notes on System Configuration

Your choice of build environment can alter significantly the probability of success when building with OE. For my building and testing with OE, I used a Mint 17 64-bit virtual machine with 4 cores, 8 GB RAM, and 100 GB of disk space. Until I increased to 8 GB RAM, I was having psuedo-random build failures for the larger packages (e.g., compiler errors related to building toolchains). Also the actual process for building everything prior to packaging into an image would routinely consume up to 30 GB, so you can get away with less than 100 GB if needed.

The Procedure

Next, as mentioned above the USRP Hardware Driver and USRP Manual includes instructions for how to build the E310’s filesystem image using OE and BitBake, found here. However, at the time of this update (14 June 2019), those instructions are out of date. Rather than referencing their manifest, use ours from https://github.com/Geontech/e300-manifest on the rocko branch. Once you have made that change and otherwise followed the first 3 steps (ending with a the TEMPLATECONF... line), change directories to the top level containing all of the layers (meta-oe, meta-sdr, etc.).

git clone https://github.com/GeonTech/meta-redhawk-sdr

Important: Please read.

This installs Geon’s meta-redhawk-sdr layer into the top-level path.

Next you need to add that path to the BBLAYERS variable found in the build/conf/bblayers.conf file. For example if you are building in a top-level path /oe-workspace your BBLAYERS should be updated to look like this:

BBLAYERS ?= " \
  /oe-workspace/e300-oe-build/oe-core/meta \
  /oe-workspace/e300-oe-build/oe-core/../meta-ettus/e100-bsp \
  /oe-workspace/e300-oe-build/oe-core/../meta-ettus/e300-bsp \
  /oe-workspace/e300-oe-build/oe-core/../meta-ettus/common \
  /oe-workspace/e300-oe-build/oe-core/../meta-xilinx \
  /oe-workspace/e300-oe-build/oe-core/../meta-oe/meta-oe \
  /oe-workspace/e300-oe-build/oe-core/../meta-oe/meta-networking \
  /oe-workspace/e300-oe-build/oe-core/../meta-oe/meta-python \
  /oe-workspace/e300-oe-build/oe-core/../meta-oe/meta-filesystems \
  /oe-workspace/e300-oe-build/oe-core/../meta-sdr \
  /oe-workspace/e300-oe-build/oe-core/../meta-redhawk-sdr \
  "

Note: the only change here is the last line after ... meta-sdr \.

The default configuration for the E310 build is to remove work files once they are no longer needed. This will cause trouble when packaging the files into a disk image unless you are using one of Ettus’ own image definitions (which we won’t be, directly). We’re using the redhawk-usrp-uhd-image defined in meta-redhawk-sdr/recipes-images/images. Therefore to your build/conf/local.conf find the RM_WORK_EXCLUDE variable and add this image name to it (i.e., add redhawk-usrp-uhd-image).

From your build folder, set the MACHINE environment variable to ettus-e3xx-sg3 and run bitbake redhawk-usrp-uhd-image. A few hours later, you should end up with a file in tmp/deploy/images/ettus-e3xx-sg3 named redhawk-usrp-uhd-image-ettus-e3xx-sg3.wic.

Just Dessert

Don’t be too hard on yourself for wanting to skip forward the few hours it will take to cross-compile everything; it is however a very worthwhile effort to see how it all fits together.

Here is a compressed USRP UHD disk image that, once decompressed, can be written to an 8 GB SD card to deploy your E310 as a REDHAWK SDR FEI 2.0-compliant Device. Once decompressed, copy it to your SD card in the usual way:

dd if=redhawk-usrp-uhd-image-ettus-e3xx-sg3.wic of=/dev/sdb bs=1M && sync

Note: This assumes your SD card is at /dev/sdb and is empty. On occasion attempting to overwrite an existing image using this method resulted in a currupt root filesystem.

Connecting to a Domain

It is possible to stand up the Domain locally on the Node and its default network configuration will link to it, but let’s be honest: that’s not nearly as interesting as having the sensor join an active Domain, right?

The resulting configuration is looking for a REDHAWK Domain named REDHAWK_DEV, which you’ll recall is the usual default installation instructions. So first, follow those instructions if you do not already have a Domain running somewhere. If you are installing on a VM, be sure to bridge your network interfaces so that the Domain isn’t hidden behind a NAT layer, as that might cause you more headaches.

Next, noting especially the instructions for distributed systems, we need to configure your Domain as well as this Node to communicate. In your Domain system’s /etc/omniORB.cfg, update it to use the Domain’s external IP address (i.e., the one that this node will connect to). You may need to reset your omniORB services after this on the Domain by clearing the logs, as su, using $OSSIEHOME/bin/cleanomni.

Note: You may need to disable your Domain machine’s firewall before proceeding.

Accordingly, also update the same file on the Node’s SD card to point at the same address. The Node will handle cleaning the log files out when it boots up so you do not need to do anything else in that regard.

With both the Domain and Node configured, ensure the Node’s network configuration is compatible with your network. If you are using DHCP to assign addresses, you can go on since that is the image’s default. Otherwise you need to make appropriate changes to the /etc/network/interfaces to adjust its configuration on the SD card.

Now the fun part.

On the Domain system, start the REDHAWK_DEV Domain using either the IDE or from a terminal. If you choose the IDE, right-click on the Target SDR and choose Launch Domain. If using a terminal window, call nodeBooter -D and then in an IDE attach to it in the usual way. In either case, ensure the domain is called REDHAWK_DEV.

Plug the SD card into the E310, and the E310 into your network. Power up the E310; you may need to press-and-hold the power button.

It might be worthwhile to you to also plug in the serial cable so that you can ensure it did in-fact boot (screen /dev/ttyUSB0 115200, depending on your configuration). The root user has no password. If you’re successful, one of the last log messages you will see on the Node is:

INFO: nodebooter - Running as daemon

Moreover, if you’re successful, you’ll see the E310 join the Domain:

From here, you can create allocations against the RX_DIGITIZERs manually or using a Waveform of your choosing from varioius sources. Please note, sometimes it does take a moment for the E310 to begin outputting samples depending on what your allocation stated.

Also for the time being the captured data is being fed up through the FPGA fabric to the processor before ultimately being wrapped and exported by the USRP_UHD as BULKIO within REDHAWK. This is going to limit us (for now) on raw performance, but this is a great first step on our road to easily making these great devices REDHAWK Compatible, for starters, and OpenCPI (soon).

Some Node Notes

Why is the node called -ALL?

One of the features of our REDHAWK SDR OE layer is the node-deployer recipe found under the recipes-devices; it facilitates creating REDHAWK Nodes using existing definitions… We’ll come back to that in a moment.

The Devices provided in our REDHAWK SDR OE layer configure not only the Device’s XML files but also executes the Node configuration scripts that each of the core asset Devices provides. So when you add to your local.conf an IMAGE_FEATURES += "gpp" for example, it will include the GPP as well as a Node configured to launch just that GPP. These generated Nodes do not include auto-start /etc/init.d scripts, so you can use them to test each individual installed Device as you add more.

Consequently, there is a template autotools recipe included as well for easily adding new Devices.

What the node-deployer recipe does is insert a pair of scripts. One groups those various Node definitions together into a new Node on the first boot-up. Thereafter, the other script starts that conglomerate Node each time the system starts. So in essence when you have all the Devices for your system working, simply include the node-deployer recipe to lump those capabilities into a single layer. Done!

Note: Alternative to including it in your configuration, the node-deployer recipe is already included as part of the redhawk-node-image to facilitate creating one’s own Node OE images with arbitrarily specified Devices. See the redhawk-usrp-uhd-image (used above) as an example for how to leverage this as a means to define an image simply as a set of your own Devices.

Coming Soon…

What’s next? OpenCPI.

Soon we will be releasing instructions for also combining OpenCPI into a build image so that we can start enhancing the performance of these and other FPGA-based sensors with the same ease described above for REDHAWK itself. Stay tuned for information on that partnership.

Demo Videos

We have added a new video to our YouTube channel with a few demos using the E310 as well as the Ettus N210. We start by showing the FEI capability the E310 gains by merging this OE layer with theirs, and then follow on by showing the N210 and E310 working together in the same Domain for a cognitive radio application.

IMPORTANT: This video has not been updated to reflect the steps above, which changed on 14 June 2019. Please treat this page as the correct set of instructions.

For those without access to YouTube, [here is a direct download link].

: https://www.geontech.com/yocto-builds/videos/REDHAWK-E310-Demo.m4v