OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /or1k/trunk/ecos-2.0/packages/redboot/v2_0/doc
    from Rev 1254 to Rev 1765
    ↔ Reverse comparison
  •

Rev 1254 → Rev 1765

/redboot.sgml
0,0 → 1,693
<!-- {{{ Banner -->
 
<!-- =============================================================== -->
<!-- -->
<!-- redboot.sgml -->
<!-- -->
<!-- RedBoot package -->
<!-- -->
<!-- =============================================================== -->
<!-- ####COPYRIGHTBEGIN#### -->
<!-- -->
<!-- =============================================================== -->
<!-- Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/) -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission obtained from the copyright holder -->
<!-- =============================================================== -->
<!-- -->
<!-- ####COPYRIGHTEND#### -->
<!-- =============================================================== -->
<!-- #####DESCRIPTIONBEGIN#### -->
<!-- -->
<!-- ####DESCRIPTIONEND#### -->
<!-- =============================================================== -->
 
<!-- }}} -->
 
<part id="redboot"><beginpage>
<title>RedBoot&trade; User's Guide</title>
<toc id="Getting-Started-with-Redboot2"></toc>
<chapter id="Getting-Started-with-RedBoot">
<title>Getting Started with RedBoot</title>
<para><indexterm><primary>Red Boot</primary><secondary>getting started</secondary>
</indexterm>RedBoot&trade; is an acronym for "Red Hat Embedded Debug and Bootstrap",
and is the standard embedded system debug/bootstrap environment from Red Hat,
replacing the previous generation of debug firmware: <indexterm><primary>CygMon</primary>
</indexterm>CygMon and <indexterm><primary>GDB stubs</primary></indexterm>GDB
stubs. It provides a complete bootstrap environment for a range of embedded
operating systems, such as embedded Linux&trade; and eCos&trade;, and includes facilities
such as network downloading and debugging. It also provides a simple flash
file system for boot images.</para>
<para>RedBoot provides a wide set of tools for downloading and executing programs
on embedded target systems, as well as tools for manipulating the target system's
environment. It can be used for both product development (debug support) and
for end product deployment (flash and network booting).</para>
<para>Here are some highlights of <indexterm><primary>RedBoot's capabilities
</primary></indexterm>RedBoot&rsquo;s capabilities: </para>
<itemizedlist>
<listitem><para>Boot scripting support</para>
</listitem>
<listitem><para>Simple command line interface for RedBoot configuration and
management, accessible via serial (terminal) or Ethernet (telnet) </para>
</listitem>
<listitem><para>Integrated GDB stubs for connection to a host-based debugger
via serial or ethernet. (Ethernet connectivity is limited to local network
only)</para>
</listitem>
<listitem><para>Attribute Configuration - user control of aspects such as
system time and date (if applicable), default Flash image to boot from, default
failsafe image, static IP address, etc.</para>
</listitem>
<listitem><para>Configurable and extensible, specifically adapted to the target
environment </para>
</listitem>
<listitem><para>Network bootstrap support including setup and download, via
BOOTP, DHCP and TFTP</para>
</listitem>
<listitem><para>X/YModem support for image download via serial</para>
</listitem>
<listitem><para>Power On Self Test</para>
</listitem>
</itemizedlist>
<para>Although RedBoot is derived from eCos, it may be used as a generalized
system debug and bootstrap control software for any embedded system and any
operating system. For example, with appropriate additions, RedBoot could replace
the commonly used BIOS of PC (and certain other) architectures. Red Hat is
currently installing RedBoot on all embedded platforms as a standard practice,
and RedBoot is now generally included as part of all Red Hat Embedded Linux
and eCos ports. Users who specifically wish to use RedBoot with the eCos operating
system should refer to the <emphasis>Getting Started with eCos</emphasis>
document, which provides information about the portability and extendability
of RedBoot in an eCos environment.</para>
<sect1 id="redboot-on-the-web">
<title>More information about RedBoot on the web</title>
<para>The <ulink url="http://sources.redhat.com/redboot/">RedBoot Net
Distribution web site</ulink> contains downloadable sources and documentation
for all publically released targets, including the latest features and updates.
</para>
</sect1>
<sect1 id="installing-redboot">
<title>Installing RedBoot</title>
<para><indexterm><primary>installing RedBoot</primary><secondary>general procedures
</secondary></indexterm><indexterm><primary>RedBoot installation</primary>
<secondary>general procedures</secondary></indexterm>To install the RedBoot
package, follow the procedures detailed in the accompanying README. </para>
<para>Although there are other possible configurations, RedBoot is usually
run from the target platform&rsquo;s flash boot sector or boot ROM, and is
designed to run when your system is initially powered on. The method used
to install the RedBoot image into non-volatile storage varies from platform
to platform. In general, it requires that the image be programmed into flash
in situ or programmed into the flash or ROM using a device programmer. In
some cases this will be done at manufacturing time; the platform being delivered
with RedBoot already in place. In other cases, you will have to program RedBoot
into the appropriate device(s) yourself. Installing to flash in situ may require
special cabling or interface devices and software provided by the board manufacturer.
The details of this installation process for a given platform will be found
in Installation and Testing. Once installed, user-specific configuration options
may be applied, using the <command>fconfig</command> command,
providing that persistent data storage in flash is present in the relevant
RedBoot version. See <xref linkend="Configuring-the-RedBoot-Environment">
for details.</para>
</sect1>
<sect1 id="user-interface">
<title>User Interface</title>
<para><indexterm><primary>user interface</primary></indexterm><indexterm>
<primary>ui</primary></indexterm><indexterm><primary>cli</primary></indexterm>RedBoot
provides a command line user interface (CLI). At the minimum, this interface
is normally available on a serial port on the platform. If more than one serial
interface is available, RedBoot is normally configured to try to use any one
of the ports for the CLI. Once command input has been received on one port,
that port is used exclusively until the board is reset or the channel
is manually changed by the
user. If the platform has networking
capabilities, the RedBoot CLI is also accessible using the <computeroutput>
telnet</computeroutput> access protocol. By default, RedBoot runs <computeroutput><indexterm>
<primary>telnet</primary></indexterm>telnet</computeroutput> on port TCP/9000,
but this is configurable and/or settable by the user. </para>
<para>RedBoot also contains a set of <indexterm><primary>GDB stubs</primary>
</indexterm>GDB "stubs", consisting of code which supports the GDB remote
protocol. GDB stub mode is automatically invoked when the '$' character appears
anywhere on a command line unless escaped using the '\' character.
The platform will remain in GDB
stub mode until explicitly disconnected (via the GDB protocol). The GDB stub
mode is available regardless of the connection method; either serial or network.
Note that if a GDB connection is made via the network, then special care must
be taken to preserve that connection when running user code. eCos contains
special network sharing code to allow for this situation, and can be used
as a model if this methodology is required in other OS environments.</para>
</sect1>
 
<sect1 id="RedBoot-Editing-Commands">
<title>RedBoot Editing Commands</title>
<para><indexterm><primary>RedBoot</primary><secondary>editing commands</secondary>
</indexterm><indexterm><primary>editing commands</primary></indexterm><indexterm>
<primary>commands</primary><secondary>editing</secondary></indexterm>RedBoot
uses the following line editing commands.
<note><title>NOTE</title>
<para>
In this description, <guibutton>^A</guibutton> means the character formed
by typing the letter &ldquo;A&rdquo; while holding down the control key.
</para></note>
<itemizedlist>
<listitem><para><guibutton>Delete</guibutton> (0x7F) or
<guibutton>Backspace</guibutton> (0x08)
erases the character to the left of the cursor.
</para></listitem>
<listitem><para>
<guibutton>^A</guibutton>
moves the cursor (insertion point) to the beginning of the line.
</para></listitem>
<listitem><para>
<guibutton>^K</guibutton>
erases all characters on the line from the cursor to the end.
</para></listitem>
<listitem><para>
<guibutton>^E</guibutton>
positions the cursor to the end of the line.
</para></listitem>
<listitem><para>
<guibutton>^D</guibutton>
erases the character under the cursor.
</para></listitem>
<listitem><para>
<guibutton>^F</guibutton>
moves the cursor one character to the right.
</para></listitem>
<listitem><para>
<guibutton>^B</guibutton>
moves the cursor one character to the left.
</para></listitem>
<listitem><para>
<guibutton>^P</guibutton>
replaces the current line by a previous line from the history buffer.
A small number of lines
can be kept as history. Using ^P (and ^N), the current line can be replaced
by any one of the previously typed lines.
</para></listitem>
<listitem><para>
<guibutton>^N</guibutton>
replaces the current line by the next line from the history buffer.
</para></listitem>
</itemizedlist></para>
<para>In the case of the <command>fconfig</command>
command, additional editing commands are possible.
As data are entered for this command, the current/previous value
will be displayed and the cursor placed at the end of that data.
The user may use the editing keys (above) to move around in the data
to modify it as appropriate.
Additionally, when certain
characters are entered at the end of the current value,
i.e. entered separately, certain behavior is elicited.</para>
<para><itemizedlist>
<listitem>
<para>^ (caret) switch to editing the previous item in the
<command>fconfig</command> list. If fconfig edits item A, followed by item B,
pressing ^ when changing item B, allows you to change item A. This is similar
to the up arrow.
Note: ^P and ^N do not have the same meaning while editing
<command>fconfig</command> data and should not be used.
</para>
</listitem>
<listitem><para>. (period) stop editing any further items. This does not change
the current item.</para>
</listitem>
<listitem><para><guibutton>Return</guibutton> leaves the value
for this item unchanged. Currently it is not possible to step through the
value for the start-up script; it must always be retyped.</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
number which needs to be configured, regardless of IP address selection mode,
is the <indexterm><primary>GDB connection port</primary></indexterm><computeroutput>
GDB connection port</computeroutput>. RedBoot allows for incoming commands
on either the available serial ports or via the network. This port number
is the TCP port that RedBoot will use to accept incoming connections. </para>
<para>These connections can be used for GDB sessions, but they can also be
used for generic RedBoot commands. In particular, it is possible to communicate
with RedBoot via the <indexterm><primary>telnet</primary></indexterm>telnet
protocol. For example, on Linux&reg;: </para>
<programlisting>% telnet redboot_board 9000
Connected to redboot_board
Escape character is &lsquo;^]&rsquo;.
RedBoot> </programlisting>
</sect2>
<sect2>
<title>Host Network Configuration</title>
<para><indexterm><primary>host network configuration</primary></indexterm><indexterm>
<primary>network configuration</primary><secondary>host</secondary></indexterm><indexterm>
<primary>configuration</primary><secondary>network</secondary></indexterm>RedBoot
may require three different classes of service from a network host: </para>
<itemizedlist>
<listitem><para>dynamic IP address allocation, using BOOTP </para>
</listitem>
<listitem><para>TFTP service for file downloading </para>
</listitem>
<listitem><para>DNS server for hostname lookups </para>
</listitem>
</itemizedlist>
<para>Depending on the host system, these services may or may not be available
or enabled by default. See your system documentation for more details.</para>
<para>In particular, on Red Hat Linux, neither of these services will be configured
out of the box. The following will provide a limited explanation of how to
set them up. These configuration setups must be done as <computeroutput>root
</computeroutput> on the host or server machine.</para>
<sect3>
<title>Enable TFTP on Red Hat Linux 6.2</title>
<procedure>
<step><para><indexterm><primary>TFTP</primary><secondary>enabling on Red Hat
Linux 6.2</secondary></indexterm><indexterm><primary>Red Hat Linux</primary>
<secondary>enabling TFTP on version 6.2</secondary></indexterm>Ensure that
you have the tftp-server RPM package installed. By default, this installs
the TFTP server in a disabled state. These steps will enable it:</para>
</step>
<step><para>Make sure that the following line is uncommented in the control
file <filename>/etc/inetd.conf</filename> <screen>tftp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.tftpd
</screen></para>
<para></para>
</step>
<step><para>If it was necessary to change the line in Step 2, then the inetd
server must be restarted, which can be done via the command: <programlisting>
# service inet reload</programlisting></para>
</step>
</procedure>
</sect3>
<sect3>
<title>Enable TFTP on Red Hat Linux 7 (or newer)</title>
<procedure>
<step><para><indexterm><primary>TFTP</primary><secondary>enabling on Red Hat
Linux 7</secondary></indexterm><indexterm><primary>Red Hat Linux</primary>
<secondary>enabling TFTP on version 7</secondary></indexterm>Ensure that the
xinetd RPM is installed.</para>
</step>
<step><para>Ensure that the tftp-server RPM is installed.</para>
</step>
<step><para>Enable TFTP by means of the following: <programlisting>/sbin/chkconfig tftp on
</programlisting>Reload the xinetd configuration using the command:<programlisting>
/sbin/service xinetd reload </programlisting>Create the directory /tftpboot
using the command <programlisting>mkdir /tftpboot</programlisting></para>
</step>
</procedure>
<note><title>NOTE</title>
<para>Under Red Hat 7 you must address files by absolute pathnames, for example: <filename>
/tftpboot/boot.img</filename> not <filename>/boot.img</filename>, as you may have done with
other implementations.
On systems newer than Red Hat 7 (7.1 and beyond), filenames are once again relative to the
<filename>/tftpboot</filename> directory.
</para>
</note>
</sect3>
<sect3>
<title>Enable BOOTP/DHCP server on Red Hat Linux</title>
<para><indexterm><primary>DHCP</primary><secondary>enabling on Red Hat Linux
</secondary></indexterm><indexterm><primary>BOOTP</primary><secondary>
enabling on Red Hat Linux</secondary></indexterm>First, ensure that you have
the proper package, <computeroutput>dhcp</computeroutput> (not <computeroutput>
dhcpd</computeroutput>) installed. The DHCP server provides Dynamic Host Configuration,
that is, IP address and other data to hosts on a network. It does this in
different ways. Next, there can be a fixed relationship between a certain
node and the data, based on that node&rsquo;s unique Ethernet Station Address
(ESA, sometimes called a MAC address). The other possibility is simply to
assign addresses that are free. The sample DHCP configuration file shown does
both. Refer to the DHCP documentation for more details.</para>
<example><title>Sample DHCP configuration file</title>
<programlisting>--------------- /etc/dhcpd.conf -----------------------------
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option domain-name-servers 198.41.0.4, 128.9.0.107;
option domain-name &ldquo;bogus.com&rdquo;;
allow bootp;
shared-network BOGUS {
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.101;
range 192.168.1.1 192.168.1.254;
}
}
host mbx {
hardware ethernet 08:00:3E:28:79:B8;
fixed-address 192.168.1.20;
filename &ldquo;/tftpboot/192.168.1.21/zImage&rdquo;;
default-lease-time -1;
server-name &ldquo;srvr.bugus.com&rdquo;;
server-identifier 192.168.1.101;
option host-name &ldquo;mbx&rdquo;;
} </programlisting></example>
<para>Once the DHCP package has been installed and the configuration file
set up, type:<screen>
# <userinput>service dhcpd start</userinput></screen></para>
</sect3>
<sect3>
<title>Enable DNS server on Red Hat Linux</title>
<para><indexterm><primary>DNS</primary><secondary>enabling on Red Hat
Linux</secondary></indexterm>First, ensure that you have the proper
RPM package, <computeroutput>caching-nameserver</computeroutput>
installed. Then change the configuration
(in <filename>/etc/named.conf</filename>) so that the
<computeroutput>forwarders</computeroutput> point to the primary
nameservers for your machine, normally using the nameservers listed in
<filename>/etc/resolv.conf</filename>.</para>
 
<example><title>
Sample <filename>/etc/named.conf</filename> for Red Hat Linux 7.x
</title>
 
<programlisting>--------------- /etc/named.conf -----------------------------
// generated by named-bootconf.pl
 
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
 
 
forward first;
forwarders {
212.242.40.3;
212.242.40.51;
};
};
 
//
// a caching only nameserver config
//
// Uncomment the following for Red Hat Linux 7.2 or above:
// controls {
// inet 127.0.0.1 allow { localhost; } keys { rndckey; };
// };
// include "/etc/rndc.key";
zone "." IN {
type hint;
file "named.ca";
};
 
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
 
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
 
</programlisting></example>
 
<para>Make sure the server is started with the command:
<screen># <userinput>service named start</userinput></screen> and is
started on next reboot with the command
<screen># <userinput>chkconfig named on</userinput></screen>
Finally, you may wish to change
<filename>/etc/resolv.conf</filename> to use
<computeroutput>127.0.0.1</computeroutput> as the nameserver for your
local machine.</para>
</sect3>
<sect3>
<title>RedBoot network gateway</title>
<para><indexterm><primary>RedBoot network gateway</primary></indexterm><indexterm>
<primary>network gateway</primary></indexterm>RedBoot cannot communicate with
machines on different subnets because it does not support routing. It always
assumes that it can get to an address directly, therefore it always tries
to ARP and then send packets directly to that unit. This means that whatever
it talks to must be on the same subnet. If you need to talk to a host on a
different subnet (even if it's on the same &lsquo;wire&rsquo;), you need to
go through an ARP proxy, providing that there is a Linux box connected to
the network which is able to route to the TFTP server. For example: <filename>
/proc/sys/net/ipv4/conf/<replaceable>&lt;interface></replaceable>/proxy_arp </filename>where <replaceable>
&lt;interface></replaceable>should be replaced with whichever network interface
is directly connected to the board.</para>
</sect3></sect2>
<sect2>
<title>Verification</title>
<para><indexterm><primary>verification (network)</primary></indexterm><indexterm>
<primary>network verification</primary></indexterm>Once your network setup
has been configured, perform simple verification tests as follows: <itemizedlist>
<listitem><para>Reboot your system, to enable the setup, and then try to &lsquo;ping&rsquo;
the target board from a host.</para>
</listitem>
<listitem><para>Once communication has been established, try to ping
a host using the RedBoot ping command - both by IP address and hostname.</para>
</listitem>
<listitem><para>Try using the RedBoot load command to download a file
from a host.</para>
</listitem>
</itemizedlist></para>
</sect2></sect1></chapter>
 
<!-- Commands -->
<!-- &redboot-current-doc-redboot-cmds-sgml; -->
 
<!-- Rebuilding -->
<!-- &redboot-current-doc-redboot-rebuilding-sgml; -->
 
<!-- Installing and testing -->
<!-- &redboot-current-doc-redboot-installing-sgml; -->
 
<!-- Epilogue -->
<!-- &redboot-current-doc-redboot-epilogue-sgml; -->
/redboot_rebuilding.sgml
0,0 → 1,374
<!-- {{{ Banner -->
 
<!-- =============================================================== -->
<!-- -->
<!-- redboot_rebuilding.sgml -->
<!-- -->
<!-- RedBoot Documentation -->
<!-- -->
<!-- =============================================================== -->
<!-- ####COPYRIGHTBEGIN#### -->
<!-- -->
<!-- =============================================================== -->
<!-- Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/) -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission obtained from the copyright holder -->
<!-- =============================================================== -->
<!-- -->
<!-- ####COPYRIGHTEND#### -->
<!-- =============================================================== -->
<!-- #####DESCRIPTIONBEGIN#### -->
<!-- -->
<!-- ####DESCRIPTIONEND#### -->
<!-- =============================================================== -->
 
<!-- }}} -->
 
<chapter id="Rebuilding-Redboot">
<title>Rebuilding RedBoot</title>
<sect1>
<title>Introduction</title>
<para><indexterm><primary>rebuilding RedBoot</primary></indexterm><indexterm>
<primary>RedBoot</primary><secondary>rebuilding</secondary></indexterm>
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 <application>Configuration
Tool</application>, as well as from the command line using
<application>ecosconfig</application>.</para>
 
<para>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.</para>
 
<para>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:
<filename>redboot_RAM.ecm</filename> for a RAM mode RedBoot
configuration and <filename>redboot_ROM.ecm</filename> or
<filename>redboot_ROMRAM.ecm</filename> for a ROM or ROMRAM mode
RedBoot configuration. There may be additional
configuration files according to the requirements of the particular
platform.</para>
 
<para>The RedBoot build process results in a number of files in the
install <filename class="directory">bin</filename> directory. The ELF
file <filename>redboot.elf</filename> is the pricipal
result. Depending on the platform CDL, there will also be generated
versions of RedBoot in other file formats, such as
<filename>redboot.bin</filename> (binary format, good when doing an
update of a primary RedBoot image, see <xref
linkend="update-primary-image">), <filename>redboot.srec</filename>
(Motorola S-record format, good when downloading a RAM mode image for
execution), and <filename>redboot.img</filename> (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.</para>
 
<para>The platform specific information in <xref
linkend="Installation-and-Testing"> should be consulted, as there may
be other special instructions required to build RedBoot for particular
platforms.</para>
 
<sect2>
<title>Rebuilding RedBoot using <application>ecosconfig</application></title>
 
<para>To rebuild RedBoot using the
<application>ecosconfig</application> tool, create a temporary
directory for building RedBoot, name it according to the desired
configuration of RedBoot, here RAM:
<screen>
$ <userinput>mkdir /tmp/redboot_RAM</userinput>
$ <userinput>cd /tmp/redboot_RAM</userinput>
</screen>
</para>
 
<para>Create the build tree according to the chosen platform, here
using the Hitachi Solution Engine 7751 board as
an example:
<note><para>It is assumed that the environment variable
ECOS_REPOSITORY points to the eCos/RedBoot source tree.</para></note>
<screen>
$ <userinput>ecosconfig new se7751 redboot</userinput>
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
</screen>
Replace the platform name ("se7751") with the appropriate name for the
chosen platform.
</para>
 
<para>Then import the appropriate platform RedBoot configuration file,
here for RAM configuration:
<screen>
$ <userinput>ecosconfig import <filename>${ECOS_REPOSITORY}/hal/sh/se7751/<replaceable>VERSION</replaceable>/misc/redboot_RAM.ecm</filename></userinput>
$ <userinput>ecosconfig tree</userinput>
</screen>
Replace architecture ("sh"), platform ("se7751") and version
("<replaceable>VERSION</replaceable>") 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.
</para>
 
<para>RedBoot can now be built:
<screen>
$ <userinput>make</userinput>
</screen>
</para>
 
<para>The resulting RedBoot files will be in the associated
install directory, in this example, <filename
class="directory">./install/bin</filename>.</para>
 
<para>In <xref linkend="Installation-and-Testing"> each platform's
details are described in the form of shell variables. Using those,
the steps to build RedBoot are:
<programlisting>
export REDBOOT_CFG=redboot_ROM
export VERSION=<replaceable>VERSION</replaceable>
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
</programlisting>
To build for another configuration, simply change the
<replaceable>REDBOOT_CFG</replaceable> definition accordingly. Also
make sure the <replaceable>VERSION</replaceable> variable matches the
version of the platform package.
</para>
</sect2>
 
 
<sect2>
<title>Rebuilding RedBoot from the <application>Configuration Tool</application></title>
 
<para>To rebuild RedBoot from the <application>Configuration
Tool</application>, open the template window (<guimenuitem>Build->Templates</guimenuitem>) 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".</para>
 
<para>Import the desired RedBoot configuration file from the platform HAL
(<guimenuitem>File->Import...</guimenuitem>). 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
<filename>hal/sh/se7751/<replaceable>VERSION</replaceable>/misc/redboot_RAM.ecm</filename>.</para>
 
<para>Save the configuration somewhere suitable with enough disk space
for building RedBoot (<guimenuitem>File->Save...</guimenuitem>). Choose the name according to
the RedBoot configuration, for example
<filename>redboot_RAM.ecc</filename>.</para>
 
<para>Then start the build (<guimenuitem>Build->Library</guimenuitem>) and wait for it to
complete. The resulting RedBoot files will be in the associated
install directory, for the example this would be <filename
class="directory">redboot_RAM_install/bin</filename>.</para>
 
<para>As noted above, each platform's details are described in <xref
linkend="Installation-and-Testing">. Use the information provided in
the shell variables to find the configuration file - the path to it is
<filename>${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm</filename>,
where <replaceable>ECOS_REPOSITORY</replaceable> points to the
eCos/RedBoot sources, <replaceable>VERSION</replaceable> is the
version of the package (usually "current") and
<replaceable>REDBOOT_CFG</replaceable> is the desired configuration,
e.g. redboot_RAM.
</para>
</sect2></sect1></chapter>
 
<chapter id="Updating-Redboot">
<title>Updating RedBoot</title>
<sect1>
<title>Introduction</title>
<para><indexterm><primary>updating
RedBoot</primary></indexterm><indexterm>
<primary>RedBoot</primary><secondary>updating</secondary></indexterm>RedBoot
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.</para>
 
<para>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
<xref linkend="update-primary-image">.</para>
 
<note><para>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.</para></note>
 
<sect2 id="different-version-from-RAM">
<title>Load and start a RedBoot RAM instance</title>
<para>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: <screen>
RedBoot> <userinput>fis load RedBoot[RAM]</userinput>
RedBoot> <userinput>go</userinput></screen>
If this image is not available, or does not work,
then an alternate RAM mode image must be loaded:
<screen>
RedBoot> <userinput>load redboot_RAM.img</userinput>
Entry point: 0x060213c0, address range: 0x06020000-0x060369c8
RedBoot> <userinput>go</userinput>
</screen>
 
<note><para>This command loads the RedBoot image using the TFTP
protocol via a network connection. Other methods of loading are
available, refer to the <command><link
linkend="download-command">load</link</command> command for more
details. </para></note>
 
<note><para>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 <command>fis create</command> command after having
downloaded the RAM mode image, but before you start it.</para>
<para>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 <command>fis unlock</command> and
<command>fis lock</command> steps (the commands will not be
recognized by RedBoot).</para>
<para>
<screen>
RedBoot> <userinput>fis unlock RedBoot[RAM]</userinput>
... Unlock from 0x00000000-0x00020000: ..
RedBoot> <userinput>fis create RedBoot[RAM]</userinput>
An image named 'RedBoot[RAM]' exists - continue (y/n)? <userinput>y</userinput>
* CAUTION * about to program 'RedBoot[RAM]'
at 0x00020000..0x000369c7 from 0x06020000 - continue (y/n)?<userinput>y</userinput>
... Erase from 0x00020000-0x00040000: ..
... Program from 0x06020000-0x060369c8 at 0x00020000: ..
... Erase from 0x00070000-0x00080000: .
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
RedBoot> <userinput>fis lock RedBoot[RAM]</userinput>
... Lock from 0x00000000-0x00020000: ..
</screen>
</para></note>
</para>
</sect2>
 
<sect2 id="update-primary-image">
<title>Update the primary RedBoot flash image</title> <para>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].</para>
 
<para>If this is the first time RedBoot is running on the board or if
the flash contents has been damaged, initialize the FIS directory:
<screen>RedBoot> <userinput>fis init -f</userinput>
About to initialize [format] FLASH image system - continue (y/n)? <userinput>y</userinput>
*** Initialize FLASH Image System
... Erase from 0x00020000-0x00070000: .....
... Erase from 0x00080000-0x00080000:
... Erase from 0x00070000-0x00080000: .
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
</screen>
</para>
 
<para>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 <command>fis list</command>) 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.</para>
 
<note><para>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.</para></note>
 
<para>Using the <command>load</command> command, download the
new flash based image from the host, relocating the image to RAM::
<screen>RedBoot> <userinput>load -r -b %{FREEMEMLO} redboot_ROM.bin</userinput>
Raw file loaded 0x06046800-0x06062fe8, assumed entry at 0x06046800
</screen>
 
<note><para>This command loads the RedBoot image using the TFTP
protocol via a network connection. Other methods of loading are
available, refer to the <xref linkend="download-command"> command for
more details. </para></note>
 
<note><para>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.</para></note>
</para>
 
<para>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 <xref linkend="cksum-command">
command:
<screen>RedBoot> <userinput>cksum</userinput>
Computing cksum for area 0x06046800-0x06062fe8
POSIX cksum = 2535322412 116712 (0x971df32c 0x0001c7e8)
</screen>
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.</para>
 
 
<para>Assuming the cksum matches, the next step is programming the
image into flash using the FIS commands.</para>
 
<para>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 <command>fis unlock</command> and
<command>fis lock</command> steps (the commands will not be recognized
by RedBoot).</para>
 
<screen>RedBoot> <userinput>fis unlock RedBoot</userinput>
... Unlock from 0x00000000-0x00020000: ..
RedBoot> <userinput>fis create RedBoot</userinput>
An image named 'RedBoot' exists - continue (y/n)? <userinput>y</userinput>
* CAUTION * about to program 'RedBoot'
at 0x00000000..0x0001c7e7 from 0x06046800 - continue (y/n)? <userinput>y</userinput>
... Erase from 0x00000000-0x00020000: ..
... Program from 0x06046800-0x06062fe8 at 0x00000000: ..
... Erase from 0x00070000-0x00080000: .
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
RedBoot> <userinput>fis lock RedBoot</userinput>
... Lock from 0x00000000-0x00020000: ..
</screen>
 
</sect2>
<sect2>
<title>Reboot; run the new RedBoot image</title>
<para>Once the image has been successfully written into the flash, simply
reset the target and the new version of RedBoot should be running. </para>
<para>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
<command>fconfig</command> command. See <xref
linkend="Persistent-State-Flash">.
</para>
 
</sect2></sect1></chapter>
/redboot_installing.sgml
0,0 → 1,5723
<!-- {{{ Banner -->
 
<!-- =============================================================== -->
<!-- -->
<!-- redboot_installing.sgml -->
<!-- -->
<!-- RedBoot Documentation -->
<!-- -->
<!-- =============================================================== -->
<!-- ####COPYRIGHTBEGIN#### -->
<!-- -->
<!-- =============================================================== -->
<!-- Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/) -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission obtained from the copyright holder -->
<!-- =============================================================== -->
<!-- -->
<!-- ####COPYRIGHTEND#### -->
<!-- =============================================================== -->
<!-- #####DESCRIPTIONBEGIN#### -->
<!-- -->
<!-- ####DESCRIPTIONEND#### -->
<!-- =============================================================== -->
 
<!-- }}} -->
 
<!-- FIXME:
Need to make index terms consistent
-->
 
 
<chapter id="Installation-and-Testing">
<title>Installation and Testing</title>
<indexterm><primary>installing and testing RedBoot</primary></indexterm><indexterm>
<primary>RedBoot</primary><secondary>installing and testing</secondary></indexterm>
 
<!-- *************************** AM3x ********************** -->
 
<?Pub _newpage>
<sect1 id="asb2305">
<title>AM3x/MN103E010 Matsushita MN103E010 (AM33/2.0) ASB2305 Board</title>
<sect2>
<title>Overview</title>
<para>
<indexterm>
<primary>Matsushita MN103E010 (AM33/2.0) ASB2305 Board</primary>
<secondary>installing and testing</secondary>
</indexterm>
<indexterm>
<primary>installing and testing</primary>
<secondary>Matsushita MN103E010 (AM33/2.0) ASB2305 Board</secondary>
</indexterm>
RedBoot supports the debug serial port and the built in ethernet port for communication and
downloads. The default serial port settings are 115200,8,N,1 with RTS/CTS flow control. RedBoot can
run from either flash, and can support flash management for either the boot PROM or the system
flash regions.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>PROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the boot PROM and able to
access the system flash.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>FLASH</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the system flash and able to
access the boot PROM.</entry>
<entry>redboot_FLASH.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM and able to access the
boot PROM.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
 
<sect2>
<title>Initial Installation</title>
<para>Unless a pre-programmed system flash module is available to be plugged into a new board,
RedBoot must be installed with the aid of a JTAG interface unit. To achieve this, the RAM mode
RedBoot must be loaded directly into RAM by JTAG and started, and then <emphasis>that</emphasis>
must be used to store the ROM mode RedBoot into the boot PROM.</para>
<para>These instructions assume that you have binary images of the RAM-based and boot PROM-based
RedBoot images available.</para>
<sect3>
<title>Preparing to program the board</title>
<para>If the board is to be programmed, whether via JTAG or RedBoot, some hardware settings need to
be changed:</para>
<itemizedlist>
<listitem>
<para>Jumper across ST18 on the board to allow write access to the boot PROM.</para>
</listitem>
<listitem>
<para>Set DIP switch S1-3 to OFF to allow RedBoot to write to the system flash.</para>
</listitem>
<listitem>
<para>Set the switch S5 (on the front of the board) to boot from whichever flash is
<emphasis>not</emphasis> being programmed. Note that the RedBoot image cannot access the flash from
which it is currently executing (it can only access the other flash).</para>
</listitem>
</itemizedlist>
<para>
The RedBoot binary image files should also be copied to the TFTP pickup area on the host providing
TFTP services if that is how RedBoot should pick up the images it is going to program into the
flash. Alternatively, the images can be passed by YMODEM over the serial link.
</para>
</sect3>
<sect3>
<title>Preparing to use the JTAG debugger</title>
<para>The JTAG debugger will also need setting up:</para>
<orderedlist>
<listitem><para>Install the JTAG debugger software (WICE103E) on a PC running Windows (WinNT is
probably the best choice for this) in &ldquo;C:/PanaX&rdquo;.</para>
</listitem>
<listitem><para>Install the Matsushita provided &ldquo;project&rdquo; into the
&ldquo;C:/Panax/wice103e/prj&rdquo; directory.</para>
</listitem>
<listitem><para>Install the RedBoot image files into the &ldquo;C:/Panax/wice103e/prj&rdquo;
directory under the names redboot.ram and redboot.prom.</para>
</listitem>
<listitem><para>Make sure the PC's BIOS has the parallel port set to full bidirectional
mode.</para>
</listitem>
<listitem><para>Connect the JTAG debugger to the PC's parallel port.</para>
</listitem>
<listitem><para>Connect the JTAG debugger to the board.</para>
</listitem>
<listitem><para>Set the switch on the front of the board to boot from &ldquo;boot
PROM&rdquo;.</para>
</listitem>
<listitem><para>Power up the JTAG debugger and then power up the board.</para>
</listitem>
<listitem><para>Connect the board's Debug Serial port to a computer by a null modem cable.</para>
</listitem>
<listitem><para>Start minicom or some other serial communication software and set for 115200 baud,
1-N-8 with hardware (RTS/CTS) flow control.</para>
</listitem>
</orderedlist>
</sect3>
<sect3>
<title>Loading the RAM-based RedBoot via JTAG</title>
<para>To perform the first half of the operation, the following steps should be followed:</para>
<orderedlist>
<listitem><para>Start the JTAG debugger software.</para>
</listitem>
<listitem>
<para>Run the following commands at the JTAG debugger's prompt to set up the MMU registers on the
CPU.</para>
<screen>
<userinput>ed 0xc0002000, 0x12000580</userinput>
 
