hal-porting-architecture.html

ecos 文档

><LI
><P
>Create the <TT
CLASS="FILENAME"
>&lt;architecture&gt;.ld</TT
> file. While
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
><P
>This file defines a set of macros that are used by the platform
<TT
CLASS="LITERAL"
>.ldi</TT
> files to generate linker scripts. Most GCC
toolchains are very similar so the correct approach is to copy the
file from an existing architecture and edit it. The main things that
will need editing are the <TT
CLASS="LITERAL"
>OUTPUT_FORMAT()</TT
> directive
and maybe the creation or allocation of extra sections to various
macros. Running the target linker with just the
<TT
CLASS="LITERAL"
>--verbose</TT
> argument will cause it to output its
default linker script. This can be compared with the
<TT
CLASS="LITERAL"
>.ld</TT
> file and appropriate edits made.</P
></LI
><LI
><P
>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
CLASS="FILENAME"
>include/&lt;architecture&gt;-stub.h</TT
> and
<TT
CLASS="FILENAME"
>src/&lt;architecture&gt;-stub.c</TT
>. In all existing
architecture HALs these files, and any support files they need, have
been derived from files supplied in <TT
CLASS="LITERAL"
>libgloss</TT
>, as
part of the GDB toolchain package. If this is a totally new
architecture, this may not have been done, and they must be created
from scratch.</P
><P
><TT
CLASS="FILENAME"
>include/&lt;architecture&gt;-stub.h</TT
>
contains definitions that are used by the GDB stubs to describe the
size, type, number and names of CPU registers. This information is
usually found in the GDB support files for the architecture. It also
contains prototypes for the functions exported by
<TT
CLASS="FILENAME"
>src/&lt;architecture&gt;-stub.c</TT
>; however, since
this is common to all architectures, it can be copied from some other
HAL.</P
><P
><TT
CLASS="FILENAME"
>src/&lt;architecture&gt;-stub.c</TT
> implements the
functions exported by the header. Most of this is fairly straight
forward: the implementation in existing HALs should show exactly what
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
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
must be simulated by planting a breakpoint in the next
instruction. This can be quite involved since it requires some
analysis of the current instruction plus the state of the CPU to
determine where execution is going to go next.</P
></LI
></OL
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="HAL-PORTING-ARCHITECTURE-CDL">CDL Requirements</H2
><P
>The CDL needed for any particular architecture HAL depends to a large
extent on the needs of that architecture. This includes issues such as
support for different variants, use of FPUs, MMUs and caches. The
exact split between the architecture, variant and platform HALs for
various features is also somewhat fluid. </P
><P
>To give a rough idea about how the CDL for an architecture is
structured, we will take as an example the I386 CDL.</P
><P
>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
<TT
CLASS="FILENAME"
>include/cyg/hal</TT
> directory, and definitions from
this file will be placed in
<TT
CLASS="FILENAME"
>include/pkgconf/hal_i386.h</TT
>. The
<TT
CLASS="LITERAL"
>compile</TT
> line specifies the files in the
<TT
CLASS="FILENAME"
>src</TT
> directory that are to be compiled as part of
this package.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_I386 {
    display       "i386 architecture"
    parent        CYGPKG_HAL
    hardware
    include_dir   cyg/hal
    define_header hal_i386.h
    description   "
        The i386 architecture HAL package provides generic
        support for this processor architecture. It is also
        necessary to select a specific target platform HAL
        package."

    compile       hal_misc.c context.S i386_stub.c hal_syscall.c</PRE
></TD
></TR
></TABLE
><P
>Next we need to generate some files using non-standard make rules. The
first is <TT
CLASS="FILENAME"
>vectors.S</TT
>, which is not put into the
library, but linked explicitly with all applications. The second is
the generation of the <TT
CLASS="FILENAME"
>target.ld</TT
> file from
<TT
CLASS="FILENAME"
>i386.ld</TT
> and the startup-selected
<TT
CLASS="FILENAME"
>.ldi</TT
> file. Both of these are essentially
boilerplate code that can be copied and edited.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>&#13;    make {
        &lt;PREFIX&gt;/lib/vectors.o : &lt;PACKAGE&gt;/src/vectors.S
        $(CC) -Wp,-MD,vectors.tmp $(INCLUDE_PATH) $(CFLAGS) -c -o $@ $&lt;
        @echo $@ ": \\" &gt; $(notdir $@).deps
        @tail +2 vectors.tmp &gt;&gt; $(notdir $@).deps
        @echo &gt;&gt; $(notdir $@).deps
        @rm vectors.tmp
    }

    make {
        &lt;PREFIX&gt;/lib/target.ld: &lt;PACKAGE&gt;/src/i386.ld
        $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $&lt;
        @echo $@ ": \\" &gt; $(notdir $@).deps
        @tail +2 target.tmp &gt;&gt; $(notdir $@).deps
        @echo &gt;&gt; $(notdir $@).deps
        @rm target.tmp
    }</PRE
