Building Embedded Systems using Open Source Software

Joe Schartman

November 23, 2005

Abstract

This report discusses the issues and steps necessary for building embedded systems (ESs) using free open source software (OSS) tools. Some of the issues covered include required experience and the restrictions with the associated licenses. Understanding these issues will help program management make system decisions between using commercial off the shelf (COTS) products or building custom OSS systems. Following the steps covered in this report will enable experienced software developer's to build an OSS ES.

The central component of OSS is Linux, which is the operating system (OS) kernel that controls all of the software tools and running applications. Thus, how to build a Linux kernel using OSS tools for an ES application will be the focus of this report. Linux has been adopted by a majority of ESs developers, as reflected in the current commercial offerings discussed in the below introduction. Several of the main reasons for this adoption include its sophisticated scheduling and networking, its cost-free license, its open development model, and the support offered by many powerful programming tools.

The free availability of Linux is a big advantage to small developers but the challenge is learning what tools are available and how to use them. This is especially true for embedded development versus attempting to build Linux for a personal computer. The challenge for ES developers is building and using tools that are separate from the default tools on the host development computer. This report discusses ES development using OSS and the Linux kernel and offers a solution to the OSS challenge by covering the following procedures:

```
Building a cross development toolchain 
```

Configuring, building, and installing a target-specific kernel

```
Creating a target filesystem 
```
```
Using custom storage devices 
```

Installing and configuring a target bootloader

```
Debugging the embedded system 
```

Table of Contents

Chapter 1. Introduction ………............................................………....... 5

       Licensing ………...........................................................………....... 5
       Popular Embedded Linux Systems  ……......................………....... 5

Chapter 2. Hosts and Target Setups Options ….....................……........ 6

Types of Development Hosts ........................................................... 6

      Types of Host/Target Development Setups ...................................... 6
      Types of Host/Target Debug Setups ................................................. 7
      System Startup .................................................................................. 7
      Generic Architecture of an Embedded Linux System ...................... 8

Chapter 3. Hardware Choices …........................................................... 8

Buses and Interfaces .........…........................................................... 8

Storage …......................................................................................... 8

Networking ….................................................................................. 8

Monitoring ….................................................................................. 9

Chapter 4. Development Tools …........................................................ 10

      Host-Target GNU Development Toolchain ..................................... 10

Chapter 5. Kernel Considerations …..................................................... 11

Selection …....................................................................................... 11

Configuring ...................................................................................... 12

Compiling ........................................................................................ 12

Installing ......................................................................................... 12

Chapter 6. File System Issues …........................................................... 13

     System Initialization …..................................................................... 13

Root Filesystem Structure …............................................................. 14

Chapter 7. Storage Device Setup …...................................................... 15

      MTD-Supported Devices …............................................................. 15
      Disk Devices …................................................................................ 15

Chapter 8. Root Filesystem Choices ..................................................... 16

      Selecting a Filesystem ...................................................................... 16

Chapter 9. Boot Loader Issues…........................................................... 16

      Server Setup for Network Boot ....................................................... 16
      U-Boot ............................................................................................. 16

Chapter 10. Networking Services and Options …................................. 17

Setting Up Networking Services

     The Internet Super-Server

Chapter 11. Debugging Tools…............................................................ 17

Debugging Applications with gdb .................................................... 17

     Hardware debugging options ............................................................ 17

Chapter 12. Conclusion ………............................................................. 19

Appendix A: Revised Proposal …......................................................... 20

Appendix B: Revised Progress Report …............................................... 25

Appendix C: Acronyms ……..............................................….….......... 27

References ……….............................................................…….............. 28

List of Figures

Figure 1 – Linux System Architecture …......................……................... 8

Table 2 – Common Directory Layout ……......................…................. 11

Table 3 – Embeddeded System Filesystem Layout ……….................. 15

Chapter 1. Introduction

Building an ES is now possible for any experienced software (SW) programmer because of free OSS tools and associated licenses.  An ES is a minimal system that has a custom software application controlling its functions.  Such a system is usually developed on a host computer and then downloaded to the target ES system. By following the sections in this report and researching the cited references, an experience SW developer will be able to design and implement an ES.  This report is written for such developers but also explains critical issues that management and architects should underderstand for making ES project decisions.