<userinput>ed 0xd8c00100, 0x8000fe01</userinput>
<userinput>ed 0xd8c00200, 0x21111000</userinput>
<userinput>ed 0xd8c00204, 0x00100200</userinput>
<userinput>ed 0xd8c00208, 0x00000004</userinput>
 
<userinput>ed 0xd8c00110, 0x8400fe01</userinput>
<userinput>ed 0xd8c00210, 0x21111000</userinput>
<userinput>ed 0xd8c00214, 0x00100200</userinput>
<userinput>ed 0xd8c00218, 0x00000004</userinput>
 
<userinput>ed 0xd8c00120, 0x8600ff81</userinput>
<userinput>ed 0xd8c00220, 0x21111000</userinput>
<userinput>ed 0xd8c00224, 0x00100200</userinput>
<userinput>ed 0xd8c00228, 0x00000004</userinput>
 
<userinput>ed 0xd8c00130, 0x8680ff81</userinput>
<userinput>ed 0xd8c00230, 0x21111000</userinput>
<userinput>ed 0xd8c00234, 0x00100200</userinput>
<userinput>ed 0xd8c00238, 0x00000004</userinput>
 
<userinput>ed 0xd8c00140, 0x9800f801</userinput>
<userinput>ed 0xd8c00240, 0x00140000</userinput>
<userinput>ed 0xd8c00244, 0x11011100</userinput>
<userinput>ed 0xd8c00248, 0x01000001</userinput>
 
<userinput>ed 0xda000000, 0x55561645</userinput>
<userinput>ed 0xda000004, 0x000003c0</userinput>
<userinput>ed 0xda000008, 0x9000fe01</userinput>
<userinput>ed 0xda00000c, 0x9200fe01</userinput>
<userinput>ed 0xda000000, 0xa89b0654</userinput>
</screen>
</listitem>
<listitem>
<para>Run the following commands at the JTAG debugger's prompt to tell it what regions of the CPU's
address space it can access:</para>
<screen>
<userinput>ex 0x80000000,0x81ffffff,/mexram</userinput>
<userinput>ex 0x84000000,0x85ffffff,/mexram</userinput>
<userinput>ex 0x86000000,0x867fffff,/mexram</userinput>
<userinput>ex 0x86800000,0x87ffffff,/mexram</userinput>
<userinput>ex 0x8c000000,0x8cffffff,/mexram</userinput>
<userinput>ex 0x90000000,0x93ffffff,/mexram</userinput>
</screen>
</listitem>
<listitem><para>Instruct the debugger to load the RAM RedBoot image into RAM:</para>
<screen>
<userinput>_pc=90000000</userinput>
<userinput>u_pc</userinput>
<userinput>rd redboot.ram,90000000</userinput>
</screen>
</listitem>
<listitem><para>Load the boot PROM RedBoot into RAM:</para>
<screen>
<userinput>rd redboot.prom,91020000</userinput>
</screen>
</listitem>
<listitem><para>Start RedBoot in RAM:</para>
<screen>
<userinput>g</userinput>
</screen>
<para>Note that RedBoot may take some time to start up, as it will attempt to query a BOOTP or DHCP
server to try and automatically get an IP address for the board. Note, however, that it should send
a plus over the serial port immediately, and the 7-segment LEDs should display &ldquo;rh
8&rdquo;.</para>
</listitem>
</orderedlist>
</sect3>
<sect3>
<title>Loading the boot PROM-based RedBoot via the RAM mode RedBoot</title>
<para>Once the RAM mode RedBoot is up and running, it can be communicated with by way of the serial
port. Commands can now be entered directly to RedBoot for flashing the boot PROM.</para>
<orderedlist>
<listitem><para>Instruct RedBoot to initialise the boot PROM:</para>
<screen>
RedBoot> <userinput>fi init</userinput>
</screen>
</listitem>
<listitem><para>Write the previously loaded redboot.prom image into the boot PROM:</para>
<screen>
RedBoot> <userinput>fi write -f 0x80000000 -b 0x91020000 -l 0x00020000</userinput>
</screen>
</listitem>
<listitem><para>Check that RedBoot has written the image:</para>
<screen>
RedBoot> <userinput>dump -b 0x91020000</userinput>
RedBoot> <userinput>dump -b 0x80000000</userinput>
</screen>
<para>Barring the difference in address, the two dumps should be the same.</para>
</listitem>
<listitem><para>Close the JTAG software and power-cycle the board. The RedBoot banners should be
displayed again over the serial port, followed by the RedBoot prompt. The boot PROM-based RedBoot
will now be running.</para>
</listitem>
<listitem><para>Power off the board and unjumper ST18 to write-protect the contents of the boot
PROM. Then power the board back up.</para>
</listitem>
<listitem><para>Run the following command to initialise the system flash:</para>
<screen>
RedBoot> <userinput>fi init</userinput>
</screen>
<para>Then program the system flash based RedBoot into the system flash:</para>
<screen>
RedBoot> <userinput>load -r -b %{FREEMEMLO} redboot_FLASH.bin</userinput>
RedBoot> <userinput>fi write -f 0x84000000 -b %{FREEMEMLO} -l 0x00020000</userinput>
</screen>
<note>
<title>NOTE</title>
<para>RedBoot arranges the flashes on booting such that they always appear at the same addresses,
no matter which one was booted from.</para>
</note>
</listitem>
<listitem>
<para>A similar sequence of commands can be used to program the boot PROM when RedBoot has been
booted from an image stored in the system flash.
</para>
<screen>
RedBoot> <userinput>load -r -b %{FREEMEMLO} /tftpboot/redboot_ROM.bin</userinput>
RedBoot> <userinput>fi write -f 0x80000000 -b %{FREEMEMLO} -l 0x00020000</userinput>
</screen>
<para>See <xref linkend="Persistent-State-Flash"> for details on configuring the RedBoot in
general, and also <xref linkend="Flash-Image-System"> for more details on programming the system
flash.</para>
</listitem>
</orderedlist>
</sect3>
</sect2>
<sect2>
<title>Additional Commands</title>
<para>The <command>exec</command> command which allows the loading and execution of
Linux kernels, is supported for this architecture (see <xref linkend="executing-programs">). The
<command>exec</command> parameters used for ASB2305 board are:</para>
<variablelist>
<varlistentry><term>
-w <replaceable>&lt;time></replaceable></term>
<listitem><para>Wait time in seconds before starting kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term><replaceable>&lt;addr></replaceable></term>
<listitem><para>Kernel entry point, defaulting to the entry point of the last image
loaded</para></listitem></varlistentry>
</variablelist>
<para>The parameter string is stored in the on-chip memory at location 0x8C001000, and is prefixed
by &ldquo;cmdline:&rdquo; if it was supplied.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the ASB2305 board.</para>
<note>
<title>NOTE</title>
<para>The regions mapped between 0x80000000-0x9FFFFFFF are cached by the CPU. However, all those
regions can be accessed uncached by adding 0x20000000 to the address.</para>
</note>
<programlisting>
Physical Address Range Description
----------------------- -----------
0x80000000 - 0x9FFFFFFF Cached Region
0x80000000 - 0x81FFFFFF Boot PROM
0x84000000 - 0x85FFFFFF System Flash
0x86000000 - 0x86007FFF 64Kbit Sys Config EEPROM
0x86F90000 - 0x86F90003 4x 7-segment LEDs
0x86FA0000 - 0x86FA0003 Software DIP Switches
0x86FB0000 - 0x86FB001F PC16550 Debug Serial Port
0x8C000000 - 0x8FFFFFFF On-Chip Memory (repeated 16Kb SRAM)
0x90000000 - 0x93FFFFFF SDRAM
0x98000000 - 0x9BFFFFFF Paged PCI Memory Space (64Mb)
0x9C000000 - 0x9DFFFFFF PCI Local SRAM (32Mb)
0x9E000000 - 0x9E03FFFF PCI I/O Space
0x9E040000 - 0x9E0400FF AM33-PCI Bridge Registers
0x9FFFFFF4 - 0x9FFFFFF7 PCI Memory Page Register
0x9FFFFFF8 - 0x9FFFFFFF PCI Config Registers
0xA0000000 - 0xBFFFFFFF Uncached Mirror Region
0xC0000000 - 0xDFFFFFFF CPU Control Registers
</programlisting>
<para>The ASB2305 HAL makes use of the on-chip memory in the following way:</para>
<programlisting>
0x8C000000 - 0x8C0000FF hal_vsr_table
0x8C000100 - 0x8C0001FF hal_virtual_vector_table
0x8C001000 - Linux command line (RedBoot exec command)
- 0x8C003FFF Emergency DoubleFault Exception Stack
</programlisting>
<para>Currently the CPU's interrupt table lies at the beginning of the RedBoot image, which must
therefore be aligned to a 0xFF000000 mask.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=asb2305
export ARCH_DIR=mn10300
export PLATFORM_DIR=asb2305
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<!-- *************************** ARM ******************* -->
 
<?Pub _newpage>
<sect1 id="e7t">
<title>ARM/ARM7 ARM Evaluator7T</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>ARM Evaluator7T</primary><secondary>installing and
testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>ARM Evaluator7T</secondary></indexterm>RedBoot supports
both serial ports for communication and downloads. The default serial port
settings are 38400,8,N,1.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from flash address 0x20000, with
ARM Boot Monitor in flash boot sector.</entry>
<entry>redboot_ROMA.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation</title>
<para>RedBoot is installed using the on-board boot environment. See the user
manual for full details.</para>
</sect2>
<sect2>
<title>Quick download instructions</title>
<para>Here are quick start instructions for downloading the prebuilt Redboot
image:</para>
<itemizedlist>
<listitem><para>Boot the board and press ENTER:</para>
<screen>
 
ARM Evaluator7T Boot Monitor PreRelease 1.00
Press ENTER within 2 seconds to stop autoboot
Boot: </screen>
</listitem>
<listitem><para>Erase the part of the flash where RedBoot will get programmed:
</para>
<screen> Boot: <userinput>flasherase 01820000 10000</userinput></screen>
</listitem>
<listitem><para>Prepare to download the UU-encoded version of the RedBoot
image:</para>
<screen> Boot: <userinput>download 10000</userinput>
Ready to download. Use 'transmit' option on terminal emulator to download file.
</screen>
</listitem>
<listitem><para>Either use ASCII transmit option in the terminal emulator,
or on Linux, simply cat the file to the serial port:<screen> $ <userinput>
cat redboot.UU > /dev/ttyS0</userinput></screen>When complete, you should
see:<screen> Loaded file redboot.bin at address 000100000, size = 41960
Boot:</screen></para>
</listitem>
<listitem><para>Program the flash:<screen> Boot: <userinput>flashwrite 01820000 10000 10000
</userinput></screen></para>
</listitem>
<listitem><para>And verify that the module is available:<screen> Boot: <userinput>
rommodules</userinput>
Header Base Limit
018057c8 01800000 018059e7 BootStrapLoader v1.0 Apr 27 2000 10:33:58
01828f24 01820000 0182a3e8 RedBoot Apr 5 2001</screen></para>
</listitem>
<listitem><para>Reboot the board and you should see the RedBoot banner.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the E7T board. <note><title>
NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note> <programlisting>Physical Address Range C B Description
----------------------- - - -----------
0x00000000 - 0x0007ffff Y N SDRAM
0x03ff0000 - 0x03ffffff N N Microcontroller registers
0x01820000 - 0x0187ffff N N System flash (mirrored)</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=e7t
export ARCH_DIR=arm
export PLATFORM_DIR=e7t
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="integrator">
<title>ARM/ARM7+ARM9 ARM Integrator</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>ARM Integrator</primary><secondary>installing and
testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>ARM Integrator</secondary></indexterm>RedBoot supports
both serial ports for communication and downloads. The default serial port
settings are 38400,8,N,1.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector.</entry>
<entry>redboot_ROMRAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
 
<sect2>
<title>Initial Installation</title>
<para>RedBoot is installed using the on-board bootPROM environment. See the user
manual for full details.</para>
</sect2>
<sect2>
<title>Quick download instructions</title>
<para>Here are quick start instructions for downloading the prebuilt Redboot
image:</para>
<itemizedlist>
<listitem><para>Set DIP switch S1[1] to the ON position and reset or
power the board up. You will see the bootPROM startup message on
serial port A (J14):</para>
<screen>
Initialising...
 
 
ARM bootPROM [Version 1.3] Rebuilt on Jun 26 2001 at 22:04:10
Running on a Integrator Evaluation Board
Board Revision V1.0, ARM966E-S Processor
Memory Size is 16MBytes, Flash Size is 32MBytes
Copyright (c) ARM Limited 1999 - 2001. All rights reserved.
Board designed by ARM Limited
Hardware support provided at http://www.arm.com/
For help on the available commands type ? or h
boot Monitor >
</screen>
</listitem>
<listitem>
<para>Issue the FLASH ROM load command:
</para>
<screen>
boot Monitor > <userinput>L</userinput>
Load Motorola S-Records into flash
 
Deleting Image 0
 
The S-Record loader only accepts input on the serial port.
Type Ctrl/C to exit loader.
</screen>
</listitem>
<listitem><para>Either use the ASCII transmit option in the terminal emulator,
or on Linux, simply cat the file to the serial port:
</para>
<screen>
$ <userinput>cat redboot.srec > /dev/ttyS0</userinput>
</screen>
<para>
When complete, type Ctrl-C and you should see something similar to:
</para>
<screen>
................................
................................
....................
Downloaded 5,394 records in 81 seconds.
 
Overwritten block/s
0
 
boot Monitor >
</screen>
</listitem>
<listitem><para>Set DIP switch S1[1] to the OFF position and reboot
the board and you should see the RedBoot banner.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the Integrator board. <note><title>
NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note>
<programlisting>
 
ARM7TDMI
--------
 
Physical Address Range C B Description
----------------------- - - -----------
0x00000000 - 0x0007ffff N N SSRAM
0x00080000 - 0x0fffffff N N SDRAM (depends on part fitted)
0x10000000 - 0x1fffffff N N System control and peripheral registers
0x20000000 - 0x23ffffff N N Boot ROM (contains boot Monitor)
0x24000000 - 0x27ffffff N N FLASH ROM (contains RedBoot)
0x28000000 - 0x2bffffff N N SSRAM echo area
0x40000000 - 0x5fffffff N N PCI Memory access windows
0x60000000 - 0x60ffffff N N PCI IO access window
0x61000000 - 0x61ffffff N N PCI config space window
0x62000000 - 0x6200ffff N N PCI bridge register window
0x80000000 - 0x8fffffff N N SDRAM echo area (used for PCI accesses)
 
 
ARM966E
-------
 
Physical Address Range C B Description
----------------------- - - -----------
0x00000000 - 0x000fffff N N SSRAM
0x00100000 - 0x0fffffff N N SDRAM (depends on part fitted)
0x10000000 - 0x1fffffff N N System control and peripheral registers
0x20000000 - 0x23ffffff N N Boot ROM (contains boot Monitor)
0x24000000 - 0x27ffffff N N FLASH ROM (contains RedBoot)
0x28000000 - 0x2bffffff N N SSRAM echo area
0x40000000 - 0x5fffffff N N PCI Memory access windows
0x60000000 - 0x60ffffff N N PCI IO access window
0x61000000 - 0x61ffffff N N PCI config space window
0x62000000 - 0x6200ffff N N PCI bridge register window
0x80000000 - 0x8fffffff N N SDRAM echo area (used for PCI accesses)
 
</programlisting>
</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=integrator
export ARCH_DIR=arm
export PLATFORM_DIR=integrator
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="pid">
<title>ARM/ARM7+ARM9 ARM PID Board and EPI Dev7+Dev9</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>ARM ARM7 PID, Dev7 and Dev9</primary><secondary>
installing and testing</secondary></indexterm><indexterm><primary>installing
and testing</primary><secondary>ARM ARM7 PID, Dev7 and Dev9</secondary></indexterm>RedBoot
uses either of the serial ports. The default serial port settings are 38400,8,N,1.
Management of onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
 
<sect2>
<title>Initial Installation Method </title>
<para>Device programmer is used to program socketed flash parts with ROM version
of RedBoot. </para>
<para>Alternatively, to install RedBoot on a target that already has eCos
GDB stubs, download the RAM mode image of RedBoot and run it. Initialize the
flash image directory: <command>fis init</command> Then
download the ROM version of RedBoot and program it into flash: <screen>
RedBoot> <userinput>load -b %{FREEMEMLO} -m ymodem</userinput>
RedBoot> <userinput>fi cr RedBoot</userinput>
</screen></para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the PID board. <programlisting>
Physical Address Range Description
----------------------- -----------
0x00000000 - 0x0007ffff DRAM
0x04000000 - 0x04080000 flash
0x08000000 - 0x09ffffff ASB Expansion
0x0a000000 - 0x0bffffff APB Reference Peripheral
0x0c000000 - 0x0fffffff NISA Serial, Parallel and PC Card ports </programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=pid
export ARCH_DIR=arm
export PLATFORM_DIR=pid
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2></sect1>
 
<?Pub _newpage>
<sect1 id="at91">
<title>ARM/ARM7 Atmel AT91 Evaluation Board (EB40)</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Atmel AT91/EB40</primary>
<secondary>installing and testing</secondary></indexterm><indexterm><primary>
installing and testing</primary><secondary>Atmel AT91/EB40
</secondary></indexterm>RedBoot supports both serial ports.
The default serial port settings are 38400,8,N,1. RedBoot
also supports minimal flash management on the EB40.
However, since the flash device (AT29LV1024) is so small (only the upper 64K is
available for general use), only the simple flash write command 'fis
write' is supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector.</entry>
<entry>redboot_ROMRAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
 
<sect2>
<title>Initial Installation Method </title>
<para>
This development board comes with ARM's debug tool, Angel, installed in flash.
At this time, Angel will not be replaced. Rather, RedBoot will be placed in
the alternate half of flash. Switch SW1 is used which monitor to boot. Selecting
SW1 to "lower mem" will choose Angel. Select SW1 to "Upper mem" for RedBoot once
it has been installed.
</para>
<para>
Set SW1 to "lower mem" and connect serial port A to a host computer. Using GDB
from the host and Angel on the board, download the RAM mode image of RedBoot
to the board. SW1 should then be set to "upper mem" just before starting RedBoot using
the 'cont' command. Once RedBoot is started, the Angel session must be interrupted (on
Linux this can be done using ^Z). Follow this by connecting to the board using
minicom at 38400-8N1. At this point, RedBoot will be running on the board in
RAM. Now, download the ROMRAM mode image and program it to flash.
<screen>
<userinput>arm-elf-gdb redboot_RAM.elf</userinput>
(gdb) <userinput>tar rdi s=/dev/ttyS0</userinput>
Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.5) for
AT91EB40 (2.00)
Angel Debug Monitor rebuilt on Apr 07 2000 at 12:40:31
Serial Rate: 9600
Connected to ARM RDI target.
(gdb) <userinput>set $cpsr=0xd3</userinput>
(gdb) <userinput>load</userinput>
Loading section .rom_vectors, size 0x40 lma 0x2020000
Loading section .text, size 0x7fd8 lma 0x2020040
Loading section .rodata, size 0x15a0 lma 0x2028018
Loading section .data, size 0x2e4 lma 0x20295b8
Start address 0x2020040 , load size 39068
Transfer rate: 6250 bits/sec, 500 bytes/write.
</screen>
At this point, set SW1 to "upper mem".
<screen>
(gdb) <userinput>cont</userinput>
Continuing.
</screen>
At this point, suspend the GDB session (use Ctrl-Z) and start a
terminal emulator:
<screen>
RedBoot> <userinput>version</userinput>
 
RedBoot(tm) bootstrap and debug environment [RAM]
Non-certified release, version UNKNOWN - built 14:09:27, Jul 20 2001
 
Platform: Atmel AT91/EB40 (ARM7TDMI)
Copyright (C) 2000, 2001, Red Hat, Inc.
 
RAM: 0x02000000-0x02080000, 0x020116d8-0x0207fd00 available
FLASH: 0x01010000 - 0x01020000, 256 blocks of 0x00000100 bytes each.
 
RedBoot> <userinput>load -m ymodem -b %{FREEMEMLO}</userinput>
</screen>
Use minicom to send the file redboot_ROMRAM.srec via YModem.
<screen>
RedBoot> <userinput>fi wr -f 0x01010000 -b %{FREEMEMLO} -l 0xe100</userinput>
</screen>
Press the "reset" pushbutton and RedBoot
should come up on the board.
</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>This processor has no MMU, so the only memory map is for physical addresses.
<programlisting>
Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x00000fff On-chip SRAM
0x01000000 - 0x0101ffff Flash
0x02000000 - 0x0207ffff RAM
0xffe00000 - 0xffffffff I/O registers
 
The flash based RedBoot image occupies virtual addresses 0x01010000 - 0x0101dfff
</programlisting></para>
 
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=eb40
export ARCH_DIR=arm
export PLATFORM_DIR=at91
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
 
<?Pub _newpage>
<sect1 id="edb7xxx">
<title>ARM/ARM7 Cirrus Logic EP7xxx (EDB7211, EDB7212, EDB7312) </title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Cirrus Logic EP7xxx (EDB7211, EDB7212, EDB7312)</primary>
<secondary>installing and testing</secondary></indexterm><indexterm><primary>
installing and testing</primary><secondary>Cirrus Logic EP7xxx (EDB7211, EDB7212, EDB7312)
</secondary></indexterm>RedBoot supports both serial ports on the board and
the ethernet port. The default serial port settings are 38400,8,N,1. RedBoot
also supports flash management on the EDB7xxx for the NOR flash
only.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector (EDB7312 only).</entry>
<entry>redboot_ROMRAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>A Windows or Linux utility is used to program flash using serial port
#1 via on-chip programming firmware. See board documentation for details on
in situ flash programming. </para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>The MMU page tables and LCD display buffer, if enabled, are located
at the end of DRAM. <note><title>NOTE
</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>
Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x01ffffff NOR Flash (EDB7211, EDB7212)
0x00000000 - 0x00ffffff NOR Flash (EDB7312)
0x10000000 - 0x11ffffff NAND Flash
0x20000000 - 0x2fffffff Expansion 2
0x30000000 - 0x3fffffff Expansion 3
0x40000000 - 0x4fffffff PCMCIA 0
0x50000000 - 0x5fffffff PCMCIA 1
0x60000000 - 0x600007ff On-chip SRAM
0x80000000 - 0x8fffffff I/O registers
0xc0000000 - 0xc1ffffff DRAM (EDB7211, EDB7212)
0xc0000000 - 0xc0ffffff DRAM (EDB7312)
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x01ffffff Y Y DRAM
0x00000000 - 0x00fcffff Y Y DRAM (EDB7312)
0x20000000 - 0x2fffffff N N Expansion 2
0x30000000 - 0x3fffffff N N Expansion 3
0x40000000 - 0x4fffffff N N PCMCIA 0
0x50000000 - 0x5fffffff N N PCMCIA 1
0x60000000 - 0x600007ff Y Y On-chip SRAM
0x80000000 - 0x8fffffff N N I/O registers
0xc0000000 - 0xc001ffff N Y LCD buffer (if configured)
0xe0000000 - 0xe1ffffff Y Y NOR Flash (EDB7211, EDB7212)
0xe0000000 - 0xe0ffffff Y Y NOR Flash (EDB7312)
0xf0000000 - 0xf1ffffff Y Y NAND Flash
 
The flash based RedBoot image occupies virtual addresses 0xe0000000 - 0xe003ffff.
</programlisting></para>
</sect2>
<sect2>
<title>Platform Resource Usage</title>
<para>The EP7xxx timer #2 is used as a polled timer to provide timeout support
for network and XModem file transfers.</para>
</sect2><sect2>
 
<title>Rebuilding RedBoot</title>
 
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=edb7211
export TARGET=edb7212
export TARGET=edb7312
export ARCH_DIR=arm
export PLATFORM_DIR=edb7xxx
</programlisting>
 
Use one of the TARGET settings only.
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="aaed2000">
<title>ARM/ARM9 Agilent AAED2000</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Agilent AAED2000 ARM9 (aaed)</primary>
<secondary>installing and testing</secondary></indexterm><indexterm><primary>
installing and testing</primary><secondary>Agilent AAED2000 ARM9 (aaed)
</secondary></indexterm>RedBoot supports the serial and ethernet ports
on the board. The default serial port settings are 38400,8,N,1.
RedBoot also supports flash management on the AAED2000.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector.</entry>
<entry>redboot_primary_ROMRAM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_primary_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
 
<sect2>
<title>Initial Installation Method </title>
<para>It is possible to install RedBoot in one of two ways. Either as
the primary bootmonitor on the board (installed to blocks 0-1 of the
flash) or as the secondary bootmonitor on the board (installed to
blocks 1-2 of the flash).</para>
 
<para>Presently, only the former method is supported.</para>
<!-- Nuke the above line if uncommenting this block
<para>When installed as the secondary bootmonitor, the ARM bootmonitor
remains in flash and auto-executes RedBoot (but only when RedBoot is
smaller than 128KB - which means it cannot include the LCD driver).
It is of crucial importance that no RedBoot configured to be
primary bootmonitor is executed on a board where RedBoot is actually
supposed to be the secondary bootmonitor since it may cause corruption
of the flash. Installing RedBoot as the primary booter is
adviced.</para>
-->
 
<sect3><title>RedBoot as Primary Bootmonitor</title>
 
<para>RedBoot is installed in flash using the on-board ARM Boot
Monitor.</para>
<para>Boot the board while pressing SPACE. This should bring up the
Boot Monitor:
<screen>ARM bootPROM [Version 1.3] Rebuilt on Jul 16 2001 at 16:21:36
Running on a P920 board Evaluation Board
Board Revision V1.0, ARM920T processor Processor
Memory Size is 32MBytes, Flash Size is 32MBytes
Copyright (c) ARM Limited 1999 - 2001. All rights reserved.
Board designed by ARM Limited
Hardware support provided at http://www.arm.com/
For help on the available commands type ? or h
boot Monitor >
</screen>
 
Download the RAM mode image of RedBoot configured as a primary
bootmonitor using the ARM bootmonitor's SREC-download command:
 
<screen>boot Monitor &gt; <userinput>m</userinput>
Load Motorola S-Record image into memory and execute it
The S-Record loader only accepts input on the serial port.
Record addresses must be between 0x00008000 and 0x01E0F510.
Type Ctrl/C to exit loader.
</screen>
 
Use the terminal emulator's ASCII upload command, or (on Linux) simply
cat the file to the serial port:
 
<screen>$ <userinput>cat redboot_primary_RAM/redboot.srec &gt;/dev/ttyS1</userinput>
</screen>
 
You should see RedBoot start up:
 
<screen>FLASH configuration checksum error or invalid key
Ethernet eth0: MAC address 00:30:d3:03:04:99
IP: 192.168.42.111, Default server: 192.168.42.3
RedBoot(tm) bootstrap and debug environment [RAM]
Non-certified release, version UNKNOWN - built 13:15:40, Nov 9 2001
Platform: AAED2000 system (ARM9) [Primary]
Copyright (C) 2000, 2001, Red Hat, Inc.
RAM: 0x00000000-0x01f80000, 0x0006f208-0x01f51000 available
FLASH: 0x60000000 - 0x62000000, 256 blocks of 0x00020000 bytes each.
RedBoot></screen>
 
As can be seen from the output above, the network has been configured
to give the board an IP address and information about the default
server. If things are not set up on your network, you can still
continue, but use the Y-modem download method when loading the RedBoot
ROMRAM mode image.
 
Now initialize RedBoot's FIS:
 
<screen>RedBoot&gt; <userinput>fis init</userinput>
About to initialize [format] FLASH image system - continue (y/n)? <userinput>y</userinput>
*** Initialize FLASH Image System
Warning: device contents not erased, some blocks may not be usable
... Erase from 0x61fe0000-0x62000000: .
... Program from 0x01f5f000-0x01f5f300 at 0x61fe0000: .
</screen>
 
Download the ROMRAM mode image of RedBoot via ethernet:
 
<screen>RedBoot&gt; <userinput>load -b %{FREEMEMLO} redboot_primary_ROMRAM/redboot.srec</userinput>
</screen>
 
or using serial Y-modem protocol:
 
<screen>RedBoot&gt; <userinput>load -mode ymodem -b %{FREEMEMLO}</userinput>
</screen>
 
(Use the terminal emulator's Y-modem upload command to send the file
<filename>redboot_primary_ROMRAM/redboot.srec</filename>.)
 
When the image has been downloaded, program it into flash:
 
<screen>Address offset = 0x00ff8000
Entry point: 0x00008040, address range: 0x00008000-0x0002da80
RedBoot&gt; <userinput>fi cr RedBoot</userinput>
An image named 'RedBoot' exists - continue (y/n)? <userinput>y</userinput>
* CAUTION * about to program 'RedBoot'
at 0x60000000..0x6003ffff from 0x00100000 - continue (y/n)? <userinput>y</userinput>
... Erase from 0x60000000-0x60040000: ..
... Program from 0x00100000-0x00140000 at 0x60000000: ..
... Erase from 0x61fe0000-0x62000000: .
... Program from 0x01f5f000-0x01f7f000 at 0x61fe0000: .
</screen>
 
Now reset the board. You should see the RedBoot banner.</para>
 
</sect3>
 
<!--
<sect3><title>RedBoot as Secondary Bootmonitor</title>
 
<para>RedBoot is installed in flash using the on-board ARM Boot
Monitor.</para>
<para>Boot the board while pressing SPACE. This should bring up the
Boot Monitor:
<screen>ARM bootPROM [Version 1.3] Rebuilt on Jul 16 2001 at 16:21:36
Running on a P920 board Evaluation Board
Board Revision V1.0, ARM920T processor Processor
Memory Size is 32MBytes, Flash Size is 32MBytes
Copyright (c) ARM Limited 1999 - 2001. All rights reserved.
Board designed by ARM Limited
Hardware support provided at http://www.arm.com/
For help on the available commands type ? or h
boot Monitor >
</screen>
 
Download the RAM mode image of RedBoot configured as a secondary
bootmonitor using the ARM bootmonitor's SREC-download command:
 
<screen>boot Monitor &gt; <userinput>m</userinput>
Load Motorola S-Record image into memory and execute it
The S-Record loader only accepts input on the serial port.
Record addresses must be between 0x00008000 and 0x01E0F510.
Type Ctrl/C to exit loader.
</screen>
 
Use the terminal emulator's ASCII upload command, or (on Linux) simply
cat the file to the serial port:
 
<screen>$ <userinput>cat redboot_secondary_RAM.srec &gt;/dev/ttyS1</userinput>
</screen>
 
You should see RedBoot start up:
 
<screen>FLASH configuration checksum error or invalid key
Ethernet eth0: MAC address 00:30:d3:03:04:99
IP: 192.168.42.111, Default server: 192.168.42.3
 
RedBoot(tm) bootstrap and debug environment [RAM]
Non-certified release, version UNKNOWN - built 12:31:13, Nov 9 2001
 
Platform: AAED2000 system (ARM9) [Secondary]
Copyright (C) 2000, 2001, Red Hat, Inc.
 
RAM: 0x00000000-0x01f80000, 0x00063568-0x01f51000 available
FLASH: 0x60000000 - 0x62000000, 256 blocks of 0x00020000 bytes each.
</screen>
 
As can be seen from the output above, the network has been configured
to give the board an IP address and information about the default
server. If things are not set up on your network, you can still
continue, but use the Y-modem download method when loading the RedBoot
ROMRAM mode image.
 
Next step is to erase all of the flash, except where the ARM booter resides:
 
<screen>RedBoot&gt; <userinput>fi erase -f 0x60020000 -l 0x01fe0000</userinput>
... Erase from 0x60020000-0x62000000: ..........................................
................................................................................
................................................................................
.....................................................
</screen>
 
Then initialize RedBoot's FIS:
 
<screen>RedBoot&gt; <userinput>fi init</userinput>
About to initialize [format] FLASH image system - continue (y/n)? <userinput>y</userinput>
*** Initialize FLASH Image System
Warning: device contents not erased, some blocks may not be usable
... Erase from 0x61fc0000-0x61fe0000: .
... Program from 0x01fdf000-0x01fff000 at 0x61fc0000: .
</screen>
 
Download the ROMRAM mode RedBoot image via ethernet:
 
<screen>RedBoot&gt; <userinput>load -raw -b %{FREEMEMLO} redboot_secondary_ROMRAM.arm.bin</userinput>
</screen>
 
or using serial Y-modem protocol:
 
<screen>RedBoot&gt; <userinput>load -raw -mode ymodem -b %{FREEMEMLO}</userinput>
</screen>
 
(Use the terminal emulator's Y-modem upload command to send the file
<filename>redboot_secondary_ROMRAM.arm.bin</filename>.)
 
When the image has been downloaded, program it into flash:
 
