Figure 2: Configuration Tool showing RedBoot configuration options

Figure 2 is a snapshot of the RedBoot configuration options that are shown in the Configuration Tool. The Configuration Tool offers an easy method for graphically configuring the necessary components that are built into the RedBoot image.

Configuration options are enabled or disabled by checking or unchecking the selection boxes for a particular component. The values for a configuration can be set on the right side pane in the configuration window.

There are two methods to create a new RedBoot configuration. The first method is to select Templates under the Build menu item in the Configuration Tool. This brings up the Templates dialog box, which allows the selection of the hardware platform and template packages. In this case the template package to select is redboot. This method gives a basic set-up for building the RedBoot image with all default configuration options. Additional packages can be added or removed using the Packages dialog box, which is launched by selecting Build—>Packages from the menu.

The second method to create a new RedBoot configuration is to import an eCos minimal configuration (.ecm) file. Minimal configuration files are included for each hardware platform supported by RedBoot. These configuration files are typically located under the misc subdirectory for each architecture under the Hardware Abstraction Layer directory, hal.

Minimal configuration files contain the basic configuration information for a particular hardware platform. By using the .ecm file as a starting point, we have a working configuration for the hardware platform that we are using as a baseline. The configuration options can then be modified to support any changes needed in the RedBoot image.

Listing 3: Example eCos minimal configuration (.ecm) file

cdl_savefile_version 1;
cdl_savefile_command cdl_savefile_version {};
cdl_savefile_command cdl_savefile_command {};

cdl_configuration eCos {
description "" ;
hardware mbx ;
template redboot ;
package -hardware CYGPKG_HAL_POWERPC current ;
package -hardware CYGPKG_HAL_POWERPC_MPC8xx current ;
package -hardware CYGPKG_HAL_POWERPC_MBX current ;
} ;

cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
inferred_value 1
} ;

cdl_option CYGSEM_HAL_ROM_MONITOR {
inferred_value 1
} ;

Minimal configuration files also use the CDL. Listing 3 is from the redboot_ROM.ecm file for the PowerPC-based Motorola MBX development board. As you can see, the .ecm file shows a list of the packages, under the cdl_configuration command, that need to be included for the RedBoot configuration. The cdl_option commands set the configuration option values for specific options.

Most supported platforms contain a ROM and RAM RedBoot .ecm file that can be imported as the configuration starting point. ROM and RAM indicate where the RedBoot image resides on the target hardware. Typically, the RAM configuration is initially used when debugging hardware and the ROM configuration is used when the image has been debugged and is ready to be placed in flash memory. The RAM image is also used to update the flash-resident RedBoot image. The i386 PC target platform also includes a RedBoot FLOPPY configuration file that can be used if booting RedBoot from a floppy drive.

In order to import a minimal configuration file, we select File->Import from the menu in the Configuration Tool. Then we browse to the appropriate .ecm file and select it. The Configuration Tool uses the .ecm file to load the appropriate packages and set the options accordingly. If conflicts arise due to the configuration option settings, the Configuration Tool displays a conflict resolution dialog box. The conflicts can be resolved by selecting the continue button.

Since RedBoot relies on other software modules, such as the HAL, not all of the configuration options are located under the RedBoot ROM Monitor package. The low-level hardware configuration options are found under the eCos HAL package. Other packages that may need configuration are device drivers. For example, on platforms that include networking support, the Ethernet device driver options are located under the Common Ethernet Support package.

If network communication is desired, the RedBoot Networking configuration options need to be set up. This sets the default IP address for the target hardware or configures that BOOTP is used during initialization.

After completing the RedBoot configuration, it is a good idea to save a minimal configuration file. This is accomplished by selecting File->Export and saving the configuration under the desired filename.

Building the RedBoot image

Next, we need to save the current configuration. To save the current configuration, into an eCos current configuration file (.ecc), we go to Save As under the File menu bar item. We can save the file as redboot_rom.ecc. This creates a working directory structure for the RedBoot image we are creating. All directories begin with the name of the .ecc file we created. In our case, the directories begin with redboot. The working directory structure is shown in Table 2.

Table 2: RedBoot working directory structure
Directory	Description
redboot_build	Contains all files created during the RedBoot build process.
redboot_install	Output files generated from the build process are located under this directory.
redboot_install\bin	This directory contains the different RedBoot image files. The types of files generated can vary depending on the processor architecture. The file format types may include binary, ELF, and S-record.
redboot_install\include	Contains the header files for the RedBoot image build
redboot_install\lib	Includes the library files generated for the RedBoot image build and the linker script files.
redboot_mlt	Contains the memory layout files used by the Configuration Tool.

Now that we have the configuration set up correctly, we can build the RedBoot image. To launch the build process, we select Build->Library. The build information is displayed in the output window of the Configuration Tool.

When the build is complete, the RedBoot images are stored in the redboot_install\bin subdirectory, as described in Table 2. For our example, the new RedBoot image is called redboot_rom.bin.

Updating the target

The method used to install the RedBoot image into non-volatile storage varies by target. In general, the image must be programmed into flash using software or ROM using a device programmer.

Once a RedBoot image is resident in the flash memory, the task of updating that image, for bug fixes or additional features, is straightforward. The existing flash RedBoot image and a RedBoot image built to run from RAM are needed.

