Getting Started with the Yocto Project - New Developer Screencast Tutorial

Hello and welcome to the

screencast

of how to get

started

with the Yocto

project

. This

screencast

aims to provide a gentle introduction to the octo

project

from a

developer

's perspective. You do not need to have any prior experience with the Yocto project to follow the screencast, but you will find it helpful to have some prior experience working with Linux systems and have a basic understanding of how software is configured and built on Linux. My name is Scott Carmen and for the next half hour we'll walk you through a couple of builds of a complete Linux operating system and show you some of what goes on behind the scenes, although there's no way we can cover everything you need to know. with this screencast.

The goal is to familiarize you enough with the build system so that you can get the most out of it. from our documentation and to begin your exploration of the octo project with a solid foundation of knowledge, so we'll start by spending a couple of minutes examining the goals and benefits of the octo project and then providing a high-level overview of the Yoko build . system, we will take a closer look at the recipes that are an important fundamental part of the build system and then we will build and run a Linux image under emulation, then we will discuss the Yoko layering system and how the board support packages are used. as layers and finally we will see how easy it is to rebuild a Linux image for a different board and I will point you to some useful project resources for further research, so the purpose of the Yocto project is to help you build a custom Linux.

Operating system for almost any type of embedded computing device. Yocto can create Linux images for all major hardware architectures, including MIPS x86 arm and PowerPC. Yocto is essentially an umbrella project where the open source community and industry come together to collaborate on a set of tools and best practices for developing custom Linux images, the idea is not that it is a Linux distribution that sets software policies that ultimately get in the way of developing your products; Instead, Yocto focuses on allowing a high degree of flexibility and customization, which is essential when developing custom Linux images. You are developing Linux-based embedded products and need to have a lot of control over the software running on your device, whether you need to focus on making your device boot up as quickly as possible or enable certain optimizations in your software that Yocto It allows.

You can do this while adhering to practices that allow you to reuse your software stack across a wide range of hardware platforms, saving your organization time and money. The Yocto project is hosted on the Linux Foundation, making it an independent project from any particular company or vendor, but as an open source project, many companies and individuals are shaping the future of the project through their participation and code contributions. As you can see, there are quite a few organizations supporting the octo project, from silicon vendors to OS vs2 Consulting Group and, if you wish, you would like to become an official participating organization.

We recommend that you do so. Contact the Linux Foundation for more details. Many benefits can be gained by adopting the Yocto project. One of the most important is being able to reuse your development efforts regardless of the hardware device you are working with. You will no longer have to restructure your development processes every time you start using a new board integrated with the octo board support package. . Often, all that is necessary to rebuild your software for a new platform is to change one line. In a configuration file, we'll demonstrate later in the screencast, the option allows you to start with a validated set of applications and software libraries, and since we're based on open embedded systems, there are thousands of additional recipes that you can easily port to Yocto. octo offers integration with a large set of development tools, such as an eclipse plugin for application development, as well as tools for debugging and profiling, analyzing power consumption, and finally the fact that Yocto is a Open source allows you to get

started

.

With it right away, you can use it to develop prototypes or completely finished products. If you decide you want commercial support, any of the osvs listed on the previous slide can provide it for you without forcing you to adopt a completely different build system. We have learned a few things about the Yocto project, let's turn our attention to the build system. The name of the build system software that Yocto uses is called Pocky and Pocky consists of two main components. There's Bitbake, which runs and manages all the build steps and a set. metadata that describes what is built and how to build it metadata is divided into three main types we have configuration files that define global defaults for things such as standard file system paths where the compilation output will be placed compiler flags architectures machines and so on, there are bitbake classes that end in the dot DB class file name extension and these are the ones that actually do most of the heavy lifting in the build system, for example we have bitbake classes that define how build a Linux kernel or how to build a software based on automated tools, we have some on how to generate an RPM package, how to create a root file system image, etc., finally, there are recipes and recipes that define an individual piece of software to be built, so we have a recipe for the guitar command. a recipe for the gtk library etc.

Recipes are also used to define which packages are included in the final filesystem image, so one of the key things about Yocto is that it provides a very flexible set of tools for creating highly custom Linux images that are designed for the embedded device you're using, gives you a lot of control over what software and features you want to include in your image, but at the same time offers a sensible set of defaults to start with when you're

