Options -- Configuring the MIPS Architectural HAL Package
Description
The MIPS architectural HAL is included in all
ecos.db entries for MIPS targets, so
the package will be loaded automatically when creating a
configuration. It should never be necessary to load the package
explicitly or to unload it.
The MIPS architectural HAL contains a number of configuration
points. Few of these should be altered by the user, they are
mainly present for the variant and platform HALs to select
different architectural features.
CYGINT_HAL_MIPS_VARIANT
This interface is implemented by each variant HAL and acts as a
check on the number of variants included in the configuration.
CYGPKG_HAL_MIPS_MIPS16_SUPPORT
This option is usually set with a requires statement by the
variant or platform HAL to enable support for MIPS16
applications. The eCos operating system and library remains in
the MIPS32 instruction set.
CYGINT_HAL_MIPS_MICROMIPS_SUPPORT
This interface is implemented by the variant or platform HAL to
enable support for the microMIPS instruction set.
CYGPKG_HAL_MIPS_MICROMIPS_SUPPORT
This option is usually enabled implicitly by the variant or
platform HAL
implementing CYGINT_HAL_MIPS_MICROMIPS_SUPPORT.
Its value controls the level of support for the microMIPS
instruction set. If set to APP then only
application code may be compiled in the microMIPS instruction
set, eCos remains in the MIPS32 instruction set. If set
to ECOS then the whole of eCos is also
compiled to the microMIPS instruction set, although those parts
of the HAL involved in startup and exception handling remain in
MIPS32 instructions. If set to FULL then all
code is compiled or assembled to microMIPS. This latter option
is only applicable to CPU variants that only execute microMIPS
instructions and is not currently supported.
CYGNUM_HAL_MIPS_RELEASE
This option defines the architecture release that the processor
supports. It is usually set by the variant or platform HAL to
enable various configuration changes in the architecture HAL.
CYGINT_HAL_MIPS_DEBUG_MODE
This interface is implemented by the variant or platform HAL to
enable support for Debug Mode. Debug Mode is only available on
Release 2 devices that have EJTAG support. It is used primarily to
support single step and breakpoints.
CYGHWR_HAL_MIPS_CPU_FREQ
This option contains the frequency of the CPU in MegaHertz.
This will usually be set from the variant or platform HAL,
which may define additional clock related options. This may
affect thing like serial device, interval clock and memory
access speed settings.
CYGSEM_HAL_MIPS_EMULATE_UNIMPLEMENTED_FPU_OPS
Enabling this option will include a hook in the exception
processing so that Unimplemented Operation FPU exceptions may
be handled. This option has no effect if there is no hardware
floating-point unit. Note that not all situations in which an
exception is raised may be handled. If not, the exception will
be passed on as normal through the standard exception delivery
mechanism.
CYGINT_HAL_MIPS_STUB_REPRESENT_32BIT_AS_64BIT
This interface may be implemented by MIPS variant or platform
HALs to instruct the MIPS stub to interwork correctly with GDB
which expects 64-bit register values, even in application code
which has been compiled as 32-bit. Do not use this for real
64-bit code.
CYGINT_HAL_MIPS_INTERRUPT_RETURN_KEEP_SR_IM
On some MIPS variants, the status register (SR) contains a
number of interrupt mask bits (IM\[0..7\]). Default behaviour
is to restore the whole SR over an interrupt. This means that
if the ISR modifies those bits, the change is lost when the
interrupt returns. If this interface is implemented, changes
made to the SR IM bits by an ISR will instead be preserved.
Variants whose HAL_INTERRUPT_MASK() routines (et al) modify the
IM bits in the SR should implement this interface to get the
necessary preserving behaviour.
Redefinable Macros
In addition to the CDL configuration points above, there are a
number of assembler macros that may be redefined. The assembler
header cyg/hal/arch.inc contains default
implementations of most of these. Variant or platform HALs may
supply alternative definitions of these and define the matching
preprocessor macro. For example, the default implementation of
the hal_intc_init macro sets up the default
interrupt mechanism using the Status register. By
defining CYGPKG_HAL_MIPS_INTC_INIT_DEFINED,
this macro may be
redefined. Defining CYGPKG_HAL_MIPS_INTC_DEFINED
allows all the hal_intc_* macros to be
redefined. This same approach is applicable to most other macros
or macro groups in arch.inc.
The same approach is also applicable to C-level macros for
controlling interrupts, the timer, caches, bit
indexing. A ..._DEFINED macro is tested to
determine whether a macro, or group of macros, have been defined
in the variant or platform and if not then a default
implementation is defined.
Compiler Flags
It is normally the responsibility of the platform HAL to define
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.
Linker Scripts
The linker script, supplied by either the variant or platform
HALs, must define some symbols that the architecture HAL depends
on:
hal_vsr_table
This defines the location of the VSR table. First level
interrupt and exception trampolines use the value of the Cause
register ExcCode field to index this table and vector to a VSR
routine. Generally this table should be placed in RAM close to
the vector trampolines. This table should be 64 entries in
length, although not all will be used.
hal_virtual_vector_table
This defines the location of the virtual vector table used to
communicate between a ROM monitor and an eCos application. This
table needs to be word aligned. It is usually placed in
internal SRAM just after the VSR table, perhaps aligned to a
convenient boundary. This table should be 64 entries in length.
