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.
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
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
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.
The coprocessor 0 TMR1 timer is used for the eCos system clock. The
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.
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.
The platform HAL provides the platform-specific support for a single
SMSC LAN9118 ethernet device, if the generic ethernet support is
enabled. The configuration
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.
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:
The mipsisa32-elf-gcc toolchain defaults to supporting the mips32 architecture, and the PNX8310's PR1910 core does not fully implement this. Specifying
-mips2restricts the compiler to using a subset of the mips32 instruction set appropriate for the PR1910.
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
-Goption provides some control over this. However due to limitations within the current linker all modules have to be compiled with the same
-Gsetting, and the compiler support libraries are built with
-G0. Therefore all eCos and application modules also have to be built with
-G0and this optimization is not available.
The eCos port only supports big-endian mode so
-EBmust be specified.
The PR1910 does not have a hardware floating point unit so software floating point has to be used instead.