hal-porting-platform.html

ecos 文档

>Debugging the interrupt processing is possible if you are
    careful with the way you program the very early interrupt entry
    handling. Write it so that as soon as possible in the interrupt
    path, taking a trap (exception) does not harm execution. See the
    SH vectors.S code for an example. Look for
    <TT
CLASS="LITERAL"
>cyg_hal_default_interrupt_vsr</TT
> and the label
    <TT
CLASS="LITERAL"
>cyg_hal_default_interrupt_vsr_bp_safe</TT
>, which
    marks the point after which traps/single-stepping is safe.
    </P
><P
>Being able to display memory content, CPU registers,
    interrupt controller details at the time of an interrupt can save
    a lot of time.</P
></LI
><LI
><P
>Using assertions is a good idea. They can sometimes reveal subtle
    bugs or missing features long before you would otherwise have
    found them, let alone notice them.
    </P
><P
>The default eCos configuration does not use assertions, so you
    have to enable them by switching on the option <TT
CLASS="LITERAL"
>CYGPKG_INFRA_DEBUG</TT
>
    in the infra package.</P
></LI
><LI
><P
>The idle loop can be used to help debug the system.
    </P
><P
>Triggering clock from the idle loop is a neat trick for
    examining system behavior either before interrupts are fully
    working, or to speed up &quot;the clock&quot;.
    </P
><P
>Use the idle loop to monitor and/or print out variables or
    hardware registers.</P