<screen>RedBoot&gt; <userinput>fi cr RedBoot</userinput>
An image named 'RedBoot' exists - continue (y/n)? <userinput>y</userinput>
* CAUTION * about to program 'RedBoot'
at 0x60020000..0x6005ffff from 0x00100000 - continue (y/n)? <userinput>y</userinput>
... Erase from 0x60020000-0x60060000: ..
... Program from 0x00100000-0x00140000 at 0x60020000: ..
... Erase from 0x61fc0000-0x61fe0000: .
... Program from 0x01f5f000-0x01f7f000 at 0x61fc0000: .
</screen>
 
Now reset the board. You might see the ARM Monitor complain:
 
<screen>Failed to boot from flash.
The ARM Boot Monitor SIB can not be found.
Press any key to continue.
</screen>
 
This is due to due to the flash having been erased. Press a key, and
execute the "validate flash contents" command:
 
<screen>boot Monitor &gt; <userinput>v</userinput>
 
There are 254 128KByte blocks of Application Flash:
 
No images found!
================
 
System Information Blocks
=========================
Address Owner Size Idx Rev
~~~~~~~ ~~~~~ ~~~~ ~~~ ~~~
0x05FE0000 ARM Boot Monitor 312 0 0
 
 
Blocks of unknown type
======================
Block Size Footer Type
~~~~~ ~~~~ ~~~~~~~~~~~
252 1 0x52420000
boot Monitor &gt;
</screen>
 
This causes the last block of the flash to be initialized with the ARM
Boot Monitor ID, necessary for the Monitor to work properly. When
resetting the board now, it should automatically start RedBoot. If you
ever need to get into the ARM Boot Monitor again, reset the board
while pressing the SPACE key.
 
</para></sect3>
-->
 
</sect2>
 
<sect2>
<title>Special RedBoot Commands </title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels,
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the AAED2000 are:</para>
<variablelist><varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Location Linux kernel was loaded to</para></listitem></varlistentry>
<varlistentry><term>
-l <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term>-r <replaceable>&lt;addr></replaceable></term>
<listitem><para>'initrd' ramdisk location</para></listitem></varlistentry>
<varlistentry><term>-s <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of initrd ramdisk</para></listitem></varlistentry>
</variablelist>
 
<para>The parameters for kernel image base and size are automatically
set after a load operation. So one way of starting the kernel would
be:
 
<screen>RedBoot&gt; <userinput>load -r -b 0x100000 zImage</userinput>
Raw file loaded 0x00100000-0x001a3d6c
RedBoot&gt; exec -c "console=ttyAC0,38400"
Using base address 0x00100000 and length 0x000a3d6c
Uncompressing Linux.....
</screen>
 
An image could also be put in flash and started directly:
 
<screen>RedBoot&gt; <userinput>exec -b 0x60040000 -l 0xc0000 -c "console=ttyAC0,38400"</userinput>
Uncompressing Linux.....
</screen>
 
</para>
 
</sect2>
<sect2>
<title>Memory Maps </title>
<para>The MMU page tables are located at 0x4000. <note><title>NOTE
</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x01ffffff Flash
0x10000000 - 0x100fffff Ethernet
0x30000000 - 0x300fffff Board registers
0x40000000 - 0x4fffffff PCMCIA Slot (0)
0x50000000 - 0x5fffffff Compact Flash Slot (1)
0x80000000 - 0x800037ff I/O registers
0xb0060000 - 0xb00fffff On-chip SRAM
0xf0000000 - 0xfd3fffff SDRAM
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x01f7ffff Y Y SDRAM
0x01f80000 - 0x01ffffff Y Y SDRAM (used for LCD frame buffer)
0x10000000 - 0x100fffff N N Ethernet
0x30000000 - 0x300fffff N N Board registers
0x40000000 - 0x4fffffff N N PCMCIA Slot (0)
0x50000000 - 0x5fffffff N N Compact Flash Slot (1)
0x60000000 - 0x61ffffff N N Flash
0x80000000 - 0x800037ff N N I/O registers
0xf0000000 - 0xffffffff N N SDRAM (uncached)
 
</programlisting></para>
 
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=aaed
export ARCH_DIR=arm
export PLATFORM_DIR=arm9/aaed2000
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="excaliburarm9">
<title>ARM/ARM9 Altera Excalibur</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Altera Excalibur ARM9 (excalibur_arm9)</primary>
<secondary>installing and testing</secondary></indexterm><indexterm><primary>
installing and testing</primary><secondary>Altera Excalibur ARM9 (excalibur_arm9)
</secondary></indexterm>RedBoot supports the serial port labelled
P2 on the board. The default serial port settings are 57600,8,N,1. RedBoot
also supports flash management on the Excalibur.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector.</entry>
<entry>redboot_ROMRAM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
<row>
<entry>REDBOOT</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from top of RAM, but contained in
the board's flash boot sector.</entry>
<entry>redboot_REDBOOT.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
<note> <title>NOTE</title>
<para>RedBoot is currently hardwired to use a 128MB SDRAM SIMM module.
</para>
</note>
</sect2>
 
<sect2>
<title>Initial Installation Method </title>
<para>A Windows utility
(<application>exc_flash_programmer.exe</application>) is used to
program flash using the ByteBlasterMV JTAG unit.
See board documentation for details on
in situ flash programming. </para>
<para>For ethernet to work (under Linux) the following jumper
settings should be used on a REV 2 board: <literallayout>
SW2-9 : OFF
U179 : 2-3
JP14-18 : OPEN
JP40-41 : 2-3
JP51-55 : 2-3
</literallayout>
</para>
</sect2>
<sect2>
<title>Flash management</title>
 
<para>The ROMRAM and REDBOOT configurations supported on this platform
differ only in the memory layout (ROMRAM configuration runs RedBoot from
0x00008000 while REDBOOT configuration runs RedBoot from 0x07f80000). The
REDBOOT configuration allows applications to be loaded and run from
address 0x00008000.</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels,
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the Excalibur are:</para>
<variablelist><varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Location Linux kernel was loaded to</para></listitem></varlistentry>
<varlistentry><term>
-l <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term>-r <replaceable>&lt;addr></replaceable></term>
<listitem><para>'initrd' ramdisk location</para></listitem></varlistentry>
<varlistentry><term>-s <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of initrd ramdisk</para></listitem></varlistentry>
</variablelist>
 
<para>The parameters for kernel image base and size are automatically
set after a load operation. So one way of starting the kernel would
be:
 
<screen>RedBoot&gt; <userinput>load -r -b 0x100000 zImage</userinput>
Raw file loaded 0x00100000-0x001a3d6c
RedBoot&gt; <userinput>exec -c "console=ttyUA0,57600"</userinput>
Using base address 0x00100000 and length 0x000a3d6c
Uncompressing Linux.....
</screen>
 
An image could also be put in flash and started directly:
 
<screen>RedBoot&gt; <userinput>exec -b 0x40400000 -l 0xc0000 -c "console=ttyUA0,57600"</userinput>
Uncompressing Linux.....
</screen>
 
</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>The MMU page tables are located at 0x4000. <note><title>NOTE
</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x07ffffff SDRAM
0x08000000 - 0x0805ffff On-chip SRAM
0x40000000 - 0x40ffffff Flash
0x7fffc000 - 0x7fffffff I/O registers
0x80000000 - 0x8001ffff PLD
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x07ffffff Y Y SDRAM
0x08000000 - 0x0805ffff Y Y On-chip SRAM
0x40000000 - 0x403fffff N Y Flash
0x7fffc000 - 0x7fffffff N N I/O registers
0x80000000 - 0x8001ffff N N PLD
</programlisting></para>
 
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=excalibur_arm9
export ARCH_DIR=arm
export PLATFORM_DIR=arm9/excalibur
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="ebsa285">
<title>ARM/StrongARM(SA110) Intel EBSA 285</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Intel StrongArm EBSA 285</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Intel StrongArm EBSA 285</secondary></indexterm>RedBoot
uses the single EBSA-285 serial port. The default serial port settings are
38400,8,N,1. If the EBSA-285 is used as a host on a PCI backplane, ethernet
is supported using an Intel PRO/100+ ethernet adapter. Management of
onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>A linux application is used to program the flash over the PCI bus. Sources
and build instructions for this utility are located in the RedBoot sources
in: <filename class="directory">packages/hal/arm/ebsa285/current/support/linux/safl_util</filename>
</para>
</sect2>
<sect2>
<title>Communication Channels </title>
<para>Serial, Intel PRO 10/100+ 82559 PCI ethernet card.</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>Physical and virtual mapping are mapped one to one on the EBSA-285 using
a first level page table located at address 0x4000. No second level tables
are used. <note><title>NOTE </title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x01ffffff Y Y SDRAM
0x40000000 - 0x400fffff N N 21285 Registers
0x41000000 - 0x413fffff Y N flash
0x42000000 - 0x420fffff N N 21285 CSR Space
0x50000000 - 0x50ffffff Y Y Cache Clean
0x78000000 - 0x78ffffff N N Outbound Write Flush
0x79000000 - 0x7c0fffff N N PCI IACK/Config/IO
0x80000000 - 0xffffffff N Y PCI Memory </programlisting></para>
</sect2>
<sect2>
<title>Platform Resource Usage </title>
<para>Timer3 is used as a polled timer to provide timeout support for networking
and XModem file transfers.</para>
</sect2>
<!--
<sect2>
<title>Building eCos Test Cases to run with old RedBoots</title>
<para>If using older versions of RedBoot, the default configuration for
EBSA-285 will send diagnostic output to the serial line only, not over an ethernet
connection. To allow eCos programs to use RedBoot to channel diagnostic output to
GDB whether connected by net or serial, enable the configuration option <programlisting>
CYGSEM_HAL_VIRTUAL_VECTOR_DIAG
"Do diagnostic IO via virtual vector table"</programlisting> located here
in the common HAL configuration tree: <programlisting>"eCos HAL"
"ROM monitor support"
"Enable use of virtual vector calling interface"
"Do diagnostic IO via virtual vector table"</programlisting>Other
than that, no special configuration is required to use RedBoot. </para>
<para>If you have been using built-in stubs to acquire support for thread-aware
debugging, you can still do that, but you must only use the serial device
for GDB connection and you must not enable the option mentioned above. However,
it is no longer necessary to do that to get thread-awareness; RedBoot is thread
aware.</para>
</sect2>
-->
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=ebsa285
export ARCH_DIR=arm
export PLATFORM_DIR=ebsa285
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="brutus">
<title>ARM/StrongARM(SA1100) Intel Brutus</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Intel-SA1100 (Brutus)</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Intel SA1100 (Brutus)</secondary></indexterm>RedBoot
supports both board serial ports on the Brutus board. The default serial port
settings are 38400,8,N,1. flash management is not currently supported. </para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>Device programmer is used to program socketed flash parts.</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>The first level page table is located at physical address 0xc0004000.
No second level tables are used.
 
<note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
 
</note><programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x000fffff Boot ROM
0x08000000 - 0x083fffff Application flash
0x10000000 - 0x100fffff SRAM
0x18000000 - 0x180fffff Chip Select 3
0x20000000 - 0x3fffffff PCMCIA
0x80000000 - 0xbfffffff SA-1100 Internal Registers
0xc0000000 - 0xc7ffffff DRAM Bank 0
0xc8000000 - 0xcfffffff DRAM Bank 1
0xd0000000 - 0xd7ffffff DRAM Bank 2
0xd8000000 - 0xdfffffff DRAM Bank 3
0xe0000000 - 0xe7ffffff Cache Clean
 
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x003fffff Y Y DRAM Bank 0
0x00400000 - 0x007fffff Y Y DRAM Bank 1
0x00800000 - 0x00bfffff Y Y DRAM Bank 2
0x00c00000 - 0x00ffffff Y Y DRAM Bank 3
0x08000000 - 0x083fffff Y Y Application flash
0x10000000 - 0x100fffff Y N SRAM
0x20000000 - 0x3fffffff N N PCMCIA
0x40000000 - 0x400fffff Y Y Boot ROM
0x80000000 - 0xbfffffff N N SA-1100 Internal Registers
0xe0000000 - 0xe7ffffff Y Y Cache Clean</programlisting></para>
</sect2>
<sect2>
<title>Platform Resource Usage </title>
<para>
The SA11x0 OS timer is used as a polled timer to provide timeout
support for XModem file transfers.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=brutus
export ARCH_DIR=arm
export PLATFORM_DIR=sa11x0/brutus
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="sa1100mm">
<title>ARM/StrongARM(SA1100) Intel SA1100 Multimedia Board </title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Intel SA1100 Multimedia Board</primary><secondary>
installing and testing</secondary></indexterm><indexterm><primary>installing
and testing</primary><secondary>Intel SA1100 Multimedia Board</secondary>
</indexterm>RedBoot supports both board serial ports. The default serial port
settings are 38400,8,N,1. flash management is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
 
<sect2>
<title>Initial Installation Method </title>
<para>A device programmer is used to program socketed flash parts.</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>The first level page table is located at physical address 0xc0004000.
No second level tables are used.<note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x000fffff Boot flash
0x08000000 - 0x083fffff Application flash
0x10000000 - 0x107fffff SA-1101 Board Registers
0x18000000 - 0x180fffff Ct8020 DSP
0x18400000 - 0x184fffff XBusReg
0x18800000 - 0x188fffff SysRegA
0x18c00000 - 0x18cfffff SysRegB
0x19000000 - 0x193fffff Spare CPLD A
0x19400000 - 0x197fffff Spare CPLD B
0x20000000 - 0x3fffffff PCMCIA
0x80000000 - 0xbfffffff SA1100 Internal Registers
0xc0000000 - 0xc07fffff DRAM Bank 0
0xe0000000 - 0xe7ffffff Cache Clean
Virtual Address Range C B Description
 
 
----------------------- - - ----------------------------------
0x00000000 - 0x007fffff Y Y DRAM Bank 0
0x08000000 - 0x083fffff Y Y Application flash
0x10000000 - 0x100fffff N N SA-1101 Registers
0x18000000 - 0x180fffff N N Ct8020 DSP
0x18400000 - 0x184fffff N N XBusReg
0x18800000 - 0x188fffff N N SysRegA
0x18c00000 - 0x18cfffff N N SysRegB
0x19000000 - 0x193fffff N N Spare CPLD A
0x19400000 - 0x197fffff N N Spare CPLD B
0x20000000 - 0x3fffffff N N PCMCIA
0x50000000 - 0x500fffff Y Y Boot flash
0x80000000 - 0xbfffffff N N SA1100 Internal Registers
0xc0000000 - 0xc07fffff N Y DRAM Bank 0
0xe0000000 - 0xe7ffffff Y Y Cache Clean</programlisting></para>
</sect2>
<sect2>
<title>Platform Resource Usage </title>
<para> The SA11x0 OS timer is used as a polled timer to provide timeout support
for XModem file transfers.</para>
</sect2><sect2>
 
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=sa1100mm
export ARCH_DIR=arm
export PLATFORM_DIR=sa11x0/sa1100mm
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
 
 
<?Pub _newpage>
<sect1 id="assabet">
<title>ARM/StrongARM(SA1110) Intel SA1110 (Assabet) </title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Intel SA1110 (Assabet)</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Intel SA1110 (Assabet)</secondary></indexterm>RedBoot
supports the board serial port and the compact flash ethernet port. The default
serial port settings are 38400,8,N,1. RedBoot also supports flash management
on the Assabet. </para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
<sect2>
<title>Initial Installation Method</title>
<para>A Windows or Linux utility is used to program flash over parallel port
driven JTAG interface. See board documentation for details on in situ flash
programming. </para>
<para>The flash parts are also socketed and may be programmed in a suitable
device programmer.</para>
</sect2>
<sect2>
<title>Special RedBoot Commands</title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps</title>
<para>The first level page table is located at physical address 0xc0004000.
No second level tables are used.<note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x07ffffff flash
0x08000000 - 0x0fffffff SA-1111 Board flash
0x10000000 - 0x17ffffff Board Registers
0x18000000 - 0x1fffffff Ethernet
0x20000000 - 0x2fffffff SA-1111 Board PCMCIA
0x30000000 - 0x3fffffff Compact Flash
0x40000000 - 0x47ffffff SA-1111 Board
0x48000000 - 0x4bffffff GFX
0x80000000 - 0xbfffffff SA-1110 Internal Registers
0xc0000000 - 0xc7ffffff DRAM Bank 0
0xc8000000 - 0xcfffffff DRAM Bank 1
0xd0000000 - 0xd7ffffff DRAM Bank 2
0xd8000000 - 0xdfffffff DRAM Bank 3
0xe0000000 - 0xe7ffffff Cache Clean
 
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x01ffffff Y Y DRAM Bank 0
0x08000000 - 0x0fffffff Y Y SA-1111 Board flash
0x10000000 - 0x17ffffff N N Board Registers
0x18000000 - 0x1fffffff N N Ethernet
0x20000000 - 0x2fffffff N N SA-1111 Board PCMCIA
0x30000000 - 0x3fffffff N N Compact Flash
0x40000000 - 0x47ffffff N N SA-1111 Board
0x48000000 - 0x4bffffff N N GFX
0x50000000 - 0x57ffffff Y Y flash
0x80000000 - 0xbfffffff N N SA-1110 Internal Registers
0xc0000000 - 0xc1ffffff N Y DRAM Bank 0
0xe0000000 - 0xe7ffffff Y Y Cache Clean
</programlisting></para>
</sect2>
<sect2>
<title>Platform Resource Usage </title>
<para>The SA11x0 OS timer is used as a polled timer to provide timeout support
for network and XModem file transfers.</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=assabet
export ARCH_DIR=arm
export PLATFORM_DIR=sa11x0/assabet
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="nano">
<title>ARM/StrongARM(SA11X0) Bright Star Engineering commEngine and nanoEngine</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>commEngine</primary><secondary>installing and testing
</secondary></indexterm><indexterm><primary>nanoEngine</primary><secondary>
installing and testing</secondary></indexterm><indexterm><primary>installing
and testing</primary><secondary>commEngine</secondary></indexterm><indexterm>
<primary>installing and testing</primary><secondary>nanoEngine</secondary>
</indexterm>RedBoot supports a serial port and the built in ethernet port
for communication and downloads. The default serial port settings are 38400,8,N,1.
RedBoot runs from and supports flash management for the system flash
region.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>POST</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the first free flash block
at 0x40000.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation</title>
<para>Unlike other targets, the nanoEngine comes equipped with boot firmware
which you cannot modify. See chapter 5, "nanoEngine Firmware" of the <citetitle>
nanoEngine Hardware Reference Manual</citetitle> (we refer to "July 17, 2000
Rev 0.6") from Bright Star Engineering. </para>
<para>Because of this, eCos, and therefore Redboot, only supports a
special configuration of the ROM mode, starting at offset 0x40000 in
the flash.</para>
<para>Briefly, the POST-configuration RedBoot image lives in flash following the
BSE firmware. The BSE firmware is configured, using its standard <command>
bootcmd</command> command, to run RedBoot at startup.
</para>
</sect2>
<sect2>
<title>Download Instructions</title>
<para>You can perform the initial load of the POST-configuration RedBoot image into
flash using the BSE firmware's <command>load</command> command.
This will load a binary file, using TFTP, and program it into flash in one
operation. Because no memory management is used in the BSE firmware, flash
is mapped from address zero upwards, so the address for the RedBoot POST image
is 0x40000. You must use the binary version of RedBoot for this,
<filename>redboot-post.bin</filename>.</para>
 
<para>This assumes you have set up the other BSE firmware config
parameters such that it can communicate over your network to your TFTP
server.
<screen>><userinput>load redboot-post.bin 40000</userinput>
loading ... erasing blk at 00040000
erasing blk at 00050000
94168 bytes loaded cksum 00008579
done
>
> <userinput>set bootcmd "go 40000"</userinput>
> <userinput>get</userinput>
myip = 10.16.19.198
netmask = 255.255.255.0
eth = 0
gateway = 10.16.19.66
serverip = 10.16.19.66
bootcmd = go 40000
></screen>
 
<note><title>NOTE</title>
<para>the BSE firmware runs its serial IO at 9600 Baud; RedBoot runs instead
at 38400 Baud. You must select the right baud rate in your terminal program
to be able to set up the BSE firmware.</para>
</note>
 
After a reset, the BSE firmware will print
 
<screen>Boot: BSE 2000 Sep 12 2000 14:00:30
autoboot: "go 40000" [hit ESC to abort]</screen>
 
and then RedBoot starts, switching to 38400 Baud.</para>
 
<para>Once you have installed a bootable RedBoot in the system in this
manner, we advise re-installing using the generic method described in
<xref linkend="updating-redboot"> in order that the Flash Image System
contains an appropriate description of the flash entries.</para>
</sect2>
<sect2>
<title>Cohabiting with POST in Flash</title>
<para>The configuration file named <filename>redboot_POST.ecm</filename>
configures RedBoot to build for execution at address 0x50040000 (or, during
bootup, 0x00040000). This is to allow power-on self-test (POST) code or immutable
firmware to live in the lower addresses of the flash and to run before RedBoot
gets control. The assumption is that RedBoot will be entered at its base address
in physical memory, that is 0x00040000.</para>
 
<para>Alternatively, for testing, you can call it in an already running system
by using <userinput>go 0x50040040</userinput> at another RedBoot prompt, or
a branch to that address. The address is where the reset vector
points. It is reported by RedBoot's <command>load</command> command
and listed
by the <command>fis list</command> command, amongst other
places.</para>
 
<para>Using the POST configuration enables a normal config option which causes
linking and initialization against memory layout files called "...post..."
rather than "...rom..." or "...ram..." in the <filename class="directory">include/pkgconf
</filename> directory. Specifically:<literallayout><filename>include/pkgconf/mlt_arm_sa11x0_nano_post.h</filename>
<filename>include/pkgconf/mlt_arm_sa11x0_nano_post.ldi</filename>
<filename>include/pkgconf/mlt_arm_sa11x0_nano_post.mlt</filename></literallayout>
 
It is these you should edit if you wish to move the execution address
from 0x50040000 in the POST configuration. Startup mode naturally
remains ROM in this configuration.</para>
 
<para>Because the nanoEngine contains immutable boot firmware at the start
of flash, RedBoot for this target is configured to reserve that area in the
Flash Image System, and to create by default an entry for the POST
mode RedBoot.
<screen>
RedBoot> <userinput>fis list</userinput>
Name FLASH addr Mem addr Length Entry point
(reserved) 0x50000000 0x50000000 0x00040000 0x00000000
RedBoot[post] 0x50040000 0x00100000 0x00020000 0x50040040
RedBoot config 0x503E0000 0x503E0000 0x00010000 0x00000000
FIS directory 0x503F0000 0x503F0000 0x00010000 0x00000000
RedBoot>
</screen>
The entry "(reserved)" ensures that the FIS cannot attempt
to overwrite the BSE firmware, thus ensuring that the board remains bootable
and recoverable even after installing a broken RedBoot image.</para>
</sect2>
<sect2>
<title>Special RedBoot Commands</title>
<para>The nanoEngine/commEngine has one or two Intel i82559 Ethernet controllers
installed, but these have no associated serial EEPROM in which to record their
Ethernet Station Address (ESA, or MAC address). The BSE firmware records an
ESA for the device it uses, but this information is not available to RedBoot;
we cannot share it.</para>
<para>To keep the ESAs for the two ethernet interfaces, two new items of RedBoot
configuration data are introduced. You can list them with the RedBoot command <command>
fconfig -l</command> thus:
<screen>
RedBoot> <userinput>fconfig -l</userinput>
Run script at boot: false
Use BOOTP for network configuration: false
Local IP address: 10.16.19.91
Default server IP address: 10.16.19.66
Network hardware address [MAC] for eth0: 0x00:0xB5:0xE0:0xB5:0xE0:0x99
Network hardware address [MAC] for eth1: 0x00:0xB5:0xE0:0xB5:0xE0:0x9A
GDB connection port: 9000
Network debug at boot time: false
RedBoot></screen>
 
You should set them before running RedBoot or eCos applications with
the board connected to a network. The <command>fconfig </command>
command can be used as for any configuration data item; the entire ESA
is entered in one line.</para>
</sect2>
<sect2>
<title>Memory Maps</title>
<para>The first level page table is located at physical address 0xc0004000.
No second level tables are used. <note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x003fffff 4Mb FLASH (nCS0)
0x18000000 - 0x18ffffff Internal PCI bus - 2 x i82559 ethernet
0x40000000 - 0x4fffffff External IO or PCI bus
0x80000000 - 0xbfffffff SA-1110 Internal Registers
0xc0000000 - 0xc7ffffff DRAM Bank 0 - 32Mb SDRAM
0xc8000000 - 0xcfffffff DRAM Bank 1 - empty
0xe0000000 - 0xe7ffffff Cache Clean
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x001fffff Y Y DRAM - 8Mb to 32Mb
0x18000000 - 0x180fffff N N Internal PCI bus - 2 x i82559 ethernet
0x40000000 - 0x4fffffff N N External IO or PCI bus
0x50000000 - 0x51ffffff Y Y Up to 32Mb FLASH (nCS0)
0x80000000 - 0xbfffffff N N SA-1110 Internal Registers
0xc0000000 - 0xc0ffffff N Y DRAM Bank 0: 8 or 16Mb
0xc8000000 - 0xc8ffffff N Y DRAM Bank 1: 8 or 16Mb or absent
0xe0000000 - 0xe7ffffff Y Y Cache Clean</programlisting>
</para>
 
<para>The ethernet devices use a "PCI window" to communicate with the CPU.
This is 1Mb of SDRAM which is shared with the ethernet devices that are on
the PCI bus. It is neither cached nor buffered, to ensure that CPU and PCI
accesses see correct data in the correct order. By default it is configured
to be megabyte number 30, at addresses 0x01e00000-0x01efffff. This can be
modified, and indeed must be, if less than 32Mb of SDRAM is installed, via
the memory layout tool, or by moving the section <computeroutput>__pci_window
</computeroutput> referred to by symbols <computeroutput>CYGMEM_SECTION_pci_window*
</computeroutput> in the linker script. </para>
<para>Though the nanoEngine ships with 32Mb of SDRAM all attached to DRAM
bank 0, the code can cope with any of these combinations also; "2 x " in this
context means one device in each DRAM Bank. <literallayout>1 x 8Mb = 8Mb 2 x 8Mb = 16Mb
1 x 16Mb = 16Mb 2 x 16Mb = 32Mb</literallayout>All are programmed the same
in the memory controller. </para>
<para>Startup code detects which is fitted and programs the memory map accordingly.
If the device(s) is 8Mb, then there are gaps in the physical memory map, because
a high order address bit is not connected. The gaps are the higher 2Mb out
of every 4Mb.</para>
 
<para> The SA11x0 OS timer is used as a polled timer to provide timeout
support within RedBoot.</para>
</sect2>
<sect2>
<title>Nano Platform Port</title>
<para>The nano is in the set of SA11X0-based platforms. It uses the arm architectural
HAL, the sa11x0 variant HAL, plus the nano platform hal. These are components
<literallayout>CYGPKG_HAL_ARM hal/arm/arch/
CYGPKG_HAL_ARM_SA11X0 hal/arm/sa11x0/var
CYGPKG_HAL_ARM_SA11X0_NANO hal/arm/sa11x0/nano</literallayout> respectively.
</para>
<para>The target name is "nano" which includes all these, plus the ethernet
driver packages, flash driver, and so on.</para>
</sect2>
<sect2>
<title>Ethernet Driver</title>
<para>The ethernet driver is in two parts: </para>
<para>A generic ether driver for Intel i8255x series devices, specifically
the i82559, is <computeroutput>devs/eth/intel/i82559</computeroutput>. Its
package name is <computeroutput>CYGPKG_DEVS_ETH_INTEL_I82559</computeroutput>.
</para>
<para>The platform-specific ether driver is <computeroutput>devs/eth/arm/nano
</computeroutput>. Its package is <computeroutput>CYGPKG_DEVS_ETH_ARM_NANO
</computeroutput>. This tells the generic driver the address in IO memory
of the chip, for example, and other configuration details. This driver picks
up the ESA from RedBoot's configuration data - unless configured to use a
static ESA in the usual manner. </para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=nano
export ARCH_DIR=arm
export PLATFORM_DIR=sa11x0/nano
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="ipaq">
<title>ARM/StrongARM(SA11X0) Compaq iPAQ PocketPC</title>
<indexterm><primary>Compaq iPAQ PocketPC</primary><secondary>installing and
testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Compaq iPAQ PocketPC</secondary></indexterm>
<sect2>
<title>Overview</title>
<para>RedBoot supports the serial port via cradle or cable, and Compact Flash
ethernet cards if fitted for communication and downloads. The LCD touchscreen
may also be used for the console, although by default RedBoot will switch
exclusively to one channel once input arrives. </para>
<para>The default serial port settings are 38400,8,N,1. RedBoot runs from
and supports flash management for the system flash region. </para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
<row>
<entry>WinCE</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM, started from
<application>OSloader</application>.</entry>
<entry>redboot_WinCE.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
 
 
</sect2>
<sect2>
<title>Initial Installation</title>
<para>RedBoot ROM and WinCE mode images are needed by the installation process.
</para>
<sect3>
<title>Installing RedBoot on the iPAQ using Windows/CE</title>
<para>
The Windows/CE environment originally shipped with the iPAQ contains a hidden
mini-loader, sometimes referred to as the "Parrot" loader. This loader can
be started by holding down the action button (the joypad) while resetting
the unit or when powering on. At this point, a blue bird will appear on
the LCD screen. Also at this point, a simple loader can be accessed over the
serial port at 115200/8N1. Using this loader, the contents of the iPAQ flash
memory can be saved to a Compact Flash memory card.
<note><title>NOTE</title><para>We have only tested this operation with a 32Mbyte CF memory card.
Given that the backup will take 16MBytes + 1KByte, something more than a 16MByte
card will be required.</para></note>
</para>
<para>
Use the "r2c" command to dump Flash contents to the CF memory card. Once this
completes, RedBoot can be installed with no fear since the Parrot loader can
be used to restore the Flash contents at a later time.
</para>
<para>
If you expect to completely recover the state of the iPAQ Win/CE environment, then
HotSync should be run to backup all "RAM" files as well before installing RedBoot.
</para>
<para>The next step in installing RedBoot on the iPAQ actually involves Windows/CE,
which is the native environment on the unit. Using WinCE, you need to
install an application which will run a RAM based version of RedBoot. Once
this is installed and running, RedBoot can be used to update the flash with
a native/ROM version of RedBoot. <itemizedlist>
<listitem><para>Using ActiveSync, copy the file OSloader to your iPAQ. </para>
</listitem>
<listitem><para>Using ActiveSync, copy the file redboot_WinCE.bin to the iPAQ
as bootldr in its root directory. Note: this is not the top level folder
displayed by Windows (Mobile Device), but rather the 'My Pocket PC' folder
within it.</para>
</listitem>
<listitem><para>Execute OSloader. If you didn't create a shortcut, then you
will have to poke around for it using the WinCE file explorer.</para>
</listitem>
<listitem><para>Choose the <guimenuitem>Tools->BootLdr->Run after loading
from file</guimenuitem> menu item. </para>
</listitem>
</itemizedlist>At this point, the RAM based version of RedBoot should be running.
You should be able to return to this point by just executing the last two
steps of the previous process if necessary.</para>
</sect3>
<sect3>
<title>Installing RedBoot on the iPAQ - using the Compaq boot loader</title>
<para>This method of installation is no longer supported.
If you have previously installed either the Compaq boot loader or older
versions of RedBoot, restore the Win/CE environment and proceed as outlined
above.
</para>
</sect3>
<sect3 id="setting-up-and-testing-redboot">
<title>Setting up and testing RedBoot</title>
<para>When RedBoot first comes up, it will want to initialize its LCD touch
screen parameters. It does this by displaying a keyboard graphic and asks
you to press certain keys. Using the stylus, press and hold until the prompt
is withdrawn. When you lift the stylus, RedBoot will continue with the next
calibration. </para>
<para>Once the LCD touchscreen has been calibrated, RedBoot will start. The
calibration step can be skipped by pressing the <guibutton>return/abort</guibutton>
button on the unit (right most button with a curved arrow icon). Additionally,
the unit will assume default values if the screen is not touched within about
15 seconds. </para>
<para>Once RedBoot has started, you should get information similar to this
on the LCD screen. It will also appear on the serial port at 38400,8,N,1.
 
<screen>RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 06:17:41, Mar 19 2001
Platform: Compaq iPAQ Pocket PC (StrongARM 1110)
 
Copyright (C) 2000, 2001, Red Hat, Inc.
 
RAM: 0x00000000-0x01fc0000, 0x0001f200-0x01f70000 available
FLASH: 0x50000000 - 0x51000000, 64 blocks of 0x00040000 bytes
each.</screen>
 
Since the LCD touchscreen is only 30 characters wide, some of this
data will be off the right hand side of the display. The joypad may be
used to pan left and right in order to see the full lines. </para>
<para>If you have a Compact Flash ethernet card, RedBoot should find
it. You'll need to have BOOTP enabled for this unit (see your
sysadmin for details). If it does, it will print a message like:
 
<screen>... Waiting for network card: .Ready!
Socket Communications Inc: CF+ LPE Revision E 08/04/99
IP: 192.168.1.34, Default server: 192.168.1.101</screen></para>
</sect3>
 
<sect3 id="ipaq-install-rb-permanently">
<title>Installing RedBoot permanently</title>
<para>Once you are satisfied with the setup and that RedBoot is operating
properly in your environment, you can set up your iPAQ unit to have RedBoot
be the bootstrap application.
 
<caution><title>CAUTION</title>
<para>This step will destroy your Windows/CE environment.</para>
<para>Before you take this step, it is strongly recommended you save your WinCE FLASH contents
as outlined above using the "parrot" loader, or
by using the Compaq OSloader:<itemizedlist>
 
