Configuration

Name

Configuration -- Platform-specific Configuration Options

Overview

The STB200 platform HAL package is loaded automatically when eCos is configured for an STB200 target. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.

Startup

The STB200 platform HAL package supports three separate startup types: RAM, ROMRAM and JTAG. The configuration option CYG_HAL_STARTUP controls which startup type is being used. For typical application development RAM startup should be used, and the application will be run via mipsisa32-elf-gdb interacting with RedBoot using either serial or ethernet. It is assumed that the low-level hardware initialization, including setting up the memory map, has already been performed by RedBoot. By default the application will use certain services provided by RedBoot via the virtual vector mechanism, including diagnostic output, but that can be disabled via CYGSEM_HAL_USE_ROM_MONITOR.

ROMRAM startup can be used for applications which are programmed into the base of flash at 0x98000000. On power up the chip's boot loader will load the first 8K of code from flash to RAM at 0x80001000 and branch to that location. The startup code will copy the remainder of the application from flash to RAM, and subsequently the flash will not be used for executing any code. All the hardware will be initialized, and the application is self-contained. This startup type is used by the flash-resident version of RedBoot, and can also be used for finished applications.

JTAG startup can be used for applications which will be debugged via JTAG instead of RedBoot. The behaviour is mostly the same as for ROMRAM startup: the application is loaded at 0x80001000 and initializes all the hardware, with no dependencies on services provided by a ROM monitor. There are some minor differences in the startup code, for example it is not necessary to copy the remainder of the application from flash to RAM.

RedBoot and Virtual Vectors

If the application is intended to act as a ROM monitor, providing services for other applications, then the configuration option CYGSEM_HAL_ROM_MONITOR should be set. Typically this option is set only when building RedBoot.

If the application is supposed to make use of services provided by a ROM monitor, via the eCos virtual vector mechanism, then the configuration option CYGSEM_HAL_USE_ROM_MONITOR should be set. By default this option is enabled when building for a RAM startup, disabled otherwise. It can be manually disabled for a RAM startup, making the application self-contained. That is useful as a testing step before switching to ROM startup. It also allows applications to be run and debugged via BDM.

If the application does not rely on a ROM monitor for diagnostic services then uart1 will be used for HAL diagnostics and standard output. The default baud rate is controlled by CYGNUM_HAL_MIPS_STB200_DIAG_BAUD. The board does not have a connector for uart0 so that cannot be used instead. Since uart1 is needed by the HAL diagnostics code it cannot be accessed via the serial driver.

System Clock

The coprocessor 0 TMR1 timer is used for the eCos system clock. The configuration option CYGNUM_HAL_RTC_PERIOD controls the value programmed into the compare register. TMR1 ticks at 120MHz so the default value of 1200000 corresponds to a 100Hz system clock or one tick per 10ms. Other clock-related settings are recalculated automatically if the period is changed.

Flash Driver

The platform HAL package contains flash driver support for the external flash device. By default this is inactive, and it can be made active by loading the generic flash package CYGPKG_IO_FLASH. The board may use one of a variety of flash chips. The exact type present is determined at run-time using CFI and the system will adjust accordingly.

Ethernet Support

The platform HAL provides the platform-specific support for a single SMSC LAN9118 ethernet device, if the generic ethernet support is enabled. The configuration CYGNUM_HAL_MIPS_STB200_ETH_ISR_PRIORITY provides control over the interrupt priority used for this device. The board does not have a suitable EEPROM so the MAC address is provided via a RedBoot fconfig option.

Compiler Flags

The platform HAL defines the default compiler and linker flags for all packages, although it is possible to override these on a per-package basis. Most of the flags used are the same as for other architectures supported by eCos. There are four flags specific to this port:

-mips2

The mipsisa32-elf-gcc toolchain defaults to supporting the mips32 architecture, and the PNX8310's PR1910 core does not fully implement this. Specifying -mips2 restricts the compiler to using a subset of the mips32 instruction set appropriate for the PR1910.

-G0

MIPS calling conventions reserve one register for use as a global pointer register. In theory this allows static variables in one 64K area of memory to be accessed using just one instruction instead of two, and the -G option provides some control over this. However due to limitations within the current linker all modules have to be compiled with the same -G setting, and the compiler support libraries are built with -G0. Therefore all eCos and application modules also have to be built with -G0 and this optimization is not available.

-EB

The eCos port only supports big-endian mode so -EB must be specified.

-msoft-float

The PR1910 does not have a hardware floating point unit so software floating point has to be used instead.

2017-02-09
Documentation license for this page: eCosPro License