<!-- Copyright (C) 2003 Red Hat, Inc. -->
|
<!-- Copyright (C) 2003 Red Hat, Inc. -->
|
<!-- This material may be distributed only subject to the terms -->
|
<!-- This material may be distributed only subject to the terms -->
|
<!-- and conditions set forth in the Open Publication License, v1.0 -->
|
<!-- and conditions set forth in the Open Publication License, v1.0 -->
|
<!-- or later (the latest version is presently available at -->
|
<!-- or later (the latest version is presently available at -->
|
<!-- http://www.opencontent.org/openpub/). -->
|
<!-- http://www.opencontent.org/openpub/). -->
|
<!-- Distribution of the work or derivative of the work in any -->
|
<!-- Distribution of the work or derivative of the work in any -->
|
<!-- standard (paper) book form is prohibited unless prior -->
|
<!-- standard (paper) book form is prohibited unless prior -->
|
<!-- permission is obtained from the copyright holder. -->
|
<!-- permission is obtained from the copyright holder. -->
|
<HTML
|
<HTML
|
><HEAD
|
><HEAD
|
><TITLE
|
><TITLE
|
>Architecture HAL Porting</TITLE
|
>Architecture HAL Porting</TITLE
|
><meta name="MSSmartTagsPreventParsing" content="TRUE">
|
><meta name="MSSmartTagsPreventParsing" content="TRUE">
|
<META
|
<META
|
NAME="GENERATOR"
|
NAME="GENERATOR"
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
"><LINK
|
"><LINK
|
REL="HOME"
|
REL="HOME"
|
TITLE="eCos Reference Manual"
|
TITLE="eCos Reference Manual"
|
HREF="ecos-ref.html"><LINK
|
HREF="ecos-ref.html"><LINK
|
REL="UP"
|
REL="UP"
|
TITLE=" Porting Guide"
|
TITLE=" Porting Guide"
|
HREF="hal-porting-guide.html"><LINK
|
HREF="hal-porting-guide.html"><LINK
|
REL="PREVIOUS"
|
REL="PREVIOUS"
|
TITLE="Variant HAL Porting"
|
TITLE="Variant HAL Porting"
|
HREF="hal-porting-variant.html"><LINK
|
HREF="hal-porting-variant.html"><LINK
|
REL="NEXT"
|
REL="NEXT"
|
TITLE="Future developments"
|
TITLE="Future developments"
|
HREF="hal-future-developments.html"></HEAD
|
HREF="hal-future-developments.html"></HEAD
|
><BODY
|
><BODY
|
CLASS="SECTION"
|
CLASS="SECTION"
|
BGCOLOR="#FFFFFF"
|
BGCOLOR="#FFFFFF"
|
TEXT="#000000"
|
TEXT="#000000"
|
LINK="#0000FF"
|
LINK="#0000FF"
|
VLINK="#840084"
|
VLINK="#840084"
|
ALINK="#0000FF"
|
ALINK="#0000FF"
|
><DIV
|
><DIV
|
CLASS="NAVHEADER"
|
CLASS="NAVHEADER"
|
><TABLE
|
><TABLE
|
SUMMARY="Header navigation table"
|
SUMMARY="Header navigation table"
|
WIDTH="100%"
|
WIDTH="100%"
|
BORDER="0"
|
BORDER="0"
|
CELLPADDING="0"
|
CELLPADDING="0"
|
CELLSPACING="0"
|
CELLSPACING="0"
|
><TR
|
><TR
|
><TH
|
><TH
|
COLSPAN="3"
|
COLSPAN="3"
|
ALIGN="center"
|
ALIGN="center"
|
>eCos Reference Manual</TH
|
>eCos Reference Manual</TH
|
></TR
|
></TR
|
><TR
|
><TR
|
><TD
|
><TD
|
WIDTH="10%"
|
WIDTH="10%"
|
ALIGN="left"
|
ALIGN="left"
|
VALIGN="bottom"
|
VALIGN="bottom"
|
><A
|
><A
|
HREF="hal-porting-variant.html"
|
HREF="hal-porting-variant.html"
|
ACCESSKEY="P"
|
ACCESSKEY="P"
|
>Prev</A
|
>Prev</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="80%"
|
WIDTH="80%"
|
ALIGN="center"
|
ALIGN="center"
|
VALIGN="bottom"
|
VALIGN="bottom"
|
>Chapter 11. Porting Guide</TD
|
>Chapter 11. Porting Guide</TD
|
><TD
|
><TD
|
WIDTH="10%"
|
WIDTH="10%"
|
ALIGN="right"
|
ALIGN="right"
|
VALIGN="bottom"
|
VALIGN="bottom"
|
><A
|
><A
|
HREF="hal-future-developments.html"
|
HREF="hal-future-developments.html"
|
ACCESSKEY="N"
|
ACCESSKEY="N"
|
>Next</A
|
>Next</A
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><HR
|
><HR
|
ALIGN="LEFT"
|
ALIGN="LEFT"
|
WIDTH="100%"></DIV
|
WIDTH="100%"></DIV
|
><DIV
|
><DIV
|
CLASS="SECTION"
|
CLASS="SECTION"
|
><H1
|
><H1
|
CLASS="SECTION"
|
CLASS="SECTION"
|
><A
|
><A
|
NAME="HAL-PORTING-ARCHITECTURE">Architecture HAL Porting</H1
|
NAME="HAL-PORTING-ARCHITECTURE">Architecture HAL Porting</H1
|
><P
|
><P
|
>A new architecture HAL is the most complex HAL to write, and it the
|
>A new architecture HAL is the most complex HAL to write, and it the
|
least easily described. Hence this section is presently nothing more
|
least easily described. Hence this section is presently nothing more
|
than a place holder for the future.</P
|
than a place holder for the future.</P
|
><DIV
|
><DIV
|
CLASS="SECTION"
|
CLASS="SECTION"
|
><H2
|
><H2
|
CLASS="SECTION"
|
CLASS="SECTION"
|
><A
|
><A
|
NAME="AEN9793">HAL Architecture Porting Process</H2
|
NAME="AEN9793">HAL Architecture Porting Process</H2
|
><P
|
><P
|
>The easiest way to make a new architecture HAL is simply to copy an
|
>The easiest way to make a new architecture HAL is simply to copy an
|
existing architecture HAL of an, if possible, closely matching
|
existing architecture HAL of an, if possible, closely matching
|
architecture and change all the files to match the new
|
architecture and change all the files to match the new
|
architecture. The MIPS architecture HAL should be used if possible, as
|
architecture. The MIPS architecture HAL should be used if possible, as
|
it has the appropriate layout and coding conventions. Other HALs
|
it has the appropriate layout and coding conventions. Other HALs
|
may deviate from that norm in various ways.</P
|
may deviate from that norm in various ways.</P
|
><DIV
|
><DIV
|
CLASS="NOTE"
|
CLASS="NOTE"
|
><BLOCKQUOTE
|
><BLOCKQUOTE
|
CLASS="NOTE"
|
CLASS="NOTE"
|
><P
|
><P
|
><B
|
><B
|
>Note: </B
|
>Note: </B
|
> eCos is written for GCC. It requires C and C++
|
> eCos is written for GCC. It requires C and C++
|
compiler support as well as a few compiler features introduced during
|
compiler support as well as a few compiler features introduced during
|
eCos development - so compilers older than eCos may not provide these
|
eCos development - so compilers older than eCos may not provide these
|
features. Note that there is no C++ support for any 8 or 16 bit
|
features. Note that there is no C++ support for any 8 or 16 bit
|
CPUs. Before you can undertake an eCos port, you need the required
|
CPUs. Before you can undertake an eCos port, you need the required
|
compiler support.</P
|
compiler support.</P
|
></BLOCKQUOTE
|
></BLOCKQUOTE
|
></DIV
|
></DIV
|
><P
|
><P
|
>The following gives a rough outline of the steps needed to create a
|
>The following gives a rough outline of the steps needed to create a
|
new architecture HAL. The exact order and set of steps needed will
|
new architecture HAL. The exact order and set of steps needed will
|
vary greatly from architecture to architecture, so a lot of
|
vary greatly from architecture to architecture, so a lot of
|
flexibility is required. And of course, if the architecture HAL is to
|
flexibility is required. And of course, if the architecture HAL is to
|
be tested, it is necessary to do variant and platform ports for the
|
be tested, it is necessary to do variant and platform ports for the
|
initial target simultaneously.</P
|
initial target simultaneously.</P
|
><P
|
><P
|
></P
|
></P
|
><OL
|
><OL
|
TYPE="1"
|
TYPE="1"
|
><LI
|
><LI
|
><P
|
><P
|
>Make a new directory for the new architecture under the
|
>Make a new directory for the new architecture under the
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal</TT
|
>hal</TT
|
> directory in the source repository. Make an
|
> directory in the source repository. Make an
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>arch</TT
|
>arch</TT
|
> directory under this and populate this with
|
> directory under this and populate this with
|
the standard set of package directories.</P
|
the standard set of package directories.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Copy the CDL file from an example HAL changing its name to match the
|
>Copy the CDL file from an example HAL changing its name to match the
|
new HAL. Edit the file, changing option names as appropriate. Delete
|
new HAL. Edit the file, changing option names as appropriate. Delete
|
any options that are specific to the original HAL, and and any new
|
any options that are specific to the original HAL, and and any new
|
options that are necessary for the new architecture. This is likely to
|
options that are necessary for the new architecture. This is likely to
|
be a continuing process during the development of the HAL. See <A
|
be a continuing process during the development of the HAL. See <A
|
HREF="hal-porting-architecture.html#HAL-PORTING-ARCHITECTURE-CDL"
|
HREF="hal-porting-architecture.html#HAL-PORTING-ARCHITECTURE-CDL"
|
>the Section called <I
|
>the Section called <I
|
>CDL Requirements</I
|
>CDL Requirements</I
|
></A
|
></A
|
> for more details.</P
|
> for more details.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Copy the <TT
|
>Copy the <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_arch.h</TT
|
>hal_arch.h</TT
|
> file from an example
|
> file from an example
|
HAL. Within this file you need to change or define the following:</P
|
HAL. Within this file you need to change or define the following:</P
|
><P
|
><P
|
></P
|
></P
|
><UL
|
><UL
|
><LI
|
><LI
|
><P
|
><P
|
>Define the <SPAN
|
>Define the <SPAN
|
CLASS="STRUCTNAME"
|
CLASS="STRUCTNAME"
|
>HAL_SavedRegisters</SPAN
|
>HAL_SavedRegisters</SPAN
|
> structure. This
|
> structure. This
|
may need to reflect the save order of any group register save/restore
|
may need to reflect the save order of any group register save/restore
|
instructions, the interrupt and exception save and restore formats,
|
instructions, the interrupt and exception save and restore formats,
|
and the procedure calling conventions. It may also need to cater for
|
and the procedure calling conventions. It may also need to cater for
|
optional FPUs and other functional units. It can be quite difficult to
|
optional FPUs and other functional units. It can be quite difficult to
|
develop a layout that copes with all requirements.</P
|
develop a layout that copes with all requirements.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define the bit manipulation routines,
|
>Define the bit manipulation routines,
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_LSBIT_INDEX()</TT
|
>HAL_LSBIT_INDEX()</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_MSBIT_INDEX()</TT
|
>HAL_MSBIT_INDEX()</TT
|
>. If the architecture contains
|
>. If the architecture contains
|
instructions to perform these, or related, operations, then these
|
instructions to perform these, or related, operations, then these
|
should be defined as inline assembler fragments. Otherwise make them
|
should be defined as inline assembler fragments. Otherwise make them
|
calls to functions.</P
|
calls to functions.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define <TT
|
>Define <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_THREAD_INIT_CONTEXT()</TT
|
>HAL_THREAD_INIT_CONTEXT()</TT
|
>. This initializes
|
>. This initializes
|
a restorable CPU context onto a stack pointer so that a later call to
|
a restorable CPU context onto a stack pointer so that a later call to
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_THREAD_LOAD_CONTEXT()</TT
|
>HAL_THREAD_LOAD_CONTEXT()</TT
|
> or
|
> or
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_THREAD_SWITCH_CONTEXT()</TT
|
>HAL_THREAD_SWITCH_CONTEXT()</TT
|
> will execute it
|
> will execute it
|
correctly. This macro needs to take account of the same optional
|
correctly. This macro needs to take account of the same optional
|
features of the architecture as the definition of
|
features of the architecture as the definition of
|
<SPAN
|
<SPAN
|
CLASS="STRUCTNAME"
|
CLASS="STRUCTNAME"
|
>HAL_SavedRegisters</SPAN
|
>HAL_SavedRegisters</SPAN
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define <TT
|
>Define <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_THREAD_LOAD_CONTEXT()</TT
|
>HAL_THREAD_LOAD_CONTEXT()</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_THREAD_SWITCH_CONTEXT()</TT
|
>HAL_THREAD_SWITCH_CONTEXT()</TT
|
>. These should just be
|
>. These should just be
|
calls to functions in <TT
|
calls to functions in <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>context.S</TT
|
>context.S</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define <TT
|
>Define <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_REORDER_BARRIER()</TT
|
>HAL_REORDER_BARRIER()</TT
|
>. This prevents code
|
>. This prevents code
|
being moved by the compiler and is necessary in some order-sensitive
|
being moved by the compiler and is necessary in some order-sensitive
|
code. This macro is actually defined identically in all architecture,
|
code. This macro is actually defined identically in all architecture,
|
so it can just be copied.</P
|
so it can just be copied.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define breakpoint support. The macro
|
>Define breakpoint support. The macro
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_BREAKPOINT(label)</TT
|
>HAL_BREAKPOINT(label)</TT
|
> needs to be an inline assembly
|
> needs to be an inline assembly
|
fragment that invokes a breakpoint. The breakpoint instruction should
|
fragment that invokes a breakpoint. The breakpoint instruction should
|
be labeled with the <TT
|
be labeled with the <TT
|
CLASS="PARAMETER"
|
CLASS="PARAMETER"
|
><I
|
><I
|
>label</I
|
>label</I
|
></TT
|
></TT
|
>
|
>
|
argument. <TT
|
argument. <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_BREAKINST</TT
|
>HAL_BREAKINST</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_BREAKINST_SIZE</TT
|
>HAL_BREAKINST_SIZE</TT
|
> define the breakpoint
|
> define the breakpoint
|
instruction for debugging purposes.</P
|
instruction for debugging purposes.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define GDB support. GDB views the registers of the target as a linear
|
>Define GDB support. GDB views the registers of the target as a linear
|
array, with each register having a well defined offset. This array may
|
array, with each register having a well defined offset. This array may
|
differ from the ordering defined in
|
differ from the ordering defined in
|
<SPAN
|
<SPAN
|
CLASS="STRUCTNAME"
|
CLASS="STRUCTNAME"
|
>HAL_SavedRegisters</SPAN
|
>HAL_SavedRegisters</SPAN
|
>. The macros
|
>. The macros
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_GET_GDB_REGISTERS()</TT
|
>HAL_GET_GDB_REGISTERS()</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_SET_GDB_REGISTERS()</TT
|
>HAL_SET_GDB_REGISTERS()</TT
|
> translate between the GDB
|
> translate between the GDB
|
array and the <SPAN
|
array and the <SPAN
|
CLASS="STRUCTNAME"
|
CLASS="STRUCTNAME"
|
>HAL_SavedRegisters</SPAN
|
>HAL_SavedRegisters</SPAN
|
> structure.
|
> structure.
|
The <TT
|
The <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_THREAD_GET_SAVED_REGISTERS()</TT
|
>HAL_THREAD_GET_SAVED_REGISTERS()</TT
|
> translates a
|
> translates a
|
stack pointer saved by the context switch macros into a pointer to a
|
stack pointer saved by the context switch macros into a pointer to a
|
<SPAN
|
<SPAN
|
CLASS="STRUCTNAME"
|
CLASS="STRUCTNAME"
|
>HAL_SavedRegisters</SPAN
|
>HAL_SavedRegisters</SPAN
|
> structure. Usually this is
|
> structure. Usually this is
|
a one-to-one translation, but this macro allows it to differ if
|
a one-to-one translation, but this macro allows it to differ if
|
necessary.</P
|
necessary.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define long jump support. The type <SPAN
|
>Define long jump support. The type <SPAN
|
CLASS="TYPE"
|
CLASS="TYPE"
|
>hal_jmp_buf</SPAN
|
>hal_jmp_buf</SPAN
|
> and the
|
> and the
|
functions <TT
|
functions <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_setjmp()</TT
|
>hal_setjmp()</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>hal_longjmp()</TT
|
>hal_longjmp()</TT
|
> provide the underlying implementation
|
> provide the underlying implementation
|
of the C library <TT
|
of the C library <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>setjmp()</TT
|
>setjmp()</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>longjmp()</TT
|
>longjmp()</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define idle thread action. Generally the macro
|
>Define idle thread action. Generally the macro
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_IDLE_THREAD_ACTION()</TT
|
>HAL_IDLE_THREAD_ACTION()</TT
|
> is defined to call a
|
> is defined to call a
|
function in <TT
|
function in <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_misc.c</TT
|
>hal_misc.c</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define stack sizes. The macros
|
>Define stack sizes. The macros
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>CYGNUM_HAL_STACK_SIZE_MINIMUM</TT
|
>CYGNUM_HAL_STACK_SIZE_MINIMUM</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>CYGNUM_HAL_STACK_SIZE_TYPICAL</TT
|
>CYGNUM_HAL_STACK_SIZE_TYPICAL</TT
|
> should be defined to
|
> should be defined to
|
the minimum size for any thread stack and a reasonable default for
|
the minimum size for any thread stack and a reasonable default for
|
most threads respectively. It is usually best to construct these out
|
most threads respectively. It is usually best to construct these out
|
of component sizes for the CPU save state and procedure call stack
|
of component sizes for the CPU save state and procedure call stack
|
usage. These definitions should not use anything other than numerical
|
usage. These definitions should not use anything other than numerical
|
values since they can be used from assembly code in some HALs.</P
|
values since they can be used from assembly code in some HALs.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define memory access macros. These macros provide translation between
|
>Define memory access macros. These macros provide translation between
|
cached and uncached and physical memory spaces. They usually consist
|
cached and uncached and physical memory spaces. They usually consist
|
of masking out bits of the supplied address and ORing in alternative
|
of masking out bits of the supplied address and ORing in alternative
|
address bits.</P
|
address bits.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define global pointer save/restore macros. These really only need
|
>Define global pointer save/restore macros. These really only need
|
defining if the calling conventions of the architecture require a
|
defining if the calling conventions of the architecture require a
|
global pointer (as does the MIPS architecture), they may be empty
|
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
|
otherwise. If it is necessary to define these, then take a look at the
|
MIPS implementation for an example.</P
|
MIPS implementation for an example.</P
|
></LI
|
></LI
|
></UL
|
></UL
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Copy <TT
|
>Copy <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_intr.h</TT
|
>hal_intr.h</TT
|
> from an example HAL. Within this
|
> from an example HAL. Within this
|
file you should change or define the following:</P
|
file you should change or define the following:</P
|
><P
|
><P
|
></P
|
></P
|
><UL
|
><UL
|
><LI
|
><LI
|
><P
|
><P
|
>Define the exception vectors. These should be detailed in the
|
>Define the exception vectors. These should be detailed in the
|
architecture specification. Essentially for each exception entry point
|
architecture specification. Essentially for each exception entry point
|
defined by the architecture there should be an entry in the VSR
|
defined by the architecture there should be an entry in the VSR
|
table. The offsets of these VSR table entries should be defined here
|
table. The offsets of these VSR table entries should be defined here
|
by <TT
|
by <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>CYGNUM_HAL_VECTOR_*</TT
|
>CYGNUM_HAL_VECTOR_*</TT
|
> definitions. The size of the
|
> definitions. The size of the
|
VSR table also needs to be defined here.</P
|
VSR table also needs to be defined here.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Map any hardware exceptions to standard names. There is a group of
|
>Map any hardware exceptions to standard names. There is a group of
|
exception vector name of the form
|
exception vector name of the form
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>CYGNUM_HAL_EXCEPTION_*</TT
|
>CYGNUM_HAL_EXCEPTION_*</TT
|
> that define a wide variety
|
> that define a wide variety
|
of possible exceptions that many architectures raise. Generic code
|
of possible exceptions that many architectures raise. Generic code
|
detects whether the architecture can raise a given exception by
|
detects whether the architecture can raise a given exception by
|
testing whether a given <TT
|
testing whether a given <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>CYGNUM_HAL_EXCEPTION_*</TT
|
>CYGNUM_HAL_EXCEPTION_*</TT
|
>
|
>
|
definition is present. If it is present then its value is the vector
|
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
|
that raises that exception. This does not need to be a one-to-one
|
correspondence, and several <TT
|
correspondence, and several <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>CYGNUM_HAL_EXCEPTION_*</TT
|
>CYGNUM_HAL_EXCEPTION_*</TT
|
>
|
>
|
definitions may have the same value.</P
|
definitions may have the same value.</P
|
><P
|
><P
|
>Interrupt vectors are usually defined in the variant or platform
|
>Interrupt vectors are usually defined in the variant or platform
|
HALs. The interrupt number space may either be continuous with the VSR
|
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
|
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
|
be a separate space where a separate decode stage is used (as in MIPS
|
or PowerPC).</P
|
or PowerPC).</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Declare any static data used by the HAL to handle interrupts and
|
>Declare any static data used by the HAL to handle interrupts and
|
exceptions. This is usually three vectors for interrupts:
|
exceptions. This is usually three vectors for interrupts:
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>hal_interrupt_handlers[]</TT
|
>hal_interrupt_handlers[]</TT
|
>,
|
>,
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>hal_interrupt_data[]</TT
|
>hal_interrupt_data[]</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>hal_interrupt_objects[]</TT
|
>hal_interrupt_objects[]</TT
|
>, which are sized according
|
>, which are sized according
|
to the interrupt vector definitions. In addition a definition for the
|
to the interrupt vector definitions. In addition a definition for the
|
VSR table, <TT
|
VSR table, <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>hal_vsr_table[]</TT
|
>hal_vsr_table[]</TT
|
> should be made. These
|
> should be made. These
|
vectors are normally defined in either <TT
|
vectors are normally defined in either <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>vectors.S</TT
|
>vectors.S</TT
|
>
|
>
|
or <TT
|
or <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_misc.c</TT
|
>hal_misc.c</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define interrupt enable/disable macros. These are normally inline
|
>Define interrupt enable/disable macros. These are normally inline
|
assembly fragments to execute the instructions, or manipulate the CPU
|
assembly fragments to execute the instructions, or manipulate the CPU
|
register, that contains the CPU interrupt enable bit.</P
|
register, that contains the CPU interrupt enable bit.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>A feature that many HALs support is the ability to execute DSRs on the
|
>A feature that many HALs support is the ability to execute DSRs on the
|
interrupt stack. This is not an essential feature, and is better left
|
interrupt stack. This is not an essential feature, and is better left
|
unimplemented in the initial porting effort. If this is required, then
|
unimplemented in the initial porting effort. If this is required, then
|
the macro <TT
|
the macro <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_INTERRUPT_STACK_CALL_PENDING_DSRS()</TT
|
>HAL_INTERRUPT_STACK_CALL_PENDING_DSRS()</TT
|
>
|
>
|
should be defined to call a function in
|
should be defined to call a function in
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>vectors.S</TT
|
>vectors.S</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define the interrupt and VSR attachment macros. If the same arrays as
|
>Define the interrupt and VSR attachment macros. If the same arrays as
|
for other HALs have been used for VSR and interrupt vectors, then
|
for other HALs have been used for VSR and interrupt vectors, then
|
these macro can be copied across unchanged.</P
|
these macro can be copied across unchanged.</P
|
></LI
|
></LI
|
></UL
|
></UL
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>A number of other header files also need to be filled in:</P
|
>A number of other header files also need to be filled in:</P
|
><P
|
><P
|
></P
|
></P
|
><UL
|
><UL
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>basetype.h</TT
|
>basetype.h</TT
|
>. This file defines the basic types
|
>. This file defines the basic types
|
used by eCos, together with the endianness and some other
|
used by eCos, together with the endianness and some other
|
characteristics. This file only really needs to contain definitions
|
characteristics. This file only really needs to contain definitions
|
if the architecture differs significantly from the defaults defined
|
if the architecture differs significantly from the defaults defined
|
in <TT
|
in <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>cyg_type.h</TT
|
>cyg_type.h</TT
|
></P
|
></P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_io.h</TT
|
>hal_io.h</TT
|
>. This file contains macros for accessing
|
>. This file contains macros for accessing
|
device IO registers. If the architecture uses memory mapped IO, then
|
device IO registers. If the architecture uses memory mapped IO, then
|
these can be copied unchanged from an existing HAL such as MIPS. If
|
these can be copied unchanged from an existing HAL such as MIPS. If
|
the architecture uses special IO instructions, then these macros must
|
the architecture uses special IO instructions, then these macros must
|
be defined as inline assembler fragments. See the I386 HAL for an
|
be defined as inline assembler fragments. See the I386 HAL for an
|
example. PCI bus access macros are usually defined in the variant or
|
example. PCI bus access macros are usually defined in the variant or
|
platform HALs.</P
|
platform HALs.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_cache.h</TT
|
>hal_cache.h</TT
|
>. This file contains cache access
|
>. This file contains cache access
|
macros. If the architecture defines cache instructions, or control
|
macros. If the architecture defines cache instructions, or control
|
registers, then the access macros should be defined here. Otherwise
|
registers, then the access macros should be defined here. Otherwise
|
they must be defined in the variant or platform HAL. Usually the cache
|
they must be defined in the variant or platform HAL. Usually the cache
|
dimensions (total size, line size, ways etc.) are defined in the
|
dimensions (total size, line size, ways etc.) are defined in the
|
variant HAL.</P
|
variant HAL.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>arch.inc</TT
|
>arch.inc</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
><architecture>.inc</TT
|
><architecture>.inc</TT
|
>. These files are
|
>. These files are
|
assembler headers used by <TT
|
assembler headers used by <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>vectors.S</TT
|
>vectors.S</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>context.S</TT
|
>context.S</TT
|
>.
|
>.
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
><architecture>.inc</TT
|
><architecture>.inc</TT
|
> is a general purpose
|
> is a general purpose
|
header that should contain things like register aliases, ABI
|
header that should contain things like register aliases, ABI
|
definitions and macros useful to general assembly
|
definitions and macros useful to general assembly
|
code. If there are no such definitions, then this file need not be
|
code. If there are no such definitions, then this file need not be
|
provided. <TT
|
provided. <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>arch.inc</TT
|
>arch.inc</TT
|
> contains macros for performing
|
> contains macros for performing
|
various eCos related operations such as initializing the CPU, caches,
|
various eCos related operations such as initializing the CPU, caches,
|
FPU etc. The definitions here may often be configured or overridden by
|
FPU etc. The definitions here may often be configured or overridden by
|
definitions in the variant or platform HALs. See the MIPS HAL for an
|
definitions in the variant or platform HALs. See the MIPS HAL for an
|
example of this.</P
|
example of this.</P
|
></LI
|
></LI
|
></UL
|
></UL
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Write <TT
|
>Write <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>vectors.S</TT
|
>vectors.S</TT
|
>. This is the most important file
|
>. This is the most important file
|
in the HAL. It contains the CPU initialization code, exception and
|
in the HAL. It contains the CPU initialization code, exception and
|
interrupt handlers. While other HALs should be consulted for
|
interrupt handlers. While other HALs should be consulted for
|
structures and techniques, there is very little here that can be
|
structures and techniques, there is very little here that can be
|
copied over without major edits.</P
|
copied over without major edits.</P
|
><P
|
><P
|
>The main pieces of code that need to be defined here are:</P
|
>The main pieces of code that need to be defined here are:</P
|
><P
|
><P
|
></P
|
></P
|
><UL
|
><UL
|
><LI
|
><LI
|
><P
|
><P
|
>Reset vector. This usually need to be positioned at the start of the
|
>Reset vector. This usually need to be positioned at the start of the
|
ROM or FLASH, so should be in a linker section of its own. It can then be
|
ROM or FLASH, so should be in a linker section of its own. It can then be
|
placed correctly by the linker script. Normally this code is little
|
placed correctly by the linker script. Normally this code is little
|
more than a jump to the label <TT
|
more than a jump to the label <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>_start</TT
|
>_start</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Exception vectors. These are the trampoline routines connected to the
|
>Exception vectors. These are the trampoline routines connected to the
|
hardware exception entry points that vector through the VSR table. In
|
hardware exception entry points that vector through the VSR table. In
|
many architectures these are adjacent to the reset vector, and should
|
many architectures these are adjacent to the reset vector, and should
|
occupy the same linker section. If the architecture allow the vectors
|
occupy the same linker section. If the architecture allow the vectors
|
to be moved then it may be necessary for these trampolines to be
|
to be moved then it may be necessary for these trampolines to be
|
position independent so they can be relocated at runtime.</P
|
position independent so they can be relocated at runtime.</P
|
><P
|
><P
|
>The trampolines should do the minimum necessary to transfer control
|
>The trampolines should do the minimum necessary to transfer control
|
from the hardware vector to the VSR pointed to by the matching table
|
from the hardware vector to the VSR pointed to by the matching table
|
entry. Exactly how this is done depends on the architecture. Usually
|
entry. Exactly how this is done depends on the architecture. Usually
|
the trampoline needs to get some working registers by either saving
|
the trampoline needs to get some working registers by either saving
|
them to CPU special registers (e.g. PowerPC SPRs), using reserved
|
them to CPU special registers (e.g. PowerPC SPRs), using reserved
|
general registers (MIPS K0 and K1), using only memory based
|
general registers (MIPS K0 and K1), using only memory based
|
operations (IA32), or just jumping directly (ARM). The VSR table index
|
operations (IA32), or just jumping directly (ARM). The VSR table index
|
to be used is either implicit in the entry point taken (PowerPC, IA32,
|
to be used is either implicit in the entry point taken (PowerPC, IA32,
|
ARM), or must be determined from a CPU register (MIPS).</P
|
ARM), or must be determined from a CPU register (MIPS).</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Write kernel startup code. This is the location the reset vector jumps
|
>Write kernel startup code. This is the location the reset vector jumps
|
to, and can be in the main text section of the executable, rather than
|
to, and can be in the main text section of the executable, rather than
|
a special section. The code here should first initialize the CPU and other
|
a special section. The code here should first initialize the CPU and other
|
hardware subsystems. The best approach is to use a set of macro
|
hardware subsystems. The best approach is to use a set of macro
|
calls that are defined either in <TT
|
calls that are defined either in <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>arch.inc</TT
|
>arch.inc</TT
|
> or
|
> or
|
overridden in the variant or platform HALs. Other jobs that this code
|
overridden in the variant or platform HALs. Other jobs that this code
|
should do are: initialize stack pointer; copy the data section from
|
should do are: initialize stack pointer; copy the data section from
|
ROM to RAM if necessary; zero the BSS; call variant and platform
|
ROM to RAM if necessary; zero the BSS; call variant and platform
|
initializers; call <TT
|
initializers; call <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>cyg_hal_invoke_constructors()</TT
|
>cyg_hal_invoke_constructors()</TT
|
>;
|
>;
|
call <TT
|
call <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>initialize_stub()</TT
|
>initialize_stub()</TT
|
> if necessary. Finally it
|
> if necessary. Finally it
|
should call <TT
|
should call <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>cyg_start()</TT
|
>cyg_start()</TT
|
>. See <A
|
>. See <A
|
HREF="hal-exception-handling.html#HAL-STARTUP"
|
HREF="hal-exception-handling.html#HAL-STARTUP"
|
>the Section called <I
|
>the Section called <I
|
>HAL Startup</I
|
>HAL Startup</I
|
> in Chapter 10</A
|
> in Chapter 10</A
|
> for details.</P
|
> for details.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Write the default exception VSR. This VSR is installed in the VSR
|
>Write the default exception VSR. This VSR is installed in the VSR
|
table for all synchronous exception vectors. See <A
|
table for all synchronous exception vectors. See <A
|
HREF="hal-default-synchronous-exception-handling.html"
|
HREF="hal-default-synchronous-exception-handling.html"
|
>the Section called <I
|
>the Section called <I
|
>Default Synchronous Exception Handling</I
|
>Default Synchronous Exception Handling</I
|
> in Chapter 10</A
|
> in Chapter 10</A
|
> for details of
|
> for details of
|
what this VSR does.</P
|
what this VSR does.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Write the default interrupt VSR. This is installed in all VSR table
|
>Write the default interrupt VSR. This is installed in all VSR table
|
entries that correspond to external interrupts. See <A
|
entries that correspond to external interrupts. See <A
|
HREF="hal-default-synchronous-exception-handling.html"
|
HREF="hal-default-synchronous-exception-handling.html"
|
>the Section called <I
|
>the Section called <I
|
>Default Synchronous Exception Handling</I
|
>Default Synchronous Exception Handling</I
|
> in Chapter 10</A
|
> in Chapter 10</A
|
> for details of
|
> for details of
|
what this VSR does.</P
|
what this VSR does.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Write
|
>Write
|
<TT
|
<TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_interrupt_stack_call_pending_dsrs()</TT
|
>hal_interrupt_stack_call_pending_dsrs()</TT
|
>. If this
|
>. If this
|
function is defined in <TT
|
function is defined in <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_arch.h</TT
|
>hal_arch.h</TT
|
> then it should
|
> then it should
|
appear here. The purpose of this function is to call DSRs on the
|
appear here. The purpose of this function is to call DSRs on the
|
interrupt stack rather than the current thread's stack. This is not an
|
interrupt stack rather than the current thread's stack. This is not an
|
essential feature, and may be left until later. However it interacts
|
essential feature, and may be left until later. However it interacts
|
with the stack switching that goes on in the interrupt VSR, so it may
|
with the stack switching that goes on in the interrupt VSR, so it may
|
make sense to write these pieces of code at the same time to ensure
|
make sense to write these pieces of code at the same time to ensure
|
consistency.</P
|
consistency.</P
|
><P
|
><P
|
>When this function is implemented it should do the following:</P
|
>When this function is implemented it should do the following:</P
|
><P
|
><P
|
></P
|
></P
|
><UL
|
><UL
|
><LI
|
><LI
|
><P
|
><P
|
>Take a copy of the current SP and then switch to the interrupt stack.</P
|
>Take a copy of the current SP and then switch to the interrupt stack.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Save the old SP, together with the CPU status register (or whatever
|
>Save the old SP, together with the CPU status register (or whatever
|
register contains the interrupt enable status) and any other
|
register contains the interrupt enable status) and any other
|
registers that may be corrupted by a function call (such as any link
|
registers that may be corrupted by a function call (such as any link
|
register) to locations in the interrupt stack.</P
|
register) to locations in the interrupt stack.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Enable interrupts.</P
|
>Enable interrupts.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Call <TT
|
>Call <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>cyg_interrupt_call_pending_DSRs()</TT
|
>cyg_interrupt_call_pending_DSRs()</TT
|
>. This is a
|
>. This is a
|
kernel functions that actually calls any pending DSRs.</P
|
kernel functions that actually calls any pending DSRs.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Retrieve saved registers from the interrupt stack and switch back to
|
>Retrieve saved registers from the interrupt stack and switch back to
|
the current thread stack.</P
|
the current thread stack.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Merge the interrupt enable state recorded in the save CPU status
|
>Merge the interrupt enable state recorded in the save CPU status
|
register with the current value of the status register to restore the
|
register with the current value of the status register to restore the
|
previous enable state. If the status register does not contain any
|
previous enable state. If the status register does not contain any
|
other persistent state then this can be a simple restore of the
|
other persistent state then this can be a simple restore of the
|
register. However if the register contains other state bits that might
|
register. However if the register contains other state bits that might
|
have been changed by a DSR, then care must be taken not to disturb
|
have been changed by a DSR, then care must be taken not to disturb
|
these.</P
|
these.</P
|
></LI
|
></LI
|
></UL
|
></UL
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Define any data items needed. Typically <TT
|
>Define any data items needed. Typically <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>vectors.S</TT
|
>vectors.S</TT
|
>
|
>
|
may contain definitions for the VSR table, the interrupt tables and the
|
may contain definitions for the VSR table, the interrupt tables and the
|
interrupt stack. Sometimes these are only default definitions that may
|
interrupt stack. Sometimes these are only default definitions that may
|
be overridden by the variant or platform HALs.</P
|
be overridden by the variant or platform HALs.</P
|
></LI
|
></LI
|
></UL
|
></UL
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Write <TT
|
>Write <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>context.S</TT
|
>context.S</TT
|
>. This file contains the context
|
>. This file contains the context
|
switch code. See <A
|
switch code. See <A
|
HREF="hal-architecture-characterization.html#HAL-CONTEXT-SWITCH"
|
HREF="hal-architecture-characterization.html#HAL-CONTEXT-SWITCH"
|
>the Section called <I
|
>the Section called <I
|
>Thread Context Switching</I
|
>Thread Context Switching</I
|
> in Chapter 9</A
|
> in Chapter 9</A
|
> for details of
|
> for details of
|
how these functions operate. This file may also contain the
|
how these functions operate. This file may also contain the
|
implementation of <TT
|
implementation of <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_setjmp()</TT
|
>hal_setjmp()</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_longjmp()</TT
|
>hal_longjmp()</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Write <TT
|
>Write <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_misc.c</TT
|
>hal_misc.c</TT
|
>. This file contains any C
|
>. This file contains any C
|
data and functions needed by the HAL. These might include:</P
|
data and functions needed by the HAL. These might include:</P
|
><P
|
><P
|
></P
|
></P
|
><UL
|
><UL
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>hal_interrupt_*[]</TT
|
>hal_interrupt_*[]</TT
|
>. In some HALs, if these arrays
|
>. In some HALs, if these arrays
|
are not defined in <TT
|
are not defined in <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>vectors.S</TT
|
>vectors.S</TT
|
> then they must be
|
> then they must be
|
defined here.</P
|
defined here.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>cyg_hal_exception_handler()</TT
|
>cyg_hal_exception_handler()</TT
|
>. This function is
|
>. This function is
|
called from the exception VSR. It usually does extra decoding of the
|
called from the exception VSR. It usually does extra decoding of the
|
exception and invokes any special handlers for things like FPU traps,
|
exception and invokes any special handlers for things like FPU traps,
|
bus errors or memory exceptions. If there is nothing special to be
|
bus errors or memory exceptions. If there is nothing special to be
|
done for an exception, then it either calls into the GDB stubs, by
|
done for an exception, then it either calls into the GDB stubs, by
|
calling <TT
|
calling <TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>__handle_exception()</TT
|
>__handle_exception()</TT
|
>, or
|
>, or
|
invokes the kernel by calling
|
invokes the kernel by calling
|
<TT
|
<TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>cyg_hal_deliver_exception()</TT
|
>cyg_hal_deliver_exception()</TT
|
>.</P
|
>.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_arch_default_isr()</TT
|
>hal_arch_default_isr()</TT
|
>. The
|
>. The
|
<TT
|
<TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>hal_interrupt_handlers[]</TT
|
>hal_interrupt_handlers[]</TT
|
> array is usually
|
> array is usually
|
initialized with pointers to <TT
|
initialized with pointers to <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_default_isr()</TT
|
>hal_default_isr()</TT
|
>,
|
>,
|
which is defined in the common HAL. This function handles things like
|
which is defined in the common HAL. This function handles things like
|
Ctrl-C processing, but if that is not relevant, then it will call
|
Ctrl-C processing, but if that is not relevant, then it will call
|
<TT
|
<TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_arch_default_isr()</TT
|
>hal_arch_default_isr()</TT
|
>. Normally this function
|
>. Normally this function
|
should just return zero.</P
|
should just return zero.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>cyg_hal_invoke_constructors()</TT
|
>cyg_hal_invoke_constructors()</TT
|
>. This calls the
|
>. This calls the
|
constructors for all static objects before the program starts. eCos
|
constructors for all static objects before the program starts. eCos
|
relies on these being called in the correct order for it to function
|
relies on these being called in the correct order for it to function
|
correctly. The exact way in which constructors are handled may differ
|
correctly. The exact way in which constructors are handled may differ
|
between architectures, although most use a simple table of function
|
between architectures, although most use a simple table of function
|
pointers between labels <TT
|
pointers between labels <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>__CTOR_LIST__</TT
|
>__CTOR_LIST__</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>__CTOR_END__</TT
|
>__CTOR_END__</TT
|
> which must called in order from the
|
> which must called in order from the
|
top down. Generally, this function can be copied directly from an
|
top down. Generally, this function can be copied directly from an
|
existing architecture HAL.</P
|
existing architecture HAL.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Bit indexing functions. If the macros
|
>Bit indexing functions. If the macros
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_LSBIT_INDEX()</TT
|
>HAL_LSBIT_INDEX()</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_MSBIT_INDEX()</TT
|
>HAL_MSBIT_INDEX()</TT
|
> are defined as function calls,
|
> are defined as function calls,
|
then the functions should appear here. The main reason for doing this
|
then the functions should appear here. The main reason for doing this
|
is that the architecture does not have support for bit indexing and
|
is that the architecture does not have support for bit indexing and
|
these functions must provide the functionality by conventional
|
these functions must provide the functionality by conventional
|
means. While the trivial implementation is a simple for loop, it is
|
means. While the trivial implementation is a simple for loop, it is
|
expensive and non-deterministic. Better, constant time,
|
expensive and non-deterministic. Better, constant time,
|
implementations can be found in several HALs (MIPS for example).</P
|
implementations can be found in several HALs (MIPS for example).</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_delay_us()</TT
|
>hal_delay_us()</TT
|
>. If the macro
|
>. If the macro
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_DELAY_US()</TT
|
>HAL_DELAY_US()</TT
|
> is defined in <TT
|
> is defined in <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>hal_intr.h</TT
|
>hal_intr.h</TT
|
> then it should be defined to
|
> then it should be defined to
|
call this function. While most of the time this function is called
|
call this function. While most of the time this function is called
|
with very small values, occasionally (particularly in some ethernet
|
with very small values, occasionally (particularly in some ethernet
|
drivers) it is called with values of several seconds. Hence the
|
drivers) it is called with values of several seconds. Hence the
|
function should take care to avoid overflow in any calculations.</P
|
function should take care to avoid overflow in any calculations.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_idle_thread_action()</TT
|
>hal_idle_thread_action()</TT
|
>. This function is called
|
>. This function is called
|
from the idle thread via the
|
from the idle thread via the
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>HAL_IDLE_THREAD_ACTION()</TT
|
>HAL_IDLE_THREAD_ACTION()</TT
|
> macro, if so
|
> macro, if so
|
defined. While normally this function does nothing, during development
|
defined. While normally this function does nothing, during development
|
this is often a good place to report various important system
|
this is often a good place to report various important system
|
parameters on LCDs, LED or other displays. This function can also
|
parameters on LCDs, LED or other displays. This function can also
|
monitor system state and report any anomalies. If the architecture
|
monitor system state and report any anomalies. If the architecture
|
supports a <TT
|
supports a <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>halt</TT
|
>halt</TT
|
> instruction then this is a good
|
> instruction then this is a good
|
place to put an inline assembly fragment to execute it. It is also a
|
place to put an inline assembly fragment to execute it. It is also a
|
good place to handle any power saving activity.</P
|
good place to handle any power saving activity.</P
|
></LI
|
></LI
|
></UL
|
></UL
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>Create the <TT
|
>Create the <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
><architecture>.ld</TT
|
><architecture>.ld</TT
|
> file. While
|
> file. While
|
this file may need to be moved to the variant HAL in the future, it
|
this file may need to be moved to the variant HAL in the future, it
|
should initially be defined here, and only moved if necessary.</P
|
should initially be defined here, and only moved if necessary.</P
|
><P
|
><P
|
>This file defines a set of macros that are used by the platform
|
>This file defines a set of macros that are used by the platform
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>.ldi</TT
|
>.ldi</TT
|
> files to generate linker scripts. Most GCC
|
> files to generate linker scripts. Most GCC
|
toolchains are very similar so the correct approach is to copy the
|
toolchains are very similar so the correct approach is to copy the
|
file from an existing architecture and edit it. The main things that
|
file from an existing architecture and edit it. The main things that
|
will need editing are the <TT
|
will need editing are the <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>OUTPUT_FORMAT()</TT
|
>OUTPUT_FORMAT()</TT
|
> directive
|
> directive
|
and maybe the creation or allocation of extra sections to various
|
and maybe the creation or allocation of extra sections to various
|
macros. Running the target linker with just the
|
macros. Running the target linker with just the
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>--verbose</TT
|
>--verbose</TT
|
> argument will cause it to output its
|
> argument will cause it to output its
|
default linker script. This can be compared with the
|
default linker script. This can be compared with the
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>.ld</TT
|
>.ld</TT
|
> file and appropriate edits made.</P
|
> file and appropriate edits made.</P
|
></LI
|
></LI
|
><LI
|
><LI
|
><P
|
><P
|
>If GDB stubs are to be supported in RedBoot or eCos, then support must
|
>If GDB stubs are to be supported in RedBoot or eCos, then support must
|
be included for these. The most important of these are <TT
|
be included for these. The most important of these are <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>include/<architecture>-stub.h</TT
|
>include/<architecture>-stub.h</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>src/<architecture>-stub.c</TT
|
>src/<architecture>-stub.c</TT
|
>. In all existing
|
>. In all existing
|
architecture HALs these files, and any support files they need, have
|
architecture HALs these files, and any support files they need, have
|
been derived from files supplied in <TT
|
been derived from files supplied in <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>libgloss</TT
|
>libgloss</TT
|
>, as
|
>, as
|
part of the GDB toolchain package. If this is a totally new
|
part of the GDB toolchain package. If this is a totally new
|
architecture, this may not have been done, and they must be created
|
architecture, this may not have been done, and they must be created
|
from scratch.</P
|
from scratch.</P
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>include/<architecture>-stub.h</TT
|
>include/<architecture>-stub.h</TT
|
>
|
>
|
contains definitions that are used by the GDB stubs to describe the
|
contains definitions that are used by the GDB stubs to describe the
|
size, type, number and names of CPU registers. This information is
|
size, type, number and names of CPU registers. This information is
|
usually found in the GDB support files for the architecture. It also
|
usually found in the GDB support files for the architecture. It also
|
contains prototypes for the functions exported by
|
contains prototypes for the functions exported by
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>src/<architecture>-stub.c</TT
|
>src/<architecture>-stub.c</TT
|
>; however, since
|
>; however, since
|
this is common to all architectures, it can be copied from some other
|
this is common to all architectures, it can be copied from some other
|
HAL.</P
|
HAL.</P
|
><P
|
><P
|
><TT
|
><TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>src/<architecture>-stub.c</TT
|
>src/<architecture>-stub.c</TT
|
> implements the
|
> implements the
|
functions exported by the header. Most of this is fairly straight
|
functions exported by the header. Most of this is fairly straight
|
forward: the implementation in existing HALs should show exactly what
|
forward: the implementation in existing HALs should show exactly what
|
needs to be done. The only complex part is the support for
|
needs to be done. The only complex part is the support for
|
single-stepping. This is used a lot by GDB, so it cannot be
|
single-stepping. This is used a lot by GDB, so it cannot be
|
avoided. If the architecture has support for a trace or single-step
|
avoided. If the architecture has support for a trace or single-step
|
trap then that can be used for this purpose. If it does not then this
|
trap then that can be used for this purpose. If it does not then this
|
must be simulated by planting a breakpoint in the next
|
must be simulated by planting a breakpoint in the next
|
instruction. This can be quite involved since it requires some
|
instruction. This can be quite involved since it requires some
|
analysis of the current instruction plus the state of the CPU to
|
analysis of the current instruction plus the state of the CPU to
|
determine where execution is going to go next.</P
|
determine where execution is going to go next.</P
|
></LI
|
></LI
|
></OL
|
></OL
|
></DIV
|
></DIV
|
><DIV
|
><DIV
|
CLASS="SECTION"
|
CLASS="SECTION"
|
><H2
|
><H2
|
CLASS="SECTION"
|
CLASS="SECTION"
|
><A
|
><A
|
NAME="HAL-PORTING-ARCHITECTURE-CDL">CDL Requirements</H2
|
NAME="HAL-PORTING-ARCHITECTURE-CDL">CDL Requirements</H2
|
><P
|
><P
|
>The CDL needed for any particular architecture HAL depends to a large
|
>The CDL needed for any particular architecture HAL depends to a large
|
extent on the needs of that architecture. This includes issues such as
|
extent on the needs of that architecture. This includes issues such as
|
support for different variants, use of FPUs, MMUs and caches. The
|
support for different variants, use of FPUs, MMUs and caches. The
|
exact split between the architecture, variant and platform HALs for
|
exact split between the architecture, variant and platform HALs for
|
various features is also somewhat fluid. </P
|
various features is also somewhat fluid. </P
|
><P
|
><P
|
>To give a rough idea about how the CDL for an architecture is
|
>To give a rough idea about how the CDL for an architecture is
|
structured, we will take as an example the I386 CDL.</P
|
structured, we will take as an example the I386 CDL.</P
|
><P
|
><P
|
>This first section introduces the CDL package and placed it under the
|
>This first section introduces the CDL package and placed it under the
|
main HAL package. Include files from this package will be put in the
|
main HAL package. Include files from this package will be put in the
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>include/cyg/hal</TT
|
>include/cyg/hal</TT
|
> directory, and definitions from
|
> directory, and definitions from
|
this file will be placed in
|
this file will be placed in
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>include/pkgconf/hal_i386.h</TT
|
>include/pkgconf/hal_i386.h</TT
|
>. The
|
>. The
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>compile</TT
|
>compile</TT
|
> line specifies the files in the
|
> line specifies the files in the
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>src</TT
|
>src</TT
|
> directory that are to be compiled as part of
|
> directory that are to be compiled as part of
|
this package.</P
|
this package.</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
>cdl_package CYGPKG_HAL_I386 {
|
>cdl_package CYGPKG_HAL_I386 {
|
display "i386 architecture"
|
display "i386 architecture"
|
parent CYGPKG_HAL
|
parent CYGPKG_HAL
|
hardware
|
hardware
|
include_dir cyg/hal
|
include_dir cyg/hal
|
define_header hal_i386.h
|
define_header hal_i386.h
|
description "
|
description "
|
The i386 architecture HAL package provides generic
|
The i386 architecture HAL package provides generic
|
support for this processor architecture. It is also
|
support for this processor architecture. It is also
|
necessary to select a specific target platform HAL
|
necessary to select a specific target platform HAL
|
package."
|
package."
|
|
|
compile hal_misc.c context.S i386_stub.c hal_syscall.c</PRE
|
compile hal_misc.c context.S i386_stub.c hal_syscall.c</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>Next we need to generate some files using non-standard make rules. The
|
>Next we need to generate some files using non-standard make rules. The
|
first is <TT
|
first is <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>vectors.S</TT
|
>vectors.S</TT
|
>, which is not put into the
|
>, which is not put into the
|
library, but linked explicitly with all applications. The second is
|
library, but linked explicitly with all applications. The second is
|
the generation of the <TT
|
the generation of the <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>target.ld</TT
|
>target.ld</TT
|
> file from
|
> file from
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>i386.ld</TT
|
>i386.ld</TT
|
> and the startup-selected
|
> and the startup-selected
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>.ldi</TT
|
>.ldi</TT
|
> file. Both of these are essentially
|
> file. Both of these are essentially
|
boilerplate code that can be copied and edited.</P
|
boilerplate code that can be copied and edited.</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
> make {
|
> make {
|
<PREFIX>/lib/vectors.o : <PACKAGE>/src/vectors.S
|
<PREFIX>/lib/vectors.o : <PACKAGE>/src/vectors.S
|
$(CC) -Wp,-MD,vectors.tmp $(INCLUDE_PATH) $(CFLAGS) -c -o $@ $<
|
$(CC) -Wp,-MD,vectors.tmp $(INCLUDE_PATH) $(CFLAGS) -c -o $@ $<
|
@echo $@ ": \\" > $(notdir $@).deps
|
@echo $@ ": \\" > $(notdir $@).deps
|
@tail +2 vectors.tmp >> $(notdir $@).deps
|
@tail +2 vectors.tmp >> $(notdir $@).deps
|
@echo >> $(notdir $@).deps
|
@echo >> $(notdir $@).deps
|
@rm vectors.tmp
|
@rm vectors.tmp
|
}
|
}
|
|
|
make {
|
make {
|
<PREFIX>/lib/target.ld: <PACKAGE>/src/i386.ld
|
<PREFIX>/lib/target.ld: <PACKAGE>/src/i386.ld
|
$(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $<
|
$(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $<
|
@echo $@ ": \\" > $(notdir $@).deps
|
@echo $@ ": \\" > $(notdir $@).deps
|
@tail +2 target.tmp >> $(notdir $@).deps
|
@tail +2 target.tmp >> $(notdir $@).deps
|
@echo >> $(notdir $@).deps
|
@echo >> $(notdir $@).deps
|
@rm target.tmp
|
@rm target.tmp
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>The i386 is currently the only architecture that supports SMP. The
|
>The i386 is currently the only architecture that supports SMP. The
|
following CDL simply enabled the HAL SMP support if
|
following CDL simply enabled the HAL SMP support if
|
required. Generally this will get enabled as a result of a
|
required. Generally this will get enabled as a result of a
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>requires</TT
|
>requires</TT
|
> statement in the kernel. The
|
> statement in the kernel. The
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>requires</TT
|
>requires</TT
|
> statement here turns off lazy FPU
|
> statement here turns off lazy FPU
|
switching in the FPU support code, since it is inconsistent with SMP
|
switching in the FPU support code, since it is inconsistent with SMP
|
operation.</P
|
operation.</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
> cdl_component CYGPKG_HAL_SMP_SUPPORT {
|
> cdl_component CYGPKG_HAL_SMP_SUPPORT {
|
display "SMP support"
|
display "SMP support"
|
default_value 0
|
default_value 0
|
requires { CYGHWR_HAL_I386_FPU_SWITCH_LAZY == 0 }
|
requires { CYGHWR_HAL_I386_FPU_SWITCH_LAZY == 0 }
|
|
|
cdl_option CYGPKG_HAL_SMP_CPU_MAX {
|
cdl_option CYGPKG_HAL_SMP_CPU_MAX {
|
display "Max number of CPUs supported"
|
display "Max number of CPUs supported"
|
flavor data
|
flavor data
|
default_value 2
|
default_value 2
|
}
|
}
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>The i386 HAL has optional FPU support, which is enabled by default. It
|
>The i386 HAL has optional FPU support, which is enabled by default. It
|
can be disabled to improve system performance. There are two FPU
|
can be disabled to improve system performance. There are two FPU
|
support options: either to save and restore the FPU state on every
|
support options: either to save and restore the FPU state on every
|
context switch, or to only switch the FPU state when necessary.</P
|
context switch, or to only switch the FPU state when necessary.</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
>
|
>
|
cdl_component CYGHWR_HAL_I386_FPU {
|
cdl_component CYGHWR_HAL_I386_FPU {
|
display "Enable I386 FPU support"
|
display "Enable I386 FPU support"
|
default_value 1
|
default_value 1
|
description "This component enables support for the
|
description "This component enables support for the
|
I386 floating point unit."
|
I386 floating point unit."
|
|
|
cdl_option CYGHWR_HAL_I386_FPU_SWITCH_LAZY {
|
cdl_option CYGHWR_HAL_I386_FPU_SWITCH_LAZY {
|
display "Use lazy FPU state switching"
|
display "Use lazy FPU state switching"
|
flavor bool
|
flavor bool
|
default_value 1
|
default_value 1
|
|
|
description "
|
description "
|
This option enables lazy FPU state switching.
|
This option enables lazy FPU state switching.
|
The default behaviour for eCos is to save and
|
The default behaviour for eCos is to save and
|
restore FPU state on every thread switch, interrupt
|
restore FPU state on every thread switch, interrupt
|
and exception. While simple and deterministic, this
|
and exception. While simple and deterministic, this
|
approach can be expensive if the FPU is not used by
|
approach can be expensive if the FPU is not used by
|
all threads. The alternative, enabled by this option,
|
all threads. The alternative, enabled by this option,
|
is to use hardware features that allow the FPU state
|
is to use hardware features that allow the FPU state
|
of a thread to be left in the FPU after it has been
|
of a thread to be left in the FPU after it has been
|
descheduled, and to allow the state to be switched to
|
descheduled, and to allow the state to be switched to
|
a new thread only if it actually uses the FPU. Where
|
a new thread only if it actually uses the FPU. Where
|
only one or two threads use the FPU this can avoid a
|
only one or two threads use the FPU this can avoid a
|
lot of unnecessary state switching."
|
lot of unnecessary state switching."
|
}
|
}
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>The i386 HAL also has support for different classes of CPU. In
|
>The i386 HAL also has support for different classes of CPU. In
|
particular, Pentium class CPUs have extra functional units, and some
|
particular, Pentium class CPUs have extra functional units, and some
|
variants of GDB expect more registers to be reported. These options
|
variants of GDB expect more registers to be reported. These options
|
enable these features. Generally these are enabled by
|
enable these features. Generally these are enabled by
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>requires</TT
|
>requires</TT
|
> statements in variant or platform
|
> statements in variant or platform
|
packages, or in <TT
|
packages, or in <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>.ecm</TT
|
>.ecm</TT
|
> files.</P
|
> files.</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
> cdl_component CYGHWR_HAL_I386_PENTIUM {
|
> cdl_component CYGHWR_HAL_I386_PENTIUM {
|
display "Enable Pentium class CPU features"
|
display "Enable Pentium class CPU features"
|
default_value 0
|
default_value 0
|
description "This component enables support for various
|
description "This component enables support for various
|
features of Pentium class CPUs."
|
features of Pentium class CPUs."
|
|
|
cdl_option CYGHWR_HAL_I386_PENTIUM_SSE {
|
cdl_option CYGHWR_HAL_I386_PENTIUM_SSE {
|
display "Save/Restore SSE registers on context switch"
|
display "Save/Restore SSE registers on context switch"
|
flavor bool
|
flavor bool
|
default_value 0
|
default_value 0
|
|
|
description "
|
description "
|
This option enables SSE state switching. The default
|
This option enables SSE state switching. The default
|
behaviour for eCos is to ignore the SSE registers.
|
behaviour for eCos is to ignore the SSE registers.
|
Enabling this option adds SSE state information to
|
Enabling this option adds SSE state information to
|
every thread context."
|
every thread context."
|
}
|
}
|
|
|
cdl_option CYGHWR_HAL_I386_PENTIUM_GDB_REGS {
|
cdl_option CYGHWR_HAL_I386_PENTIUM_GDB_REGS {
|
display "Support extra Pentium registers in GDB stub"
|
display "Support extra Pentium registers in GDB stub"
|
flavor bool
|
flavor bool
|
default_value 0
|
default_value 0
|
|
|
description "
|
description "
|
This option enables support for extra Pentium registers
|
This option enables support for extra Pentium registers
|
in the GDB stub. These are registers such as CR0-CR4, and
|
in the GDB stub. These are registers such as CR0-CR4, and
|
all MSRs. Not all GDBs support these registers, so the
|
all MSRs. Not all GDBs support these registers, so the
|
default behaviour for eCos is to not include them in the
|
default behaviour for eCos is to not include them in the
|
GDB stub support code."
|
GDB stub support code."
|
}
|
}
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>In the i386 HALs, the linker script is provided by the architecture
|
>In the i386 HALs, the linker script is provided by the architecture
|
HAL. In other HALs, for example MIPS, it is provided in the variant
|
HAL. In other HALs, for example MIPS, it is provided in the variant
|
HAL. The following option provides the name of the linker script to
|
HAL. The following option provides the name of the linker script to
|
other elements in the configuration system.</P
|
other elements in the configuration system.</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
> cdl_option CYGBLD_LINKER_SCRIPT {
|
> cdl_option CYGBLD_LINKER_SCRIPT {
|
display "Linker script"
|
display "Linker script"
|
flavor data
|
flavor data
|
no_define
|
no_define
|
calculated { "src/i386.ld" }
|
calculated { "src/i386.ld" }
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>Finally, this interface indicates whether the platform supplied an
|
>Finally, this interface indicates whether the platform supplied an
|
implementation of the
|
implementation of the
|
<TT
|
<TT
|
CLASS="FUNCTION"
|
CLASS="FUNCTION"
|
>hal_i386_mem_real_region_top()</TT
|
>hal_i386_mem_real_region_top()</TT
|
> function. If it
|
> function. If it
|
does then it will contain a line of the form: <TT
|
does then it will contain a line of the form: <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>implements
|
>implements
|
CYGINT_HAL_I386_MEM_REAL_REGION_TOP</TT
|
CYGINT_HAL_I386_MEM_REAL_REGION_TOP</TT
|
>. This allows packages
|
>. This allows packages
|
such as RedBoot to detect the presence of this function so that they
|
such as RedBoot to detect the presence of this function so that they
|
may call it.</P
|
may call it.</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
> cdl_interface CYGINT_HAL_I386_MEM_REAL_REGION_TOP {
|
> cdl_interface CYGINT_HAL_I386_MEM_REAL_REGION_TOP {
|
display "Implementations of hal_i386_mem_real_region_top()"
|
display "Implementations of hal_i386_mem_real_region_top()"
|
}
|
}
|
|
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
></DIV
|
></DIV
|
></DIV
|
></DIV
|
><DIV
|
><DIV
|
CLASS="NAVFOOTER"
|
CLASS="NAVFOOTER"
|
><HR
|
><HR
|
ALIGN="LEFT"
|
ALIGN="LEFT"
|
WIDTH="100%"><TABLE
|
WIDTH="100%"><TABLE
|
SUMMARY="Footer navigation table"
|
SUMMARY="Footer navigation table"
|
WIDTH="100%"
|
WIDTH="100%"
|
BORDER="0"
|
BORDER="0"
|
CELLPADDING="0"
|
CELLPADDING="0"
|
CELLSPACING="0"
|
CELLSPACING="0"
|
><TR
|
><TR
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="left"
|
ALIGN="left"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="hal-porting-variant.html"
|
HREF="hal-porting-variant.html"
|
ACCESSKEY="P"
|
ACCESSKEY="P"
|
>Prev</A
|
>Prev</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="34%"
|
WIDTH="34%"
|
ALIGN="center"
|
ALIGN="center"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="ecos-ref.html"
|
HREF="ecos-ref.html"
|
ACCESSKEY="H"
|
ACCESSKEY="H"
|
>Home</A
|
>Home</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="right"
|
ALIGN="right"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="hal-future-developments.html"
|
HREF="hal-future-developments.html"
|
ACCESSKEY="N"
|
ACCESSKEY="N"
|
>Next</A
|
>Next</A
|
></TD
|
></TD
|
></TR
|
></TR
|
><TR
|
><TR
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="left"
|
ALIGN="left"
|
VALIGN="top"
|
VALIGN="top"
|
>Variant HAL Porting</TD
|
>Variant HAL Porting</TD
|
><TD
|
><TD
|
WIDTH="34%"
|
WIDTH="34%"
|
ALIGN="center"
|
ALIGN="center"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="hal-porting-guide.html"
|
HREF="hal-porting-guide.html"
|
ACCESSKEY="U"
|
ACCESSKEY="U"
|
>Up</A
|
>Up</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="right"
|
ALIGN="right"
|
VALIGN="top"
|
VALIGN="top"
|
>Future developments</TD
|
>Future developments</TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
></DIV
|
></DIV
|
></BODY
|
></BODY
|
></HTML
|
></HTML
|
|
|