getting

started to develop your integrated product, the basic components of these images are recipes and we will see some recipes very soon, but I want to make it clear from the beginning that a recipe is not a complete script or a build file that creates a software like it is in others built systems, recipes instead include bits of metadata about the software, such as where you download upstream sources of build or runtime dependencies and what features you want to enable in your application.

You can also split the final result of a recipe into multiple binary packages, for example you probably want to separate the documentation files into another package so you can choose whether or not to install that package in your image in most built-in applications, I would probably skip it to save disk space. The workflow diagram provides a high-level overview of what happens during a Pocky build. The first step is to download the sources for the software you are going to create. We refer to this step as searching for sources. Of course, we support standard methods. such as downloading a tarball from an HTTP or FTP site and we also allow you to query sources from several different source code repository systems such as get or subversion, once the sources have been downloaded they will be extracted to a local workspace. where the necessary patches will be applied, at which time the common steps will be executed to configure and compile the software, then the software will be installed in a temporary staging area, at which time the binary package format that you selected to update will be used the software. on one or more output packages during this process, a number of different quality control and sanity checks are run, such as checking to ensure that the newly created software is not linked to software libraries located outside the build system; actually, it's not true.

Let's say all these tests are run in a single step, there are many different checks that are run throughout the build process, once all the necessary binary packages have been created, a source of binary packages is generated which is then used to create the final root file system. image The fact that a packaged feed is used in this process is very useful if you are developing an integrated product with networking capabilities that may need to be updated in the field. What this allows you to do is copy that packet feed over a network. server and then design your online update system to pull your updates from that package.

When you do this, you can take full advantage of the package management system you're using to do things like automatically resolve package dependencies and make sure your update packages install in the correct order, eventually you'll notice that the system image files and the application development SDK are generated in parallel. It's true that there isn't a single SDK you can use to develop any Yocto-based embedded device, that's because Yocto isn't. a Linux distribution and instead lets you decide which software from the libraries is included in your Linux image, so that when you build your custom Linux image you can also build a nest that is customized for the software you've chosen for your Linux image.

In a nutshell, this is what happens during a Pocky build, since we are building everything from source code. A side effect of this process is that the first build you run can take a significant amount of time. The good news is that we have developed several caching mechanisms to speed up successive builds. Fonts you have downloaded, for example, are saved in a separate area and will not be downloaded again every time. Additionally, we maintain a cache or the binary build output that is generated so you don't. recompile the same software over and over again when running successive builds, only if you make changes to the recipes will those parts of the system be rebuilt.

There was a lot to cover on that last slide, but in contrast to the amount of work Pocky does. generate an image. We've tried to make it extremely easy to get started creating your first Linux image with the 8th. It literally involves just a handful of commands and a little patience during your first build while it completes. Follow our quick start guide in the documentation section of the Yocto project organization website to install the necessary build system prerequisites on your Linux system, then you should be able to follow the live examples that I will show during the rest of the screencast , now that you have general information.

About the Yocto project and an abstract understanding of the build systems workflow, let's look at some things more specific to this exercise. We'll take a look at the source tree you get when you download Pocky and I'll show you where. Different types of metadata are maintained. The Linux system I'm using for my build host is based on Fedora 16. I generally recommend using a recent version of Fedora Ubuntu or opening SUSE for your build hosts, since those three Linux distributions are the ones we use the most. From our tests you could now theoretically run builds from a virtual machine, but if you can help it, I don't recommend using one for performance reasons.

If you end up using a virtual machine for your builds, keep in mind that the builds will take much longer, typically two to three times longer than if you were running Linux natively, so I'll start the graphical file manager here to explore the sources. from pocky. You can see that the tarball version of pocky 6.0 has already been downloaded. and extracted inside this directory you will find several subdirectories, the bitbake directory is where the bitbake command and sources are saved. I'll go back to the build directory in just a second, the documentation directory is where we keep our documentation sources and you'll find them easier to read by just going to the documentation section of our website in the Yocto project organization and you'll notice that we have several metadirectories, this is where the main build system metadata files are located. and the reason we have multiple directories is that each of these directories represents a layer, which is a concept we'll delve into later in the screencast within the meta directory.

