Building Linux With The Yocto Project – Is It Really Worth The Trouble?
Like you, the engineers at DornerWorks are always interested in the latest opportunities in open source software. Such applications have grown exponentially since the development of the Internet of Things (IoT), and many are being integrated into the latest product lines of the world’s most innovative companies.
Being well-versed in the various Linux distributions, we have found that Poky, a reference embedded Linux distro from the Yocto Project (an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based system images) has provided a worthy platform for experimentation and discovery. Electrical engineer Anthony Boorsma provided DornerWorks with a helpful demonstration of how Poky and other tools from the Yocto Project work together to build a Linux-based an open source platform for innovative application development.
Yocto, a unit of measurement denoted by 10-24, was taken on as the moniker of this open source project, reflecting its dedication to meritocracy and the offering of information and resources to users of any skill level. Boorsma maintains that there is general industry support for YP, as well as a growing interest from our own clients, due in no small part to the platform’s ability to roll security issues into active development, pertinent to the branches and versions maintained, without much effort from the user.
BitBake, a Python-based build engine inherited from OpenEmbedded, is configured to build an embedded Linux system through configuration files collectively called “metadata,” Boorsma says.
“It is responsible for the parsing of the configuration and actually executing the scripts contained within,” he explains. “It is designed around handling the dependencies of the build elements.”
For a local build, the work involved is relatively simple. Given a stable environment, Boorsma says, along with a Secure Shell (ssh) network connection, the Poky distro could even be set up remotely. He offers this example using the “Krogoth” version of “Poky,” an older stable version of the distro, since superceded by “Morty” and “Pyro” Poky releases:
Poky Krogoth with Core – Image build for the Quick Emulator (QEMU) machine
$ gitclone git://git.yoctoproject.org/poky
$ cd poky
$ gitcheckout krogoth
$ . oe-init-build-env krogoth
$ bitbake core-image-minimal
The default machine in this instance is QEMU, and configuration data stored in krogoth/local.conf.
“The problem with that is, it is very difficult to coordinate builds with a team in that fashion,” Boorsma admits. “It requires communication amongst the team regarding who has control over what is being currently built.”
The Yocto Autobuilder uses a customized version of BuildBot, also written in Python, adding an element of familiarity to this tool, along with Yocto Specific functionality. It’s used by the Yocto team in testing their own layers, and supported by Intel, as well, Boorsma says. Yocto also provides options to build a platform from its Command Line Interface (CLI) and “Toaster” Graphical User Interface (GUI). A few of the most appreciated features of this tool include its ease of use between multiple users, the option to schedule builds, and a convenient web interface Boorsma says.
“As far as I know, it’s original purpose was really only for Continuous Integration testing of the Yocto meta-layers, but we can re-purpose it to circumvent slow workstation build times by leveraging a faster build machine with a fairly useful interface,” he explains. “There have been bugs though, and the process for setting up the configuration involved BuildBot documentation, Autobuilder Source code, and trial and error.”
DornerWorks engineers currently work with Yocto meta-layers in order to add additional configuration to boot-strap-processors and in recipes with patches for U-Boot and Linux images for custom embedded systems, such as those built with NXP’s i.MX line up of embedded application processors.
As mentioned in previous posts, active development in Yocto can be difficult, as operations sometimes corrupt files or ignore changes to them. Boorsma says the platform is good for quick experiments, but possibly little else. His suggestion is to work on developing changes to components outside of Yocto, and integrating them in the image, merging updates with the Yocto-connected branch at regular intervals. Other issues became apparent in the exploration of non-standard BSP meta-layers, as “the flexibility of the Yocto’s build flow paradigm also allows developers to circumvent best practices and cause headaches for others,” Boorsma says.
The Yocto Mega Manual offers documentation on the system. This is a great place to start reading when getting started with Yocto. While the platform is quite easy to use to build a working configuration, it can be notoriously difficult to change the configuration properly for your custom target. Moreover, older versions of Poky may not build on new Ubuntu Releases, Boorsma says.
Building an Embedded Linux system image with the Yocto Project may not seem like the ideal environment for your needs, but we expect the open source community to continue to augment its features and improve its ease of use in future iterations. Yocto Project’s Poky Version 2.4, named “Rocko” is currently in development, and planned for release in the Fall of 2017.
Expect DornerWorks to keep you updated on the Yocto Project front as we continue to experiment and work with this versatile tool.
Git Repository links are valuable resources for anyone interested in Yocto or Poky, especially when building for a custom embedded system with NXP’s i.MX processors:
For further documentation, visit these links:
- NXP BSP Developers Guide
- Poky Pyro (2.3)
- BitBake Reference Manual (the ins and outs of constructing recipes)
- NXP Forums
By Matthew Russell and Anthony Boorsma