Subversion Repositories openrisc

    Overview

    eCos Support for the SuperH SH4-202 MicroDev Board

    Overview

The SuperH SH4-202 MicroDev board (henceforth just "MicroDev") has

an SH4-202 processor, 64MB of external SDRAM, 32MB of external flash

memory, an SMSC LAN91C111 ethernet controller and connectors plus

required support chips for all the on-chip peripherals.

For typical eCos development, a RedBoot image is programmed into the

flash memory, and the board will boot this image from reset. RedBoot

provides gdb stub functionality so it is then possible to download and

debug stand-alone and eCos applications via the gdb debugger. This can

happen over either a serial line or over ethernet.

The flash memory consists of 128 blocks of 256k bytes each.

In a typical setup, the first

flash block is used for the ROM RedBoot image

and the second is used to store a version of RedBoot that can run out of

RAM. The topmost two blocks are used to manage the flash and hold RedBoot fconfig

values. The remaining 124 blocks between 0xA0080000 and 0xA1F7FFFF can be

used by application code.

The board is fitted with a PLCC socket suitable for an EEPROM (or PROM) such as

the 1Mbit ST M29WO10B. This is enabled by toggling two DIP switches, after which

the EEPROM is mapped into the same address as the flash memory. Therefore,

the flash is not accessible if booting from the EEPROM.

There is a serial driver CYGPKG_DEVS_SERIAL_SH_SCIF

which supports the on-chip serial device. This device

can be used by RedBoot for communication with the host. If this device

is needed by the application, either directly or via the serial

driver, then it cannot also be used for RedBoot communication. Another

communication channel such as ethernet should be used instead. The

serial driver package is loaded automatically when configuring for the

MicroDev target.

There is an ethernet driver CYGPKG_DEVS_ETH_SH_MICRODEV

for the on-chip ethernet device. This driver is also loaded

automatically when configuring for the MicroDev target.

eCos manages the on-chip interrupt controller. Timer 0 is used to

implement the eCos system clock, and timer 1 is used to implement a

microsecond delay function. Timer 2 is unused and

left for the application. Other on-chip devices (FEMI, EMI, INTC, TMU,

CAC, UBC) are initialized only as far as is necessary for eCos to

run. Other devices (eg RTC, DMAC, etc) are not touched.

The MicroDev port is intended to work with GNU tools configured for an

sh-elf target. The original port was done using sh-elf-gcc version

3.2.1, sh-elf-gdb version 5.3, and binutils version 2.13.1.

    Setup

    Setup

    Preparing the MicroDev board for eCos Development

In a typical development environment, the MicroDev 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. Alternatively

RedBoot may be programmed into a PLCC EEPROM and inserted into socket U21,

although in that case, the flash memory is not accessible.

The following RedBoot configurations are supported:

            ROM

            RedBoot running from the board's flash

            redboot_ROM.ecm

            redboot_ROM.bin

            EEPROM

            RedBoot running from the board's socketed EEPROM

            redboot_EEPROM.ecm

            redboot_EEPROM.bin

            RAM

            Used for upgrading ROM version

            redboot_RAM.ecm

            redboot_RAM.bin

For serial communications, all versions run with 8 bits, no parity, and

1 stop bit at 38400 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.

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 

class="directory">loaders directory. If it needs to be

rebuilt then instructions for this are supplied 

linkend="sh4-microdev-setup-rebuild">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.

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 

linkend="sh4-microdev-setup-rebuild">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.

Should it prove necessary to rebuild a RedBoot binary, this is done

most conveniently at the command line. The steps needed to rebuild the

RAM version of RedBoot are:

$ mkdir redboot_ram

$ cd redboot_ram

$ ecosconfig new sh4_202_md redboot

$ ecosconfig import $ECOS_REPOSITORY/hal/sh/sh4_202_md/v2_0_2/misc/redboot_RAM.ecm

$ ecosconfig resolve

$ ecosconfig tree

$ make

At the end of the build the 

class="directory">install/bin subdirectory should contain

the file redboot.bin.

Rebuilding the ROM versions involves basically the same

process. The ROM version uses the file

redboot_ROM.ecm and generates a file

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.

    Configuration

    Configuration

    Platform-specific Configuration Options

The MicroDev platform HAL package is loaded automatically when eCos is

configured for an sh4_202_md target. It should

never be necessary to load this package explicitly. Unloading the

package should only happen as a side effect of switching target

hardware.

The MicroDev platform HAL package supports two separate startup types:

        RAM

This is the startup type which is normally used during application

development. The board has RedBoot programmed into flash at location

0xA0000000 and boots from that location.

sh-elf-gdb is then used to load a RAM

startup application into memory and debug it. It is assumed that the

hardware has already been initialized by RedBoot. By default the

application will use the eCos virtual vectors mechanism to obtain certain

services from RedBoot, including diagnostic output.

        ROM

This startup type can be used for finished applications which will

be programmed into flash at location 0xA0000000. The application will

be self-contained with no dependencies on services provided by other

software. eCos startup code will perform all necessary hardware

initialization.

If the application is intended to act as a ROM monitor, providing

services for other applications, then the configuration option

CYGSEM_HAL_ROM_MONITOR should be set. Typically

this option is set only when building RedBoot.

If the application is supposed to make use of services provided by a

ROM monitor, via the eCos virtual vector mechanism, then the

