We were kindly provided a copy of Embedded Linux Development with Yocto Project, written by Otavio Salvador and Daiane Angolini. It is available at Packt Publishing, either in an electronic format (DRM free) or printed.
This book will help you start with your embedded system development and integration using the Yocto Project or OpenEmbedded.
The first chapter sheds some light on the meaning of commonly misused names: Yocto Project, Poky, OpenEmbedded, BitBake. Then, it doesn’t waste time and explains how to install and use Poky to build and then run an image. The entire book is full of examples that can easily be tested, providing useful hands-on experience, using Yocto Project 1.6 (Poky 11).
The following chapters cover:
Hob: a user friendly interface, however, it will soon be deprecated and replaced by Toaster.
BitBake and Metadata: how to use BitBake, how to write recipes for packages or images, how to extend existing recipes, how to write new classes, how to create a layer, where to find existing layers and use them.
The build directory layout: what the generated files are, and what their use is.
Packaging: how to generate different package formats, how to handle a package feed and the package versions.
The various SDKs that can be generated and their integration in Eclipse.
Debugging the metadata: what the common issues are, how to find what is going wrong, and solving these issues.
Debugging the applications on the target: how to generate an image with debugging tools installed.
Available tools to help achieve copyleft compliance: in particular, how to cope with the GPL requirements.
Finally, there is a chapter dedicated to explaining how to generate and run an image on the Wandboard, an i.MX6 based community board.
The book is easy to read, with plenty of examples and useful tips. It requires some knowledge about generic embedded Linux system development (see our training) as only the Yocto Project specifics are covered. I would recommend it both for beginners wanting to learn about the Yocto Project and for developers wanting to improve their current knowledge and their recipes and also understand the BitBake internals.
We are happy to announce that our engineering team has recently welcomed two new embedded Linux engineers: Boris Brezillon and Antoine Ténart. Boris and Antoine will both be working from the Toulouse office of the company, together with Maxime Ripard and Thomas Petazzoni. They will be helping Bootlin to address the increasing demand for its development and training services.
Antoine started his professional experience with Embedded Linux and Android in 2011. Before joining Bootlin in 2014, he started with low level Android system development at Archos (France), and worked on Embedded Linux and Android projects at Adeneo Embedded (France). He joined Bootlin early March, and has already been involved in kernel contributions on the Marvell Berlin processors and the Atmel AT91 processors, and is also working on our upcoming Yocto training course.
Boris joined Bootlin on April, 1st, and brings a significant embedded Linux experience that he gained while working on home automation devices at Overkiz (France). He was maintaining a custom distribution built with the Yocto. Boris also has already contributed many patches to the mainline Linux kernel sources, in particular for the Atmel AT91 ARM SoCs. Boris is also developing the NAND controller driver for the Allwinner ARM processors and has proposed improvements to the core Linux MTD subsystem (see this thread and this other thread).
The Yocto 1.5 release is approaching and the Freescale layer trees are now frozen.
Bootlin added support for the various Crystalfontz boards to that release as you can check on the OpenEmbedded metadata index.
First some preparative work has been done in the meta-fsl-arm layer in order to add the required features to generate an image able to boot on the Crystalfontz boards:
Support for a newer version of the Barebox mainline, 2013.08.0. As the previously supported version of Barebox was too old, it didn’t include support for the Crystalfontz boards. Also, some work has been done to make the recipe itself more generic so that custom layers can reuse it more easily.
Inclusion of the patches allowing the imx-bootlets to boot Barebox. The imx-bootlets were only able to boot U-Boot or the Linux kernel until now.
Creation of a new image type, using the imx-bootlets, then Barebox to boot the Linux kernel. All the boards based on a Freescale mxs SoC (i.mx23 and i.mx28) will benefit of this new image type. This is actually the difficult part where you lay out the compiled binaries (bootloaders, kernel and root filesystem) in the final file that is an SD card image ready to be flashed.
Then, the recipes for the Crystalfontz boards have been added to the meta-fsl-arm-extra layer:
First the bootloaders, imx-bootlets and Barebox, including the specific patches and configurations for the Crystalfontz boards.
Then the kernel. The linux-cfa recipe uses the 3.10 based kernel available on github.
The machine configurations themselves, selecting Barebox as the bootloader and the correct kernel recipe. Also, these are choosing to install the kernel in the root filesystem instead of in its own partition.
Touchscreen calibration for the cfa-10057 and the cfa-10058 boards. This is required to get xinput-calibrator working properly as it can’t calibrate without starting values.
In a nut shell, you can now use the following commands to get a working image for your particular Crystalfontz board:
For your convenience, Freescale is providing a repo manifest to retrieve all the necessary git repositories. So first download and install repo: mkdir ~/bin
curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
chmod a+x ~/bin/repo
PATH=${PATH}:~/bin
We will work in a directory named fsl-community-bsp: mkdir fsl-community-bsp
cd fsl-community-bsp
Ask repo to get the master branch, when Yocto 1.5 is released, you could select the new branch. (Edit: starting from September, 28th, you can use the branch named dora) repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master
Download the layers: repo sync
Configure the build for cfa-10036: MACHINE=cfa10036 source ./setup-environment build
Start the build with: bitbake core-image-minimal
Grab a cup of coffee!
You’ll end up with an image that you can flash using the following command: sudo dd if=tmp/deploy/images/cfa10036/core-image-minimal-cfa10036.sdcard of=/dev/mmcblk0
Obviously, you need to replace cfa10036 by the board model you are using in the above commands. While not completely perfect, core-image-sato is also working.
I recently had the opportunity to use Yocto. I already practiced quite a lot with OpenEmbedded before. You can see Yocto as a project derived from OpenEmbedded even it is a bit more than that.
In fact, Yocto is made of Poky (a build system based on OpenEmbedded), a few added build tools (swabber, pseudo, etc.), as well as a set of meta data allowing to create embedded distributions for a number of targets.
The strength but also the weakness of OpenEmbedded is that it a very flexible build system. It can make production root filesystems, but also a complete distribution with its ready to use package repository, and this for multiple hardware platforms. It makes it a difficult system to get started and get efficient with. Even two years ago, the OpenEmbedded documentation contributed to making it difficult to get started. Indeed, OpenEmbedded did supply some documentation, but which only started to make sense once you start mastering it. This is quite a paradox for a piece of documentation. It lacked the elements allowing developers to understand its operation well.
With Yocto, I was pleased to realize that substantial progress had been made on this side. The project comes with documentation that is much more exhaustive and above all much more accessible for beginners. Getting started with it is still not completely straightforward, but this time, this is rather because of the complexity and the rich features of the tool.
In a few hours, I managed to develop a minimalistic BSP (Board Support Package) for a given board (in this case a AT91SAM9G20-EK). The concept of layer allows to have a configuration layer specific to a given piece of hardware. You can even support multiple hardware platforms at once and add specific packages. A layer is indeed just a set of packages and configurations (or configuration overrides). The BSP is just a layer specific to one or several pieces of hardware.
As you can see, even to support a simple embedded board, there is already a number of concepts to deal with. There are also multiple ways of achieving the same result but which will be easier or more difficult to maintain. The concept of “BSP” for Yocto is therefore a kind of guideline to allow the Yocto community to have a common point of reference. I will try to illustrate the use of a BSP on the AT91SAMG20-EK board here and/or on my Google+ page.
Another significant progress is optimizing build time for a “minimalistic” target, which went down from more than three hours to just over one hour now. It remains a long time for a very simple target.
To build a filesystem image with only a few components, Buildroot remains much more appropriate. For systems that require a great number of components, more advanced functionality is then often needed, such as managing a package repository and supporting multiple hardware platforms at once for example. In this case, Yocto remains the best (the only?) option, all the more as this project addresses the traditional weaknesses of OpenEmbedded.
It’s now Thursday morning here in Redwood City, California, and I didn’t had the time yesterday morning to do a write-up about our second day at the Android Builders Summit. Hopefully the following write-up will give our readers some details about what happened during this day.
This second of Android Builders Summit was co-located with the Yocto Developer Day, and as my colleagues Maxime Ripard and Grégory Clément were attending the two tracks of Android Builders Summit, I decided that I would attend the Yocto Developer Day.
Yocto Developer Day
Yocto is an umbrella project that consists in creating an embedded Linux build system, called Poky and some associated development tools. Poky takes its roots into the OpenEmbedded community: it re-uses the bitbake recipe processor, and a set of recipes for building packages that are now shared between Yocto and OpenEmbedded through the openembedded-core repository. At Bootlin, we are strong contributors to the Buildroot build system, and we use it for many of our customer projects. However, being pushed very strongly by Intel and the Linux Foundation, Yocto is gaining traction, and the fact that Yocto provides stable releases every 6 months now makes it a lot more usable than OpenEmbedded, which had to be checked out through Git, leaving the user with the uncertainty on whether the version (s)he got would actually work or not. And moreover, Buildroot and Yocto are not really competing projects: Buildroot is a simple root filesystem image generator, while Yocto is more a cross-distribution generator, they target projects of different sizes.
I started attending the Yocto Developer Day with a general presentation talk about what Yocto is and why it is necessary. Nothing really new in this talk for someone who already uses embedded Linux build systems and understands the need for such tools. However, the thing that always surprises me is that the Yocto project claims everywhere to solve the fragmentation problem in the embedded Linux build system space (there are too many tools in this area) by creating the tool, and that they envision that in 5 years, everybody will link embedded Linux build with the Yocto project. It’s quite funny because at the moment, they have just created yet another build system 🙂 But it’s true that the project is gaining traction and seems to attract the SoC vendors, which is a good thing because having a standard build system is so much better than having crappy vendor-specific build systems.
Yocto Developer Day: Yocto introduction by Saul Wold from Intel
The second talk, by Saul Wold, from Intel, went more into the details on how to use Yocto: what the different components are, how recipes are written, how configuration is defined, what tasks, images, recipes, etc are. I would have liked if the talk went a bit further into the details, but it gave a very good introduction to the Poky build system.
In the afternoon, I attended a hands-on session for new users to Yocto. The room setup was very impressive: about forty high-end PCs provided, each having a development board next to it. The first part of the hands-on session consisted in using Yocto to produce a basic filesystem image which we booted into Qemu. In order to solve the very long first build problem that all OpenEmbedded and Yocto users face, they had pre-built a number of packages and stored them into a shared state directory. Interestingly, the size of the Yocto output directory was about 30 GB, just to build an embedded Linux system with BusyBox and a few minor things. Once this was done, we went ahead in creating our own layer, in order to define our own image and its contents it terms of packages. We used it to add a graphical splashscreen, and I also extended it to include Dropbear into the build. The whole thing went quite well. One thing that worries me is that bitbake and the build process really looks like a black box, and it seems hard to understand what’s going on behind the scenes. With Buildroot, I am used to a very simple build system with which it is very easy to fully understand what’s going on. Here, even the people that give speeches about Yocto or deliver a bit of training, seem to not fully understand what’s going on. This impression is also validated by the complexity of the output directory (where all the build results are). But maybe it’s just a matter of spending some time using it and reading some code, but the fact that people that have been developing/using Yocto for a while still do not really understand its internals is a bit surprising. Or maybe it’s just a wrong impression on my side.
Yocto Developer Day: hands-on session starting
The next part of the hands-on was around the Eclipse integration of Yocto. First with ADT (Application Development Toolkit), which integrates the cross-development thing into Eclipse. Thanks to an agent running into the target, Eclipse is able to push the application binary to the target and start gdbserver on it, and therefore transparently start a debugging session for the user. I am not a big fan of Eclipse (I have been an Emacs user for a huge number of years), but it’s true that for people used to Integrated Development Environments, this ADT thing provides a quite nice experience. Then, we went ahead in trying to use HOB, which integrates into Eclipse the possibility of selecting which packages should be built and integrated into the image. Unfortunately, it seems it didn’t work for anybody (even though we were selecting the package in the GUI, it didn’t appear in the final filesystem image), but that wasn’t a big problem since I don’t really see the point in a tool such as HOB: editing configuration files is something that shouldn’t scare any embedded Linux developer.
Regardless of the contents of the hands-on, I was quite interested by how it was conducted. Instead of having some written lab instructions, and having everyone following, alone, those lab instructions, the instructor was simply demoing the various steps to be done on the video-projector screen, which we simply had to replicate. It makes the session quite interactive, with of course the drawback that everyone needs to progress at the same pace.
All in all, this Yocto Developer Day was interesting, and I hope to find some time soon to experiment further with Yocto.
Android Builders Summit
My colleagues attended multiple talks about Android during this second day of the conference. In the morning, they attended Headless Android, Towards a Standard Audio HAL for Android, Android on eMMC: Optimizing for Performance.
Android Builders Summit: Real-time Android
In the afternoon, Grégory attended the Real-Time Android talk, which he said, was interesting. It showed that it was possible to integrate the PREEMPT_RT patches together with the Android kernel modifications, and provide a system having real-time capabilities for native (C/C++) applications and still the nice aspect of the Android user interface. During the same slot, Maxime attended the Android Services Black Magic, given by Aleksandar (Saša) Gargenta from Marakana. As usual with the Gargenta brothers, the talk was highly interesting and gave a lot of detailed information about Android services.
Some other thoughts…
At the organization level, the conference organizers should make it clear in the conference program and flyer the location where the slides will be posted. At almost every talk there is someone that asked if and where the slides will be posted, and the speakers are sometimes a bit uncomfortable because there is no clearly identified place to post the slides. In the past years, it was made clear that the slides would be posted on the elinux.org wiki, but this year, things are very unclear. Moreover, it’s even more surprising since speakers are asked to post their slides into their Linux Foundation website account, but those slides are not being made visible. Maybe a good suggestion for the Linux Foundation would be to improve how slides are handled and posted online.
Another thought about the Android Builders Summit is the surprising absence of Google, the developer and maker of Android. Google sponsors the Embedded Linux Conference which takes place right after the Android Builders Summit, but they do not sponsor the Android Builders Summit. There is also no talk from Google developers, and I haven’t seen any Google person in the attendees. It’s even more surprising when we know that the conference takes place in a location about 18 minutes away by car from Google headquarters in Mountain View. Maybe Google doesn’t want to see Android being used in application areas other than phones and tablets?
