Skip to content

Creating Linux based Embedded System Images with Yocto

Jump to bottom
Jon Szymaniak edited this page Jun 27, 2015 · 40 revisions

NOTE: This page is a work in progress. It is not complete and is subject to (significant) change

This page describes how to build Linux-based embedded system images with bladeRF support, using Yocto.

Table of Contents

Introduction

Per its website, "The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture."

Yocto heavily leverages the build system provided and originally developed by OpenEmbedded. You will find that there is significant common ground between these projects.

The Yocto Project provides *excellent* documentation. Perhaps one of the most handy documents is the beloved "Mega-Manual" that consists of all the documentation concatenated together into a single web page, for your searching pleasure. In particular, this guide is handy for quickly searching for terms and various names.

These slides and this blog post provide some helpful clarifications on various terminology. Have these handy as you read the manual.

Platform Support

Covered on this page:

Wishlist:

We'd love to see the following hardware tested and its respective build process with Yocto documented.

Available to test:

The associated user has this platform available to test and develop with.

Deemed Problematic:

Problems have been experienced with the following platforms. Additional investigations and work is required.

  • Beaglebone Black
    • The musb driver was crashing with kernel OOPses. It may be related to the use of the USB reset request when libbladeRF opens a device. (jynik)

Disclaimers

Learning Curve

The tools used in this page do have a significant learning curve. As such, you will need to practice independence and due diligence in reading manuals, mailing list archives, and searching the web.

The bladeRF developers and maintainers of the layers used in this guide simply will not have enough time in the day to walk everyone through this process and debug the mistakes that one are bound to make while learning the tools. While you're certainly free to ask questions on the bladeRF IRC channel and forums, please do your homework first when encountering issues.

Expectations vs. Capabilities

It is very important to understand and be aware of the limitations of the platform you are targeting.

Computational Performance

Many of the popular low-cost platforms simply may not have the computational capabilities of executing the signal processing code at the desired sample rate. As such, it is advised that you do some initial benchmarking to better understand this.

Bear in mind that the FPGA on the bladeRF provides excellent opportunities for offloading DSP operations. Consider whether or not it makes sense in your application to have the embedded platform simply perform control and configuration, while custom FPGA blocks perform the intensive processing.

USB Interface

To achieve a reasonable level of signal quality, the platform must be able to sustain a sample rate of 2Msps, or 2 Msps * 2 * sizeof(int16_t) = 8MiB/s, since the lowest front-end LPF setting is 1.5 MHz. (Sampling slightly above this ensures the filter reaches full rejection before the Nyquist limit).

Power Requirements

Some platforms many not be able to supply sufficient power to the bladeRF via their USB ports. Therefore, it is recommended that you first consider powering the bladeRF externally.

Recommended Workflow

In general, it is not recommended to perform you initial development using the embedded target.

Instead, consider performing your initial development, testing, and benchmarking on a desktop machine. This will often ensure you can debug and benchmark code effectively, in a comfortable environment. (As a side effect, this requires that you develop reasonably portable code.)

At this stage you can also identify potential bottlenecks that may prove problematic on the embedded target, as well as develop your benchmarking strategies.

Next, you could try building, testing, and benchmarking on the embedded target. At this point, you should have an understanding of expected behavior, and debugging will consist of identifying the causes for any differences in operation you observe. If you find that you are exceeding the limits of your platform, you will need to make optimizations in either your code or through FPGA development.

Rinse and repeat!

Fetching and Setting up Yocto

Obligatory Quick Start Guide

First, read and review the Yocto Quick Start Guide. This page will assume you're familiar with the terms presented there, and may not make sense if you skip this.

It is **highly** recommended that you work through the Quick Start Guide, including the parts where you build and "boot" images for a QEMU x86 target.

Initial Setup

Directories

These builds can become quite large. Some vendors providing Yocto-based BSPs recommend a minimum of 50 GiB of available space. With that said, you may want to perform these builds in a directory on a large disk.

These instructions will assume the user's home directory is on a sufficiently large disk. We first create a "builds" directory: 

$ mkdir ~/builds
$ cd ~/builds

Lots of software will be downloaded during this process. It's handy to store it all in one common place, so we'll now make a directory for it. 

$ mkdir downloads

Next, make a directory where we'll actually perform the build: 

$ mkdir -p build/sdr

Cloning Repositories

Now we'll clone the Yocto from the project's git repository. See the Yocto downloads page for more information and any new releases. 

$ git clone -b fido git://git.yoctoproject.org/poky.git poky-fido-1.8
$ cd poky-fido-1.8

Next, we'll check out the layers we'll need for our SDR-related items: 

$ git clone git://github.com/balister/meta-sdr.git
$ git clone -b fido git://github.com/openembedded/meta-openembedded.git

For Freescale platforms: 

$ git clone -b fido git://git.yoctoproject.org/meta-fsl-arm
$ git clone -b fido git://git.yoctoproject.org/meta-fsl-arm-extra

For the Raspberry Pi 2: 

$ git clone -b fido http://git.yoctoproject.org/git/meta-raspberrypi

Initial Configuration

When entering your build directory, you must always do it via the oe-init-build-env script to ensure your environment is set up. The argument here is the target build directory, which we created earlier: 

$ source oe-init-build-en build/sdr

conf/local.conf

First, we'll open and edit the conf/local.conf file. Search for MACHINE ?= ... and change it to one of the following, per your target platform:

  • MACHINE = "wandboard-quad"
  • MACHINE = "raspberrypi2"
Next, we'll ensure downloads are placed in the directory we created earlier. Find the line containing DL_DIR and change as needed, using a full path:

DL_DIR = "/home/jon/builds/yocto/downloads"

Review the rest of this file, as the template describes additional options. Also consider using the following parameters, if they are of interest to you:

  • Parallel build parameters
    • By default, all cores will be used. This may slow your machine down, so you may wish to limit the build to half of your cores.
  • You can get a list of all packages and their versions installed into your final image by adding the line: BUILDHISTORY_COMMIT ?= "0"
  • If you wish to use a package manager, consider selecting the desired package type via PACKAGE_CLASSES.
Clone this wiki locally