></TD
></TR
></TABLE
><P
>The i386 is currently the only architecture that supports SMP. The
following CDL simply enabled the HAL SMP support if
required. Generally this will get enabled as a result of a
<TT
CLASS="LITERAL"
>requires</TT
> statement in the kernel. The
<TT
CLASS="LITERAL"
>requires</TT
> statement here turns off lazy FPU
switching in the FPU support code, since it is inconsistent with SMP
operation.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>&#13;    cdl_component CYGPKG_HAL_SMP_SUPPORT {
	display       "SMP support"
	default_value 0
	requires { CYGHWR_HAL_I386_FPU_SWITCH_LAZY == 0 }
	
	cdl_option CYGPKG_HAL_SMP_CPU_MAX {
	    display       "Max number of CPUs supported"
	    flavor        data
	    default_value 2
	}
    }</PRE
></TD
></TR
></TABLE
><P
>The i386 HAL has optional FPU support, which is enabled by default. It
can be disabled to improve system performance. There are two FPU
support options: either to save and restore the FPU state on every
context switch, or to only switch the FPU state when necessary.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>        
    cdl_component CYGHWR_HAL_I386_FPU {
	display       "Enable I386 FPU support"
	default_value 1
	description   "This component enables support for the
	              I386 floating point unit."

	cdl_option CYGHWR_HAL_I386_FPU_SWITCH_LAZY {
	    display       "Use lazy FPU state switching"
	    flavor        bool
	    default_value 1

	    description "
	                This option enables lazy FPU state switching.
                        The default behaviour for eCos is to save and
                        restore FPU state on every thread switch, interrupt
	                and exception. While simple and deterministic, this
	                approach can be expensive if the FPU is not used by
	                all threads. The alternative, enabled by this option,
	                is to use hardware features that allow the FPU state
	                of a thread to be left in the FPU after it has been
	                descheduled, and to allow the state to be switched to
	                a new thread only if it actually uses the FPU. Where
	                only one or two threads use the FPU this can avoid a
	                lot of unnecessary state switching."
	}
    }</PRE
></TD
></TR
></TABLE
><P
>The i386 HAL also has support for different classes of CPU. In
particular, Pentium class CPUs have extra functional units, and some
variants of GDB expect more registers to be reported. These options
enable these features. Generally these are enabled by
<TT
CLASS="LITERAL"
>requires</TT
> statements in variant or platform
packages, or in <TT
CLASS="LITERAL"
>.ecm</TT
> files.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>&#13;    cdl_component CYGHWR_HAL_I386_PENTIUM {
	display       "Enable Pentium class CPU features"
	default_value 0
	description   "This component enables support for various
	              features of Pentium class CPUs."

	cdl_option CYGHWR_HAL_I386_PENTIUM_SSE {
	    display       "Save/Restore SSE registers on context switch"
	    flavor        bool
	    default_value 0

	    description "
	                This option enables SSE state switching. The default
                        behaviour for eCos is to ignore the SSE registers.
                        Enabling this option adds SSE state information to
                        every thread context."
	}

	cdl_option CYGHWR_HAL_I386_PENTIUM_GDB_REGS {
	    display       "Support extra Pentium registers in GDB stub"
	    flavor        bool
	    default_value 0

	    description "
	                This option enables support for extra Pentium registers
			in the GDB stub. These are registers such as CR0-CR4, and
                        all MSRs. Not all GDBs support these registers, so the
                        default behaviour for eCos is to not include them in the
			GDB stub support code."
	}
    }</PRE
></TD
></TR
></TABLE
><P
>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. The following option provides the name of the linker script to
other elements in the configuration system.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    cdl_option CYGBLD_LINKER_SCRIPT {
        display "Linker script"
        flavor data
	no_define
        calculated  { "src/i386.ld" }
    }</PRE
></TD
></TR
></TABLE
><P
>Finally, this interface indicates whether the platform supplied an
implementation of the
<TT
CLASS="FUNCTION"
>hal_i386_mem_real_region_top()</TT
> function. If it
does then it will contain a line of the form: <TT
CLASS="LITERAL"
>implements
CYGINT_HAL_I386_MEM_REAL_REGION_TOP</TT
>. This allows packages
such as RedBoot to detect the presence of this function so that they
may call it.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>&#13;    cdl_interface CYGINT_HAL_I386_MEM_REAL_REGION_TOP {
        display  "Implementations of hal_i386_mem_real_region_top()"
    }
    
}</PRE
></TD
></TR
></TABLE
></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="hal-porting-variant.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-future-developments.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Variant HAL Porting</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="hal-porting-guide.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Future developments</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>