Name

Setup — Preparing the ST40EB board for eCos Development

Overview

In a typical development environment, the ST40EB board boots from flash into the RedBoot ROM monitor. eCos applications are configured for RAM startup and then downloaded and run on the board via the debugger sh-elf-gdb. Preparing the board therefore usually involves programming a suitable RedBoot image into flash memory.

The following RedBoot configurations are supported:

ConfigurationDescriptionUseFile
ROMRedBoot running from the board's flashredboot_ROM.ecmredboot_ROM.bin
RAMUsed for upgrading ROM versionredboot_RAM.ecmredboot_RAM.bin
RAM_NOETHUsed for programming RedBoot the first timeredboot_RAM_NOETH.ecmredboot_RAM_NOETH.bin

For serial communications, all versions run with 8 bits, no parity, and 1 stop bit at 115200 baud. This baud rate can be changed via the configuration option CYGNUM_HAL_SH_SH4_SCIF_BAUD_RATE and rebuilding RedBoot. RedBoot also supports ethernet communication and flash management.

Initial Installation

Flash Installation

This process assumes that the board is connected to an ST40-Connect/SH. The ST40-Connect should be set up as described in the ST Micro Connect Manual. You should also have access to the SuperH development tools since it is necessary to use the version of GDB that comes with those tools to access the ST40-Connect, sh-elf-gdb will not work.

Programming the RedBoot ROM monitor into flash memory requires an application that can manage flash blocks. RedBoot itself has this capability. Rather than have a separate application that is used only for flash management during the initial installation, a special RAM-resident version of RedBoot is loaded into memory and run. This version can then be used to load the normal flash-resident version of RedBoot and program it into the flash.

The first step is to connect an RS232 null modem cable between either of the ST40EB serial ports and the host PC. Next start a terminal emulation application such as HyperTerminal or minicom on the host PC and set the serial communication parameters to 115200 baud, 8 data bits, no parity, 1 stop bit (8N1) and no flow control (handshaking).

Now run the sh4gdb command, giving it the name of the RAM_NOETH redboot ELF file, connect to the ST40-Connect, load the executable and run it. The entire session should look like this:

$ sh4gdb -nw redboot_RAM_NOETH.elf
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sh-superh-elf"...
(gdb) mb360 172.31.1.90
The target is assumed to be little endian
The target architecture is assumed to be sh4
0xa0000000 in ?? ()
(gdb) load
Loading section .vectors, size 0x9d0 lma 0x88020000
Loading section .text, size 0x1d650 lma 0x880209d0
Loading section .rodata, size 0x4364 lma 0x8803e020
Loading section .data, size 0x12b8 lma 0x880423a0
Start address 0x88020000, load size 144956
Transfer rate: 1159648 bits/sec, 3814 bytes/write.
(gdb) cont
Continuing.

The required redboot_RAM_NOETH.elf file is normally supplied with the eCos release in the loaders directory. If it needs to be rebuilt then instructions for this are supplied below. The RAM_NOETH build is used this time instead of plain RAM as it does not contain any PCI or ethernet support. PCI support has been observed to cause complications with using the ST40-Connect.

If this sequence fails in any way then check the setup and connections of the ST40-Connect. It if is successful then you should see the following printed out on the serial line:

+FLASH configuration checksum error or invalid key

RedBoot(tm) bootstrap and debug environment [RAM]
Non-certified release, version UNKNOWN - built 09:27:11, Sep 20 2004

Platform: ST40 Eval Board (ST40)
Copyright (C) 2000, 2001, 2002, Free Software Foundation, Inc.
Copyright (C) 2003, 2004, eCosCentric Limited

RAM: 0x88000000-0x8a000000, [0x880491e0-0x89fd1000] available
FLASH: 0x80000000 - 0x80400000, 32 blocks of 0x00020000 bytes each.
RedBoot>

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 fis init -f command:

RedBoot> fis init -f
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
*** Initialize FLASH Image System
... Erase from 0x80040000-0x803e0000: .............................
... Erase from 0x80400000-0x80400000:
... Erase from 0x803e0000-0x80400000: .
... Program from 0x89fe0000-0x8a000000 at 0x803e0000: .
RedBoot>

At the end, the block of flash at location 0x89FE0000 holds information about the various flash blocks, allowing other flash management operations to be performed.

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.

RedBoot> load -r -m ymodem -b %{freememlo}

The file redboot_ROM.bin should now be uploaded using the terminal emulator on your host. The file is raw binary and should be transferred using the Y-modem protocol.

Raw file loaded 0x8804fc00-0x88075137, assumed entry at 0x8804fc00
xyzModem - CRC mode, 1197(SOH)/0(STX)/0(CAN) packets, 4 retries
RedBoot>

Once the ROM version of RedBoot has been loaded into RAM it can be programmed into flash:

RedBoot> fis create RedBoot -b %{freememlo}
An image named 'RedBoot' exists - continue (y/n)? y
... Erase from 0x80000000-0x80040000: ..
... Program from 0x8804fc00-0x8808fc00 at 0x80000000: ..
... Erase from 0x803e0000-0x80400000: .
... Program from 0x89fe0000-0x8a000000 at 0x803e0000: .
RedBoot>

The flash-resident version of RedBoot has now been programmed at location 0x80000000/0xA0000000, and the flash info block at 0x89FE0000/0xA9FE0000 has been updated (on the SuperH, addresses beginning 0xA are the non-cacheable shadow versions in the P2 region of addresses beginning 0x8 from the P1 region). The initial setup is now complete. Power off the ST40-CONNECT and reset the ST40EB board using the reset button SW2. You should see something similar to the following:

+FLASH configuration checksum error or invalid key
... waiting for BOOTP information
Ethernet eth0: MAC address 00:80:e1:12:00:3b
IP: 172.31.1.99/255.255.255.0, Gateway: 172.31.1.1
Default server: 172.31.1.2, DNS server IP: 172.31.1.1

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 01:21:36, Sep 20 2004

Platform: ST40 Eval Board (ST40)
Copyright (C) 2000, 2001, 2002, Free Software Foundation, Inc.
Copyright (C) 2003, 2004, eCosCentric Limited

RAM: 0x88000000-0x8a000000, [0x8800e380-0x89fd1000] available
FLASH: 0x80000000 - 0x80400000, 32 blocks of 0x00020000 bytes each.
RedBoot>

If the ethernet cable is not plugged in there may be a fairly long wait after the "... waiting for BOOTP information" message.

Flash Configuration

The next step is to set up RedBoot's non-volatile configuration values:

RedBoot> fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Use BOOTP for network configuration: true
Default server IP address:
Console baud rate: 115200
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)? y
... Erase from 0x803e0000-0x80400000: .
... Program from 0x89fe0000-0x8a000000 at 0x803e0000: .
RedBoot>

For most of these configuration variables, the default value is correct, although you may wish to provide a default server used for TFTP retrieval, and default DNS server. 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.

Once you have set appropriate RedBoot flash configuration values you may reset the board. When RedBoot issues its prompt, it is ready to accept connections from sh-elf-gdb, allowing applications to be downloaded and debugged. Connections can be made via either serial port, or by TCP to port 9000 (or an alternative port if manually set by the fconfig command).

Occasionally it may prove necessary to update the installed RedBoot image. This can be done simply by repeating the above process, using the ST40-Connect. Alternatively, the existing RedBoot install can be used to load the RAM-resident version in which case the standard RAM RedBoot build can be used instead of the RAM_NOETH build. 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.

Rebuilding RedBoot

Should it prove necessary to rebuild a RedBoot binary, this is done most conveniently at the command line. Assuming your PATH and ECOS_REPOSITORY environment variables have been set correctly, the steps needed to rebuild the RAM version of RedBoot are:

$ mkdir redboot_ram
$ cd redboot_ram
$ ecosconfig new st40raeb redboot
$ ecosconfig import $ECOS_REPOSITORY/hal/sh/st40eb/VERSION/misc/redboot_RAM.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make

At the end of the build the install/bin subdirectory should contain the file redboot.bin.

Rebuilding the ROM or RAM_NOETH versions involve basically the same process. The ROM version uses the file redboot_ROM.ecm and the RAM_NOETH version uses the file redboot_RAM_NOETH.ecm and both versions generate a file named redboot.bin. Make sure you don't mix up the different redboot.bin files; rename them to something more memorable such as redboot_RAM.bin and redboot_ROM.bin.