Overview

Supported Hardware

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

Memory	Base	Length
SDRAM	0x80000000	0x20000000
SRAM	0x80000000	0x00400000
User Flash	0x9c000000	0x02000000
SRAM Shadow	0x8E000000	0x00400000
Interrupt Controller	0xBB1C0000	0x00020000
Peripherals	0xBF000000	0x00010000
SMSC LAN9211	0xBF010000	0x00010000
Boot Flash	0xBFC00000	0x00600000

On the LX110 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.

Overview

Name

Description

Supported Hardware

Tools