<listitem><para>Using OSloader on the iPAQ, select the <guimenuitem>Tools->Flash->Save
to files...</guimenuitem>. menu item.</para>
</listitem>
 
<listitem><para>Four (4) files, 4MB each in size will be created.</para>
</listitem>
 
<listitem><para>After each file is created, copy the file to your computer,
then delete the file from the iPAQ to make room in the WinCE ramdisk for the
next file.</para></listitem>
</itemizedlist></para>
 
</caution>You will need to download the version of RedBoot designed as the
ROM bootstrap. Then install it permanently using these commands:
<screen>
RedBoot> <userinput>lo -r -b 0x100000 redboot_ROM.bin</userinput>
RedBoot> <userinput>fi loc -f 0x50000000 -l 0x40000</userinput>
RedBoot> <userinput>fis init</userinput>
RedBoot> <userinput>fi unl -f 0x50040000 -l 0x40000</userinput>
RedBoot> <userinput>fi cr RedBoot -b 0x100000</userinput>
RedBoot> <userinput>fi loc -f 0x50040000 -l 0x40000</userinput>
RedBoot> <userinput>reset</userinput>
</screen>
 
<warning><title>WARNING</title>
<para>You must type these commands exactly! Failure to do so may render your
iPAQ totally useless. Once you've done this, RedBoot should come up every
time you reset.</para>
</warning></para>
</sect3>
 
<sect3>
<title>Restoring Windows/CE</title>
<para>To restore Windows/CE from the backup taken in <xref linkend="ipaq-install-rb-permanently">,
visit <ulink url="http://www.handhelds.org/projects/wincerestoration.html">http://www.handhelds.org/projects/wincerestoration.html</ulink>
for directions.
</para>
</sect3></sect2>
 