First we boot the target and run the outdated RedBoot image from flash memory. Since we use the Flash Image System commands to program the new RedBoot image into flash memory, we need to initialize the fis system by running the command:

RedBoot> fis init

This will initialize the flash memory and enable new images to be downloaded using the fis commands. After initializing the image system, we can see the images in flash memory by running the command:

RedBoot> fis list

Listing 4: Example output from fis list command

Name	flash addr	Mem addr	Length	Entry point
RedBoot	0xA0000000	0xA0000000	0x020000	0x80000000
RedBoot[backup]	0xA0020000	0x8C010000	0x010000	0x8C010000
RedBoot config	0xA0FC0000	0xA0FC0000	0x020000	v0x00000000
FIS directory	0xA0FE0000	0xA0FE0000	0x020000	0x00000000

Output similar to that shown in Listing 4 is displayed. The addresses, lengths, and entry points may differ depending on the hardware platform you are using. We can see the RedBoot image name, which indicates the RedBoot image currently executing in flash memory.

Next, a RedBoot RAM image, redboot_ram.bin, is created using the steps detailed above. To build an image that runs from RAM, we want to ensure the Startup Type (CYG_HAL_STARTUP) configuration option is set to RAM. Since hardware platforms include a ROM and RAM minimal configuration file, it's not difficult to import and build the RAM configuration. It is important to remember to save the RAM and ROM images to separate working directories.

We load the redboot_ram.bin image into RAM using the outdated RedBoot image residing in flash memory. This is accomplished using the following command:

RedBoot> load redboot_ram.bin

The load command offers various methods, such as TFTP, for transmitting the image from the host computer to the target hardware. The method depends on the resources you have available. The fis load command can also be used to load and store the redboot_ram.bin image using the Flash Image Storage system.

We execute the RedBoot image we just loaded into RAM using:

RedBoot> go

This produces a new initialization message, similar to the one shown in Listing 1, after the RedBoot image executes from RAM. At this point we are executing the RedBoot image from RAM.

Next, we want to load the RedBoot image we created for ROM from the steps above. To load the redboot_rom.bin image we use the command:

RedBoot> load redboot_rom.bin 
-b <ram_addr>

where ram_addr is the location in RAM, which varies from platform to platform, where we temporarily store the redboot_rom.bin image before programming it into flash.

Now we can program the new image into flash memory using the fis commands. Certain platforms may support locking and unlocking of flash memory. If we can unlock the flash, the first fis command that we need to enter is:

RedBoot>  fis unlock <flash_addr> 
-l <flash_len>

where flash_addr is the address of flash memory we want to unlock. In our case, this corresponds to the flash address of the RedBoot image name from the fis list command. We also get the length for flash_len from the fis list command. If the platform does not support flash locking, we can skip this step.

Next, we program the new RedBoot image from RAM into flash memory using the command:

RedBoot> fis create RedBoot 
-f <flash_addr> -b <ram_addr>
-l <flash_len> -s <data_len>

where flash_addr is the location in flash memory where the new RedBoot image will be programmed, as shown in the fis list command. ram_addr is the location where we loaded the redboot_rom.bin file into RAM memory. The flash_len, also shown in the fis list command, is the length of the RedBoot flash image. data_len is the length of the redboot_rom.bin file to be programmed into flash memory.

Before proceeding, the fis create command asks if you would like to replace the existing image named RedBoot. Replying y causes the new image to be programmed into flash memory. Next, the flash can be locked, if the hardware platform permits it, using the following command:

RedBoot> fis lock -f <flash_addr> 
-l <flash_len>

The actual memory locations described above for the platforms supported are detailed in the RedBoot documentation.

Finally, reboot the target hardware to begin using the new RedBoot image we just programmed into flash memory.

Porting RedBoot

Since RedBoot uses the eCos HAL for its low level interface to the hardware, the procedure for porting RedBoot to a new hardware platform is the same as that for porting eCos. The procedure for porting eCos was covered in my previous article called "eCos Porting Guide" (January 2002, p. 34). The procedures detailed in that article apply directly to the porting of RedBoot to new hardware platforms.

Futurespeak

As of the writing of this article a new release of RedBoot is planned to coincide with the upcoming v. 2 release of eCos. Planned RedBoot enhancements include a DHCP client, an embedded web server, USB debugging, and IDE drive support.

Even without these improvements, the RedBoot ROM monitor provides a low-cost, easy to use method for debugging and testing hardware. And because RedBoot is open source, it can be customized to meet any specific need during the project development and test phases. The support for GDB might even eliminate your need for expensive hardware debugging tools.

Anthony J. Massa is a senior software engineer. He holds a BS in electrical engineering and has been developing embedded software since 1994. This article was adapted from his upcoming book Embedded Development with eCos, which will be published by Prentice Hall this fall. Contact him at amassa@san.rr.com.

Endnotes

1. sources.redhat.com/ecos/license.html
Back

2. A formal list of supported processors is maintained online at sources.redhat.com/ecos/hardware.html
Back

3. sources.redhat.com/ecos/docs-latest/cdl/cdl-guide.html
Back

4. sources.redhat.com/ecos/ct2.html
Back

5. sources.redhat.com/ecos/anoncvs.html
Back

Resources

RedBoot home: sources.redhat.com/redboot

Documentation: sources.redhat.com/ecos/docs-latest

Mailing List: sources.redhat.com/ml/ecos-discuss

Return to the August 2002 Table of Contents