Overview

Supported Hardware

The memory map used by both eCos and RedBoot is as follows:

Memory	Base	Length
External SDRAM	0x80000000	0x01000000
External Flash	0x98000000	0x00400000
Internal RAM	0xA4000000	0x00001000
On-chip Peripherals	0xB7000000	0x00200000
SMSC LAN9118	0xBA000000	0x02000000

External SDRAM and flash are normally accessed via the kseg0 segment and hence via the cache. The internal RAM and the peripherals are normally accessed via kseg1 and hence uncached. Accesses to the on-chip RAM are as fast as cache accesses so there is no point in going through the cache for those.

eCos can be configured for one of three startup types:

RAM: This is the startup type normally used during application development. RedBoot is programmed into flash and performs the initial bootstrap. mipsisa32-elf-gdb is then used to load a RAM startup application into memory and debug it. By default the application will use eCos' virtual vectors mechanism to obtain certain services from RedBoot, including diagnostic output. The bottom 256K of RAM is used for RedBoot code and data so the application will start at 0x80040000.
ROMRAM: This startup type can be used for finished applications which will be programmed into the start of external flash at location 0xB8000000. On power-up the chip's bootloader will automatically load the application into RAM at location 0x80001000 and start it. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization. This startup type is used for building the flash-resident version of RedBoot but can also be used for application code.
JTAG: This can be used to run applications via JTAG rather than RedBoot. As with ROMRAM startup, the application will be loaded at location 0x80001000 and it will take over all the hardware. Uart1 will be used for all HAL diagnostics and standard output. A JTAG build of RedBoot can be used during hardware setup to program the ROMRAM version into flash. A JTAG application build may prove useful for debugging certain problems, especially ones related to interrupts and exceptions. However the JTAG software may not fully cope with the executables and debug information generated by the GNU tools, so the user experience may be poor compared with using the GNU mipsisa32-elf-gdb debugger.

In a typical setup the first 128K of flash is used for holding the RedBoot image, and the last 64K is used for managing the flash and holding the RedBoot fconfig values. The remaining blocks from 0x98020000 to 0x983EFFFF can be used by application code.

RedBoot can communicate with the host using either uart1 or ethernet. The PNX8310's uart0 is not connected on this board.

All configurations for the STB200 target include an ethernet driver package CYGPKG_DEVS_ETH_SMSC_LAN9118. If the application does not actually require ethernet functionality then the package is inactive and the final executable will not suffer any overheads from unused functionality. This is determined by the presence of the generic ethernet I/O package CYGPKG_IO_ETH_DRIVERS. Typically the choice of eCos template causes the right thing to happen. For example, the default template does not include any TCP/IP stack so CYGPKG_IO_ETH_DRIVERS is not included, but both the net and redboot templates do include a TCP/IP stack so will specify that package and hence enable the ethernet driver. The ethernet device can be shared by RedBoot and the application, so it is possible to debug a networked application over ethernet.

The STB200 board does not have a serial EPROM or similar hardware providing a unique network MAC address. Instead a suitable address has to be programmed into flash via RedBoot's fconfig command.

All configurations for the STB200 target include a serial device driver package CYGPKG_DEVS_SERIAL_MIPS_PNX8310. The driver as a whole is inactive unless the generic serial support, CYGPKG_IO_SERIAL_DEVICES is enabled. Only uart1 has a suitable connector so that is the only device which can be accessed through the serial driver. The hardware flow control lines are not connected so only software flow control is available. If the UART is needed by the application then it cannot also be used by RedBoot for gdb traffic, so another communication channel such as ethernet should be used instead.

All configurations for the STB200 target include a watchdog device driver package CYGPKG_DEVS_WATCHDOG_MIPS_PNX8310. This is inactive unless the generic watchdog support, CYGPKG_IO_WATCHDOG is loaded.

The on-chip interrupt controller is managed by eCos using macros provided by the PNX8310 processor HAL. The on-chip timer TMR1 is used to implement the eCos system clock. If gprof-based profiling is enabled then that will use TMR2, otherwise that timer can be used by the application. TMR3 is normally used only by the watchdog device driver. GPIO pins 17 and 18 are used for uart1, and pin 14 is used for ethernet interrupts. The remaining GPIO pins are not used by eCos. Other on-chip peripherals are left to their initial settings and not manipulated by eCos.

Overview

Name

Description

Supported Hardware

Tools