For a excellent history and overview on the OSS development model, read The Cathedral and the Bazaar (Raymond 2001). It is also very helpful to have a hardware and software background including development, programming and debugging for embedded systems. Understanding of kernel operation and device drives is also helpful. An excellent book covering these topics is Embedded Systems Design (Berger, 2001).

This report uses bold text to indicate a user input and italic font for file and command names. A list of all used acronyms is supplied as Appendix C.

Licensing

This report starts by discussing licensing issues and several of the most popular embedded systems (ES) currently available commercially. It then moves to the basics of building embedded Linux systems. "Open source" and "free software" are general terms that apply to many variants of licenses for software packages. These licenses cover restrictions on how the associated open source software (OSS) can be modified and distributed. The most important Linux components, including the kernel itself, are distributed under the GNU General Public License (GPL). The Berkeley Software Distribution (BSD) OSS license is similar but less restrictive since it allows redistribution of binaries without the original source code. OSS is available without any access restrictions, usually via Internet download and the associated licenses allow developers to modify, and redistribute the software. The default restriction for these licenses is providing the same rights to any of the generated software users. These restriction rights vary according to the license used (GPL, Lesser GPL (LGPL), BSD, Mozilla Public License (MPL), etc.) and does not imply a loss of copyrights and patents control for newly developed software.

Popular Embedded Linux Systems

The important point to remember for doing ES development using Linux and OSS tools is that all these development tools are available free of charge, and the licenses under which they are distributed prevent the collection of any royalties. Most developers do not have the time to search for the many OSS tools, components and versions and then work out all the build dependencies and problems. Because of this time concern, developers usually use a packaged vendor distribution. These vendors provide support for their distribution for a fee and offer services for porting their distributions to new architectures and developing new drivers, all for profit. This situation explains why the following distributions are very popular and profitable:

- WindRiver Systems (WRS) Tornado http://www.windriver.com
- LynuxWorks Bluecat http://www.lynuxworks.com
- GreenHills Integrity http://www.ghs.com/
- QNX Neutrino http://www.qnx.com/
- MontaVista http://www.mvista.com/

The trend is to offer freeware versions based on Linux and customized versions that offer more guaranteed “hard real-time” performance for profit. Linux is the preferred OS for ES development and these systems are now found in many everyday gadgets including mobile phones, medical equipment, vehicle navigation systems, automated bank tellers, MP3 players, printers, autos, ....

Chapter 2. Hosts and Target Setups Options

Types of Development Hosts

A Linux workstation is the most common type of development host for embedded Linux systems and the best choice for developing them.  There are many different Linux OS choices for a development workstation installation.  The most popular choices are Red Hat, Fedora, Suse, Debian, and Mandrake. All of these distributions are easy to install, allow for many personal preferences, and include development and kernel building tools.  Remember to include these building tools when installing the distribution.

Types of Host/Target Development Setups 
 
Three different host/target architectures are common for embedded Linux system cross development: linked setup, removable storage setup and standalone setup. There are also three different host/target interfaces common for linking a target to a host for debugging.  These interfaces include serial line, networking interface and special debugging hardware.  The following is a discussion of the linked host/target setup, which is the most common.

Types of Host/Target Debug Setups

Using a serial link is the simplest choice for target debugging because serial hardware is usually included in embedded systems. Serial links are the slowest option and having only one serial port in the embedded system makes it impossible to both debug the system and interact with it while using a terminal emulator.

Using a networking interface, like TCP/IP over Ethernet, is preferable for debugging and downloading because of the much faster speed. The network stack code is part of the Linux kernel, so debugging the kernel often requires using a serial port since failing network stack code will not support the Ethernet interface. Developing and debugging a custom kernel is usually the most challenging part of an ES and the reason why many developers choose one of the popular commercial distributions. Wth the commercial choice, the developers can concentrate on the application code. For developers who choose to write custom kernel's, the BDM and JTAG debuggers are the least expensive options verses an In-Circuit Emulator (ICE) debugger. These interfaces use special hardware to communicate with the kernel.

System Startup

The ES startup is handled by the bootloader, the kernel, and the initialization “init” process. The bootloader is the first software to run and is responsible for downloading the kernel and the filesystem to the target's hardware. The bootloader will perform low-level hardware initialization and then pass control to the kernel's startup code. The start kernel function then initializes the required kernel functionality, mounts the root filesystem, and starts the initialization process. See Chapter 6 System Initialization for more details on initialization process.