You will notice that we have recipe subdirectories where we store the recipe files this is where you will find our recipe files for the Busybox environment, for example in the classes directory you will find all of our bitbake classes. You can see that we have classes for automatic tools for the systemsea ​​construction and the one here. so pan would be used to build Pearl modules etc., in the conf directory you will find different types of configuration files for the build system. One of the top level configuration files is bitbake kampf which, as you can see here, defines the default file. system paths and configure architecture-specific build variables and quite a bit more in the machine subdirectory, we have machine configuration files that define the hardware characteristics of our QEMU targets.

Note that the lines required here will extract the contents of additional files returning to the top. directory level, the scripts directory contains a number of support scripts that are used by the build system, for example we have some scripts here to help simplify running the QEMU emulator. Now the build directory is something that is dynamically generated during builds and below this is where they are all located. its generated output is stored the Downloads directory is where all upstream sources are downloaded the state cache is where we store the compiled output which can be reused during successive builds and the temporary directory is where builds are performed you will find the working directories below here as well as the sibling directory etc. the conf directory is very important as it stores the local kampf and BB layer build files that set critical variables that you'll want to see in the local build, for example it allows you configure things like how many threads you want bitbake to have, use which target machine you are building for which package format you want to use, etc., the bebe layer build file specifies which metadata layer we want to use, since a board support package is distributes as a Yocto layer.

I doubt you'll want to enable that within your baby layers dot-com file, so this is just a quick tour of the pocky directory tree to give you a feel for the terrain. Why don't we build our first image? We open a terminal and a CD. in the pocky directory now we are going to get a script called oh we and weave build env. This script simply sets some basic environment variables and automatically changes your working directory to the build directory before starting the build for the first time. to open your local build file and make sure to specify the desired target machine, as well as configure performance-related variables to get the most out of your build hardware.

In this case, I set the target machine to QEMU x86 and parallelism options 2. 2 and 4, which is appropriate for my dual-core laptop for a quad-core system. I would set them to 4 and 8 now that we have done that we want to make sure we are in the build subdirectory and then we run bitbake minimal core image this starts the build and now it should just be a waiting game to give you an idea of what you should expect at this point if you have a modern quad core i7 processor and 8 gigabytes of RAM this build should take about an hour and a half if you are running it on native hardware keep in mind you are building a full linux operating system from scratch and if you are running it in a virtual machine it will take even longer with our build running in the background, let's take a closer look at the recipe files.

This slide shows an example recipe for the utility of the eath tool. As you can see, we specified some metadata about the purpose of the software creating this recipe in the summary description and home page fields. We also specify the license or licenses under which the software is distributed. Most importantly, we use the source viewer's I variable to tell Bitbake where to download upstream sources from. In this case, we are downloading it from SourceForge. The pv variable in the RI source view is found. for the package version and corresponds to the part of the recipe file named after the underscore, in this case it is expanded to 2.6 36.

Doing this makes it easier to update this recipe when a new version of the eath tool is released, It allows us to simply change the name. the recipe file and minimize a set of changes that we need to make to the content of the recipe you will finally notice the line of automatic inheritance tools. This line tells bitbake to use the automatic tools BB class logic to build the software using With these bitbake class files you can keep a lot of complexity out of the individual recipe files. This is a design goal of the Pocky build system, as we have so many individual recipe files that we try to keep them as simple as possible and take care of the build.

The logic within Bitbake class files, on the other hand, the process of creating a piece of software, no matter what type of build system you use, boils down to a standard set of steps that we execute with Bitbake. These steps are listed here and include retrieving the sources, unpacking them to the working directory, patching the sources, configuring the sources, compiling them, installing the compiled output into a staging area, and packaging the output into one or more binary package formats. What happens behind the scenes when you inherit something like the Auto Tools BB class? version of these build steps that works to successfully build the software using the desired build system.

Additionally, you can further override these build steps by defining them within your recipe file. We'll look at some examples of this shortly. Let's take a closer look. in some specific recipes, the first one we'll look at is mini-com, which is found in mehta recipes, extended mini-com and will recognize the same types of metadata that we saw in the ether recipe example. Slide a new field to take. note is the depends variable, this variable is used to declare any compile time dependencies, so in this case we are saying that Minicon depends on the N curses library, so bitbake will make sure to compile n curses first.

