Working with the Yocto build system

Info Box Applies to Yocto Applies to MVM

Introduction

Currently, Yocto is the default distribution for the DAVE Embedded Systems' Linux kits. This is due to the fact that the main semiconductor companies manufacturing the SOCs on which our products are based (NXP, Texas Instruments, Xilinx, etc.) chose to use the Yocto build system as the base for their official BSPs. As our kits are generally derived from these BSPs, the choice of Yocto is straightforward.

The Yocto build system is extremely powerful but its learning curve may be quite steep. The Yocto-based MVMs are conceived in order to help the user to work with Yocto distribution on DAVE Embedded System's products. A deep understanding of the Yocto build system is beyond the scope of this documentation. In order to get more external resources related to this topic, please refer to the Yocto category.

The typical development/deployment process for an embedded Linux system–no matter if using Yocto or not–basically consists of two stages:

• editing/building/debugging code: during this stage, the target is connected via Ethernet LAN to host machine and is configured to
  • Retrieve binary images (i.e. Linux kernel) via TFTP protocol
  • Mount the development root file system via NFS protocol. This root file system is physically in the file system of the host machine as depicted here.
• deployment: the goal of this stage is to configure the target for normal operation, that is out of the development environment. A target root file system–optimized in terms of memory footprint–is used. This root file system is stored onto the target's non-volatile memory.

To implement this workflow, the MVM provides

