The STB220 platform HAL package is loaded automatically when eCos is configured for an STB220 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 STB220 platform HAL package supports four separate startup
types: RAM, ROM, 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
ROM startup can be used for applications which are programmed into the base of a parallel flash device at 0x98000000. On power up the chip's boot loader will jump to this location and execute the code that is there. The startup code will copy the applications data segment from ROM to RAM at 0x80000000 and zero the BSS. Code execution will continue from ROM. All the hardware will be initialized, and the application is self-contained. This startup type can be used by the flash-resident version of RedBoot, and can also be used for finished applications.
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 jump to this location and execute the code that is there. The startup code will copy the application from flash to RAM at 0x80000000, 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 0x80000000 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 JTAG.
If the application does not rely on a ROM monitor for diagnostic
services then uart0 will be used for HAL diagnostics and standard
output. The default baud rate is controlled by
uart0 is needed by the HAL diagnostics code it cannot be accessed via
the serial driver and uart1 should be used for this purpose.
The coprocessor 0 COUNTER/COMPARE timer is used for the eCos system
clock. The configuration option
CYGNUM_HAL_RTC_PERIOD controls the value programmed
into the compare register. The value of this is calculated from the
CPU frequency and the value of
CYGNUM_HAL_RTC_DENOMINATOR. The calculations are
arranged so that
effectively defines the clock frequency and it the only configuration
option that need to be changed to select a different clock rate.
DRAM Type Selection
EV8330 boards can be fitted with either DDR RAM or SDRAM. These
require different initialization of the the SDRAM interface
controller. This is selected by setting
CYGHWR_HAL_PNX8330_DRAM to either
SDRAM or DDR. The default
is to select SDRAM.
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 option
CYGNUM_HAL_MIPS_STB220_ETH_ISR_PIO controls which
PIO pin the ethernet interrupt is connected to and
CYGNUM_HAL_MIPS_STB220_ETH_CS controls which chip
select is used to access the ethernet device. These options must match
the setting of the jumpers on the board. The board does not have a
suitable EEPROM so the MAC address is provided via a RedBoot fconfig
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, so this option is not strictly necessary. However, it is good practice to include it.
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 PNX8330 does not have a hardware floating point unit so software floating point has to be used instead.