Learn about Yocto, Buildroot, OpenWRT, and modified desktop distributions to determine which method is best for your project.
Linux has been deployed to a wider range of devices than Linus Torvalds anticipated when he developed it in his dorm room. It astonishingly supports various chips, making Linux applicable to devices of all sizes: from IBM mainframes[1] to micro devices[2] that are smaller than their connected ports, as well as devices of various sizes. It is used in large enterprise data centers, internet infrastructure devices, and personal development systems. It also powers consumer electronics, mobile phones, and many IoT devices.
When building Linux software for desktop and enterprise-level devices, developers often use desktop distributions like Ubuntu[3] on their build machines to remain as similar as possible to the deployed machines. Tools like VirtualBox[4] and Docker[5] help maintain consistency between development, testing, and production environments.
What is an embedded system?
Wikipedia defines an embedded system[6] as “a computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints.”
I believe it can simply be said that an embedded system is a computer that most people do not think of as a computer. Its primary role is to function as a device rather than being viewed as a general-purpose computing platform.
The development environment for embedded system programming often differs significantly from testing and production environments. They may use different chip architectures, software stacks, and even operating systems. The development workflow is very different for embedded developers compared to desktop and web developers. Typically, the output of the build will include the entire software image for the target device, including the kernel, device drivers, libraries, and application software (sometimes including the bootloader).
In this article, I will provide an overview of four commonly used methods for building embedded Linux systems. I will introduce how each product works and provide enough information to help readers determine which tool to use for their designs. I will not teach you how to use any of them; once you narrow down your choices, there are plenty of in-depth online learning resources available. No single choice is suitable for all situations, and I hope to provide enough details to guide your decision.
Yocto
The Yocto project defines[8] itself as “an open-source collaboration project that provides templates, tools, and methods to help you create customized Linux-based systems for embedded products, regardless of the hardware architecture.” It is a collection of recipes, configuration values, and dependencies for creating customized Linux runtime images tailored to your specific needs.
Full disclosure: Most of my work in embedded Linux has focused on the Yocto project, and my understanding and biases about this system may be evident.
Yocto uses Openembedded[9] as its build system. Technically, these two are independent projects; however, in practice, users do not need to understand the distinction, and project names are often used interchangeably.
The output of the Yocto project generally consists of three parts:
Advantages
The Yocto project is widely used in the industry and has the support of many influential companies. Additionally, it has a large and vibrant developer community[10] and ecosystem[11]. The combination of open-source enthusiasts and corporate sponsors helps drive the Yocto project forward.
There are many options for obtaining support for Yocto. If you want to get hands-on, there are books and other training materials available. If you seek expertise, many engineers with Yocto experience are available. Moreover, many commercial organizations can provide turnkey products based on Yocto or service-based implementation and customization for your design.
The Yocto project can easily be extended through layers[12], which can be independently released to add extra functionality, target platforms that were not available at the time of project release, or preserve system-specific customizations. Layers can be added to your configuration to include unique features not specifically included in market versions; for example, the “meta-browser[13]” layer includes a list of web browsers that can be easily built for your system. Since they are independently maintained, layers can be released at different times (depending on the development speed of the layer) rather than following the standard Yocto release schedule.
Yocto arguably has the broadest device support of any method discussed in this article. With the support of many semiconductor and board manufacturers, Yocto is likely to support any target platform you choose. The main Yocto branch[14] only supports a few main boards (to achieve reasonable testing and release cycles); however, the standard operating mode is to use external board support layers.
Finally, Yocto is very flexible and customizable. Customizations for your specific application can be encapsulated and isolated in a layer, often storing custom elements specific to the layer as part of the layer itself, allowing the same settings to be applied to multiple system configurations simultaneously. Yocto also provides a well-defined layer priority and override functionality. This allows you to define the order in which layers apply and search for metadata. It also allows you to override settings from higher-priority layers; for example, many custom features of existing manifests can be retained.
Disadvantages
The biggest drawback of the Yocto project is its steep learning curve. Learning the system and truly understanding it requires a significant investment of time and effort. Depending on your needs, this may represent an excessive investment in technical capabilities that might not be relevant for your application. In such cases, working with a commercial vendor might be a good option.
The development time and resources for the Yocto project are quite high. The number of packages that need to be built (including toolchains, kernels, and all target runtime components) is substantial. Yocto developers’ development workstations tend to be large systems. Using small laptops is not recommended. This can be alleviated by using cloud-based build servers provided by many vendors. Additionally, Yocto has a built-in caching mechanism that allows it to reuse previously built components when it determines that the parameters used to build a specific package have not changed.
Recommendations
Using the Yocto project for your next embedded Linux design is a strong choice. Among the options presented here, it is the most broadly applicable regardless of your target use case. Extensive industry support, an active community, and broad platform support make it a solid choice for designers.
Buildroot
The Buildroot[15] project is defined as “a simple, efficient, and easy-to-use tool for generating embedded Linux systems through cross-compilation.” It shares many of the same goals as the Yocto project but focuses on simplicity and minimalism. Generally, Buildroot disables all optional compile-time settings for all packages (with some notable exceptions) to generate the smallest possible system. System designers need to enable the settings applicable to their specific device.
Buildroot builds all components from source but does not support target package management. Therefore, it is sometimes referred to as a firmware generator, as the image is largely fixed at build time. Applications can update the target filesystem, but there is no mechanism for installing new packages on the running system.
Buildroot output primarily consists of three parts:
Advantages
Buildroot’s focus on simplicity generally makes it easier to learn than Yocto. The core build system is written in Make and is short enough for developers to understand the entire system while being extensible enough to meet the needs of embedded Linux developers. The Buildroot core typically only handles common use cases but can be extended through scripts.
Buildroot systems use standard Makefile and Kconfig languages for configuration. Kconfig is developed by the Linux kernel community and is widely used in open-source projects, making it familiar to many developers.
Due to its design goal of disabling all optional build-time settings, Buildroot typically generates the smallest possible image with out-of-the-box configurations. Generally, build times and the scale of build host resources will be smaller than those of the Yocto project.
Disadvantages
The focus on simplicity and minimal build options means that you may need to perform a lot of customization to configure a Buildroot build for your application. Additionally, all configuration options are stored in a single file, meaning that if you have multiple hardware platforms, you need to make every customization change for each platform.
Any change to the system configuration file requires a complete rebuild of all packages. Compared to Yocto, this issue is somewhat mitigated by the minimal image size and build times, but it can lead to long build times as you adjust configurations.
Intermediate package state caching is not enabled by default and is not as thoroughly implemented as in Yocto. This means that while the first build may be shorter than the equivalent Yocto build, subsequent builds may require rebuilding many components.
Recommendations
Using Buildroot for your next embedded Linux design is a good choice for most applications. If your design requires multiple hardware types or other differences, you may need to reconsider due to the complexity of synchronizing multiple configurations, but for systems composed of a single setup, Buildroot may suit you.
OpenWRT/LEDE
The OpenWRT[16] project began by developing custom firmware for consumer routers. Many low-cost routers available from your local retailer can run Linux systems but may not be functional out of the box. The manufacturers of these routers may not provide frequent updates to address new threats, and even if they do, the mechanism for installing updated images can be difficult and error-prone. The OpenWRT project generates updated firmware images for many devices abandoned by their manufacturers, giving these devices a new lease on life.
The primary deliverable of the OpenWRT project is binary images available for a wide range of commercial devices. It has a network-accessible software package repository that allows end users to add new software to their systems. The OpenWRT build system is a generic build system that allows developers to create custom versions to meet their own needs and add new packages, but its primary focus is on target binary files.
Advantages
If you are looking for alternative firmware for commercial devices, OpenWRT should be on your list of options. It is well-maintained and can protect you from issues that the manufacturer’s firmware cannot address. You can also add extra features to make your device more useful.
If your embedded design focuses on networking, OpenWRT is a good choice. Network applications are the primary use case for OpenWRT, and you may find many available packages.
Disadvantages
OpenWRT imposes many restrictions on your design (compared to Yocto and Buildroot). If these decisions do not align with your design goals, you may need to make significant modifications.
Allowing package-based updates on deployed devices is difficult to manage. By definition, this leads to a situation where the software load differs from what your QA team tested. Additionally, guaranteeing atomic installations for most package managers is challenging, and erroneous power cycles may leave your device in an unpredictable state.
Recommendations
OpenWRT is a good choice for hobbyist projects or commercial hardware reuse. It is also a good choice for network applications. If you need extensive customization from the defaults, you may prefer Buildroot or Yocto.
Desktop Distributions
A common approach to designing embedded Linux systems is to start with a desktop distribution, such as Debian[17] or Red Hat[18], and remove unnecessary components until the installed image fits the footprint of the target device. This is the approach taken by the popular Raspbian[19] distribution for the Raspberry Pi[20] platform.
Advantages
The main advantage of this approach is familiarity. Generally, embedded Linux developers are also desktop Linux users and are well-versed in their chosen distributions. Using a similar environment on the target may allow developers to get up to speed faster. Depending on the distribution chosen, many other tools can be installed using standard packaging tools like apt and yum.
You can connect a monitor and keyboard to the target device and perform all development directly there. For developers unfamiliar with the embedded space, this may be a more familiar environment without the need to configure and use tricky cross-development setups.
The number of packages available on most desktop distributions is usually greater than the number of available software packages in the previously discussed embedded-specific builders. Because of the larger user base and broader use cases, you may be able to find all the runtime packages your application needs that have already been built and are available for use.
Disadvantages
Using the target platform as your primary development environment can be slow. Running compiler tools is resource-intensive, and depending on how much code you are building, this can significantly hinder your performance.
With some exceptions, desktop distributions are not designed for low-resource systems and may be difficult to trim adequately for the target image. Similarly, the preset workflows in a desktop environment are not ideal for most embedded designs. Achieving a reproducible environment in this way is difficult. Manually adding and removing packages is prone to error. This can be scripted using distribution-specific tools, such as debootstrap[21], based on Debian systems. To further improve reproducibility[21], configuration management tools like CFEngine[22] (which my employer Mender.io[23] fully discloses) can be used. However, you remain subject to the whims of the distribution provider, who will update packages to meet their needs rather than yours.
Recommendations
Be cautious using this method for products you intend to bring to market. It is a great model for hobbyist applications; however, for products that require support, this method will likely run into trouble. While you may be able to get a faster start, you may end up spending your time and effort in the long run.
Other Considerations
This discussion focuses on the capabilities of the build systems, but there are often non-functional requirements that may influence your decision. If you have already chosen a system-on-chip (SoC) or board, your options are likely dictated by the vendor. If your vendor provides board support packages (BSPs) for specific systems, using them can save a significant amount of time, but be sure to investigate the quality of the BSP to avoid issues later in the development cycle.
If your budget allows, you may want to consider using a commercial vendor for your target operating system. Some companies offer verified and supported configurations for many of the options discussed here, which is a good choice unless you have expertise in embedded Linux build systems, allowing you to focus on your core competencies.
Alternatively, you might consider commercial training for your developers. This may be cheaper than commercial operating system vendors and can make you more self-sufficient. It is a quick way to get up to speed on the basics of the build system of your choice.
Finally, you may already have some developers with experience in one or more systems. If your engineers have preferences, it is worth considering when making your decision.
Conclusion
There are various options for building embedded Linux systems, each with its advantages and disadvantages. It is crucial to prioritize this part of the design, as switching systems later in the process can be costly. In addition to these options, new systems are under development. I hope this discussion provides some background for evaluating new systems (as well as those mentioned here) and helps you make a solid decision for your next project.
via: https://opensource.com/article/18/6/embedded-linux-build-tools
Author: Drew Moseley[25] Topic: lujun9972 Translator: LHRChina Proofreader: wxy
This article is originally compiled by LCTT and honorably presented by Linux China