m68k-m5272c3-setup.html

ecos3.0 beta 的官方文档,html格式

*** Initialize FLASH Image System
... Erase from 0xfff40000-0xfffc0000: ..
... Erase from 0x00000000-0x00000000:
... Erase from 0xfffc0000-0xffffffff: .
... Program from 0x003bf000-0x003ff000 at 0xfffc0000: .
RedBoot>
    </PRE
></TD
></TR
></TABLE
><P
>The flash chip on the M5272C3 board is slow at erasing flash blocks so
this operation can take some time. At the end the block of flash at
location 0xFFFC0000 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:
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>RedBoot&gt; fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Use BOOTP for network configuration: true
DNS server IP address:
GDB connection port: 9000
Force console for special debug messages: false
Network hardware address [MAC]: 0x00:0x00:0x00:0x00:0x00:0x03
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xfffc0000-0xffffffff: .
... Program from 0x003bf000-0x003ff000 at 0xfffc0000: .
RedBoot&gt;
    </PRE
></TD
></TR
></TABLE
><P
>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. The other exception is the network hardware address,
also known as MAC address. All boards should be given a unique MAC
address, not the one in the above example. If there are two boards on
the same network trying to use the same MAC address then the resulting
behaviour is undefined.
    </P
><P
>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.
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>RedBoot&gt; load -r -m ymodem -b %{freememlo}
    </PRE
></TD
></TR
></TABLE
><P
>The file <TT
CLASS="FILENAME"
>redboot_rom.bin</TT
> should now be uploaded
using the terminal emulator. The file is a raw binary and should be
transferred using the Y-modem protocol.
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>Raw file loaded 0x0003f800-0x000545a3, assumed entry at 0x0003f800
xyzModem - CRC mode, 2(SOH)/84(STX)/0(CAN) packets, 5 retries
RedBoot&gt;
    </PRE
></TD
></TR
></TABLE
><P
>Once RedBoot has been loaded into RAM it can be programmed into flash:
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>RedBoot&gt; fis create RedBoot -b %{freememlo}
An image named 'RedBoot' exists - continue (y/n)? y
... Erase from 0xfff00000-0xfff40000: .
... Program from 0x0003f800-0x0007f800 at 0xfff00000: .
... Erase from 0xfffc0000-0xffffffff: .
... Program from 0x003bf000-0x003ff000 at 0xfffc0000: .
RedBoot&gt;
    </PRE
></TD
></TR
></TABLE
><P
>The flash-resident version of RedBoot has now programmed at location
0xFFF00000, and the flash info block at 0xFFFC0000 has been updated.
The initial setup is now complete. Power off the board and set the
flash jumper to boot from location 0xFFF00000 instead of 0xFFE00000.
Also set the terminal emulator to run at 38400 baud (the usual baud
rate for RedBoot), and power up the board again.
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>+Ethernet eth0: MAC address 00:00:00:00:00:03
Can't get BOOTP info for device!

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version v2_0_1 - built 09:57:50, Jun 24 2003

Platform: M5272C3 (Freescale MCF5272)
Copyright (C) 2000, 2001, 2002, Free Software Foundation, Inc.

RAM: 0x00000000-0x00400000, 0x0000b400-0x003bd000 available
FLASH: 0xffe00000 - 0x00000000, 8 blocks of 0x00040000 bytes each.
RedBoot&gt;
    </PRE
></TD
></TR
></TABLE
><P
>When RedBoot issues its prompt it is also ready to accept connections
from m68k-elf-gdb, allowing eCos applications to be downloaded and
debugged.
    </P
><P
>Occasionally it may prove necessary to update the installed RedBoot
image. This can be done simply by repeating the above process, using
dBUG to load the dBUG version of RedBoot
<TT
CLASS="FILENAME"
>redboot_dbug.srec</TT
>. Alternatively the existing
RedBoot install can be used to load a RAM-resident version,
<TT
CLASS="FILENAME"
>redboot_ram.bin</TT
>.
    </P
><P
>The ROMFFE version of RedBoot can be installed at location 0xFFE00000,
replacing dBUG. This may be useful if the system needs more flash
blocks than are available with the usual ROM RedBoot. Installing this
RedBoot image will typically involve a BDM-based utility.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="M68K-M5272C3-SETUP-REBUILD"
></A
><H2
>Rebuilding RedBoot</H2
><P
>Should it prove necessary to rebuild a RedBoot binary, this is done
most conveniently at the command line. The steps needed to rebuild the
dBUG version of RedBoot are:
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ mkdir redboot_dbug
$ cd redboot_dbug
$ ecosconfig new m5272c3 redboot
$ ecosconfig import $ECOS_REPOSITORY/hal/m68k/mcf52xx/mcf5272/m5272c3/v2_0_1/misc/redboot_DBUG.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make
    </PRE
></TD
></TR
></TABLE
><P
>At the end of the build the <TT
CLASS="FILENAME"
>install/bin</TT
> subdirectory should contain
the required file <TT
CLASS="FILENAME"
>redboot_dbug.srec</TT
>.
    </P
><P
>Rebuilding the RAM and ROM versions involves basically the same
process. The RAM version uses the file
<TT
CLASS="FILENAME"
>redboot_RAM.ecm</TT
> and generates a file
<TT
CLASS="FILENAME"
>redboot_ram.bin</TT
>. The ROM version uses the file
<TT
CLASS="FILENAME"
>redboot_ROM.ecm</TT
> and generates a file
<TT
CLASS="FILENAME"
>redboot_rom.bin</TT
>. 
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="M68K-M5272C3-BDM"
></A
><H2
>BDM</H2
><P
>An alternative to debugging an application on top of Redboot is to use
a BDM hardware debug solution. On the eCos side this requires building
the configuration for RAM startup and
with <CODE
CLASS="VARNAME"
>CYGSEM_HAL_USE_ROM_MONITOR</CODE
> disabled. Note that
a RAM build of RedBoot automatically has the latter configuration
option disabled, so it is possible to run a RAM RedBoot via BDM and
bypass the dBUG stages of the installation process.
    </P
><P
>On the host-side the details depend on exactly which BDM solution is
in use. Typically it will be necessary to initialize the hardware
prior to downloading the eCos application, either via a configuration
file or by using gdb macros. The
file <TT
CLASS="FILENAME"
>misc/bdm.gdb</TT
> in the platform HAL defines
example gdb macros.
    </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="m68k-m5272c3.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="m68k-m5272c3-config.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Overview</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="hal-m68k-m5272c3-part.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Configuration</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>