5月 16, 2020

Cross-compiling System for Linux

Yocto

A Yocto build starts by building many of the native utilities needed by the build system itself. This is performed to minimize the dependencies on the host OS and to ensure a known set of package versions. Most configurations then proceed to build a tested and known good cross-compilation environment before moving on to building the binaries for the target platform.

The package definitions include various phases (e.g., fetch, compile, install, package) and must specify any runtime or build-time dependencies. The build is controlled by an executive called bitbake , which is responsible for processing the dependencies and scheduling the tasks.

Developing Embedded Linux Devices Using the Yocto Project

David Stewart

What is the Yocto Project (YP)? ... and what’s new

The purpose is to spend less time on things which are routine works (build system, core Linux components).

The Yocto Project is an open source collaboration project that helps developers create custom Linux-based systems that are designed for embedded products regardless of the product's hardware architecture. In summary, it provides tools and metadata for creating custom embedded systems

An image is a collection of 'baked' recipes (packages)
A 'recipe' is a set of instructions for building 'packages'

Where to get the source and which patches to apply
Dependencies (on libraries or other recipes, for example)
Config/compile options, 'install' customization

A 'layer' is a logical collection of recipes representing the core, a board support package (BSP), or an application stack

The Yocto Project's "Layer Model" is a development model. Layers are repositories that contain related sets of instructions that tell the OpenEmbedded build system what to do. You use different layers to logically separate information in your build. As an example, you could have BSP, GUI, distro configuration, middleware, or application layers.

Poky is the Yocto Project reference distribution. It contains the Open-Embedded build system (BitBake and OE-Core) as well as a set of metadata to get you started building your own distribution.

How does it work?

Yocto Project Quick Build

Use Git to Clone Poky


$ git clone git://git.yoctoproject.org/poky


$ git checkout tags/yocto-3.1 -b my-yocto-3.1

Building Your Image

oe-init-build-env


$ cd ~/poky
$ source oe-init-build-env

Build Directory

build

Build Directory

A local configuration file named local.conf becomes available under build/conf . For this example,

the default target are set to build for qemux86 , which is suitable for emulation.
the package manager used is set to the RPM package manager.


$ bitbake core-image-sato


$ runqemu qemux86-64

Yocto Project provides best of upstream for a stable base:

bitbake is a task executor and scheduler, Poky provides metadata: task definitions in recipes, classes and configurations.

Configurations

global configuration

build/conf/local.conf

BB_NUMBER_THREADS,PARALLEL_MAKE
MACHINE
EXTRA_IMAGE_FEATURES
INCOMPATIBLE_LICENSE