• TFTP server with /tftpboot as root directory [1]
• NFS server configured to export /home on 192.168.0.0/24 network without root squash. [1]
• target't development root file systems in /home/dvdk/<target_name>/rfs/<kit_name>
• cross-tool chain to build software modules individually
• Yocto SDK for the applications cross-building (/home/dvdk/<target_name>/sdk/<kit_name>/sysroots/
  • by default, cross-tool chain is installed in /home/dvdk/<targetname>/sdk/latest. <targetname> is the name of the actual hardware platform (i.e. lynx, axelulite etc.).
• target-specific sources
  • U-Boot bootloader
  • Linux kernel
• Eclipse/ADT integrated development environment.

Part of these resources was generated by the Yocto build system, as depicted in the following picture.

Simplified flow of Yocto-based building process

The Yocto-related resources included in the MVM allows the developer to:

• Build U-Boot SPL/U-Boot individually
• Build the Linux kernel individually
• Build the user application upon the Yocto SDK
• Build the Yocto BSP image, including the U-Boot, the Linux kernel, and the target root file system
• Use a pre-built root file system image
• Install on the target pre-built additional packages.

Depending on the specific task, a different types of cross-build process is used. In general, the following are of interest:

1. Building software modules individually (i.e. without using the Yocto build system)
2. Generating the image including the U-Boot binary file, the Linux kernel image, and the root file system image (this process is based on the Yocto build system)
3. Generating the SDK associated with a specific root file system image
4. Building a user application against a specific SDK.

The overall development flow of a user application is depicted in the following image. For example, the last step shown in the diagram is performed by the the build process #2 of the previous list.

Typical Yocto-based development flow

[1] For more details about TFTP and NFS servers on host side, please refer to this page.

Building software modules individually

This kind of build processes makes use of a pre-built cross-toolchain. To use it, the shell environment has to be set up properly first. To do this, just issue the following command:

source /home/dvdk/env.sh

This build process is typically used for the U-Boot bootloader, for the Linux kernel, and for user libraries and applications that are not supported by any Yocto recipes. In some cases, in fact, it is convenient to build such modules without invoking the Yocto build system.

For detailed instructions on how to build the U-Boot and the Linux kernel following this approach, please refer to the specific documentation of your kit.

By default, the source files are installed in the following directories:

• U-Boot: /home/dvdk/<target_name>/u-boot
• Linux kernel: /home/dvdk/<target_name>/linux
• MVM: /home/dvdk/<target_name>/mvm/.

U-Boot and Linux sources were retrieved from public git repositories, during the creation process of the MVM. Again, the specific documentation of your kit indicates the addresses of these repositories.

Please note that access to DAVE Embedded Systems' git repositories is granted to development kit's owners only. Please refer to this page for detailed instructions on how to get access.

These sources can be kept in sync and up to date with DAVE Embedded Systems' repositories. Once the git account has been enabled, the developer can:

• Clone the repository with the git clone <git_remote_repository> command
• Synchronize a source tree entering the repository directory and launching the git fetch origin command.

Please note that git fetch doesn't merge the commits on the current branch. To do that, the developer should run the git merge command or replace the fetch-merge process with a single git pull command. Please note that the recommended method is the fetch-merge process. For further information on Git, please refer to the official Git Documentation (http://git-scm.com/documentation).

Building Yocto BSP images including the U-Boot, the Linux kernel, and the target root file system

This process requires a lot of hardware resources in terms of disk storage, RAM, and processing power. For this reason, it also is recommended to consider the use of a physical machine. For more details on this topic, please refer to the specific documentation of your kit related to the advanced use of Yocto build system.

The process described in this section makes use of tons of source files retrieved from many different online repositories. Any issue preventing Yocto to access these repositories–whose URLs are statically specified in the recipe files–may stop the build process. For instance, from time to time these URLs change over the time. Consequently, the build process can't complete successfully because the URL included in the recipes don't match the actual address anymore. Another problem that may interrupt the procedure is a temporary interruption of the Internet connection. The following example shows an error message reported by Yocto in such a case: ERROR: Fetcher failure: Fetch command failed with exit code 4, output: wget: unable to resolve host address 'download.berlios.de' ERROR: Function failed: Fetcher failure for URL: 'http://download.berlios.de/fetchmail/fetchmail-6.3.26.tar.xz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /home/dvdk/build-fb/tmp/work/ cortexa7hf-vfp-neon-poky-linux-gnueabi/fetchmail/6.3.26-r0/ temp/log.do_fetch.28992 ERROR: Task 632 (/home/dvdk/sources/meta-openembedded/ meta-networking/recipes-support/fetchmail/fetchmail_ 6.3.26.bb, do_fetch) failed with exit code '1'

As known, Linux needs a root file system to operate: a root file system must contain everything needed to support the Linux system (applications, settings, data, etc.). The root file system is the file system that is contained on the same partition on which the root directory is located. The Linux kernel, at the end of its startup stage, mounts the root file system on the configured root device and finally launches the /sbin/init, the first user space process and "father" of all the other processes. For more information on the Linux filesystem, please refer to http://www.thegeekstuff.com/2010/09/linux-file-system-structure/.

In general, the kit supports several root file system images. These images are generated by the BSP build process along with the U-Boot binary file and the Linux kernel image.

The typical root file system images supported by the MVM are the following:

• <target_name>-image or <target_name>-core-image
  • This is a minimal image that can be used as starting point for the production file system.
• <target_name>-image-networking
  • This is like the minimal image with the addition of the most common packages used to implement networking applications.
• <target_name>-image-devel
  • This is an image that includes a rich set of packages convenient for the development stage. Usually, the memory footprint of this image is significantly greater than the other ones.

MVM includes one (or more) pre-built images. They are located here: /home/dvdk/<target_name>/rfs/<kit_name>. Kit specific documentation describes how to build such images.

In addition to the packages included in the root file system images, it is possible to build further packages with the Yocto build system, as described by the kit-specific documentation. Please note that most of them are available for the download as pre-built packages in an online repository. These packages can be easily installed on the target by using the smart tool. Again, please refer to the specific documentation of your kit to have more information about the use of this tool.

Generating the SDK associated with a specific root file system image

For each supported root file system, an associated SDK can be generated. The pre-built SDKs included in the MVM are located here: /home/dvdk/<target_name>/sdk. The specific documentation of your kit indicates how to generate the SDKs using the Yocto build system as well.

Building user applications against a specific SDK

About C/C++ application development and debugging, please refer to this page.

Misc

The MVM may include additional files used for other useful purposes. The following sections detail the usage of such files.

bootscript

U-Boot provides flexible mechanisms to support different forms of scripting. One of the most used to automate complex actions at start-up is based on the use of script images.

Most of DAVE Embedded Systems' Linux kits provide a ready-to-use microSD card that allows the target to boot in standalone mode. This means that all the required images (U-Boot, Linux kernel, device tree blob, etc.) for a complete boot are stored in the card itself.

This card makes use of a script image to do this. This image is usually a file named boot.scr. U-Boot provided along with DAVE Embedded Systems' Linux kits implements several customizations. One of these is tailored default environment. This environment is defined to execute boot.scr script image on start-up.

This script image is in turn generated from a source file that is stored in the /home/dvdk/<target> directory of the MVM and that is named bootscript.txt. For instance, this section shows how the script image is generated for the XELK kit.

For more details, please refer to the following links:

• https://www.denx.de/wiki/view/DULG/UBootScripts
• https://www.denx.de/wiki/view/DULG/UBootCmdGroupExec

Related links

• Yocto build system FAQs