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, Free Software Foundation, 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, Free Software Foundation, 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.