<sect2>
<title>Additional commands</title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels,
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the iPAQ are:</para>
<variablelist><varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Location Linux kernel was loaded to</para></listitem></varlistentry>
<varlistentry><term>
-l <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term>-r <replaceable>&lt;addr></replaceable></term>
<listitem><para>'initrd' ramdisk location</para></listitem></varlistentry>
<varlistentry><term>-s <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of initrd ramdisk</para></listitem></varlistentry>
</variablelist>
<para>Linux kernels may be run on the iPAQ using the sources from the anonymous
CVS repository at the Handhelds project (<ulink url="http://www.handhelds.org/">
http://www.handhelds.org/</ulink>) with
the <filename>elinux.patch</filename> patch file applied. This file can be
found in the
<filename>misc/</filename> subdirectory of the iPAQ platform HAL in the
RedBoot sources, normally
<filename>hal/arm/sa11x0/ipaq/<replaceable>VERSION</replaceable>/misc/</filename>
</para>
<para>
On the iPAQ (and indeed all SA11x0 platforms), Linux expects to be loaded
at address 0xC0008000 and the entry point is also at 0xC0008000.
</para>
 
</sect2>
<sect2>
<title>Memory Maps</title>
<para>RedBoot sets up the following memory map on the iPAQ: The first level
page table is located at physical address 0xC0004000. No second level tables
are used. <note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note> <programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x01ffffff 16Mb to 32Mb FLASH (nCS0) [organized as below]
0x000000 - 0x0003ffff Parrot Loader
0x040000 - 0x0007ffff RedBoot
0xf80000 - 0x00fbffff Fconfig data
0xfc0000 - 0x00ffffff FIS directory
0x30000000 - 0x3fffffff Compact Flash
0x48000000 - 0x4bffffff iPAQ internal registers
0x80000000 - 0xbfffffff SA-1110 Internal Registers
0xc0000000 - 0xc1ffffff DRAM Bank 0 - 32Mb SDRAM
0xe0000000 - 0xe7ffffff Cache Clean
 
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x01ffffff Y Y DRAM - 32Mb
0x30000000 - 0x3fffffff N N Compact Flash
0x48000000 - 0x4bffffff N N iPAQ internal registers
0x50000000 - 0x51ffffff Y Y Up to 32Mb FLASH (nCS0)
0x80000000 - 0xbfffffff N N SA-1110 Internal Registers
0xc0000000 - 0xc1ffffff N Y DRAM Bank 0: 32Mb
0xe0000000 - 0xe7ffffff Y Y Cache Clean </programlisting> </para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=ipaq
export ARCH_DIR=arm
export PLATFORM_DIR=sa11x0/ipaq
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2></sect1>
 
<?Pub _newpage>
<sect1 id="cerfcube">
<title>ARM/StrongARM(SA11X0) Intrinsyc CerfCube</title>
<indexterm><primary>Intrinsyc CerfCube</primary><secondary>installing and
testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Intrinsyc CerfCube</secondary></indexterm>
<sect2>
<title>Overview</title>
<para>RedBoot supports the serial port and the builtin
ethernet connection for communication and downloads.
</para>
<para>The default serial port settings are 38400,8,N,1. RedBoot runs from
and supports flash management for the system flash region. </para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
 
</sect2>
<sect2>
<title>Initial Installation</title>
<para>
The original boot loader supplied with the CerfCube can be used to install
RedBoot. Connect to the device using a serial port at 38400/8N1.
Copy the binary RedBoot ROM mode image to an available TFTP server.
Issue these commands to the Instrinsyc loader:
<screen>
<userinput>download tftp:<replaceable>x.x.x.x</replaceable> redboot_ROM.bin 0xc0000000</userinput>
<userinput>flashloader 0x00000000 0xc0000000 0x20000</userinput>
</screen>
where <replaceable>x.x.x.x</replaceable> is the IP address of the TFTP
server.
<note>
<title>NOTE</title>
<para>
Other installation methods may be available via the Intrinsyc loader.
Contact Intrinsyc for details.
</para>
</note>
</para>
</sect2>
<sect2>
<title>Additional commands</title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels,
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the CerfCube are:</para>
<variablelist><varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Location Linux kernel was loaded to</para></listitem></varlistentry>
<varlistentry><term>
-l <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term>-r <replaceable>&lt;addr></replaceable></term>
<listitem><para>'initrd' ramdisk location</para></listitem></varlistentry>
<varlistentry><term>-s <replaceable>&lt;len></replaceable></term>
<listitem><para>Length of initrd ramdisk</para></listitem></varlistentry>
</variablelist>
 
</sect2>
<sect2>
<title>Memory Maps</title>
<para>RedBoot sets up the following memory map on the CerfCube: The first level
page table is located at physical address 0xC0004000. No second level tables
are used. <note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note> <programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x01ffffff 16Mb to 32Mb FLASH (nCS0) [organized as below]
0x000000 - 0x0001ffff RedBoot
0x020000 - 0x0003ffff RedBoot [RAM version]
0xfc0000 - 0x00fdffff Fconfig data
0xfe0000 - 0x00ffffff FIS directory
0x0f000000 - 0x0fffffff Onboard ethernet
0x10000000 - 0x17ffffff CerfCube internal registers
0x20000000 - 0x3fffffff PCMCIA / Compact Flash
0x80000000 - 0xbfffffff SA-1110 Internal Registers
0xc0000000 - 0xc1ffffff DRAM Bank 0 - 32Mb SDRAM
0xe0000000 - 0xe7ffffff Cache Clean
 
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x01ffffff Y Y DRAM - 32Mb
0x08000000 - 0x0fffffff N N Onboard ethernet controller
0x10000000 - 0x17ffffff N N CerfCube internal registers
0x20000000 - 0x3fffffff N N PCMCIA / Compact Flash
0x50000000 - 0x51ffffff Y Y Up to 32Mb FLASH (nCS0)
0x80000000 - 0xbfffffff N N SA-1110 Internal Registers
0xc0000000 - 0xc1ffffff N Y DRAM Bank 0: 32Mb
0xe0000000 - 0xe7ffffff Y Y Cache Clean </programlisting> </para>
</sect2>
 
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=cerf
export ARCH_DIR=arm
export PLATFORM_DIR=sa11x0/cerf
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2></sect1>
 
 
<sect1 id="iq80310">
<title>ARM/Xscale Cyclone IQ80310</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Cyclone IQ80310</primary><secondary>installing and
testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Cyclone IQ80310</secondary></indexterm>RedBoot supports
both serial ports and the built-in ethernet port for communication and downloads.
The default serial port settings are 115200,8,N,1. RedBoot also supports flash
management for the onboard 8MB flash.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
<row>
<entry>ROMA</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from flash address 0x40000, with
ARM bootloader in flash boot sector.</entry>
<entry>redboot_ROMA.ecm</entry>
</row>
<row>
<entry>RAMA</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with ARM bootloader in
flash boot sector.</entry>
<entry>redboot_RAMA.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
<sect2>
<title>Initial Installation Method</title>
 
<para>The board manufacturer provides a DOS application which is
capable of programming the flash over the PCI bus, and this is
required for initial installations of RedBoot. Please see the board
manual for information on using this utility. In general, the process
involves programming one of the two flash based RedBoot images to
flash. The ROM mode RedBoot (which runs from the flash boot sector)
should be programmed to flash address 0x00000000. The ROMA RedBoot
mode (which is started by the ARM bootloader) should be programmed to
flash address 0x00004000.
</para>
 
<para> To install RedBoot to run from the flash boot sector, use the manufacturer's
flash utility to install the ROM mode image at address zero.
</para>
<para>To install RedBoot to run from address 0x40000 with the ARM bootloader
in the flash boot sector, use the manufacturer's flash utility to install
the ROMA mode image at address 0x40000. </para>
 
<para>After booting the initial installation of RedBoot, this warning may
be printed: <screen>flash configuration checksum error or invalid key
</screen>This is normal, and indicates that the flash must be configured
for use by RedBoot. Even if the above message is not printed, it may be a
good idea to reinitialize the flash anyway. Do this with the <command>
fis</command> command: <screen>RedBoot> <userinput>fis init</userinput>
About to initialize [format] flash image system - continue (y/n)? <userinput>y</userinput>
*** Initialize flash Image System
Warning: device contents not erased, some blocks may not be usable
... Unlock from 0x007e0000-0x00800000: .
... Erase from 0x007e0000-0x00800000: .
... Program from 0xa1fd0000-0xa1fd0400 at 0x007e0000: .
... Lock from 0x007e0000-0x00800000: .
Followed by the fconfig command:
RedBoot> <userinput>fconfig</userinput>
Run script at boot: <userinput>false</userinput>
Use BOOTP for network configuration: <userinput>false</userinput>
Local IP address: <userinput>192.168.1.153</userinput>
Default server IP address: <userinput>192.168.1.10</userinput>
GDB connection port: <userinput>1000</userinput>
Network debug at boot time: <userinput>false</userinput>
Update RedBoot non-volatile configuration - continue (y/n)? <userinput>y</userinput>
... Unlock from 0x007c0000-0x007e0000: .
... Erase from 0x007c0000-0x007e0000: .
... Program from 0xa0013018-0xa0013418 at 0x007c0000: .
... Lock from 0x007c0000-0x007e0000: .</screen></para>
 
<note><para>When later updating RedBoot in situ, it is important to
use a matching ROM and RAM mode pair of images. So use either RAM/ROM
or RAMA/ROMA images. Do not mix them.</para></note>
 
</sect2>
<sect2>
<title>Error codes</title>
<para>RedBoot uses the two digit LED display to indicate errors during board
initialization. Possible error codes are: <literallayout>88 - Unknown Error
55 - I2C Error
FF - SDRAM Error
01 - No Error</literallayout></para>
</sect2>
<sect2>
<title>Using RedBoot with ARM Bootloader </title>
<para>RedBoot can coexist with ARM tools in flash on the IQ80310 board. In
this configuration, the ARM bootloader will occupy the flash boot sector while
RedBoot is located at flash address 0x40000. The sixteen position rotary switch
is used to tell the ARM bootloader to jump to the RedBoot image located at
address 0x40000. RedBoot is selected by switch position 0 or 1. Other switch
positions are used by the ARM firmware and RedBoot will not be started. </para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>A special RedBoot command, <command>diag</command>, is used to
access a set of hardware diagnostics provided by the board
manufacturer. To access the diagnostic menu, enter diag at the RedBoot prompt:
<screen>
RedBoot> <userinput>diag</userinput>
Entering Hardware Diagnostics - Disabling Data Cache!
1 - Memory Tests
2 - Repeating Memory Tests
3 - 16C552 DUART Serial Port Tests
4 - Rotary Switch S1 Test for positions 0-3
5 - seven Segment LED Tests
6 - Backplane Detection Test
7 - Battery Status Test
8 - External Timer Test
9 - i82559 Ethernet Configuration
10 - i82559 Ethernet Test
11 - Secondary PCI Bus Test
12 - Primary PCI Bus Test
13 - i960Rx/303 PCI Interrupt Test
14 - Internal Timer Test
15 - GPIO Test
0 - quit Enter the menu item number (0 to quit):
</screen>
Tests for various hardware subsystems are provided, and some
tests require special hardware in order to execute normally. The Ethernet
Configuration item may be used to set the board ethernet address.</para>
</sect2>
<sect2>
<title>IQ80310 Hardware Tests</title>
<para><screen>1 - Memory Tests
2 - Repeating Memory Tests
3 - 16C552 DUART Serial Port Tests
4 - Rotary Switch S1 Test for positions 0-3
5 - 7 Segment LED Tests
6 - Backplane Detection Test
7 - Battery Status Test
8 - External Timer Test
9 - i82559 Ethernet Configuration
10 - i82559 Ethernet Test
11 - i960Rx/303 PCI Interrupt Test
12 - Internal Timer Test
13 - Secondary PCI Bus Test
14 - Primary PCI Bus Test
15 - Battery Backup SDRAM Memory Test
16 - GPIO Test
17 - Repeat-On-Fail Memory Test
18 - Coyonosa Cache Loop (No return)
19 - Show Software and Hardware Revision
0 - quit
Enter the menu item number (0 to quit): </screen></para>
<para>Tests for various hardware subsystems are provided, and some tests require
special hardware in order to execute normally. The Ethernet Configuration
item may be used to set the board ethernet address.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot </title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=iq80310
export ARCH_DIR=arm
export PLATFORM_DIR=iq80310
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
 
<sect2>
<title>Interrupts</title>
<para>RedBoot uses an interrupt vector table which is located at address 0xA000A004.
Entries in this table are pointers to functions with this protoype:: <programlisting>
int irq_handler( unsigned vector, unsigned data )</programlisting>On an IQ80310
board, the vector argument is one of 49 interrupts defined in <computeroutput>
hal/arm/iq80310/current/include/hal_platform_ints.h:</computeroutput>: <programlisting>
// *** 80200 CPU ***
#define CYGNUM_HAL_INTERRUPT_reserved0 0
#define CYGNUM_HAL_INTERRUPT_PMU_PMN0_OVFL 1 // See Ch.12 - Performance Mon.
#define CYGNUM_HAL_INTERRUPT_PMU_PMN1_OVFL 2 // PMU counter 0/1 overflow
#define CYGNUM_HAL_INTERRUPT_PMU_CCNT_OVFL 3 // PMU clock overflow
#define CYGNUM_HAL_INTERRUPT_BCU_INTERRUPT 4 // See Ch.11 - Bus Control Unit
#define CYGNUM_HAL_INTERRUPT_NIRQ 5 // external IRQ
#define CYGNUM_HAL_INTERRUPT_NFIQ 6 // external FIQ
 
 
// *** XINT6 interrupts ***
#define CYGNUM_HAL_INTERRUPT_DMA_0 7
#define CYGNUM_HAL_INTERRUPT_DMA_1 8
#define CYGNUM_HAL_INTERRUPT_DMA_2 9
#define CYGNUM_HAL_INTERRUPT_GTSC 10 // Global Time Stamp Counter
#define CYGNUM_HAL_INTERRUPT_PEC 11 // Performance Event Counter
#define CYGNUM_HAL_INTERRUPT_AAIP 12 // application accelerator unit
 
 
// *** XINT7 interrupts ***
// I2C interrupts
#define CYGNUM_HAL_INTERRUPT_I2C_TX_EMPTY 13
#define CYGNUM_HAL_INTERRUPT_I2C_RX_FULL 14
#define CYGNUM_HAL_INTERRUPT_I2C_BUS_ERR 15
#define CYGNUM_HAL_INTERRUPT_I2C_STOP 16
#define CYGNUM_HAL_INTERRUPT_I2C_LOSS 17
#define CYGNUM_HAL_INTERRUPT_I2C_ADDRESS 18
 
 
// Messaging Unit interrupts
#define CYGNUM_HAL_INTERRUPT_MESSAGE_0 19
#define CYGNUM_HAL_INTERRUPT_MESSAGE_1 20
#define CYGNUM_HAL_INTERRUPT_DOORBELL 21
#define CYGNUM_HAL_INTERRUPT_NMI_DOORBELL 22
#define CYGNUM_HAL_INTERRUPT_QUEUE_POST 23
#define CYGNUM_HAL_INTERRUPT_OUTBOUND_QUEUE_FULL 24
#define CYGNUM_HAL_INTERRUPT_INDEX_REGISTER 25
// PCI Address Translation Unit
#define CYGNUM_HAL_INTERRUPT_BIST 26
 
 
// *** External board interrupts (XINT3) ***
#define CYGNUM_HAL_INTERRUPT_TIMER 27 // external timer
#define CYGNUM_HAL_INTERRUPT_ETHERNET 28 // onboard enet
#define CYGNUM_HAL_INTERRUPT_SERIAL_A 29 // 16x50 uart A
#define CYGNUM_HAL_INTERRUPT_SERIAL_B 30 // 16x50 uart B
#define CYGNUM_HAL_INTERRUPT_PCI_S_INTD 31 // secondary PCI INTD
// The hardware doesn't (yet?) provide masking or status for these
// even though they can trigger cpu interrupts. ISRs will need to
// poll the device to see if the device actually triggered the
// interrupt.
#define CYGNUM_HAL_INTERRUPT_PCI_S_INTC 32 // secondary PCI INTC
#define CYGNUM_HAL_INTERRUPT_PCI_S_INTB 33 // secondary PCI INTB
#define CYGNUM_HAL_INTERRUPT_PCI_S_INTA 34 // secondary PCI INTA
 
 
// *** NMI Interrupts go to FIQ ***
#define CYGNUM_HAL_INTERRUPT_MCU_ERR 35
#define CYGNUM_HAL_INTERRUPT_PATU_ERR 36
#define CYGNUM_HAL_INTERRUPT_SATU_ERR 37
#define CYGNUM_HAL_INTERRUPT_PBDG_ERR 38
#define CYGNUM_HAL_INTERRUPT_SBDG_ERR 39
#define CYGNUM_HAL_INTERRUPT_DMA0_ERR 40
#define CYGNUM_HAL_INTERRUPT_DMA1_ERR 41
#define CYGNUM_HAL_INTERRUPT_DMA2_ERR 42
#define CYGNUM_HAL_INTERRUPT_MU_ERR 43
#define CYGNUM_HAL_INTERRUPT_reserved52 44
#define CYGNUM_HAL_INTERRUPT_AAU_ERR 45
#define CYGNUM_HAL_INTERRUPT_BIU_ERR 46
 
 
// *** ATU FIQ sources ***
#define CYGNUM_HAL_INTERRUPT_P_SERR 47
#define CYGNUM_HAL_INTERRUPT_S_SERR 48</programlisting>The data passed
to the ISR is pulled from a data table <computeroutput>(hal_interrupt_data)
</computeroutput> which immediately follows the interrupt vector table. With
49 interrupts, the data table starts at address 0xA000A0C8. </para>
<para>An application may create a normal C function with the above prototype
to be an ISR. Just poke its address into the table at the correct index and
enable the interrupt at its source. The return value of the ISR is ignored
by RedBoot.</para>
</sect2>
<sect2>
<title>Memory Maps</title>
<para>The first level page table is located at 0xa0004000. Two second level
tables are also used. One second level table is located at 0xa0008000 and
maps the first 1MB of flash. The other second level table is at 0xa0008400,
and maps the first 1MB of SDRAM. <note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note></para>
<para><programlisting>Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x00000fff flash Memory
0x00001000 - 0x00001fff 80312 Internal Registers
0x00002000 - 0x007fffff flash Memory
0x00800000 - 0x7fffffff PCI ATU Outbound Direct Window
0x80000000 - 0x83ffffff Primary PCI 32-bit Memory
0x84000000 - 0x87ffffff Primary PCI 64-bit Memory
0x88000000 - 0x8bffffff Secondary PCI 32-bit Memory
0x8c000000 - 0x8fffffff Secondary PCI 64-bit Memory
0x90000000 - 0x9000ffff Primary PCI IO Space
0x90010000 - 0x9001ffff Secondary PCI IO Space
0x90020000 - 0x9fffffff Unused
0xa0000000 - 0xbfffffff SDRAM
0xc0000000 - 0xefffffff Unused
0xf0000000 - 0xffffffff 80200 Internal Registers
 
 
Virtual Address Range C B Description
----------------------- - - ----------------------------------
0x00000000 - 0x00000fff Y Y SDRAM
0x00001000 - 0x00001fff N N 80312 Internal Registers
0x00002000 - 0x007fffff Y N flash Memory
0x00800000 - 0x7fffffff N N PCI ATU Outbound Direct Window
0x80000000 - 0x83ffffff N N Primary PCI 32-bit Memory
0x84000000 - 0x87ffffff N N Primary PCI 64-bit Memory
0x88000000 - 0x8bffffff N N Secondary PCI 32-bit Memory
0x8c000000 - 0x8fffffff N N Secondary PCI 64-bit Memory
0x90000000 - 0x9000ffff N N Primary PCI IO Space
0x90010000 - 0x9001ffff N N Secondary PCI IO Space
0xa0000000 - 0xbfffffff Y Y SDRAM
0xc0000000 - 0xcfffffff Y Y Cache Flush Region
0xd0000000 - 0xd0000fff Y N first 4k page of flash
0xf0000000 - 0xffffffff N N 80200 Internal Registers </programlisting></para>
</sect2>
<sect2>
<title>Platform Resource Usage</title>
<para>The external timer is used as a polled timer to provide timeout support
for networking and XModem file transfers.</para>
</sect2></sect1>
 
<?Pub _newpage>
<sect1 id="iq80321">
<title>ARM/Xscale Intel IQ80321</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Intel IQ80321</primary><secondary>installing and
testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Intel IQ80321</secondary></indexterm>RedBoot supports
the serial port and the built-in ethernet port for communication and downloads.
The default serial port settings are 115200,8,N,1. RedBoot also supports flash
management for the onboard 8MB flash.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
 
</sect2>
<sect2>
<title>Initial Installation Method</title>
<para>The board manufacturer provides a DOS application which is capable of
programming the flash over the PCI bus, and this is required for initial installations
of RedBoot. Please see the board manual for information on using this utility.
In general, the process involves programming the ROM mode RedBoot
image to flash. RedBoot should be programmed to flash address
0x00000000 using the DOS utility.
</para>
 
<para>After booting the initial installation of RedBoot, this warning may
be printed: <screen>flash configuration checksum error or invalid key
</screen>This is normal, and indicates that the flash must be configured
for use by RedBoot. Even if the above message is not printed, it may be a
good idea to reinitialize the flash anyway. Do this with the <command>
fis</command> command: <screen>RedBoot> <userinput>fis init</userinput>
About to initialize [format] FLASH image system - continue (y/n)? <userinput>y</userinput>
*** Initialize FLASH Image System
Warning: device contents not erased, some blocks may not be usable
... Unlock from 0xf07e0000-0xf0800000: .
... Erase from 0xf07e0000-0xf0800000: .
... Program from 0x01ddf000-0x01ddf400 at 0xf07e0000: .
... Lock from 0xf07e0000-0xf0800000: .
</screen></para></sect2>
<sect2>
<title>Switch Settings</title>
<para>The 80321 board is highly configurable through a number of switches and jumpers.
RedBoot makes some assumptions about board configuration and attention must be paid
to these assumptions for reliable RedBoot operation:
<itemizedlist>
<listitem><para>The onboard ethernet and the secondary slot may be placed in a
private space so that they are not seen by a PC BIOS. If the board is to be used
in a PC with BIOS, then the ethernet should be placed in this private space so that
RedBoot and the BIOS do not conflict.
</para></listitem>
<listitem><para>RedBoot assumes that the board is plugged into a PC with BIOS. This
requires RedBoot to detect when the BIOS has configured the PCI-X secondary bus. If
the board is placed in a backplane, RedBoot will never see the BIOS configure the
secondary bus. To prevent this wait, set switch S7E1-3 to ON when using the board
in a backplane.</para></listitem>
<listitem><para>For the remaining switch settings, the following is a known good
configuration:
<informaltable frame=all>
<tgroup cols=2>
<tbody>
<row><entry>S1D1</entry><entry>All OFF</entry></row>
<row><entry>S7E1</entry><entry>7 is ON, all others OFF</entry></row>
<row><entry>S8E1</entry><entry>2,3,5,6 are ON, all others OFF</entry></row>
<row><entry>S8E2</entry><entry>2,3 are ON, all others OFF</entry></row>
<row><entry>S9E1</entry><entry>3 is ON, all others OFF</entry></row>
<row><entry>S4D1</entry><entry>1,3 are ON, all others OFF</entry></row>
<row><entry>J9E1</entry><entry>2,3 jumpered</entry></row>
<row><entry>J9F1</entry><entry>2,3 jumpered</entry></row>
<row><entry>J3F1</entry><entry>Nothing jumpered</entry></row>
<row><entry>J3G1</entry><entry>2,3 jumpered</entry></row>
<row><entry>J1G2</entry><entry>2,3 jumpered</entry></row>
</tbody></tgroup></informaltable></para></listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>LED Codes</title>
<para>RedBoot uses the two digit LED display to indicate status during board
initialization. Possible codes are:</para>
 
<literallayout width=72>
LED Actions
-------------------------------------------------------------
Power-On/Reset
88
Set the CPSR
Enable coprocessor access
Drain write and fill buffer
Setup PBIU chip selects
A1
Enable the Icache
A2
Move FLASH chip select from 0x0 to 0xF0000000
Jump to new FLASH location
A3
Setup and enable the MMU
A4
I2C interface initialization
90
Wait for I2C initialization to complete
91
Send address (via I2C) to the DIMM
92
Wait for transmit complete
93
Read SDRAM PD data from DIMM
94
Read remainder of EEPROM data.
An error will result in one of the following
error codes on the LEDs:
77 BAD EEPROM checksum
55 I2C protocol error
FF bank size error
A5
Setup DDR memory interface
A6
Enable branch target buffer
Drain the write & fill buffers
Flush Icache, Dcache and BTB
Flush instuction and data TLBs
Drain the write & fill buffers
SL
ECC Scrub Loop
SE
A7
Clean, drain, flush the main Dcache
A8
Clean, drain, flush the mini Dcache
Flush Dcache
Drain the write & fill buffers
A9
Enable ECC
AA
Save SDRAM size
Move MMU tables into RAM
AB
Clean, drain, flush the main Dcache
Clean, drain, flush the mini Dcache
Drain the write & fill buffers
AC
Set the TTB register to DRAM mmu_table
AD
Set mode to IRQ mode
A7
Move SWI & Undefined "vectors" to RAM (at 0x0)
A6
Switch to supervisor mode
A5
Move remaining "vectors" to RAM (at 0x0)
A4
Copy DATA to RAM
Initialize interrupt exception environment
Initialize stack
Clear BSS section
A3
Call platform specific hardware initialization
A2
Run through static constructors
A1
Start up the eCos kernel or RedBoot
</literallayout>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>A special RedBoot command, <command>diag</command>, is used to
access a set of hardware diagnostics. To access the diagnostic menu,
enter <command>diag</command> at the RedBoot prompt:
<screen>
RedBoot> <userinput>diag</userinput>
Entering Hardware Diagnostics - Disabling Data Cache!
 
IQ80321 Hardware Tests
 
1 - Memory Tests
2 - Repeating Memory Tests
3 - Repeat-On-Fail Memory Tests
4 - Rotary Switch S1 Test
5 - 7 Segment LED Tests
6 - i82544 Ethernet Configuration
7 - Baterry Status Test
8 - Battery Backup SDRAM Memory Test
9 - Timer Test
10 - PCI Bus test
11 - CPU Cache Loop (No Return)
0 - quit
Enter the menu item number (0 to quit):
</screen>
Tests for various hardware subsystems are provided, and some tests require
special hardware in order to execute normally. The Ethernet Configuration
item may be used to set the board ethernet address.</para>
<sect3>
<title>Memory Tests</title>
<para>This test is used to test installed DDR SDRAM memory. Five different
tests are run over the given address ranges. If errors are encountered, the
test is aborted and information about the failure is printed. When selected,
the user will be prompted to enter the base address of the test range and its
size. The numbers must be in hex with no leading &ldquo;0x&rdquo;
</para>
<screen>
Enter the menu item number (0 to quit): <userinput>1</userinput>
 
Base address of memory to test (in hex): <userinput>100000</userinput>
 
Size of memory to test (in hex): <userinput>200000</userinput>
 
Testing memory from 0x00100000 to 0x002fffff.
 
Walking 1's test:
0000000100000002000000040000000800000010000000200000004000000080
0000010000000200000004000000080000001000000020000000400000008000
0001000000020000000400000008000000100000002000000040000000800000
0100000002000000040000000800000010000000200000004000000080000000
passed
32-bit address test: passed
32-bit address bar test: passed
8-bit address test: passed
Byte address bar test: passed
Memory test done.
</screen>
</sect3>
<sect3>
<title>Repeating Memory Tests</title>
<para>The repeating memory tests are exactly the same as the above memory tests,
except that the tests are automatically rerun after completion. The only way out
of this test is to reset the board.
</para>
</sect3>
<sect3>
<title>Repeat-On-Fail Memory Tests</title>
<para>This is similar to the repeating memory tests except that when an error
is found, the failing test continuously retries on the failing address.
</para>
</sect3>
<sect3>
<title>Rotary Switch S1 Test</title>
<para>This tests the operation of the sixteen position rotary switch. When run,
this test will display the current position of the rotary switch on the LED
display. Slowly dial through each position and confirm reading on LED.
</para>
</sect3>
<sect3>
<title>7 Segment LED Tests</title>
<para>This tests the operation of the seven segment displays. When run, each
LED cycles through 0 through F and a decimal point.
</para>
</sect3>
<sect3>
<title>i82544 Ethernet Configuration</title>
<para>This test initializes the ethernet controller&rsquo;s serial EEPROM if
the current contents are invalid. In any case, this test will also allow the
user to enter a six byte ethernet MAC address into the serial EEPROM.
</para>
<screen>
Enter the menu item number (0 to quit): <userinput>6</userinput>
 
 
Current MAC address: 00:80:4d:46:00:02
Enter desired MAC address: <userinput>00:80:4d:46:00:01</userinput>
Writing to the Serial EEPROM... Done
 
******** Reset The Board To Have Changes Take Effect ********
</screen>
</sect3>
<sect3>
<title>Battery Status Test</title>
<para>This tests the current status of the battery. First, the test checks to
see if the battery is installed and reports that finding. If the battery is
installed, the test further determines whether the battery status is one or
more of the following:
<itemizedlist>
<listitem><para>Battery is charging.</para></listitem>
<listitem><para>Battery is fully discharged.</para></listitem>
<listitem><para>Battery voltage measures within normal operating range.
</para></listitem>
</itemizedlist>
</para>
</sect3>
<sect3>
<title>Battery Backup SDRAM Memory Test</title>
<para>This tests the battery backup of SDRAM memory. This test is a three
step process:</para>
<orderedlist>
<listitem><para>Select Battery backup test from main diag menu, then write
data to SDRAM.</para></listitem>
<listitem><para>Turn off power for 60 seconds, then repower the board.
</para></listitem>
<listitem><para>Select Battery backup test from main diag menu, then check
data that was written in step 1.
</para></listitem>
</orderedlist>
</sect3>
<sect3>
<title>Timer Test</title>
<para>This tests the internal timer by printing a number of dots at one
second intervals.</para>
</sect3>
<sect3>
<title>PCI Bus Test</title>
<para>This tests the secondary PCI-X bus and socket. This test requires that
an IQ80310 board be plugged into the secondary slot of the IOP80321 board.
The test assumes at least 32MB of installed memory on the IQ80310. That memory
is mapped into the IOP80321 address space and the memory tests are run on that
memory.
</para>
</sect3>
<sect3>
<title>CPU Cache Loop</title>
<para>This test puts the CPU into a tight loop run entirely from the ICache.
This should prevent all external bus accesses.
</para>
</sect3>
</sect2>
<sect2>
<title>Rebuilding RedBoot </title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=iq80321
export ARCH_DIR=arm
export PLATFORM_DIR=xscale/iq80321
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
</sect2>
 
<sect2>
<title>Interrupts</title>
<para>RedBoot uses an interrupt vector table which is located at address 0x8004.
Entries in this table are pointers to functions with this protoype:: <programlisting>
int irq_handler( unsigned vector, unsigned data )</programlisting>On an IQ80321
board, the vector argument is one of 32 interrupts defined in <computeroutput>
hal/arm/xscale/verde/current/include/hal_var_ints.h:</computeroutput>: <programlisting>
// *** 80200 CPU ***
#define CYGNUM_HAL_INTERRUPT_DMA0_EOT 0
#define CYGNUM_HAL_INTERRUPT_DMA0_EOC 1
#define CYGNUM_HAL_INTERRUPT_DMA1_EOT 2
#define CYGNUM_HAL_INTERRUPT_DMA1_EOC 3
#define CYGNUM_HAL_INTERRUPT_RSVD_4 4
#define CYGNUM_HAL_INTERRUPT_RSVD_5 5
#define CYGNUM_HAL_INTERRUPT_AA_EOT 6
#define CYGNUM_HAL_INTERRUPT_AA_EOC 7
#define CYGNUM_HAL_INTERRUPT_CORE_PMON 8
#define CYGNUM_HAL_INTERRUPT_TIMER0 9
#define CYGNUM_HAL_INTERRUPT_TIMER1 10
#define CYGNUM_HAL_INTERRUPT_I2C_0 11
#define CYGNUM_HAL_INTERRUPT_I2C_1 12
#define CYGNUM_HAL_INTERRUPT_MESSAGING 13
#define CYGNUM_HAL_INTERRUPT_ATU_BIST 14
#define CYGNUM_HAL_INTERRUPT_PERFMON 15
#define CYGNUM_HAL_INTERRUPT_CORE_PMU 16
#define CYGNUM_HAL_INTERRUPT_BIU_ERR 17
#define CYGNUM_HAL_INTERRUPT_ATU_ERR 18
#define CYGNUM_HAL_INTERRUPT_MCU_ERR 19
#define CYGNUM_HAL_INTERRUPT_DMA0_ERR 20
#define CYGNUM_HAL_INTERRUPT_DMA1_ERR 22
#define CYGNUM_HAL_INTERRUPT_AA_ERR 23
#define CYGNUM_HAL_INTERRUPT_MSG_ERR 24
#define CYGNUM_HAL_INTERRUPT_SSP 25
#define CYGNUM_HAL_INTERRUPT_RSVD_26 26
#define CYGNUM_HAL_INTERRUPT_XINT0 27
#define CYGNUM_HAL_INTERRUPT_XINT1 28
#define CYGNUM_HAL_INTERRUPT_XINT2 29
#define CYGNUM_HAL_INTERRUPT_XINT3 30
#define CYGNUM_HAL_INTERRUPT_HPI 31
</programlisting>
The data passed to the ISR is pulled from a data table <computeroutput>(hal_interrupt_data)
</computeroutput> which immediately follows the interrupt vector table. With
32 interrupts, the data table starts at address 0x8084. </para>
<para>An application may create a normal C function with the above prototype
to be an ISR. Just poke its address into the table at the correct index and
enable the interrupt at its source. The return value of the ISR is ignored
by RedBoot.</para>
</sect2>
<sect2>
<title>Memory Maps</title>
<para>The RAM based page table is located at RAM start + 0x4000. RedBoot may be configured
for one of two memory maps. The difference between them is the location of RAM and the
PCI outbound windows. The alternative memory map may be used when
building RedBoot or eCos by using the <literal>RAM_ALTMAP</literal>
and <literal>ROM_ALTMAP</literal> startup types in the configuration.
<note><title>NOTE</title>
<para>The virtual memory maps in this section use a C, B, and X column to indicate
the caching policy for the region..</para>
</note></para>
<para><programlisting>
X C B Description
- - - ---------------------------------------------
0 0 0 Uncached/Unbuffered
0 0 1 Uncached/Buffered
0 1 0 Cached/Buffered Write Through, Read Allocate
0 1 1 Cached/Buffered Write Back, Read Allocate
1 0 0 Invalid -- not used
1 0 1 Uncached/Buffered No write buffer coalescing
1 1 0 Mini DCache - Policy set by Aux Ctl Register
1 1 1 Cached/Buffered Write Back, Read/Write Allocate
 
Physical Address Range Description
----------------------- ----------------------------------
0x00000000 - 0x7fffffff ATU Outbound Direct Window
0x80000000 - 0x900fffff ATU Outbound Translate Windows
0xa0000000 - 0xbfffffff SDRAM
0xf0000000 - 0xf0800000 FLASH (PBIU CS0)
0xfe800000 - 0xfe800fff UART (PBIU CS1)
0xfe840000 - 0xfe840fff Left 7-segment LED (PBIU CS3)
0xfe850000 - 0xfe850fff Right 7-segment LED (PBIU CS2)
0xfe8d0000 - 0xfe8d0fff Rotary Switch (PBIU CS4)
0xfe8f0000 - 0xfe8f0fff Baterry Status (PBIU CS5)
0xfff00000 - 0xffffffff Verde Memory mapped Registers
 
 
Default Virtual Map X C B Description
----------------------- - - - ----------------------------------
0x00000000 - 0x1fffffff 1 1 1 SDRAM
0x20000000 - 0x9fffffff 0 0 0 ATU Outbound Direct Window
0xa0000000 - 0xb00fffff 0 0 0 ATU Outbound Translate Windows
0xc0000000 - 0xdfffffff 0 0 0 Uncached alias for SDRAM
0xe0000000 - 0xe00fffff 1 1 1 Cache flush region (no phys mem)
0xf0000000 - 0xf0800000 0 1 0 FLASH (PBIU CS0)
0xfe800000 - 0xfe800fff 0 0 0 UART (PBIU CS1)
0xfe840000 - 0xfe840fff 0 0 0 Left 7-segment LED (PBIU CS3)
0xfe850000 - 0xfe850fff 0 0 0 Right 7-segment LED (PBIU CS2)
0xfe8d0000 - 0xfe8d0fff 0 0 0 Rotary Switch (PBIU CS4)
0xfe8f0000 - 0xfe8f0fff 0 0 0 Baterry Status (PBIU CS5)
0xfff00000 - 0xffffffff 0 0 0 Verde Memory mapped Registers
 
Alternate Virtual Map X C B Description
----------------------- - - - ----------------------------------
0x00000000 - 0x000fffff 1 1 1 Alias for 1st MB of SDRAM
0x00100000 - 0x7fffffff 0 0 0 ATU Outbound Direct Window
0x80000000 - 0x900fffff 0 0 0 ATU Outbound Translate Windows
0xa0000000 - 0xbfffffff 1 1 1 SDRAM
0xc0000000 - 0xdfffffff 0 0 0 Uncached alias for SDRAM
0xe0000000 - 0xe00fffff 1 1 1 Cache flush region (no phys mem)
0xf0000000 - 0xf0800000 0 1 0 FLASH (PBIU CS0)
0xfe800000 - 0xfe800fff 0 0 0 UART (PBIU CS1)
0xfe840000 - 0xfe840fff 0 0 0 Left 7-segment LED (PBIU CS3)
0xfe850000 - 0xfe850fff 0 0 0 Right 7-segment LED (PBIU CS2)
0xfe8d0000 - 0xfe8d0fff 0 0 0 Rotary Switch (PBIU CS4)
0xfe8f0000 - 0xfe8f0fff 0 0 0 Baterry Status (PBIU CS5)
0xfff00000 - 0xffffffff 0 0 0 Verde Memory mapped Registers
 
</programlisting></para>
</sect2>
<sect2>
<title>Platform Resource Usage</title>
<para>The Verde programmable timer0 is used for timeout support
for networking and XModem file transfers.</para>
</sect2></sect1>
 
<!-- ********************** CalmRISC ********************** -->
<?Pub _newpage>
<sect1 id="CalmRISC16">
<title>CalmRISC/CalmRISC16 Samsung CalmRISC16 Core Evaluation Board </title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Samsung CalmRISC16 Core EVB</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Samsung CalmRISC16 Core EVB</secondary></indexterm> The
Samsung CalmRISC16 evaluation platform consists of two boards connected by a
ribbon cable. One board contains the CPU core and memory. The other board is
called the MDSChip board and provides the host interface. The calmRISC16 is a
harvard architecture with separate 22-bit program and data addresses. The
instruction set provides no instruction for writing to program memory. The
MDSChip board firmware (called CalmBreaker) provides a pseudo register interface
so that code running on the core has access to a serial channel and a mechanism
to write to program memory. The serial channel is fixed at 57600-8-N-1 by the
firmware. The CalmBreaker firmware also provides a serial protocol which
allows a host to download a program and to start or stop the core board.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running via the MDSChip board.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>The CalmRISC16 core is controlled through the MDSChip board. There is
no non-volatile storage available for RedBoot, so RedBoot must be downloaded
to the board on every power cycle. A small utility program is used to download
S-record files to the eval board. Sources and build instructions for this
utility are located in the RedBoot sources in:
<filename class="directory">packages/hal/calmrisc16/ceb/current/support
</filename></para>
<para>To download the RedBoot image, first press the reset button on the MDSChip
board. The green 'Run' LED on the core board should go off. Now, use the
utility to download the RedBoot image with:
<screen>$ <userinput>calmbreaker -p /dev/term/b --reset --srec-code -f redboot.elf</userinput>
</screen>
Note that the '-p /dev/term/b' specifies the serial port to use and will vary
from system to system. The download will take about two minutes. After it
finishes, start RedBoot with:
<screen>$ <userinput>calmbreaker -p /dev/term/b --run</userinput></screen>
The 'Run' LED on the core board should be on. Connecting to the MDSboard with
a terminal and typing enter should result in RedBoot reprinting the command
prompt.
</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Special Note on Serial Channel </title>
<para>The MDSChip board uses a relatively slow microcontroller to provide
the pseudo-register interface to the core board. This pseudo-register
interface provides access to the serial channel and write access to program
memory. Those interfaces are slow and the serial channel is easily overrun
by a fast host. For this reason, GDB must be told to limit the size of code
download packets to avoid serial overrun. This is done with the following
GDB command:
<screen>(gdb) <userinput>set download-write-size 25</userinput></screen>
</para>
</sect2>
<sect2>
 
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=calm16_ceb
export ARCH_DIR=calmrisc16
export PLATFORM_DIR=ceb
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="CalmRISC32">
<title>CalmRISC/CalmRISC32 Samsung CalmRISC32 Core Evaluation Board </title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Samsung CalmRISC32 Core EVB</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Samsung CalmRISC32 Core EVB</secondary></indexterm> The
Samsung CalmRISC32 evaluation platform consists of two boards connected by a
ribbon cable. One board contains the CPU core and memory. The other board is
called the MDSChip board and provides the host interface. The calmRISC32 is a
harvard architecture with separate 32-bit program and data addresses. The
instruction set provides no instruction for writing to program memory. The
MDSChip board firmware (called CalmBreaker) provides a pseudo register interface
so that code running on the core has access to a serial channel and a mechanism
to write to program memory. The serial channel is fixed at 57600-8-N-1 by the
firmware. The CalmBreaker firmware also provides a serial protocol which
allows a host to download a program and to start or stop the core board.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running via the MDSChip board.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>The calmRISC32 core is controlled through the MDSChip board. There is
no non-volatile storage available for RedBoot, so RedBoot must be downloaded
to the board on every power cycle. A small utility program is used to download
S-record files to the eval board. Sources and build instructions for this
utility are located in the RedBoot sources in:
<filename class="directory">packages/hal/calmrisc32/ceb/current/support
</filename></para>
<para>To download the RedBoot image, first press the reset button on the MDSChip
board. The green 'Run' LED on the core board should go off. Now, use the
utility to download the RedBoot image with:
<screen>$ <userinput>calmbreaker -p /dev/term/b --reset --srec-code -f redboot.elf</userinput>
</screen>
Note that the '-p /dev/term/b' specifies the serial port to use and will vary
from system to syetm. The download will take about two minutes. After it
finishes, start RedBoot with:
<screen>$ <userinput>calmbreaker -p /dev/term/b --run</userinput></screen>
The 'Run' LED on the core board should be on. Connecting to the MDSboard with
a terminal and typing enter should result in RedBoot reprinting the command
prompt.
</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Special Note on Serial Channel </title>
<para>The MDSChip board uses a relatively slow microcontroller to provide
the pseudo-register interface to the core board. This pseudo-register
interface provides access to the serial channel and write access to program
memory. Those interfaces are slow and the serial channel is easily overrun
by a fast host. For this reason, GDB must be told to limit the size of code
download packets to avoid serial overrun. This is done with the following
GDB command:
<screen>(gdb) <userinput>set download-write-size 25</userinput></screen>
</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=calm32_ceb
export ARCH_DIR=calmrisc32
export PLATFORM_DIR=ceb
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<!-- ******************************** FRV ********************* -->
 
<?Pub _newpage>
<sect1 id="frv400">
<title>FRV/FRV400 Fujitsu FR-V 400 (MB-93091)</title>
<sect2>
<title>Overview</title>
 
<para><indexterm><primary>Fujitsu FR-V 400</primary>
<secondary>installing and testing</secondary></indexterm><indexterm><primary>
installing and testing
</primary><secondary>Fujitsu FR-V 400</secondary></indexterm>
RedBoot supports both serial ports, which are available via
the stacked serial connectors on the mother board.
The topmost port is the default and is considered to be port 0 by RedBoot.
The bottommost port is serial port 1.
The default serial port settings are 38400,8,N,1.
</para>
<para>
FLASH management is also supported, but only for the FLASH device in IC7.
This arrangement allows for IC8 to retain either the original Fujitsu board
firmware, or some application specific contents.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector.</entry>
<entry>redboot_ROMRAM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
 
<sect2>
<title>Initial Installation Method </title>
 
<para>
RedBoot can be installed by directly programming the FLASH device in IC7
or by using the Fujitsu provided software to download and install a
version into the FLASH device. Complete instructions are provided
separately.
</para>
 
</sect2>
 
<sect2>
<title>Special RedBoot Commands</title>
 
<para>None.</para>
</sect2>
 
<sect2>
<title>Memory Maps</title>
 
<para>The memory map of this platform is fixed by the hardware (cannot
be changed by software). The only attributes which can be modified are
control over cacheability, as noted below.
<screen>
Address Cache? Resource
00000000-03EFFFFF Yes SDRAM (via plugin DIMM)
03F00000-03FFFFFF No SDRAM (used for PCI window)
10000000-1FFFFFFF No MB86943 PCI bridge
20000000-201FFFFF No SRAM
21000000-23FFFFFF No Motherboard resources
24000000-25FFFFFF No PCI I/O space
26000000-2FFFFFFF No PCI Memory space
30000000-FDFFFFFF ?? Unused
FE000000-FEFFFFFF No I/O devices
FF000000-FF1FFFFF No IC7 - RedBoot FLASH
FF200000-FF3FFFFF No IC8 - unused FLASH
FF400000-FFFFFFFF No Misc other I/O
</screen>
</para>
 
<note> <title>NOTE</title>
<para>
The only configuration currently suppored requires a 64MB SDRAM
DIMM to be present on the CPU card. No other memory configuration
is supported at this time.
</para>
</note>
 
</sect2>
 
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=frv400
export ARCH_DIR=frv
export PLATFORM_DIR=frv400
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
</sect2>
 
</sect1>
 
<!-- ********************************* IA32 *************************** -->
<?Pub _newpage>
<sect1 id="x86pc">
<title>IA32/x86 x86-Based PC</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>x86 Based PC</primary><secondary>installing and
testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>x86 Based PC</secondary></indexterm>RedBoot supports
two serial ports and an Intel i82559 based ethernet card (for example an Intel
EtherExpress Pro 10/100) for communication and downloads. The default serial
port settings are 38400,8,N,1.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>Floppy</entry>
<entry>[Floppy]</entry>
<entry>RedBoot running from a boot floppy disk installed
in the A: drive of the PC.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation</title>
<para>RedBoot takes the form of a self-booting image that must be written
onto a formatted floppy disk. The process will erase any file system or data
that already exists on that disk, so proceed with caution.</para>
<para>For Red Hat Linux users, this can be done by:</para>
<screen>$ <userinput>dd conv=sync if=install/bin/redboot.bin of=/dev/fd0H1440
</userinput></screen>
<para>For NT Cygwin users, this can be done by first ensuring that the raw
floppy device is mounted as <filename>/dev/fd0</filename>. To check if this
is the case, type the command <command>mount</command> at the Cygwin bash
prompt. If the floppy drive is already mounted, it will be listed as something
similar to the following line:</para>
<screen> \\.\a: /dev/fd0 user binmode</screen>
<para>If this line is not listed, then mount the floppy drive using the command:
</para>
<screen>$ <userinput>mount -f -b //./a: /dev/fd0</userinput></screen>
<para>To actually install the boot image on the floppy, use the command:</para>
<screen>$ <userinput>dd conv=sync if=install/bin/redboot.bin of=/dev/fd0
</userinput></screen>
<para>Insert this floppy in the A: drive of the PC to be used as a target
and ensure that the BIOS is configured to boot from A: by default. On reset,
the PC will boot from the floppy and be ready to be debugged via either serial
line, or via the ethernet interface if it is installed.</para>
<note><title>NOTE</title>
<para>Unreliable floppy media may cause the write to silently fail. This
can be determined if the RedBoot image does not correctly
boot. In such cases, the floppy should be (unconditionally) reformatted
using the <command>fdformat</command> command on Linux, or
<command>format a: /u</command> on DOS/Windows.</para>
</note>
</sect2>
<sect2>
<title>Flash management</title>
<para>PC RedBoot does not support any FLASH commands.</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>All selectors are initialized to map the entire 32-bit address space
in the familiar protected mode flat model. Page translation is not used.
RAM up to 640K is mapped to 0x0 to 0xa0000. RAM above 640K is mapped
from address 0x100000 upwards. Space is reserved between 0xa0000 and
0x100000 for option ROMs and the BIOS.
</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=pc
export ARCH_DIR=i386
export PLATFORM_DIR=pc
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<!-- *************** MIPS ******************* -->
 
<?Pub _newpage>
<sect1 id="atlas">
<title>MIPS/MIPS32(CoreLV 4Kc)+MIPS64(CoreLV 5Kc) Atlas Board</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>MIPS Atlas Board with CoreLV 4KC and CoreLV 5KC
</primary><secondary>installing and testing</secondary></indexterm><indexterm>
<primary>installing and testing</primary><secondary>MIPS Atlas Board with
CoreLV 4KC and CoreLV 5KC</secondary></indexterm>RedBoot supports the DgbSer
serial port and the built in ethernet port for communication and downloads.
The default serial port settings are 115200,8,N,1. RedBoot runs from and supports
flash management for the system flash region.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation</title>
<para>RedBoot is installed using the code download facility built into the
Atlas board. See the Atlas User manual for details, and also the Atlas download
format in <xref linkend="Atlas-download-format">.</para>
<sect3>
<title>Quick download instructions</title>
<para>Here are quick start instructions for downloading the prebuilt RedBoot
image.</para>
<orderedlist>
<listitem><para>Locate the prebuilt files in the bin directory: <filename>
deleteall.dl</filename> and <filename>redboot.dl</filename>.
</para>
</listitem>
<listitem><para>Make sure switch S1-1 is OFF and switch S5-1 is ON. Reset
the board and verify that the LED display reads <computeroutput>Flash DL</computeroutput>.
</para>
</listitem>
<listitem><para>Make sure your parallel port is connected to the 1284 port
Of the Atlas board. </para>
</listitem>
<listitem><para>Send the <filename>deleteall.dl</filename> file to the
parallel port to erase previous images:
<screen>$ <userinput>cat deleteall.dl >/dev/lp0</userinput></screen>
When this is complete, the LED display should read
<computeroutput>Deleted</computeroutput>.</para>
</listitem>
<listitem><para>Send the ROM mode RedBoot image to the board:
<screen>$ <userinput>cat redboot.dl >/dev/lp0</userinput></screen>
When this is complete, the LED display should show the last
address programmed. This will be something like: <computeroutput>1fc17000
</computeroutput>. </para>
</listitem>
<listitem><para>Change switch S5-1 to OFF and reset the board. The LED display
should read <computeroutput>RedBoot</computeroutput>. </para>
</listitem>
<listitem><para>Run the RedBoot <command>fis init</command>
and <command>fconfig</command> commands to initialize the flash.
See <xref linkend="Atlas-Additional-fconfig-options">, <xref linkend="Flash-Image-System">
and <xref linkend="Persistent-State-Flash"> for details. </para>
</listitem>
</orderedlist>
</sect3>
<sect3 id="Atlas-download-format">
<title>Atlas download format</title>
<para>In order to download RedBoot to the Atlas board, it must be converted
to the Atlas download format. There are different ways of doing this depending
on which version of the developer's kit is shipped with the board. </para>
<para>The <citetitle>Atlas Developer's Kit</citetitle> CD contains an <application>
srec2flash</application> utility. The source code for this utility is part
of the <filename>yamon/yamon-src-01.01.tar.gz</filename> tarball
on the Dev Kit CD. The path in the expanded tarball is <filename
class="directory">yamon/bin/tools</filename>. To use
<application>srec2flash</application> to convert the S-record file:
<screen>$ <userinput>srec2flash -EL -S29 redboot.srec >redboot.dl</userinput></screen>
The <citetitle>Atlas/Malta Developer's Kit</citetitle> CD
contains an <application>srecconv.pl</application> utility which requires
Perl. This utilty is part of the <filename>yamon/yamon-src-02.00.tar.gz</filename>
tarball on the Dev Kit CD. The path in the expanded tarball
is <filename class="directory">yamon/bin/tools</filename>. To use <application>
srecconv</application> to convert the S-record file:
<screen>$ <userinput>cp redboot_ROM.srec redboot_ROM.rec</userinput>
$ <userinput>srecconv.pl -ES L -A 29 redboot_ROM</userinput></screen>
The resulting file is named <filename>redboot_ROM.fl</filename>.</para>
</sect3></sect2>
<sect2>
<title>Flash management</title>
<sect3 id="Atlas-Additional-fconfig-options">
<title>Additional config options</title>
<para>The ethernet MAC address is stored in flash manually using the <command>
fconfig</command> command. You can use the YAMON <command>setenv
ethaddr</command> command to print out the board ethernet address.
Typically, it is: <screen>00:0d:a0:00:<replaceable>xx:xx</replaceable></screen> where
<replaceable>xx.xx</replaceable> is the hex representation of the
board serial number.</para>
</sect3>
</sect2>
<sect2>
<title>Additional commands</title>
<para>The <command>exec</command> command which allows the
loading and execution of Linux kernels, is supported for this architecture
(see <xref linkend="executing-programs">). The
<command>exec</command> parameters used for MIPS boards are:</para>
<variablelist><varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Location to store command line and environment passed to kernel</para></listitem></varlistentry>
<varlistentry><term>
-w <replaceable>&lt;time></replaceable></term>
<listitem><para>Wait time in seconds before starting kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term><replaceable>&lt;addr></replaceable></term>
<listitem><para>Kernel entry point, defaulting to the entry point of the last image
loaded</para></listitem></varlistentry>
</variablelist>
<para>Linux kernels on MIPS platforms expect the entry point to be called with arguments
in the registers equivalent to a C call with prototype:
<programlisting>void Linux(int argc, char **argv, char **envp);</programlisting></para>
<para>RedBoot will place the appropriate data at the offset specified by the
<parameter>-b</parameter> parameter, or by default at address 0x80080000, and will set the
arguments accordingly when calling into the kernel.</para>
<para>
The default entry point, if no image with explicit entry point has been loaded and
none is specified, is 0x80000750.
</para>
</sect2>
 
<sect2>
<title>Interrupts</title>
<para>RedBoot uses an interrupt vector table which is located at address 0x80000400.
Entries in this table are pointers to functions with this protoype: <programlisting>
int irq_handler( unsigned vector, unsigned data )</programlisting>On an atlas
board, the vector argument is one of 25 interrupts defined in <computeroutput>
hal/mips/atlas/<replaceable>VERSION</replaceable>/include/plf_intr.h</computeroutput>: <programlisting>
#define CYGNUM_HAL_INTERRUPT_SER 0
#define CYGNUM_HAL_INTERRUPT_TIM0 1
#define CYGNUM_HAL_INTERRUPT_2 2
#define CYGNUM_HAL_INTERRUPT_3 3
#define CYGNUM_HAL_INTERRUPT_RTC 4
#define CYGNUM_HAL_INTERRUPT_COREHI 5
#define CYGNUM_HAL_INTERRUPT_CORELO 6
#define CYGNUM_HAL_INTERRUPT_7 7
#define CYGNUM_HAL_INTERRUPT_PCIA 8
#define CYGNUM_HAL_INTERRUPT_PCIB 9
#define CYGNUM_HAL_INTERRUPT_PCIC 10
#define CYGNUM_HAL_INTERRUPT_PCID 11
#define CYGNUM_HAL_INTERRUPT_ENUM 12
#define CYGNUM_HAL_INTERRUPT_DEG 13
#define CYGNUM_HAL_INTERRUPT_ATXFAIL 14
#define CYGNUM_HAL_INTERRUPT_INTA 15
#define CYGNUM_HAL_INTERRUPT_INTB 16
#define CYGNUM_HAL_INTERRUPT_INTC 17
#define CYGNUM_HAL_INTERRUPT_INTD 18
#define CYGNUM_HAL_INTERRUPT_SERR 19
#define CYGNUM_HAL_INTERRUPT_HW1 20
#define CYGNUM_HAL_INTERRUPT_HW2 21
#define CYGNUM_HAL_INTERRUPT_HW3 22
#define CYGNUM_HAL_INTERRUPT_HW4 23
#define CYGNUM_HAL_INTERRUPT_HW5 24</programlisting>The data
passed to the ISR is pulled from a data table (<computeroutput>hal_interrupt_data
</computeroutput>) which immediately follows the interrupt vector table. With
25 interrupts, the data table starts at address 0x80000464 on atlas.</para>
<para>An application may create a normal C function with the above prototype
to be an ISR. Just poke its address into the table at the correct index and
enable the interrupt at its source. The return value of the ISR is ignored
by RedBoot. </para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>Memory Maps RedBoot sets up the following memory map on the Atlas board.
<programlisting>Physical Address Range Description
----------------------- -------------
0x00000000 - 0x07ffffff SDRAM
0x08000000 - 0x17ffffff PCI Memory Space
0x18000000 - 0x1bdfffff PCI I/O Space
0x1be00000 - 0x1bffffff System Controller
0x1c000000 - 0x1dffffff System flash
0x1e000000 - 0x1e3fffff Monitor flash
0x1f000000 - 0x1fbfffff FPGA</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=atlas_mips32_4kc
export TARGET=atlas_mips64_5kc
export ARCH_DIR=mips
export PLATFORM_DIR=atlas
</programlisting>
 
Use one of the TARGET settings only.
 
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="malta">
<title>MIPS/MIPS32(CoreLV 4Kc)+MIPS64(CoreLV 5Kc) Malta Board </title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>MIPS Malta Board with CoreLV 4KC and CoreLV 5KC
</primary><secondary>installing and testing</secondary></indexterm><indexterm>
<primary>installing and testing</primary><secondary>MIPS Malta Board with
CoreLV 4KC and CoreLV 5KC</secondary></indexterm>RedBoot supports both front
facing serial ports and the built in ethernet port for communication and downloads.
The default serial port settings are 38400,8,N,1. RedBoot runs from and supports
flash management for the system flash region.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation</title>
<para>RedBoot is installed using the code download facility built into the
Malta board. See the Malta User manual for details, and also the Malta download
format in <xref linkend="Malta-download-format">.</para>
<sect3>
<title>Quick download instructions</title>
<para>Here are quick start instructions for downloading the prebuilt RedBoot
image. </para>
<orderedlist>
<listitem><para>Locate the prebuilt files in the bin directory: <filename>
deleteall.fl</filename> and <filename>redboot_ROM.fl</filename>. </para>
</listitem>
<listitem><para>Make sure switch S5-1 is ON. Reset the board and verify that
the LED display reads <computeroutput>Flash DL</computeroutput>. </para>
</listitem>
<listitem><para>Make sure your parallel port is connected to the 1284 port
Of the Atlas board. </para>
</listitem>
<listitem><para>Send the <filename>deleteall.fl</filename> file to the
parallel port to erase previous images:
<screen>$ <userinput>cat deleteall.fl >/dev/lp0</userinput></screen>
When this is complete, the LED display should read
<computeroutput>Deleted</computeroutput>.</para>
</listitem>
<listitem><para>Send the RedBoot image to the board:
<screen>$ <userinput>cat redboot_ROM.fl >/dev/lp0</userinput></screen>
When this is complete, the LED display should show the last address
programmed. This will be something like:
<computeroutput>1fc17000</computeroutput>. </para>
</listitem>
<listitem><para>Change switch S5-1 to OFF and reset the board. The LED display
should read <computeroutput>RedBoot</computeroutput>. </para>
</listitem>
<listitem><para>Run the RedBoot <command>fis init</command> and <command>
fconfig</command> commands to initialize the flash. See <xref linkend="Flash-Image-System">
and <xref linkend="Persistent-State-Flash"> for details. </para>
</listitem>
</orderedlist>
</sect3>
<sect3 id="malta-download-format">
<title>Malta download format</title>
<para>In order to download RedBoot to the Malta board, it must be converted
to the Malta download format.</para>
<para>The <citetitle>Atlas/Malta Developer's Kit</citetitle> CD contains an <application>
srecconv.pl</application> utility which requires Perl. This utility is part
of the <filename>yamon/yamon-src-02.00.tar.gz</filename> tarball
on the Dev Kit CD. The path in the expanded tarball is <filename
class="directory">yamon/bin/tools</filename>. To use
<application>srecconv</application> to convert the S-record file:
<screen>$ <userinput>cp redboot_ROM.srec redboot_ROM.rec</userinput>
$ <userinput>srecconv.pl -ES L -A 29 redboot_ROM</userinput></screen>
The resulting file is named <filename>redboot_ROM.fl</filename>.</para>
</sect3></sect2>
 
<sect2>
<title>Additional commands</title>
<para>The <command>exec</command> command which allows the
loading and execution of Linux kernels, is supported for this architecture
(see <xref linkend="executing-programs">). The
<command>exec</command> parameters used for MIPS boards are:</para>
<variablelist><varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Location to store command line and environment passed to kernel</para></listitem></varlistentry>
<varlistentry><term>
-w <replaceable>&lt;time></replaceable></term>
<listitem><para>Wait time in seconds before starting kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term><replaceable>&lt;addr></replaceable></term>
<listitem><para>Kernel entry point, defaulting to the entry point of the last image
loaded</para></listitem></varlistentry>
</variablelist>
<para>Linux kernels on MIPS platforms expect the entry point to be called with arguments
in the registers equivalent to a C call with prototype:
<programlisting>void Linux(int argc, char **argv, char **envp);</programlisting></para>
<para>RedBoot will place the appropriate data at the offset specified by the
<parameter>-b</parameter> parameter, or by default at address 0x80080000, and will set the
arguments accordingly when calling into the kernel.</para>
<para>
The default entry point, if no image with explicit entry point has been loaded and
none is specified, is 0x80000750.
</para>
</sect2>
 
<sect2>
<title>Interrupts</title>
<para>RedBoot uses an interrupt vector table which is located at address 0x80000200.
Entries in this table are pointers to functions with this protoype: <programlisting>
int irq_handler( unsigned vector, unsigned data )</programlisting>On the malta
board, the vector argument is one of 22 interrupts defined in <computeroutput>
hal/mips/malta/<replaceable>VERSION</replaceable>/include/plf_intr.h</computeroutput>: <programlisting>
 
#define CYGNUM_HAL_INTERRUPT_SOUTH_BRIDGE_INTR 0
#define CYGNUM_HAL_INTERRUPT_SOUTH_BRIDGE_SMI 1
#define CYGNUM_HAL_INTERRUPT_CBUS_UART 2
#define CYGNUM_HAL_INTERRUPT_COREHI 3
#define CYGNUM_HAL_INTERRUPT_CORELO 4
#define CYGNUM_HAL_INTERRUPT_COMPARE 5
#define CYGNUM_HAL_INTERRUPT_TIMER 6
#define CYGNUM_HAL_INTERRUPT_KEYBOARD 7
#define CYGNUM_HAL_INTERRUPT_CASCADE 8
#define CYGNUM_HAL_INTERRUPT_TTY1 9
#define CYGNUM_HAL_INTERRUPT_TTY0 10
#define CYGNUM_HAL_INTERRUPT_11 11
#define CYGNUM_HAL_INTERRUPT_FLOPPY 12
#define CYGNUM_HAL_INTERRUPT_PARALLEL 13
#define CYGNUM_HAL_INTERRUPT_REAL_TIME_CLOCK 14
#define CYGNUM_HAL_INTERRUPT_I2C 15
#define CYGNUM_HAL_INTERRUPT_PCI_AB 16
#define CYGNUM_HAL_INTERRUPT_PCI_CD 17
#define CYGNUM_HAL_INTERRUPT_MOUSE 18
#define CYGNUM_HAL_INTERRUPT_19 19
#define CYGNUM_HAL_INTERRUPT_IDE_PRIMARY 20
#define CYGNUM_HAL_INTERRUPT_IDE_SECONDARY 21</programlisting>The data
passed to the ISR is pulled from a data table (<computeroutput>hal_interrupt_data
</computeroutput>) which immediately follows the interrupt vector table. With
22 interrupts, the data table starts at address 0x80000258.</para>
<para>An application may create a normal C function with the above prototype
to be an ISR. Just poke its address into the table at the correct index and
enable the interrupt at its source. The return value of the ISR is ignored
by RedBoot. </para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>Memory Maps RedBoot sets up the following memory map on the Malta board.<note>
<title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Physical Address Range C B Description
----------------------- - - -----------
0x80000000 - 0x81ffffff Y Y SDRAM
0x9e000000 - 0x9e3fffff Y N System flash (cached)
0x9fc00000 - 0x9fffffff Y N System flash (mirrored)
0xa8000000 - 0xb7ffffff N N PCI Memory Space
0xb4000000 - 0xb40fffff N N Galileo System Controller
0xb8000000 - 0xb80fffff N N Southbridge / ISA
0xb8100000 - 0xbbdfffff N N PCI I/O Space
0xbe000000 - 0xbe3fffff N N System flash (noncached)
0xbf000000 - 0xbfffffff N N Board logic FPGA</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=malta_mips32_4kc
export ARCH_DIR=mips
export PLATFORM_DIR=malta
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2></sect1>
<?Pub _newpage>
<sect1 id="ocelot">
<title>MIPS/RM7000 PMC-Sierra Ocelot</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>PMC-Sierra MIPS RM7000 Ocelot</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>PMC-Sierra MIPS RM7000 Ocelot</secondary></indexterm>RedBoot
uses the front facing serial port. The default serial port settings are 38400,8,N,1.
RedBoot also supports ethernet. Management of onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
 
<sect2>
<title>Additional commands</title>
<para>The <command>exec</command> command which allows the
loading and execution of Linux kernels, is supported for this architecture
(see <xref linkend="executing-programs">). The
<command>exec</command> parameters used for MIPS boards are:</para>
<variablelist><varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Location to store command line and environment passed to kernel</para></listitem></varlistentry>
<varlistentry><term>
-w <replaceable>&lt;time></replaceable></term>
<listitem><para>Wait time in seconds before starting kernel</para></listitem></varlistentry>
<varlistentry><term>
-c <replaceable>"params"</replaceable></term>
<listitem><para>Parameters passed to kernel</para></listitem></varlistentry>
<varlistentry><term><replaceable>&lt;addr></replaceable></term>
<listitem><para>Kernel entry point, defaulting to the entry point of the last image
loaded</para></listitem></varlistentry>
</variablelist>
<para>Linux kernels on MIPS platforms expect the entry point to be called with arguments
in the registers equivalent to a C call with prototype:
<programlisting>void Linux(int argc, char **argv, char **envp);</programlisting></para>
<para>RedBoot will place the appropriate data at the offset specified by the
<parameter>-b</parameter> parameter, or by default at address 0x80080000, and will set the
arguments accordingly when calling into the kernel.</para>
<para>
The default entry point, if no image with explicit entry point has been loaded and
none is specified, is 0x80000750.
</para>
</sect2>
 
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the Ocelot board. </para>
<para>Note that these addresses are accessed through kseg0/1 and thus translate
to the actual address range 0x80000000-0xbfffffff, depending on the need for
caching/non-caching access to the bus.<note><title>NOTE</title>
<para>The virtual memory maps in this section use a C and B column to indicate
whether or not the region is cached (C) or buffered (B).</para>
</note><programlisting>Physical Address Range Description
----------------------- -----------
0x00000000 - 0x0fffffff SDRAM
0x10000000 - 0x10ffffff PCI I/O space
0x12000000 - 0x13ffffff PCI Memory space
0x14000000 - 0x1400ffff Galileo system controller
0x1c000000 - 0x1c0000ff PLD (board logic)
0x1fc00000 - 0x1fc7ffff flash</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=ocelot
export ARCH_DIR=mips
export PLATFORM_DIR=rm7000/ocelot
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2></sect1>
 
 
<?Pub _newpage>
<sect1 id="vrc4375">
<title>MIPS/VR4375 NEC DDB-VRC4375</title>
<sect2>
<title>Overview</title>
 
<para><indexterm><primary>NEC DDB-VRC4375</primary>
<secondary>installing and testing</secondary></indexterm><indexterm><primary>
installing and testing</primary><secondary>NEC DDB-VRC4375
</secondary></indexterm>RedBoot supports only serial port 1, which is connected to the upper
of the stacked serial connectors on the board. The default serial
port settings are 38400,8,N,1. FLASH management is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector.</entry>
<entry>redboot_ROMRAM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
 
<sect2>
<title>Initial Installation Method </title>
 
<para>A device programmer should be used to program a socketed FLASH part
(AMD 29F040). The board as delivered is configured for a 512K
EPROM. To install a FLASH ROM, Jumpers J30, J31 and J36 need to be
changed as described in the board's User Manual.</para>
</sect2>
 
<sect2>
<title>Special RedBoot Commands</title>
 
<para>None.</para>
</sect2>
 
<sect2>
<title>Memory Maps</title>
 
<para>RedBoot sets up the memory map primarily as described in the board's
User Manual. There are some minor differences, noted in the following
table:
<screen>
Physical Virtual Resource
Addresses Addresses
00000000-01FFFFFF 80000000-81FFFFFF Base SDRAM (cached)
00000000-01FFFFFF A0000000-A1FFFFFF Base SDRAM (uncached)
0C000000-0C0BFFFF AC000000-AC0B0000 PCI IO space
0F000000-0F0001FF AF000000-AF0001FF VRC4375 Registers
1C000000-1C0FFFFF BC000000-BC0FFFFF VRC4372 Registers
1C100000-1DFFFFFF BC100000-BDFFFFFF PCI Memory space
1FC00000-1FC7FFFF BFC00000-BFC7FFFF FLASH ROM
80000000-8000000D C0000000-C000000D RTC
8000000E-80007FFF C000000E-C0007FFF NVRAM
81000000-81FFFFFF C1000000-C1FFFFFF Z85C30 DUART
82000000-82FFFFFF C2000000-C2FFFFFF Z8536 Timer
83000000-83FFFFFF C3000000-C3FFFFFF 8255 Parallel port
87000000-87FFFFFF C7000000-C7FFFFFF Seven segment display</screen>
</para>
 
<note> <title>NOTE</title>
<para>
By default the VRC4375 SIMM control registers are not programmed
since the values used must depend on the SIMMs installed. If SIMMs
are to be used, correct values must be placed in these registers
before accessing the SIMM address range.
</para>
</note>
 
<note> <title>NOTE</title>
<para>
The allocation of address ranges to devices in the PCI IO and
memory spaces is handled by the eCos PCI support library. They do
not correspond to those described in the board User Manual.
</para>
</note>
 
<note> <title>NOTE</title>
<para>
The MMU has been set up to relocate the VRC4372 supported devices
mapped at physical addresses 0x8xxxxxxx to virtual addresses
0xCxxxxxxx.
</para>
</note>
 
</sect2>
 
<sect2>
<title>Ethernet Driver</title>
 
<para>
The ethernet driver is in two parts:
</para>
 
<para>
A generic ether driver for the Intel i21143 device is located in
<filename class="directory">devs/eth/intel/i21143</filename>. Its package name is <computeroutput>CYGPKG_DEVS_ETH_INTEL_I21143</computeroutput>.
</para>
 
<para>
The platform-specific ether driver is <filename
class="directory">devs/eth/mips/vrc4375</filename>. Its package is
<computeroutput>CYGPKG_DEVS_ETH_MIPS_VRC4375</computeroutput>. This
tells the generic driver the address in IO memory of the chip, for
example, and other configuration details. The ESA (MAC address) is by
default collected from on-board serial EEPROM, unless configured
statically within this package.
</para>
</sect2>
 
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=vrc4373
export ARCH_DIR=mips
export PLATFORM_DIR=vrc4373
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<!-- ************************** PowerPC ********************** -->
 
<?Pub _newpage>
<sect1 id="viper">
<title>PowerPC/MPC860T Analogue & Micro PowerPC 860T</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Analogue & Micro PowerPC 860T</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Analogue & Micro PowerPC 860T</secondary></indexterm>RedBoot uses
the SMC1 serial port. The default serial port settings are 38400,8,N,1.
Ethernet is also supported using the RJ-45 connector. Management of
onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROMRAM</entry>
<entry>[ROMRAM]</entry>
<entry>RedBoot running from RAM, but contained in the
board's flash boot sector.</entry>
<entry>redboot_ROMRAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>RedBoot must be installed at the A & M factory.
</para>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>Memory Maps RedBoot sets up the following memory map on the MBX board.<programlisting>
Physical Address Range Description
----------------------- -----------
0x00000000 - 0x007fffff DRAM
0xfe000000 - 0xfe0fffff flash (AMD29LV8008B)
0xff000000 - 0xff0fffff MPC registers</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=viper
export ARCH_DIR=powerpc
export PLATFORM_DIR=viper
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="mbx">
<title>PowerPC/MPC8XX Motorola MBX</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Motorola PowerPC MBX</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Motorola PowerPC MBX</secondary></indexterm>RedBoot uses
the SMC1/COM1 serial port. The default serial port settings are 38400,8,N,1.
Ethernet is also supported using the 10-base T connector. </para>
<para>Management of onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>Device programmer is used to program the XU1 socketed flash part (AM29F040B)
with the ROM mode image of RedBoot. Use the on-board EPPC-Bug monitor to update
RedBoot. </para>
<para>This assumes that you have EPPC-Bug in the on-board flash. This can
be determined by setting up the board according to the following instructions
and powering up the board. </para>
<para>The EPPC-Bug prompt should appear on the SMC1 connector at 9600 baud,
8N1. </para>
<orderedlist>
<listitem><para>Set jumper 3 to 2-3 [allow XU1 flash to be programmed] </para>
</listitem>
<listitem><para>Set jumper 4 to 2-3 [boot EPPC-Bug] </para>
</listitem>
</orderedlist>
<para>If it is available, program the flash by following these steps: </para>
<orderedlist>
<listitem><para>Prepare EPPC-Bug for download: <screen>EPPC-Bug><userinput>lo 0</userinput>
</screen>At this point the monitor is ready for input. It will not
return the prompt until the file has been downloaded. </para>
</listitem>
<listitem><para>Use the terminal emulator's ASCII download feature (or a simple
clipboard copy/paste operation) to download the
<filename>redboot.ppcbug</filename> file.</para>
<para>Note that on Linux, <application>Minicom</application>'s ASCII
download feature seems to be broken. A workaround is to load the file
into <application>emacs</application> (or another editor) and copy the
full contents to the clipboard. Then press the mouse paste-button (usually
the middle one) over the <application>Minicom</application> window. </para>
</listitem>
<listitem><para>Program the flash with the downloaded data: <screen>
EPPC-Bug><userinput>pflash 40000 60000 fc000000</userinput></screen></para>
</listitem>
<listitem><para>Switch off the power, and change jumper 4 to 1-2. Turn on
the power again. The board should now boot using the newly programmed RedBoot.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>None.</para>
</sect2>
<sect2>
<title>Memory Maps </title>
<para>Memory Maps RedBoot sets up the following memory map on the MBX board.<programlisting>
Physical Address Range Description
----------------------- -----------
0x00000000 - 0x003fffff DRAM
0xfa100000 - 0xfa100003 LEDs
0xfe000000 - 0xfe07ffff flash (AMD29F040B)
0xff000000 - 0xff0fffff MPC registers</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=mbx
export ARCH_DIR=powerpc
export PLATFORM_DIR=mbx
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
 
 
 
