Configuration
Prev Chapter 332. MIPS Architectural HAL Next

Name

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.
Prev Up Next
MIPS Architectural HAL  Home The HAL Port