Comtrol eCos - Manual (Page 344)

Chapter 11. Porting Guide
address bits.
• Define global pointer save/restore macros. These really only need defining if the calling conventions of the
architecture require a global pointer (as does the MIPS architecture), they may be empty otherwise. If it is
necessary to define these, then take a look at the MIPS implementation for an example.
4. Copy hal_intr.h from an example HAL. Within this file you should change or define the following:
• Define the exception vectors. These should be detailed in the architecture specification. Essentially for each
exception entry point defined by the architecture there should be an entry in the VSR table. The offsets of
these VSR table entries should be defined here by
CYGNUM_HAL_VECTOR_* definitions. The size of the VSR
table also needs to be defined here.
• Map any hardware exceptions to standard names. There is a group of exception vector name of the form
CYGNUM_HAL_EXCEPTION_* that define a wide variety of possible exceptions that many architectures raise.
Generic code detects whether the architecture can raise a given exception by testing whether a given
CYGNUM_HAL_EXCEPTION_* definition is present. If it is present then its value is the vector that raises that
exception. This does not need to be a one-to-one correspondence, and several CYGNUM_HAL_EXCEPTION_*
definitions may have the same value.
Interrupt vectors are usually defined in the variant or platform HALs. The interrupt number space may
either be continuous with the VSR number space, where they share a vector table (as in the i386) or may be
a separate space where a separate decode stage is used (as in MIPS or PowerPC).
• Declare any static data used by the HAL to handle interrupts and exceptions. This is usually
three
vectors for interrupts: hal_interrupt_handlers[] , hal_interrupt_data[] and
hal_interrupt_objects[] , which are sized according to the interrupt vector definitions. In addition a
definition for the VSR table, hal_vsr_table[] should be made. These vectors are normally defined in
either vectors.S or hal_misc.c .
• Define interrupt enable/disable macros. These are normally inline assembly fragments to execute the in-
structions, or manipulate the CPU register, that contains the CPU interrupt enable bit.
• A feature that many HALs support is the ability to execute DSRs on the interrupt stack. This is not an essen-
tial feature, and is better left unimplemented in the initial porting effort. If this is required, then the macro
HAL_INTERRUPT_STACK_CALL_PENDING_DSRS() should be defined to call a function in vectors.S .
• Define the interrupt and VSR attachment macros. If the same arrays as for other HALs have been used for
VSR and interrupt vectors, then these macro can be copied across unchanged.
5. A number of other header files also need to be filled in:
• basetype.h . This file defines the basic types used by eCos, together with the endianness and some other
characteristics. This file only really needs to contain definitions if the architecture differs significantly from
the defaults defined in
cyg_type.h
• hal_io.h . This file contains macros for accessing device IO registers. If the architecture uses memory
mapped IO, then these can be copied unchanged from an existing HAL such as MIPS. If the architecture
uses special IO instructions, then these macros must be defined as inline assembler fragments. See the I386
HAL for an example. PCI bus access macros are usually defined in the variant or platform HALs.
240