The Yocto Project's Reference Distribution “Poky” on Toradex Hardware

sexta-feira, 19 de junho de 2015

LinuxThis article provides a short overview of the differences and relationship between the Toradex default BSP based on the Ångström distribution and the Yocto project's reference distribution “Poky”. The first chapter will explain the motivation behind using a meta-distribution. If you are aware of bitbake and OpenEmbedded, and their advantages, you can as well skip this part.

Distributions vs. Meta-distributions
To efficiently use Linux and open-source software, distributions have evolved that provide pre-compiled and pre-packaged open-source software. These easily allow installing and removing additional software packages on a system. However, when packages need further customisation, such as removing features, different configurations or integrate bug fixes, working with the packaging process of the big distributions can be problematic for embedded projects. The classic build systems use native compilation only, which is usually considerably slower on an embedded target, compared to cross-compiling on a powerful workstation or build server. Package customisations cannot be upstreamed since they are not applicable for other users of the distribution and managing the changes in a fork is time-consuming. On the other hand, building a custom Linux root file system from scratch without any higher level build system is also very time consuming and error-prone.

To fill the gap between maximum flexibility and the ease of use of a distribution, meta-distributions have evolved. Typically, these distributions are specifically designed for embedded use. An elaborate build system allows to customise each individual package (if needed) and to cross compile the whole root file system from source. The two most widespread meta-distributions for embedded Linux are Buildroot and OpenEmbedded.

This article will focus on bitbake and OpenEmbedded - the build system Toradex uses to build its Linux Board Support Packages (BSPs). The utility bitbake and OpenEmbedded are projects that are currently developed under the umbrella of the Yocto project, which in turn, is a Linux Foundation working group.

In OpenEmbedded the 'distribution' layer configures the basic features of a rootfs build. The Yocto project provides its own distribution layer called “Poky”, which makes use of bitbake and OpenEmbedded. However the Toradex BSP uses “Ångström”, another well known distribution layer for OpenEmbedded. One advantage of using Ångström instead of Poky is that Ångström also provides pre-built packages. The pre-built package feeds allow “desktop distribution like” installation of additional packages. This is especially useful when prototyping, which our (pre-installed) demo images are intended for. If you would like to use the Yocto project's reference distribution Poky instead, then this is easily possible as the underlying build system is the same.


Yocto Internals
In the OpenEmbedded environment, a common release cycle of 6 months has evolved. However, version naming/numbering depends on the (sub-) project. A table helps to better understand which versions belong together.

OpenEmbedded
Codename
Yocto Project
Release
Poky
Distribution
Ångström
Distribution
Toradex
Version
dylan 1.4 9.0 v2013.06 2.1
dora 1.5 10.0 v2013.12 2.2
daisy 1.6 11.0 v2014.06 2.3
dizzy 1.7 12.0 v2014.12 2.4
fido 1.8 13.0 v2015.06 2.5
(master) 1.9

The OpenEmbedded build system is layered. This allows largely independent development of the meta-distributions core features and individual board support. Toradex provides the board support in its own layer called meta-toradex. Beside that we also maintain an independent layer called meta-lxde, which contains the GTK2 based LXDE (Lightweight X11 Desktop Environment) - our default user interface. Poky uses Sato as its default user interface which is a custom GTK2 based desktop environment. Hence, the meta-lxde layer is not needed when building the Poky reference distribution. Besides that, Toradex also started to participate in the Community driven BSP for NXP®/Freescale based boards (meta-fsl-arm and meta-fsl-arm-extra). Currently, the NXP®/Freescale Vybrid based Computer on Modules (Colibri VF50/VF61) are supported within those layers and we plan to support the NXP®/Freescale i.MX 6 based modules in the near future too.

In its current state, the meta-toradex layer is not a pure BSP layer. The layer has grown over time and we plan to split it up into a software layer and distinct BSP layer(s). The Toradex layer also contains a custom image deployment process: After the image building process completed, a custom step combines our flashing utilities and scripts (e.g. update.sh) and creates a single distributable tar.bz2 package. This image customisation will not be applied to the Poky images. Hence, the Toradex standard flashing process using update.sh will not work. However one can download the Toradex binary image releases and use the flash scripts thereof.

This steps below will show how to build two images:

  • An image using the Poky reference distribution 12.0 (dizzy) for our Apalis T30 module using the meta-toradex layer.
  • An image using the Poky reference distribution 13.0 (fido) for our Colibri VF50/VF61 modules using the meta-fsl-arm-extra layer.


Build Poky's Sato Image for Apalis T30
Before starting, the distribution specific preparation steps documented in the official Yocto Project Quick Start need to be executed. Then execute the following commands in a terminal of your build host machine. We need to get the Dizzy branch of the Poky reference distribution first:

$ git clone http://git.yoctoproject.org/git/poky -b dizzy
...

In the next step, we need to clone the Toradex layer. Because the layer also supports NXP®/Freescale SoC's the meta-fsl-arm layer needs to be added too:

$ cd poky
$ git clone https://github.com/Freescale/meta-fsl-arm.git -b dizzy
$ git clone git://git.toradex.com/meta-toradex.git -b V2.4-next

Then the default OE environment initialisation needs to be done. After this initialisation, you should be in a sub-directory called “build”:

$ source oe-init-build-env

Add the layer in the layer configuration file under conf/bblayers.conf:

BBLAYERS ?= " \
 /build/ags/poky/meta \
 /build/ags/poky/meta-yocto \
 /build/ags/poky/meta-yocto-bsp \
 /build/ags/poky/meta-toradex \
 /build/ags/poky/meta-fsl-arm \
 "

