The SEAD3 platform HAL package is loaded automatically when eCos is configured for an SEAD3 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 SEAD3 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
mips-sde-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 boot flash at 0xbfc00000. On power up the processor 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 that run stand-alone.
ROMRAM startup can be used for applications which are programmed into the boot flash at 0xbfc00000. On power up the processor will jump to this location and execute the code that is there. The startup code will copy the applications taxt and data segments from ROM to RAM at 0x80000000 and zero the BSS. Code execution will continue from RAM. 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 that run stand-alone.
JTAG startup can be used for applications which will be debugged via JTAG instead of RedBoot. The behaviour is a combination of ROM and RAM startup: the application is loaded at 0x80000000 and initializes all the hardware, with no dependencies on services provided by a ROM monitor.
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 applications should be loaded via
ethernet. Diagnostic output can also be switched to using UART1 by
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.
Board Type Selection
CYGHWR_HAL_MIPS_SEAD3 selects the
SEAD3 board variant. It may be set to
LX110. Normally this will be set
automatically when selecting for the sead3_14k
or sead3_14kc targets.
Endian Mode Selection
the CPU and peripheral endian mode. It may be set to
The BIGEND switch, SW2, needs to be set to
match and if RAM applications are to be used a matching RedBoot
must also be installed. Note also that the RedBoot flash directory
and configuration are not stored in an endian-independent manner
and would need to be reinitialized.
Instruction Set Selection
selects instruction set support. It may be set to
FULL. The default is
which causes eCos and RedBoot to be compiled in the MIPS32
instruction set, but allows user code to be compiled in the
microMIPS instruction set. When set to
then all eCos/RedBoot C and C++ code is compiled into microMIPS
instructions; however assembly level startup and exception
handling code remains in MIPS32 instructions, as it must since the
CPU starts in this instruction set, and switches to it for all
FULL option is present for
future devices that operate entirely in microMIPS mode, and is not
Unlike endian mode, the instruction set selection of RedBoot and eCos applications need not match. A MIPS32 RedBoot can load and run microMIPS eCos applications and a microMIPS RedBoot can load and run MIPS32 applications.
To compile applications into microMIPS the standard flags that are used in eCos and exported to the ecos.mak file should be used except that the -mips32r2 flag should be replaced by -mmicromips and the options -mno-jals -minterlink-mips16 added.
The platform HAL package contains flash driver support for the
user flash device. By default this is inactive, and it can be made
active by loading the generic flash package
CYGPKG_IO_FLASH. The boot flash is not
programmable at runtime.
The platform HAL provides the platform-specific support for a single SMSC LAN9211 ethernet device, if the generic ethernet support is enabled. The MAC address is stored in an EEPROM connected to the LAN9211 and will be loaded into the MAC automatically on reset.
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 some flags specific to this port:
The mips-sde-elf-gcc toolchain defaults to supporting the mips32 release 2 architecture, so this option is not strictly necessary. However, it is good practice to include it.
To compile code in the microMIPS instruction set, this option must be substituted for
These options are necessary to link MIPS32 code with microMIPS code. They both restrict the compiler to generating instructions for calls and other control transfers that can be converted to instructions that switch the instruction set. Without these options some instructions either cannot be converted, or will be converted incorrectly.
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 supports both big-endian and little-endian modes.
The M14K family does not have a hardware floating point unit so software floating point has to be used instead.