📄 hal-porting-architecture.html
字号:
<!-- Copyright (C) 2003 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/). -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission is obtained from the copyright holder. -->
<HTML
><HEAD
><TITLE
>Architecture HAL Porting</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="eCos Reference Manual"
HREF="ecos-ref.html"><LINK
REL="UP"
TITLE=" Porting Guide"
HREF="hal-porting-guide.html"><LINK
REL="PREVIOUS"
TITLE="Variant HAL Porting"
HREF="hal-porting-variant.html"><LINK
REL="NEXT"
TITLE="Future developments"
HREF="hal-future-developments.html"></HEAD
><BODY
CLASS="SECTION"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>eCos Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="hal-porting-variant.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 11. Porting Guide</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="hal-future-developments.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="HAL-PORTING-ARCHITECTURE">Architecture HAL Porting</H1
><P
>A new architecture HAL is the most complex HAL to write, and it the
least easily described. Hence this section is presently nothing more
than a place holder for the future.</P
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9792">HAL Architecture Porting Process</H2
><P
>The easiest way to make a new architecture HAL is simply to copy an
existing architecture HAL of an, if possible, closely matching
architecture and change all the files to match the new
architecture. The MIPS architecture HAL should be used if possible, as
it has the appropriate layout and coding conventions. Other HALs
may deviate from that norm in various ways.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
> eCos is written for GCC. It requires C and C++
compiler support as well as a few compiler features introduced during
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
CPUs. Before you can undertake an eCos port, you need the required
compiler support.</P
></BLOCKQUOTE
></DIV
><P
>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
vary greatly from architecture to architecture, so a lot of
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
initial target simultaneously.</P
><P
></P
><OL
TYPE="1"
><LI
><P
>Make a new directory for the new architecture under the
<TT
CLASS="FILENAME"
>hal</TT
> directory in the source repository. Make an
<TT
CLASS="FILENAME"
>arch</TT
> directory under this and populate this with
the standard set of package directories.</P
></LI
><LI
><P
>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
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
be a continuing process during the development of the HAL. See <A
HREF="hal-porting-architecture.html#HAL-PORTING-ARCHITECTURE-CDL"
>the Section called <I
>CDL Requirements</I
></A
> for more details.</P
></LI
><LI
><P
>Copy the <TT
CLASS="FILENAME"
>hal_arch.h</TT
> file from an example
HAL. Within this file you need to change or define the following:</P
><P
></P
><UL
><LI
><P
>Define the <SPAN
CLASS="STRUCTNAME"
>HAL_SavedRegisters</SPAN
> structure. This
may need to reflect the save order of any group register save/restore
instructions, the interrupt and exception save and restore formats,
and the procedure calling conventions. It may also need to cater for
optional FPUs and other functional units. It can be quite difficult to
develop a layout that copes with all requirements.</P
></LI
><LI
><P
>Define the bit manipulation routines,
<TT
CLASS="LITERAL"
>HAL_LSBIT_INDEX()</TT
> and
<TT
CLASS="LITERAL"
>HAL_MSBIT_INDEX()</TT
>. If the architecture contains
instructions to perform these, or related, operations, then these
should be defined as inline assembler fragments. Otherwise make them
calls to functions.</P
></LI
><LI
><P
>Define <TT
CLASS="LITERAL"
>HAL_THREAD_INIT_CONTEXT()</TT
>. This initializes
a restorable CPU context onto a stack pointer so that a later call to
<TT
CLASS="LITERAL"
>HAL_THREAD_LOAD_CONTEXT()</TT
> or
<TT
CLASS="LITERAL"
>HAL_THREAD_SWITCH_CONTEXT()</TT
> will execute it
correctly. This macro needs to take account of the same optional
features of the architecture as the definition of
<SPAN
CLASS="STRUCTNAME"
>HAL_SavedRegisters</SPAN
>.</P
></LI
><LI
><P
>Define <TT
CLASS="LITERAL"
>HAL_THREAD_LOAD_CONTEXT()</TT
> and
<TT
CLASS="LITERAL"
>HAL_THREAD_SWITCH_CONTEXT()</TT
>. These should just be
calls to functions in <TT
CLASS="FILENAME"
>context.S</TT
>.</P
></LI
><LI
><P
>Define <TT
CLASS="LITERAL"
>HAL_REORDER_BARRIER()</TT
>. This prevents code
being moved by the compiler and is necessary in some order-sensitive
code. This macro is actually defined identically in all architecture,
so it can just be copied.</P
></LI
><LI
><P
>Define breakpoint support. The macro
<TT
CLASS="LITERAL"
>HAL_BREAKPOINT(label)</TT
> needs to be an inline assembly
fragment that invokes a breakpoint. The breakpoint instruction should
be labeled with the <TT
CLASS="PARAMETER"
><I
>label</I
></TT
>
argument. <TT
CLASS="LITERAL"
>HAL_BREAKINST</TT
> and
<TT
CLASS="LITERAL"
>HAL_BREAKINST_SIZE</TT
> define the breakpoint
instruction for debugging purposes.</P
></LI
><LI
><P
>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
differ from the ordering defined in
<SPAN
CLASS="STRUCTNAME"
>HAL_SavedRegisters</SPAN
>. The macros
<TT
CLASS="LITERAL"
>HAL_GET_GDB_REGISTERS()</TT
> and
<TT
CLASS="LITERAL"
>HAL_SET_GDB_REGISTERS()</TT
> translate between the GDB
array and the <SPAN
CLASS="STRUCTNAME"
>HAL_SavedRegisters</SPAN
> structure.
The <TT
CLASS="LITERAL"
>HAL_THREAD_GET_SAVED_REGISTERS()</TT
> translates a
stack pointer saved by the context switch macros into a pointer to a
<SPAN
CLASS="STRUCTNAME"
>HAL_SavedRegisters</SPAN
> structure. Usually this is
a one-to-one translation, but this macro allows it to differ if
necessary.</P
></LI
><LI
><P
>Define long jump support. The type <SPAN
CLASS="TYPE"
>hal_jmp_buf</SPAN
> and the
functions <TT
CLASS="FUNCTION"
>hal_setjmp()</TT
> and
<TT
CLASS="LITERAL"
>hal_longjmp()</TT
> provide the underlying implementation
of the C library <TT
CLASS="FUNCTION"
>setjmp()</TT
> and
<TT
CLASS="FUNCTION"
>longjmp()</TT
>.</P
></LI
><LI
><P
>Define idle thread action. Generally the macro
<TT
CLASS="LITERAL"
>HAL_IDLE_THREAD_ACTION()</TT
> is defined to call a
function in <TT
CLASS="FILENAME"
>hal_misc.c</TT
>.</P
></LI
><LI
><P
>Define stack sizes. The macros
<TT
CLASS="LITERAL"
>CYGNUM_HAL_STACK_SIZE_MINIMUM</TT
> and
<TT
CLASS="LITERAL"
>CYGNUM_HAL_STACK_SIZE_TYPICAL</TT
> should be defined to
the minimum size for any thread stack and a reasonable default for
most threads respectively. It is usually best to construct these out
of component sizes for the CPU save state and procedure call stack
usage. These definitions should not use anything other than numerical
values since they can be used from assembly code in some HALs.</P
></LI
><LI
><P
>Define memory access macros. These macros provide translation between
cached and uncached and physical memory spaces. They usually consist
of masking out bits of the supplied address and ORing in alternative
address bits.</P
></LI
><LI
><P
>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.</P
></LI
></UL
></LI
><LI
><P
>Copy <TT
CLASS="FILENAME"
>hal_intr.h</TT
> from an example HAL. Within this
file you should change or define the following:</P
><P
></P
><UL
><LI
><P
>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 <TT
CLASS="LITERAL"
>CYGNUM_HAL_VECTOR_*</TT
> definitions. The size of the
VSR table also needs to be defined here.</P
></LI
><LI
><P
>Map any hardware exceptions to standard names. There is a group of
exception vector name of the form
<TT
CLASS="LITERAL"
>CYGNUM_HAL_EXCEPTION_*</TT
> 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 <TT
CLASS="LITERAL"
>CYGNUM_HAL_EXCEPTION_*</TT
>
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 <TT
CLASS="LITERAL"
>CYGNUM_HAL_EXCEPTION_*</TT
>
definitions may have the same value.</P
><P
>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).</P
></LI
><LI
><P
>Declare any static data used by the HAL to handle interrupts and
exceptions. This is usually three vectors for interrupts:
<TT
CLASS="LITERAL"
>hal_interrupt_handlers[]</TT
>,
<TT
CLASS="LITERAL"
>hal_interrupt_data[]</TT
> and
<TT
CLASS="LITERAL"
>hal_interrupt_objects[]</TT
>, which are sized according
to the interrupt vector definitions. In addition a definition for the
VSR table, <TT
CLASS="LITERAL"
>hal_vsr_table[]</TT
> should be made. These
vectors are normally defined in either <TT
CLASS="FILENAME"
>vectors.S</TT
>
or <TT
CLASS="FILENAME"
>hal_misc.c</TT
>.</P
></LI
><LI
><P
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -