Embedded Development with GNU Radio

Introduction to the Development Cycle

The graphic above describes the different levels of development we can work on for our embedded GNU Radio systems.

• On the far left are where the real embedded experts work to develop the Board Support Package (BSP) that allows us to boot and run on various different embedded boards. Most of us will never touch this space as GNU Radio developers.

• The next level is the basic OpenEmbedded (OE) level of development. This is the base Operating System (OS) and GNU Radio libraries. On this level, we provide the OS will all of the tools and libraries for a working GNU Radio system. The GNU Radio development team and the Embedded Working group takes care of this level. General embedded developers are unlikely to need to work on this level of development, though feedback to the Embedded Working Group is useful to keep the system up-to-date with the proper support infrastructure.

• Developers then work on the OE software development kit (SDR) provided by the GNU Radio development team. Developers use the SDK to build their own GNU Radio applications and any Out-of-Tree projects for specific tasks. Results at this level are applications and/or libraries for use on other, similar embedded systems and ready for deployment.
  • PyBOMBS support is an optional level of team development integration. Before a package is built and installed as part of a standard OE system provided by GNU Radio, PyBOMBS can move quicker to provide team-level support to a new product. (We are still working out the full details of this level and style of support.)

• Deployment is the final stage where development is completed and we have the OS, libraries, and apps built for our specific deployment needs.

This page is dedicated to understanding the development cycle and how to use the tools to accomplish your embedded task with GNU Radio. We expect most developers to care about using the SDKs for their embedded systems and not the details for how to create your own OE distribution or SDK. For those of you who require more detailed knowledge or insist on using OE yourselves, we provide information about that as well.

OpenEmbedded Background

GNU Radio has been working with OpenEmbedded on developing a way to build and deploy GNU Radio Linux systems on embedded devices. The purpose of using OpenEmbedded, or OE, is to give us a stable base and consistent behavior between devices. There are three main components to know about when using OE:

1. The rootfs: this is the file system of the embedded device, often placed on the root partition of an SD Card or micro SD Card.
2. The boot system: very device-specific to load the initial kernel and boot into the rootfs. Generally using u-boot.
3. The SDK: the software development kit provides the necessary libraries and executables to cross-compile projects targeted to the embedded device but built using a more powerful, capable desktop computer.

Device Support

To date, GNU Radio has mostly focused on the following devices:

• TI OMAP 3 (ARM Cortex-A8)
• Xilinx Zynq (see Zynq for details of working with this chip)
• TI Keystone II (Work-in-progress for GSoC 2014; see Keystone2)
• BeagleBoard (ARM Cortex-A8) and other Beagle-like products
• Developing:
  • nVidia Jetson TK1
  • Wandboard (quad)
  • ODroid

We have heard of success stories with other embedded devices such as the RaspberryPi. We have not direct support for these, however, but there are members of the GNU Radio community who can help. See the MailingLists to look for help.

Common development tasks

• Install and configure SDK
• Hardware setup notes
• Cross compile GNU Radio and install on target
• Cross compile an OOT and install on target

Tips and tricks for working with embedded things

• Copy an image file to the SD card
• Serial Port Setup
• Mount the device's file system on the development machine
• Configure a static IP
• Enable X11 forwarding

Initial Setup

Once we're at this point, we should be able to:

• Interact with the device over the serial debug port.
• SSH into the device.
• Access the device's root file system from the host over sshfs.

GNURadio example status

Native Compiling

To get the C compiler and assembler to handle the NEON and assembly files, we have to pass the right flags to cmake. The following worked for me:

cmake [other options] -DCMAKE_C_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9" -DCMAKE_ASM_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" 

(PRELIMINARY) Provided SDKs

GNU Radio will host a set of pre-built files to support various machines and architectures. For the specific machines, we host:

• rootfs: The root file system image as a tar.gz file.
• SDK: the SDK as a self-installing shell script.
• Boot files: files used to boot the machine.