distro/poky.conf
machine/*.conf

classes(*.bbclass)
Metadata and patches

Recipes

meta/recipes-core/coreutils/coreutils_6.9.bb
meta-recipes-core/coreutils/coreutils-6.9/

Machine (BSP) configuration

conf/machine/*.conf

Source Fetching

Recipes call out location of all sources, whether on the internet or local (Look for SRC_URI in *.bb files)
Bitbake can get sources from git, svn, bzr, from tarballs, and many, many more*
Versions of packages can be fixed or updated automatically (Add SRCREV_pn- PN = "${AUTOREV}” to local.conf)
Yocto Project sources mirror available as a fallback, if the sources move on the internet

Patching

Once sources are obtained, the patches are applied
This is a good place place to patch the software yourself
However, we encourage you to contribute development upstream whenever possible (we try to)

auto configure/build

Packaging

Once configure/compile/install is completed, packaging commences.
The package management mechanism can be set via PACKAGE_CLASSES in conf/local.conf.
The most popular package formats are supported: RPM, Debian, and ipk
You can split into multiple packages using PACKAGES and FILES in a *.bb file. Fo ex., :


PACKAGES =+ "sxpm cxpm"
FILES_cxpm = "${bindir}/cxpm"
FILES_sxpm = "${bindir}/sxpm"

Image Generation

Images are constructed using the packages built earlier in the process
Uses for these built images:

Live Image to boot a device
Root filesystem for QEMU emulator
Sysroot for App development

Application Development SDK

Cross toolchain and installation script generated.
This can be used to set up an application developer’s cross development environment to create apps
MACHINE=qemuarm bitbake poky-image-sato-sdk meta-toolchain package-index
QEMU built for target architecture emulation

Setting Up the App Development Environment

Embedded Linux Development Using Yocto Project Cookbook

2nd Edition
Practical recipes to help you leverage the power of Yocto to build exciting Linux-based systems

by
Alex González

The example code in the book can be accessed through several GitHub repositories at https://github.com/yoctocookbook2ndedition .

1. The Build System

1.1 Introduction

The Yocto Project ( http://www.yoctoproject.org/ ) is an embedded Linux distribution builder that makes use of several other open source projects.
Most of these are not designed for embedded systems, the Yocto Project allows you to create a Linux distribution designed for your particular embedded system. The Yocto Project provides a reference distribution for embedded Linux, called Poky.
The Yocto Project has the BitBake and OpenEmbedded-Core (OE-Core) projects at its base. Itbuilds the components needed for an embedded Linux product:

A bootloader image
A Linux kernel image
A root filesystem image
Toolchains and software development kits (SDKs) for application development

The Yocto Project makes a new release every 6 months.

codename	version	release date
Gatesgarth	3.2	Oct 2020
Dunfell	3.1	April 2020
Zeus	3.0	October 2019
Warrior	2.7	April 2019
Thud	2.6	Nov 2018
Sumo	2.5	April 2018
Rocko	2.4	Oct 2017

A Yocto release comprises the following components:

Poky, the reference build system and distribution
Board Support Packages (BSPs) with the recipes needed to support different architectures and boards
Build Appliance, a virtual machine image ready to use Yocto
Standard and extensible SDKs for the host system
Eclipse plugins

And for the different supported platforms:

Prebuilt toolchains
Prebuilt images

Yocto builds all the components mentioned from scratch, including the cross-compilation toolchain and the native tools it needs
It is recommended to use symmetric multiprocessing (SMP) systems with >= 8 GB and solid state drives (SSD) if possible.

1.2 Setting up the host system

1.2.1 Getting ready

The first build will also download all the sources from the internet.

Yocto is able to run on any Linux system if it has the following dependencies:

Git 1.8.3.1 or greater
Tar 1.27 or greater
Python 3.4.0 or greater

1.3 Installing Poky

1.3.1 Getting ready

Poky and BitBake are two of the open source projects used by Yocto:

Poky


git://git.yoctoproject.org/poky

Development discussions
Poky development takes place in the master branch.
Stable Yocto releases have their own branch.

BitBake

The Poky distribution only supports virtualized QEMU machines for the following architectures:

ARM (qemuarm, qemuarm64)
x86 (qemux86)
x86-64 (qemux86-64)
PowerPC (qemuppc)
MIPS (qemumips, qemumips64)

The Poky distribution supports some reference hardware BSPs:

Texas Instruments BeagleBone (beaglebone)
Freescale MPC8315E-RDB (mpc8315e-rdb)
Intel x86-based PCs and devices (genericx86 and genericx86-64)
Ubiquiti Networks EdgeRouter Lite (edgerouter)

1.3.2 Getting ready

The Poky project incorporates a stable BitBake release.
To install a Yocto release, ZEUS 3.0.2,


$ sudo install -o $(id -u) -g $(id -g) -d /opt/yocto
$ cd /opt/yocto
/opt/yocto$ git clone -b zeus git://git.yoctoproject.org/poky.git

this clone the Poky repository, which includes BitBake, into a new poky directory under /opt/yocto.
Poky contains three metadata directories,

meta
meta-poky
meta-yocto-bsp

There is a template metadata layer, meta-skeleton , which can be used as a base for new layers.

1.4 Creating a build directory

Before building your first Yocto image, we need to create a build directory for it.
A build directory for our project is where the build output will be generated.

1.4.1 How to do it

A good practice is to have one build directory per architecture or machine type.
To create a build directory, we use the oe-init-build-env script provided by Poky.
The script will set up your environment to use the OpenEmbedded/Yocto build system, including adding the BitBake utility to your path.
You can specify a build directory to use or it will use build by default.


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

The script will change to the specified/default build directory.

1.4.2 How it works

The oe-init-build-env script calls scripts/oe-setup-builddir script inside the Poky directory to create the build directory.
On creation, the build directory contains a conf directory with the following three files:

bblayers.conf

metadata layers

local.conf

configuration variables

site.conf

auto.conf

templateconf.cfg


meta-poky/conf

1.5 Building your first image

We need to decide what type of image to be built.

1.5.1 Getting ready

Poky contains a set of default target images which can be listed:


/opt/yocto/poky$ ls meta*/recipes*/images/*.bb

These default images are used as a base for your customized project needs. The most frequently used base default images are:

core-image-minimal
core-image-full-cmdline
core-image-lsb
core-image-x11
core-image-sato
core-image-weston

Image names with the following suffixes:

development on the target

initramfs

1.5.2 How to do it

There are 2 ways for us to configure the MACHINE variable we are building it for and pass its name to BitBake:

export the MACHINE variable to the current shell environment

oe-init-build-env


$ export MACHINE=raspberrypi4

edit the conf/local.conf configuration file to change the default machine


MACHINE ?= "raspberrypi4"

Then, after setting up the environment(including the correct BSP layer: "1.6 Explaining the Raspberry Pi Yocto ecosystem"), we execute the following:


$ bitbake core-image-minimal

With the preceding steps, BitBake will launch the build process for the specified target image.

1.5.3 How it works

When you pass a target recipe to BitBake, it first parses the following configuration files under the build directory in order:

BUILD/conf/bblayers.conf


BBLAYERS ?= " \
  /opt/yocto/poky/meta \
  /opt/yocto/poky/meta-poky \
  /opt/yocto/poky/meta-yocto-bsp \
  /opt/yocto/meta-raspberrypi \
  "

layer.conf
POKY/meta/conf/bitbake.conf
BUILD/conf/local.conf
meta*/conf/machine/machine.conf