We also have a license file checksum field that we use to track possible changes to license information from upstream sources. This works by specifying one or more files that include license information and taking the md5 sum of that file in case the file changes in a future version of the software. Bitbake will warn us about a checksum mismatch and we can stop to inspect what the changes actually are to check if this license has changed. We can do this with entire files like the copy file here or just a section of the file we're doing here. a mini college file that only checks the first twelve lines of the file which presumably has license information for the source URI.

We can see that we are downloading a tar ball from Debian or a website, but we also included an extra line here that references patch file, you might be wondering where these patches are stored, so if we go back to our browser files, we are in the extended mini-com directory of recipes and in addition to the recipe file itself, you will notice that there is another directory with the name the name of the recipe file and if we look here we will find the patch file. You can store patches in this directory, as well as other files your recipe may need, such as custom startup scripts.

Going back to the recipe, we have some additional fields associated with it. with the source URI, these are md5 and sha-1 or star ball. We do this to ensure that the upstream sources have not been tampered with or corrupted due to a bad download, as those hashes should not change for this particular version of mini. -com you will see here that we inherit not only the automatic tools but also the get text bate class. get text is used to manage localization support during the software build process and finally we see that an install function has been defined and so this means that instead of using the do install function defined in the autotools bitbake class, we are executing the content of this function.

Instead, this is an important feature we provide because not all software follows exactly the same build pattern, even if you use automated tools. This then gives us the control to override the behavior of any build steps when necessary. Another recipe we can see is the review recipe below the main recipe review line. This, of course, is for the new review library, so we start with a typical boilerplate. metadata at the top and you'll notice that the red line also depends on the end of the curses library in order to compile. We also have a couple of patches we make to read build system lines.

You'll notice that we've defined a couple of functions. but in this case the configure function has an underscore prepended at the end and this is a hook function that allows us to execute the content of this function before executing the new configure step instead of overriding it completely, in the same way we have an underscore. add the hook function to perform installation so that the content of this function is executed after the perform installation step. Finally, you'll notice the BB class extension variable, which allows us to create virtual versions of this recipe to exist in both the native and native SDK cases.

Recipes generate software that is not installed on the target machine, but is used to start the build system so that the target software can be compiled. This is usually done for utilities that need to run on the build system, like Quilt Native, which we use to apply. patches for our final recipe example, let's take a look at the pee splash recipe P splash is a system for displaying a graphical logo on the boot screen when a system is booting up, kept in the centerpiece of the flash recipe and You will notice that this recipe instead of a version number at the end of the file name has a word get instead, as you can imagine, this means that the recipe pulls its sources from a git repository. the git repository is specified in the source URI as you can see here and by default this will pull the latest version of the git repository whenever P splash is built to specify a particular commit to build you would set the commit hash in the Source Rev variable as done here, the S variable here refers to where the sources are stored within the job. directory, you usually have to set this manually when your source code doesn't pull like a tarball normally does to a directory whose name matches your recipe name and version number.

We're inheriting Auto Tools again, by far the most common build. system for Linux programs, but we also inherit the package configuration and update our CD. The package configuration is an interface to locate shared libraries that the build system, if P Splash uses an update, our CD means that the software is a startup daemon and therefore needs some logic. enabled to support files underline the pn variable allows you to control which files go in which binary packages pn corresponds to the recipe name without the version number, so here we are manually adding the assembly point P presentation file with forward slash to the package called P Splash, this recipe also uses the prepended hooks for the setup and installation steps and finally, the Annette script variables here need to be set when you inherit the update from our CD class, they specify the file name of the startup script, as well as options to configure.

The run levels for when the startup script is executed. One thing I would like to mention is that if you ever come across a variable within a recipe that you don't recognize, the first place to look for it is in the Yocto Project Reference Manual, which can be found on our website at Yocto Project org. . Once the minimal build of the main image has completed, we can boot the image with the QEMU emulator. The image files are generated under the temporary build of deployment images and as you can see here there is a kernel and root filesystem in ext3 format as well as a tarball of the root filesystem, pakhi includes a script called run QEMU which automatically passes the appropriate options to the qemu command.

