This document is a brief introduction to cross-development for embedded systems on the Linux platform. It is aimed at software professionals who do not have any background in embedded device development. Working knowledge about software development in general and on Linux in particular is expected. The document quotes several external sources of information and provides links to all of them for further exploration.

1. Embedded Linux

Embedded Linux usually means Linux kernel running on a particular CPU and inside an embedded device. Kernel code base and API's are the same for embedded Linux as for desktop Linux, for the most part. (Blue Mug: Embedded Linux Survey )

2. Cross-development

Peter Seebach defines cross-compilation as follows: "Cross compilation occurs when a compiler running on one system produces executables for another system -- this is an important concept when the target system doesn't have a native set of compilation tools, or when the host system is faster or has greater resources." (Seebach, Peter: A cross-development primer )

Cross-compilation means compiling a program for a CPU architecture different from the one used on the machine where the compilation is done. This is accomplished using a cross-compiler toolchain and cross-compiled libraries.

Cross-development in general refers to the overall software development process that eventually produces a single application or a complete system running on an platform that is different from the development platform.

3. Platforms and targets

Platform means "a specific combination of operating system and hardware" (Everything2 ). The single most important part of hardware is the CPU, and usually platforms are defined as a combination of OS and CPU architecture: "Linux/i386", "Solaris/UltraSPARC", and so forth.

Cross-development usually involves two different platforms, the host platform where actual development work takes place, and the target platform where the final application is tested and run. In embedded Linux development, a typical host platform is a x86-architecture based Linux desktop computer. When discussing Scratchbox, the most widely used target platform is Linux/ARM, usually running on a StrongARM-based PDA or a similar device.

4. Toolchains

In a broad sense, toolchain is the set of tools used to build applications, or to create an image for an embedded device (Blue Mug: Embedded Linux Survey ).

When discussing Scratchbox, toolchain usually manages a slightly narrower part of the process; building and compiling the application. Compiler, assember , and linker form the core of a cross-compiling toolchain. They are supplemented by tools that facilitate pre-processing input (e.g. source files) and post-processing output (cleaning up binary executables, for instance).

One of the strengths of Scratchbox is the ease of changing between different toolchains. For example, you can set up one toolchain that uses the latest gcc with standard glibc and creates binaries for the (native) x86 target. Another toolchain can use slightly older gcc version with uClibc to produce binaries for an embedded ARM target. With a single command you can switch between these two toolchains and attempt to compile and build your project. This way, any portability problems are easily detected and remedied.

5. Automated build tools

Open Source Software (OSS) projects widely employ automated build tools to ease the development and testing processes. GNU Autoconf and Automake are two very common examples. They are often required when doing cross-development work, especially when porting existing software to an embedded platform.

Autoconf produces shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. (FSF: GNU Autoconf)

Automake is a tool for automatically generating Makefile information that is compliant with the GNU Makefile standards. (FSF: GNU Automake)

When used for cross-development, the fundamental problem with these tools is that they automatically detect and recognize certain features of the build environment. This is not desirable when build environment (host platform) is different to the target platform. Scratchbox ingeniously solves this problem by placing the whole build process within a dedicated sandbox environment; see Cross-compilation and cross-configuration explained - Proposed solution section for more details.

6. Related concepts

BusyBox is a single small executable that combines tiny versions of many common Linux utilities into it. (K computing, BusyBox mini-tutorial )

C library provides common file operations (open, read, write), memory management operations (malloc, free), and many other functions that make a Linux system a Linux system. Most Linux systems use Glibc . (Sundsted, Todd E.: Lightweight Linux, Part 1)

uClibc is a modern, stable, highly compatible replacement for Glibc. uClibc was developed for embedded systems and is therefore intended to be complete but lightweight. (Sundsted, Todd E.: Lightweight Linux, Part 1)

Configuration option is the basic unit of (source package) configurability. Typically each option corresponds to a single choice that a user can make. For example there might be an option to control whether or not assertions are enabled. (Red Hat: The eCos Component Writer's Guide)

Configuration is a collection of user choices, i.e. configuration options. (Red Hat: The eCos Component Writer's Guide)

Package in Linux is an archive of files for installing software easily. Each package contains a program and the scripts needed to install, configure, and remove it. In most cases, it also includes the on-line help files. (Debian: User's Guide)

Introduction to Cross-development for Embedded Linux