<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>
<sect1 id="iq80310">
<title>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. Several basic RedBoot configurations
are supported: </para>
<itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from flash address 0x40000, with ARM bootloader
in flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>RedBoot running from RAM with ARM bootloader in flash boot
sector.</para>
</listitem>
</itemizedlist>
<para>A special RedBoot command: <command>diag</command> is
used to access a set of hardware diagnostics provided by the board manufacturer.
</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
configurations to flash. The RedBoot which runs from the flash boot sector
should be programmed to flash address 0x00000000. RedBoot that has been configured
to be started by the ARM bootloader should be programmed to flash address
0x00004000. </para>
<para>Four sets of prebuilt files are provided in a tarball and zip format.
Each set corresponds to one of the four supported configurations and includes
an ELF file (.elf), a binary image (.bin), and an S-record file (.srec). <programlisting>
For RedBoot running from the flash boot sector:
bins/cyclone-rom.bin
bins/cyclone-rom.elf
bins/cyclone-rom.srec


For RedBoot running from flash address 0x40000:
bins/cyclone-roma.bin
bins/cyclone-roma.elf
bins/cyclone-roma.srec


For RedBoot running from RAM with RedBoot in the flash boot sector:
bins/cyclone-ram.bin
bins/cyclone-ram.elf
bins/cyclone-ram.srec


For RedBoot running from RAM with ARM bootloader in the flash boot sector:
bins/cyclone-rama.bin
bins/cyclone-rama.elf
bins/cyclone-rama.srec</programlisting>Initial installations deal with the
flash-based RedBoots. Installation and use of RAM based RedBoots is documented
elsewhere.</para>
<para> To install RedBoot to run from the flash boot sector, use the manufacturer's
flash utility to install the bins/cyclone-rom.bin 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 bins/cyclone-roma.bin image at address 0x40000. </para>
<para>After booting the initial installation of RedBoot, this warning may
be printed: <programlisting>flash configuration checksum error or invalid key
</programlisting>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: <programlisting>RedBoot> <userinput>fis init</userinput>
About to initialize [format] flash image system - continue (y/n)? y
*** 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: .</programlisting></para>
</sect2>
<sect2>
<title>Error codes</title>
<para>RedBoot uses the two digit LED display to indicate errors during   board
initialization. Possible error codes are:      <programlisting>88 - Unknown Error
55 - I2C Error
FF - SDRAM Error
01 - No Error </programlisting></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>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be: </para>
<bridgehead>ARM bootloader in flash boot sector</bridgehead>
<para><programlisting>-f 0x40000
-b 0xa0100000
-l 0x40000</programlisting></para>
<bridgehead>RedBoot in flash boot sector</bridgehead>
<para><programlisting>-f 0
-b 0xa0100000
-l 0x40000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<bridgehead>ARM bootloader in flash boot sector</bridgehead>
<programlisting>-f 0x80000
-b 0xa0020000
-r 0xa0020000
-l 0x40000</programlisting>
<bridgehead>RedBoot in flash boot sector</bridgehead>
<programlisting>-f 0x40000
-b 0xa0020000
-r 0xa0020000
-l 0x40000</programlisting>
</sect3></sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>A special RedBoot command, diag, 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: 
<programlisting>
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):
</programlisting>
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>The build process is nearly identical for the four supported configurations.
Assuming that the provided RedBoot source tree is located in the current directory
and that we want to build a RedBoot that runs from the flash boot sector,
the build process is: <programlisting>% export TOPDIR=`pwd`
% export ECOS_REPOSITORY=\
    ${TOPDIR}/src/ecos-monitors/redboot-<replaceable>DATE</replaceable>-intel/packages
% mkdir ${TOPDIR}/build
% cd ${TOPDIR}/build
% ecosconfig new iq80310 redboot
% ecosconfig import \
   ${ECOS_REPOSITORY}/hal/arm/iq80310/<replaceable>VERSION</replaceable>/misc/redboot_ROM.ecm
% ecosconfig tree
% make</programlisting>If a different configuration is desired,
simply use the above build process but substitute an alternate configuration
file for the ecosconfig import command, e.g.:</para>
<para>For a RedBoot that runs from flash address 0x40000 with the ARM booloader
in the flash boot sector, use: <programlisting>% ecosconfig import \
  ${ECOS_REPOSITORY}/hal/arm/iq80310/<replaceable>VERSION</replaceable>/misc/redboot_ROMA.ecm</programlisting>For
a RedBoot which runs from RAM with RedBoot located in the flash boot sector,
use:<programlisting>% ecosconfig import \
  ${ECOS_REPOSITORY}/hal/arm/iq80310/<replaceable>VERSION</replaceable>/misc/redboot_RAM.ecm</programlisting>For
a RedBoot which runs from RAM with ARM bootloader located in the flash boot
sector, use: <programlisting>% ecosconfig import \
  ${ECOS_REPOSITORY}/hal/arm/iq80310/<replaceable>VERSION</replaceable>/misc/redboot_RAMA.ecm</programlisting></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>Resource Usage</title>
<para>The standalone flash based RedBoot image (no ARM bootloader) occupies
flash addresses 0x00000000 - 0x0003ffff. </para>
<para>The flash based RedBoot configured to be booted by the ARM bootloader
occupies flash addresses 0x00040000 - 0x0007ffff. Both of these also reserve
RAM (0xa0000000 - 0xa001ffff) for RedBoot runtime uses. </para>
<para>Both RAM based RedBoot configurations are designed to run from RAM at
addresses 0xa0020000 - 0xa005ffff. RAM addresses from 0xa0060000 to the end
of RAM are available for general use, such as a temporary scratchpad for downloaded
images before they are written to flash. </para>
<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>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. Several basic RedBoot configurations
are supported: </para>
<itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist>
<para>A special RedBoot command: <command>diag</command> is
used to access a set of hardware diagnostics.
</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 flash based RedBoot to flash.
RedBoot should be programmed to flash address 0x00000000 using the DOS utility.
</para>
<para>Two sets of prebuilt files are provided in a tarball and zip format.
Each set corresponds to one of the supported configurations and includes
an ELF file (.elf), a binary image (.bin), and an S-record file (.srec). <programlisting>
For RedBoot running from the flash boot sector:
loaders/iq80321/iq80321-rom.bin
loaders/iq80321/iq80321-rom.elf
loaders/iq80321/iq80321-rom.srec

For RedBoot running from RAM with RedBoot in the flash boot sector:
loaders/iq80321/iq80321-ram.bin
loaders/iq80321/iq80321-ram.elf
loaders/iq80321/iq80321-ram.srec

</programlisting>Initial installations deal with the
flash-based RedBoots. Installation and use of RAM based RedBoots is documented
elsewhere.</para>
<para> To install RedBoot to run from the flash boot sector, use the manufacturer's
flash utility to install the
<filename>loaders/iq80321/iq80321-rom.bin</filename>
image at address zero.
</para>
<para>After booting the initial installation of RedBoot, this warning may
be printed: <programlisting>flash configuration checksum error or invalid key
</programlisting>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: <programlisting>RedBoot> <userinput>fis init</userinput>
About to initialize [format] FLASH image system - continue (y/n)? y
*** 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: .
</programlisting></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>

