|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rebuilding RedBoot
|
Rebuilding RedBoot
|
|
|
Introduction
|
Introduction
|
rebuilding RedBoot
|
rebuilding RedBoot
|
RedBootrebuilding
|
RedBootrebuilding
|
RedBoot is built as an application on top of eCos. The makefile rules
|
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
|
for building RedBoot are part of the eCos CDL package, so it's
|
possible to build eCos from the Configuration
|
possible to build eCos from the Configuration
|
Tool, as well as from the command line using
|
Tool, as well as from the command line using
|
ecosconfig.
|
ecosconfig.
|
|
|
Building RedBoot requires only a few steps: selecting the
|
Building RedBoot requires only a few steps: selecting the
|
platform and the RedBoot template, importing a platform specific
|
platform and the RedBoot template, importing a platform specific
|
configuration file, and finally starting the build.
|
configuration file, and finally starting the build.
|
|
|
The platform specific configuration file makes sure the settings
|
The platform specific configuration file makes sure the settings
|
are correct for building RedBoot on the given platform. Each platform
|
are correct for building RedBoot on the given platform. Each platform
|
should provide at least two of these configuration files:
|
should provide at least two of these configuration files:
|
redboot_RAM.ecm for a RAM mode RedBoot
|
redboot_RAM.ecm for a RAM mode RedBoot
|
configuration and redboot_ROM.ecm or
|
configuration and redboot_ROM.ecm or
|
redboot_ROMRAM.ecm for a ROM or ROMRAM mode
|
redboot_ROMRAM.ecm for a ROM or ROMRAM mode
|
RedBoot configuration. There may be additional
|
RedBoot configuration. There may be additional
|
configuration files according to the requirements of the particular
|
configuration files according to the requirements of the particular
|
platform.
|
platform.
|
|
|
The RedBoot build process results in a number of files in the
|
The RedBoot build process results in a number of files in the
|
install bin directory. The ELF
|
install bin directory. The ELF
|
file redboot.elf is the pricipal
|
file redboot.elf is the pricipal
|
result. Depending on the platform CDL, there will also be generated
|
result. Depending on the platform CDL, there will also be generated
|
versions of RedBoot in other file formats, such as
|
versions of RedBoot in other file formats, such as
|
redboot.bin (binary format, good when doing an
|
redboot.bin (binary format, good when doing an
|
update of a primary RedBoot image, see
|
update of a primary RedBoot image, see
|
linkend="update-primary-image">), redboot.srec
|
linkend="update-primary-image">), redboot.srec
|
(Motorola S-record format, good when downloading a RAM mode image for
|
(Motorola S-record format, good when downloading a RAM mode image for
|
execution), and redboot.img (stripped ELF format,
|
execution), and redboot.img (stripped ELF format,
|
good when downloading a RAM mode image for execution, smaller than the
|
good when downloading a RAM mode image for execution, smaller than the
|
.srec file). Some platforms may provide additional file formats and
|
.srec file). Some platforms may provide additional file formats and
|
also relocate some of these files to a
|
also relocate some of these files to a
|
particular address making them more suitable for downloading using a
|
particular address making them more suitable for downloading using a
|
different boot monitor or flash programming tools.
|
different boot monitor or flash programming tools.
|
|
|
The platform specific information in
|
The platform specific information in
|
linkend="Installation-and-Testing"> should be consulted, as there may
|
linkend="Installation-and-Testing"> should be consulted, as there may
|
be other special instructions required to build RedBoot for particular
|
be other special instructions required to build RedBoot for particular
|
platforms.
|
platforms.
|
|
|
|
|
Rebuilding RedBoot using <application>ecosconfig</application>
|
Rebuilding RedBoot using <application>ecosconfig</application>
|
|
|
To rebuild RedBoot using the
|
To rebuild RedBoot using the
|
ecosconfig tool, create a temporary
|
ecosconfig tool, create a temporary
|
directory for building RedBoot, name it according to the desired
|
directory for building RedBoot, name it according to the desired
|
configuration of RedBoot, here RAM:
|
configuration of RedBoot, here RAM:
|
|
|
$ mkdir /tmp/redboot_RAM
|
$ mkdir /tmp/redboot_RAM
|
$ cd /tmp/redboot_RAM
|
$ cd /tmp/redboot_RAM
|
|
|
|
|
|
|
Create the build tree according to the chosen platform, here
|
Create the build tree according to the chosen platform, here
|
using the Hitachi Solution Engine 7751 board as
|
using the Hitachi Solution Engine 7751 board as
|
an example:
|
an example:
|
It is assumed that the environment variable
|
It is assumed that the environment variable
|
ECOS_REPOSITORY points to the eCos/RedBoot source tree.
|
ECOS_REPOSITORY points to the eCos/RedBoot source tree.
|
|
|
$ ecosconfig new se7751 redboot
|
$ ecosconfig new se7751 redboot
|
U CYGPKG_HAL_SH_7750, new inferred value 0
|
U CYGPKG_HAL_SH_7750, new inferred value 0
|
U CYGPKG_HAL_SH_7751, new inferred value 1
|
U CYGPKG_HAL_SH_7751, new inferred value 1
|
U CYGHWR_HAL_SH_IRQ_USE_IRQLVL, 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 CYGSEM_HAL_USE_ROM_MONITOR, new inferred value 0
|
U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM, 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 CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1
|
U CYGFUN_LIBC_STRING_BSD_FUNCS, new inferred value 0
|
U CYGFUN_LIBC_STRING_BSD_FUNCS, new inferred value 0
|
U CYGPKG_NS_DNS_BUILD, new inferred value 0
|
U CYGPKG_NS_DNS_BUILD, new inferred value 0
|
|
|
Replace the platform name ("se7751") with the appropriate name for the
|
Replace the platform name ("se7751") with the appropriate name for the
|
chosen platform.
|
chosen platform.
|
|
|
|
|
Then import the appropriate platform RedBoot configuration file,
|
Then import the appropriate platform RedBoot configuration file,
|
here for RAM configuration:
|
here for RAM configuration:
|
|
|
$ ecosconfig import ${ECOS_REPOSITORY}/hal/sh/se7751/VERSION/misc/redboot_RAM.ecm
|
$ ecosconfig import ${ECOS_REPOSITORY}/hal/sh/se7751/VERSION/misc/redboot_RAM.ecm
|
$ ecosconfig tree
|
$ ecosconfig tree
|
|
|
Replace architecture ("sh"), platform ("se7751") and version
|
Replace architecture ("sh"), platform ("se7751") and version
|
("VERSION") with those appropriate for the
|
("VERSION") with those appropriate for the
|
chosen platform and the version number of its HAL package. Also
|
chosen platform and the version number of its HAL package. Also
|
replace the configuration name ("redboot_RAM.ecm") with that of the
|
replace the configuration name ("redboot_RAM.ecm") with that of the
|
appropriate configuration file.
|
appropriate configuration file.
|
|
|
|
|
RedBoot can now be built:
|
RedBoot can now be built:
|
|
|
$ make
|
$ make
|
|
|
|
|
|
|
The resulting RedBoot files will be in the associated
|
The resulting RedBoot files will be in the associated
|
install directory, in this example,
|
install directory, in this example,
|
class="directory">./install/bin.
|
class="directory">./install/bin.
|
|
|
In each platform's
|
In each platform's
|
details are described in the form of shell variables. Using those,
|
details are described in the form of shell variables. Using those,
|
the steps to build RedBoot are:
|
the steps to build RedBoot are:
|
|
|
export REDBOOT_CFG=redboot_ROM
|
export REDBOOT_CFG=redboot_ROM
|
export VERSION=VERSION
|
export VERSION=VERSION
|
mkdir /tmp/${REDBOOT_CFG}
|
mkdir /tmp/${REDBOOT_CFG}
|
cd /tmp/${REDBOOT_CFG}
|
cd /tmp/${REDBOOT_CFG}
|
ecosconfig new ${TARGET} redboot
|
ecosconfig new ${TARGET} redboot
|
ecosconfig import ${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm
|
ecosconfig import ${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm
|
ecosconfig tree
|
ecosconfig tree
|
make
|
make
|
|
|
To build for another configuration, simply change the
|
To build for another configuration, simply change the
|
REDBOOT_CFG definition accordingly. Also
|
REDBOOT_CFG definition accordingly. Also
|
make sure the VERSION variable matches the
|
make sure the VERSION variable matches the
|
version of the platform package.
|
version of the platform package.
|
|
|
|
|
|
|
|
|
|
|
Rebuilding RedBoot from the <application>Configuration Tool</application>
|
Rebuilding RedBoot from the <application>Configuration Tool</application>
|
|
|
To rebuild RedBoot from the Configuration
|
To rebuild RedBoot from the Configuration
|
Tool, open the template window (Build->Templates) and
|
Tool, open the template window (Build->Templates) and
|
select the appropriate Hardware target and in Packages select
|
select the appropriate Hardware target and in Packages select
|
"redboot". Then press OK. Depending on the platform, a number of
|
"redboot". Then press OK. Depending on the platform, a number of
|
conflicts may need to be resolved before the build can be started;
|
conflicts may need to be resolved before the build can be started;
|
select "Continue".
|
select "Continue".
|
|
|
Import the desired RedBoot configuration file from the platform HAL
|
Import the desired RedBoot configuration file from the platform HAL
|
(File->Import...). Depending on the platform, a number of
|
(File->Import...). Depending on the platform, a number of
|
conflicts may need to be resolved before the build can be started;
|
conflicts may need to be resolved before the build can be started;
|
select "Continue". For example, if the platform selected is Hitachi
|
select "Continue". For example, if the platform selected is Hitachi
|
SE7751 board and the RAM configuration RedBoot should be built, import
|
SE7751 board and the RAM configuration RedBoot should be built, import
|
the file
|
the file
|
hal/sh/se7751/VERSION/misc/redboot_RAM.ecm.
|
hal/sh/se7751/VERSION/misc/redboot_RAM.ecm.
|
|
|
Save the configuration somewhere suitable with enough disk space
|
Save the configuration somewhere suitable with enough disk space
|
for building RedBoot (File->Save...). Choose the name according to
|
for building RedBoot (File->Save...). Choose the name according to
|
the RedBoot configuration, for example
|
the RedBoot configuration, for example
|
redboot_RAM.ecc.
|
redboot_RAM.ecc.
|
|
|
Then start the build (Build->Library) and wait for it to
|
Then start the build (Build->Library) and wait for it to
|
complete. The resulting RedBoot files will be in the associated
|
complete. The resulting RedBoot files will be in the associated
|
install directory, for the example this would be
|
install directory, for the example this would be
|
class="directory">redboot_RAM_install/bin.
|
class="directory">redboot_RAM_install/bin.
|
|
|
As noted above, each platform's details are described in
|
As noted above, each platform's details are described in
|
linkend="Installation-and-Testing">. Use the information provided in
|
linkend="Installation-and-Testing">. Use the information provided in
|
the shell variables to find the configuration file - the path to it is
|
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,
|
${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm,
|
where ECOS_REPOSITORY points to the
|
where ECOS_REPOSITORY points to the
|
eCos/RedBoot sources, VERSION is the
|
eCos/RedBoot sources, VERSION is the
|
version of the package (usually "current") and
|
version of the package (usually "current") and
|
REDBOOT_CFG is the desired configuration,
|
REDBOOT_CFG is the desired configuration,
|
e.g. redboot_RAM.
|
e.g. redboot_RAM.
|
|
|
|
|
|
|
|
|
Updating RedBoot
|
Updating RedBoot
|
|
|
Introduction
|
Introduction
|
updating
|
updating
|
RedBoot
|
RedBoot
|
RedBootupdatingRedBoot
|
RedBootupdatingRedBoot
|
normally resides in an EPROM or, more common these days, a flash
|
normally resides in an EPROM or, more common these days, a flash
|
on the board. In the former case, updating RedBoot necessitates
|
on the board. In the former case, updating RedBoot necessitates
|
physically removing the part and
|
physically removing the part and
|
reprogramming a new RedBoot image into it using prommer hardware. In
|
reprogramming a new RedBoot image into it using prommer hardware. In
|
the latter case, it is often possible to update RedBoot in situ using
|
the latter case, it is often possible to update RedBoot in situ using
|
Redboot's flash management commands.
|
Redboot's flash management commands.
|
|
|
The process of updating RedBoot in situ is documented in this
|
The process of updating RedBoot in situ is documented in this
|
section. For this process, it is assumed that the target is connected
|
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 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
|
to the RedBoot CLI. For platforms with a ROMRAM mode RedBoot, skip to
|
.
|
.
|
|
|
The addresses and sizes included in the below are examples
|
The addresses and sizes included in the below are examples
|
only, and will differ from those you will see. This is normal and
|
only, and will differ from those you will see. This is normal and
|
should not cause concern.
|
should not cause concern.
|
|
|
|
|
Load and start a RedBoot RAM instance
|
Load and start a RedBoot RAM instance
|
There are a number of choices here. The basic case is where a RAM
|
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
|
mode image has been stored in the FIS (flash Image System). To load and
|
execute this image, use the commands:
|
execute this image, use the commands:
|
RedBoot> fis load RedBoot[RAM]
|
RedBoot> fis load RedBoot[RAM]
|
RedBoot> go
|
RedBoot> go
|
If this image is not available, or does not work,
|
If this image is not available, or does not work,
|
then an alternate RAM mode image must be loaded:
|
then an alternate RAM mode image must be loaded:
|
|
|
RedBoot> load redboot_RAM.img
|
RedBoot> load redboot_RAM.img
|
Entry point: 0x060213c0, address range: 0x06020000-0x060369c8
|
Entry point: 0x060213c0, address range: 0x06020000-0x060369c8
|
RedBoot> go
|
RedBoot> go
|
|
|
|
|
This command loads the RedBoot image using the TFTP
|
This command loads the RedBoot image using the TFTP
|
protocol via a network connection. Other methods of loading are
|
protocol via a network connection. Other methods of loading are
|
available, refer to the
|
available, refer to the
|
linkend="download-command">load command for more
|
linkend="download-command">load command for more
|
details.
|
details.
|
|
|
If you expect to be doing this more than once, it is a
|
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
|
good idea to program the RAM mode image into the flash. You do this
|
using the fis create command after having
|
using the fis create command after having
|
downloaded the RAM mode image, but before you start it.
|
downloaded the RAM mode image, but before you start it.
|
Some platforms support locking (write protecting) certain regions of
|
Some platforms support locking (write protecting) certain regions of
|
the flash, while others do not. If your platform does not support
|
the flash, while others do not. If your platform does not support
|
locking, simply ignore the fis unlock and
|
locking, simply ignore the fis unlock and
|
fis lock steps (the commands will not be
|
fis lock steps (the commands will not be
|
recognized by RedBoot).
|
recognized by RedBoot).
|
|
|
|
|
RedBoot> fis unlock RedBoot[RAM]
|
RedBoot> fis unlock RedBoot[RAM]
|
... Unlock from 0x00000000-0x00020000: ..
|
... Unlock from 0x00000000-0x00020000: ..
|
RedBoot> fis create RedBoot[RAM]
|
RedBoot> fis create RedBoot[RAM]
|
An image named 'RedBoot[RAM]' exists - continue (y/n)? y
|
An image named 'RedBoot[RAM]' exists - continue (y/n)? y
|
* CAUTION * about to program 'RedBoot[RAM]'
|
* CAUTION * about to program 'RedBoot[RAM]'
|
at 0x00020000..0x000369c7 from 0x06020000 - continue (y/n)?y
|
at 0x00020000..0x000369c7 from 0x06020000 - continue (y/n)?y
|
... Erase from 0x00020000-0x00040000: ..
|
... Erase from 0x00020000-0x00040000: ..
|
... Program from 0x06020000-0x060369c8 at 0x00020000: ..
|
... Program from 0x06020000-0x060369c8 at 0x00020000: ..
|
... Erase from 0x00070000-0x00080000: .
|
... Erase from 0x00070000-0x00080000: .
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
RedBoot> fis lock RedBoot[RAM]
|
RedBoot> fis lock RedBoot[RAM]
|
... Lock from 0x00000000-0x00020000: ..
|
... Lock from 0x00000000-0x00020000: ..
|
|
|
|
|
|
|
|
|
|
|
|
|
Update the primary RedBoot flash image An
|
Update the primary RedBoot flash image An
|
instance of RedBoot should now be running on the target from RAM. This
|
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
|
can be verified by looking for the mode identifier in the banner. It
|
should be either [RAM] or [ROMRAM].
|
should be either [RAM] or [ROMRAM].
|
|
|
If this is the first time RedBoot is running on the board or if
|
If this is the first time RedBoot is running on the board or if
|
the flash contents has been damaged, initialize the FIS directory:
|
the flash contents has been damaged, initialize the FIS directory:
|
RedBoot> fis init -f
|
RedBoot> fis init -f
|
About to initialize [format] FLASH image system - continue (y/n)? y
|
About to initialize [format] FLASH image system - continue (y/n)? y
|
*** Initialize FLASH Image System
|
*** Initialize FLASH Image System
|
... Erase from 0x00020000-0x00070000: .....
|
... Erase from 0x00020000-0x00070000: .....
|
... Erase from 0x00080000-0x00080000:
|
... Erase from 0x00080000-0x00080000:
|
... Erase from 0x00070000-0x00080000: .
|
... Erase from 0x00070000-0x00080000: .
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
|
|
|
|
|
|
It is important to understand that the presence of a correctly
|
It is important to understand that the presence of a correctly
|
initialized FIS directory allows RedBoot to automatically determine
|
initialized FIS directory allows RedBoot to automatically determine
|
the flash parameters. Additionally, executing the steps below as
|
the flash parameters. Additionally, executing the steps below as
|
stated without loading other data or using other flash commands (than
|
stated without loading other data or using other flash commands (than
|
possibly fis list) allows RedBoot to automatically
|
possibly fis list) allows RedBoot to automatically
|
determine the image location and size parameters. This greatly reduces
|
determine the image location and size parameters. This greatly reduces
|
the risk of potential critical mistakes due to typographical errors. It is
|
the risk of potential critical mistakes due to typographical errors. It is
|
still always possible to explicitly specify parameters, and indeed
|
still always possible to explicitly specify parameters, and indeed
|
override these, but it is not advised.
|
override these, but it is not advised.
|
|
|
If the new RedBoot image has grown beyond the slot in
|
If the new RedBoot image has grown beyond the slot in
|
flash reserved for it, it is necessary to change the RedBoot
|
flash reserved for it, it is necessary to change the RedBoot
|
configuration option CYGBLD_REDBOOT_MIN_IMAGE_SIZE so the FIS is
|
configuration option CYGBLD_REDBOOT_MIN_IMAGE_SIZE so the FIS is
|
created with adequate space reserved for RedBoot images. In this case,
|
created with adequate space reserved for RedBoot images. In this case,
|
it is necessary to re-initialize the FIS directory as described above,
|
it is necessary to re-initialize the FIS directory as described above,
|
using a RAM mode RedBoot compiled with the updated
|
using a RAM mode RedBoot compiled with the updated
|
configuration.
|
configuration.
|
|
|
Using the load command, download the
|
Using the load command, download the
|
new flash based image from the host, relocating the image to RAM::
|
new flash based image from the host, relocating the image to RAM::
|
RedBoot> load -r -b %{FREEMEMLO} redboot_ROM.bin
|
RedBoot> load -r -b %{FREEMEMLO} redboot_ROM.bin
|
Raw file loaded 0x06046800-0x06062fe8, assumed entry at 0x06046800
|
Raw file loaded 0x06046800-0x06062fe8, assumed entry at 0x06046800
|
|
|
|
|
This command loads the RedBoot image using the TFTP
|
This command loads the RedBoot image using the TFTP
|
protocol via a network connection. Other methods of loading are
|
protocol via a network connection. Other methods of loading are
|
available, refer to the command for
|
available, refer to the command for
|
more details.
|
more details.
|
|
|
Note that the binary version of the image is being
|
Note that the binary version of the image is being
|
downloaded. This is to ensure that the memory after the image is
|
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
|
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
|
or ELF versions of the image does not guarantee this since these
|
formats may contain holes, leaving bytes in these holes in an unknown
|
formats may contain holes, leaving bytes in these holes in an unknown
|
state after the load, and thus causing a likely cksum difference. It
|
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
|
is possible to use these, but then the step verifying the cksum below
|
may fail.
|
may fail.
|
|
|
|
|
Once the image is loaded into RAM, it should be checksummed,
|
Once the image is loaded into RAM, it should be checksummed,
|
thus verifying that the image on the target is indeed the image
|
thus verifying that the image on the target is indeed the image
|
intended to be loaded, and that no corruption of the image has
|
intended to be loaded, and that no corruption of the image has
|
happened. This is done using the
|
happened. This is done using the
|
command:
|
command:
|
RedBoot> cksum
|
RedBoot> cksum
|
Computing cksum for area 0x06046800-0x06062fe8
|
Computing cksum for area 0x06046800-0x06062fe8
|
POSIX cksum = 2535322412 116712 (0x971df32c 0x0001c7e8)
|
POSIX cksum = 2535322412 116712 (0x971df32c 0x0001c7e8)
|
|
|
Compare the numbers with those for the binary version of the image on
|
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.
|
the host. If they do not match, try downloading the image again.
|
|
|
|
|
Assuming the cksum matches, the next step is programming the
|
Assuming the cksum matches, the next step is programming the
|
image into flash using the FIS commands.
|
image into flash using the FIS commands.
|
|
|
Some platforms support locking (write protecting) certain
|
Some platforms support locking (write protecting) certain
|
regions of the flash, while others do not. If your platform does not
|
regions of the flash, while others do not. If your platform does not
|
support locking, simply ignore the fis unlock and
|
support locking, simply ignore the fis unlock and
|
fis lock steps (the commands will not be recognized
|
fis lock steps (the commands will not be recognized
|
by RedBoot).
|
by RedBoot).
|
|
|
RedBoot> fis unlock RedBoot
|
RedBoot> fis unlock RedBoot
|
... Unlock from 0x00000000-0x00020000: ..
|
... Unlock from 0x00000000-0x00020000: ..
|
RedBoot> fis create RedBoot
|
RedBoot> fis create RedBoot
|
An image named 'RedBoot' exists - continue (y/n)? y
|
An image named 'RedBoot' exists - continue (y/n)? y
|
* CAUTION * about to program 'RedBoot'
|
* CAUTION * about to program 'RedBoot'
|
at 0x00000000..0x0001c7e7 from 0x06046800 - continue (y/n)? y
|
at 0x00000000..0x0001c7e7 from 0x06046800 - continue (y/n)? y
|
... Erase from 0x00000000-0x00020000: ..
|
... Erase from 0x00000000-0x00020000: ..
|
... Program from 0x06046800-0x06062fe8 at 0x00000000: ..
|
... Program from 0x06046800-0x06062fe8 at 0x00000000: ..
|
... Erase from 0x00070000-0x00080000: .
|
... Erase from 0x00070000-0x00080000: .
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
RedBoot> fis lock RedBoot
|
RedBoot> fis lock RedBoot
|
... Lock from 0x00000000-0x00020000: ..
|
... Lock from 0x00000000-0x00020000: ..
|
|
|
|
|
|
|
|
|
Reboot; run the new RedBoot image
|
Reboot; run the new RedBoot image
|
Once the image has been successfully written into the flash, simply
|
Once the image has been successfully written into the flash, simply
|
reset the target and the new version of RedBoot should be running.
|
reset the target and the new version of RedBoot should be running.
|
When installing RedBoot for the first time, or after updating to
|
When installing RedBoot for the first time, or after updating to
|
a newer RedBoot with different configuration keys, it is necessary to
|
a newer RedBoot with different configuration keys, it is necessary to
|
update the configuration directory in the flash using the
|
update the configuration directory in the flash using the
|
fconfig command. See
|
fconfig command. See
|
linkend="Persistent-State-Flash">.
|
linkend="Persistent-State-Flash">.
|
|
|
|
|
|
|
|
|
