Subversion Repositories openrisc

rebuilding RedBoot

RedBootrebuilding

RedBoot is built as an application on top of eCos. The makefile rules

for building RedBoot are part of the eCos CDL package, so it's

possible to build eCos from the Configuration

Tool, as well as from the command line using

ecosconfig.

Building RedBoot requires only a few steps: selecting the

platform and the RedBoot template, importing a platform specific

configuration file, and finally starting the build.

The platform specific configuration file makes sure the settings

are correct for building RedBoot on the given platform. Each platform

should provide at least two of these configuration files:

redboot_RAM.ecm for a RAM mode RedBoot

configuration and redboot_ROM.ecm or

redboot_ROMRAM.ecm for a ROM or ROMRAM mode

RedBoot configuration. There may be additional

configuration files according to the requirements of the particular

platform.

The RedBoot build process results in a number of files in the

install bin directory. The ELF

file redboot.elf is the pricipal

result. Depending on the platform CDL, there will also be generated

versions of RedBoot in other file formats, such as

redboot.bin (binary format, good when doing an

update of a primary RedBoot image, see 

linkend="update-primary-image">), redboot.srec

(Motorola S-record format, good when downloading a RAM mode image for

execution), and redboot.img (stripped ELF format,

good when downloading a RAM mode image for execution, smaller than the

.srec file). Some platforms may provide additional file formats and

also relocate some of these files to a

particular address making them more suitable for downloading using a

different boot monitor or flash programming tools.

The platform specific information in 

linkend="Installation-and-Testing"> should be consulted, as there may

be other special instructions required to build RedBoot for particular

platforms.

To rebuild RedBoot using the

ecosconfig tool, create a temporary

directory for building RedBoot, name it according to the desired

configuration of RedBoot, here RAM:

$ mkdir /tmp/redboot_RAM

$ cd /tmp/redboot_RAM

Create the build tree according to the chosen platform, here

using the Hitachi Solution Engine 7751 board as

an example:

It is assumed that the environment variable

ECOS_REPOSITORY points to the eCos/RedBoot source tree.

$ ecosconfig new se7751 redboot

U CYGPKG_HAL_SH_7750, new inferred value 0

U CYGPKG_HAL_SH_7751, new inferred value 1

U CYGHWR_HAL_SH_IRQ_USE_IRQLVL, new inferred value 1

U CYGSEM_HAL_USE_ROM_MONITOR, new inferred value 0

U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM, new inferred value 0

U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1

U CYGFUN_LIBC_STRING_BSD_FUNCS, new inferred value 0

U CYGPKG_NS_DNS_BUILD, new inferred value 0

Replace the platform name ("se7751") with the appropriate name for the

chosen platform.

Then import the appropriate platform RedBoot configuration file,

here for RAM configuration:

$ ecosconfig import ${ECOS_REPOSITORY}/hal/sh/se7751/VERSION/misc/redboot_RAM.ecm

$ ecosconfig tree

Replace architecture ("sh"), platform ("se7751") and version

("VERSION") with those appropriate for the

chosen platform and the version number of its HAL package. Also

replace the configuration name ("redboot_RAM.ecm") with that of the

appropriate configuration file.

RedBoot can now be built:

$ make

The resulting RedBoot files will be in the associated

install directory, in this example, 

class="directory">./install/bin.

In  each platform's

details are described in the form of shell variables. Using those,

the steps to build RedBoot are:

export REDBOOT_CFG=redboot_ROM

export VERSION=VERSION

mkdir /tmp/${REDBOOT_CFG}

cd /tmp/${REDBOOT_CFG}

ecosconfig new ${TARGET} redboot