></LI
><LI
><P
><SPAN
CLASS="APPLICATION"
>hal_mk_defs</SPAN
> is used in some of the
HALs (ARM, SH) as a way to generate assembler symbol definitions from
C header files without imposing an assembler/C syntax separation in
the C header files.</P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="HAL-PORTING-CDL-REQUIREMENTS">HAL Platform CDL</H2
><P
>The platform CDL both contains details necessary for the building
of eCos, and platform-specific configuration options. For this reason
the options differ between platforms, and the below is just a brief
description of the most common options.</P
><P
> See  Components Writers Guide
for more details on CDL. Also have a quick look around in
existing platform CDL files to get an idea of what is possible and how
various configuration issues can be represented with CDL.</P
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="HAL-PORTING-ECOS-DATABASE">eCos Database</H3
><P
>The eCos configuration system is made aware of a package by
adding a package description in <TT
CLASS="FILENAME"
>ecos.db</TT
>. As an
example we use the <TT
CLASS="LITERAL"
>TX39/JMR3904</TT
> platform:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>package CYGPKG_HAL_MIPS_TX39_JMR3904 {
	alias		{ "Toshiba JMR-TX3904 board" hal_tx39_jmr3904 tx39_jmr3904_hal }
	directory	hal/mips/jmr3904
	script		hal_mips_tx39_jmr3904.cdl
	hardware
	description "
           The JMR3904 HAL package should be used when targeting the
           actual hardware. The same package can also be used when
           running on the full simulator, since this provides an
           accurate simulation of the hardware including I/O devices.
           To use the simulator in this mode the command
           `target sim --board=jmr3904' should be used from inside gdb."
}</PRE
></TD
></TR
></TABLE
><P
>This contains the title and description presented in the
Configuration Tool when the package is selected. It also specifies
where in the tree the package files can be found (<TT
CLASS="LITERAL"
>directory</TT
>)
and the name of the CDL file which contains the package details
(<TT
CLASS="LITERAL"
>script</TT
>).</P
><P
>To be able to build and test a configuration for the new target, there
also needs to be a <TT
CLASS="LITERAL"
>target</TT
> entry in the
<TT
CLASS="FILENAME"
>ecos.db</TT
> file. </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>target jmr3904 {
        alias		{ "Toshiba JMR-TX3904 board" jmr tx39 }
	packages        { CYGPKG_HAL_MIPS
                          CYGPKG_HAL_MIPS_TX39
                          CYGPKG_HAL_MIPS_TX39_JMR3904
        }
        description "
           The jmr3904 target provides the packages needed to run
           eCos on a Toshiba JMR-TX3904 board. This target can also
           be used when running in the full simulator, since the simulator provides an
           accurate simulation of the hardware including I/O devices.
           To use the simulator in this mode the command
           `target sim --board=jmr3904' should be used from inside gdb."
}</PRE
></TD
></TR
></TABLE
><P
>The important part here is the <TT
CLASS="LITERAL"
>packages</TT
> section
which defines the various hardware specific packages that contribute
to support for this target. In this case the MIPS architecture
package, the TX39 variant package, and the JMR-TX3904 platform
packages are selected. Other packages, for serial drivers, ethernet
drivers and FLASH memory drivers may also appear here.</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9558">CDL File Layout</H3
><P
>All the platform options are contained in a CDL package named
<TT
CLASS="LITERAL"
>CYGPKG_HAL_&lt;architecture&gt;_&lt;variant&gt;_&lt;platform&gt;</TT
>.
They all share more or less the same <TT
CLASS="LITERAL"
>cdl_package</TT
>
details:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_MIPS_TX39_JMR3904 {
    display       "JMR3904 evaluation board"
    parent        CYGPKG_HAL_MIPS
    requires      CYGPKG_HAL_MIPS_TX39
    define_header hal_mips_tx39_jmr3904.h
    include_dir   cyg/hal
    description   "
           The JMR3904 HAL package should be used when targeting the
           actual hardware. The same package can also be used when
           running on the full simulator, since this provides an
           accurate simulation of the hardware including I/O devices.
           To use the simulator in this mode the command
           `target sim --board=jmr3904' should be used from inside gdb."

    compile       platform.S plf_misc.c plf_stub.c

    define_proc {
        puts $::cdl_system_header "#define CYGBLD_HAL_TARGET_H   &lt;pkgconf/hal_mips_tx39.h&gt;"
        puts $::cdl_system_header "#define CYGBLD_HAL_PLATFORM_H &lt;pkgconf/hal_mips_tx39_jmr3904.h&gt;"
    }

    ...
}</PRE
></TD
></TR
></TABLE
><P
>This specifies that the platform package should be parented under
the MIPS packages, requires the TX39 variant HAL and all configuration
settings should be saved in
<TT
CLASS="FILENAME"
>cyg/hal/hal_mips_tx39_jmt3904.h</TT
>.</P
><P
>The <TT
CLASS="LITERAL"
>compile</TT
> line specifies which files should be built
when this package is enabled, and the <TT
CLASS="LITERAL"
>define_proc</TT
> defines
some macros that are used to access the variant or architecture (the
<TT
CLASS="LITERAL"
>_TARGET_</TT
> name is a bit of a misnomer) and platform
configuration options. </P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9570">Startup Type</H3
><P
>eCos uses an option to select between a set of valid startup
configurations. These are normally RAM, ROM and possibly ROMRAM. This
setting is used to select which linker map to use (i.e., where to link
eCos and the application in the memory space), and how the startup
code should behave.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_component CYG_HAL_STARTUP {
    display       "Startup type"
    flavor        data
    legal_values  {"RAM" "ROM"}
    default_value {"RAM"}
	no_define
	define -file system.h CYG_HAL_STARTUP
    description   "
       When targeting the JMR3904 board it is possible to build
       the system for either RAM bootstrap, ROM bootstrap, or STUB
       bootstrap. RAM bootstrap generally requires that the board
       is equipped with ROMs containing a suitable ROM monitor or
       equivalent software that allows GDB to download the eCos
       application on to the board. The ROM bootstrap typically
       requires that the eCos application be blown into EPROMs or
       equivalent technology."
}</PRE
></TD
></TR
></TABLE
><P
>The <TT
CLASS="LITERAL"
>no_define</TT
> and <TT
CLASS="LITERAL"
>define</TT
>
pair is used to make the setting of this option appear in the file
<TT
CLASS="FILENAME"
>system.h</TT
> instead of the default specified in the
header.</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9578">Build options</H3
><P
>A set of options under the components
<TT
CLASS="LITERAL"
>CYGBLD_GLOBAL_OPTIONS</TT
> and
<TT
CLASS="LITERAL"
>CYGHWR_MEMORY_LAYOUT</TT
> specify how eCos should be
built: what tools and compiler options should be used, and which
linker fragments should be used.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>&#13;cdl_component CYGBLD_GLOBAL_OPTIONS {
    display "Global build options"
    flavor  none
    parent  CYGPKG_NONE
    description   "
	    Global build options including control over
	    compiler flags, linker flags and choice of toolchain."


    cdl_option CYGBLD_GLOBAL_COMMAND_PREFIX {
        display "Global command prefix"
        flavor  data
        no_define
        default_value { "mips-tx39-elf" }
        description "
            This option specifies the command prefix used when
            invoking the build tools."
    }

    cdl_option CYGBLD_GLOBAL_CFLAGS {
        display "Global compiler flags"
        flavor  data
        no_define
        default_value { "-Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -fvtable-gc -finit-priority" }
        description   "
            This option controls the global compiler flags which
            are used to compile all packages by
            default. Individual packages may define
            options which override these global flags."
    }

    cdl_option CYGBLD_GLOBAL_LDFLAGS {
        display "Global linker flags"
        flavor  data
        no_define
        default_value { "-g -nostdlib -Wl,--gc-sections -Wl,-static" }
        description   "
            This option controls the global linker flags. Individual
            packages may define options which override these global flags."
    }
}

cdl_component CYGHWR_MEMORY_LAYOUT {
    display "Memory layout"
    flavor data
    no_define
    calculated { CYG_HAL_STARTUP == "RAM" ? "mips_tx39_jmr3904_ram" : \
                                            "mips_tx39_jmr3904_rom" }

    cdl_option CYGHWR_MEMORY_LAYOUT_LDI {
        display "Memory layout linker script fragment"
        flavor data
        no_define
        define -file system.h CYGHWR_MEMORY_LAYOUT_LDI
        calculated { CYG_HAL_STARTUP == "RAM" ? "&lt;pkgconf/mlt_mips_tx39_jmr3904_ram.ldi&gt;" : \
                                                "&lt;pkgconf/mlt_mips_tx39_jmr3904_rom.ldi&gt;" }
    }

    cdl_option CYGHWR_MEMORY_LAYOUT_H {
        display "Memory layout header file"
        flavor data
        no_define
        define -file system.h CYGHWR_MEMORY_LAYOUT_H
        calculated { CYG_HAL_STARTUP == "RAM" ? "&lt;pkgconf/mlt_mips_tx39_jmr3904_ram.h&gt;" : \
                                                "&lt;pkgconf/mlt_mips_tx39_jmr3904_rom.h&gt;" }
    }
}&#13;</PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9584">Common Target Options</H3
><P
>All platforms also specify real-time clock details:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
># Real-time clock/counter specifics
cdl_component CYGNUM_HAL_RTC_CONSTANTS {
    display       "Real-time clock constants."
    flavor        none

    cdl_option CYGNUM_HAL_RTC_NUMERATOR {
        display       "Real-time clock numerator"
        flavor        data
        calculated    1000000000
    }
    cdl_option CYGNUM_HAL_RTC_DENOMINATOR {
        display       "Real-time clock denominator"
        flavor        data
        calculated    100
    }
    # Isn't a nice way to handle freq requirement!
    cdl_option CYGNUM_HAL_RTC_PERIOD {
        display       "Real-time clock period"
        flavor        data
        legal_values  { 15360 20736 }
        calculated     { CYGHWR_HAL_MIPS_CPU_FREQ == 50 ? 15360 : \
                         CYGHWR_HAL_MIPS_CPU_FREQ == 66 ? 20736 : 0 }
    }
}</PRE
></TD
></TR
></TABLE
><P
> The <TT
CLASS="LITERAL"
>NUMERATOR</TT
> divided by the
<TT
CLASS="LITERAL"
>DENOMINATOR</TT
> gives the number of nanoseconds per
tick. The <TT
CLASS="LITERAL"
>PERIOD</TT
> is the divider to be programmed
into a hardware timer that is driven from an appropriate hardware
clock, such that the timer overflows once per tick (normally
generating a CPU interrupt to mark the end of a tick). The tick
default rate is typically 100Hz.</P
><P
>Platforms that make use of the virtual vector
ROM calling interface (see <A
HREF="hal-calling-if.html"
>the Section called <I
>Virtual Vectors (eCos/ROM Monitor Calling Interface)</I
></A
>) will also
specify details necessary to define configuration channels (these
options are from the SH/EDK7707 HAL) :</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS {
    display      "Number of communication channels on the board"
    flavor       data
    calculated   1
}

cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL {
    display          "Debug serial port"
    flavor data
    legal_values     0 to CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS-1
    default_value    0
    description      "
       The EDK/7708 board has only one serial port. This option
       chooses which port will be used to connect to a host
       running GDB."
}

cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
    display          "Diagnostic serial port"
    flavor data
    legal_values     0 to CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS-1
    default_value    0
    description      "
       The EDK/7708 board has only one serial port.  This option
       chooses which port will be used for diagnostic output."
}</PRE
></TD
></TR
></TABLE
><P
>The platform usually also specify an option controlling the ability
 to co-exist with a ROM monitor:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
    display       "Work with a ROM monitor"
    flavor        booldata
    legal_values  { "Generic" "CygMon" "GDB_stubs" }
    default_value { CYG_HAL_STARTUP == "RAM" ? "CygMon" : 0 }
    parent        CYGPKG_HAL_ROM_MONITOR
    requires      { CYG_HAL_STARTUP == "RAM" }
    description   "
        Support can be enabled for three different varieties of ROM monitor.
        This support changes various eCos semantics such as the encoding
        of diagnostic output, or the overriding of hardware interrupt
        vectors.
        Firstly there is \"Generic\" support which prevents the HAL
        from overriding the hardware vectors that it does not use, to
        instead allow an installed ROM monitor to handle them. This is
        the most basic support which is likely to be common to most
        implementations of ROM monitor.
        \"CygMon\" provides support for the Cygnus ROM Monitor.
        And finally, \"GDB_stubs\" provides support when GDB stubs are
        included in the ROM monitor or boot ROM."
}</PRE
></TD
></TR
></TABLE
><P
>Or the ability to be configured as a ROM monitor:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_option CYGSEM_HAL_ROM_MONITOR {
    display       "Behave as a ROM monitor"
    flavor        bool
    default_value 0
    parent        CYGPKG_HAL_ROM_MONITOR
    requires      { CYG_HAL_STARTUP == "ROM" }