<programlisting 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
</programlisting>
</sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be: </para>
<para><programlisting>-f 0xf0000000
-b 0x100000
-l 0x40000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot image, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used with
the flags in the sample commands should be: </para>
<programlisting>-f 0xf0040000
-b 0x20000
-r 0x20000
-l 0x40000</programlisting>
</sect3></sect2>
<sect2>
<title>Special RedBoot Commands </title>
<para>A special RedBoot command, diag, is used to access a set of hardware
diagnostics. To access the diagnostic menu, enter diag at the RedBoot prompt: 
<programlisting>
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):
</programlisting>
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>
<programlisting>
Enter the menu item number (0 to quit): 1

Base address of memory to test (in hex): 100000

Size of memory to test (in hex): 200000

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.
</programlisting>
</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>
<programlisting>
Enter the menu item number (0 to quit): 6


Current MAC address: 00:80:4d:46:00:02
Enter desired MAC address: 00:80:4d:46:00:01
Writing to the Serial EEPROM... Done

******** Reset The Board To Have Changes Take Effect ********
</programlisting>
</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>The build process is nearly identical for the supported configurations.
Assuming that the provided RedBoot source tree is located in the current directory
and that we want to build a RedBoot that runs from the flash boot sector,
the build process is: <programlisting>% export TOPDIR=`pwd`
% export ECOS_REPOSITORY=\
    ${TOPDIR}/src/ecos-monitors/redboot-<replaceable>DATE</replaceable>-intel/packages
% mkdir ${TOPDIR}/build
% cd ${TOPDIR}/build
% ecosconfig new iq80321 redboot
% ecosconfig import \
   ${ECOS_REPOSITORY}/hal/arm/xscale/iq80321/<replaceable>VERSION</replaceable>/misc/redboot_ROM.ecm
% ecosconfig tree
% make</programlisting>If a RedBoot that runs from RAM is desired,
simply use the above build process but substitute an alternate configuration
file for the ecosconfig import command, e.g.:</para>
<para><programlisting>% ecosconfig import \
  ${ECOS_REPOSITORY}/hal/arm/xscale/iq80321/<replaceable>VERSION</replaceable>/misc/redboot_RAM.ecm
