Book Image

Linux: Embedded Development

By : Alexandru Vaduva, Alex Gonzalez, Chris Simmonds
Book Image

Linux: Embedded Development

By: Alexandru Vaduva, Alex Gonzalez, Chris Simmonds

Overview of this book

Embedded Linux is a complete Linux distribution employed to operate embedded devices such as smartphones, tablets, PDAs, set-top boxes, and many more. An example of an embedded Linux distribution is Android, developed by Google. This learning path starts with the module Learning Embedded Linux Using the Yocto Project. It introduces embedded Linux software and hardware architecture and presents information about the bootloader. You will go through Linux kernel features and source code and get an overview of the Yocto Project components available. The next module Embedded Linux Projects Using Yocto Project Cookbook takes you through the installation of a professional embedded Yocto setup, then advises you on best practices. Finally, it explains how to quickly get hands-on with the Freescale ARM ecosystem and community layer using the affordable and open source Wandboard embedded board. Moving ahead, the final module Mastering Embedded Linux Programming takes you through the product cycle and gives you an in-depth description of the components and options that are available at each stage. You will see how functions are split between processes and the usage of POSIX threads. By the end of this learning path, your capabilities will be enhanced to create robust and versatile embedded projects. This Learning Path combines some of the best that Packt has to offer in one complete, curated package. It includes content from the following Packt products: ? Learning Embedded Linux Using the Yocto Project by Alexandru Vaduva ? Embedded Linux Projects Using Yocto Project Cookbook by Alex González ? Mastering Embedded Linux Programming by Chris Simmonds

Related Content you might be interested in

Current Title:

Small book image
Linux: Embedded Development
Alexandru Vaduva | Alex Gonzalez | Chris Simmonds
Sep, 2016 | 16 hours 29 minutes
No titles found
Table of Contents (6 chapters)
Preface
Preface
What this learning path covers
What you need for this learning path
Who this learning path is for
Reader feedback
Customer support
Free Chapter
1
1. Module 1
1. Module 1
1. Introduction
2. Cross-compiling
3. Bootloaders
4. Linux Kernel
5. The Linux Root Filesystem
6. Components of the Yocto Project
7. ADT Eclipse Plug-ins
8. Hob, Toaster, and Autobuilder
9. Wic and Other Tools
10. Real-time
11. Security
12. Virtualization
13. CGL and LSB
2
2. Module 2
2. Module 2
1. The Build System
2. The BSP Layer
3. The Software Layer
4. Application Development
5. Debugging, Tracing, and Profiling
3
3. Module 3
3. Module 3
1. Starting Out
2. Learning About Toolchains
3. All About Bootloaders
4. Porting and Configuring the Kernel
5. Building a Root Filesystem
6. Selecting a Build System
7. Creating a Storage Strategy
8. Introducing Device Drivers
9. Starting up - the init Program
10. Learning About Processes and Threads
11. Managing Memory
12. Debugging with GDB
13. Profiling and Tracing
14. Real-time Programming
4
A. Bibliography
A. Bibliography
5
Index
Index

In this chapter, you will be given a short introduction to a number of components from the ecosystem of the Yocto Project. This chapter is meant to introduce all of them so that in subsequent chapters they can be presented more elaborately. It also tries to direct readers toward extra readings. For each presented tool, feature, or interesting fact, links are offered to help interested readers search for their own answers to the questions in this book and those that this chapter does not cover.

This chapter is full of guidance and relevant examples for an embedded development process that involves specific Yocto Project tools. The selection of the tools was done in a purely subjective manner. Only the tools that are considered helpful in the development process have been selected. We also considered the fact that some of them could offer new insights into the embedded world and the development for embedded systems in general.

Poky represents the reference build system for the metadata and tools of the Yocto Project, which are used as starting points for anyone interested in interacting with the Yocto Project. It is platform-independent and provides the tools and mechanisms to build and customize the end result, which is in fact a Linux software stack. Poky is used as the central piece of interaction with the Yocto Project.

When working with the Yocto Project as a developer, it is very important to have information about mailing lists and an Internet Relay Chat (IRC) channel. Also, Project Bugzilla can be a source of inspiration in terms of a list of available bugs and features. All of these elements would need a short introduction, so the best starting point would be the Yocto Project Bugzilla. It represents a bug tracking application for the users of the Yocto Project and is the place where problems are reported. The next component is represented by the available channels of IRC. There are two available components on a freenode, one used for Poky and the other for discussions related to the Yocto Project, such as #poky and #yocto, respectively. The third element is represented by the Yocto Project mailing lists, which are used to subscribe to these mailing lists of the Yocto Project:

With the help of http://lists.yoctoproject.org/listinfo, more information can be gathered regarding general and project-specific mailing lists. It contains a list of all the mailing lists available at https://www.yoctoproject.org/tools-resources/community/mailing-lists.

In order to initiate development using the Yocto Project in general, and Poky in particular, you should not only use the previously mentioned components; some information regarding these tolls should also be made available. A very good explanation of the Yocto Project is available on their documentation page at https://www.yoctoproject.org/documentation. Those of you interested in reading a shorter introduction, it may be worth checking out the Embedded Linux Development with Yocto Project, Otavio Salvador and Daiane Angolini, by Packt Publishing.

To use the Yocto Project, a number of specific requirements are needed:

There are other extra optional requirements that should be taken care of if special requirements are needed, as follows:

The development process inside the Yocto Project has many meanings. It can refer to the various bugs and features that are available inside the Yocto Project Bugzilla. The developer can assign one of them to his or her account and solve it. Various recipes can be upgraded, and this process also requires the developer's involvement; new features can also be added and various recipes need to be written by developers. All these tasks need to have a well defined process in place that also involves git interaction.

To send changes added in the recipes back into the community, the available create-pull-request and send-pull request scripts can be used. These scripts are available inside the poky repository in the scripts directory. Also, in this section, there are also a bunch of other interesting scripts available, such as the create-recipe script, and others that I will let you discover on your own. The other preferred method to send the changes upstream would be to use the manual method, which involves interaction with git commands, such as git add, git commit –s, git format-patch, git send-email, and others.

Before moving on to describe the other components presented in this chapter, a review of the existing Yocto Project development models will be made. This process involves these tools made available by the Yocto Project:

For operating systems where the provided components are too old to satisfy the requirements of the Yocto Project, a buildtools toolchain is recommended for providing the required versions of the software. There are two methods used for installing a buildtools tarball. The first method implies the use of an already available prebuilt tarball, and the second one involves building it using the Bitbake build system. More information about this option can be found in the subsections under the Required Git, tar, and Python Versions section of the Yocto documentation mega manual available at http://www.yoctoproject.org/docs/1.7/mega-manual/mega-manual.html#required-git-tar-and-python-versions.

The Application Development Toolkit, also called ADT, provides a cross-development platform suitable for custom build and user-targeted applications. It is comprised of the following elements:

In this section, each of the preceding elements will be discussed, and we will start with the cross-development toolchain. It consists of a cross-linker, cross-debugger, and a cross-compiler that are used for the application development of a target. It also needs the associated target sysroot because the necessary headers and libraries are required when building an application that will run on the target device. The generated sysroot is obtained from the same configuration that generates the root filesystem; this refers to the image recipe.

The toolchain can be generated using multiple methods. The most common one is to download the toolchain from http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/, and get the appropriate toolchain installer for your host and target. One such example is the poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh script, which when executed will install the toolchain in the default location of the /opt/poky/1.7/ directory. This location can be changed if proper arguments are offered in the script before starting the execution of the script.

Another method I prefer to use when generating a toolchain involves the use of the Bitbake build system. Here, I am referring to meta-ide-support. When running bitbake meta-ide-support, the cross-toolchain is generated and it populates the build directory. After this task is finished, the same result is obtained as in the previously mentioned solution, but in this case, a build directory that is already available is used. The only remaining task for both solutions would be to set up the environment using the script that contains the environment-setup string and start using it.

The Qemu emulator offers the possibility to simulate one hardware device when this one is not available. There are multiple ways of making it available in the development process:

The user-space tools are included into the distribution and are used during the development process. They are very common on a Linux platform and can include the following:

The last element of the ADT platform is represented by the Eclipse IDE. It is, in fact, the most popular development environment, and it offers full support for the development of the Yocto Project. With the installation of the Yocto Project Eclipse Plug-ins into the Eclipse IDE, the Yocto Project experience is complete. These plugins offer the possibility to cross-compile, develop, deploy, and execute the resultant binary in a Qemu emulated environment. Activities, such as cross-debugging, tracing, remote profiling, and power data collection, are also possible. More information about the activities that appear related to working with Eclipse Plug-ins for the Yocto Project can be found at http://www.yoctoproject.org/docs/1.7/mega-manual/mega-manual.html#adt-eclipse.

To better understand the workflow of the application development of the ADT toolkit platform and Eclipse, an overview of the whole process is available in the following image:

Eclipse ADT plug-ins

The application development process can also be done with other tools that are different from the ones already presented. However, all these options involve the use of a Yocto Project component, most notably the Poby reference system. Therefore, ADT is the suggested, tested, and recommended option by the open source community.

The project—Hob—represents a graphical user interface for the Bitbake build system. Its purpose was to simplify the interaction with the Yocto Project and create a leaner learning curve for the project, allowing users to perform daily tasks in a simpler manner. Its primary focus was the generation of a Linux operating system image. With time, it evolved and can now be considered a tool suitable for both experienced and nonexperienced users. Although I mostly prefer using the command line interaction, this statement does not hold true for all Yocto Project users.