raspberrypi4


$ ls meta-raspberrypi/conf/machine/*.conf
./meta-raspberrypi/conf/machine/raspberrypi0.conf       ./meta-raspberrypi/conf/machine/raspberrypi4-64.conf
./meta-raspberrypi/conf/machine/raspberrypi0-wifi.conf  ./meta-raspberrypi/conf/machine/raspberrypi4.conf
./meta-raspberrypi/conf/machine/raspberrypi2.conf       ./meta-raspberrypi/conf/machine/raspberrypi-cm3.conf
./meta-raspberrypi/conf/machine/raspberrypi3-64.conf    ./meta-raspberrypi/conf/machine/raspberrypi-cm.conf
./meta-raspberrypi/conf/machine/raspberrypi3.conf       ./meta-raspberrypi/conf/machine/raspberrypi.conf

conf/distro/.conf

poky.conf

And then, BitBake parses the target recipe that has been provided and its dependencies. The outcome is a set of interdependent tasks that BitBake will then execute in order.

1.5.4 There's more...

INHERIT
RM_WORK_EXCLUDE
INHIBIT_PACKAGE_DEBUG_SPLIT

1.6 Explaining the Raspberry Pi Yocto ecosystem

Unless you are working with one of the reference boards already supported by Poky, you will need to extend Poky to support your hardware by adding extra BSP layers.

1.6.1 Getting ready

The first thing to do is to select which base hardware your design is going to be based on.
We will use the board "Raspberry Pi 4" as a starting point for our embedded product design.

1.6.2 How to do it

The Yocto community that support Raspberry Pi boards is the layer called meta-raspberrypi .
You can download meta-raspberrypi from its Git repository or from Yocto project:


/opt/yocto$ git clone -b zeus git://git.yoctoproject.org/meta-raspberrypi

1.6.3 How it works...

The BSP extends Poky with the following layers:

meta-raspberrypi

The two most important configuration files under the Yocto build directory needed to be changed to support the additional BSP layer:

build/conf/bblayers.conf

BBLAYERS


BBLAYERS ?= " \
  /opt/yocto/poky/meta \
  /opt/yocto/poky/meta-poky \
  /opt/yocto/poky/meta-yocto-bsp \
  /opt/yocto/meta-raspberrypi \
  "

build/conf/local.conf

MACHINE


MACHINE ?= "raspberrypi4"

meta-raspberrypi

1.7 Building Raspberry Pi 4 images

1.7.1 How to do it...

All of the Raspberry Pi board variants are bundled and defined by different Yocto machines:


/opt/yocto$ find meta-raspberrypi -name raspberrypi*.conf -print
meta-raspberrypi/conf/machine/raspberrypi4.conf
meta-raspberrypi/conf/machine/raspberrypi2.conf
meta-raspberrypi/conf/machine/raspberrypi0-wifi.conf
meta-raspberrypi/conf/machine/raspberrypi4-64.conf
meta-raspberrypi/conf/machine/raspberrypi-cm3.conf
meta-raspberrypi/conf/machine/raspberrypi3-64.conf
meta-raspberrypi/conf/machine/raspberrypi0.conf
meta-raspberrypi/conf/machine/raspberrypi3.conf
meta-raspberrypi/conf/machine/raspberrypi.conf
meta-raspberrypi/conf/machine/raspberrypi-cm.conf

source poky/oe-init-build-env rpi-build
Add the above depended layer to build/conf/bblayers.conf
Set MACHINE in build/conf/local.conf to one of the supported boards
bitbake core-image-base


Parsing recipes: 100% |#######################################################################################################################################| Time: 0:00:34
Parsing of 801 .bb files complete (0 cached, 801 parsed). 1329 targets, 67 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi4"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0.3"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            
meta-yocto-bsp       = "zeus:c77dade37c92bb3a25686a6759a231881bb96477"
meta-raspberrypi     = "zeus:0e05098853eea77032bff9cf81955679edd2f35d"
...

Copy the built image file to the SD card

build/tmp/deploy/images/raspberrypi4


build/tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rpi-sdimg

graphical SD card writing tool

Check which SD card are currently connected to your machine.


$ lsblk -p
...
/dev/sdd      8:48   1  29.7G  0 disk 
├─/dev/sdd1   8:49   1   256M  0 part /media/jerry/boot
└─/dev/sdd2   8:50   1  29.5G  0 part /media/jerry/rootfs
...

umount


$ umount /dev/sdd1
$ umount /dev/sdd2

Backup the content of the working SD card


sudo dd bs=4M  if=/dev/sdd conv=fsync of=2020-06-09-raspi-4.img

Verify the backup image


$ fdisk -l 2020-06-09-raspi-4.img
Disk 2020-06-09-raspi-4.img: 26.6 GiB, 28498198528 bytes, 55660544 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6c586e13

Device                  Boot  Start      End  Sectors  Size Id Type
2020-06-09-raspi-4.img1        8192   532479   524288  256M  c W95 FAT32 (LBA)
2020-06-09-raspi-4.img2      532480 62333951 61801472 29.5G 83 Linux

offset

unit size

Start

offest of the 1st partition
offest of the 2nd partition


mount -v -o offset=4194304 -t vfat *.img /mnt/img/1
mount -v -o offset=272629760 -t ext4 *.img /mnt/img/2

mount

size


mount -v -o offset=4194304,sizelimit=29360128 -t vfat *.img /mnt/img/one

kpartx

To mount all the partitions in a raw disk image


kpartx -av disk.img


              add map loop1p1 (254:4): 0 409597 linear 7:1 3


              fsck /dev/mapper/loop1p1

When you're done, you need to remove the devices


kpartx -d disk.img


$ mount -o loop disk1.iso /mnt/disk


$ ls -l *sdimg
-rw-r--r-- 2 jerry jerry 192937984  六   9 20:21 core-image-base-raspberrypi4-20200609093357.rootfs.rpi-sdimg
lrwxrwxrwx 2 jerry jerry        60  六   9 20:21 core-image-base-raspberrypi4.rpi-sdimg -> core-image-base-raspberrypi4-20200609093357.rootfs.rpi-sdimg

$ fdisk -l core-image-base-raspberrypi4-20200609093357.rootfs.rpi-sdimg

Disk core-image-base-raspberrypi4-20200609093357.rootfs.rpi-sdimg: 184 MiB, 192937984 bytes, 376832 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3fe7ef76

Device                                                        Boot Start    End Sectors  Size Id Type
core-image-base-raspberrypi4-20200609093357.rootfs.rpi-sdimg1 *     8192  90111   81920   40M  c W95 FAT32 (LBA)
core-image-base-raspberrypi4-20200609093357.rootfs.rpi-sdimg2      90112 376831  286720  140M 83 Linux

$ sudo dd if=core-image-base-raspberrypi4.rpi-sdimg of=/dev/sdd bs=4M  conv=fsync status=progress
[sudo] password for jerry: 
176160768 bytes (176 MB, 168 MiB) copied, 2 s, 87.0 MB/s
46+0 records in
46+0 records out
192937984 bytes (193 MB, 184 MiB) copied, 17.8175 s, 10.8 MB/s

config.txt


enable_uart=1
core_freq=250

cmdline.txt


earlyprintk

Boot your RPI

For the official Raspberry Pi OS, if you need to manually log in, the default user name is pi, with password raspberry.
Use the serial console ( 115200, 8N1, /dev/ttyUSB0) to login the built Yocto/Poky distribution: root, password is empty .

Using the Toaster web interface

Toaster is a web application interface to the Yocto Project's build system built on the Django framework with a database backend to store and represent build data.
It replaces the Hob user interface(a graphical interface for BitBake), which could be found on releases prior to Yocto 1.8.

Django的主要目標是簡化資料庫驅動的網站的開發。

1.7.2 Getting ready

your host machine needs to be set up as follows:


$ sudo apt-get install python3-pip
$ pip3 install --user -r /opt/yocto/poky/bitbake/toaster-requirements.txt

1.7.3 How to do it...

To start Toaster:


$ cd /opt/yocto/poky
$ source oe-init-build-env raspi4
$ source toaster start

/opt/yocto/poky/bitbake/bin/toaster is a shell script that will do necessary things to start the web server.
By default, Toaster binds to localhost on port 8000 and can be accessed by: http://127.0.0.1:8000 .
This port can be specified as follows:


$ source toaster start webport=IP:PORT

1.7.4 Administrator interface

To access the Django administration interface, you must create a superuser:

To append the pip3 local user path


$ export PATH=$PATH:$HOME/.local/bin

From the Build Directory, invoke the createsuperuser command


$ cd /opt/yocto/poky/raspi4
$ ../bitbake/lib/toaster/manage.py createsuperuser

To access the Django administration interface through a browser.


http://127.0.0.1:8000/admin

You can manually start a build on the terminal and Toaster will monitor it.
You can then use the Toaster web UI to explore the build results.

1.7.5 Starting a build

You can also use the Toaster web interface to create a new project.

1.8 Running a Toaster Docker container

Docker is a software technology that provides OS level virtualization. 虛擬機器則是虛擬化硬體.
Docker 利用Linux核心中的資源分離機制，例如cgroups，以及Linux核心命名空間（namespaces），來建立獨立的容器（containers）。這可以在單一Linux實體下運作，避免啟動一個虛擬機器造成的額外負擔。
Dockers是有能力打包應用程式及其虛擬容器，可以在任何Linux伺服器上執行的依賴性工具，這有助於實現靈活性和可攜式性，應用程式在任何地方都可以執行，無論是公用雲、私有雲、單機等。
It allows you to create containers that run on Docker and are independent of the operating system underneath.

1.9 Configuring network booting for a development setup

1.9.1 Getting ready

The ideal setup for development work is to use both TFTP and NFS servers in your host system and to only store the bootloader in either the internal flash or a microSD card.
With this setup, the bootloader will fetch the Linux kernel from the TFTP server and the kernel will mount the root filesystem from the NFS server. Changes to either the kernel or the root filesystem are available without the need to reprogram.

1.9.

1.10 Using Docker as a Yocto build system container

1.11 Sharing downloads

1.12 Sharing the shared state cache

Setting up a package feed

1.13 Using build history

1.14 Working with build statistics

1.15 Debugging the build system

2. The BSP Layer

Yocto for Raspberry Pi

by
Pierre-Jean TEXIER
Petter Mabäcker

the code repository for this book

https://github.com/PacktPublishing/Yocto-for-Raspberry-Pi

1. Meeting the Yocto Project

The Yocto Project

"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." It provides tools, processes, templates and methods so that developers can rapidly create and deploy products for embedded devices. The two main components that make up the Yocto Project are:

Poky
Poky is the reference system of the Yocto Project with a six month release cycle. It provides meta data divided into layers and recipes for building various packages and images.
BitBake
This is the scheduler. It is a tool based on the Gentoo distribution.

Understanding the build system

A build system enables you to:

Compile or cross-compile applications
Package applications
Test output binaries and ecosystem compatibility
Deploy generated images

Buildroot is rather dedicated to firmware generation, while Yocto/OpenEmbedded is oriented towards distribution.

The core components

The core components (other available tools are optional) of the Yocto Project are:

BitBake
OpenEmbedded-Core
Poky
The BSP layer (meta-raspberry, meta-fsl-arm, meta-ti, meta-intel, meta-sunxi, and so on)

OpenEmbedded Build System includes BitBake and OpenEmbedded-Core.

What is Poky?

Poky is maintained as a reference distribution under the Yocto Project. It provides the mechanism to build and combine thousands of distributed open source projects for a number of targets.

The Chief - BitBake

BitBake, the build engine, is a task scheduler (like GNU Make). Once the environment is built, BitBake will execute the task (an environment variable do_<task name> decides the task ) that has been requested. According to the information contained in the recipes (or metadata), it downloads the sources of projects from the assigned repository( local, http,git ) then builds in the order determined by the dependency graph generated dynamically. Finally, it installs binaries, generates the corresponding package, and builds the final image, which can be installed on the target(Raspberry Pi for us).

OpenEmbedded-Core

OpenEmbedded-Core is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded.

Exploring metadata

Metadata refers to the build instructions themselves as well as the data used to control what things get built and to affect how they are built.

Yocto Project - workflow

2. Building our First Poky Image for the Raspberry Pi

Installing the required packages for the host system

The steps necessary for the configuration of the host system depend on the Linux distribution used.

Poky on Ubuntu


$ sudo apt-get install gawk wget git diffstat unzip chrpath g++ gcc make python texinfo python3-distutils

Poky on Fedora


$ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat

Downloading the Poky metadata

The Yocto Project® build system (BitBake and the OE-Core metadata) is packaged with the reference distro (called Poky). Download the latest release branch master of the Yocto Project)


git clone -b master git://git.yoctoproject.org/poky.git

Downloading the Raspberry Pi BSP metadata

To download the specific layer (BSP Layer) to the Raspberry PI:


$ cd poky
$ git clone git://git.yoctoproject.org/meta-raspberrypi

make sure the meta data is downloaded:


$ ls meta-raspberrypi/conf/machine/*.conf

The folders under meta-raspberrypi:


$ tree -L 1  meta-raspberrypi
meta-raspberrypi
├── classes
├── conf
├── COPYING.MIT
├── docs
├── dynamic-layers
├── files
├── kas-poky-rpi.yml
├── lib
├── README.md
├── recipes-bsp
├── recipes-connectivity
├── recipes-core
├── recipes-devtools
├── recipes-graphics
├── recipes-kernel
├── recipes-multimedia
└── wic

Initialize the build environment: The oe-init-build-env script

oe-init-build-env is a script for the configuration/initialization of the build environment. This needs to be sourced to setup the environment. It is to initialize a certain number of environment variables and place itself in the build directory specified in the argument:


$ source oe-init-build-env build-directory

The build-directory folder is the place where we perform builds. If build-directory is not specified, it defaults to build . To initialize our environment:


$ source oe-init-build-env rpi-build
You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to, for
example, select a different MACHINE (target hardware). See conf/local.conf
for more information as common configuration options are commented.

You had no conf/bblayers.conf file. This configuration file has therefore been
created for you with some default values. To add additional metadata layers
into your configuration please add entries to conf/bblayers.conf.

The Yocto Project has extensive documentation about OE including a reference
manual which can be found at:
    http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
    http://www.openembedded.org/


### Shell environment set up for builds. ###

You can now run 'bitbake '

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

Other commonly useful commands are:
 - 'devtool' and 'recipetool' handle common recipe tasks
 - 'bitbake-layers' handles common layer tasks
 - 'oe-pkgdata-util' handles common target package tasks

~/poky/rpi-build$

After the initialzation, there are important files created under the build-folder ~/poky/rpi-build:


bblayers.conf  local.conf  templateconf.cfg

Editing the local.conf file

local.conf file is a file containing variables which can configure every aspect of the build process.

MACHINE variable


MACHINE ?= "raspberrypi"

DISTRO variable
PACKAGE_CLASSES variable
PARALLEL_MAKE variable

The minimal set of variables we have to change from the default is:


MACHINE ?= "raspberrypi"

Editing the bblayers.conf file

Add lines: POKY_BBLAYERS_CONF_VERSION = "2"


BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/jerry/poky/meta \
  /home/jerry/poky/meta-poky \
  /home/jerry/poky/meta-yocto-bsp \
  /home/jerry/poky/meta-raspberrypi \
  "

Building the Poky image

Poky provides several pre-designed image recipes that we can use to build our own binary image:


~/poky$ ls meta*/recipes*/images/*.bb

Choice of image

Image recipes provided by meta-raspberry:


~/poky$ ls meta-raspberrypi/recipes-core/images/*.bb

rpi-basic-image.bb
rpi-test-image.bb
rpi-hwup-image.bb

Running BitBake

BitBake, the build engine, which will parse all the recipes related to the image you pass as a parameter:


~/poky$ source oe-init-build-env rpi-build
~/poky/rpi-build$ bitbake rpi-basic-image

After a few hours of baking, the system image for our target is generated under tmp/deploy/images/raspberrypi/.

Creating an SD card

Booting the image on the Raspberry Pi

3. Mastering Baking with Hob and Toaster

Hob

Preparing the environment for Hob

Running Hob

Configuring recipes and packages

Building the image

Exploring Toaster

Installing the required packages for the host system

Running Toaster

Running BitBake

Running the web interface

4. Understanding BitBake

BitBake

BitBake is a task scheduler (like GNU Make) that parses shell and Python scripts. The code parsed generates and runs tasks (configure, compile, and so on), which are basically sets of steps ordered according to the code's dependencies.

Metadata

The metadata used by BitBake:

Configuration ( .conf ) files
Recipes ( .bb and .bbappend files)
Classes ( .bbclass files)
Include ( .inc ) files

Configuration

Configuration files, which are denoted by the .conf extension, define various configuration variables that govern the project's build process.

Classes

Class files, which are denoted by the .bbclass extension, contain information that is useful to share between metadata files.

Recipes

BitBake recipes, which are denoted by the .bb file extension , provide BitBake with the following information:

Descriptive information about the package
The version of the recipe
Existing dependencies
Where the source code resides
Whether the source code requires any patches
How to compile the source code
Where on the target machine to install the package being compiled

Parsing metadata

Preferences and providers

Dependencies

Fetching

The local file fetcher

The HTTP fetcher

The Git fetcher

Understanding BitBake's tasks

5. Creating, Developing, and Deploying on the Raspberry Pi

Software development kits (SDKs)

A generic SDK - meta-toolchain

image.bb -c populate_sdk

The Qt SDK - meta-toolchain-qt

The Qt5 SDK - meta-toolchain-qt5

Cross-compilation - an example

Configuration of the SDK environment

List of tools

Compilation

Raspberry Pi and a package manager

Package format availablility

Choosing a package format

Installing and updating a package on the target

RPM packages

Installing manually

Installing automatically

IPK packages

Installing manually Installing automatically

Our application - an introduction

Our application - creating the recipe

The recipe explained

6. Working with External Layers

Introducing layers

The basic concepts of layers

Theory

The software layer

README and COPYING

The classes folder

The conf folder

The recipes-* directory

The machine (BSP) layer

Adding external layers to the Raspberry Pi

7. Deploying a Custom Layer on the Raspberry Pi

Creating the meta-packt_rpi layer with the yocto-layer script

Adding gpio-packt to meta-packt_rpi

Patching gpio-packt

Generating the patch

Adding the patch to the recipe file

Creating the raspberry-packt-image.bb image

Creating the environment

Modifying the recipe file

Deploying the raspberry-packt-image.bb image

8. Diving into the Raspberry Pi's Peripherals and Yocto Recipes

The SPI bus

The spi-tools project Inclusion in the meta-oe layer Baking spi-tools Testing on the Raspberry Pi spi-config spi-pipe Conclusion

The i2c bus

The Wii Nunchuck

The Nunchuck connector

The Raspberry Pi connection

The Nunchuck's protocol

Encryption

Requesting sensor data

Testing the i2c connection

Creating the Nunchuck application

Integrating with meta-packt_rpi

Creating the Nunchuck recipe

Testing the Nunchuck application

V4L presentation

Video support

v4l-utils integration

9. Making a Media Hub on the Raspberry Pi

Project description â CPU temperature monitoring

Overview

Hardware/software requirements

Creating the main application

server.js

index.html

Creating the Yocto/OE environment

Modifying the image

Creating the recipe file

Explanation

Autostarting - the init file

Explanation

Autostarting - the recipe file

Explanation

Deploying raspberry-packt-image

Testing the application

The future of this project

10. Playing with an LCD Touchscreen and the Linux Kernel

The Linux kernel

The Linux kernels versus the Raspberry Pi Linux kernel Getting started with the Linux kernel Configuring the kernel in Yocto Configuring the kernel with LCD support The Raspberry Pi device tree Configuring the touchscreen from the kernel perspective

Setting up an LCD display for the Raspberry Pi using the Yocto Project

The Raspberry Pi 7 touchscreen The PiTFT 2.8 resistive touchscreen

Developing applications and using them on an LCD display

Developing a custom application using Qt Summary

11. Contributing to the Raspberry Pi BSP Layer

Open source Contributing to open source projects Exploring Git What is Git? Working with Git Contributing to the Yocto Project Contributing to meta-raspberrypi Setting up your Git repository Creating your commit Sending changes to the community Follow-up Practical example - sending a custom tool upstream Summary

12. Home Automation Project - Booting a Custom Image

Home automation using a Raspberry Pi

Material required for the project

Setting up the base for the project

Creating a new layer Customizing the image recipe Building and booting the image

Creating the server side

Creating a packet list for your image

Setting up a customized package list Start using a customized package list in meta-packt-iot