</programlisting></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>Resource Usage</title>
<para>The flash based RedBoot image occupies flash addresses
0xf0000000 - 0xf003ffff and RAM addresses (0x00000000 - 0x0001ffff). </para>
<para>The RAM based RedBoot configuration is designed to run from RAM at
addresses 0x00020000 - 0x0005ffff. RAM addresses from 0x00060000 to the end
of RAM are available for general use, such as a temporary scratchpad for
downloaded images before they are written to flash. </para>
<para>The Verde programmable timer0 is used for timeout support
for networking and XModem file transfers.</para>
</sect2></sect1>
<?Pub _newpage>
<sect1 id="brutus">
<title>Intel SA1100 (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>Two basic RedBoot configurations are supported:<itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist></para>
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>Device programmer is used to program socketecflash 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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x40000000 -
0x4000ffff. The RAM based RedBoot image occupies RAM addresses 0x10000 - 0x2ffff.
RAM addresses from 0x30000 to the end of RAM are available for general use
such as a temporary scratchpad for downloaded images before they are written
to flash. 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>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;brutus&rdquo;, &ldquo;arm&rdquo; and &ldquo;sa11x0/brutus&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/sa11x0/brutus/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="ebsa285">
<title>Intel StrongArm 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.</para>
<para>Management of onboard flash is also supported. Two basic RedBoot configurations
are supported: <itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist></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: <programlisting>.../packages/hal/arm/ebsa285/current/support/linux/safl_util
</programlisting></para>
</sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x41000000
-b 0x100000
-l 0x40000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:        <programlisting>-f 0x41040000
-b 0x20000
-r 0x20000
-l 0x40000
</programlisting></para>
</sect3></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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x41000000 -
0x4103ffff. It also reserves the first 192K bytes of RAM for runtime uses.
The RAM based RedBoot image occupies RAM addresses 0x30000 - 0x5ffff. RAM
addresses from 0x60000 to the end of RAM are available for general use such
as a temporary scratchpad for downloaded images before they are written to
flash.</para>
<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>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;ebsa285&rdquo;, &ldquo;arm&rdquo; and &ldquo;ebsa285&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/ebsa285/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="sa1100mm">
<title>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. Two basic RedBoot
configurations are supported: n <itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist></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>Resource Usage </title>
<para>The flash based RedBoot image occupies virtual addresses 0x50000000
- 0x5000ffff. The RAM based RedBoot image occupies virtual addresses 0x10000
- 0x2ffff. RAM addresses from 0x30000 to the end of RAM are available for
general use such as a temporary scratchpad for downloaded images before they
are written to flash.</para>
<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>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;sa1100mm&rdquo;, &ldquo;arm&rdquo; and &ldquo;sa11x0/sa1100mm&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/sa11x0/sa1100mm/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="assabet">
<title>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. Two basic RedBoot configurations are supported: <itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist></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>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x50000000
-b 0x60000
-l 0x40000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:        <programlisting>-f 0x50040000
-b 0x20000
-r 0x20000
-l 0x40000</programlisting></para>
</sect3></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
The flash based RedBoot image occupies virtual addresses 0x50000000 - 0x5003ffff.
</programlisting></para>
</sect2>
<sect2>
<title>Resource Usage </title>
<para>The RAM based RedBoot image occupies RAM addresses 0x20000 - 0x5ffff.
RAM addresses from 0x60000 to the end of RAM are available for general use
such as a temporary scratchpad for downloaded images before they are written
to flash. </para>
<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>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;assabet&rdquo;, &ldquo;arm&rdquo; and &ldquo;sa11x0/assabet&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/sa11x0/assabet/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="atlas">
<title>MIPS Atlas Board with CoreLV 4Kc and CoreLV 5Kc </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. These configurations are supported: <itemizedlist>
<listitem><para>RedBoot running from the system flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the system flash
boot sector.</para>
</listitem>
</itemizedlist></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: <computeroutput>
deleteall.dl</computeroutput> and <computeroutput>redboot.dl</computeroutput>.
</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 deleteall.dl file to the parallel port to erase previous
images: <programlisting>% cat deleteall.dl >/dev/lp0</programlisting> When
this is complete, the LED display should read &ldquo;Deleted.&rdquo; </para>
</listitem>
<listitem><para>Send the RedBoot image to the board: <programlisting>% cat redboot.dl >/dev/lp0
</programlisting>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 &ldquo;RedBoot&rdquo;. </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 <computeroutput>
srec2flash</computeroutput> utility. The source code for this utility is part
of the <computeroutput>yamon/yamon-src-01.01.tar.gz</computeroutput> tarball
on the Dev Kit CD. The path in the expanded tarball is <computeroutput>yamon/bin/tools
</computeroutput>.   To use <computeroutput>srec2flash</computeroutput> to
convert the S-record file:     <programlisting>% srec2flash -EL -S29 redboot.srec >redboot.dl
</programlisting> The <citetitle>Atlas/Malta Developer's Kit</citetitle> CD
contains an <computeroutput>srecconv.pl</computeroutput> utility which requires
Perl. This utilty is part of the <computeroutput>yamon/yamon-src-02.00.tar.gz
</computeroutput> tarball on the Dev Kit CD. The path in the expanded tarball
is <computeroutput>yamon/bin/tools</computeroutput>.   To use <computeroutput>
srecconv</computeroutput> to convert the S-record file:     <programlisting>
% cp redboot_ROM.srec redboot_ROM.rec
% srecconv.pl -ES L -A 29 redboot_ROM </programlisting>  The resulting file is
named redboot_ROM.fl.</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 <computeroutput>setenv
ethaddr</computeroutput> command to print out the board ethernet address.
Typically, it is:    <programlisting>00:0d:a0:00:xx:xx</programlisting> where
xx.xx is the hex representation of the board serial number.</para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be: <programlisting>-f 0x9dc40000
-b 0x80020000
-r 0x80020000
-l 0x40000</programlisting></para>
</sect3>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x9dc00000
-b 0x80080000
-l 0x40000</programlisting></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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x1fc00000 -
0x1fc1ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x00020000 - 0x0003ffff. RAM physical addresses from
0x00040000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;atlas_mips32_4kc&rdquo; or &ldquo;atlas_mips64_5kc&rdquo;, &ldquo;mips&rdquo;
and &ldquo;atlas&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/mips/atlas/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="malta">
<title>MIPS Malta Board with CoreLV 4Kc and CoreLV 5Kc </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. These configurations are supported: <itemizedlist>
<listitem><para>RedBoot running from the system flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the system flash
boot sector.</para>
</listitem>
</itemizedlist></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 deleteall.fl file to the parallel port to erase previous
images: <programlisting>% cat deleteall.fl >/dev/lp0</programlisting> When
this is complete, the LED display should read <computeroutput>Deleted.</computeroutput></para>
</listitem>
<listitem><para>Send the RedBoot image to the board:  <programlisting>% cat redboot_ROM.fl >/dev/lp0
</programlisting> 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 &ldquo;RedBoot&rdquo;. </para>
</listitem>
<listitem><para>Run the RedBoot <userinput>fis init</userinput> and <userinput>
fconfig</userinput> 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 <computeroutput>
srecconv.pl</computeroutput> utility which requires Perl. This utility is part
of the <computeroutput>yamon/yamon-src-02.00.tar.gz</computeroutput> tarball
on the Dev Kit CD. The path in the expanded tarball is <computeroutput>yamon/bin/tools
</computeroutput>.   To use <computeroutput>srecconv</computeroutput> to convert
the S-record file:     <programlisting>% cp redboot_ROM.srec redboot_ROM.rec
% srecconv.pl -ES L -A 29 redboot_ROM </programlisting>  The resulting file
is named redboot_ROM.fl.</para>
</sect3></sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:        <programlisting>-f 0xBE020000
-b 0x80020000
-r 0x80020000
-l 0x20000</programlisting></para>
</sect3>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be: <programlisting>-f 0xBE000000
-b 0x80080000
-l 0x20000</programlisting></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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0xbe000000 -
0xbe01ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x00020000 - 0x0004ffff. RAM physical addresses from
0x00050000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;malta_mips32_4kc&rdquo;, &ldquo;mips&rdquo; and &ldquo;malta&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/mips/malta/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2></sect1>
<?Pub _newpage>
<sect1 id="ocelot">
<title>PMC-Sierra MIPS RM7000 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.
Two basic RedBoot configurations are supported:<itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist></para>
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>Device programmer is used to program socketed flash parts.</para>
</sect2>
<sect2>
<title>Flash Management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, loading the primary image into
RAM at 0x80100000. The actual numbers used with
the flags in the sample commands are then:
<programlisting>
-f 0xbfc00000
-b 0x80100000
-l 0x20000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:
<programlisting>
-f 0xbfc20000
-b 0x80020000
-r 0x80020000
-l 0x20000
</programlisting></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>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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x1fc00000 -
0x1fc1ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot
runtime uses. </para>
<para>RAM based RedBoot configurations are designed to run from RAM at physical
addresses 0x00020000 - 0x0003ffff. RAM physical addresses from 0x00040000
to the end of RAM are available for general use, such as a temporary scratchpad
for downloaded images, before they are written to flash.</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;ocelot&rdquo;, &ldquo;mips&rdquo; and &ldquo;rm7000/ocelot&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/mips/rm7000/ocelot/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2></sect1>
<?Pub _newpage>
<sect1 id="mbx">
<title>Motorola PowerPC 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. Two basic RedBoot configurations
are supported: <itemizedlist>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>RedBoot running from the board's flash boot sector.  </para>
</listitem>
</itemizedlist></para>
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>Device programmer is used to program the XU1 socketed flash part  (AM29F040B)
with the ROM version 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: <programlisting>EPPC-Bug>lo 0
</programlisting>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 redboot.ppcbug file.</para>
<para>Note that on Linux, Minicom's ASCII download feature seems to be broken.
A workaround is to load the file into emacs (or another editor) and copy the
full contents to the clipboard. Then press the mouse paste-button (usually
the middle one) over the Minicom window.  </para>
</listitem>
<listitem><para>Program the flash with the downloaded data: <programlisting>
EPPC-Bug>pflash 40000 60000 fc000000</programlisting></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>
<para>To install RedBoot on a target that already has eCos GDB stubs, download
the RAM version of RedBoot and run it. Initialize the flash image directory: <programlisting>
RedBoot> fi init</programlisting>Then download the ROM version of RedBoot
and program it into flash: 
<programlisting>
RedBoot> <userinput>load redboot_ROM.srec -b 0x80100000</userinput>
RedBoot> <userinput>fi cr RedBoot -f 0xFE000000 -b 0x00040000 -l 0x20000</userinput>
</programlisting></para>
</sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0xfe000000
-b 0x50000
-l 0x20000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:
<programlisting>
-f 0xfe020000
-b 0x20000
-r 0x20000
-l 0x20000
</programlisting></para>
</sect3></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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0xfe000000 -
 0xfe01ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x00020000 - 0x0004ffff. RAM physical addresses from
0x00050000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;mbx&rdquo;, &ldquo;powerpc&rdquo; and &ldquo;mbx&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/powerpc/mbx/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="viper">
<title>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. </para>
<para>Management of onboard flash is also supported. 
A single RedBoot configuration is supported: <itemizedlist>
<listitem><para>RedBoot running from RAM using an image copied from the flash boot sector (ROMRAM mode).
</para>
</listitem>
</itemizedlist></para>
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>RedBoot must be installed at the A & M factory.
</para>
</sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:
<programlisting>
-f 0xfe000000
-b 0x50000
-l 0x30000
</programlisting></para>
</sect3>
</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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0xfe000000 -
 0xfe02ffff. RedBoot also reserves RAM (0x00000000 - 0x0003ffff) for RedBoot
runtime uses. RAM physical addresses from
0x00040000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;viper&rdquo;, &ldquo;powerpc&rdquo; and &ldquo;viper&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/powerpc/viper/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="e7t">
<title>ARM Evaluator7T (e7t) board with ARM7TDMI</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>
</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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x0182000 - 0x0182ffff.
</para>
<para>RedBoot also reserves RAM (0x00000000 - 0x0000ffff) for RedBoot runtime
uses. </para>
<para>RAM physical addresses from 0x00010000 to the end of RAM are available
for general use.</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;e7t&rdquo;, &ldquo;arm&rdquo; and &ldquo;e7t&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/e7t/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="integrator">
<title>ARM Integrator board with ARM7TDMI or ARM966E</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>
</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>Resource Usage </title>
<para>
The flash based RedBoot image occupies flash addresses
0x24000000 - 0x2401ffff.
</para>
<para>
RedBoot also reserves RAM (0x00000000 - 0x0003ffff) for RedBoot runtime
uses. If ethernet support is included, then the address range
0x00f00000 to 0x00ffffff are reserved for use by the driver. This may
be moved using the MLT.
</para>
<para>RAM physical addresses from 0x00040000 to 0x00efffff and from
0x00100000 to the end of SDRAM are available for general use.</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should
be followed.  The values for TARGET, ARCH_DIR and PLATFORM_DIR on this
platform are &ldquo;integrator&rdquo; or
&ldquo;integrator_arm9&rdquo;, &ldquo;arm&rdquo; and
&ldquo;integrator&rdquo; respectively.  Note that the configuration
export files supplied in the <computeroutput>
hal/arm/integrator/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="pid">
<title>ARM ARM7 PID, Dev7 and 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. Two basic RedBoot configurations
are supported:  <itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist></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 version of RedBoot and run it. Initialize the
flash image directory: <command>fi init</command> Then
download the ROM version of RedBoot and program it into flash: <programlisting>
RedBoot> <userinput>load -b 0x00040000 -m ymodem</userinput>
RedBoot> <userinput>fi cr RedBoot -f 0x04000000 -b 0x00040000 -l 0x20000</userinput>
</programlisting></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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x04000000 -
 0x0401ffff. </para>
<para>RedBoot also reserves RAM (0x00000000 - 0x00007fff) for RedBoot runtime
uses. </para>
<para>RAM based RedBoot configurations are designed to run from RAM at physical
addresses 0x00008000 - 0x0003ffff. RAM physical addresses from 0x00040000
to the end of RAM are available for general use, such as a temporary scratchpad
for downloaded images, before they are written to flash.</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;pid&rdquo;, &ldquo;arm&rdquo; and &ldquo;pid&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/pid/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2></sect1>

<?Pub _newpage>
<sect1 id="ipaq">
<title>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>
</sect2>
<sect2>
<title>Initial Installation</title>
<para>Prebuilt images for the OSloader, redboot_ROM.bin
and redboot_WinCE.bin images mentioned in the instructions below are provided.
</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.
         <programlisting>RedBoot(tm) bootstrap and debug environment [ROM]
Red Hat certified release, version R1.xx - 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.</programlisting>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:         <programlisting>... 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</programlisting></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:
 <programlisting>
RedBoot> <userinput>lo -r -b 0x100000 /tftpboot/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>
</programlisting>   <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>Flash Management</title>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, relying on default location
and size of the image. It is also possible to explicitly specify the options
- the appropriate options for the iPAQ are:   <programlisting>-f 0x50080000
-b 0x00020000
-r 0x00020000
-e 0x00020040
-l 0x40000</programlisting>When updating the image, the flash should be unlocked
before programming, and relocked afterwards. This is done with the commands:
    <programlisting>fis unlock -f 0x50080000 -l 0x40000</programlisting>and<programlisting>
fis lock -f 0x50080000 -l 0x40000</programlisting></para>
</sect3>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, relying on default location and
size of the image. It is also possible to explicitly specify the options -
the appropriate options for the iPAQ are:    <programlisting>-f 0x50040000
-b 0x00100000
-l 0x40000</programlisting> When updating the image, the flash should be unlocked
before programming, and relocked afterwards. This is done with the commands:
    <programlisting>fis unlock -f 0x50040000 -l 0x40000</programlisting>and<programlisting>
fis lock -f 0x50040000 -l 0x40000</programlisting></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>Resource Usage</title>
<para>The flash based RedBoot image occupies flash addresses 0x50040000 -
0x5007ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at virtual addresses 0x00020000 - 0x0005ffff. RAM virtual addresses from
0x00060000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash. An exception
is RAM from 0x01F70000 - 0x01FFFFFF which is reserved for use by the LCD
display.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;ipaq&rdquo;, &ldquo;arm&rdquo; and &ldquo;sa11x0/ipaq&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/sa11x0/ipaq/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2></sect1>

<?Pub _newpage>
<sect1 id="cerfcube">
<title>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>
</sect2>
<sect2>
<title>Initial Installation</title>
<para>Prebuilt images for redboot_ROM.bin
mentioned in the instructions below are provided.
</para>
<sect3>
<title>Installing RedBoot on the CerfCube using the Intrinsyc loader</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 redboot_ROM.bin image to an available TFTP server.
Issue these commands to the Instrinsyc loader.    
<programlisting>
    download tftp:xxx.x.x.xx redboot_ROM.bin 0xc0000000
    flashloader 0x00000000 0xc0000000 0x20000
</programlisting>
where xxx.x.x.xx 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>
</sect3>
<sect3 id="setting-up-and-testing-cerfcube-redboot">
<title>Setting up and testing RedBoot</title>
<para>Once RedBoot has started, you should get information similar to this
on the serial port at 38400,8,N,1.
<programlisting>RedBoot(tm) bootstrap and debug environment [ROM]
Red Hat certified release, version R1.xx - built 06:17:41, Mar 19 2001
Platform: Intrinsyc CerfCube (StrongARM 1110)

Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

RAM: 0x00000000-0x02000000, 0x00012708-0x01fd1000 available
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.
</programlisting>
</para>
</sect3>
</sect2>
<sect2>
<title>Flash Management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, relying on default location and
size of the image. It is also possible to explicitly specify the options -
the appropriate options for the CerfCube are:    <programlisting>-f 0x50000000
-b 0x00100000
-l 0x40000</programlisting> When updating the image, the flash should be unlocked
before programming, and relocked afterwards. This is done with the commands:
    <programlisting>fis unlock -f 0x50000000 -l 0x20000</programlisting>and<programlisting>
fis lock -f 0x50000000 -l 0x20000</programlisting></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 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>Resource Usage</title>
<para>The flash based RedBoot image occupies flash addresses 0x50000000 -
0x5001ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at virtual addresses 0x00020000 - 0x0005ffff. RAM virtual addresses from
0x00060000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.
</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;cerf&rdquo;, &ldquo;arm&rdquo; and &ldquo;sa11x0/ipaq&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/sa11x0/cerf/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2></sect1>

<?Pub _newpage>
<sect1 id="edb7xxx">
<title>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. Two
basic RedBoot configurations are supported: <itemizedlist>
<listitem><para>RedBoot running from the board's flash boot sector.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>EDB7312 only: RedBoot running from RAM copied directly from the 
flash boot sector.
</para>
</listitem>
</itemizedlist></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>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:         
<programlisting>
-f 0xE0000000
-b 0x40000
-l 0x40000
</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:         <programlisting>
-f 0xE0040000
-b 0x40000
-r 0x40000
-l 0x40000
</programlisting></para>
<note><title>NOTE</title>
<para>
On the EDB7312, because the primary RedBoot image runs in RAM and not
FLASH, it can be updated directly without
use of the separate RAM based version.
</para></note>
</sect3>
</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>Resource Usage </title>
<para>
The RAM based RedBoot image occupies RAM addresses 
<computeroutput>0x40000 - 0x7ffff</computeroutput>.
The ROMRAM based RedBoot image (EDB7312 only) occupies RAM addresses 
<computeroutput>0x1000 - 0x3ffff</computeroutput>.
RAM addresses start at 
<computeroutput>0x80000</computeroutput> 
and continue up to the top of the installed
physical RAM size, less the memory reserved for MMU page tables
(0x9000 bytes) and the LCD display buffer, if enabled (0x20000 bytes). The
RAM is available for general use such as a temporary scratchpad
for downloaded images before they are written to flash. </para>
<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>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;arm&rdquo; and &ldquo;edb7xxx&rdquo; respectively.
The value for TARGET is either &ldquo;edb7211&rdquo; or &ldquo;edb7212&rdquo;
 or &ldquo;edb7312&rdquo;,
depending on the desired platform.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/edb7xxx/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used, and the correct
edb7XXX variant chosen.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="nano">
<title>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.
These configurations are supported:<itemizedlist>
<listitem><para>RedBoot running from the first free block at 0x40000</para>
</listitem>
<listitem><para>RedBoot running from RAM</para>
</listitem>
</itemizedlist></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 RAM and
POST startup types, rather than the more usual ROM, RAM and optionally, POST.
</para>
<para>Briefly, the POST-startup RedBoot image lives in flash following the
BSE firmware. The BSE firmware is configured, using its standard <computeroutput>
bootcmd</computeroutput> parameter, to jump into the RedBoot image at startup.
</para>
</sect2>
<sect2>
<title>Download Instructions</title>
<para>You can perform the initial load of the POST-startup 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 /tftpboot/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 export 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, and
is reported by RedBoot's <userinput>tftp load</userinput> command and listed
by the <userinput>fis list</userinput> 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 <computeroutput>include/pkgconf
</computeroutput> directory. Specifically:    <programlisting>665 Feb  9 17:57 include/pkgconf/mlt_arm_sa11x0_nano_post.h
839 Feb  9 17:57 include/pkgconf/mlt_arm_sa11x0_nano_post.ldi
585 Feb  9 17:57 include/pkgconf/mlt_arm_sa11x0_nano_post.mlt</programlisting>It
is these you should edit if you wish to move that execution address from 0x50040000
in the POST configuration.  Startup type 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 startup
RedBoot.      
<programlisting>
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>
</programlisting>    
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:     
<programlisting>
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></programlisting>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>The FLASH based
RedBoot POST-startup image occupies virtual addresses 0x50040000 - 0x5005ffff.
</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.     <programlisting>1 x 8Mb = 8Mb     2 x 8Mb = 16Mb
1 x 16Mb = 16Mb   2 x 16Mb = 32Mb</programlisting>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. 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
        <programlisting>CYGPKG_HAL_ARM                  hal/arm/arch/
CYGPKG_HAL_ARM_SA11X0           hal/arm/sa11x0/var
CYGPKG_HAL_ARM_SA11X0_NANO      hal/arm/sa11x0/nano</programlisting> 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>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;nano&rdquo;, &ldquo;arm&rdquo; and &ldquo;sa11x0/nano&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/sa11x0/nano/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="x86pc">
<title>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. RedBoot runs from a boot floppy disk installed
in the A: drive of the PC.</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 <userinput>mount</userinput> 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>Resource Usage </title>
<para>RedBoot is loaded into RAM at address 0x2000 and reserves all RAM below
0xa0000 for its own use. RAM applications should load from address 0x100000
upwards.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;pc&rdquo;, &ldquo;i386&rdquo; and &ldquo;pc&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/i386/pc/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used. In particular, the
<filename>redboot_FLOPPY.ecm</filename> file is used for building a version
of RedBoot suitable for booting off a floppy disk.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="CalmRISC16">
<title>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>Only a ROM startup RedBoot configuration is supported.</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:
<programlisting>    .../packages/hal/calmrisc16/ceb/current/support
</programlisting></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:
<programlisting>    % calmbreaker -p /dev/term/b --reset --srec-code -f redboot.elf
</programlisting>
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:
<programlisting>    % calmbreaker -p /dev/term/b --run</programlisting>
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:
<programlisting>    (gdb) set download-write-size 25</programlisting>
</para>
</sect2>
<sect2>
<title>Resource Usage </title>
<para>The RedBoot image occupies program addresses 0x000000 - 0x00ffff
and data addresses 0x000000 - 0x00ffff.
</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;calm16_ceb&rdquo;, &ldquo;calmrisc16&rdquo; and &ldquo;ceb&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/calmrisc16/ceb/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="CalmRISC32">
<title>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>Only a ROM startup RedBoot configuration is supported.</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:
<programlisting>    .../packages/hal/calmrisc32/ceb/current/support
</programlisting></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:
<programlisting>    % calmbreaker -p /dev/term/b --reset --srec-code -f redboot.elf
</programlisting>
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:
<programlisting>    % calmbreaker -p /dev/term/b --run</programlisting>
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:
<programlisting>    (gdb) set download-write-size 25</programlisting>
</para>
</sect2>
<sect2>
<title>Resource Usage </title>
<para>The RedBoot image occupies program addresses 0x00000000 - 0x0000ffff
and data addresses 0x00000000 - 0x0000ffff.
</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;calm32_ceb&rdquo;, &ldquo;calmrisc32&rdquo; and &ldquo;ceb&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/calmrisc32/ceb/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>

<?Pub _newpage>
<sect1 id="edk7708">
<title>Hitachi EDK7708 (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. Two basic RedBoot configurations
are supported: <itemizedlist>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>RedBoot running from the board's flash boot sector.  </para>
</listitem>
</itemizedlist></para>
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>Program the ROM RedBoot image into flash using an eprom programmer.</para>

</sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x80000000
-b 0x88040000
-l 0x20000</programlisting></para>
</sect3>
</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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x80000000 -
 0x8001ffff. RedBoot also reserves RAM (0x88000000 - 0x8800ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x88010000 - 0x8803ffff. RAM physical addresses from
0x88040000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;edk7708&rdquo;, &ldquo;sh&rdquo; and &ldquo;edk7708&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/sh/edk7708/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>

<?Pub _newpage>
<sect1 id="se77x9">
<title>Hitachi Solution Engine 77X9 (SE77X9)</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. </para>
<para>Management of onboard flash is also supported. Two basic RedBoot configurations
are supported: <itemizedlist>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>RedBoot running from the board's flash boot sector.  </para>
</listitem>
</itemizedlist></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:<programlisting>Ready &gt;fl</programlisting></para>
</listitem>
<listitem><para>The monitor should now ask for input:
<programlisting>Flash ROM data copy to RAM
Please Send A S-format Record</programlisting>At this point copy the
RedBoot ROM SREC file to the serial port:<programlisting>
$ cat redboot_ROM.eprom.srec &gt /dev/ttyS0</programlisting>Eventually you
should see something like<programlisting>Start Addrs = A1000000
End Addrs = A1xxxxxx
Transfer complete</programlisting> 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>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x80000000
-b 0x8c080000
-l 0x20000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:
<programlisting>
-f 0x80020000
-b 0x8c020000
-r 0x8c020000
-l 0x20000
</programlisting></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 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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x80000000 -
 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from
0x8c080000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;se77x9&rdquo;, &ldquo;sh&rdquo; and &ldquo;se77x9&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/sh/se77x9/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>

<?Pub _newpage>
<sect1 id="se7709">
<title>Hitachi Solution Engine 7709 (SE77X9)</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. Two basic RedBoot configurations
are supported: <itemizedlist>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>RedBoot running from the board's flash boot sector.  </para>
</listitem>
</itemizedlist></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:<programlisting>Ready &gt;fl</programlisting></para>
</listitem>
<listitem><para>The monitor should now ask for input:
<programlisting>Flash ROM data copy to RAM
Please Send A S-format Record</programlisting>At this point copy the
RedBoot ROM SREC file to the serial port:<programlisting>
$ cat redboot_SE7709RP_ROM.eprom.srec &gt /dev/ttyS0</programlisting>Eventually you
should see something like<programlisting>Start Addrs = A1000000
End Addrs = A1xxxxxx
Transfer complete</programlisting> 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>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x80000000
-b 0x8c080000
-l 0x20000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:
<programlisting>
-f 0x80020000
-b 0x8c020000
-r 0x8c020000
-l 0x20000
</programlisting></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 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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x80000000 -
 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from
0x8c080000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;se77x9&rdquo;, &ldquo;sh&rdquo; and &ldquo;se77x9&rdquo; respectively.
Note that the configuration export files (containing SE7709RP
substring) supplied in the <computeroutput>
hal/sh/se77x9/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>

<?Pub _newpage>
<sect1 id="se7751">
<title>Hitachi Solution Engine 7751 (SE7751)</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. </para>
<para>Management of onboard flash is also supported. Two basic RedBoot configurations
are supported: <itemizedlist>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>RedBoot running from the board's flash boot sector.  </para>
</listitem>
</itemizedlist></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:<programlisting>Ready &gt;fl</programlisting></para>
</listitem>
<listitem><para>The monitor should now ask for input:
<programlisting>Flash ROM data copy to RAM
Please Send A S-format Record</programlisting>At this point copy the
RedBoot ROM SREC file to the serial port:<programlisting>
$ cat redboot_ROM.eprom.srec &gt /dev/ttyS0</programlisting>Eventually you
should see something like<programlisting>Start Addrs = A1000000
End Addrs = A1xxxxxx
Transfer complete</programlisting> 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>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x80000000
-b 0x8c080000
-l 0x20000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:
<programlisting>
-f 0x80020000
-b 0x8c020000
-r 0x8c020000
-l 0x20000
</programlisting></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 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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x80000000 -
 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from
0x8c080000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;se7751&rdquo;, &ldquo;sh&rdquo; and &ldquo;se7751&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/sh/se7751/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>

<?Pub _newpage>
<sect1 id="hs7729pci">
<title>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.</para>
<para>Management of onboard flash is also supported. Two basic RedBoot configurations
are supported: <itemizedlist>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
<listitem><para>RedBoot running from the board's flash boot sector.  </para>
</listitem>
</itemizedlist></para>
</sect2>
<sect2>
<title>Initial Installation Method </title>
<para>A copy of the ROM startup version of RedBoot must be programmed
into the two EPROMs. Two files with a split version of the ROM image is
provided: it is also possible to recreate these from the redboot.bin
file, but requires the split_word.c program in
hal/sh/hs7729pci/<replaceable>VERSION</replaceable>/misc to be built
and executed with the redboot.bin filename as sole argument.</para>

<para>After doing this it is advised that another ROM version of
RedBoot is programmed into the 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 use
<programlisting>-f 0x80400000</programlisting> 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 <programlisting>fis init</programlisting> to initialize
the flash table with the correct addresses.</para>
</listitem>
</orderedlist>


</sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot images, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        <programlisting>-f 0x80000000
-b 0x8c080000
-l 0x20000</programlisting></para>
</sect3>
<sect3>
<title>Updating the secondary RedBoot image</title>
<para>To update the secondary RedBoot images, follow the procedures detailed
in <xref linkend="different-version-from-RAM">, but the actual numbers used
with the flags in the sample commands should be:
<programlisting>
-f 0x80020000
-b 0x8c020000
-r 0x8c020000
-l 0x20000
</programlisting></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 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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x80000000 -
 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot
runtime uses. RAM based RedBoot configurations are designed to run from RAM
at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from
0x8c080000 to the end of RAM are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.</para>
</sect2>
<sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;hs7729pci&rdquo;, &ldquo;sh&rdquo; and &ldquo;hs7729pci&rdquo; respectively.
Note that the configuration export files supplied in the <computeroutput>
hal/sh/hs7729pci/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>


<?Pub _newpage>
<sect1 id="at91">
<title>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 'fconfig' is
supported, along with the simple flash write command, 'fis write'.
Two
basic RedBoot configurations are supported: <itemizedlist>
<listitem><para>RedBoot running from RAM, but contained in the board's flash boot sector
(ROMRAM mode).</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist>
The RAM version is only used during the initialization of RedBoot the first time.
</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 based version of RedBoot
to the board.  Once this 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 version and program it to flash.  Be sure and
first set SW1 to "upper mem".
<programlisting>
arm-elf-gdb redboot_RAM.elf
(gdb) tar rdi s=/dev/ttyS0
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) set $ps=0xd3
(gdb) lo
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.
(gdb) c
Continuing.
</programlisting>
At this point, interrupt the Angel session and start minicom.
<programlisting>
RedBoot> <userinput>ve</userinput>

RedBoot(tm) bootstrap and debug environment [RAM]
Red Hat certified release, version R1.xx - 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 0x02040000</userinput>
</programlisting>
Use minicom to send the file redboot_ROMRAM.srec via YModem.
<programlisting>
RedBoot> <userinput>fi wr -f 0x01010000 -b 0x02040000 -l 0xe000</userinput>
</programlisting>
Set switch SW1 to "upper mem", press the "reset" pushbutton and RedBoot
should come up on the board.
</para>
</sect2>
<sect2>
<title>Flash management</title>
<sect3>
<title>Updating the RedBoot image in flash</title>
<para>
Since the primary RedBoot runs from RAM, it can be used to update itself directly.
Simply follow the steps above, starting with a connection to RedBoot running on
the board.
</para>
</sect3>
</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>Resource Usage </title>
<para>The RAM based RedBoot image occupies RAM addresses 0x02020000 - 0x0203ffff.
RAM addresses from 0x02040000 to the end of RAM are available for general use
such as a temporary scratchpad for downloaded images before they are written
to flash. </para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for PLATFORM_DIR on this platform is
&ldquo;at91&rdquo;.
The value for TARGET is &ldquo;eb40&rdquo;.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/at91/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.
The ROMRAM configuration should be used to build the RedBoot image to be
programmed into flash.  The RAM configuration is used for the initial download
of RedBoot.
</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="asb2305">
<title>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. These configurations are supported:
<itemizedlist>
<listitem><para>RedBoot running from the boot PROM and able to access the system flash (the
redboot_ROM.bin image should be used for this).</para>
</listitem>
<listitem><para>RedBoot running from the system flash and able to access the boot PROM (the
redboot_FLASH.bin image should be used for this).</para>
</listitem>
<listitem><para>RedBoot running from RAM and able to access the boot PROM (the
redboot_RAM.bin image should be used for this).</para>
</listitem>
</itemizedlist>
</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 based
RedBoot must be loaded directly into RAM by JTAG and started, and then <emphasis>that</emphasis>
must be used to store the ROM based 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>
<programlisting>
ed 0xc0002000, 0x12000580

ed 0xd8c00100, 0x8000fe01
ed 0xd8c00200, 0x21111000
ed 0xd8c00204, 0x00100200
ed 0xd8c00208, 0x00000004

ed 0xd8c00110, 0x8400fe01
ed 0xd8c00210, 0x21111000
ed 0xd8c00214, 0x00100200
ed 0xd8c00218, 0x00000004

ed 0xd8c00120, 0x8600ff81
ed 0xd8c00220, 0x21111000
ed 0xd8c00224, 0x00100200
ed 0xd8c00228, 0x00000004

ed 0xd8c00130, 0x8680ff81
ed 0xd8c00230, 0x21111000
ed 0xd8c00234, 0x00100200
ed 0xd8c00238, 0x00000004

ed 0xd8c00140, 0x9800f801
ed 0xd8c00240, 0x00140000
ed 0xd8c00244, 0x11011100
ed 0xd8c00248, 0x01000001

ed 0xda000000, 0x55561645
ed 0xda000004, 0x000003c0
ed 0xda000008, 0x9000fe01
ed 0xda00000c, 0x9200fe01
ed 0xda000000, 0xa89b0654
</programlisting>
</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>
<programlisting>
ex 0x80000000,0x81ffffff,/mexram
ex 0x84000000,0x85ffffff,/mexram
ex 0x86000000,0x867fffff,/mexram
ex 0x86800000,0x87ffffff,/mexram
ex 0x8c000000,0x8cffffff,/mexram
ex 0x90000000,0x93ffffff,/mexram
</programlisting>
</listitem>
<listitem><para>Instruct the debugger to load the RAM RedBoot image into RAM:</para>
<programlisting>
_pc=90000000
u_pc
rd redboot.ram,90000000
</programlisting>
</listitem>
<listitem><para>Load the boot PROM RedBoot into RAM:</para>
<programlisting>
rd redboot.prom,91020000
</programlisting>
</listitem>
<listitem><para>Start RedBoot in RAM:</para>
<programlisting>
g
</programlisting>
<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 RedBoot</title>
<para>Once the RAM 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>
<programlisting>
fi init
</programlisting>
</listitem>
<listitem><para>Write the previously loaded redboot.prom image into the boot PROM:</para>
<programlisting>
fi write -f 0x80000000 -b 0x91020000 -l 0x00020000
</programlisting>
</listitem>
<listitem><para>Check that RedBoot has written the image:</para>
<programlisting>
dump -b 0x91020000
dump -b 0x80000000
</programlisting>
<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>
<programlisting>
fi init
</programlisting>
<para>Then program the system flash based RedBoot into the system flash:</para>
<programlisting>
load -r -b 0x91020000 /tftpboot/redboot_FLASH.bin
fi write -f 0x84000000 -b 0x91020000 -l 0x00020000
</programlisting>
<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>
<programlisting>
load -r -b 0x91020000 /tftpboot/redboot_ROM.bin
fi write -f 0x80000000 -b 0x91020000 -l 0x00020000
</programlisting>
<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>Resource Usage </title>
<para>The flash based RedBoot image occupies flash addresses 0x80000000 - 0x8001ffff. RedBoot also
reserves RAM (0x90000000 - 0x9001ffff) for RedBoot runtime uses. RAM based RedBoot configurations
are designed to run from RAM at physical addresses 0x90000000 - 0x9001ffff. RAM physical addresses
from 0x90050000 to the end of RAM are available for general use, such as a temporary scratchpad for
downloaded images, before they are written to flash.</para>
<note>
<title>NOTE</title>
<para>The location at which RedBoot can be started is highly restricted due to the way in which the
address of the Trap Vector Table is specified to the CPU.</para>
</note>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-RedBoot"> should be followed.  The values for
TARGET, ARCH_DIR and PLATFORM_DIR on this platform are &ldquo;asb2305&rdquo;, &ldquo;mn10300&rdquo;
and &ldquo;asb2305&rdquo; respectively.  Note that the configuration export files supplied in the
<computeroutput> hal/mn10300/asb2305/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="aaed2000">
<title>Agilent AAED2000 ARM9 (aaed) </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. 
Two basic RedBoot configurations are supported: <itemizedlist>
<listitem><para>RedBoot being automatically executed by the on-board
ARM Boot Monitor, running from RAM.</para>
</listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.
</para>
</listitem>
</itemizedlist></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:
<programlisting>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 >                                                                  
</programlisting>

Download the RAM startup version of RedBoot configured as a primary
bootmonitor using the ARM bootmonitor's SREC-download command:

<programlisting>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.                                                     
</programlisting>

Use the terminal emulator's ASCII upload command, or (on Linux) simply
cat the file to the serial port:

<programlisting>$ <userinput>cat redboot_primary_RAM/redboot.srec &gt;/dev/ttyS1</userinput>
</programlisting>

You should see RedBoot start up:

<programlisting>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></programlisting>

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 image.

Now initialize RedBoot's FIS:

<programlisting>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 0x61fe0000-0x62000000: .                                         
... Program from 0x01f5f000-0x01f5f300 at 0x61fe0000: .                         
</programlisting>

Download the ROMRAM version of RedBoot via ethernet:

<programlisting>RedBoot&gt; <userinput>load -b 0x100000 redboot_primary_ROMRAM/redboot.srec</userinput>
</programlisting>

or using serial Y-modem protocol:

<programlisting>RedBoot&gt; <userinput>load -mode ymodem -b 0x100000</userinput>
</programlisting>

(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:

<programlisting>Address offset = 0x00ff8000                                                     
Entry point: 0x00008040, address range: 0x00008000-0x0002da80                   
RedBoot&gt; <userinput>fi cr RedBoot -b 0x100000</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: .                         
</programlisting>

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:
<programlisting>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 >                                                                  
</programlisting>

Download the RAM startup version of RedBoot configured as a secondary
bootmonitor using the ARM bootmonitor's SREC-download command:

<programlisting>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.                                                     
</programlisting>

Use the terminal emulator's ASCII upload command, or (on Linux) simply
cat the file to the serial port:

<programlisting>$ <userinput>cat redboot_secondary_RAM.srec &gt;/dev/ttyS1</userinput>
</programlisting>

You should see RedBoot start up:

<programlisting>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.            
</programlisting>

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 image.

Next step is to erase all of the flash, except where the ARM booter resides:

<programlisting>RedBoot&gt; <userinput>fi erase -f 0x60020000 -l 0x01fe0000</userinput>
... Erase from 0x60020000-0x62000000: ..........................................
................................................................................
................................................................................
.....................................................                           
</programlisting>

Then initialize RedBoot's FIS:

<programlisting>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: .                         
</programlisting>

Download the ROMRAM version of RedBoot via ethernet:

<programlisting>RedBoot&gt; <userinput>load -raw -b 0x100000 redboot_secondary_ROMRAM.arm.bin</userinput>
</programlisting>

or using serial Y-modem protocol:

<programlisting>RedBoot&gt; <userinput>load -raw -mode ymodem -b 0x100000</userinput>
</programlisting>

(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:

<programlisting>RedBoot&gt; <userinput>fi cr RedBoot -b 0x100000</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: .                         
</programlisting>

Now reset the board. You might see the ARM Monitor complain:

<programlisting>Failed to boot from flash.                                                      
The ARM Boot Monitor SIB can not be found.                                      
Press any key to continue.                                                      
</programlisting>

This is due to due to the flash having been erased. Press a key, and
execute the "validate flash contents" command:

<programlisting>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;
</programlisting>

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>Flash management</title>
<sect3>
<title>Updating the RedBoot image</title>
<para> Since the RedBoot image is a ROMRAM-startup
type, it is not necessary to load and run the RAM startup RedBoot
image to update the image in flash. Doing so causes no harm though -
but ignoring the step saves some time.
</para>

<para>To update the primary RedBoot image, follow the procedures
detailed in <xref linkend="update-primary-image">, but let RedBoot
find the correct flash address (the -f option) since this is different
between the bootmonitor configurations. If
specifying it, be sure to get it right - the actual numbers used with
the flags in the sample commands should for a RedBoot image configured
to be the primary bootmonitor be:
<programlisting>
-f 0x60000000
-b 0x100000
-l 0x40000
</programlisting>

<!--
And for a RedBoot image configured to be the secondary bootmonitor:

<programlisting>
-f 0x60020000
-b 0x100000
-l 0x40000
</programlisting>
-->

</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:

<programlisting>RedBoot&gt; load -r -b 0x100000 zImage
Raw file loaded 0x00100000-0x001a3d6c
RedBoot&gt; exec -c "console=ttyAC0,38400"
Using base address 0x00100000 and length 0x000a3d6c
Uncompressing Linux.....
</programlisting>

An image could also be put in flash and started directly:

<programlisting>RedBoot&gt; exec -b 0x60040000 -l 0xc0000 -c "console=ttyAC0,38400"
Uncompressing Linux.....
</programlisting>

</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>Resource Usage </title>
<para>The RAM based RedBoot image occupies RAM addresses 
<computeroutput>0x40000 - 0x7ffff</computeroutput>. 
The flash based RedBoot image occupies RAM addresses 
<computeroutput>0x00000000 - 0x0003ffff</computeroutput>.
RAM addresses from <computeroutput>0x80000</computeroutput> to the end of RAM are available for general use
such as a temporary scratchpad for downloaded images before they are written
to flash. 
If configured to use the LCD screen, additional DRAM from 
<computeroutput>0x01f80000 - 0x01ffffff</computeroutput>
is used for the LCD frame buffer.
</para>
</sect2><sect2>
<title>Rebuilding RedBoot</title>
<para>The instructions in <xref linkend="Rebuilding-Redboot"> should be followed.
The values for ARCH_DIR and PLATFORM_DIR on this platform are
&ldquo;arm&rdquo; and &ldquo;arm9/aaed2000&rdquo; respectively.
The value for TARGET is &ldquo;aaed&rdquo;.
Note that the configuration export files supplied in the <computeroutput>
hal/arm/arm9/aaed2000/<replaceable>VERSION</replaceable>/misc</computeroutput>
directory in the RedBoot source tree should be used.
</para>
</sect2>
</sect1>
<?Pub _newpage>
<sect1 id="vrc4375">
<title>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. Two
basic RedBoot configurations are supported:

<itemizedlist>
<listitem><para>RedBoot running from RAM which has been relocated from the board's
flash boot sector.</para></listitem>
<listitem><para>RedBoot running from RAM with RedBoot in the flash boot sector.</para></listitem>
</itemizedlist></para>

<para>Since the normal RedBoot configuration does not use the FLASH ROM
except during startup, it is unnecessary to load a RAM-based RedBoot
before reprogramming the FLASH.</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>

<para>
Since RedBoot for this board relocates itself from ROM to RAM at
startup, it is not necessary to run a secondary RAM based version of
RedBoot to update the main FLASH image. Instead this can be done from
the primary version of RedBoot.
</para>

<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot image, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        
<programlisting>
-b 0x80100000
</programlisting>
Flash locking and unlocking is not required.
Note that these values are inferred when updating the RedBoot image once
the <command>fis create</command> has been run.
</para>
</sect3>

</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>Resource Usage</title>

<para>
The RedBoot image occupies flash addresses 0x1fc00000 - 0x1fc1ffff. To
execute it copies itself out of there to RAM at 0x80000000. RedBoot
reserves 1MB of RAM from 0x80000000 to 0x800FFFFF for its own use.
The top 1MB of RAM from 0x81F00000 to 0x81FFFFFF is reserved for use
by the PCI Ethernet device. RAM based RedBoot configurations are
designed to run from RAM at virtual addresses 0x80100000 -
0x8011ffff. RAM virtual addresses from 0x80020000 to the start of the
PCI window are available for general use, such as a temporary
scratchpad for downloaded images, before they are written to flash.
</para>
</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
<computeroutput>devs/eth/intel/i21143</computeroutput>. Its package name is <computeroutput>CYGPKG_DEVS_ETH_INTEL_I21143</computeroutput>.
</para>

<para>
The platform-specific ether driver is <computeroutput>devs/eth/mips/vrc4375</computeroutput>. 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>
The instructions in <xref linkend="Rebuilding-Redboot"> should be followed. The values for
TARGET, ARCH_DIR and PLATFORM_DIR on this platform are &ldquo;vrc4375&rdquo;,
&ldquo;mips&rdquo; and &ldquo;vrc4375&rdquo; respectively. The configuration export files
supplied in the <computeroutput>hal/mips/vrc4375/<replaceable>VERSION</replaceable>/misc</computeroutput> directory in the RedBoot
source tree should be used. In general only the ROMRAM variant should
need to be used.
</para>
</sect2>

</sect1>
<?Pub _newpage>
<sect1 id="frv400">
<title>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.
Two basic RedBoot configurations are supported:

<itemizedlist>
  <listitem>
    <para>
     RedBoot running from RAM which has been relocated from the board's
     flash boot sector.  This mode is known as ROMRAM.
    </para>
  </listitem>
  <listitem>
    <para>
      RedBoot running from RAM, loaded by some other means.
    </para>
  </listitem>
</itemizedlist>

</para>

<para>Since the normal RedBoot configuration does not use the FLASH ROM
except during startup, it is unnecessary to load a RAM-based RedBoot
before reprogramming the FLASH.</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>

<sect3>
<title>Updating the primary RedBoot image</title>
<para>To update the primary RedBoot image, follow the procedures detailed
in <xref linkend="update-primary-image">, but the actual numbers used with
the flags in the sample commands should be:        
<programlisting>
-f 0xFF000000
-b 0x100000
-l 0x40000
</programlisting>
Note that these values are inferred when updating the RedBoot image once
the <command>fis create</command> has been run.
</para>
</sect3>

</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>Resource Usage</title>

<para>
The RedBoot image occupies flash addresses 0xFF000000 - 0xFF03FFFF. To
execute it copies itself out of there to RAM at 0x03E00000. RedBoot
reserves memory from 0x00000000 to 0x0001FFFF for its own use.
User programs can use memory from 0x00020000 to 0x03DFFFFF.
RAM based RedBoot configurations are
designed to run from RAM at 0x00020000.
</para>
</sect2>

<sect2>
<title>Rebuilding RedBoot</title>

<para>
The instructions in <xref linkend="Rebuilding-Redboot"> should be followed. The values for
TARGET, ARCH_DIR and PLATFORM_DIR on this platform are &ldquo;frv400&rdquo;,
&ldquo;frv&rdquo; and &ldquo;frv400&rdquo; respectively. The configuration export files
supplied in the <computeroutput>hal/frv/frv400/<replaceable>VERSION</replaceable>/misc</computeroutput> directory in the RedBoot
source tree should be used. In general only the ROMRAM variant should
need to be used.
</para>
</sect2>

</sect1>

</chapter>