Generic Architecture of an Embedded Linux System

Figure 1 - Linux System Architecture

There is little difference in the high level description and architecture between an embedded Linux system and a workstation or server system.  The four major subsystems are user applications, O/S services, the kernel, and the hardware controllers.  The user applications are what give the system its unique abilities and support the target application such as a cell phone, a vehicle navigation systems, or a MP3 player.  The O/S services include the system monitor and command interface.  The kernel is the main interest of this report since it controls access to the hardware resources, schedules the software processes and is the central interface to an ES application.  The hardware controllers include all of the required physical devices for the processor, memory, Input/Output (I/O) and network interfaces.  A good reference book for information on understanding, installing, and using the Linux operating system is Running Linux (Welsh, Dallheimer, and Kaufman, 1999).

Chapter 3. Hardware Choices

ES hardware supported by Linux is dependent on the processor architecture or central processing unit (CPU).   The CPU controls the common hardware components including buses, I/O, storage, general-purpose networking, and system monitoring.  The most common architecture family is the Intel x86 which started with the 386 introduced by Intel in 1985 and now includes the Pentium family,  along with compatible processors by other vendors such as AMD and National Semiconductor.

Buses and Interfaces

The buses and interfaces are the channels that connect the CPU to the system peripherals.  The Industry Standard Architecture (ISA) bus has been favored by developers because of its simplicity.  This bus allows device access via I/O port programming which is part of the  x86's instruction set.  This simplicity means the kernel is not involved in ISA bus transfers.  Many developers are now transitioning to the Peripheral Component Interconnect (PCI) bus since they can use common kernel device drivers to program these type of bus transfers.  Another advantage for using the PCI bus is a larger number of tools for manipulating PCI devices. 

A few other buses that are popular include Personal Computer Memory Card International Association (PCMCIA), PC/104, VME, CompactPCI and  Small Computer Systems Interface (SCSI) , Universal Serial Bus (USB) and IEEE1394 (FireWire).  USB and FireWire are now the most popular buses for high bandwidth applications like streaming media devices.  Developer's need to research the device drivers available for the desired bus choices to insure support and compatibility with  the other ES devices.

Storage

All ESs require at least one form of persistent storage to start the boot process.  Most ES continue to use this same initial storage choice to run the developed application and transfer the data.  Memory technology devices (MTDs) include all memory devices, such as conventional RAM, ROM, DiskOnChip (DOC), and  flash chips. As explained in Programming Embedded Systems in C and C++ (Barr, 1999), such devices have their own capabilities, peculiarities, and limitations. Hence, to program and use an MTD device in their systems, ES developers traditionally use tools and methods specific to that type of device.

Networking

It is very common now for ESs to be attached to networks and Linux supports many different network interface cards, devices and chips.  A good source covering this area is Ethernet: The Definitive Guide (Spurgeon, 2000).  The kernel build configuration menu is the first place to check to see if a network hardware interface is supported.  Also remember that industrial grade applications need to use a specialized network interface to help shield  higher levels of EMI (Electromagnetic Interference) and RFI (Radio Frequency Interference).

Monitoring

System monitors are critical for detecting the eventual  hardware and software failures.  An ES designer needs to design recovery mechanisms, and system monitors are typically the best choice.  System monitors often use hardware (H/W) and software (S/W) features, like watchdog timers. These timers depend on periodic resets of the S/W otherwise the system will be rebooted because the system will assumed that the S/W has failed. H/W status and health monitors provide data tracking of the system's physical state. This information is checked and when necessary routines will be called to alert or correct physical problems 
such as out of range temperate or electrical values.

Chapter 4. Development Tools

Host-Target GNU Development Toolchain

The embedded developer's tools are typically used on a development platform to build applications for the target platform.  These tools are called cross-development tools, and the developed application is cross targeted by downloading to the  ES .  There are quite a few choices involved in the setup, configuration, and use of cross-platform development tools.  The most common choice is the GNU cross-platform development toolchain.  Other choices include using the C library alternatives, Java, Perl, Python, Ada,  other programming languages, integrated development environments, and terminal emulation programs.  The developer should organize the software packages and project components in a directory structure following commonly used conventions. Table  2  (Yaghmour, 2003, p.107)  shows a common  directory layout following standard conventions.

