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:
Configuration | Description | Use | File |
---|---|---|---|
ROM | RedBoot running from the board's flash | redboot_ROM.ecm | redboot_ROM.bin |
RAM | Used for upgrading ROM version | redboot_RAM.ecm | redboot_RAM.bin |
RAM_NOETH | Used for programming RedBoot the first time | redboot_RAM_NOETH.ecm | redboot_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
.
2024-03-18 | eCosPro Non-Commercial Public License |