It might seem, though, that Hob development stopped with the release of Daisy 1.6. The development activity somewhat moved to the new project—Toaster—, which will be explained shortly; the Hob project is still in use today and its functionalities should be mentioned. So, the current available version of Hob is able to do the following:

The Hob project can be started in the same way that Bitbake is executed. After the environment sources and the build directory are created, the hob command can be called and the graphical interface will appear for the user. The disadvantage of this is that this tool does not substitute the command-line interaction. If new recipes need to be created, then this tool will not be able to provide any help with the task.

The next project is called Toaster. It is an application programming interface and also a web interface that the Yocto Project builds. In its current state, it is only able to gather and present information relevant to a build process through a web browser. These are some of its functionalities:

Although it might not seem much, this project promises to offer the possibility to build and customize builds the same way that Hob did, along with many other goodies. You can find useful information about this tool at: https://wiki.yoctoproject.org/wiki/Toaster.

Autobuilder is a project that facilitates the build test automation and conducts quality assurance. Through this internal project, the Yocto community tries to set a path on which embedded developers are able to publish their QA tests and testing plans, develop new tools for automatic testing, continuous integration, and develop QA procedures to demonstrate and show them for the benefit of all involved parties.

These points are already achieved by a project that publishes its current status using this Autobuilder platform, which is available at http://autobuilder.yoctoproject.org/. This link is accessible to everyone and testing is performed on all the changes related to the Yocto Project, as well as nightly builds for all supported hardware platforms. Although started from the Buildbot project, from which it borrowed components for continuous integration, this project promises to move forward and offer the possibility of performing runtime testing and other must-have functionalities.

You can find some useful information about this project at: https://wiki.yoctoproject.org/wiki/AutoBuilder and https://wiki.yoctoproject.org/wiki/QA, which offers access to the QA procedures done for every release, as well as some extra information.

The Lava project is not an internal work of the Yocto Project, but is, in fact, a project developed by Linaro, which is an automated validation architecture aimed towards testing the deployments of Linux systems on devices. Although its primary focus is the ARM architecture, the fact that it is open source does not make it a disincentive. Its actual name is Linaro Automation and Validation Architecture (LAVA).

This project offers the possibility of deploying an operating system on a hardware or virtual platform, defining, tests, and performing them on the project. The tests can be of various complexities, they can be combined into bigger and more conclusive tests, and the results are tracked in time, after which the resulting data is exported for analysis.

This is developed with the idea of a continuous evolving architecture that allows test performing along with automation and quality control. At the same time, it offers validation for gathered data. Tests can be anything from compiling a boot test to a change on the kernel scheduler that may or may not have reduced power consumption.

Although it is still young, this project has gained quite an audience, so some investigation into the project would not hurt anyone.

Note

The LAVA manual is available at https://validation.linaro.org/static/docs/

Wic is more of a feature then a project per se. It is the least documented, and if a search is conducted for it, you may find no results. I have decided to mention it here because in the development process, some special requirements could appear, such as generating a custom root filesystem from available packages (such as .deb, .rpm, or .ipk). This job is the one that is best suited for the wic tool.

This tool tries to solve some special requirements from devices or bootloaders, such as special formatting or the partitioning of the root filesystem. It is a highly customized tool that offers the possibility of extending its features. It has been developed from another tool called oeic, which was used to create a certain proprietary formatted image for hardware and was imported into the Yocto Project to serve a broader purposes for developers who did not wanted to touch recipes and had already packaged sources, or required special formatting for their deliverable Linux image.

Unfortunately, there is no documentation available for this tool, but I can direct those who are interested to its location on the Yocto Project. It resides in the Poky repository in the scripts directory under the name of wic. Wic can be used as any script, and it provides a help interface where you can seek more information. Also, its functionalities will be presented in an extended manner in the coming chapters.

A list with all the available projects developed around the Yocto Project can be found at https://www.yoctoproject.org/tools-resources/projects. Some of the projects available there were not discussed in the context of this chapter, but I will let you discover each one of them. There are also other external projects that did not make the list. I encourage you to find out and learn about them on your own.

In this chapter, you were presented with the elements that will be discussed next in this book. In the following chapter, each of the previously mentioned sections will be presented in various chapters, and the information will be presented in-depth and in a more applied manner.

In the next chapter, the previously mentioned process will start with the Application Development Toolkit platform. It will be explained with the steps necessary for the setup of the platform, and some usage scenarios will also be introduced to you. These involve cross-development, debugging using Qemu, and the interaction between specific tools.

Previous Section
End of Section 7
Next Section