Many embedded developers today use a ROM- or flash-resident software program that provides functionality such as loading and running application software, scripting, read/write access to processor registers, and memory dumps. A ROM monitor, as it is often called, can be a useful and far less expensive debugging tool than an in-circuit emulator.

This article describes the RedBoot ROM monitor. We'll take a look at the features offered by the RedBoot ROM monitor and see how it can be configured. We'll also walk through the steps of rebuilding and installing a new RedBoot image on a target platform. Finally, we'll look at future enhancements that are coming in new releases and how to get support and additional information when using RedBoot.

Although RedBoot uses software modules from the eCos real-time operating system (RTOS) and is often used in systems running embedded Linux, it is completely independent of both operating systems. RedBoot can be used with any operating system or RTOS-or even without one.

About RedBoot

RedBoot, which is also called Red Hat's Embedded Debug and Bootstrap Program, is a standalone open source bootstrap/loader designed for use in embedded systems. The RedBoot source code is available for download and is currently covered by the Red Hat eCos Public License.^[1]

RedBoot includes a GDB "stub," which provides the target side communication software to allow remote debugging via standard GDB protocol commands. This allows you to use RedBoot and a host running the GNU debugger to debug your embedded applications over a serial port or network connection. For more information about using GDB in this way, read Bill Gatliff's "Embedding with GNU: GNU Debugger" (September 1999, p. 80).

RedBoot supports a wide range of processor architectures and hardware platforms. The list of supported architectures includes ARM, Hitachi SHx, MIPS, PowerPC, SPARC, x86, and many others.^[2]

Configuration

RedBoot can be run in many different configurations. However, it is typically run from the target platform's flash boot sector or boot ROM. RedBoot is designed to start when the system is powered on, providing enough processor initialization and device configuration to allow you to communicate with the system from that point forward.

RedBoot can be configured to use either a serial port or Ethernet port (via telnet) for communication. Once the first command is received from one of the enabled ports, all RedBoot communications are conducted over that port until the system is reset.

When using the Ethernet port to communicate with RedBoot, it is important to understand how the target will obtain its IP address. There are two methods for configuring the target IP address: static and dynamic. In the static scenario, the IP address for the target is set before the RedBoot image is compiled, as described in a later section of this article, or via command over the serial port.

To assign an IP address dynamically, RedBoot uses the BOOTP protocol, which is a subset of the Dynamic Host Configuration Protocol (DHCP) widely supported on many networks these days. Enabling the target to use dynamic network configuration can also be done at compile time or over the serial port. Of course, in order to get an IP address, the device must be on a network that has an accessible BOOTP or DHCP server.

It is important not to use a dynamic IP address for the RedBoot image if the application software it will load needs an IP address of its own. Otherwise, conflicts may occur in the configuration of the Ethernet port's IP address, causing communication problems with RedBoot, the application software, or both. In this case, it is best to set a static IP address for RedBoot that is outside the range for the dynamic network configuration protocol.

RedBoot is also capable of using the Trivial File Transfer Protocol (TFTP) to download application code automatically, based on the configuration information received with the BOOTP response. In this case, a TFTP server is also needed on the host to provide access to the software images.

Command line

RedBoot provides a command line interface (CLI) for entering commands. At a minimum, the RedBoot CLI is available on the target hardware serial port. If multiple serial ports exist, RedBoot may use any of them for communication. Alternatively, the RedBoot CLI may use the Ethernet port, via the telnet protocol. (By default, RedBoot uses port 9000 for telnet; however, this can be changed using the fconfig command described later.)

Listing 1: RedBoot initialization message

FLASH: 0xfe000000-0xfe080000, 8 blocks of 0x00010000 bytes each.
IP: 192.168.0.100, Default server: 192.168.0.3

RedBoot (tm) bootstrap and debug environment - built 17:55:12, Apr 21 2001

Platform: Motorola MBX (PowerPC 860)
Copyright (C) 2000, 2001, Red Hat, Inc.

RAM:0x00000000-0x00400000, 0x00022420-0x003e0000 available
RedBoot>

The RedBoot initialization message, which is output by the CLI, is shown in Listing 1. This message gives information about the RedBoot image such as the image build date, the target hardware platform, and the resources available for RedBoot to use. When the RedBoot> prompt is shown, the CLI is ready for command input from the user.

The basic form of a RedBoot command is:

COMMAND [-OPTION1]
[-OPTION2 VALUE] OPERAND

where OPTION1 and OPTION2 are optional switches for specific actions or additional information that can be added to certain commands. In the case of OPTION2, a value is also included with the switch. OPERAND specifies additional information needed for particular commands.

Commands may be abbreviated to their shortest unique string. For example, dump, dum, du, and d are all valid command inputs for the dump command.

RedBoot downloads application software images using the load command. Images can be downloaded using the TFTP protocol, the X/Y modem protocol, or directly from target hardware resources. After an image is downloaded to the target hardware, the software can be executed using the go command.