Table 2 Common Directory Layout
Directory	Content
bootldr	The bootloader or bootloaders for your target
build-tools	The packages and directories needed to build the cross-platform development toolchain
debug	The debugging tools and all related packages
doc	All the documentation you will need for your project
images	The binary images of the bootloader, the kernel, and the root filesystem ready to be used on the target
kernel	The different kernel versions you are evaluating for your target
project	Your own source code for this project
rootfs	The root filesystem as seen by the target's kernel at runtime
sysapps	The system applications required for your target
tmp	A temporary directory to experiment and store transient files
tools	The complete cross-platform development toolchain and C library

The GNU toolchain is used to develop applications for many different  targets and requires the C compiler (gcc), the C library (glibc), and binary utilities (binutils).  The cross-platform development toolchain requires the same elements only for the target architecture compiler.  The development system will therefore need toolchains for both the development and the desired target systems.  These multiple toolchains  require  building cross-development toolchains that are independent of the host toolchain and this can be problematic since if not done correctly because the host system tools may get overwritten.
 
The components of the GNU toolchain can be downloaded from the Free Software Foundation's (FSF's) FTP site at ftp://ftp.gnu.org/gnu/ or any of its mirrors.  The gcc, glibc, and  binutils packages are in the gcc, glibc, and  binutils directories, respectively.  Also make sure to get the glibc-linuxthreads package which is also in the glibc directory.

Chapter 5. Kernel Considerations

Selection

The kernel is the central component for an ES.  This component choice determines which system capabilities can be controlled. The Linux kernels are only maintained at the www.kernel.org repository.  The processor kernel patches need to be downloaded to support the ES are dependent upon the architecture selected.  A highly recommended reference book is Understanding the Linux Kernel  (Bovet and Cesati, 2000).

Configuring

Many different kernel configuration options exist for the provided features of an ES. Several of the most common procedures for setting the configuration options include make config, and make menuconfig, both of which generate a .config command  file. This command file can now be executed to set the configuration options.

Compiling