configuration option CYGSEM_HAL_USE_ROM_MONITOR

should be set. By default this option is enabled when building for a

RAM startup, disabled otherwise. It can be manually disabled for a RAM

startup, making the application self-contained, as a testing step

before switching to ROM startup.

If the application does not rely on a ROM monitor for diagnostic

services then the serial port will be claimed for HAL

diagnostics.

The MicroDev board contains 32Mb of Intel StrataFlash, specifically,

two E28F128 parts in parallel. The

CYGPKG_DEVS_FLASH_STRATA package contains all the

code necessary to support these parts and the

CYGPKG_DEVS_FLASH_SH_MICRODEV package contains

definitions that customize the driver to the MicroDev board.

Note that if booting from EEPROM instead of flash, the flash driver will

not be able to detect or use the flash parts.

The MicroDev board contains an SMSC LAN91C111 ethernet device.

The

CYGPKG_DEVS_ETH_SMSC_LAN91CXX package contains all the

code necessary to support this part and the

CYGPKG_DEVS_ETH_SH_MICRODEV package contains

definitions that customize the driver to the MicroDev board.

By default, the system clock interrupts once every 10ms, corresponding

to a 100Hz clock. This can be changed by the configuration option

CYGNUM_HAL_RTC_DENOMINATOR which corresponds to the

clock frequency. Other clock-related settings are recalculated

automatically if the denominator is changed.

The platform HAL defines the default compiler and linker flags for all

packages, although it is possible to override these on a per-package

basis. Most of the flags used are the same as for other architectures

supported by eCos. There are two flags specific to this port:

        -m4

The sh-elf-gcc compiler supports many

variants of the SH architecture, from the SH2 onwards.

A -m option should be used to select the specific

variant in use, and with current tools -m4 is the

correct option for the SH4-202.

    The HAL Port

    HAL Port

    Implementation Details

This documentation explains how the eCos HAL specification has been

mapped onto the MicroDev hardware, and should be read in conjunction

with that specification. The MicroDev platform HAL package complements

the SH architectural HAL and the SH4 variant HAL. It provides

functionality which is specific to the target board.

Following a hard or soft reset the HAL will initialize or

reinitialize most of the on-chip peripherals. There is an exception

for RAM startup applications which depend on a ROM monitor for certain

services.

For ROM startup, the HAL will perform additional initialization,

setting up the external DRAM and programming the various internal

registers. The values used for most of these registers are assigned

fixed values from a table in the header 

class="headerfile">cyg/hal/platform.inc.

The platform HAL package provides the memory layout information needed

to generate the linker script. The key memory locations are as follows:

        off-chip Flash

This is located at address 0x00000000 of the physical memory space and is

therefore accessible in the P1 region at location 0x80000000. An

uncached shadow of this memory is available in the P2 region at 0xA0000000.

The contents of the flash are organized as described earlier.

        off-chip EEPROM

If selected by the DIP switches, this occupies the same addresses as the

off-chip flash, and the flash is no longer visible.

        external SDRAM

This is located at address 0x08000000 of the physical memory space and is

therefore accessable in the P1 region at location 0x88000000. An

uncached shadow of this memory is available in the P2 region at 0xA8000000. The

first 256 bytes are used for hardware exception vectors. The next 256

bytes are normally used for the eCos virtual vectors, allowing

RAM-based applications to use services provided by the ROM

monitor. For ROM startup, all remaining SDRAM is available. For RAM

startup, available SDRAM starts at location 0x80100000, with the bottom

1MB reserved for use by RedBoot.

        on-chip peripherals

These are accessible  via the P4 region at location 0xE0000000 onwards.

        off-chip peripherals

The ethernet device is located at 0xA7500000. The FPGA interrupt

controller is located at 0x06110000. These are the only

off-chip peripherals accessed by eCos. All others are left

untouched.

The platform HAL provides configuration options for the eCos system

clock. This always uses the hardware timer 0, which should not be used

directly by application code. Timer 1 is used to implement a

microsecond resolution busy delay service. Timer 2 is not used by eCos

so application code is free to manipulate this as required. The

actual HAL macros for managing the clock are provided by the SH architecture

processor HAL.

There is a software model of the structure of the SH family clock

supply subsystem which performs the correct calculations to yield not

only the inputs for the CPU clock but also the peripheral clocks fed

to the serial device, memory controllers and other devices. The values

for the master crystal, the PLL multipliers and various dividers are

supplied by the platform HAL. Some care must be taken in defining

these since wrong values will cause the timers and the SCIF baud rate

to be miscalculated. If the OSCAR chip switches are changed from the

default then the value of CYGHWR_HAL_SH_OOC_XTAL

must be changed to match.

The MicroDev platform HAL does not affect the implementation of other

parts of the eCos HAL specification. The

SH4 variant HAL, and the SH architectural HAL documentation

should be consulted for further details.

It should be noted that the floating point support in the SH HAL has a

caveat that, if the FPSCR register is changed, it may get reverted at a

later stage by certain operations performed by the GCC compiler. This

behaviour is intentional as the alternative would be to update the GCC

compiler's internal state about the FPSCR at every context switch which

would be expensive for a feature that is unlikely to be used frequently.

If the FPSCR is to be changed by the application, the developer

should call the function __set_fpscr(int), passing it

the new FPSCR value.