Name

eCos Support for the MIPS SEAD3 Board — Overview

Description

The MIPS SEAD3 board comes in three variants. The LX50 is fitted with a M14K processor and no SDRAM. The LX110 is fitted with a M14Kc processor and 512MiB of SDRAM. The LX155 is virtually identical to the LX110, but is fitted with a larger FPGA. From the point of view of eCos, it is considered identical to the LX110 and all references in this documentation and in eCos to the LX110 should be considered to include the LX155. All boards have 4MiB of SRAM and 32MiB of NOR flash, a dual 16550 compatible UART, and a SMSC LAN9211 ethernet controller. A two line LCD display and LEDs are also present. For typical eCos development a RedBoot image is programmed into the external flash. RedBoot provides gdb stub functionality so it is then possible to download and debug eCos applications via the gdb debugger. This can happen over either a serial line or over ethernet. It is also possible to debug applications using the JTAG interface.

Supported Hardware

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

MemoryBaseLength
SDRAM0x800000000x20000000
SRAM0x800000000x00400000
User Flash0x9c0000000x02000000
SRAM Shadow0x8E0000000x00400000
Interrupt Controller (if present)0xBB1C00000x00020000
Peripherals0xBF0000000x00010000
SMSC LAN92110xBF0100000x00010000
Boot Flash0xBFC000000x00600000

On the LX110/LX155 SDRAM is mapped to physical address 0x00000000 and SRAM is visible only at the shadow location. On the LX50 SRAM is mapped to physical location 0x00000000 as well as the shadow location. SDRAM, SRAM and flash are normally accessed via the kseg0 segment and hence via the cache. The peripherals are normally accessed via kseg1 and hence uncached.

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. mip-sde-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 1MB of RAM is used for RedBoot code and data so the application will start at 0x80100000.
ROM
This startup type can be used for finished applications which will be programmed into the start of external flash at location 0xbfc00000. On power-up the processor will automatically execute the contents of flash from 0xbfc00000. The application will initialize the system, copy its data to RAM and zero its BSS. 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.
ROMRAM
This startup type can be used for finished applications which will be programmed into the start of external flash at location 0xbfc00000. On power-up the processor automatically execute the contents of flash from 0xbfc00000. The application will initialize the system, copy itself from flash to RAM, and zero its BSS. 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. The application will be loaded at location 0x80000000 and it will take over all the hardware. Uart0 will be used for all HAL diagnostics and standard output. 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 mips-sde-elf-gdb debugger.

In a typical setup RedBoot is programmed into the boot flash, which eCos does not manage. The last 256KiB of User flash is used for managing the flash and holding the RedBoot fconfig values. The remaining blocks from 0x9c000000 to 0x9dfbffff can be used by application code.

RedBoot can communicate with the host using either uart0 or ethernet.

All configurations for the SEAD3 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 SEAD3 board has a serial EPROM providing a unique network MAC address.

All configurations for the SEAD3 target include serial device driver packages CYGPKG_IO_SERIAL_GENERIC_16X5X and CYGPKG_IO_SERIAL_MIPS_SEAD3. The 16X5X driver provided generic support for 16X5X compatible UARTs while the SEAD3 package provides configuration to adapt that driver to the SEAD3 board. The driver as a whole is inactive unless the generic serial support, CYGPKG_IO_SERIAL_DEVICES is enabled. Both UART0 and UART1 are connected, and both have hardware flow control lines routed to the connector. UART0 is routed to a standard 9-pin RS232 connector and UART1 is connected to an FTDI USB adaptor. If a UART is needed by the application then it cannot also be used by RedBoot for gdb traffic, so care should be exercised in selecting which UART to use for these purposes. Alternatively another communication channel such as ethernet should be used instead.

The GIC interrupt controller is managed by eCos using macros provided by the SEAD3 platform HAL. The architecture COUNTER/COMPARE timer is used to implement the eCos system clock. If gprof-based profiling is enabled then that will use the GIC compare register and its associated interrupt. If the core does not include a GIC, then the configuration option CYGHWR_HAL_SEAD3_HAS_GIC must be disabled, and gprof profiling will not be possible. At the moment, without a GIC additional interrupt decoding is performed to indicate which of the two UART devices generated an interrupt, as these are multiplexed in the same interrupt vector (2). However decoding is not performed on the multiplexed peripherals on interrupt vector 0: PIC32 GPIO, SPI or USB as these peripherals are as yet not supported in eCosPro.

Tools

The SEAD3 port is intended to work with GNU tools configured for an mips-sde-elf target. The original port was done using mips-sde-elf-gcc version 4.4 mips-sde-elf-gdb version 6.8, and binutils version 2.19.