redboot.sgml

eCos/RedBoot for勤研ARM AnywhereII(4510) 含全部源代码

<listitem><para>
!! repeats last command.
</para></listitem>
<listitem><para>
!<userinput>n</userinput> repeats command <userinput>n</userinput>.
</para></listitem>
<listitem><para>
!<userinput>string</userinput> repeats most recent command starting with
<userinput>string</userinput>.
</para></listitem>
</itemizedlist>
</para>
</sect1>

<sect1 id="startup-mode">
<title>RedBoot Startup Mode</title>
<para>
  <indexterm><primary>RedBoot</primary><secondary>mode</secondary></indexterm>
  <indexterm><primary>RedBoot</primary><secondary>startup mode</secondary></indexterm>
</para>

<para>RedBoot can normally be configured to run in a number of startup
modes (or just "modes" for short), determining its location of
residence and execution:
<variablelist>
 <varlistentry><term>ROM mode</term>
 <listitem><para>In this mode, RedBoot both resides and executes from
 ROM memory (flash or EPROM). This mode is used when there are limited
 RAM resources. The flash commands cannot update the region of flash
 where the RedBoot image resides. In order to update the RedBoot image
 in flash, it is necessary to run a RAM mode instance of
 RedBoot.</para></listitem>
 </varlistentry>

 <varlistentry><term>ROMRAM mode</term>
 <listitem><para>In this mode, RedBoot resides in ROM memory (flash or
 EPROM), but is copied to RAM memory before it starts executing. The
 RAM footprint is larger than for ROM mode, but there are two
 advantages to make up for this: it normally runs faster (relevant
 only on slower boards) and it is able to update the flash region
 where the image resides.</para></listitem>
 </varlistentry>

 <varlistentry><term>RAM mode</term>
 <listitem><para>In this mode, RedBoot both resides and executes from
 RAM memory. This is used for updating a primary ROM
 mode image in situ and sometimes as part of the RedBoot installation
 on the board when there's already an existing (non-RedBoot) boot
 monitor available.</para>

 <para> You can only use ROM and ROMRAM mode images for booting a
 board - a RAM mode image cannot run unless loaded by another ROM
 monitor. There is no need for this startup mode if a RedBoot ROMRAM
 mode image is the primary boot monitor.  When this startup mode is
 programmed into flash (as a convenience as it's fast to load from
 flash) it will generally be named as "RedBoot[RAM]" in the FIS
 directory.  </para></listitem>
 </varlistentry>
</variablelist>

The chosen mode has influence on flash and RAM resource usage (see
<xref linkend="resource-usage">) and the procedure of an in situ update
of RedBoot in flash (see <xref linkend="Updating-Redboot">).</para>

<para>The startup mode is controlled by the option CYG_HAL_STARTUP
which resides in the platform HAL. Some platforms provide only some of
the RAM, ROM, and ROMRAM modes, others provide additional
modes.</para>

<para>To see mode of a currently executing RedBoot, issue the
<command>version</command> command, which prints the RedBoot banner,
including the startup mode (here ROM):
<screen>RedBoot><userinput>version</userinput>

RedBoot(tm) bootstrap and debug environment <emphasis>[ROM]</emphasis>
Non-certified release, version UNKNOWN - built 13:31:57, May 17 2002
</screen>
</para>

</sect1>

<sect1 id="resource-usage">
<title>RedBoot Resource Usage</title>
<para>
  <indexterm><primary>RedBoot</primary><secondary>resource usage</secondary></indexterm>
</para>

<para>RedBoot takes up both flash and RAM resources depending on its
startup mode and number of enabled features. There are also other
resources used by RedBoot, such as timers. Platform-specific resources
used by RedBoot are listed in the platform specific parts of this
manual.</para>

<para>Both flash and RAM resources used by RedBoot depend to some
degree on the features enabled in the RedBoot configuration. It is
possible to reduce in particular the RAM resources used by RedBoot by
removing features that are not needed. Flash resources can also be
reduced, but due to the granularity of the flash (the block sizes),
reductions in feature size do not always result in flash resource
savings.</para>


<sect2>
<title>Flash Resources</title>
<para>On many platforms, a ROM mode RedBoot image resides in the first
flash sectors, working as the board's primary boot monitor. On these
platforms, it is also normal to reserve a similar amount of flash for
a secondary RAM mode image, which is used when updating the primary
ROM mode image.</para>
<para>On other platforms, a ROMRAM mode RedBoot image is used as the
primary boot monitor. On these platforms there is not normally
reserved space for a RAM mode RedBoot image, since the ROMRAM mode
RedBoot is capable of updating the primary boot monitor image.</para>
<para>Most platforms also contain a FIS directory (keeping track of
available flash space) and a RedBoot config block (containing RedBoot
board configuration data).</para>
<para>To see the amount of reserved flash memory, run the <command>fis
list</command> command:
<screen>RedBoot> <userinput>fis list</userinput>
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0x00000000  0x00000000  0x00020000  0x00000000
RedBoot[RAM]      0x00020000  0x06020000  0x00020000  0x060213C0
RedBoot config    0x0007F000  0x0007F000  0x00001000  0x00000000
FIS directory     0x00070000  0x00070000  0x0000F000  0x00000000
</screen>
</para>

<para>To save flash resources, use a ROMRAM mode RedBoot, or if using
a ROM mode RedBoot, avoid reserving space for the RedBoot[RAM] image
(this is done by changing the RedBoot configuration) and download the
RAM mode RedBoot whenever it is needed. If the RedBoot image takes up
a fraction of an extra flash block, it may be possible to reduce the
image size enough to free this block by removing some features.</para>

