Flash Installation
This process assumes that the board is connected to a SuperH Micro
Probe. The Micro Probe should be set up as described in Appendix A of
the "SH4 Development Tools User Guide". 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 Micro Probe,
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 the MicroDev
serial port 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 38400 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 redboot ELF file, connect to the Micro Probe, load the
executable and run it. The entire session should look like this:
$ sh4gdb redboot_RAM.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) sh4si superh
The target is assumed to be little endian
The target architecture is assumed to be sh4
0xa0000000 in ?? ()
(gdb) load
Loading section .vectors, size 0x9e0 lma 0x88010000
Loading section .text, size 0x1ab20 lma 0x880109e0
Loading section .rodata, size 0x3e6c lma 0x8802b500
Loading section .data, size 0xf30 lma 0x8802f370
Start address 0x88010000, load size 131740
Transfer rate: 351306 bits/sec, 433 bytes/write.
(gdb) cont
Continuing.
|
The required redboot_RAM.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.
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:
+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>
|
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
fis init -f command:
RedBoot> fis init -f
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Unlock from 0xa1fc0000-0xa2000000: .
... Erase from 0xa1fc0000-0xa2000000: .
... Program from 0x8bfbf000-0x8bfff000 at 0xa1fc0000: .
... Lock from 0xa1fc0000-0xa2000000: .
RedBoot>
|
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:
RedBoot> fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
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)? y
... Unlock from 0xa1f80000-0xa1f81000: .
... Erase from 0xa1f80000-0xa1f81000: .
... Program from 0x8bfb2000-0x8bfb3000 at 0xa1f80000: .
... Lock from 0xa1f80000-0xa1f81000: .
RedBoot>
|
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.
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 xmodem -b %{freememlo}
|
The file redboot_ROM.bin should now be uploaded
using the terminal emulator. The file is a raw binary and should be
transferred using the X-modem protocol.
Raw file loaded 0x8812d000-0x8814e32f, assumed entry at 0x8812d000
xyzModem - CRC mode, 1064(SOH)/0(STX)/0(CAN) packets, 2 retries
RedBoot>
|
Once 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 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>
|
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:
+... 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>
|
When RedBoot issues its prompt, it is also ready to accept connections
from sh-elf-gdb, allowing applications to be downloaded and
debugged.
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.
EEPROM Installation
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
redboot_EEPROM.bin (normally supplied with the eCos release
in the loaders 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 below, and the import file
redboot_EEPROM.ecm should be used.
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.
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.