NOTE: We are still working out a few final wrinkles, so these files are likely to evolve over the next few weeks/months. All uploaded images and SDKs are tested and will work for normal operations for the targeted architecture. Just be aware that there may be a few missing or buggy features.

The SDK files can be found here:

• http://gnuradio.org/data/sdk

The images are all built with both shared and static libraries.

Conflicts

• Due to an issue with Orc, use of Orc in VOLK is disabled on ARM hard-float.

Getting the SDK Support

Download the rootfs, boot files, and SDK file. Follow the specific instructions for each platform of interest for how to use the files, especially the boot files. In general, the SDK support will come with:

• rootfs files
  • The rootfs itself that is named gnuradio-dev-image-${MACHINE}.tar.gz
  • Any additional system modules: modules-${MACHINE}.tar.gz

• The SDK
  • A self-extracting/installing shell file: oecore-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}.sh
    • TCLIBC: the libc architecture of the host system (the system running the SDK: x86_64, for examples)
    • SDK_ARCH: The architecture of the targeted platform (e.g., armv7a)
    • IMAGE_BASENAME and TUNE_PKGARCH explain any specific attributes of the SDK and compiler tuning used

• Boot files
  • If the SDK image is geared towards a specific device, like the Zedboard, then we provide the boot files such as the u-boot image itself, the kernel image, device-tree file, and other possible settings.

Currently Supported SDKs

• Machines
  • Zynq (for the Zedboard, ZC702, and ZC706 dev kits)

• Architectures (SDKs only)
  • ARMv7 Supports the Soft-Float ARMv7 ABI
  • ARMv7hf Supports the Hard-Float ARMv7 ABI
    • Note: due to a bug with ORC on ARM hard float systems, ORC is not distributed with this SDK
    • See bug: https://bugzilla.gnome.org/show_bug.cgi?id=727464
    • Neither GNU Radio nor the UHD drivers are built against ORC and so may suffer speed issues due reduced use of SIMD vectorization.

Building Your Own rootfs or SDK

If something in the current rootfs or SDK does not solve your problems or work for your device, you can always build your own. For supported systems by GNU Radio, this is not recommended and will significantly impact our ability to help you debug problems. If going this route for GNU Radio, it is recommended to use Philip Balister's OE Manifest:

• Manifest for bitbaking GNU Radio: https://github.com/balister/oe-gnuradio-manifest/tree/dizzy
• Information on building the SDK: https://github.com/balister/meta-sdr/wiki/CrossCompile

Configuring Your SDK

Start by using Philip Balister's OE Manifest for GNU Radio. Follow the instructions in the readme in that repo. You may wish to tweak a few parameters, which we can now do completely in the local.conf files.

When following the manifest instructions, before running bitbake, edit conf/local.conf. The main changes we use to build the different SDKs involve adding support for static libraries and toggle GUI support on/off. The following example is what we used to build the non-GUI version of the SDK that also includes static libraries for all of our programs.

#DISTRO_FEATURES_append = " opengl x11"

SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs staticdev-pkgs"

PACKAGECONFIG_append_pn-volk = " staticlibs "
PACKAGECONFIG_append_pn-uhd = " staticlibs "
PACKAGECONFIG_pn-gnuradio = " uhd logging ctrlport zeromq staticlibs "
PACKAGECONFIG_pn-gr-osmosdr = "uhd rtl-sdr hackrf rfspace "

The DISTRO_FEATURES can be uncommented to add back in GUI support. When enabling GUI support, we can also add "grc" and "qtgui" to the PACKAGECONFIG_pn-gnuradio line. This example also removed "bladerf" from the list of supported gr-osmosdr devices because it does not currently build a static library. If static libraries are of no concern, adding "bladerf" to this line re-enables that device.

Reporting Problems and Bugs

All problems and bugs should be reported directly to the meta-sdr github repo.