This is the first in a multi-part series on the OpenEmbedded development environment. This and subsequent articles will provide an introduction to OpenEmbedded, why to use it, how it works, and will provide examples of how BEC has used OE in various projects.
Part 1 — Why do we need OpenEmbedded? This article discusses some of the problems developers face when building embedded Linux systems, such as collecting the pieces needed, setting up a repeatable build environment, cross-compiling, customizing a system, and licensing issues. Future articles will cover how OE addresses some of these issues.
Embedded Linux = Complex System
The fundamental problem with building Embedded Linux systems is the sheer complexity. Lets face it, there is a lot going on in a typical Embedded Linux system. Millions of lines of code are being compiled. Typically there are tens to hundreds of applications and libraries that need to be built. Linux supports many different processor architectures. The size of Linux leads to the conclusion that a good deal of automation is required to manage all this. In my paper “Tips for Planning your Embedded Linux Project” (http://bec-systems.com/web/content/view/35/37/ ), the analogy of the Iceberg is presented. The application specific software in the project is the part of the Iceberg that is above water — the part you see. Most of the system (Linux and system applications) is below water — you don’t see it. The part under water is the big unknown and has the potential to add a lot of variance to a project. Note: this problem is not specific to Linux — any system of this complexity that is targeted to so many different applications faces the same problem. As a side, one might ask why use Linux if it is so complex? The answer is simple — features. Linux has the features and device support required for many Embedded products to be competitive.
Collecting and building all the pieces
There are a lot of pieces of software that need to come together to build an Embedded Linux system. This may include a toolchain, kernel, system libraries, and many system applications and configuration scripts required to make a system work. The is not something you want to do manually, or building an embedded Linux system quickly becomes impractical for most developers.
Repeatable Builds
With any software project, it is highly desirable to have a build system that is easily repeatable — which means it can be reproduced at any time on a wide variety of development workstations. Some of the of the situations I have run into that are less than desirable are:
- Being dependent on a vendor to provide a pre-compiled root file system image for a system. What happens when you need to add something two years down the road (such as foreign language support) and you don’t have a build system where you can easily reproduce the current build?
- Being dependent on a golden build machine that takes a lot of work to set up and is very difficult to reproduce. If you have a build environment where all the developers use one machine to build software, you may want to investigate if you are in this situation.
What is really needed is a build system where you can check the build system out of a source control system onto about any Linux workstation at any point in time, type make, and a few hours later you have an image.
GPL Compliance
If you distribute binaries in your product compiled from GPL software, you must offer to provide the source code for these binaries. Do you have easy access to the source for everything that is in your product? Do you even know what all is in your product? It is not good enough to simply point to someone else’s distribution or web site and say “I use that”. As the founder of the MEPIS distribution discovered, the GPL license explicitly states the distributor of the GPL code is obligated to provide source code for up to 3 years. So if you build a distribution by copying binaries from a pre-build distribution, you may have a problem. In one case I am familiar with, a company was in the last stages of a multi-year product development cycle. They then discovered that they did not have the source code used to build the GPL binaries in the system. The company that built the distribution for them was out of business and the open source project the binaries where originally obtained from no longer maintained the sources. Although it may be possible to find all of the old sources, it is a huge amount of work and would probably be easier to just start over and build new distribution.
Customizing the system
For most embedded systems, the distribution needs to be customized. There are often requirements such as custom software update schemes. Ideally, a good build system should easily allow you to integrate changes into the build system in a automated way, so that you don’t have any manual steps in the process of creating an image for the embedded system.
Cross Compiling
The above “repeatable build” requirement that you be able to build an image for your embedded target on about any Linux workstation leads to a requirement for cross-compiling. Cross-compiling is the process of creating executable code for a platform different than the one on which the cross compiler is run (http://en.wikipedia.org/wiki/Cross_compiler). Cross compiling many standard open source applications and libraries can be difficult on a good day, and near impossible on a bad day, as many of them were not written with cross compiling in mind. Therefore, a good build environment should have tools that automate the process of cross-compiling as well as provide the ability to easily cross compile the many common programs and libraries that may be needed in an embedded Linux system.
Summary
As we examine some of the challenges, it should be obvious that putting together a production embedded Linux system is not something to be done in an ad-hoc fashion. There are several ways to approach this problem. Stay tuned for future articles where we explore how the OpenEmbedded build system solves these problems (subscribing to our blog or newsletter is a good way to do this).
Also, please post comments about your experiences — we like to hear and learn from you. We are also interested in what problems you face when building Embedded systems. This input will be used when writing future articles. Thanks!