</sect2>

<sect2>
<title>RAM Resources</title>

<para>RedBoot reserves RAM space for its run-time data, and such
things as CPU exception/interrupt tables. It normally does so at the
bottom of the memory map. It may also reserve space at the top of the
memory map for configurable RedBoot features such as the net stack
and zlib decompression support.</para>
<para>To see the actual amount of reserved space, issue the
<command>version</command> command, which prints the RedBoot banner,
including the RAM usage:
<screen>RedBoot> <userinput>version</userinput>

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 13:31:57, May 17 2002

Platform: FooBar (SH 7615)
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

<emphasis>RAM: 0x06000000-0x06080000, 0x06012498-0x06061000 available</emphasis>
FLASH: 0x00000000 - 0x00080000, 8 blocks of 0x00010000 bytes each.
</screen>
</para>

<para>To simplify operations that temporarily need data in free
memory, the limits of free RAM are also available as aliases (aligned
to the nearest kilo-byte limit). These are named
<indexterm><primary>FREEMEMLO</primary></indexterm>FREEMEMLO and
<indexterm><primary>FREEMEMHI</primary></indexterm>FREEMEMHI, and can
be used in commands like any user defined alias:
<screen>RedBoot> <userinput>load -r -b %{FREEMEMLO} file</userinput>
Raw file loaded 0x06012800-0x06013e53, assumed entry at 0x06012800
</screen>
<screen>
RedBoot> <userinput>x -b %{FREEMEMHI}</userinput>
06061000: 86 F5 EB D8 3D 11 51 F2  96 F4 B2 DC 76 76 8F 77  |....=.Q.....vv.w|
06061010: E6 55 DD DB F3 75 5D 15  E0 F3 FC D9 C8 73 1D DA  |.U...u]......s..|
</screen>
</para>

<para>To reduce RedBoot's RAM resource usage, use a ROM mode
RedBoot. The RedBoot features that use most RAM are the net stack, the
flash support and the gunzip support. These, and other features, can
be disabled to reduce the RAM footprint, but obviously at the cost of
lost functionality.</para>

</sect2>
</sect1>

<sect1 id="Configuring-the-RedBoot-Environment">
<title>Configuring the RedBoot Environment</title>
<para><indexterm><primary>configuring the RedBoot environment</primary><secondary></secondary>
</indexterm><indexterm><primary>RedBoot </primary><secondary>environment configuration
</secondary></indexterm><indexterm><primary>environment configuration</primary>
</indexterm>Once installed, RedBoot will operate fairly generically. However,
there are some features that can be configured for a particular installation.
These depend primarily on whether <indexterm><primary>flash and/or networking
support</primary></indexterm><indexterm><primary>networking and/or flash support
</primary></indexterm>flash and/or networking support are available. The remainder
of this discussion assumes that support for both of these options is included
in RedBoot.</para>
<sect2 id=target-network-configuration>
<title>Target Network Configuration</title>
<para><indexterm><primary>target network configuration</primary></indexterm><indexterm>
<primary>network configuration</primary></indexterm><indexterm><primary>configuration
</primary><secondary>secondary</secondary></indexterm>Each node in a networked
system needs to have a unique address. Since the network support in RedBoot
is based on <indexterm><primary>TCP/IP</primary></indexterm>TCP/IP, this address
is an IP (Internet Protocol) address. <indexterm><primary>IP address type
</primary></indexterm>There are two ways for a system to &ldquo;know&rdquo;
its IP address. First, it can be stored locally on the platform. This is known
as having a static IP address. Second, the system can use the network itself
to discover its IP address. This is known as a dynamic IP address. RedBoot
supports this dynamic IP address mode by use of the <indexterm><primary>BOOTP
</primary></indexterm>BOOTP (a subset of <indexterm><primary>DHCP</primary>
</indexterm>DHCP) protocol. In this case, RedBoot will ask the network (actually
some generic server on the network) for the IP address to use.</para>
<note><title>NOTE</title>
<para>Currently, RedBoot only supports BOOTP. In future releases, DHCP may
also be supported, but such support will be limited to additional data items,
not lease-based address allocation.</para>
</note>
<para>The choice of <indexterm><primary>IP address type</primary></indexterm>IP
address type is made via the <indexterm><primary>fconfig command</primary>
</indexterm><command>fconfig</command> command. Once a selection
is made, it will be stored in flash memory. RedBoot only queries the flash
configuration information at reset, so any changes will require restarting
the platform.</para>
<para>Here is an example of the RedBoot <command>fconfig</command>
command, showing network addressing:    </para>
<programlisting>RedBoot> <userinput>fconfig -l</userinput>
Run script at boot: false
Use BOOTP for network configuration: false
Local IP address: 192.168.1.29
Default server IP address: 192.168.1.101
DNS server IP address: 192.168.1.1
GDB connection port: 9000
Network debug at boot time: false  </programlisting>
<para>In this case, the board has been configured with a static IP address
listed as the Local IP address. The default server IP address specifies which
network node to communicate with for TFTP service. This address can be overridden
directly in the <indexterm><primary>TFTP commands</primary></indexterm>TFTP
commands.</para>
<para>The <computeroutput>DNS server IP address</computeroutput> option
controls where RedBoot should make DNS lookups<indexterm><primary>DNS
lookups</primary></indexterm>. A setting of 0.0.0.0 will disable DNS
lookups. The DNS server IP address can also be set at runtime.</para>
<para>If the selection for <computeroutput>Use BOOTP for network configuration
</computeroutput> had been <computeroutput>true</computeroutput>, these IP
addresses would be determined at boot time, via the BOOTP protocol. The final