📄 m68k-port.html
字号:
<!-- Copyright (C) 2009 Free Software Foundation, 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. -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>The HAL Port</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="eCos Reference Manual"
HREF="ecos-ref.html"><LINK
REL="UP"
TITLE="M68000 Architectural Support"
HREF="hal-m68k-arch.html"><LINK
REL="PREVIOUS"
TITLE="Configuration"
HREF="m68k-configuration.html"><LINK
REL="NEXT"
TITLE="Freescale MCFxxxx Variant Support"
HREF="hal-m68k-mcfxxxx.html"></HEAD
><BODY
CLASS="REFENTRY"
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="m68k-configuration.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="hal-m68k-mcfxxxx.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="M68K-PORT"
></A
>The HAL Port</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN18926"
></A
><H2
>Name</H2
>HAL Port -- Implementation Details</DIV
><DIV
CLASS="REFSECT1"
><A
NAME="M68K-PORT-DESCRIPTION"
></A
><H2
>Description</H2
><P
>This documentation explains how the eCos HAL specification has been
mapped onto M68K hardware, and should be read in conjunction with
that specification. It also describes how variant, processor and
platform HALs can modify the default behaviour.
</P
><P
>eCos support for any given target will involve either three or four
HAL packages: the architectural HAL, the platform HAL, the variant
HAL, and optionally a processor HAL. This package, the architectural
HAL, provides code and definitions that are applicable to all M68K
processors. The platform HAL provides support for one specific
board, for example an M5272C3 evaluation board, or possibly for a
number of almost-identical boards. The processor HAL, if present,
serves mainly to provide details of on-chip peripherals including the
interrupt controller. The variant HAL provides functionality that is
common to a group of processors, for example all MCFxxxx processors
have very similar UARTs and hence can share HAL diagnostic code.
There is no fixed specification of what should go into the variant HAL
versus the processor HAL. For simplicity the description below only
refers to variant HALs, but the work may actually happen in a
processor HAL instead.
</P
><P
>As a design goal lower-level HALs can always override functionality
that is normally provided higher up. For example the architectural HAL
will provide the required eCos <CODE
CLASS="FUNCTION"
>HAL_LSBIT_INDEX</CODE
>
and <CODE
CLASS="FUNCTION"
>HAL_MSBIT_INDEX</CODE
> macros, but these can be
provided lower down instead. Many but not all ColdFire processors have
the <TT
CLASS="LITERAL"
>ff1</TT
> and <TT
CLASS="LITERAL"
>bitrev</TT
> instructions
which allow for a more efficient implementation than the default
architectural ones. In some areas such as handling context switching
the architectural HAL will usually provide the basic functionality but
it may be extended by lower HALs, for example to add support for the
multiply-accumulate units present in certain ColdFire processors.
</P
><P
>The architectural HAL provides header files <TT
CLASS="FILENAME"
>cyg/hal/hal_arch.h</TT
>, <TT
CLASS="FILENAME"
>cyg/hal/hal_intr.h</TT
>, <TT
CLASS="FILENAME"
>cyg/hal/hal_cache.h</TT
>, <TT
CLASS="FILENAME"
>cyg/hal/hal_io.h</TT
> and <TT
CLASS="FILENAME"
>cyg/hal/arch.inc</TT
>. These automatically
include an equivalent header file from the variant HAL, for example
<TT
CLASS="FILENAME"
>cyg/hal/var_arch.h</TT
>. The
variant HAL header will in turn include processor and
platform-specific headers. This means that application developers and
other packages can simply include the architectural HAL headers
without needing to know about variants or platforms. It also allows
the variant and platform HALs to override architectural settings.
</P
><P
>The port assumes that eCos and application code always runs in
supervisor mode, with full access to all hardware and special
registers.
</P
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-TYPES"
></A
><H3
>Data Types</H3
><P
>For eCos purposes all M68K processors are big-endian and 32-bit, so
the default data types in <TT
CLASS="FILENAME"
>cyg/infra/cyg_type.h</TT
> are used. Some
variants have external bus widths less than 32-bit, but this does not
affect the architectural HAL.
</P
><P
>When porting to another variant it is possible to override some or all
of the type definitions. The variant HAL needs to implement the CDL
interface <CODE
CLASS="VARNAME"
>CYGINT_HAL_M68K_VARIANT_TYPES</CODE
> and provide
a header file <TT
CLASS="FILENAME"
>cyg/hal/var_basetype.h</TT
>.
</P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-STARTUP"
></A
><H3
>Startup and Exception Vectors</H3
><P
>The conventional bootstrap mechanism involves a table of exception
vectors at the base of memory. The first two words of this table give
the initial program counter and stack pointer. In a typical embedded
system the hardware is arranged such that non-volatile flash memory is
found at location 0x0 so it is the start of flash that contains the
exception vectors and the boot code. The table of exception vectors is
used subsequently for interrupt handling and for hardware exceptions
such as attempts to execute an illegal instruction. There are a number
of common scenarios:
</P
><P
></P
><OL
TYPE="1"
><LI
><P
>On systems with very limited memory flash may remain mapped at
location 0 and the table of exception vectors remains mapped there as
well. The M68K architecture defines the table to have 256 entries and
hence it occupies 1K of memory, but in reality many of the entries are
unused so part of the table may get used for code instead. Since the
whole exception vector table is in read-only memory parts of the eCos
interrupt and exception handling mechanisms have to be statically
initialized and macros like <CODE
CLASS="FUNCTION"
>HAL_VSR_SET</CODE
> are not
available.
</P
></LI
><LI
><P
>As a minor variation of the previous case, flash remains at location 0
but the table of exception vectors gets remapped elsewhere in the
address space, usually RAM. This allows
<CODE
CLASS="FUNCTION"
>HAL_VSR_SET</CODE
> to operate normally but at the cost
of increased memory usage. The exception vector table in flash only
contains two entries, for the initial program counter and stack
pointer. The exception vector table in RAM typically gets initialized
at run-time.
</P
></LI
><LI
><P
>On systems with more memory it is conventional to rearrange the
address map during bootstrap. The flash gets relocated, typically to
near the end of the address space, and RAM gets placed at location 0
instead. The exception vector table stays at location 0 but is now in
RAM and gets initialized at run-time. The bootstrap exception vector
table in flash again only needs two entries. A variation places the
RAM elsewhere in the address space and moves the exception vector
table there, leaving location 0 unused. This provides some protection
against null pointer accesses in errant code.
</P
><P
>As a further complication, larger systems typically support different
startup types. The application can be linked against a ROM startup
configuration and placed directly in flash, as before. Alternatively
there may be a ROM monitor such as RedBoot in the flash, taking care
of initial bootstrap. The user's application is linked against a RAM
startup configuration, loaded into RAM via the ROM monitor, and
debugged using functionality provided by the ROM monitor. Yet another
possibility involves a RAM startup application but it gets loaded and
run via a hardware debug technology such as BDM, and the ROM monitor
is either missing or not used.
</P
></LI
></OL
><P
>The exact hardware details, the various startup types, the steps
needed for low-level hardware initialization, and so on are not known
to the architectural HAL. Hence although the architectural HAL does
provide the basic framework for startup, much of the work is done via
macros provided by lower-level HAL packages and those macros are
likely to depend on various configuration options. Rather than try to
enumerate all the various combinations here it is better to look at
the actual code in <TT
CLASS="FILENAME"
>vectors.S</TT
> and in appropriate
variant, processor or platform HALs. <TT
CLASS="FILENAME"
>vectors.S</TT
> is
responsible for any low-level initialization that needs to happen.
This includes setting up a standard C environment with the stack
pointer set to the startup stack in working RAM, making sure all
statically initialized global variables have the correct values, and
that all uninitialized global variables are zeroed. Once the C
environment has been set up the code jumps to
<CODE
CLASS="FUNCTION"
>hal_m68k_c_startup</CODE
> in file
<TT
CLASS="FILENAME"
>hal_m68k.c</TT
> which completes the initialization and
jumps to the application entry point.
</P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-INTERRUPTS"
></A
><H3
>Interrupt Handling</H3
><P
>The M68K architecture reserves a 1K area of memory for 256 exception
vectors. These are used for internal and external interrupts,
exceptions, software traps, and special operations such as reset
handling. Some of the vectors have well-defined uses. However when it
comes to interrupt handling the details will depend on the processor
variant and on the platform, and the appropriate package documentation
should be consulted for full details. Most platforms will not use the
full set of 256 vectors, instead re-using some of this memory for
other purposes.
</P
><P
>By default the exception vectors are located at location 0, but some
variants allow the vectors to be located elsewhere. This is managed by
an M68K-specific macro <CODE
CLASS="VARNAME"
>CYG_HAL_VSR_TABLE</CODE
>. The
default value is 0, but a variant HAL can provide an alternative value.
</P
><P
>The standard eCos macros <CODE
CLASS="FUNCTION"
>HAL_VSR_GET</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_VSR_SET</CODE
> just manipulate one of the 256
entries in the table of exception vectors. Hence it is usually
possible to replace the default handlers for exceptions and traps in
addition to interrupt handlers.
<TT
CLASS="FILENAME"
>hal_intr.h</TT
>
provides <TT
CLASS="LITERAL"
>#define</TT
>'s for the more common exception
vectors, and additional ones can be provided by the platform or
variant. It is the responsibility of the platform or variant HAL to
initialize the table, and to provide the
<CODE
CLASS="FUNCTION"
>HAL_VSR_SET_TO_ECOS_HANDLER</CODE
> macro since that
requires knowledge of the default table entries.
</P
><P
>It should be noted that in some configurations the table of exception
vectors may reside in read-only memory so entries cannot be changed.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -