Building a Yocto-based Knoppix for the Raspberry Pi

Pi Recipes

© Lead Image © Jan Treger, 123RF.com

© Lead Image © Jan Treger, 123RF.com

Article from Issue 200/2017
Author(s):

The professor sets the stage for Knoppix on an SD card that runs on the Raspberry Pi.

Knoppix on a Raspberry Pi is an ongoing idea I started several years ago. The Raspberry Pi is a relatively cheap, yet widely available single-board computer, which is also used in embedded and mobile projects. Although many distributions are available for the Pi, creating a new one with some Knoppix technology could be a perfect base for projects.

Because of the Knoppix default hardware setting to boot from the internal SD card reader, the boot procedure already has many similarities with existing distributions. However, Raspbian (the Debian derivate) for Raspberry Pi increased complexity and became a "too many parts to tune" problem. Also, I'm not happy with Debian's move from SysVinit to systemd in Raspbian, which has caused some stuck-at-boot problems in Raspbian-based projects for me.

Therefore, I decided to give the "build-from-scratch" approach a try (Table 1) instead of basing Knoppix on Debian, as in previous versions.

Table 1

Pros and Cons of Knoppix Built from Scratch

Pros

Cons

The complete software is self-built and linked only with components included in the system

May be incompatible with large software repositories like Raspbian

No unwanted "leftover" packages

Have to create build instructions for new programs

Smallest system possible, which can be a base for incremental projects

Needs recompilation with changes or add-ons

No side effects expected from binary upstream

Updates have to get pulled in at the source level

Yocto and OpenEmbedded

Yocto is a framework for creating custom Linux distributions for specialized embedded hardware, as well as for standard boards. Yocto is based on OpenEmbedded, a build framework for embedded Linux [1].

Yocto [2] provides a sample distribution called "Poky," which is filled with templates for the so-called meta-layers. These are directories containing build recipes for software components, which can be thought of as stacked on top of each other, so you have a base layer for the hardware-dependent parts and features, and incremental layers for graphical environments and user software.

Optimally, all changes toward the standard meta-directories that come with the Yocto distribution would be placed into one or more self-created directories with your own recipes, add-ons, and override rules.

Striving to "guarantee 100% reproducible builds," Yocto first downloads, compiles, and installs a completely new development environment from original sources for the host and target architectures, so you have the same version of compilers and libraries on each build system, with no errors attributable to different versions or features. Still, to run Yocto scripts, the host distribution needs to meet some requirements:

  • Git 1.8.3.1 or greater
  • tar 1.24 or greater
  • Python 3.4.0 or greater.

For Debian as the hosting distribution, the following installation and update command is provided in the documentation [3]:

sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping

After these packages are installed, Yocto is supposed to be able to build all software packages and images included in the Poky sample distribution. The integration hierarchy of Yocto is shown in Figure 1.

Figure 1: Yocto integration hierarchy.

Layer Cake

The Yocto framework itself is rather small after installation; uncompressed, it is less than 100MB. During the build process, sources are downloaded via git or http, unpacked, and compiled, which fills up the build/tmp directory with a tremendous amount of data (Table 2).

Table 2

yocto/poky Directory

Kilobytes

Directory

Contents

9,040

bitbake

The bitbake command and tools

19,688

documentation

Yocto documentation sources

29,908

meta

First meta-layer with base recipes

1,212

meta-lxde*

Added layer for building LXDE components

704

meta-office*

Added layer for building LibreOffice

55,512

meta-openembedded

Added dependency layer for Office and LXDE

316

meta-poky

Layer for the "Poky" distribution

2432

meta-raspberrypi*

Added layer for supporting Raspberry Pi-specific rules

28

meta-raspi-knoppix*

Added layer for my own (Knoppix) configuration

356

meta-selftest

Layer for built-in tests

168

meta-skeleton

Layer containing recipe samples

12

meta-yocto

Layer for architecture-independent recipes

232

meta-yocto-bsp

Layer handling board-specific rules

3,144

scripts

Supporting scripts

 

build

Main working directory

28

build/conf/*.conf

Global configurations

7477,860

build/sstate-cache

Build process results as binary fragments and state information

23,371,760

build/tmp

Sysroot directories, build directories, images

When first using Yocto, I found it somewhat unusual that all the seemingly important build stuff, including compilers and supporting binaries as well as the final generated SD card image, resided in a directory named tmp. Even more remarkable is that when removing the tmp directory and its contents completely, rebuilding the project takes less than a tenth of the original time, because most files will be restored quickly from the sstate-cache.

Setting Up Yocto

Before starting the build process, an initial setup needs to be done. I'm using 32-bit userspace binaries on a 64-bit kernel, which is a special setup that Yocto does not yet handle well. For this reason, I start a new shell that changes the output of uname -m from x86_64 to i686, which ensures Yocto will download and compile all supporting tools for the correct host architecture:

setarch i386 /bin/bash

Afterward, paths and the environment need to be configured in the poky directory for the current shell:

cd yocto/poky
source oe-init-build-env

These commands have to be repeated whenever I restart the build procedure from a new shell.

The resulting architecture and software choices, as well as the preferred configurations, can be changed by modifying some variables in build/conf/local.conf (Listing 1).

Listing 1

build/conf/local.conf

 

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Yocto

    The Yocto project gives you all the tools you'll need to build a custom Linux for IoT device.

  • Yocto Project and OpenEmbedded Community Join Forces

    “This kind of massive collaboration is exactly what makes Linux the driving force behind today’s new technology innovations.” said Jim Zemlin, executive director at The Linux Foundation.

  • Baking Bits
  • Gnublin

    Embedded Linux doesn’t have to be rocket science, which the Gnublin board clearly shows. If you want to learn how to read sensors, flip switches, and switch LEDs on ARM Linux, this tiny machine is perfect for your research.

  • Tech Tools

    Red Hat Announces OpenShift Origin

    OpenMAMA 2.1 Now Available

    Tizen Association Releases Larkspur

    Yocto Project 1.2 Released

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News