Compiling the Kernel includes building the dependencies, the image, and the modules. Each of these build steps uses the associated make command. For a detailed explanation of these commands and all the various options consult the book Building Embedded Linux Systems (Yagmour, 2003 O'Reilly, p.164-168).  The following command builds the kernel's dependencies: 

   $ make ARCH=ppc CROSS_COMPILE=ppc-linux-gcc clean dep

The ARCH and CROSS_COMPILE parameters are very important because they designate the target ES architure and tools.  The next step is to build the kernel using the following command:

   $ make ARCH=ppc CROSS_COMPILE=ppc-linux-gcc zImage

The above zImage target indicates a compressed gzip kernel is produced. Rather than specifying zImage, the default noncompressed vmlinux target could be used.  The last build step for building the kernel is selection of the modules, which is shown using the following command:

   $ make ARCH=ppc CROSS_COMPILE=ppc-linux-gcc modules

Kernel module usage can be minimized by selecting fewer module options and then later linking them into the main kernel image.

Installing

The kernel makefile specifies a modules_install target which is installed to the 
 /lib/modules directory by default.  For an ES using a cross-development environment (CDE), another APPROOT directory will need to be set so the host modules are not overwritten.  Note that APPROOT is called an  environmental  variable that commands and scripting languages typically use as a programming variable.  The following command is an example:

   $ make ARCH=ppc CROSS_COMPILE=ppc-linux-gcc INSTALL_MOD_PATH=${APPROOT}/images/modules-2.6.8 modules_install

Once the modules are installed the dependencies need to be resolved.  Typically the  depmod utility performs this resolution, but it will fail since this is a CDE. Another utility available for CDE is called depmod.pl.  Dependencies can be built for the CDE using the following command:

   $ depmod.pl -k ./vmlinux -F ./System.map -b ${APPROOT}/images/modules-2.6.8   {APPROOT}/images/modules-2.6.8/modules.dep

This resolved kernel and its modules will need to be installed to the ES target.  There are four required files that need to be copied:  the compressed kernel image, the uncompressed kernel image, the kernel symbol map, and the configuration file. These files are typically named: 

   ${APPROOT}/images/zImage-2.6.8
   ${APPROOT}/images/System.map-2.6.8
   ${APPROOT}/images/vmlinux-2.6.8
   ${APPROOT}/images/2.6.8 .config

The  substring  2.6.8 in the above file names represent version 2.6 and release 8 for the kernel software.

Chapter 6. File System Issues

System Initialization

System Initialization uses the standard init package found in most Linux distributions.  This init file expects a /etc/inittab file and the /etc/rc.d directory with the service files for each run level.  The /etc/inittab file defines the runlevels for the system and which services are included for each run level. For ESs, there are minimal init packages available and the most popular one is BusyBox, which is ideal since it contains most of the utilities that an ES will need in very minimal versions.  These versions only support the options that are most commonly used for the utilities, thus are much more compact.

Root Filesystem Structure

The Linux filesystem is the standard storage structure where the system libraries, kernel modules, kernel images, device nodes, and application programs are stored. The kernel mounts the filesystem at the end of the boot startup process. The Filesystem Hierarchy Standard (FHS) specifies the expected layout for a linux filesystem. Table 3 (Yaghmour, 2003 O'Reilly, p.172) shows a minimal filesystem structure for an ES, thus many of the FHS directories will not be required. See http://www.pathname.com/fhs/pub/fhs-2.3.html for all the details on the FHS.

Table 3 Embedded System Filesystem Structure
Directory	Content
bin	Essential user command binaries
boot	Static files used by the bootloader
dev	Devices and other special files
etc	System configuration files, including startup files
home	User home directories, including entries for services such as FTP
lib	Essential libraries, such as the C library, and kernel modules
mnt	Mount point for temporarily mounted filesystems
opt	Add-on software packages
proc	Virtual filesystem for kernel and process information
root	Root user's home directory
sbin	Essential system administration binaries
tmp	Temporary files
usr	Secondary hierarchy containing most applications and documents useful to most users, including the X server
var	Variable data stored by daemons and utilities


Chapter 7. Storage Device Setup

MTD-Supported Devices

The next step after building the root filesystem is preparing the target's storage devices. ESs typically use solid state storage devices rather than hard drives which are more typically are used for workstations and servers. Solid state storage refers to devices without moving parts like the moving head arm for a hard drive platter. Solid state storage well suited for ES because of reduced size and increased durability to shock. These devices include flash chips and flash disks. The setup and configuration of these devices also requires a different set of commands which are available in the memory technology devices (MTD) Linux kernel subsystem. Kernel configuration of the MTD subsystem is part of the main menu of the kernel configuration options. The desired kernel configuration options will need to be configured for the ES storage devices that are installed.

Disk Devices

Using disk devices with Linux ESs is similar to Linux workstations or servers. Typical usage includes:

$ fdisk /dev/sda (partitioning)
$ mkdir /mnt/cf (creating mountpoint)
$ mke2fs /dev/sda1 (creating filesystem)
$ mount -t ext2 /dev/sda1 /mnt/cf (mounting filesystem)

Chapter 8. Root Filesystem Choices

Selecting a Filesystem

The next step after building the kernel and preparing the target's storage devices is setting up the root filesystem (FS) . First, a FS type for the root FS needs to be selected. Then, the root FSs contents need to be converted to the selected FS format to install the root FS on a device formatted for the selected FS type. The requirements regarding FS selection include:
- shall the FS be writable?
- shall the FS preserve reboot changes?
- shall the FS perform power failure recoveries?
- shall compression be used for the mounted filesystem?
- shall the FS's transer RAM data before mounted?

The most common FSs supporting these requirements are CRAMFS, JFFS2, JFFS, Ext2, and Ext3 and the choice of FS needs to be determined depending on the above issues. For example, Ext3 improves on Ext2 by performing journaling so if power failure recoveries are critical then the Ext2 FS should be ignored.

Chapter 9. Boot Loader Issues

Server Setup for Network Boot

Configuration of a bootloader for the setup of the root FS and kernel is the next logical step in buiding an ES.  The booloader copies the kernel image and root FS to a solid-state storage device so that the ES is functional.  The configuration of the bootloader is dependent upon the target processor, board and hardware architecture. There are many different bootloaders available for Linux and most are capable of being configured for many of the different H/W and S/W services. One of the most common configurations would involve configuring a server providing BOOTP/DHCP and NFS services. The target ES will then use these services to obtain a kernel image and mount the root FS, respectively.

U-Boot

The U-Boot bootloader is used for most PowerPC (PPC) ESs and was originally called PPCBoot.  This bootloader is probably the most widely used and flexible tool available.  Other good reasons for choosing this bootloader include: extensive documentation, support, and online mailing lists available.  Also, the U-Boot commands and environmental variables are standard linux so do not require learning a new interface.

Chapter 10. Networking Services and Options

Networking Services are often included and expected with ES.  These services are often used for downloading code during development, and reprogramming.  They also support system debugging, remote login capabilities, maintenance and upgrades, and occasionally   to run a web or file server for documentation and configuration.  The Linux kernel provides high reliability networking services and works well with networking applications.  Providing the most reliable networking services and applications helps to make Linux the most popular choice for ESs.

The most popular networking services include the Internet super-server (inetd), remote administration with SNMP, network login through Telnet, secure communications with SSH, serving web content through HTTP, and dynamic configuration through DHCP.  Linux Network Administrator's Guide (Kirch and Dawson, 2000) is an excellent source for details on different network protocols and administration.

Chapter 11. Debugging Tools

Debugging Applications with gdb

Once an ES system is setup, configured, built and the software is downloaded, then debugging tools are necessary to get the system working. Debugging is required for all software since it is almost never coded error free, especially for ES applications. The GNU debugger (gdb) is the most common tool for debugging, which usually involves stepping through source code statements and examining memory locations. The ES should be built with a gdb server so that remote debugging can be performed from the host development system. To debug the ES application, it must be built using the appropriate flags which require adding the -g option to the gcc compiler command line.

The gdb server running on the target communicates with the gdb debugger running on the host using either a network TCP/IP or serial link connection. The network connection is preferable because of much faster response time. Both options require starting the server and connecting to it from the debugger.

The two example commands below start the server for a network and serial connection, respectively:

$ gdbserver {IP_ADDRESS}:{PORT_NUMBER} command-daemon
$ gdbserver {SERIAL_PORT} command-daemon

Common examples for the above parameters are:
SERIAL_PORT=/dev/ttyS0
IP_ADDRESS=192.168.27.32
PORT_NUMBER=2345
Also, it's important to remember that ifdebugging an application from a remote host over the internet, then some form of security is advisable. The book SSH, The Secure Shell: The Definitive Guide (Barrett and Silverman, 2001) explains how to implement SSH port forwarding.

The following example command shows connecting the pwerpc-linux version of gdb host debugger to the started server:

$ powerpc-linux-gdb command-daemon

Hardware debugging options

Debugging kernel code applications, like device drivers, is more difficult than debugging user application code. According to Chapter 16 of Linux Device Drivers (Rubini and Corbet, 2001), Kernel code cannot be easily executed under a debugger, nor can it be easily traced, because it is a set of functionalities not related to a specific process. Kernel code errors can also be exceedingly hard to reproduce and can bring down the entire system, thus destroying much of the evidence that could be used to track them down.
For details on kernel operation see Understanding the Linux Kernel (2000 O'Reilly).

H/W debugging tools can make the difference in detecting low-level board, circuit, pin and kernel signals, and timing problems. Some of the H/W tool options include an oscilloscope, a logic analyzer, an In-Circuit Emulator (ICE), or a BDM, or JTAG debugger. Oscilloscopes are good for monitoring a small number of signals. Logic analyzers can handle monitoring many system memory and I/O bus wires simultaneously, but are much more expensive then logic analyzers. ICE, BDM and JTAG debuggers are custom designed to monitor special signal lines built into boards for kernel diagnostics. .

Chapter 12. Conclusion

The free availability of OSS tools allows software developers, with the correct mix of experience, to create an ES project with very minimal financial investment.  OSS is available without any access restrictions, usually via Internet download. The associated licenses allow developers to modify and redistribute the software without loss of copyrights and patents control for newly developed software.

This report has covered the steps necessary for building an embedded system using free OSS tools. These steps include choosing hosts and target hardware options, setting up the cross-development tools, configuring the kernel, deciding on a filesystem, storage and a boot loader for downloading the target ES application. A simpler but more expensive option is to buy a packaged kernel for a COTS vendor to eliminate several of the steps listed above by using the vendor supplied tools.

Linux is the preferred operating system for ES development and these systems are now found in many everyday gadgets including mobile phones, medical equipment, vehicle navigation systems, automated bank tellers, MP3 players, printers, cars.  Developer's  and companies currently using expensive COTS tools can consider switching to OSS tools to increase profit by decreasing development costs.

Appendix A: Revised Proposal

TS5004 - Building embedded system projects using open source tools

DATE: November 23, 2005

TO: Wendy Waugh, TS5004 professor

FROM: Joe M Schartman

SUBJECT: Topics for capstone and TS5004 projects

Introduction

This proposal will target the following purposes:

Recommend a capstone project strategy

Propose a topic for my TS5004 report

Recommend open source software (OSS) areas to research

Completion of these purposes will enable me to:

Work as a SCalLinuxSystems future projects advisor, consultant or system architect

Develop an embedded application product

Obtain a masters degree and teach embedded system development

The Problem

Currently there exists a plethora of OSS options for building embedded system projects but most designers are not aware of what options exist and how they fit together. Most designers would not consider designing an OSS embedded project because they are not aware that software components are free and available to download. Also, many companies do not understand the different licenses included with current OSS so they often choose to buy expensive commercial products.

Target Audience

Semi-expert audience including:

Experienced system designers
Real-time system programmers
System architects
Chief technology and information officers

Appendix C: Acronyms




Berkeley Software Distribution (BSD)
Central Processing Unit (CPU)

C Compiler (gcc)

C Library (glibc)

Cross-Development Environment (CDE)
DiskOnChip (DOC)
Embedded System (ES)
EMI (Electromagnetic Interference) 
Filesystem Hierarchy Standard (FHS)

Free Software Foundation' (FSF )

GNU's Not Unix (GNU) Note: Not really an acronym rather a recursive algorithm

General Public License (GPL)
Hardware (H/W) 
IEEE1394 (FireWire)
In-Circuit Emulators (ICE)
Industry Standard Architecture (ISA) 
Lesser General Public License (LGPL)
Memory Technology Device (MTD)
Mozilla Public License (MPL)
Open Source Software (OSS) 
Operating System (OS) 
Peripheral Component Interconnect (PCI)
Personal Computer Memory Card International Association (PCMCIA)
PowerPC (PPC) 
RFI (Radio Frequency Interference)
Small Computer Systems Interface (SCSI) 
Software (S/W)
Universal Serial Bus (USB) 
WindRiver Systems (WRS)

References:

Barr M. (1999). Programming Embedded Systems in C and C++, First Ed. CA: O'Reilly

Barrett and Silverman. (2001) . SSH, The Secure Shell: The Definitive Guide, First Ed. CA: O'Reilly

Berger A. (2001).  Embedded Systems Design, First Ed. CA:  CMP Books

Bovet and Cesati. (2000). Understanding the Linux Kernel, First Ed. CA: O'Reilly

Catsoulis J. (2002). Designing Embedded Hardware, First Ed. CA: O'Reilly

Embedded Linux: BlueCat Linux. (n.d.). Retrieved October 03, 2005 from  
     http://www.lynuxworks.com/embedded-linux/embedded-linux.php

Filesystem Hierarchy Standard. (2004). Retrieved November 07, 2005 from 
      http://www.pathname.com/fhs/pub/fhs-2.3.html 

Ganssle J. (1999). The Art of Designing Embedded Systems, First Ed. New York: Newnes

Kirch and Dawson (2000). Linux Network Administrator's Guide, Second Ed. CA: O'Reilly
      also available online retrieved on Noverber  09, 2005,  from  
       http://www.oreilly.com/catalog/linag2/book/

Marti, D. (2005, May 4). Embedded Linux market snapshot, 2005. Retrieved on October  25, 2005,  from 
     http://linuxdevices.com/articles/AT4036830962.html

Raymond E. (2001) . The Cathedral and the Bazaar, First Ed. CA: O'Reilly

Reep, D.C. (2003). Technical Writing Principles, Strategies And Readings. Fifth Ed. New York: Longman

Rubini and Corbet. (2001) . Linux Device Drivers, Second Ed. CA: O'Reilly

Spurgeon C. (2000) . Ethernet: The Definitive Guide, First Ed. CA: O'Reilly

THE OS AT THE HEART OF FUTURE COMBAT SYSTEMS. (n.d.). Retrieved October 03, 2005 from 
     http://www.lynuxworks.com

Welsh, Dallheimer, and Kaufman. (1999). Running Linux, Third Ed. CA: O'Reilly

Yagmour, K. (2003). Building Embedded Linux Systems, First Ed. CA: O'Reilly

Page 27 of 28 Building Embedded Systems using Open Source Software

Table 2 Common Directory Layout

Table 3 Embedded System Filesystem Structure