eCos Support for the NXP STB220 Board — Overview
The NXP STB220 board has a PNX8330 processor, 32MB of external SDRAM, 16MB of external flash, an SMSC LAN9118 ethernet chip, and connectors plus required support chips for various on-chip peripherals. 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.
The memory map used by both eCos and RedBoot is as follows:
External SDRAM 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 four startup types:
- 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 1MB of RAM is used for RedBoot code and data so the application will start at 0x80100000.
- 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 execute the contents of flash from 0xB8000000. The application will initialize SDRAM, 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.
- 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 execute the contents of flash from 0xB8000000. The application will initialize SDRAM, 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.
- 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 build of RedBoot can be used during hardware setup to program the ROM or ROMRAM versions 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 128KB of flash is used for holding the RedBoot image, and the last 128KB is used for managing the flash and holding the RedBoot fconfig values. The remaining blocks from 0x98020000 to 0x98FEFFFF can be used by application code.
RedBoot can communicate with the host using either uart0 or uart1.
All configurations for the STB220 target include an ethernet driver
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
Typically the choice of eCos template causes the right thing to
happen. For example, the default template does not include any TCP/IP
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 STB220 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 STB220 target include a serial device
(this driver is shared with PNX8310 based targets, and for historical
reasons it is named for them, however it it applicable to both). The
driver as a whole is inactive unless the generic serial support,
CYGPKG_IO_SERIAL_DEVICES is enabled. Both Uart0 and
uart1 are connected, however, only Uart0 has hardware flow control
lines routed to the connector. 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 chould be
All configurations for the STB220 target include a watchdog device
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 PNX8330 processor HAL. The architecture COUNTER/COMPARE timer is used to implement the eCos system clock. If gprof-based profiling is enabled then that will use CONFIG unit timer 0, otherwise that timer can be used by the application. GPIO pins 4 to 7 are used for UART1 and pins 10 to 13 may be 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.
The STB220 port is intended to work with GNU tools configured for an mipsisa32-elf target. The original port was done using mipsisa32-elf-gcc version 3.4.4 mipsisa32-elf-gdb version 6.3, and binutils version 2.16.
|2019-09-17||eCosPro Non-Commercial Public License|