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:
Memory | Base | Length |
---|---|---|
SDRAM | 0x80000000 | 0x20000000 |
SRAM | 0x80000000 | 0x00400000 |
User Flash | 0x9c000000 | 0x02000000 |
SRAM Shadow | 0x8E000000 | 0x00400000 |
Interrupt Controller (if present) | 0xBB1C0000 | 0x00020000 |
Peripherals | 0xBF000000 | 0x00010000 |
SMSC LAN9211 | 0xBF010000 | 0x00010000 |
Boot Flash | 0xBFC00000 | 0x00600000 |
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.
2024-12-10 | eCosPro Non-Commercial Public License |