sh4_202_md.sgml

来自「eCos操作系统源码」· SGML 代码 · 共 761 行 · 第 1/3 页

supplied with the eCos release in the <filename
class="directory">loaders</filename> directory. If it needs to be
rebuilt then instructions for this are supplied <link
linkend="sh4-microdev-setup-rebuild">below</link>.
    </para>
    <para>
If this sequence fails in any way then check the setup and connections
of the Micro Probe. It if is successful then you should see the
following printed out on the serial line:
    </para>
    <screen>
+FLASH configuration checksum error or invalid key
... waiting for BOOTP information
Ethernet eth0: MAC address 00:08:ee:00:0b:37                                   
Can't get BOOTP info for device!
                                                                                
RedBoot(tm) bootstrap and debug environment [RAM]                               
Non-certified release, version UNKNOWN - built 14:28:55, Sep  8 2003            
                                                                                
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.                                   
                                                                                
RAM: 0x88000000-0x8c000000, 0x8812cca0-0x8bfb1000 available                     
FLASH: 0xa0000000 - 0xa2000000, 128 blocks of 0x00040000 bytes each.
RedBoot&gt;
    </screen>
    <para>
If the ethernet cable is not plugged in there may be a fairly long
wait after the "... waiting for BOOTP information" message.
At this stage the RedBoot flash management initialization has not yet
happened so the warning about the configuration checksum error is
expected. To perform this initialization use the
<command>fis&nbsp;init&nbsp;-f</command> command:
    </para>
    <screen>
RedBoot&gt; <userinput>fis init -f</userinput>
About to initialize [format] FLASH image system - continue (y/n)? <userinput>y</userinput>
*** Initialize FLASH Image System                                               
... Unlock from 0xa1fc0000-0xa2000000: .                                        
... Erase from 0xa1fc0000-0xa2000000: .                                         
... Program from 0x8bfbf000-0x8bfff000 at 0xa1fc0000: .                         
... Lock from 0xa1fc0000-0xa2000000: .                                         
RedBoot&gt;
    </screen>
    <para>
At the end, the block of flash at
location 0xA1FC0000 holds information about the various flash blocks,
allowing other flash management operations to be performed. The next
step is to set up RedBoot's non-volatile configuration values:
    </para>
    <screen>
RedBoot&gt; <userinput>fconfig -i</userinput>
Initialize non-volatile configuration - continue (y/n)? <userinput>y</userinput>
Run script at boot: false                                                       
Use BOOTP for network configuration: true                                       
Console baud rate: 38400                                                        
DNS server IP address:                                                          
Set eth0 network hardware address [MAC]: false                                  
GDB connection port: 9000                                                       
Force console for special debug messages: false                                 
Network debug at boot time: false                                               
Update RedBoot non-volatile configuration - continue (y/n)? <userinput>y</userinput>
... Unlock from 0xa1f80000-0xa1f81000: .                                        
... Erase from 0xa1f80000-0xa1f81000: .                                         
... Program from 0x8bfb2000-0x8bfb3000 at 0xa1f80000: .                         
... Lock from 0xa1f80000-0xa1f81000: .
RedBoot&gt;
    </screen>
    <para>
For most of these configuration variables, the default value is
correct. If there is no suitable BOOTP service running on the local
network then BOOTP should be disabled and, instead, RedBoot will prompt
for a fixed IP address, netmask, and addresses for the local gateway
and DNS server.
    </para>
    <para>
It is now possible to load the flash-resident version of RedBoot.
Because of the way that flash chips work, it is better to first load it
into RAM and then program it into flash.
    </para>
    <screen>
RedBoot&gt; <userinput>load -r -m xmodem -b %{freememlo}</userinput>
    </screen>
    <para>
The file <filename>redboot_ROM.bin</filename> should now be uploaded
using the terminal emulator. The file is a raw binary and should be
transferred using the X-modem protocol.
    </para>
    <screen>
Raw file loaded 0x8812d000-0x8814e32f, assumed entry at 0x8812d000              
xyzModem - CRC mode, 1064(SOH)/0(STX)/0(CAN) packets, 2 retries
RedBoot&gt;
    </screen>
    <para>
Once RedBoot has been loaded into RAM it can be programmed into flash:
    </para>
    <screen>
RedBoot&gt; <userinput>fis create RedBoot -b %{freememlo}</userinput>
An image named 'RedBoot' exists - continue (y/n)? <userinput>y</userinput>
... Erase from 0xa0000000-0xa0040000: .                                         
... Program from 0x8812d000-0x8816d000 at 0xa0000000: .                         
... Unlock from 0xa1fc0000-0xa2000000: .                                        
... Erase from 0xa1fc0000-0xa2000000: .                                         
... Program from 0x8bfbf000-0x8bfff000 at 0xa1fc0000: .                         
... Lock from 0xa1fc0000-0xa2000000: .                                          
RedBoot&gt;
    </screen>
    <para>
The flash-resident version of RedBoot has now been programmed at location
0xA0000000, and the flash info block at 0xA1FC0000 has been updated.
The initial setup is now complete. Power off the Micro Probe and reset
the MicroDev board using S6. You should see the following:

    </para>
    <screen>
+... waiting for BOOTP information                                     
Ethernet eth0: MAC address 00:08:ee:00:0b:37                                    
Can't get BOOTP info for device!                                                
                                                                                
