Yocto became a popular Linux distribution for embedded and IoT devices several years ago. Not all Linux developer are aware of it or even know their organization is using it, so we thought we’d review it here.
A Little Perspective
Embedded systems needed for real-time control were initially designed as highly specialized systems running on specific processors and hardware. This meant that for every new embedded device or system being developed, new control software had to written every time. Rather than reinvent the wheel for a new product, a more generic approach was required. The development of non-processor or hardware specific operating systems, such as VxWorks or QNX solved this problem. However, they still required a software layer to allow the RTOS image to be ported and work on a specific processor and subsystems present on a hardware platform or development board.
This software layer, known as a board support package or BSP, ensured that all the functionality offered on the development board could be accessed by the RTOS. BSPs were typically designed and coded by the board manufacturer and included as part of a board development kit. Development boards could be designed for a very specific function or be generic with the value add being in the software running on the device. With the introduction of Linux as a server/desktop OS in 1991, many companies and developers viewed Linux as an opportunity to use an open source OS as a real-time operating system and in embedded applications.
Linux: From Enterprise to Embedded
The path of Linux to become an embedded OS has its twists and turns. It started with Linux usage in applications that required real-time control while running on PC platforms. Two of the most well-known implementations, RTLinux and Real-time Extensions (RTE) from Windriver and Timesys respectively, extended the Linux OS , allowing it to be used to operate in time-sensitive environments. In addition to real-time, there were also proprietary embedded Linux implementations, the most prevalent one being from Montavista, as well as other unique implementations designed for hand-helds and phones. To enable Linux to be used on other processor families from MIPs, Motorola, Freescale or ARM required building custom distributions. The issue with basing an embedded system on a standard Linux distribution was that it took time and expertise to remove the superfluous Linux components to fit the constraints of the target hardware and there was no consistency in how it was done. In addition, when bug fixes, new features or processor support were required, developers would have to start over from the beginning as there was little or no ability to reuse what was done in the previous image that was built.
It quickly became evident that this reinventing the wheel model was not sustainable and the first move by the Linux community was the definition and development of a single Linux distribution expressly for use in embedded environments. Following the RTOS model of separating the hardware specific layers from core kernel provided the ability to define and implement a single code base that was processor and sub-system hardware independent, led to the Linux community using the established BSP model of traditional RTOS implementations as the starting point. This architectural decision led to the development of Buildroot in mid-2001, OpenEmbedded in 2004, Poky in 2005 and finally to the Yocto Project in 2010.
Embedded Linux Realized: Yocto
The Yocto Project is an open source initiative of the Linux Foundation to develop and deliver the tools, documentation and methodologies that enable a Linux distribution, for embedded and IoT devices, that is abstracted from an independent of the underlying hardware layer. Yocto is not an embedded Linux implementation, but rather builds upon its predecessor, OpenEmbedded (now known as OE-core) to bring the core embedded Linux OS and tool chain into a common and consistent environment. This makes it far simpler for developers to choose only the necessary components, create and package an embedded Linux distribution which precisely meets their needs and is consistently reproducible.
Yocto Under The Covers
Rather than having to assemble all the software required to create a package and final image, tooling engineers and developers no longer have to spend time and effort bringing everything together and tuning this custom environment for Linux embedded development. They can now focus on the development value-add features and accelerate their time to a viable product. All of the Yocto development platform components are categorized and described as follows:
While not directly a part of the downloadable Yocto toolset, BSPs are required to port and then run the specific embedded Linux image on a prototype system. Development boards can run from DIY to full blown, ready for production hardware, with numerous connectivity options. A BSP will be incorporated into a build as defined in a recipe specific to the target hardware and processor type.
How does it all come together?
Metadata/Inputs: Define the policies, parameters, location of code sources, layers and recipes to instruct the build system what and how to build and compile the package and finally generate the bootable or runnable image and eSDK specific to the image for application development.
Build System: Downloads the source code, applies patches, configures and compiles the updated code in accordance with instructions in the metadata. Since the build system can support compilation for different processor architectures simultaneously, the build system analyses the output and decides if package splitting is necessary. After a package decision is made, .dab, .rpm and .ipk files are generated and subjected to QA tests.
Package Feeds: Each package generated is housed in package feeds. Depending on the configuration used, there could be a single or multiple packages generated during a build cycle. In the case where an IPK packaging manager is being used and package architecture support for both x86 64bit and ARM exists. Packages for x86 64bit and ARM architectures are placed in different unique directories structured as follows: build/tmp/deploy/ipk/”architecture”. To generate an image and associated SDK, the build system accesses the specified directory for the source package.
Image: Represents the final product of the development process, the embedded OS as a flashable or runnable entity
Application Development SDK: Concurrently with the creation of the final image, the build system also creates an application development extended SDK or eSDK that is matched to the image. The availability of the eSDK means that developers or tools engineers not having to assemble various tools into a custom SDK and then tune and maintain it on an ongoing basis.
It’s About Building Consistency: Faster
As an integrated set of tools, Yocto makes working with embedded Linux far simpler and faster to get to a ready-to-run state. While there are some unique needs and requirements to fulfill for Yocto, such as the build system, there are plenty of resources and a good “lessons learned” reference on the Yocto site. What are some of the benefits that developers of embedded systems or IoT devices will see using Yocto?
Fully documents the formula used to create the unique baseline embedded distribution enabling the consistent reproduction of the same image, even when incorporating patches or updates in the future
Recipes provide fine grained control over the configuration and of the components that are to be included in and excluded from the final image – Layers enable the logical separation of information when building for multiple architectures and also consolidate related metadata to customize a particular build
Time to Product
Accelerating the process to produce a working embedded image and simultaneously creating an eSDK with application level tools specific to the image enables teams to focus on value-add features and functionality instead of trying to reengineer a generic SDK or build one from scratch
Adding a new feature to an existing image or changing to a different Linux distribution is seamless and does not involve reconfiguring the entire build system or require restarting the development process from the beginning
Developers can use existing tools or develop/add new tools to the environment as required to support specific needs/projects without affecting any of their existing projects
The benefits of using the Yocto are many fold and by including tools for automated builds and testing, processes for board support, license compliance, and component information in a single environment is a major win for developers of Linux focused embedded devices.
Yocto Beyond IoT
As a result of the obvious benefits Yocto brings to embedded Linux developers, the automotive industry has taken notice and has embraced the environment for software development. The needs of the automotive industry are completely different as compared to those of IoT focused systems. These unique requirements around safety, in-car communications and control of up to 100 individual ECUs necessitated a different approach to the use of Linux in an automobile. To fulfill these goals auto manufacturers joined the Automotive Grade Linux Collaborative Project within the Linux foundation and have developed a set of specifications for the development of a standardized and highly optimized Linux OS called Automotive Grade Linux or AGL. To enable the use of AGL in Yocto, the AGL project has developed a build specifically for use in the Yocto environment. Using meta-agl, and defining an AGL layer and specifying the BSP and the below recipes, developers can now build and generate an AGL based image for a specified hardware platform along with the associated eSDK within the Yocto environment.
AGL specific recipes available for use:
We hope that we have provided you with some invaluable insight into the power of Yocto and how the environment enables developers to build optimized embedded Linux images faster and more reliably.