ecosconfig import ${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm

ecosconfig tree

make

To build for another configuration, simply change the

REDBOOT_CFG definition accordingly. Also

make sure the VERSION variable matches the

version of the platform package.

To rebuild RedBoot from the Configuration

Tool, open the template window (Build->Templates) and

select the appropriate Hardware target and in Packages select

"redboot". Then press OK. Depending on the platform, a number of

conflicts may need to be resolved before the build can be started;

select "Continue".

Import the desired RedBoot configuration file from the platform HAL

(File->Import...).  Depending on the platform, a number of

conflicts may need to be resolved before the build can be started;

select "Continue". For example, if the platform selected is Hitachi

SE7751 board and the RAM configuration RedBoot should be built, import

the file

hal/sh/se7751/VERSION/misc/redboot_RAM.ecm.

Save the configuration somewhere suitable with enough disk space

for building RedBoot (File->Save...). Choose the name according to

the RedBoot configuration, for example

redboot_RAM.ecc.

Then start the build (Build->Library) and wait for it to

complete. The resulting RedBoot files will be in the associated

install directory, for the example this would be 

class="directory">redboot_RAM_install/bin.

As noted above, each platform's details are described in 

linkend="Installation-and-Testing">. Use the information provided in

the shell variables to find the configuration file - the path to it is

${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm,

where ECOS_REPOSITORY points to the

eCos/RedBoot sources, VERSION is the

version of the package (usually "current") and

REDBOOT_CFG is the desired configuration,

e.g. redboot_RAM.

updating

RedBoot

RedBootupdatingRedBoot

normally resides in an EPROM or, more common these days, a flash

on the board. In the former case, updating RedBoot necessitates

physically removing the part and

reprogramming a new RedBoot image into it using prommer hardware. In

the latter case, it is often possible to update RedBoot in situ using

Redboot's flash management commands.

The process of updating RedBoot in situ is documented in this

section. For this process, it is assumed that the target is connected

to a host system and that there is a serial connection giving access

to the RedBoot CLI. For platforms with a ROMRAM mode RedBoot, skip to

.

The addresses and sizes included in the below are examples

only, and will differ from those you will see. This is normal and

should not cause concern.

There are a number of choices here. The basic case is where a RAM

mode image has been stored in the FIS (flash Image System). To load and

execute this image, use the commands: 

RedBoot> fis load RedBoot[RAM]

RedBoot> go

If this image is not available, or does not work,

then an alternate RAM mode image must be loaded:

RedBoot> load redboot_RAM.img

Entry point: 0x060213c0, address range: 0x06020000-0x060369c8

RedBoot> go

This command loads the RedBoot image using the TFTP

protocol via a network connection. Other methods of loading are

available, refer to the 

linkend="download-command">load command for more

details. 

If you expect to be doing this more than once, it is a

good idea to program the RAM mode image into the flash. You do this

using the fis create command after having

downloaded the RAM mode image, but before you start it.

Some platforms support locking (write protecting) certain regions of

the flash, while others do not. If your platform does not support

locking, simply ignore the fis unlock and

fis lock steps (the commands will not be

recognized by RedBoot).

RedBoot> fis unlock RedBoot[RAM]

  ... Unlock from 0x00000000-0x00020000: ..

RedBoot> fis create RedBoot[RAM]

An image named 'RedBoot[RAM]' exists - continue (y/n)? y

* CAUTION * about to program 'RedBoot[RAM]'

            at 0x00020000..0x000369c7 from 0x06020000 - continue (y/n)?y

... Erase from 0x00020000-0x00040000: ..

... Program from 0x06020000-0x060369c8 at 0x00020000: ..

... Erase from 0x00070000-0x00080000: .

... Program from 0x0606f000-0x0607f000 at 0x00070000: .

RedBoot> fis lock RedBoot[RAM]

  ... Lock from 0x00000000-0x00020000: ..

 An

instance of RedBoot should now be running on the target from RAM. This

can be verified by looking for the mode identifier in the banner. It

should be either [RAM] or [ROMRAM].

If this is the first time RedBoot is running on the board or if

the flash contents has been damaged, initialize the FIS directory:

RedBoot> fis init -f

About to initialize [format] FLASH image system - continue (y/n)? y

*** Initialize FLASH Image System

... Erase from 0x00020000-0x00070000: .....

... Erase from 0x00080000-0x00080000:

... Erase from 0x00070000-0x00080000: .

... Program from 0x0606f000-0x0607f000 at 0x00070000: .

It is important to understand that the presence of a correctly

initialized FIS directory allows RedBoot to automatically determine

the flash parameters. Additionally, executing the steps below as

stated without loading other data or using other flash commands (than

possibly fis list) allows RedBoot to automatically

determine the image location and size parameters. This greatly reduces

the risk of potential critical mistakes due to typographical errors. It is

still always possible to explicitly specify parameters, and indeed

override these, but it is not advised.

If the new RedBoot image has grown beyond the slot in

flash reserved for it, it is necessary to change the RedBoot

configuration option CYGBLD_REDBOOT_MIN_IMAGE_SIZE so the FIS is

created with adequate space reserved for RedBoot images. In this case,

it is necessary to re-initialize the FIS directory as described above,

using a RAM mode RedBoot compiled with the updated

configuration.

Using the load command, download the

new flash based image from the host, relocating the image to RAM::

RedBoot> load -r -b %{FREEMEMLO} redboot_ROM.bin

Raw file loaded 0x06046800-0x06062fe8, assumed entry at 0x06046800

This command loads the RedBoot image using the TFTP

protocol via a network connection. Other methods of loading are

available, refer to the  command for

more details. 

Note that the binary version of the image is being

downloaded. This is to ensure that the memory after the image is

loaded should match the contents of the file on the host. Loading SREC

or ELF versions of the image does not guarantee this since these

formats may contain holes, leaving bytes in these holes in an unknown

state after the load, and thus causing a likely cksum difference. It

is possible to use these, but then the step verifying the cksum below

may fail.

Once the image is loaded into RAM, it should be checksummed,

thus verifying that the image on the target is indeed the image

intended to be loaded, and that no corruption of the image has

happened. This is done using the 

command:

RedBoot> cksum

Computing cksum for area 0x06046800-0x06062fe8

POSIX cksum = 2535322412 116712 (0x971df32c 0x0001c7e8)

Compare the numbers with those for the binary version of the image on

the host. If they do not match, try downloading the image again.

Assuming the cksum matches, the next step is programming the

image 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 locking, simply ignore the fis unlock and

fis lock steps (the commands will not be recognized

by RedBoot).

RedBoot> fis unlock RedBoot

  ... Unlock from 0x00000000-0x00020000: ..

RedBoot> fis create RedBoot

An image named 'RedBoot' exists - continue (y/n)? y

* CAUTION * about to program 'RedBoot'

            at 0x00000000..0x0001c7e7 from 0x06046800 - continue (y/n)? y

... Erase from 0x00000000-0x00020000: ..

... Program from 0x06046800-0x06062fe8 at 0x00000000: ..

... Erase from 0x00070000-0x00080000: .

... Program from 0x0606f000-0x0607f000 at 0x00070000: .

RedBoot> fis lock RedBoot

  ... Lock from 0x00000000-0x00020000: ..

Once the image has been successfully written into the flash, simply

reset the target and the new version of RedBoot should 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 command. See 

linkend="Persistent-State-Flash">.