RedBoot™ User's Guide: Document Version 2.04, February 2007
PrevNext

Chapter 4. Updating RedBoot

Introduction

RedBoot normally runs from flash or ROM (in both cases, it is termed a ROM-startup configuration of RedBoot). In the case of flash, it is possible to update RedBoot, that is, replace it with a newer version, in situ. This process is complicated by the fact that RedBoot is running from the very flash which is being updated. The following is an outline of the steps needed for updating RedBoot:

In order to execute this process, two versions of RedBoot are required; one which runs from flash, and a separate one which runs solely from RAM. Both of these images are typically provided as part of the RedBoot package, but they may also be rebuilt from source using the instructions provided for the platform.

On some platforms, RedBoot runs in a ROMRAM-startup configuration: RedBoot is stored in the flash or ROM, but when the board is reset, it is copied to RAM and executes from there. For these platforms where RedBoot is in flash, the update in-situ process is simplified since the ROMRAM-startup configuration of RedBoot can update the flash content. The update procedure becomes:

In order to execute this process, only one version of RedBoot is required; a ROMRAM-startup configuration. This image is typically provided as part of the RedBoot package, but it may also be rebuilt from source using the instructions provided for the platform.

The following is a more detailed look at these steps. For this process, it is assumed that the target is connected to a host system and that there is some sort of serial connection used for the RedBoot CLI. For platforms with a ROMRAM-startup configuration of RedBoot, skip to the Section called Update the primary RedBoot flash image.

Start RedBoot, Running from flash

To start RedBoot, reset the platform.

Load and start a different version of RedBoot, running from RAM

There are a number of choices here. The basic case is where the RAM based version has been stored in the FIS (flash Image System). To load and execute this version, use the commands: 

RedBoot> fis load RedBoot[backup]
RedBoot> go
If this image is not available, or does not work, then an alternate RAM based image must be loaded. Using the load command: 
RedBoot> load redboot_RAM.srec
RedBoot> go

NOTE: The details of how to load are installation specific. The file must be placed somewhere the host computer can provide it to the target RedBoot system. Either TFTP (shown) or X/Ymodem can be used to download the image into RAM.

Once the image is loaded into RAM, it may be used to update the secondary RedBoot image in flash using the FIS commands. Some platforms support locking (write protecting) certain regions of the flash, while others do not. If your platform does not support the lock/unlock commands, simply ignore these steps. Again, the details of these commands (in particular the numeric values) differ on each target platform, but the ideas are the same: 
RedBoot> fis unlock -f <flash addr> -l <flash length>
RedBoot> fis create RedBoot[backup] -f <flash addr> -b <flash source>
         -r <image addr> -l <flash length>
RedBoot> fis lock -f <flash addr> -l <flash length>

Update the primary RedBoot flash image

At this point, a version of RedBoot is running on the target, in RAM.

Using the load command, download the new flash based version from the host.

Since the flash version is designed to load and run from flash, the image must be relocated into some suitable, available, RAM location. The details of this are target platform specific (found in the target appendix), but the command will look something like this: 

RedBoot> load redboot_ROM.srec -b <flash source>
This command loads the flash image into RAM at flash_source, using the TFTP protocol via a network connection. Other options are available, refer to the command section on load for more details.

Once the image is loaded into RAM, it must be placed into flash using the FIS commands. Some platforms support locking (write protecting) certain regions of the flash, while others do not. If your platform does not support the lock/unlock commands, simply ignore these steps. Again, the details of these commands (in particular the numeric values) differ on each target platform, but the ideas are the same: 

RedBoot> fis unlock -f <flash addr> -l <flash length>
RedBoot> fis create RedBoot -f <flash addr> -b <flash source> -l <flash length>
         -s <data length>  
RedBoot> fis lock -f <flash addr> -l <flash addr>

NOTE: RedBoot will display a number of lines of information as it executes these commands. Also, the size (-s) value for the create operation should be determined from the output provided as part of the file download step.

It is not required, but it does allow for improved image validity checking in the form of an image checksum.

NOTE: After the flash image directory has been initialized with the fis init command it is possible to use a shorthand version of the fis create command since it can get the necessary information from the flash image directory: 

RedBoot> fis create RedBoot -b <flash source>

Reboot; run RedBoot from flash

Once the image has been successfully written into the flash, simply reboot the target and the new version of RedBoot will be running.

When installing RedBoot for the first time, or after updating to a newer RedBoot with different configuration keys, it is necessary to update the configuration directory in the flash using the fconfig -i command.

NOTE: There may be times when RedBoot does not exist on the hardware, thus making step 1 impossible to do. In these cases, it should be possible to get to step 2 by using GDB. If this is possible, the appropriate steps are provided with the target documentation.

PrevHomeNext
Rebuilding RedBoot Installation and Testing