m68k-port.html

ecos3.0 beta 的官方文档,html格式

>cyg/hal/var_arch.h</TT
> should define
<CODE
CLASS="VARNAME"
>HAL_CONTEXT_OTHER</CODE
>,
<CODE
CLASS="VARNAME"
>HAL_CONTEXT_OTHER_SIZE</CODE
>, and
<CODE
CLASS="VARNAME"
>HAL_CONTEXT_OTHER_INIT</CODE
>, either directly or via
<TT
CLASS="FILENAME"
>cyg/hal/proc_arch.h</TT
>. The
assembler header file <TT
CLASS="FILENAME"
>cyg/hal/var.inc</TT
> should define a number
of macros such as <CODE
CLASS="FUNCTION"
>hal_context_other_save_caller</CODE
>.
For details of these macros see the architectural
<TT
CLASS="FILENAME"
>hal_arch.S</TT
> file.
      </P
><P
>Variants also need to define exactly how the status register and
program counter are saved onto the stack when an interrupt or
exception occurs. This is handled through C macros
<CODE
CLASS="VARNAME"
>HAL_CONTEXT_PCSR_SIZE</CODE
>,
<CODE
CLASS="VARNAME"
>HAL_CONTEXT_PCSR_RTE_ADJUST</CODE
>, and
<CODE
CLASS="FUNCTION"
>HAL_CONTEXT_PCSR_INIT</CODE
>, and a number of assembler
macros such as <CODE
CLASS="FUNCTION"
>hal_context_pcsr_save_sr</CODE
>. Again
the architectural files <TT
CLASS="FILENAME"
>cyg/hal/hal_arch.h</TT
> and
<TT
CLASS="FILENAME"
>hal_arch.S</TT
> provide more details of these.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-BITINDEX"
></A
><H3
>Bit Indexing</H3
><P
>For performance reasons the <CODE
CLASS="FUNCTION"
>HAL_LSBIT_INDEX</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_MSBIT_INDEX</CODE
> macros are implemented using
assembler functions. A variant HAL can override the default
definitions if, for example, the variant has special instructions to
perform these operations.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-IDLE"
></A
><H3
>Idle Thread Processing</H3
><P
>The default <CODE
CLASS="FUNCTION"
>HAL_IDLE_THREAD_ACTION</CODE
> implementation
is a no-op. A variant HAL may override this, for example to put the
processor into sleep mode. Alternative implementations should consider
exactly how this macro gets used in eCos kernel code.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-CLOCK"
></A
><H3
>Clock Support</H3
><P
>The architectural HAL cannot provide the required clock support
because it does not know what timer hardware may be available on the
target hardware. Instead this is left to either the variant or
platform HAL, depending on whether the processor has a suitable
on-chip timer or whether an off-chip timer has to be used.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-IO"
></A
><H3
>HAL I/O</H3
><P
>The M68K architecture does not have a separate I/O bus. Instead all
hardware is assumed to be memory-mapped. Further it is assumed that
all peripherals on the memory bus are wired appropriately for a
big-endian processor and that there is no need for any byte swapping.
Hence the various HAL macros for performing I/O simply involve
pointers to volatile memory.
      </P
><P
>The variant, processor and platform equivalents of the <TT
CLASS="FILENAME"
>cyg/hal/hal_io.h</TT
> header will typically
also provide details of some or all of the peripherals, for example
register offsets and the meaning of various bits in those registers.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-CACHE"
></A
><H3
>Cache Handling</H3
><P
>If the processor has a cache then the variant HAL should implement the
CDL interface <CODE
CLASS="VARNAME"
>CYGINT_HAL_M68K_VARIANT_CACHE</CODE
>. This
causes the architectural header <TT
CLASS="FILENAME"
>cyg/hal/hal_cache.h</TT
> to pick up
appropriate definitions from <TT
CLASS="FILENAME"
>cyg/hal/var_cache.h</TT
>. The architectural
header will provide null defaults for anything not defined by the
variant.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-LDSCRIPT"
></A
><H3
>Linker Scripts</H3
><P
>The architectural HAL will generate the linker script for eCos
applications. This involves the architectural file
<TT
CLASS="FILENAME"
>m68k.ld</TT
> and a <TT
CLASS="FILENAME"
>.ldi</TT
> memory
layout file provided lower down, typically by the platform HAL. It is
the LDI file which specifies the types and amount of memory available
and which places code and data in appropriate places, but most of the
hard work is done via macros provided by the architectural
<TT
CLASS="FILENAME"
>m68k.ld</TT
> file. 
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-DIAG"
></A
><H3
>Diagnostic Support</H3
><P
>The architectural HAL does not implement diagnostic support. Instead
this is left to the variant or platform HAL, depending on whether
suitable peripherals are available on-chip or off-chip.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-SMP"
></A
><H3
>SMP Support</H3
><P
>The M68K port does not have SMP support.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-GDB"
></A
><H3
>Debug Support</H3
><P
>The M68K architectural HAL package provides basic support only for gdb
stubs. There is no support for more advanced debug features like
hardware watchpoints.
      </P
><P
>The generic gdb support in the common HAL requires a platform header
<TT
CLASS="FILENAME"
>&lt;cyg/hal/plf_stub.h</TT
>. In
practice there is rarely any need for the contents of this file to
change between platforms so the architectural HAL can provide a
suitable default. It will do so if the CDL interface
<CODE
CLASS="VARNAME"
>CYGINT_HAL_M68K_USE_STANDARD_PLATFORM_STUB_SUPPORT</CODE
>
is implemented.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-DELAY"
></A
><H3
>HAL_DELAY_US Macro</H3
><P
>The architectural HAL provides a default implementation of the
standard <CODE
CLASS="FUNCTION"
>HAL_DELAY_US</CODE
> macro using a simply busy
loop. To use this support a lower-level HAL should define
<CODE
CLASS="VARNAME"
>_HAL_M68K_DELAY_US_LOOPS_</CODE
>, typically a small number
of about 20 but it will need to be calibrated during the porting
process. If the processor has a cache then the lower-level HAL may
also define <CODE
CLASS="VARNAME"
>_HAL_M68K_DELAY_US_LOOPS_UNCACHED_</CODE
> for
the case when a delay loop is triggered while the cache is disabled.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-PROFILING"
></A
><H3
>Profiling Support</H3
><P
>The M68K architectural HAL implements the <CODE
CLASS="FUNCTION"
>mcount</CODE
>
function, allowing profiling tools like
<SPAN
CLASS="APPLICATION"
>gprof</SPAN
> to determine the application's call
graph. It does not implement the profiling timer. Instead that
functionality needs to be provided by the variant or platform HAL.
The implementation of <CODE
CLASS="FUNCTION"
>mcount</CODE
> requires a dedicated
frame pointer register so code should be compiled without the
<CODE
CLASS="OPTION"
>-fomit-frame-pointer</CODE
> flag.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-OTHER"
></A
><H3
>Other Functionality</H3
><P
>The M68K architectural HAL only implements the functionality provided
by the eCos HAL specification and does not export any extra
functionality. 
      </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="m68k-configuration.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="hal-m68k-mcfxxxx.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Configuration</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="hal-m68k-arch.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Freescale MCFxxxx Variant Support</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>