Open Embedded: An alternative way to build embedded Linux distributions
Customizing a distribution for a specific application
While Linux applications will always have a significant footprint, the needs for any individual application will be significantly less than the desktop-like distributions that are frequently the default for embedded distributions. As a result, developers will often need to minimize memory footprint or perform some other customization.
Another major challenge to embedded developers is the pace of change in the Linux software world. Although it is preferable to avoid falling too far behind the latest kernel releases since this creates challenges in backporting patches, at some point developers will need to lock down toolchain, kernel, and application package versions to go through test and get to production. This may involve creating some custom recipes or configuration files for a distribution picking up different component versions. Before customizing a pre-existing distribution, some time should be spent looking at what ‘canned’ options the distribution might offer. For example, Angstrom offers stable and development branches and builds with different footprints. If such options do not meet the needs for a particular application, then some customization is required.
Footprint reduction and scalability was one issue that drove development of Arago by TI. Another issue was corporate legal concerns about shipping GPLv3-licensed software and any encryption software, which would require additional compliance activities related to export control regulations. We will discuss some of the recipe and configuration file introduced in Arago to illustrate how a custom distribution can be derived from an existing distribution.
To address footprint and scalability, Arago simply created its own set of image and task recipes, some of which we have discussed already. For many applications, doing this may suffice. For Arago, it was necessary to modify some of the package recipes themselves. While a number of the modifications initially made in Arago were to fix generic bugs in the recipes that could be pushed upstream to the standard OE and Angstrom files, avoiding GPLv3 or encryption required changes that were not appropriate for pushing upstream. For example, since SSH includes encryption, we had to remove it from the default distribution. This had a knock-on effect on the busybox recipe, which needed a standalone telnet daemon to be enabled for remote shell access through its default configuration “defconfig” file. Since modified recipes need to be subsequently maintained to track changes in the mainstream ones, this approach is recommended only when there is no other alternative.
Eliminating GPLv3 content was achieved by forcing selection of gdb and gdbserver versions that were released prior to the introduction of the GPLv3 license or any patches released under that license. In addition to selecting specific GBD versions, Arago chose to use pre-built versions of the CodeSourcery toolchain. This reduced initial build times for users since there was no longer a reason to build the tools from source.
Rather than modifying the Angstrom configuration or recipe files, the approach chose to customize GCC selection for Arago in the local configuration file. This can be used to override the preferred versions in the distro configuration file. For example, Listing #10 of the sample Arago local configuration file sets new preferred versions of various gdb-related components and disables inclusion of SSH, to avoid the presence of encryption software. Note that using pre-built GCC binaries rather than building from source required adding and fixing support for external toolchains into OE beyond just selecting a particular version.
Listing #10: Local Configuration File Snippet
# Set some preferences
PREFERRED_PROVIDER_update-alternatives-cworth =
"update-alternatives-cworth"
PREFERRED_PROVIDER_ncurses-tools = "ncurses"
PREFERRED_PROVIDER_gdbserver = "gdbserver"
PREFERRED_VERSION_gdbserver = "6.6"
PREFERRED_VERSION_gdb = "6.6"
PREFERRED_VERSION_gdb-cross-sdk = "6.6"
PREFERRED_PROVIDER_libopkg-dev = "opkg-nogpg"
# Disable DropBear for now due to export restrictions
DISTRO_SSH_DAEMON = ""
Although the local configuration file was the primary customization method chosen in Arago, developers can also insert their own recipes using the BitBake search path and override some of the choices in the pre-existing distribution.
OE drawbacks
While OE is a powerful tool, it has a considerable learning curve and the source of build errors may not be obvious. Development teams that are unfamiliar with OE should allow at least several weeks to attain moderate proficiency. Therefore, unless there is access to a developer with previous OE experience, switching to OE during an existing project or using OE for the first time on projects with high-pressure schedules may be ill-advised.
The new commercial tools being introduced are intended to address some of the ease-of-use issues but obviously require licensing fees. The Narcissus project also provides an easy-to-use web-based front-end for building Angstrom-based root file systems for embedded devices.
A second drawback can be build times. OE builds everything from source the first time a developer builds a distribution with it, including the toolchain and a plethora of host tools. As a result, initial builds are extremely time-consuming and also require machines with at least a gigabyte of RAM. Obviously, subsequent builds are significantly faster as many components such as the toolchain will not need to be rebuilt. If the time required for incremental builds is still unacceptable, a good option is to use OE to produce an SDK that can be easily used with other build tools.
Conclusion
OE offers a way to create embedded Linux distributions that can leverage from a large database of pre-tested package build recipes. This can greatly shorten the time required to create a new distribution. In addition, there are a number of pre-existing distributions that can serve as starting points for developers to create their own distributions. OE is powerful and very flexible, enabling developers to tailor distributions to their specific application needs. The flip side of this power and flexibility is a significant learning curve. As a result, it is best to develop expertise with OE outside of a committed project schedule environment.
Useful Links
For further information on the TI Arago distribution and to review or download the full selection of its recipes and configuration files, go to arago-project.org. Information on the Angstrom distribution is available at: angstrom-distribution.org/. To access a web-based based tool for building Angstrom-based root file systems, go to angstrom-distribution.org/narcissus/. The wiki for OpenEmbedded may be found at wiki.openembedded.net. A free introductory course on OpenEmbedded can be accessed at free-electrons.com where you should scroll down to the Embedded Linux System Development section.
Nick Lethaby (nlethaby@ti.com) is the operating system product manager at Texas Instruments, where he is responsible for product requirements definition for the DSP/BIOS(TM) real-time operating system and multimedia SDKs. Lethaby has over 20 years of applications engineering, product management and marketing experience in embedded systems development tools. He has worked in various other product management and marketing positions since he graduated from the University of London with a bachelor of science in computer science.
Denys Dmytriyenko is a Linux and open source technologist at Texas Instruments whose job is to work with TI internal teams and external open source communities. He has been with the company for nine years. He received his MS in Computer Engineering from the Chernigov State
Technological University in Ukraine.
Loading comments... Write a comment