<!-- ********************** SuperH ************************ -->
 
 
 
<?Pub _newpage>
<sect1 id="edk7708">
<title>SuperH/SH3(SH7708) Hitachi EDK7708</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Hitachi SH EDK7708</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Hitachi SH EDK7708</secondary></indexterm>RedBoot uses
the serial port. The default serial port settings are 38400,8,N,1.</para>
<para>Management of onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>Program the ROM RedBoot image into flash using an eprom programmer.</para>
 
</sect2>
 
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the EDK7708 board.<programlisting>
Physical Address Range Description
----------------------- -----------
0x80000000 - 0x8001ffff Flash (AT29LV1024)
0x88000000 - 0x881fffff DRAM
0xa4000000 - 0xa40000ff LED ON
0xb8000000 - 0xb80000ff LED ON
</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=edk7708
export ARCH_DIR=sh
export PLATFORM_DIR=edk7708
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
 
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="se7709">
<title>SuperH/SH3(SH7709) Hitachi Solution Engine 7709</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Hitachi SH SE7709</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Hitachi SH SE7709</secondary></indexterm>This
description covers the MS7709SE01 variant. See <xref linkend="se77x9">
for instructions for the MS7729SE01 and MS7709SSE0101 variants.</para>
 
<para>RedBoot uses
the COM1 and COM2 serial ports. The default serial port settings are 38400,8,N,1.
Ethernet is also supported using the 10-base T connector. </para>
<para>Management of onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>The Solution Engine ships with the Hitachi boot monitor in EPROM
which allows for initial programming of RedBoot:</para>
 
<orderedlist>
<listitem><para>Set switch SW4-1 to ON [boot from EPROM]</para>
</listitem>
<listitem><para>Connect a serial cable to CN1 (SCI) and power up the board.</para>
</listitem>
<listitem><para>After the boot monitor banner, invoke the flash
download/program command:<screen>Ready &gt;<userinput>fl</userinput></screen></para>
</listitem>
<listitem><para>The monitor should now ask for input:
<screen>Flash ROM data copy to RAM
Please Send A S-format Record</screen>At this point copy the
RedBoot ROM SREC file to the serial port:<screen>
$ <userinput>cat redboot_SE7709RP_ROM.eprom.srec &gt /dev/ttyS0</userinput></screen>
Eventually you
should see something like<screen>Start Addrs = A1000000
End Addrs = A1xxxxxx
Transfer complete</screen> from the monitor.
</para></listitem>
<listitem><para>Set switch SW4-1 to OFF [boot from flash] and reboot the board. You
should now see the RedBoot banner.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the SE77x9 are:</para>
<variablelist>
<varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Parameter block address. This is normally the first
page of the kernel image and defaults to 0x8c101000</para></listitem></varlistentry>
 
<varlistentry><term>-i <replaceable>&lt;addr></replaceable></term>
<listitem><para>Start address of initrd
image</para></listitem></varlistentry>
 
<varlistentry><term>-j <replaceable>&lt;size></replaceable></term>
<listitem><para>Size of initrd image</para></listitem></varlistentry>
 
<varlistentry><term>-c <replaceable>"args"</replaceable></term>
<listitem><para>Kernel arguments string</para></listitem></varlistentry>
 
<varlistentry><term>
-m <replaceable>&lt;flags></replaceable></term>
<listitem><para>Mount rdonly flags. If set to a non-zero value the
root partition will be mounted read-only.</para></listitem></varlistentry>
 
<varlistentry><term>
-f <replaceable>&lt;flags></replaceable></term>
<listitem><para>RAM disk flags. Should normally be 0x4000</para></listitem></varlistentry>
 
<varlistentry><term>-r <replaceable>&lt;device number></replaceable></term>
<listitem><para>Root device specification. /dev/ram is 0x0101</para></listitem></varlistentry>
 
<varlistentry><term>-l <replaceable>&lt;type></replaceable></term>
<listitem><para>Loader type</para></listitem></varlistentry>
 
</variablelist>
 
<para>Finally the kernel entry address can be specified as an optional
argument. The default is 0x8c102000</para>
 
<para>
For the the SE77x9, Linux by default expects to be loaded at
0x8c001000 which conflicts with the data space used by RedBoot.
To work around this, either change the CONFIG_MEMORY_START kernel
option to a higher address, or use the compressed kernel image and load
it at a higher address. For example, setting CONFIG_MEMORY_START to
0x8c100000, the kernel expects to be loaded at address 0x8c101000 with
the entry point at 0x8c102000.
</para>
 
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the SE77x9 board.<programlisting>
Physical Address Range Description
----------------------- -----------
0x80000000 - 0x803fffff Flash (MBM29LV160)
0x81000000 - 0x813fffff EPROM (M27C800)
0x8c000000 - 0x8dffffff DRAM
0xb0000000 - 0xb03fffff Ethernet (DP83902A)
0xb0800000 - 0xb08fffff 16C552A
0xb1000000 - 0xb100ffff Switches
0xb1800000 - 0xb18fffff LEDs
0xb8000000 - 0xbbffffff PCMCIA (MaruBun)
</programlisting></para>
</sect2>
<sect2>
<title>Ethernet Driver</title>
<para>The ethernet driver uses a hardwired ESA which can, at present,
only be changed in CDL.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=se77x9
export ARCH_DIR=sh
export PLATFORM_DIR=se77x9
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="hs7729pci">
<title>SuperH/SH3(SH7729) Hitachi HS7729PCI</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Hitachi SH HS7729PCI</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Hitachi SH HS7729PCI</secondary></indexterm>RedBoot uses
the COM1 and COM2 serial ports (and the debug port on the
motherboard).
The default serial port settings are 38400,8,N,1.
Ethernet is also supported using a D-Link DFE-530TX PCI plugin
card. Management of onboard flash is also supported. </para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>A ROM mode RedBoot image must be programmed
into the two EPROMs. Two files with a split version of the ROM mode
image is
provided: it is also possible to recreate these from the
<filename>redboot.bin</filename>
file, but requires the <application>split_word.c</application> program in
<filename
class="directory">hal/sh/hs7729pci/<replaceable>VERSION</replaceable>/misc</filename>
to be built and executed with the <filename>redboot.bin</filename>
filename as sole argument.</para>
 
<para>After doing this it is advised that another ROM mode image of
RedBoot is programmed into the on-board flash, and that copy be used
for booting the board. This allows for software programmed updates of
RedBoot instead of having to reprogram the EPROMs.</para>
 
<orderedlist>
<listitem><para>Program the EPROMs with RedBoot. The .lo image should
go in socket M1 and the .hi image in socket M2.
</para>
</listitem>
<listitem><para>Set switch SW1-6 to ON [boot from EPROM]</para>
</listitem>
<listitem><para>Follow the instructions under Flash management for
updating the flash copy of RedBoot, but force the flash destination
address with
<screen><userinput>-f 0x80400000</userinput></screen> due to setting of
the SW1-6 switch.</para>
</listitem>
<listitem><para>Set switch SW1-6 to OFF [boot from flash] and reboot the board. You
should now see the RedBoot banner. At this time you may want to issue
the command <command>fis init</command> to initialize
the flash table with the correct addresses.</para>
</listitem>
</orderedlist>
 
 
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the HS7729PCI are:</para>
<variablelist>
<varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Parameter block address. This is normally the first
page of the kernel image and defaults to 0x8c101000</para></listitem></varlistentry>
 
<varlistentry><term>-i <replaceable>&lt;addr></replaceable></term>
<listitem><para>Start address of initrd
image</para></listitem></varlistentry>
 
<varlistentry><term>-j <replaceable>&lt;size></replaceable></term>
<listitem><para>Size of initrd image</para></listitem></varlistentry>
 
<varlistentry><term>-c <replaceable>"args"</replaceable></term>
<listitem><para>Kernel arguments string</para></listitem></varlistentry>
 
<varlistentry><term>
-m <replaceable>&lt;flags></replaceable></term>
<listitem><para>Mount rdonly flags. If set to a non-zero value the
root partition will be mounted read-only.</para></listitem></varlistentry>
 
<varlistentry><term>
-f <replaceable>&lt;flags></replaceable></term>
<listitem><para>RAM disk flags. Should normally be 0x4000</para></listitem></varlistentry>
 
<varlistentry><term>-r <replaceable>&lt;device number></replaceable></term>
<listitem><para>Root device specification. /dev/ram is 0x0101</para></listitem></varlistentry>
 
<varlistentry><term>-l <replaceable>&lt;type></replaceable></term>
<listitem><para>Loader type</para></listitem></varlistentry>
 
</variablelist>
 
<para>Finally the kernel entry address can be specified as an optional
argument. The default is 0x8c102000</para>
 
<para>
On the HS7729PCI, Linux expects to be loaded at address 0x8c101000 with
the entry point at 0x8c102000. This is configurable in the kernel
using the CONFIG_MEMORY_START option.
</para>
 
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the HS7729PCI board.<programlisting>
Physical Address Range Description
----------------------- -----------
0x80000000 - 0x803fffff Flash (MBM29LV160)
0x80400000 - 0x807fffff EPROM (M27C800)
0x82000000 - 0x82ffffff SRAM
0x89000000 - 0x89ffffff SRAM
0x8c000000 - 0x8fffffff SDRAM
0xa8000000 - 0xa800ffff SuperIO (FDC37C935A)
0xa8400000 - 0xa87fffff USB function (ML60851C)
0xa8800000 - 0xa8bfffff USB host (SL11HT)
0xa8c00000 - 0xa8c3ffff Switches
0xa8c40000 - 0xa8c7ffff LEDs
0xa8c80000 - 0xa8cfffff Interrupt controller
0xb0000000 - 0xb3ffffff PCI (SD0001)
0xb8000000 - 0xbbffffff PCMCIA (MaruBun)
</programlisting></para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=hs7729pci
export ARCH_DIR=sh
export PLATFORM_DIR=hs7729pci
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="se77x9">
<title>SuperH/SH3(SH77X9) Hitachi Solution Engine 77X9</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Hitachi SH SE77X9</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Hitachi SH SE77X9</secondary></indexterm>This
description covers the MS7729SE01 and MS7709SSE0101 variants. See <xref linkend="se7709">
for instructions for the MS7709SE01 variant.</para>
 
<para>RedBoot uses
the COM1 and COM2 serial ports. The default serial port settings are 38400,8,N,1.
Ethernet is also supported using the 10-base T connector. Management
of onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>The Solution Engine ships with the Hitachi boot monitor in EPROM
which allows for initial programming of RedBoot:</para>
 
<orderedlist>
<listitem><para>Set switches SW4-3 and SW4-4 to ON [boot from EPROM]</para>
</listitem>
<listitem><para>Connect a serial cable to COM2 and power up the board.</para>
</listitem>
<listitem><para>After the boot monitor banner, invoke the flash
download/program command:<screen>Ready &gt;<userinput>fl</userinput></screen></para>
</listitem>
<listitem><para>The monitor should now ask for input:
<screen>Flash ROM data copy to RAM
Please Send A S-format Record</screen>At this point copy the
RedBoot ROM SREC file to the serial port:<screen>
$ <userinput>cat redboot_ROM.eprom.srec &gt /dev/ttyS0</userinput></screen>
Eventually you
should see something like<screen>Start Addrs = A1000000
End Addrs = A1xxxxxx
Transfer complete</screen> from the monitor.
</para></listitem>
<listitem><para>Set switch SW4-3 to OFF [boot from flash] and reboot the board. You
should now see the RedBoot banner.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the SE77x9 are:</para>
<variablelist>
<varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Parameter block address. This is normally the first
page of the kernel image and defaults to 0x8c101000</para></listitem></varlistentry>
 
<varlistentry><term>-i <replaceable>&lt;addr></replaceable></term>
<listitem><para>Start address of initrd
image</para></listitem></varlistentry>
 
<varlistentry><term>-j <replaceable>&lt;size></replaceable></term>
<listitem><para>Size of initrd image</para></listitem></varlistentry>
 
<varlistentry><term>-c <replaceable>"args"</replaceable></term>
<listitem><para>Kernel arguments string</para></listitem></varlistentry>
 
<varlistentry><term>
-m <replaceable>&lt;flags></replaceable></term>
<listitem><para>Mount rdonly flags. If set to a non-zero value the
root partition will be mounted read-only.</para></listitem></varlistentry>
 
<varlistentry><term>
-f <replaceable>&lt;flags></replaceable></term>
<listitem><para>RAM disk flags. Should normally be 0x4000</para></listitem></varlistentry>
 
<varlistentry><term>-r <replaceable>&lt;device number></replaceable></term>
<listitem><para>Root device specification. /dev/ram is 0x0101</para></listitem></varlistentry>
 
<varlistentry><term>-l <replaceable>&lt;type></replaceable></term>
<listitem><para>Loader type</para></listitem></varlistentry>
 
</variablelist>
 
<para>Finally the kernel entry address can be specified as an optional
argument. The default is 0x8c102000</para>
 
<para>
On the SE77x9, Linux expects to be loaded at address 0x8c101000 with
the entry point at 0x8c102000. This is configurable in the kernel
using the CONFIG_MEMORY_START option.
</para>
 
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the SE77x9 board.<programlisting>
Physical Address Range Description
----------------------- -----------
0x80000000 - 0x803fffff Flash (MBM29LV160)
0x81000000 - 0x813fffff EPROM (M27C800)
0x8c000000 - 0x8dffffff SDRAM
0xb0000000 - 0xb03fffff Ethernet (DP83902A)
0xb0400000 - 0xb07fffff SuperIO (FDC37C935A)
0xb0800000 - 0xb0bfffff Switches
0xb0c00000 - 0xbfffffff LEDs
0xb1800000 - 0xb1bfffff PCMCIA (MaruBun)
</programlisting></para>
</sect2>
<sect2>
<title>Ethernet Driver</title>
<para>The ethernet driver uses a hardwired ESA which can, at present,
only be changed in CDL.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=se77x9
export ARCH_DIR=sh
export PLATFORM_DIR=se77x9
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
</sect2>
</sect1>
 
<?Pub _newpage>
<sect1 id="se7751">
<title>SuperH/SH4(SH7751) Hitachi Solution Engine 7751</title>
<sect2>
<title>Overview</title>
<para><indexterm><primary>Hitachi SH SE7751</primary><secondary>installing
and testing</secondary></indexterm><indexterm><primary>installing and testing
</primary><secondary>Hitachi SH SE7751</secondary></indexterm>RedBoot uses
the COM1 serial port. The default serial port settings are 38400,8,N,1.
Ethernet is also supported using the 10-base T connector. Management
of onboard flash is also supported.</para>
 
<para>The following RedBoot configurations are supported:
 
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<thead>
<row>
<entry>Configuration</entry>
<entry>Mode</entry>
<entry>Description</entry>
<entry>File</entry>
</row>
</thead>
<tbody>
<row>
<entry>ROM</entry>
<entry>[ROM]</entry>
<entry>RedBoot running from the board's flash boot
sector.</entry>
<entry>redboot_ROM.ecm</entry>
</row>
<row>
<entry>RAM</entry>
<entry>[RAM]</entry>
<entry>RedBoot running from RAM with RedBoot in the
flash boot sector.</entry>
<entry>redboot_RAM.ecm</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
 
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>The Solution Engine ships with the Hitachi boot monitor in EPROM
which allows for initial programming of RedBoot:</para>
 
<orderedlist>
<listitem><para>Set switches SW5-3 and SW5-4 to ON [boot from EPROM]</para>
</listitem>
<listitem><para>Connect a serial cable to COM1 and power up the board.</para>
</listitem>
<listitem><para>After the boot monitor banner, invoke the flash
download/program command:<screen>Ready &gt;<userinput>fl</userinput></screen></para>
</listitem>
<listitem><para>The monitor should now ask for input:
<screen>Flash ROM data copy to RAM
Please Send A S-format Record</screen>At this point copy the
RedBoot ROM SREC file to the serial port:<screen>
$ <userinput>cat redboot_ROM.eprom.srec &gt /dev/ttyS0</userinput></screen>
Eventually you
should see something like<screen>Start Addrs = A1000000
End Addrs = A1xxxxxx
Transfer complete</screen> from the monitor.
</para></listitem>
<listitem><para>Set switch SW5-3 to OFF [boot from flash] and reboot the board. You
should now see the RedBoot banner.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>The <command>exec</command> command which allows the loading
and execution of Linux kernels
is supported for this board (see <xref linkend="executing-programs">). The <command>
exec</command> parameters used for the SE7751 are:</para>
<variablelist>
<varlistentry>
<term>-b <replaceable>&lt;addr></replaceable></term>
<listitem><para>Parameter block address. This is normally the first
page of the kernel image and defaults to 0x8c101000</para></listitem></varlistentry>
 
<varlistentry><term>-i <replaceable>&lt;addr></replaceable></term>
<listitem><para>Start address of initrd
image</para></listitem></varlistentry>
 
<varlistentry><term>-j <replaceable>&lt;size></replaceable></term>
<listitem><para>Size of initrd image</para></listitem></varlistentry>
 
<varlistentry><term>-c <replaceable>"args"</replaceable></term>
<listitem><para>Kernel arguments string</para></listitem></varlistentry>
 
<varlistentry><term>
-m <replaceable>&lt;flags></replaceable></term>
<listitem><para>Mount rdonly flags. If set to a non-zero value the
root partition will be mounted read-only.</para></listitem></varlistentry>
 
<varlistentry><term>
-f <replaceable>&lt;flags></replaceable></term>
<listitem><para>RAM disk flags. Should normally be 0x4000</para></listitem></varlistentry>
 
<varlistentry><term>-r <replaceable>&lt;device number></replaceable></term>
<listitem><para>Root device specification. /dev/ram is 0x0101</para></listitem></varlistentry>
 
<varlistentry><term>-l <replaceable>&lt;type></replaceable></term>
<listitem><para>Loader type</para></listitem></varlistentry>
 
</variablelist>
 
<para>Finally the kernel entry address can be specified as an optional
argument. The default is 0x8c102000</para>
 
<para>
On the SE7751, Linux expects to be loaded at address 0x8c101000 with
the entry point at 0x8c102000. This is configurable in the kernel
using the CONFIG_MEMORY_START option.
</para>
 
</sect2>
<sect2>
<title>Memory Maps </title>
<para>RedBoot sets up the following memory map on the SE7751 board.<programlisting>
Physical Address Range Description
----------------------- -----------
0x80000000 - 0x803fffff Flash (MBM29LV160)
0x81000000 - 0x813fffff EPROM (M27C800)
0x8c000000 - 0x8fffffff SDRAM
0xb8000000 - 0xb8ffffff PCMCIA (MaruBun)
0xb9000000 - 0xb9ffffff Switches
0xba000000 - 0xbaffffff LEDs
0xbd000000 - 0xbdffffff PCI MEM space
0xbe200000 - 0xbe23ffff PCI Ctrl space
0xbe240000 - 0xbe27ffff PCI IO space
</programlisting></para>
</sect2>
<sect2>
<title>Ethernet Driver</title>
<para>The ethernet driver uses a hardwired ESA which can, at present,
only be changed in CDL.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
 
<para>These shell variables provide the platform-specific information
needed for building RedBoot according to the procedure described in
<xref linkend="Rebuilding-Redboot">:
<programlisting>
export TARGET=se7751
export ARCH_DIR=sh
export PLATFORM_DIR=se7751
</programlisting>
</para>
 
<para>The names of configuration files are listed above with the
description of the associated modes.</para>
</sect2>
</sect1>
 
</chapter>
/redboot_cmds.sgml
0,0 → 1,2916
<!-- {{{ Banner -->
 
<!-- =============================================================== -->
<!-- -->
<!-- redboot_cmds.sgml -->
<!-- -->
<!-- Documentation for RedBoot Commands -->
<!-- -->
<!-- =============================================================== -->
<!-- ####COPYRIGHTBEGIN#### -->
<!-- -->
<!-- =============================================================== -->
<!-- Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/) -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission obtained from the copyright holder -->
<!-- =============================================================== -->
<!-- -->
<!-- ####COPYRIGHTEND#### -->
<!-- =============================================================== -->
<!-- #####DESCRIPTIONBEGIN#### -->
<!-- -->
<!-- ####DESCRIPTIONEND#### -->
<!-- =============================================================== -->
 
<!-- }}} -->
 
<chapter id="RedBoot-Commands-and-Examples">
<title>RedBoot Commands and Examples</title>
<sect1>
<title>Introduction</title>
<para><indexterm><primary>RedBoot</primary><secondary>commands and examples
</secondary></indexterm><indexterm><primary>commands and examples</primary>
</indexterm>RedBoot provides three basic classes of commands: <itemizedlist>
<listitem><para>Program loading and execution</para>
</listitem>
<listitem><para>Flash image and configuration management</para>
</listitem>
<listitem><para>Miscellaneous commands</para>
</listitem>
</itemizedlist>Given the extensible and configurable nature of eCos and RedBoot,
there may be extended or enhanced sets of commands available.</para>
<para>The basic format for commands is: <programlisting>RedBoot> COMMAND [-S]... [-s val]... operand
</programlisting>
</para>
<para>
Commands may require additional information beyond the basic
command name. In most cases this additional information is optional, with
suitable default values provided if they are not present.
 
<informaltable frame="all">
<tgroup cols="3" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<thead>
<row>
<entry>Format</entry>
<entry>Description</entry>
<entry>Example</entry>
</row>
</thead>
<tbody>
<row>
<entry>-S</entry>
<entry>A boolean switch; the behavior of the command will differ, depending
on the presence of the switch. In this example, the <userinput>-f</userinput> switch
indicates that a complete initialization of the FIS data should be performed.
There may be many such switches available for any given command and any or all of
them may be present, in any order.</entry>
<entry>
<computeroutput> RedBoot> <userinput>fis init -f</userinput></computeroutput>
</entry>
</row>
<row>
<entry>-s<replaceable> val</replaceable></entry>
<entry>A qualified value; the letter "s" introduces the value, qualifying it's meaning. In the
example, <userinput>-b 0x100000</userinput> specifies where the memory dump should begin.
There may be many such switches available for any given command and any or all of
them may be present, in any order.
</entry>
<entry>
<computeroutput> RedBoot> <userinput>dump -b 0x100000 -l 0x20</userinput></computeroutput>
</entry>
</row>
<row>
<entry><replaceable> operand</replaceable></entry>
<entry>A simple value; some commands require a single parameter for which an additional
<userinput>-X</userinput> switch would be redundant. In the example, <userinput>JFFS2</userinput>
is the name of a flash image. The image name is always required, thus is no need to qualify it with
a switch.
Note that any un-qualified operand must always appear at the end of the command.</entry>
<entry>
<computeroutput> RedBoot> <userinput>fis delete JFFS2</userinput></computeroutput>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
 