RedBoot(tm) bootstrap and debug environment [ROM]                               
Non-certified release, version UNKNOWN - built 14:22:57, Sep  8 2003            
                                                                                
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.                                   
                                                                                
RAM: 0x88000000-0x8c000000, 0x8800db98-0x8bfb1000 available                     
FLASH: 0xa0000000 - 0xa2000000, 128 blocks of 0x00040000 bytes each.
RedBoot&gt;
    </screen>
    <para>
When RedBoot issues its prompt, it is also ready to accept connections
from sh-elf-gdb, allowing applications to be downloaded and
debugged.
    </para>
    <para>
Occasionally it may prove necessary to update the installed RedBoot
image. This can be done simply by repeating the above process, using
the Micro Probe. Alternatively, the existing
RedBoot install can be used to load the RAM-resident version. You can
even install the RAM resident RedBoot in the "RedBoot[backup]" flash
region. See the RedBoot documentation for instruction on how to do this.
    </para>
    </refsect2>
    <refsect2 id="sh4-microdev-eeprom"><title>EEPROM Installation</title>
      <para>
The board has a 32-pin PLCC socket suitable for an EEPROM, silk screened U21.
To use RedBoot running from EEPROM, you must first program the file
<filename>redboot_EEPROM.bin</filename> (normally supplied with the eCos release
in the <filename class="directory">loaders</filename> directory) into the
EEPROM using an appropriate programmer. No byte swapping is required. If RedBoot
needs to be rebuilt, then instructions for this are supplied <link
linkend="sh4-microdev-setup-rebuild">below</link>, and the import file
<filename>redboot_EEPROM.ecm</filename> should be used.
      </para>
      <para>
To configure the board to boot from the EEPROM instead of flash, you must
power off the board and change the following DIP switch settings, which may
both be found on DIP switch 2 (silk screened S2): switch 2 (silk
screened FEMI SIZ1) should be set to ON, which will change the access
width for FEMI area 0 from 32-bit to 8-bit; switch 6 (silk screened
FPGA SW3) should be set to OFF to configure the FPGA to map memory
accesses for FEMI area 0 to point at the EEPROM instead of flash. In
this mode, it is no longer possible to access flash memory as the EEPROM
is mapped into the same area in the address space.
      </para>
      <para>
Note that it is usually preferable to boot from flash instead of EEPROM as
flash is accessed 32-bits at a time, whereas the EEPROM is accessed 8-bits
at a time, which therefore affects performance as this requires 4 times as
many read cycles.
      </para>
    </refsect2>
  </refsect1>

  <refsect1 id="sh4-microdev-setup-rebuild"><title>Rebuilding RedBoot</title>
    <para>
Should it prove necessary to rebuild a RedBoot binary, this is done
most conveniently at the command line. The steps needed to rebuild the
RAM version of RedBoot are:
    </para>
    <screen>
$ mkdir redboot_ram
$ cd redboot_ram
$ ecosconfig new sh4_202_md redboot
$ ecosconfig import $ECOS_REPOSITORY/hal/sh/sh4_202_md/v2_0_2/misc/redboot_RAM.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make
    </screen>
    <para>
At the end of the build the <filename
class="directory">install/bin</filename> subdirectory should contain
the file <filename>redboot.bin</filename>.
    </para>
    <para>
Rebuilding the ROM versions involves basically the same
process. The ROM version uses the file
<filename>redboot_ROM.ecm</filename> and generates a file
<filename>redboot.bin</filename>. Make sure you don't mix up the
different redboot.bin files; rename them to something more memorable
such as <filename>redboot_RAM.bin</filename> and
<filename>redboot_ROM.bin</filename>.
    </para>
  </refsect1>

</refentry>

<!-- }}} -->
<!-- {{{ Config                         -->

<refentry id="sh4-microdev-config">
  <refmeta>
    <refentrytitle>Configuration</refentrytitle>
  </refmeta>
  <refnamediv>
    <refname>Configuration</refname>
    <refpurpose>Platform-specific Configuration Options</refpurpose>
  </refnamediv>

  <refsect1 id="sh4-microdev-config-overview"><title>Overview</title>
    <para>
The MicroDev platform HAL package is loaded automatically when eCos is
configured for an <literal>sh4_202_md</literal> target. It should
never be necessary to load this package explicitly. Unloading the
package should only happen as a side effect of switching target
hardware.
    </para>
  </refsect1>

  <refsect1 id="sh4-microdev-config-startup"><title>Startup</title>
    <para>
The MicroDev platform HAL package supports two separate startup types:
    </para>
    <variablelist>
      <varlistentry>
        <term>RAM</term>
        <listitem><para>
This is the startup type which is normally used during application
development. The board has RedBoot programmed into flash at location
0xA0000000 and boots from that location.
<application>sh-elf-gdb</application> is then used to load a RAM
startup application into memory and debug it. It is assumed that the
hardware has already been initialized by RedBoot. By default the
application will use the eCos virtual vectors mechanism to obtain certain
services from RedBoot, including diagnostic output.
        </para></listitem>
      </varlistentry>
      <varlistentry>
        <term>ROM</term>
        <listitem><para>
This startup type can be used for finished applications which will
be programmed into flash at location 0xA0000000. The application will
be self-contained with no dependencies on services provided by other
software. eCos startup code will perform all necessary hardware
initialization.
        </para></listitem>