Configure the machine under conf/local.conf:

MACHINE ?= "apalis-t30"

Some bbappend-recipes in the meta-toradex layer make customisation on the LXDE recipes. To avoid errors due to missing base recipes, one needs to add an option in the conf/local.conf configuration:

BB_DANGLINGAPPENDS_WARNONLY = "true"

Now the build utility “bitbake” can be used to start the build process. Depending on your machine, this can take up to several hours and will heavily load your CPU/Disk IO. However, subsequent builds with modifications will run faster as the bitbake build system will reuse the already built packages.

$ bitbake core-image-sato
...

The flashing procedure isn't really standardised within the Yocto project. The Toradex image provides flashing utilities and scripts which allow to create a SD card to flash the target. To flash the Poky distribution, we can make use of these tools too. For this purpose, download the Toradex Linux image, unpack it and remove the Ångström based root files system replacing it with the Poky root file system instead:

$ sudo su
# tar xvjf Apalis_T30_LinuxImageV2.4Beta1_20150518.tar.bz2
# rm -rf rootfs/
# mkdir rootfs/
# tar xvjf path/to/poky/build/tmp/deploy/images/apalis-t30/core-image-sato-apalis-t30.tar.bz2 -C rootfs/
# echo "Apalis_T30" >> rootfs/etc/issue

Also copy the kernel and U-Boot that are provided externally:

# rm apalis-t30_bin/u-boot*
# cp --preserve=links path/to/poky/build/tmp/deploy/images/apalis-t30/u-boot* apalis-t30_bin/
# rm apalis-t30_bin/uImage*
# cp --preserve=links path/to/poky/build/tmp/deploy/images/apalis-t30/uImage* apalis-t30_bin/

Then, use update.sh to prepare a SD card with the U-Boot bootloader, Linux kernel and the root file system image.

./update.sh -o /run/media/user/UPDATE

The last three steps need to be repeated each time a new image has been generated by the build system.

Insert the SD card into the target module's carrier board and start the Toradex flashing scripts using the U-Boot boot loader's serial console:

Apalis T30 # run update
...
Apalis T30 # run setupdate
...

After a reboot, the system boots the Yocto root file system and shows the GTK2 based Sato reference user interface.

For further documentation refer to the extensive Yocto poject documentation:

For a complete list of available documentation refer to yoctoproject.org.


Build Poky's Sato Image for Colibri VF50/VF61
This is to large parts similar to the Apalis T30 instructions above with some differences in the selection of layers and a different flashing procedure. Before starting, the distribution specific preparation steps documented in the official Yocto Project Quick Start need to be executed. Then execute the following commands in a terminal of your build host machine. We need to get the Fido branch of the Poky reference distribution first:

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

Next we need the NXP®/Freescale community layers meta-fsl-arm and meta-fsl-arm-extra. Since the Colibri VF50/VF61 BSP recipes (mainly Kernel/U-Boot) are part of the NXP®/Freescale community layers we won't need the Toradex layer for the Vybrid based modules.

$ cd poky
$ git clone https://github.com/Freescale/meta-fsl-arm.git -b fido
$ git clone https://github.com/Freescale/meta-fsl-arm-extra.git -b fido

Then the default OE environment initialisation need to be done. After this initialisation, you should be in a sub-directory called “build”:

$ source oe-init-build-env

Add the layer in the layer configuration file under conf/bblayers.conf:

BBLAYERS ?= " \
 /build/ags/poky/meta \
 /build/ags/poky/meta-yocto \
 /build/ags/poky/meta-yocto-bsp \
 /build/ags/poky/meta-fsl-arm \
 /build/ags/poky/meta-fsl-arm-extra \
 "

Configure the machine under conf/local.conf:

MACHINE ?= "colibri-vf"

Then as above the build utility “bitbake” can be used to start the build process:

$ bitbake core-image-sato

If needed the boot loader can be built in a second step:

$ bitbake u-boot

The machine configuration file in meta-fsl-arm-extra directly generates a UBI file system image, hence the image generation of the update.sh can be skipped. Copy the image on a FAT formatted SD card:

$ cd tmp/deploy/images/colibri-vf/
$ cp core-image-sato-colibri-vf.ubifs /run/media/user/UPDATE/ubifs.img
$ cp u-boot-nand.imx /run/media/user/UPDATE/u-boot-nand.imx

The update scripts required by the default update commands are part of the Toradex image as well so copy them from an already unpacked Image:

$ cd path/to/Colibri_VF_LinuxImageV2.4
$ cp colibri-vf_bin/flash*.img /run/media/user/UPDATE

Insert the SD card into the target module's carrier board and start the Toradex flashing scripts using the U-Boot boot loader's serial console (see also Flashing Embedded Linux to Vybrid Modules):

Colibri VFxx # run update
...
Colibri VFxx # run setupdate
...

After a reboot, the system boots the Yocto root file system and shows the GTK2 based Sato reference user interface.

For further documentation refer to the extensive Yocto project documentation:

For a complete list of available documentation refer to yoctoproject.org.

#Apalis ARM Family #Colibri ARM Family #Computer on Module #Embedded Development #Embedded Linux #Freescale® Vybrid™ #NVIDIA Tegra
AuthorStefan Agner, Linux Development Engineer, Toradex AG

Subscribe to our future Blog posts:


Leave a comment

Your email ID will be kept confidential. Required fields are marked *

Clique aqui para alterar o código

Por favor digite as letras exibidas na imagem acima. O sistema NÃO diferencia maiúsculas e minúsculas



* Your comment will be reviewed and then added. Thank you.