All you have to do is run it from the build directory and pass it the name of the QEMU Architecture that you have created, so we will simply invoke run q mu q mu x86 and as you can see our Linux system is booting up for the first time when you get to the login prompt the root account by default does not use a password so press Enter and you will be logged in as you can see that the root file systemof this image is approximately twelve megabytes. You can actually create a much smaller Linux image than that if you use our meta-small layer which is currently in development and expected to ship with Yoko version 1.2 to log out q mu simply issue the shutdown command, let's take a few minutes to understand layers in the Yocto project layers are a powerful layout mechanism that allows you to change different software stacks in a modular way a layer includes a set of bitbake metadata so you can include configuration files that conform to baking classes and recipes in the octo project a board support package for a particular hardware device is distributed as a layer that you enable in your BB layer build This file allows you to develop the software platform for your embedded application and then deploy this app on any hardware platform for which you can get a Yocto board support package.

You can also add support for certain classes of software, such as a particular library environment or a set of software tools by obtaining or creating a Yocto layer for the software. This diagram shows how layers can be used to develop a fully featured integrated product. Each layer has a priority associated with it so you can control which levels have higher priority over others in the base. In this example, we have the open embedded core and Yocto metadata layers that are included in our ball pocket that downloads with our releases. Additionally, it would add a BSP layer for hardware support and possibly include a layer consisting of software for a user interface or application library.

Commercial Linux vendors also have the opportunity to customize and add value to Yocto-based integrated environments by maintaining their own layers. Finally, you may want to enable debugging and profiling support during your application development if you create a layer that enables these features you can develop with this layer enabled and then disable the layer when it comes time to move your application to production, as I mentioned, advanced support packages are layers whose goal is to enable hardware features and specify the drivers used with a given hardware device, a typical bsp layer will include a Linux kernel configuration, specify which graphics drivers to use, if applicable, and include any other recipes, including userspace ones, that are necessary to enable custom hardware features, let's look at an example of using a layer by

getting

and enabling a board support package, let's say we want to create an image minimal core for an integrated Intel Cedar Trail board.

To begin, we would go to the board support packages page on the Yocto project or website. This can be found in the download tab. Make sure the BSP you have selected is compatible with the version of Pocky you are using to build it, since we are using Pocky 6.0 this should work for us, the board support package is distributed as a tarball which We unload inside. In Star Ball you will find documentation files that tell you things like how to install the image in the integrated dashboard release notes and who the BSP maintainer is. The layer base directory is the one with the brown subdirectory name with a layer point offset file inside it, so in a minute we'll add the cedar trail meta directory to our BB layer build file, like You can see, this layer includes a machine configuration file as it is called cedar trail kampf will set the machine variable to cedar trail inside our local build file, this BSP also includes custom recipes that set the proper configuration for the kernel and the X server.

The binary directory you see here is optional for BSP and may include reference images or pre-built kernels. Now let's enable this layer in our Pocky Build System, first we edit our database layers build file and include the cedar trail meta directory. Note that this must be an absolute path now that our build system has access to all the additional configuration files and recipes that BSP offers. Then we configure the Machine variable. to cedar trail in our local communication file is now as simple as baking our desired image, the resulting image files will be generated under temporary deployment images and can be copied to the cedar trail dashboard according to the documentation included with the BSP as you can see the layering system that the project uses Yocto allows you to view hardware support as a simple matter of plugging in the desired layer or layers you want to use as the Yocto project community continues to grow the layering ecosystem allows

developer

s of integrated applications Dramatically improve time to market and reuse code more easily than ever.

Here are some final notes about the Yocto project that you should keep in mind. We are an open source project with a lot of integrated community and industry participation. welcome to dive in and contribute anytime our website on the Yocto project organization will help you get started with documentation and other resources, we have mailing lists that we recommend you join and our source code repository is on get the Yocto project organization bug reports and feature requests normally. submitted via our Bugzilla site, so I hope this screencast gives you a solid introduction to the Yocto project and now that you've built and booted your first Yocto-based Linux image, you can feel more comfortable diving into our documentation and codebase .

Thanks for watching.