Table of Contents
Table of Contents
Linux is becoming increasingly popular in embedded systems. The TiVo digital video recorder, for example, uses a customized version of Linux. Companies like LinkSys are using Linux to power their network routers. And the Nokia 770 Internet Tablet is a portable Internet appliance that runs Linux.
Linux offers several benefits that explain its popularity in embedded systems:
Despite this maturity, the process of getting a bootable Linux kernel onto an embedded system is still quite complex and labor-intensive. In addition to configuring and compiling Linux itself, there is the added burden of building a toolchain that matches the architecture of the embedded device. A filesystem must also be constructed with the appropriate libraries, initialization scripts, and other files necessary for a fully functional Linux system.
The complexity of building Linux for an embedded system is a widely recognized problem, and there are several known methods of dealing with it.
For the ultimate in freedom and flexibility, you can build Linux from scratch, tailoring the kernel, the toolchain, and its libraries to your particular needs. This freedom comes at a price, however: Building every component from scratch requires a great deal of knowledge and effort. Although documentation can help (e.g., “Building Embedded Linux Systems”), the manual approach is tedious and time-consuming.
The polar opposite of the manual approach is the proprietary Linux development kit. These commercial products are normally designed for one particular embedded device, usually sold by the same company that created the kit. They offer a turn-key solution: You simply install the kit and you're done. The toolchain and kernel are virtually guaranteed to work.
The drawback to these products is that they severely limit freedom and flexibility. They often lock you into specific versions of compiler, kernel, and libraries. In addition, proprietary development kits are usually very expensive. Price tags often run into the four-digit range.
An alternative to the proprietary development kit is the open-source development kit. In keeping with the spirit of Linux, such kits can be downloaded for free. An example of such a kit is Embedded Gentoo. It provides a complete infrastructure for creating embedded Linux systems.
Because Embedded Gentoo is based on Gentoo, it is quite large and complex. Its goal is to support every conceivable embedded device, so it consists of many packages and also includes several sub-projects. This complexity can make the kit difficult to learn and use.
For example, Embedded Gentoo relies extensively on the emerge tool. While emerge is suitable for desktop systems that have thousands of packages to manage, it is overkill for developing embedded systems, which normally consist of only a few basic packages. In addition, the dependency on emerge restricts Embedded Gentoo to development hosts that run Gentoo. If you prefer another distribution, you won't be able to use it.
Another open-source development kit for embedded Linux is ELDK. Like Embedded Gentoo, it is large and complex. The base installation, for example, is over 700 MB. It, too, relies on a package management system for installing and upgrading packages. Despite this complexity, ELDK's only supports PowerPC targets.
Propelant, or PRogrammable One-step Preparation of Embedded Linux using ANT, shares the same goal as these existing tools: It makes building an embedded Linux system easier. However, the design and implementation of Propelant are quite different from any prior approach, and it offers some unique advantages as a result. Its key features are summarized below:
Table of Contents
Follow these instructions to install Propelant for the first time.
~/projects/embedded).
If you have already installed an older version Propelant and wish to upgrade a newer version, follow these steps.
build.xml file and the propelant directory.
Table of Contents
Propelant builds an embedded Linux system in seven basic stages:
Each of these stages must be configured for the needs of your particular embedded device. In most cases, the configuration process is very simple. For example, to configure BusyBox, you simply use BusyBox's built-in configuration program to specify the applets you want to build.
Propelant's settings are stored in two places, each of which belongs in your workspace directory:
build.properties file
settings directory
If you are new to Propelant, you can start with a ready-made configuration for the EP405, located in the templates directory. Simply copy the contents of this directory to your workspace. You can then use the settings as a template, modifying only what is necessary for your particular device.
The following sections describe the settings for each stage in more detail.
Propelant uses crosstool to build a toolchain for your target. You can specify which version of crosstool to use, as well as which toolchain components crosstool should build, by editing the variables in build.properties. You can find more details about these variables in the crosstool-howto.
crosstool ships with a large number of patches that allow it to build many different combinations of the toolchain. However, there may be some combinations, especially with newer versions of the components, for which crosstool does not have the appropriate patches. In this case, you can supply your own. Simply copy the patches into the patches/crosstool directory of your workspace. For example, a patch for GCC 3.4.6 should be placed into patches/crosstool/gcc-3.4.6. Propelant will automatically find these patches and install them into crosstool. See the templates/patches/crosstool directory of the Propelant distribution for some examples.
You can specify which version of the Linux kernel to build by editing the build.properties file. You can also specify other basic options such as which target to use for cleaning the kernel.
For the finer grained configuration that is necessary for embedded systems, you will need to supply a standard Linux configuration file. This file should be placed in the settings/kernel directory of your workspace. Make sure that the kernel.config.file option of build.properties points to this file.
To create or edit a kernel configuration file, see the section called “Kernel Usage”. An example can be found in the templates/settings/kernel directory of the Propelant distribution.
If the kernel needs to be patched, simply place your patch files into the patches/kernel directory of your workspace. Propelant will automatically apply them before building the kernel. For some examples of kernel patches, see the templates/patches/kernel directory of the Propelant distribution.
The directory structure of the root file system is specified in your build.properties file. You can also specify which libraries should be copied to the root filesystem. See the templates/build.properties file for an example.
Linux needs certain initialization files, such as /etc/inittab, in order to boot properly. To include these initialization files in your root filesystem, simply copy them to the settings/init-scripts directory of your workspace. They will end up in the /etc directory of the root filesystem. See the templates/settings/init-files directory of the Propelant distribution for some sample initialization files.
Configuration of BusyBox is similar to configuration of the kernel. You can specify the BusyBox version and a configuration file in your build.properties file. (The standard location of the file is the settings/busybox directory of your workspace.)
See the templates/settings/busybox directory of the Propelant distribution for a sample BusyBox configuration file.
For information on how to create and edit a BusyBox configuration file, see the section called “BusyBox Usage”.
System applications are any additional third-party libraries or programs that you may need for your embedded system but are not part of the kernel, the toolchain, or BusyBox. For example, if you need to run Java on your device, a Java virtual machine would be a “system application.”
To set up a system application for a Propelant build, follow these steps:
scripts/system-apps.
jamvm.xml.
get-jamvm, build-jamvm, and install-jamvm. See the templates/scripts/system-apps directory of the Propelant distribution for examples of system application build scripts. Note that Propelant's helper macros, described in Appendix A, Helper Macros, may help simplify your build script.
build.properties file, add a property called system-apps.list. Set this property to a comma-separated list of the system applications you wish to build. Each value in the list must correspond to the name of a build script (minus the extension) in your scripts/system-apps directory.
Once this is done, Propelant will automatically add your system application to the build process.
Configuration of user applications is entirely up to you. Simply create a build.xml script for your application (or applications), and place it in the apps directory of your workspace. Propelant will then call this script during the build process.
Note that all of the Propelant properties, such as the location of the root filesystem (root-filesystem.dir), will be available to your build script.
Table of Contents
Once configured, Propelant can build the complete embedded Linux system in one step. Simply type ant at the command line. This will download all of the packages, unpack them, configure them, compile them, and install them.
If at some point you want to start the build over from scratch, simply delete the build directory. This will remove all of the downloaded and generated files while leaving your configuration files intact.
If you want Propelant to perform the build stages one at a time, you can specify the following targets:
For example, to build the toolchain only, type ant toolchain at the command line.
Note that some of these targets depend on others having already run. You cannot build the kernel, for instance, without first building the toolchain.
There are additional build targets that offer finer grained control of each stage. (You can see a list of them by typing ant -projecthelp.) For example, if you only want to download and configure the kernel, but not build it, type ant get-kernel patch-kernel configure-kernel-from-file. The following sections describe some of these additional targets in more detail.
The kernel stage includes special targets for creating and editing configuration files.
configure-kernel-from-file, which is the default for Propelant builds, configures the kernel based on an existing configuration file. This file is specified by the kernel.config.file property.
configure-kernel-default configures the kernel using an existing configuration file supplied by the kernel itself. These files have a defconfig suffix and are located in the arch directory of the kernel distribution. To specify the file to be used by this target, set the kernel.default.config property.
configure-kernel runs the kernel's built-in configuration editor. You can use this editor to create or edit a configuration file. By default, Propelant runs the text-mode editor, but you can switch to the graphical one by changing the kernel.configure.target property.
You can also “clean” the kernel's generated files using the clean-kernel target. To control which method the kernel uses for cleaning, change the kernel.clean.target property.
The BusyBox stage includes special targets for creating and editing configuration files.
configure-busybox-from-file, which is the default for Propelant builds, configures BusyBox based on an existing configuration file. This file is specified by the busybox.config.file property.
configure-busybox-default configures BusyBox using an existing configuration file supplied by BusyBox itself. To specify the file to be used by this target, set the busybox.default.config property.
configure-busybox runs BusyBox's built-in configuration editor. You can use this editor to create or edit a configuration file.
To report a bug, request a new feature, or discuss this project with other users, visit the Propelant project page.
Propelant is maintained by Trevor Harmon.
Propelant includes several helper macros to simplify its work, and these macros are available for writing your own system or user application build scripts.
configure runs a GNU Autoconf configure script
make runs GNU Make's make command
mknod runs the UNIX mknod command
ln runs the UNIX ln command
cp is a replacement for Ant's built-in Copy task, which does not preserve links or file permissions
unpack is a replacement for Ant's built-in UnTar task, which does not preserve file permissions
Copyright © 2006 Trevor Harmon
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL TREVOR HARMON OR ANY OTHER CONTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.