A full list of the available commands can be displayed by typing help at the RedBoot prompt. Not all commands are available for all RedBoot images. The available commands depend on the resources provided by the target. For example, some commands may be excluded for hardware platforms that do not have flash memory.

The GDB stub is invoked in the RedBoot image when the "$" character appears as the first character of a command. Once entered, RedBoot remains in GDB mode until the system is restarted.

RedBoot offers several commands worth noting. The first are the Flash Image System (fis) commands. If flash memory is provided on the hardware platform, RedBoot provides the fis commands as a basic file system. These commands are used to manipulate the images in the file system.

Listing 2: Querying RedBoot configuration using the fconfig command

RedBoot> fconfig -l
Run script at boot: false
Use BOOTP for network configuration: false
Local IP address: 192.168.1.6
Default server IP address: 192.168.1.12
GDB connection port: 9000
Network debug at boot time: false

Another useful command is the flash-based configuration and control command, fconfig. Example output from a query of the fconfig command can be found in Listing 2. As you can see from this listing, the configuration can be set for the RedBoot startup sequence. The startup configuration includes whether a boot script should be run at initialization time, whether the BOOTP protocol should be used to obtain an IP address, and the GDB telnet port to use for debugging.

RedBoot also supports boot scripting. This allows you to run commands that you want executed after the power up cycle. Boot scripting can be very helpful when using RedBoot to load a software application image during the product test phase. A timeout can be set to allow you to abort the boot script, by pressing Ctrl+C, before it executes. Boot scripts are setup using the fconfig command.

Building RedBoot

It is important to be able to rebuild the RedBoot image yourself, since there may be code updates and bug fixes that you want to use. You'll also need to rebuild RedBoot if you want to customize it, such as by adding your own commands or porting it.

The first step in rebuilding the RedBoot image is to set up the host development environment. The tools needed to build the RedBoot image can be run on a Windows or Linux host platform. The host development tools include the GNU binary utilities (commonly called binutils), the C/C++ compiler, and the debugger.

Detailed steps for building the GNU development tools and setting up the host development environment, based on the target processor architecture and host operating system platform, can be found online at sources.redhat.com/ecos/getstart.html.

After the GNU tools are installed, the next step is to get the configuration tools. You can configure and build the RedBoot image using either the graphical Configuration Tool or a command line tool. In this article we will focus on using the graphical Configuration Tool.

The Configuration Tool allows source-level configuration, which ensures a RedBoot image that is specific for each user's application. The entire source code repository and the Configuration Tool rely on the Component Definition Language (CDL) to describe the components in the repository and rules for building the software images.^[3]

The Configuration Tool uses the previously set up GNU tools to build the RedBoot image for a specific processor architecture. Additional information about the Configuration Tool can be found online, as well as under the help menu of the Configuration Tool.^[4]

For the examples below I used configtool-2.08-setup.exe, which was the latest release of the Configuration Tool as of the writing of this article. It is a good idea to read the readme.txt file before proceeding with the installation of the Configuration Tool. The file changes.txt, also within the download, lists the modifications to the Configuration Tool executable for different releases.

Next, we need to download the RedBoot source code. The RedBoot source code is contained in the anonymous CVS repository, which can be accessed using free client software. Detailed information is available online.^[5]

It is a good idea to get all of the source code, including the eCos files, when connected to the repository. RedBoot uses some of the eCos source files, such as device drivers. After you are certain which files are needed to build your RedBoot image, you can remove the others.

An overview block diagram detailing some of the main software modules in the RedBoot software architecture is shown in Figure 1.

Figure 1: RedBoot software architecture

RedBoot uses a layered approach in its software architecture. The RedBoot architecture was designed to accomodate new functionality and software components. The foundation of RedBoot relies on eCos' Hardware Abstraction Layer (HAL) and device drivers.

Let's take a look at the RedBoot source code directory structure. After downloading the source files from the anonymous CVS repository, the source code files are contained under the packages subdirectory. Under this main directory is the redboot subdirectory where all of the RedBoot files reside. Since the files were downloaded from the anonymous CVS repository, they are all located under the current revision subdirectory.

There is a file called ChangeLog, located under the redboot subdirectory that keeps a list of all changes to the RedBoot source files. Table 1 lists and describes the RedBoot source code directories.

Table 1: RedBoot source code directory structure
Directory	Description
cdl	Contains the CDL script file that details the RedBoot package configuration and build information. The Configuration Tool uses the CDL files to understand the RedBoot source code.
include	Directory for the header files necessary to build the RedBoot image.
include\fs	Header files for the RedBoot file system.
include\net	Header files for the RedBoot networking support.
misc	Contains the eCos Minimal Configuration (.ecm) file used to import a baseline configuration into the Configuration Tool.
src	Includes the main source files for RedBoot such as the RedBoot startup, flash memory support, the I/O communication, and command line parser files.
src\fs	Source files for RedBoot file system support.
src\net	Source files for RedBoot networking support, including the BOOTP and TFTP source code files.