</para>
<para>The list of available commands, and their syntax, can be obtained by
typing <command>help</command> at the command line:
<screen>
RedBoot> <userinput>help</userinput>
Manage aliases kept in FLASH memory
alias name [value]
Set/Query the system console baud rate
baudrate [-b &lt;rate>]
Manage machine caches
cache [ON | OFF]
Display/switch console channel
channel [-1|&lt;channel number>]
Display disk partitions
disks
Display (hex dump) a range of memory
dump -b &lt;location> [-l &lt;length>] [-s]
Manage flash images
fis {cmds}
Manage configuration kept in FLASH memory
fconfig [-i] [-l] [-n] [-f] [-d] | [-d] nickname [value]
Execute code at a location
go [-w &lt;timeout>] [entry]
Help about help?
help [&lt;topic>]
Set/change IP addresses
ip_address [-l &lt;local_ip_address>] [-h &lt;server_address>]
Load a file
load [-r] [-v] [-d] [-c &lt;channel>] [-h &lt;host>] [-m {TFTP | HTTP | {x|y}MODEM | disk}]
[-b &lt;base_address>] &lt;file_name>
Network connectivity test
ping [-v] [-n &lt;count>] [-t &lt;timeout>] [-i &lt;IP_addr]
-h &lt;host>
Reset the system
reset
Display RedBoot version information
version
Display (hex dump) a range of memory
x -b &lt;location> [-l &lt;length>] [-s]
</screen>
</para>
<para>
Commands can be abbreviated to their shortest
unique string. Thus in the list above, <command>d,du,dum</command>
and dump are all valid for the <command>dump</command> command. The <command>fconfig</command>
command can be abbreviated <command>fc</command>, but
<command>f</command> would be ambiguous with <command>fis</command>.
</para>
<para>There is one additional, special command. When RedBoot detects '$' or '+'
(unless escaped via '\') in a command, it switches to GDB protocol mode. At this
point, the eCos GDB stubs take over, allowing connections from a GDB host.
The only way to get back to RedBoot from GDB mode is to restart the platform.
</para>
<note><title>NOTE</title>
<para>
Multiple commands may be entered on a single line, separated by the semi-colon &ldquo;;&rdquo; character.
</para>
</note>
<para>The standard RedBoot command set is structured around the bootstrap
environment. These commands are designed to be simple to use and remember,
while still providing sufficient power and flexibility to be useful. No attempt
has been made to render RedBoot as the end-all product. As such, things such
as the debug environment are left to other modules, such as GDB stubs, which
are typically included in RedBoot. </para>
<para>The command set may be also be extended on a platform basis. </para>
</sect1>
 
<sect1 id="common-commands">
<title>Common Commands</title>
<para>
<indexterm><primary>commands</primary><secondary>common</secondary>
</indexterm>
</para>
 
<!-- ******** alias *************************************************** -->
<refentry id="alias-command">
<refnamediv>
<refname>alias</refname>
<refpurpose>Manipulate command line aliases</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>alias</command>
<arg choice="req"><replaceable> name</replaceable></arg>
<arg><replaceable> value</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry><replaceable>name</replaceable></entry>
<entry>Name</entry>
<entry>The name for this alias.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry><replaceable>value</replaceable></entry>
<entry>String</entry>
<entry>Replacement value for the alias.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <command>alias</command> command is used to maintain simple command
line aliases. These aliases are shorthand for longer expressions.
When the pattern %{name} appears in a command line, including in a script,
the corresponding value will be substituted. Aliases may be nested.
</para>
<para>
If no value is provided, then the current value of the alias is displayed.
</para>
<para>
If the system supports non-volatile configuration data via the
<command>fconfig</command> command (see <xref linkend="Persistent-State-Flash">),
then the value will be saved and used when the system is reset.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Set an alias.
<screen>
RedBoot> <userinput>alias joe "This is Joe"</userinput>
Update RedBoot non-volatile configuration - continue (y/n)? n
</screen>
</para>
<para>
Display an alias.
<screen>
RedBoot> <userinput>alias joe</userinput>
'joe' = 'This is Joe'
</screen>
</para>
<para>
Use an alias. Note: the <command>"="</command> command simply echoes the command to to console.
<screen>
RedBoot> <userinput>= %{joe}</userinput>
This is Joe
</screen>
</para>
<para>
Aliases can be nested.
<screen>
RedBoot> <userinput>alias frank "Who are you? %{joe}"</userinput>
Update RedBoot non-volatile configuration - continue (y/n)? n
RedBoot> <userinput>= %{frank}</userinput>
Who are you? This is Joe
</screen>
</para>
<para>
Notice how the value of %{frank} changes when %{joe} is changed since
the value of %{joe} is not evaluated until %{frank} is evaluated.
<screen>
RedBoot> <userinput>alias joe "This is now Josephine"</userinput>
Update RedBoot non-volatile configuration - continue (y/n)? n
RedBoot> <userinput>= %{frank}</userinput>
Who are you? This is now Josephine
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** baudrate *************************************************** -->
<refentry id="baudrate-command">
<refnamediv>
<refname>baudrate</refname>
<refpurpose>Set the baud rate for the system serial console</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>baudrate</command>
<arg>-b<replaceable> rate</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-b <replaceable>rate</replaceable></entry>
<entry>Number</entry>
<entry>The baud rate to use for the serial console.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <command>baudrate</command> command sets the baud rate for the system serial console.
</para>
<para>
If no value is provided, then the current value of the console baud rate is displayed.
</para>
<para>
If the system supports non-volatile configuration data via the
<command>fconfig</command> command (see <xref linkend="Persistent-State-Flash">),
then the value will be saved and used when the system is reset.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Show the current baud rate.
<screen>
RedBoot> <userinput>baudrate</userinput>
Baud rate = 38400
</screen>
</para>
<para>
Change the console baud rate. In order to make this operation safer,
there will be a slight pause after the
first message to give you time to change to the new baud rate.
If it doesn't work, or a less than affirmative answer is given to the
"continue" prompt, then the baud rate will revert to the current value.
Only after the baud rate has been firmly established will <emphasis>RedBoot</emphasis>
give you an opportunity to save the value in persistent storage.
<screen>
RedBoot> <userinput>baudrate -b 57600</userinput>
Baud rate will be changed to 57600 - update your settings
<emphasis>Device baud rate changed at this point</emphasis>
Baud rate changed to 57600 - continue (y/n)? y
Update RedBoot non-volatile configuration - continue (y/n)? n
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** cache *************************************************** -->
<refentry id="cache-command">
<refnamediv>
<refname>cache</refname>
<refpurpose>Control hardware caches</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>cache</command>
<group>
<arg>on</arg>
<arg>off</arg>
</group>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>on</entry>
<entry></entry>
<entry>Turn the caches on</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>off</entry>
<entry></entry>
<entry>Turn the caches off</entry>
<entry><emphasis>none</emphasis></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <command>cache</command> command is used to manipulate the caches on the processor. </para>
<para>With no options, this command specifies the state of the system caches.</para>
<para>When an option is given, the caches are turned off or on appropriately.</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Show the current cache state.
<screen>
RedBoot> <userinput>cache</userinput>
Data cache: On, Instruction cache: On
</screen>
</para>
<para>
Disable the caches.
<screen>
RedBoot> <userinput>cache off</userinput>
RedBoot> <userinput>cache</userinput>
Data cache: Off, Instruction cache: Off
</screen>
</para>
<para>
Enable the caches.
<screen>
RedBoot> <userinput>cache on</userinput>
RedBoot> <userinput>cache</userinput>
Data cache: On, Instruction cache: On
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** channel *************************************************** -->
<refentry id="channel-command">
<refnamediv>
<refname>channel</refname>
<refpurpose>Select the system console channel</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>channel</command>
<group>
<arg>-1</arg>
<arg><replaceable>channel_number</replaceable></arg>
</group>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-1</entry>
<entry></entry>
<entry>Reset the console channel</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>channel_number</entry>
<entry>Number</entry>
<entry>Select a channel</entry>
<entry><emphasis>none</emphasis></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>
With no arguments, the <command>channel</command> command displays the current console channel number.
</para><para>
When passed an argument of 0 upward, this command switches the console
channel to that channel number. The mapping between channel numbers and
physical channels is platform specific but will typically be something like
channel 0 is the first serial port, channel 1 is the second, etc.
</para><para>
When passed an argument of -1, this command reverts RedBoot to responding
to whatever channel receives input first, as happens when RedBoot initially
starts execution.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Show the current channel.
<screen>
RedBoot> <userinput>channel</userinput>
Current console channel id: 0
</screen>
</para>
<para>
Change to an invalid channel.
<screen>
RedBoot> <userinput>channel 99</userinput>
**Error: bad channel number '99'
</screen>
</para>
<para>
Revert to the default channel setting (any console mode).
<screen>
RedBoot> <userinput>channel -1</userinput>
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** cksum *************************************************** -->
<refentry id="cksum-command">
<refnamediv>
<refname>cksum</refname>
<refpurpose>Compute POSIX checksums</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>cksum</command>
<arg choice="req">-b <replaceable>location</replaceable></arg>
<arg choice="req">-l <replaceable>length</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-b <replaceable>location</replaceable></entry>
<entry>Memory address</entry>
<entry>Location in memory for stat of data.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-l <replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of data</entry>
<entry><emphasis>none</emphasis></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>Computes the POSIX checksum on a range of memory (either RAM or FLASH).
The values printed (decimal cksum, decimal length, hexadecimal cksum,
hexadecimal length) can be compared with the output from the Linux program 'cksum'.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Checksum a buffer.
<screen>
RedBoot> <userinput>cksum -b 0x100000 -l 0x100</userinput>
POSIX cksum = 3286483632 256 (0xc3e3c2b0 0x00000100)
</screen>
</para>
<para>
Checksum an area of memory after loading a file. Note that the base
address and length parameters are provided by the preceding
load command.
<screen>
RedBoot> <userinput>load -r -b %{FREEMEMLO} redboot.bin</userinput>
Raw file loaded 0x06012800-0x0602f0a8
RedBoot> <userinput>cksum</userinput>
Computing cksum for area 0x06012800-0x0602f0a8
POSIX cksum = 2092197813 116904 (0x7cb467b5 0x0001c8a8)
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** disks *************************************************** -->
<refentry id="disks-command">
<refnamediv>
<refname>disks</refname>
<refpurpose>List available disk partitions.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>disks</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<para>None.</para>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <command>disks</command> command is used to list disk partitions recognized by RedBoot.</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Show what disk partitions are available.
<screen>
RedBoot> <userinput>disks</userinput>
hda1 Linux Swap
hda2 Linux
00100000: 00 3E 00 06 00 06 00 06 00 00 00 00 00 00 00 00 |.>..............|
00100010: 00 00 00 78 00 70 00 60 00 60 00 60 00 60 00 60 |...x.p.`.`.`.`.`|
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** dump *************************************************** -->
<refentry id="dump-command">
<refnamediv>
<refname>dump</refname>
<refpurpose>Display memory.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>dump</command>
<arg choice="req">-b <replaceable>location</replaceable></arg>
<arg>-l <replaceable>length</replaceable></arg>
<arg>-s</arg>
<group>
<arg>-1</arg>
<arg>-2</arg>
<arg>-4</arg>
</group>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-b <replaceable>location</replaceable></entry>
<entry>Memory address</entry>
<entry>Location in memory for start of data.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-l <replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of data</entry>
<entry>32</entry>
</row>
<row>
<entry>-s</entry>
<entry>Boolean</entry>
<entry>Format data using Motorola S-records.</entry>
<entry></entry>
</row>
<row>
<entry>-1</entry>
<entry></entry>
<entry>Access one byte (8 bits) at a time.
Only the least significant 8 bits of the pattern will be used.</entry>
<entry>-1</entry>
</row>
<row>
<entry>-2</entry>
<entry></entry>
<entry>Access two bytes (16 bits) at a time.
Only the least significant 16 bits of the pattern will be used.</entry>
<entry>-1</entry>
</row>
<row>
<entry>-4</entry>
<entry></entry>
<entry>Access one word (32 bits) at a time.</entry>
<entry>-1</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>Display a range of memory on the system console.</para>
<para>The <command>x</command> is a synonym for <command>dump</command>.</para>
<para>Note that this command could
be detrimental if used on memory mapped hardware registers. </para>
<para>The memory is displayed at most sixteen bytes per line, first as the
raw hex value, followed by an ASCII interpretation of the data. </para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Display a buffer, one byte at a time.
<screen>
RedBoot> <userinput>mfill -b 0x100000 -l 0x20 -p 0xDEADFACE</userinput>
RedBoot> <userinput>x -b 0x100000</userinput>
00100000: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................|
00100010: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................|
</screen>
</para>
<para>
Display a buffer, one short (16 bit) word at a time. Note in this case that
the ASCII interpretation is suppressed.
<screen>
RedBoot> <userinput>dump -b 0x100000 -2</userinput>
00100000: FACE DEAD FACE DEAD FACE DEAD FACE DEAD
00100010: FACE DEAD FACE DEAD FACE DEAD FACE DEAD
</screen>
</para>
<para>
Display a buffer, one word (32 bit) word at a time. Note in this case that
the ASCII interpretation is suppressed.
<screen>
RedBoot> <userinput>dump -b 0x100000 -4</userinput>
00100000: DEADFACE DEADFACE DEADFACE DEADFACE
00100010: DEADFACE DEADFACE DEADFACE DEADFACE
</screen>
</para>
<para>
Display the same buffer, using Motorola S-record format.
<screen>
RedBoot> <userinput>dump -b 0x100000 -s</userinput>
S31500100000CEFAADDECEFAADDECEFAADDECEFAADDE8E
S31500100010CEFAADDECEFAADDECEFAADDECEFAADDE7E
</screen>
</para>
<para>
Display a buffer, with visible ASCII strings.
<screen>
RedBoot> <userinput>d -b 0xfe00b000 -l 0x80</userinput>
0xFE00B000: 20 25 70 0A 00 00 00 00 41 74 74 65 6D 70 74 20 | %p.....Attempt |
0xFE00B010: 74 6F 20 6C 6F 61 64 20 53 2D 72 65 63 6F 72 64 |to load S-record|
0xFE00B020: 20 64 61 74 61 20 74 6F 20 61 64 64 72 65 73 73 | data to address|
0xFE00B030: 3A 20 25 70 20 5B 6E 6F 74 20 69 6E 20 52 41 4D |: %p [not in RAM|
0xFE00B040: 5D 0A 00 00 2A 2A 2A 20 57 61 72 6E 69 6E 67 21 |]...*** Warning!|
0xFE00B050: 20 43 68 65 63 6B 73 75 6D 20 66 61 69 6C 75 72 | Checksum failur|
0xFE00B060: 65 20 2D 20 41 64 64 72 3A 20 25 6C 78 2C 20 25 |e - Addr: %lx, %|
0xFE00B070: 30 32 6C 58 20 3C 3E 20 25 30 32 6C 58 0A 00 00 |02lX &lt;> %02lX...|
0xFE00B080: 45 6E 74 72 79 20 70 6F 69 6E 74 3A 20 25 70 2C |Entry point: %p,|
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** help *************************************************** -->
<refentry id="help-command">
<refnamediv>
<refname>help</refname>
<refpurpose>Display help on available commands</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>help</command>
<arg><replaceable> topic</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry><replaceable>topic</replaceable></entry>
<entry>String</entry>
<entry>Which command to provide help for.</entry>
<entry>All commands</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>
The <command>help</command> command displays information about the available
RedBoot commands. If a <emphasis>topic</emphasis> is given, then the display
is restricted to information about that specific command.
</para>
<para>
If the command has sub-commands, e.g. <command>fis</command>, then the topic
specific display will print additional information about the available sub-commands.
special (ICMP) packets to a specific host. These packets should be automatically
returned by that host. The command will indicate how many of these round-trips
were successfully completed.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Show generic help. Note that the contents of this display will depend on the various configuration
options for RedBoot when it was built.
<screen>
RedBoot> <userinput>help</userinput>
Manage aliases kept in FLASH memory
alias name [value]
Manage machine caches
cache [ON | OFF]
Display/switch console channel
channel [-1|&lt;channel number&gt;]
Compute a 32bit checksum [POSIX algorithm] for a range of memory
cksum -b &lt;location&gt; -l &lt;length&gt;
Display (hex dump) a range of memory
dump -b &lt;location&gt; [-l &lt;length&gt;] [-s] [-1|2|4]
Manage FLASH images
fis {cmds}
Manage configuration kept in FLASH memory
fconfig [-i] [-l] [-n] [-f] [-d] | [-d] nickname [value]
Execute code at a location
go [-w &lt;timeout&gt;] [entry]
Help about help?
help [&lt;topic&gt;]
Set/change IP addresses
ip_address [-l &lt;local_ip_address&gt;] [-h &lt;server_address&gt;]
Load a file
load [-r] [-v] [-d] [-h &lt;host&gt;] [-m {TFTP | HTTP | {x|y}MODEM -c &lt;channel_number&gt;}]
[-b &lt;base_address&gt;] &lt;file_name&gt;
Compare two blocks of memory
mcmp -s &lt;location&gt; -d &lt;location&gt; -l &lt;length&gt; [-1|-2|-4]
Fill a block of memory with a pattern
mfill -b &lt;location&gt; -l &lt;length&gt; -p &lt;pattern&gt; [-1|-2|-4]
Network connectivity test
ping [-v] [-n &lt;count&gt;] [-l &lt;length&gt;] [-t &lt;timeout&gt;] [-r &lt;rate&gt;]
[-i &lt;IP_addr&gt;] -h &lt;IP_addr&gt;
Reset the system
reset
Display RedBoot version information
version
Display (hex dump) a range of memory
x -b &lt;location&gt; [-l &lt;length&gt;] [-s] [-1|2|4]
</screen>
</para>
<para>
Help about a command with sub-commands.
<screen>
RedBoot> <userinput>help fis</userinput>
Manage FLASH images
fis {cmds}
Create an image
fis create -b &lt;mem_base&gt; -l &lt;image_length&gt; [-s &lt;data_length&gt;]
[-f &lt;flash_addr&gt;] [-e &lt;entry_point&gt;] [-r &lt;ram_addr&gt;] [-n] &lt;name&gt;
Display an image from FLASH Image System [FIS]
fis delete name
Erase FLASH contents
fis erase -f &lt;flash_addr&gt; -l &lt;length&gt;
Display free [available] locations within FLASH Image System [FIS]
fis free
Initialize FLASH Image System [FIS]
fis init [-f]
Display contents of FLASH Image System [FIS]
fis list [-c] [-d]
Load image from FLASH Image System [FIS] into RAM
fis load [-d] [-b &lt;memory_load_address&gt;] [-c] name
Write raw data directly to FLASH
fis write -f &lt;flash_addr&gt; -b &lt;mem_base&gt; -l &lt;image_length&gt;
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** ip_address *************************************************** -->
<refentry id="ip-address-command">
<refnamediv>
<refname>ip_address</refname>
<refpurpose>Set IP addresses</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>ip_address</command>
<arg>-l <replaceable> local_IP_address</replaceable></arg>
<arg>-h <replaceable> server_IP_address</replaceable></arg>
<arg>-d <replaceable>
DNS_server_IP_address</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-l <replaceable>
local_IP_address</replaceable></entry>
<entry>Numeric IP or DNS name</entry>
<entry>The IP address RedBoot should use.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-h <replaceable>
server_IP_address</replaceable></entry>
<entry>Numeric IP or DNS name</entry>
<entry>The IP address of the default server. Use of this
address is implied by other commands, such as
<command>load</command>.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-d <replaceable>
DNS_server_IP_address</replaceable></entry>
<entry>Numeric IP or DNS name</entry>
<entry>The IP address of the DNS server.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <command>ip_address</command> command is used to show and/or change the basic IP
addresses used by RedBoot. IP addresses may be given as numeric
values, e.g. 192.168.1.67, or as symbolic names such as www.redhat.com
if DNS support is enabled.
</para>
<para>
The <option>-l</option> option is used to set the IP address used by
the target device.
</para>
<para>
The <option>-h</option> option is used to set the default server
address, such as is used by the <command>load</command> command.
</para>
<para>
The <option>-d</option> option is used to set the default DNS server
address which is used for resolving symbolic network addresses. Note
that an address of 0.0.0.0 will disable DNS lookups.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Display the current network settings.
<screen>
RedBoot> <userinput>ip_address</userinput>
IP: 192.168.1.31, Default server: 192.168.1.101, DNS server IP: 0.0.0.0
</screen>
</para>
<para>
Change the DNS server address.
<screen>
RedBoot> <userinput>ip_address -d 192.168.1.101</userinput>
IP: 192.168.1.31, Default server: 192.168.1.101, DNS server IP: 192.168.1.101
</screen>
</para>
<para>
Change the default server address.
<screen>
RedBoot> <userinput>ip_address -h 192.168.1.104</userinput>
IP: 192.168.1.31, Default server: 192.168.1.104, DNS server IP: 192.168.1.101
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** load *************************************************** -->
<refentry id="download-command">
<refnamediv>
<refname>load</refname>
<refpurpose>Download programs or data to the RedBoot platform</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>load</command>
<arg>-v </arg>
<arg>-d </arg>
<arg>-r </arg>
<arg>-m
<group>
<arg choice="req"><group>
<arg>xmodem</arg>
<arg>ymodem</arg>
</group></arg>
<arg>tftp</arg>
<arg>disk</arg>
</group>
</arg>
<arg>-h <replaceable> server_IP_address</replaceable></arg>
<arg>-b <replaceable> location</replaceable></arg>
<arg>-c <replaceable> channel</replaceable></arg>
<arg><replaceable>file_name</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-v</entry>
<entry>Boolean</entry>
<entry>Display a small spinner (indicator)
while the download is in progress. This is just for feedback, especially
during long loads. Note that the option has no effect when using a
serial download method since it would interfere with the protocol.</entry>
<entry><emphasis>quiet</emphasis></entry>
</row>
<row>
<entry>-d</entry>
<entry>Boolean</entry>
<entry>Decompress data stream (gzip data)</entry>
<entry><emphasis>non-compressed data</emphasis></entry>
</row>
<row>
<entry>-r</entry>
<entry>Boolean</entry>
<entry>Raw (or binary) data</entry>
<entry><emphasis>formatted (S-records, ELF image, etc)</emphasis></entry>
</row>
<row>
<entry>-m tftp</entry>
<entry></entry>
<entry>Transfer data via the network using <acronym>TFTP</acronym> protocol.</entry>
<entry><acronym>TFTP</acronym></entry>
</row>
<row>
<entry>-m http</entry>
<entry></entry>
<entry>Transfer data via the network using <acronym>HTTP</acronym> protocol.</entry>
<entry><acronym>TFTP</acronym></entry>
</row>
<row>
<entry>-m xmodem</entry>
<entry></entry>
<entry>Transfer data using <emphasis>X-modem</emphasis> protocol.</entry>
<entry><acronym>TFTP</acronym></entry>
</row>
<row>
<entry>-m ymodem</entry>
<entry></entry>
<entry>Transfer data using <emphasis>Y-modem</emphasis> protocol.</entry>
<entry><acronym>TFTP</acronym></entry>
</row>
<row>
<entry>-m disk</entry>
<entry></entry>
<entry>Transfer data from a local disk.</entry>
<entry><acronym>TFTP</acronym></entry>
</row>
<row>
<entry>-h <replaceable>server_IP_address</replaceable></entry>
<entry>Numeric IP or DNS name</entry>
<entry>The IP address of the <acronym>TFTP</acronym> or <acronym>HTTP</acronym> server.</entry>
<entry>Value set by <command>ip_address</command></entry>
</row>
<row>
<entry>-b <replaceable>location</replaceable></entry>
<entry>Number</entry>
<entry>Address in memory to load the data. Formatted data streams will have
an implied load address which this option may override.</entry>
<entry><emphasis>Depends on data format</emphasis></entry>
</row>
<row>
<entry>-c <replaceable>channel</replaceable></entry>
<entry>Number</entry>
<entry>Specify which I/O channel to
use for download. This option is only supported when using either
xmodem or ymodem protocol.</entry>
<entry><emphasis>Depends on data format</emphasis></entry>
</row>
<row>
<entry><replaceable>file_name</replaceable></entry>
<entry>String</entry>
<entry>The name of the file on the <acronym>TFTP</acronym> or <acronym>HTTP</acronym>
server or the local disk. Details of how this is specified for <acronym>TFTP</acronym> are
host-specific. For local disk files, the name must be in <emphasis>disk</emphasis>:
<emphasis>filename</emphasis> format. The disk portion must match one of the disk
names listed by the <command>disks</command> command.</entry>
<entry><emphasis>None</emphasis></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>
The <command>load</command> command is used to download
data into the target system. Data can be loaded via a network connection,
using either the <acronym>TFTP</acronym> or <acronym>HTTP</acronym> protocols, or the console serial connection using the
X/Y modem protocol. Files may also be loaded directly from local filesystems
on disk. Files to be downloaded may either be executable images in
ELF executable program format,
Motorola S-record (SREC)
format or raw data.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Download a Motorola S-record (or ELF) image, using <acronym>TFTP</acronym>, specifying the
base memory address.
<screen>
RedBoot> <userinput>load redboot.ROM -b 0x8c400000</userinput>
Address offset = 0x0c400000
Entry point: 0x80000000, address range: 0x80000000-0x8000fe80
</screen>
</para>
<para>
Download a Motorola S-record (or ELF) image, using <acronym>HTTP</acronym>, specifying the
host [server] address.
<screen>
RedBoot> <userinput>load /redboot.ROM -m HTTP -h 192.168.1.104</userinput>
Address offset = 0x0c400000
Entry point: 0x80000000, address range: 0x80000000-0x8000fe80
</screen>
</para>
<para>
Load an ELF file from /dev/hda1 which should be an EXT2 partition:
<screen>
RedBoot> <userinput>load -mode disk hda1:hello.elf</userinput>
Entry point: 0x00020000, address range: 0x00020000-0x0002fd70
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** mcmp *************************************************** -->
<refentry id="mcmp-command">
<refnamediv>
<refname>mcmp</refname>
<refpurpose>Compare two segments of memory</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>mcmp</command>
<arg choice="req">-s <replaceable>location1</replaceable></arg>
<arg choice="req">-d <replaceable>location1</replaceable></arg>
<arg choice="req">-l <replaceable>length</replaceable></arg>
<group>
<arg>-1</arg>
<arg>-2</arg>
<arg>-4</arg>
</group>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-s <replaceable>location1</replaceable></entry>
<entry>Memory address</entry>
<entry>Location for start of data.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-d <replaceable>location2</replaceable></entry>
<entry>Memory address</entry>
<entry>Location for start of data.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-l <replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of data</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-1</entry>
<entry></entry>
<entry>Access one byte (8 bits) at a time.
Only the least significant 8 bits of the pattern will be used.</entry>
<entry>-4</entry>
</row>
<row>
<entry>-2</entry>
<entry></entry>
<entry>Access two bytes (16 bits) at a time.
Only the least significant 16 bits of the pattern will be used.</entry>
<entry>-4</entry>
</row>
<row>
<entry>-4</entry>
<entry></entry>
<entry>Access one word (32 bits) at a time.</entry>
<entry>-4</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>Compares the contents of two ranges of memory (RAM, ROM, FLASH, etc).</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Compare two buffers which match (result is <emphasis>quiet</emphasis>).
<screen>
RedBoot> <userinput>mfill -b 0x100000 -l 0x20 -p 0xDEADFACE</userinput>
RedBoot> <userinput>mfill -b 0x200000 -l 0x20 -p 0xDEADFACE</userinput>
RedBoot> <userinput>mcmp -s 0x100000 -d 0x200000 -l 0x20</userinput>
</screen>
</para>
<para>
Compare two buffers which don't match.
Only the first non-matching element is displayed.
<screen>
RedBoot> <userinput>mcmp -s 0x100000 -d 0x200000 -l 0x30 -2</userinput>
Buffers don't match - 0x00100020=0x6000, 0x00200020=0x0000
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** mfill *************************************************** -->
<refentry id="mfill-command">
<refnamediv>
<refname>mfill</refname>
<refpurpose>Fill RAM with a specified pattern</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>mfill</command>
<arg choice="req">-b <replaceable>location</replaceable></arg>
<arg choice="req">-l <replaceable>length</replaceable></arg>
<arg choice="req">-p <replaceable>value</replaceable></arg>
<group>
<arg>-1</arg>
<arg>-2</arg>
<arg>-4</arg>
</group>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-b <replaceable>location</replaceable></entry>
<entry>Memory address</entry>
<entry>Location in memory for start of data.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-l <replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of data</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-p <replaceable>pattern</replaceable></entry>
<entry>Number</entry>
<entry>Data value to fill with</entry>
<entry>0</entry>
</row>
<row>
<entry>-1</entry>
<entry></entry>
<entry>Access one byte (8 bits) at a time.
Only the least significant 8 bits of the pattern will be used.</entry>
<entry>-4</entry>
</row>
<row>
<entry>-2</entry>
<entry></entry>
<entry>Access two bytes (16 bits) at a time.
Only the least significant 16 bits of the pattern will be used.</entry>
<entry>-4</entry>
</row>
<row>
<entry>-4</entry>
<entry></entry>
<entry>Access one word (32 bits) at a time.</entry>
<entry>-4</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>Fills a range of memory with the given pattern.</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Fill a buffer with zeros.
<screen>
RedBoot> <userinput>x -b 0x100000 -l 0x20</userinput>
00100000: 00 3E 00 06 00 06 00 06 00 00 00 00 00 00 00 00 |.>..............|
00100010: 00 00 00 78 00 70 00 60 00 60 00 60 00 60 00 60 |...x.p.`.`.`.`.`|
RedBoot> <userinput>mfill -b 0x100000 -l 0x20</userinput>
RedBoot> <userinput>x -b 0x100000 -l 0x20</userinput>
00100000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
</screen>
</para>
<para>
Fill a buffer with a pattern.
<screen>
RedBoot> <userinput>mfill -b 0x100000 -l 0x20 -p 0xDEADFACE</userinput>
RedBoot> <userinput>x -b 0x100000 -l 0x20</userinput>
00100000: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................|
00100010: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................|
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** ping *************************************************** -->
<refentry id="ping-command">
<refnamediv>
<refname>ping</refname>
<refpurpose>Verify network connectivity</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>ping</command>
<arg>-v </arg>
<arg>-i <replaceable> local_IP_address</replaceable></arg>
<arg>-l <replaceable> length</replaceable></arg>
<arg>-n <replaceable> count</replaceable></arg>
<arg>-t <replaceable> timeout</replaceable></arg>
<arg>-r <replaceable> rate</replaceable></arg>
<arg choice="req">-h <replaceable> server_IP_address</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-v</entry>
<entry>Boolean</entry>
<entry>Be verbose, displaying information about each packet sent.</entry>
<entry><emphasis>quiet</emphasis></entry>
</row>
<row>
<entry>-n <replaceable>local_IP_address</replaceable></entry>
<entry>Number</entry>
<entry>Controls the number of packets to be sent.</entry>
<entry>10</entry>
</row>
<row>
<entry>-i <replaceable>local_IP_address</replaceable></entry>
<entry>Numeric IP or DNS name</entry>
<entry>The IP address RedBoot should use.</entry>
<entry>Value set by <command>ip_address</command></entry>
</row>
<row>
<entry>-h <replaceable>server_IP_address</replaceable></entry>
<entry>Numeric IP or DNS name</entry>
<entry>The IP address of the host to contact.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-l <replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>The length of the ICMP data payload.</entry>
<entry>64</entry>
</row>
<row>
<entry>-r <replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>How fast to deliver packets, i.e. time between successive sends.
A value of 0 sends packets as quickly as possible.</entry>
<entry>1000ms (1 second)</entry>
</row>
<row>
<entry>-t <replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>How long to wait for the round-trip to complete, specified in milliseconds.</entry>
<entry>1000ms (1 second)</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>
The <command>ping</command> command checks the connectivity of the local network by sending
special (ICMP) packets to a specific host. These packets should be automatically
returned by that host. The command will indicate how many of these round-trips
were successfully completed.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Test connectivity to host 192.168.1.101.
<screen>
RedBoot> <userinput>ping -h 192.168.1.101</userinput>
Network PING - from 192.168.1.31 to 192.168.1.101
PING - received 10 of 10 expected
</screen>
</para>
<para>
Test connectivity to host 192.168.1.101, with verbose reporting.
<screen>
RedBoot> <userinput>ping -h 192.168.1.101 -v -n 4</userinput>
Network PING - from 192.168.1.31 to 192.168.1.101
seq: 1, time: 1 (ticks)
seq: 2, time: 1 (ticks)
seq: 3, time: 1 (ticks)
seq: 4, time: 1 (ticks)
PING - received 10 of 10 expected
</screen>
</para>
<para>
<screen>
Test connectivity to a non-existent host (192.168.1.109).
RedBoot> <userinput>ping -h 192.168.1.109 -v -n 4</userinput>
PING: Cannot reach server '192.168.1.109' (192.168.1.109)
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** reset *************************************************** -->
<refentry id="reset-command">
<refnamediv>
<refname>reset</refname>
<refpurpose>Reset the device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>reset</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<para><emphasis>None</emphasis></para>
</refsect1>
<refsect1>
<title>Description</title>
<para>
The <command>reset</command> command causes the target platform to be reset.
Where possible (hardware support permitting), this will be
equivalent to a power-on reset condition.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Reset the platform.
<screen>
RedBoot> <userinput>reset</userinput>
... Resetting.+... Waiting for network card: .
Socket Communications, Inc: Low Power Ethernet CF Revision C 5V/3.3V 08/27/98
Ethernet eth0: MAC address 00:c0:1b:00:ba:28
IP: 192.168.1.29, Default server: 192.168.1.101
 
RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 10:41:41, May 14 2002
 
Platform: Compaq iPAQ Pocket PC (StrongARM 1110)
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
 
RAM: 0x00000000-0x01fc0000, 0x00014748-0x01f71000 available
FLASH: 0x50000000 - 0x51000000, 64 blocks of 0x00040000 bytes each.
RedBoot>
</screen>
</para>
</refsect1>
</refentry>
 
 
<!-- ******** version *************************************************** -->
<refentry id="version-command">
<refnamediv>
<refname>version</refname>
<refpurpose>Display RedBoot version information</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>version</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<para><emphasis>None</emphasis></para>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <command>version</command> command simply displays version information about RedBoot.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Display RedBoot's version.
<screen>
RedBoot> <userinput>version</userinput>
RedBoot(tm) debug environment - built 09:12:03, Feb 12 2001
Platform: XYZ (PowerPC 860)
Copyright (C) 2000, 2001, Red Hat, Inc.
RAM: 0x00000000-0x00400000
</screen>
</para>
</refsect1>
</refentry>
 
</sect1>
<sect1 id="Flash-Image-System">
<title>Flash Image System (FIS)</title>
<para><indexterm><primary>commands</primary><secondary>flash image system
</secondary></indexterm><indexterm><primary>flash image system commands</primary>
</indexterm><indexterm><primary>commands</primary><secondary>fis</secondary>
</indexterm><indexterm><primary>fis commands</primary></indexterm>If the platform
has flash memory, RedBoot can use this for image storage. Executable images,
as well as data, can be stored in flash in a simple file store. The <command>
fis</command> command (fis is short for Flash Image System) is used to
manipulate and maintain flash images.
</para>
 
<!-- ******** fis init ************************************************ -->
 
<refentry id="fis-init-command">
<refnamediv>
<refname>fis init</refname>
<refpurpose>Initialize Flash Image System (FIS)</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis init</command>
<arg><replaceable>-f</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-f</entry>
<entry></entry>
<entry>All blocks of flash memory (except for the boot
blocks) will be erased as part of the initialization
procedure.</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
 
<para>This command is used to initialize the Flash Image System
(FIS). It should normally only be executed once, when RedBoot
is first installed on the hardware. If the reserved images or
their sizes in the FIS change, due to a different configuration
of RedBoot being used, it may be necessary to issue the command
again though.
 
<note><para>Subsequent executions will cause loss of
previously stored information in the FIS.</para></note>
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Initialize the FIS directory.
<screen>
RedBoot> <userinput>fis init</userinput>
About to initialize [format] flash image system - continue (y/n)? <userinput>y</userinput>
*** Initialize FLASH Image System
Warning: device contents not erased, some blocks may not be usable
... Erase from 0x00070000-0x00080000: .
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
</screen>
</para>
 
<para>
Initialize the FIS directory and all of flash memory, except for first
blocks of the flash where the boot monitor resides.
<screen>
RedBoot> <userinput>fis init -f</userinput>
About to initialize [format] flash image system - continue (y/n)? <userinput>y</userinput>
*** Initialize FLASH Image System
... Erase from 0x00020000-0x00070000: .....
... Erase from 0x00080000-0x00080000:
... Erase from 0x00070000-0x00080000: .
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis list ************************************************ -->
<refentry id="fis-list-command">
<refnamediv>
<refname>fis list</refname>
<refpurpose>List Flash Image System directory</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis list</command>
<arg><replaceable>-f</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-c</entry>
<entry></entry>
<entry>Show image checksum instead of memory address
(column <computeroutput>Mem addr</computeroutput> is
replaced by
<computeroutput>Checksum</computeroutput>).</entry>
<entry></entry>
</row>
<row>
<entry>-d</entry>
<entry></entry>
<entry>Show image data length instead of amount of flash
occupied by image (column
<computeroutput>Length</computeroutput> is replaced by
<computeroutput>Datalen</computeroutput>).</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command lists the images currently available in the FIS. Certain
images used by RedBoot have fixed names and have reserved slots in the
FIS (these can be seen after using the <command>fis init</command>
command). Other images can be manipulated by the user.</para>
<note><para>The images are listed in the order they appear in the FIS
directory, not by name or creation time.</para></note>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>
List the FIS directory.
<screen>
RedBoot> <userinput>fis list</userinput>
Name FLASH addr Mem addr Length Entry point
RedBoot 0x00000000 0x00000000 0x00020000 0x00000000
RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000
FIS directory 0x00070000 0x00070000 0x0000F000 0x00000000
</screen>
</para>
 
<para>
List the FIS directory, with image checksums substituted for
memory addresses.
<screen>
RedBoot> <userinput>fis list -c</userinput>
Name FLASH addr Checksum Length Entry point
RedBoot 0x00000000 0x00000000 0x00020000 0x00000000
RedBoot config 0x0007F000 0x00000000 0x00001000 0x00000000
FIS directory 0x00070000 0x00000000 0x0000F000 0x00000000
</screen>
</para>
 
<para>
List the FIS directory with image data lengths substituted for flash
block reservation lengths.
<screen>
RedBoot> <userinput>fis list</userinput>
Name FLASH addr Mem addr Datalen Entry point
RedBoot 0x00000000 0x00000000 0x00000000 0x00000000
RedBoot config 0x0007F000 0x0007F000 0x00000000 0x00000000
FIS directory 0x00070000 0x00070000 0x00000000 0x00000000
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis free ************************************************ -->
 
<refentry id="fis-free-command">
<refnamediv>
<refname>fis free</refname>
<refpurpose>Free flash image</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis free</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
 
 
<para>This command shows which areas of the flash memory are currently
not in use. When a block contains non-erased contents it is considered
in use. Since it is possible to force an image to be loaded at a
particular flash location, this command can be used to check whether
that location is in use by any other image.</para>
 
<note><para>There is currently no cross-checking between actual flash
contents and the FIS directory, which mans that there could be a
segment of flash which is not erased that does not correspond to a
named image, or vice-versa.</para></note>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>
Show free flash areas.
<screen>
RedBoot> <userinput>fis free</userinput>
0xA0040000 .. 0xA07C0000
0xA0840000 .. 0xA0FC0000
</screen></para>
</refsect1>
</refentry>
 
<!-- ******** fis create ************************************************ -->
 
<refentry id="fis-create-command">
<refnamediv>
<refname>fis create</refname>
<refpurpose>Create flash image</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis create</command>
<arg choice="req">-b <replaceable> data address</replaceable></arg>
<arg choice="req">-l <replaceable> length</replaceable></arg>
<arg>-f <replaceable> flash address</replaceable></arg>
<arg>-e <replaceable> entry</replaceable></arg>
<arg>-r <replaceable> relocation address</replaceable></arg>
<arg>-s <replaceable> data length</replaceable></arg>
<arg>-n </arg>
<arg><replaceable>name</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-b</entry>
<entry>Number</entry>
<entry>Address of data to be written to the flash.</entry>
<entry>Address of last loaded file. If not set in a load
operation, it must be specified.</entry>
</row>
<row>
<entry>-l</entry>
<entry>Number</entry>
<entry>Length of flash area to occopy. If specified, and
the named image already exists, the length must match
the value in the FIS directory.</entry>
<entry>Length of area reserved in FIS directory if the
image already exists, or the length of the last loaded
file. If neither are set, it must be specified.</entry>
</row>
<row>
<entry>-f</entry>
<entry>Number</entry>
<entry>Address of flash area to occopy.</entry>
<entry>The address of an area reserved in the FIS
directory for extant images. Otherwise the first free block
which is large enough will be used.</entry>
</row>
<row>
<entry>-e</entry>
<entry>Number</entry>
<entry>Entry address for an executable image, used by
the <command>fis load</command> command.</entry>
<entry>The entry address of last loaded file.</entry>
</row>
<row>
<entry>-r</entry>
<entry>Number</entry>
<entry>Address where the image should be relocated to by
the <command>fis load</command> command. This is only
relevant for images that will be loaded with the
<command>fis load</command> command.</entry>
<entry>The load address of the last loaded file.</entry>
</row>
<row>
<entry>-s</entry>
<entry>Number</entry>
<entry>Actual length of data written to image. This is
used to control the range over which the checksum is
made.</entry>
<entry>It defaults to the length of the last loaded
file.</entry>
</row>
<row>
<entry>-n</entry>
<entry></entry>
<entry>When set, no image data will be written to the
flash. Only the FIS directory will be updated.</entry>
<entry></entry>
</row>
<row>
<entry><replaceable>name</replaceable></entry>
<entry>String</entry>
<entry>Name of flash image.</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command creates an image in the FIS directory. The data for the
image must exist in RAM memory before the copy. Typically, you would use the
RedBoot <command>load</command> command to load file into
RAM and then the <command>fis create</command> command to write
it to a flash image.</para>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>Trying to create an extant image, will require the action
to be verified.
<screen>
RedBoot> <userinput>fis create RedBoot -f 0xa0000000 -b 0x8c400000 -l 0x20000</userinput>
An image named &lsquo;RedBoot&rsquo; exists - continue (y/n)? <userinput>n</userinput>
</screen>
</para>
 
<para>Create a new test image, let the command find a suitable place.
<screen>
RedBoot> <userinput>fis create junk -b 0x8c400000 -l 0x20000</userinput>
... Erase from 0xa0040000-0xa0060000: .
... Program from 0x8c400000-0x8c420000 at 0xa0040000: .
... Erase from 0xa0fe0000-0xa1000000: .
... Program from 0x8c7d0000-0x8c7f0000 at 0xa0fe0000: .
</screen>
</para>
 
<para>Update the RedBoot[RAM] image.
<screen>
RedBoot> <userinput>load redboot_RAM.img</userinput>
Entry point: 0x060213c0, address range: 0x06020000-0x06036cc0
RedBoot> <userinput>fis create RedBoot[RAM]</userinput>
No memory address set.
An image named 'RedBoot[RAM]' exists - continue (y/n)? <userinput>y</userinput>
* CAUTION * about to program 'RedBoot[RAM]'
at 0x00020000..0x00036cbf from 0x06020000 - continue (y/n)? <userinput>y</userinput>
... Erase from 0x00020000-0x00040000: ..
... Program from 0x06020000-0x06036cc0 at 0x00020000: ..
... Erase from 0x00070000-0x00080000: .
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis load ************************************************ -->
 
<refentry id="fis-load-command">
<refnamediv>
<refname>fis load</refname>
<refpurpose>Load flash image</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis load</command>
<arg>-b <replaceable> load address</replaceable></arg>
<arg>-c </arg>
<arg>-d </arg>
<arg><replaceable>name</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-b</entry>
<entry>Number</entry>
<entry>Address the image should be loaded to. Executable
images normally load at the location to which the file
was linked. This option allows the image to be loaded to
a specific memory location, possibly overriding any
assumed location.</entry>
<entry>If not specified, the address associated with the
image in the FIS directory will be used.</entry>
</row>
<row>
<entry>-c</entry>
<entry></entry>
<entry>Compute and print the checksum of the image data
after it has been loaded into memory.</entry>
</row>
<row>
<entry>-d</entry>
<entry></entry>
<entry>Decompress gzipped image while copying it from
flash to RAM.</entry>
</row>
<row>
<entry><replaceable>name</replaceable></entry>
<entry>String</entry>
<entry>The name of the file, as shown in the FIS
directory.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command is used to transfer an image from flash memory to RAM.
</para>
<para>Once the image has been loaded, it may be executed using the
<command>go</command> command.</para>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>Load and run RedBoot[RAM] image.
<screen>
RedBoot> <userinput>fis load RedBoot[RAM]</userinput>
RedBoot> <userinput>go</userinput>
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis delete ************************************************ -->
 
<refentry id="fis-delete-command">
<refnamediv>
<refname>fis delete</refname>
<refpurpose>Delete flash image</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis delete</command>
<arg choice="req"><replaceable>name</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry><replaceable>name</replaceable></entry>
<entry>Number</entry>
<entry>Name of image that should be deleted.</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command removes an image from the FIS. The flash memory will be
erased as part of the execution of this command, as well as removal of the
name from the FIS directory.</para>
 
<note><para>Certain images are reserved by RedBoot and cannot be deleted.
RedBoot will issue a warning if this is attempted.</para></note>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
<screen>
RedBoot> <userinput>fis list</userinput>
Name flash addr Mem addr Length Entry point
RedBoot 0xA0000000 0xA0000000 0x020000 0x80000000
RedBoot config 0xA0FC0000 0xA0FC0000 0x020000 0x00000000
FIS directory 0xA0FE0000 0xA0FE0000 0x020000 0x00000000
junk 0xA0040000 0x8C400000 0x020000 0x80000000
RedBoot> <userinput>fis delete junk</userinput>
Delete image &lsquo;junk&rsquo; - continue (y/n)? <userinput>y</userinput>
... Erase from 0xa0040000-0xa0060000: .
... Erase from 0xa0fe0000-0xa1000000: .
... Program from 0x8c7d0000-0x8c7f0000 at 0xa0fe0000: .
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis lock ************************************************ -->
 
<refentry id="fis-lock-command">
<refnamediv>
<refname>fis lock</refname>
<refpurpose>Lock flash area</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis lock</command>
<arg choice="req">-f <replaceable>flash_address</replaceable></arg>
<arg choice="req">-l <replaceable>length</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry><replaceable>flash_address</replaceable></entry>
<entry>Number</entry>
<entry>Address of area to be locked.</entry>
<entry></entry>
</row>
<row>
<entry><replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of area to be locked.</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command is used to write-protect (lock) a portion of flash memory,
to prevent accidental overwriting of images. In order to make make any modifications
to the flash, a matching <command>fis unlock</command> command must be
issued. This command is optional and will only be provided on hardware
which can support write-protection of the flash space.</para>
<note>
<para>Depending on the system, attempting to write to write-protected flash
may generate errors or warnings, or be benignly quiet. </para>
</note>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>Lock an area of the flash
<screen>
RedBoot> <userinput>fis lock -f 0xa0040000 -l 0x20000</userinput>
... Lock from 0xa0040000-0xa0060000: .
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis unlock ************************************************ -->
 
<refentry id="fis-unlock-command">
<refnamediv>
<refname>fis unlock</refname>
<refpurpose>Unlock flash area</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis unlock</command>
<arg choice="req">-f <replaceable>flash_address</replaceable></arg>
<arg choice="req">-l <replaceable>length</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry><replaceable>flash_address</replaceable></entry>
<entry>Number</entry>
<entry>Address of area to be unlocked.</entry>
<entry></entry>
</row>
<row>
<entry><replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of area to be unlocked.</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command is used to unlock a portion of flash memory forcibly, allowing
it to be updated. It must be issued for regions which have been locked before
the FIS can reuse those portions of flash.</para>
<note>
<para>Some flash devices power up in locked state and always need to
be manually unlocked before they can be written to.</para></note>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>Unlock an area of the flash
<screen>
RedBoot> <userinput>fis unlock -f 0xa0040000 -l 0x20000</userinput>
... Unlock from 0xa0040000-0xa0060000: .
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis erase ************************************************ -->
 
<refentry id="fis-erase-command">
<refnamediv>
<refname>fis erase</refname>
<refpurpose>Erase flash area</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis erase</command>
<arg choice="req">-f <replaceable>flash_address</replaceable></arg>
<arg choice="req">-l <replaceable>length</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry><replaceable>flash_address</replaceable></entry>
<entry>Number</entry>
<entry>Address of area to be erased.</entry>
<entry></entry>
</row>
<row>
<entry><replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of area to be erased.</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command is used to erase a portion of flash memory forcibly. There
is no cross-checking to ensure that the area being erased does not correspond
to an existing image.</para>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>Erase an area of the flash
<screen>
RedBoot> <userinput>fis erase -f 0xa0040000 -l 0x20000</userinput>
... Erase from 0xa0040000-0xa0060000: .
</screen>
</para>
</refsect1>
</refentry>
 
<!-- ******** fis write ************************************************ -->
 
<refentry id="fis-write-command">
<refnamediv>
<refname>fis write</refname>
<refpurpose>Write flash area</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>fis write</command>
<arg choice="req">-b <replaceable>mem_address</replaceable></arg>
<arg choice="req">-l <replaceable>length</replaceable></arg>
<arg choice="req">-f <replaceable>flash_address</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry><replaceable>mem_address</replaceable></entry>
<entry>Number</entry>
<entry>Address of data to be written to flash.</entry>
<entry></entry>
</row>
<row>
<entry><replaceable>length</replaceable></entry>
<entry>Number</entry>
<entry>Length of data to be writtem.</entry>
<entry></entry>
</row>
<row>
<entry><replaceable>flash_address</replaceable></entry>
<entry>Number</entry>
<entry>Address of flash to write to.</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>This command is used to write data from memory to flash. There
is no cross-checking to ensure that the area being written to does not
correspond to an existing image.</para>
</refsect1>
 
<refsect1>
<title>Examples</title>
<para>Write an area of data to the flash
<screen>
RedBoot> <userinput>fis write -b 0x0606f000 -l 0x1000 -f 0x00020000</userinput>
* CAUTION * about to program FLASH
at 0x00020000..0x0002ffff from 0x0606f000 - continue (y/n)? <userinput>y</userinput>
... Erase from 0x00020000-0x00030000: .
... Program from 0x0606f000-0x0607f000 at 0x00020000: .
</screen>
</para>
</refsect1>
</refentry>
 
</sect1>
<sect1 id="Persistent-State-Flash">
<title>Persistent State Flash-based Configuration and Control</title>
<para><indexterm><primary>persistent state flash-based configuration and control
</primary></indexterm><indexterm><primary>flash-based configuration and control
</primary></indexterm><indexterm><primary>configuration and control</primary>
<secondary>flash-based</secondary></indexterm></para>
<para>RedBoot provides flash management support for storage in the flash memory
of multiple executable images and of non-volatile information such as IP addresses
and other network information.</para>
<para>RedBoot on platforms that support flash based configuration information
will report the following message the first time that RedBoot is booted on
the target:</para>
<screen>flash configuration checksum error or invalid key</screen>
<para>This error can be ignored if no flash based configuration is desired,
or can be silenced by running the <command>fconfig</command>
command as described below. At this point you may also wish to run the <command>
fis init</command> command. See other fis commands in <xref linkend="Flash-Image-System">.
</para>
<para>Certain control and configuration information used by RedBoot can be
stored in flash. </para>
<para>The details of what information is maintained in flash differ, based
on the platform and the configuration. However, the basic operation used to
maintain this information is the same. Using the <command>fconfig -l
</command> command, the information may be displayed and/or changed.
</para>
<para>If the optional flag <computeroutput>-i</computeroutput> is specified,
then the configuration database will be reset to its default
state. This is also needed the first time RedBoot is installed on the
target, or when updating to a newer RedBoot with different
configuration keys.
</para>
<para>If the optional flag <computeroutput>-l</computeroutput> is specified,
the configuration data is simply listed. Otherwise, each configuration parameter
will be displayed and you are given a chance to change it. The entire value
must be typed - typing just carriage return will leave a value unchanged.
Boolean values may be entered using the first letter (<computeroutput>t</computeroutput>
for true, <computeroutput>f</computeroutput> for false). At any time the editing
process may be stopped simply by entering a period (.) on the line. Entering
the caret (^) moves the editing back to the previous item. See &ldquo;RedBoot
Editing Commands&rdquo;, <xref linkend="RedBoot-Editing-Commands">. </para>
<para>If any changes are made in the configuration, then the updated data
will be written back to flash after getting acknowledgment from the user.
</para>
<para>
If the optional flag <computeroutput>-n</computeroutput> is specified
(with or without <computeroutput>-l</computeroutput>) then &ldquo;nicknames&rdquo;
of the entries are used. These are shorter and less descriptive than
&ldquo;full&rdquo; names. The full name may also be displayed by adding the
<computeroutput>-f</computeroutput> flag.</para>
<para>The reason for telling you nicknames is that a quick way to set a single
entry is provided, using the format
<screen>
RedBoot> <userinput>fconfig <replaceable>nickname</replaceable> <replaceable>value
</replaceable></userinput></screen>
If no
value is supplied, the command will list and prompt for only that entry.
If a value is supplied, then the entry will be set to that value. You will
be prompted whether to write the new information into flash if any change
was made. For example
<screen>
RedBoot> <userinput>fconfig -l -n</userinput>
boot_script: false
bootp: false
bootp_my_ip: 10.16.19.176
bootp_server_ip: 10.16.19.66
dns_ip: 10.16.19.1
gdb_port: 9000
net_debug: false
RedBoot> <userinput>fconfig bootp_my_ip 10.16.19.177</userinput>
bootp_my_ip: 10.16.19.176 Setting to 10.16.19.177
Update RedBoot non-volatile configuration - continue (y/n)? <userinput>y</userinput>
... Unlock from 0x507c0000-0x507e0000: .
... Erase from 0x507c0000-0x507e0000: .
... Program from 0x0000a8d0-0x0000acd0 at 0x507c0000: .
... Lock from 0x507c0000-0x507e0000: .
RedBoot>
</screen>
</para><para>
Additionally, nicknames can be used like aliases via the format %{nickname}.
This allows the values stored by <userinput>fconfig</userinput> to be used
directly by scripts and commands.
</para>
<para>Depending on how your terminal program is connected and its
capabilities, you might find that you are unable to use line-editing to
delete the &lsquo;old&rsquo; value when using the default behaviour of
<command>fconfig <replaceable>nickname</replaceable></command> or just
plain <command>fconfig</command>, as shown in this example:
<screen>
RedBoot> <userinput>fco bootp</userinput>
bootp: false&lowbar;
</screen>
The user deletes the word &ldquo;false;&rdquo and enters &ldquo;true&rdquo;
so the display looks like this:
<screen>
RedBoot> <userinput>fco bootp</userinput>
bootp: <userinput>true</userinput>
Update RedBoot non-volatile configuration - continue (y/n)? y
... Unlock from ...
RedBoot> &lowbar;
</screen>
</para>
<para>To edit when you cannot backspace, use the optional flag
<computeroutput>-d</computeroutput> (for &ldquo;dumb terminal&rdquo;)
to provide a simpler interface thus:
<screen>
RedBoot> <userinput>fco -d bootp</userinput>
bootp: false ? &lowbar;
</screen>
and you enter the value in the obvious manner thus:
<screen>
RedBoot> <userinput>fco -d bootp</userinput>
bootp: false ? <userinput>true</userinput>
Update RedBoot non-volatile configuration - continue (y/n)? y
... Unlock from ...
RedBoot> &lowbar;
</screen>
</para>
<para>One item which is always present in the configuration data is the ability
to execute a script at boot time. A sequence of RedBoot commands can be entered
which will be executed when the system starts up. Optionally, a time-out period
can be provided which allows the user to abort the startup script and proceed
with normal command processing from the console. </para>
<para><screen>
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
</screen></para>
<para>The following example sets a boot script and then shows it running.
</para>
<para>
<screen>
RedBoot> <userinput>fconfig</userinput>
Run script at boot: false <userinput>t</userinput>
Boot script:
Enter script, terminate with empty line
>> <userinput>fi li</userinput>
Boot script timeout: 0 <userinput>10</userinput>
Use BOOTP for network configuration: false .
Update RedBoot non-volatile configuration - continue (y/n)? <userinput>y</userinput>
... Erase from 0xa0fc0000-0xa0fe0000: .
... Program from 0x8c021f60-0x8c022360 at 0xa0fc0000: .
RedBoot>
RedBoot(tm) debug environment - built 08:22:24, Aug 23 2000
Copyright (C) 2000, Red Hat, Inc.
 
 
RAM: 0x8c000000-0x8c800000
flash: 0xa0000000 - 0xa1000000, 128 blocks of 0x00020000 bytes ea.
Socket Communications, Inc: Low Power Ethernet CF Revision C \
5V/3.3V 08/27/98 IP: 192.168.1.29, Default server: 192.168.1.101 \
== Executing boot script in 10 seconds - enter ^C to abort
RedBoot> <userinput>fi li</userinput>
Name flash addr Mem addr Length Entry point
RedBoot 0xA0000000 0xA0000000 0x020000 0x80000000
RedBoot config 0xA0FC0000 0xA0FC0000 0x020000 0x00000000
FIS directory 0xA0FE0000 0xA0FE0000 0x020000 0x00000000
RedBoot>
</screen>
</para>
<note><title>NOTE</title>
<para>The bold characters above indicate where something was entered on the
console. As you can see, the <command>fi li</command> command
at the end came from the script,
not the console. Once the script is executed, command processing reverts to
the console. </para>
</note>
<para>
<note><title>NOTE</title>
<para>
RedBoot supports the notion of a boot script timeout, i.e. a period of
time that RedBoot waits before executing the boot time script. This period
is primarily to allow the possibility of canceling the script. Since
a timeout value of zero (0) seconds would never allow the script to
be aborted or canceled, this value is not allowed. If the timeout
value is zero, then RedBoot will abort the script execution immediately.
</para>
</note>
On many targets, RedBoot may be configured to run from ROM or it may be
configured to run from RAM. Other configurations are also possible. All
RedBoot configurations will execute the boot script, but in certain cases
it may be desirable to limit the execution of certain script commands to
one RedBoot configuration or the other. This can be accomplished by
prepending <computeroutput>{&lt;startup type>}</computeroutput> to the
commands which should be executed only by the RedBoot configured for the
specified startup type. The following boot script illustrates this concept
by having the ROM based RedBoot load and run the RAM based RedBoot. The RAM
based RedBoot will then list flash images.</para>
<para><screen>
RedBoot> <userinput>fco</userinput>
Run script at boot: false <userinput>t</userinput>
Boot script:
Enter script, terminate with empty line
>> <userinput>{ROM}fis load RedBoot[RAM]</userinput>
>> <userinput>{ROM}go</userinput>
>> <userinput>{RAM}fis li</userinput>
>>
Boot script timeout (1000ms resolution): <userinput>2</userinput>
Use BOOTP for network configuration: <userinput>false</userinput>
...
Update RedBoot non-volatile configuration - continue (y/n)? <userinput>y</userinput>
... Unlock from 0x007c0000-0x007e0000: .
... Erase from 0x007c0000-0x007e0000: .
... Program from 0xa0015030-0xa0016030 at 0x007df000: .
... Lock from 0x007c0000-0x007e0000: .
RedBoot> <userinput>reset</userinput>
... Resetting.
+Ethernet eth0: MAC address 00:80:4d:46:01:05
IP: 192.168.1.153, Default server: 192.168.1.10
 
RedBoot(tm) bootstrap and debug environment [ROM]
Red Hat certified release, version R1.xx - built 17:37:36, Aug 14 2001
 
Platform: IQ80310 (XScale)
Copyright (C) 2000, 2001, Red Hat, Inc.
 
RAM: 0xa0000000-0xa2000000, 0xa001b088-0xa1fdf000 available
FLASH: 0x00000000 - 0x00800000, 64 blocks of 0x00020000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
RedBoot> <userinput>fis load RedBoot[RAM]</userinput>
RedBoot> <userinput>go</userinput>
+Ethernet eth0: MAC address 00:80:4d:46:01:05
IP: 192.168.1.153, Default server: 192.168.1.10
 
RedBoot(tm) bootstrap and debug environment [RAM]
Red Hat certified release, version R1.xx - built 13:03:47, Aug 14 2001
 
Platform: IQ80310 (XScale)
Copyright (C) 2000, 2001, Red Hat, Inc.
 
RAM: 0xa0000000-0xa2000000, 0xa0057fe8-0xa1fdf000 available
FLASH: 0x00000000 - 0x00800000, 64 blocks of 0x00020000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
RedBoot> <userinput>fis li</userinput>
Name FLASH addr Mem addr Length Entry point
RedBoot 0x00000000 0x00000000 0x00040000 0x00002000
RedBoot config 0x007DF000 0x007DF000 0x00001000 0x00000000
FIS directory 0x007E0000 0x007E0000 0x00020000 0x00000000
RedBoot>
</screen></para>
</sect1>
<sect1 id="executing-programs">
<title>Executing Programs from RedBoot</title>
<para><indexterm><primary>executing programs</primary></indexterm><indexterm>
<primary>RedBoot</primary><secondary>executing programs</secondary></indexterm>Once
an image has been loaded into memory, either via the <command>load
</command> command or the <command>fis load</command>
command, execution may be transfered to that image.</para>
<para> <note><title>NOTE</title>
<para>The image is assumed to be a stand-alone entity, as RedBoot gives the
entire platform over to it. Typical examples would be an eCos application
or a Linux kernel.</para>
</note></para>
 
 
<!-- ******** go *************************************************** -->
<refentry id="go-command">
<refnamediv>
<refname>go</refname>
<refpurpose>Execute a program</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>go</command>
<arg>-w <replaceable> timeout</replaceable></arg>
<arg><replaceable> start_address</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-w <replaceable>timeout</replaceable></entry>
<entry>Number</entry>
<entry>How long to wait before starting execution.</entry>
<entry>0</entry>
</row>
<row>
<entry><replaceable>start_address</replaceable></entry>
<entry>Number</entry>
<entry>Address in memory to begin execution.</entry>
<entry>Value set by last <command>load</command> or <command>fis load</command> command.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>
The <command>go</command> command causes RedBoot to give control of the target platform to
another program. This program must execute stand alone, e.g. an eCos
application or a Linux kernel.
</para>
<para>
If the -w option is used, RedBoot will print a message and then
wait for a period of time before starting the execution. This is
most useful in a script, giving the user a chance to abort executing
a program and move on in the script.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Execute a program - <emphasis>no explicit output from RedBoot</emphasis>.
<screen>
RedBoot> <userinput>go 0x40040</userinput>
</screen>
</para>
<para>
Execute a program with a timeout.
<screen>
RedBoot> <userinput>go -w 10</userinput>
About to start execution at 0x00000000 - abort with ^C within 10 seconds
^C
RedBoot>
</screen>
Note that the starting address was implied (0x00000000 in this example).
The user is prompted that execution will commence in 10 seconds. At
anytime within that 10 seconds the user may type <guibutton>Ctrl+C</guibutton>
on the console and RedBoot will abort execution and return for the next
command, either from a script or the console.
</para>
</refsect1>
</refentry>
 
<!-- ******** exec *************************************************** -->
<refentry id="exec-command">
<refnamediv>
<refname>exec</refname>
<refpurpose>Execute a Linux kernel</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>exec</command>
<arg>-w <replaceable> timeout</replaceable></arg>
<arg>-r <replaceable> ramdisk_address</replaceable></arg>
<arg>-s <replaceable> ramdisk_length</replaceable></arg>
<arg>-b <replaceable> load_address</replaceable>
<arg choice="req">-l <replaceable> load_length</replaceable></arg>
</arg>
<arg>-c <replaceable> kernel_command_line</replaceable></arg>
<arg><replaceable> entry_point</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<informaltable frame="all">
<tgroup cols="4" colsep="1" rowsep="1" align="left">
<colspec colname="c1">
<colspec colname="c2">
<colspec colname="c3">
<colspec colname="c4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
<entry>Default</entry>
</row>
</thead>
<tbody>
<row>
<entry>-w <replaceable>timeout</replaceable></entry>
<entry>Number</entry>
<entry>Time to wait before starting execution.</entry>
<entry>0</entry>
</row>
<row>
<entry>-r <replaceable>ramdisk_address</replaceable></entry>
<entry>Number</entry>
<entry>Address in memory of "initrd"-style ramdisk - passed to Linux kernel.</entry>
<entry><emphasis>None</emphasis></entry>
</row>
<row>
<entry>-s <replaceable>ramdisk_length</replaceable></entry>
<entry>Number</entry>
<entry>Length of ramdisk image - passed to Linux kernel.</entry>
<entry><emphasis>None</emphasis></entry>
</row>
<row>
<entry>-b <replaceable>load_address</replaceable></entry>
<entry>Number</entry>
<entry>Address in memory of the Linux kernel image.</entry>
<entry>Value set by <command>load</command> or <command>fis load</command></entry>
</row>
<row>
<entry>-l <replaceable>load_length</replaceable></entry>
<entry>Number</entry>
<entry>Length of Linux kernel image.</entry>
<entry><emphasis>none</emphasis></entry>
</row>
<row>
<entry>-c <replaceable>kernel_command_line</replaceable></entry>
<entry>String</entry>
<entry>Command line to pass to the Linux kernel.</entry>
<entry><emphasis>None</emphasis></entry>
</row>
<row>
<entry><replaceable>entry_address</replaceable></entry>
<entry>Number</entry>
<entry>Starting address for Linux kernel execution</entry>
<entry>Implied by architecture</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</refsect1>
<refsect1>
<title>Description</title>
<para>
The <command>exec</command> command is used to execute a non-eCos application, typically a
Linux kernel. Additional information may be passed to the kernel at startup
time. This command is quite special (and unique from the <command>go</command> command) in
that the program being executed may expect certain environmental setups, for
example that the MMU is turned off, etc. </para>
<para>The Linux kernel expects to have been loaded to a particular memory
location which is architecture dependent(0xC0008000 in the case of the SA1110).
Since this memory is used
by RedBoot internally, it is not possible to load the kernel to that location
directly. Thus the requirement for the "-b" option which tells the command
where the kernel has been loaded. When the <command>exec</command> command runs, the image will
be relocated to the appropriate location before being started. The "-r" and
"-s" options are used to pass information to the kernel about where a statically
loaded ramdisk (initrd) is located.</para>
<para>The "-c" option can be used to pass textual "command line" information
to the kernel. If the command line data contains any punctuation (spaces,
etc), then it must be quoted using the double-quote character '"'. If the
quote character is required, it should be written as '\"'.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Execute a Linux kernel, passing a command line, which needs relocation.
The result from RedBoot is normally quiet, with the target platform being
passed over to Linux immediately.
<screen>
RedBoot> <userinput>exec -b 0x100000 -l 0x80000 -c "noinitrd root=/dev/mtdblock3 console=ttySA0"</userinput>
</screen>
</para>
<para>
Execute a Linux kernel, default entry address and no relocation required, with a timeout.
The <emphasis> emphasized lines</emphasis> are output from the loaded kernel.
<screen>
RedBoot> exec <userinput>-c "console=ttyS0,38400 ip=dhcp nfsroot=/export/elfs-sh" -w 5</userinput>
Now booting linux kernel:
Base address 0x8c001000 Entry 0x8c210000
Cmdline : console=ttyS0,38400 ip=dhcp nfsroot=/export/elfs-sh
About to start execution at 0x8x210000 - abort with ^C within 5 seconds
<emphasis>
Linux version 2.4.10-pre6 (...) (gcc version 3.1-stdsh-010931) #3 Thu Sep 27 11:04:23 BST 2001
</emphasis>
</screen>
</para>
</refsect1>
</refentry>
 
</sect1>
</chapter>
/redboot_epilogue.sgml
0,0 → 1,3
 
<!-- <index id="index"></index> -->
</part>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.