📄 hal-calling-if.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
>Virtual Vectors (eCos/ROM Monitor Calling Interface)</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="HAL Structure"
HREF="hal-porting-structure.html"><LINK
REL="NEXT"
TITLE="HAL Coding Conventions"
HREF="hal-porting-coding-conventions.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-structure.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-porting-coding-conventions.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="HAL-CALLING-IF">Virtual Vectors (eCos/ROM Monitor Calling Interface)</H1
><P
>Some eCos platforms have supported full debugging capabilities via
CygMon since day one. Platforms of the architectures PowerPC, ARM, and
SH do not provide those features unless a GDB stub is included in the
application.</P
><P
>This is going to change. All platforms will (eventually) support
all the debugging features by relying on a ROM/RAM calling interface
(also referred to as virtual vector table) provided by the ROM
monitor. This calling interface is based on the tables used by libbsp
and is thus backwards compatible with the existing CygMon supported
platforms.</P
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="HAL-PORTING-VIRTUAL-VECTORS">Virtual Vectors</H2
><P
>What are virtual vectors, what do they do, and why are they
needed?</P
><P
>"Virtual vectors" is the name of a table located at a static
location in the target address space. This table contains 64 vectors
that point to <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>service</I
></SPAN
> functions or data.</P
><P
>The fact that the vectors are always placed at the same location in
the address space means that both ROM and RAM startup configurations
can access these and thus the services pointed to.</P
><P
>The primary goal is to allow services to be provided by ROM
configurations (ROM monitors such as RedBoot in particular) with
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>clients</I
></SPAN
> in RAM configurations being able to use these
services.</P
><P
>Without the table of pointers this would be impossible since the
ROM and RAM applications would be linked separately - in effect having
separate name spaces - preventing direct references from one to the
other.</P
><P
>This decoupling of service from client is needed by RedBoot,
allowing among other things debugging of applications which do not
contain debugging client code (stubs).</P
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN8971">Initialization (or Mechanism vs. Policy)</H3
><P
>Virtual vectors are a <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>mechanism</I
></SPAN
> for decoupling services
from clients in the address space.</P
><P
>The mechanism allows services to be implemented by a ROM
monitor, a RAM application, to be switched out at run-time, to be
disabled by installing pointers to dummy functions, etc.</P
><P
>The appropriate use of the mechanism is specified loosely by a
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>policy</I
></SPAN
>. The general policy dictates that the vectors are
initialized in whole by ROM monitors (built for ROM or RAM), or by
stand-alone applications.</P
><P
>For configurations relying on a ROM monitor environment, the policy
is to allow initialization on a service by service basis. The default
is to initialize all services, except COMMS services since these are
presumed to already be carrying a communication session to the
debugger / console which was used for launching the application. This
means that the bulk of the code gets tested in normal builds, and not
just once in a blue moon when building new stubs or a ROM
configuration.</P
><P
>The configuration options are written to comply with this policy by
default, but can be overridden by the user if desired. Defaults
are:</P
><P
></P
><UL
><LI
><P
>For application development: the ROM monitor provides
debugging and diagnostic IO services, the RAM application relies
on these by default.</P
></LI
><LI
><P
>For production systems: the application contains all the
necessary services.</P
></LI
></UL
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN8985">Pros and Cons of Virtual Vectors</H3
><P
>There are pros and cons associated with the use of virtual
vectors. We do believe that the pros generally outweigh the cons by a
great margin, but there may be situations where the opposite is
true.</P
><P
>The use of the services are implemented by way of macros, meaning
that it is possible to circumvent the virtual vectors if
desired. There is (as yet) no implementation for doing this, but it is
possible.</P
><P
>Here is a list of pros and cons:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Pro: Allows debugging without including stubs</DT
><DD
><P
>This is the primary reason for using virtual vectors. It
allows the ROM monitor to provide most of the debugging
infrastructure, requiring only the application to provide
hooks for asynchronous debugger interrupts and for accessing
kernel thread information.</P
></DD
><DT
>Pro: Allows debugging to be initiated from arbitrary
channel</DT
><DD
><P
> While this is only true where the application does not
actively override the debugging channel setup, it is a very
nice feature during development. In particular it makes it
possible to launch (and/or debug) applications via Ethernet
even though the application configuration does not contain
networking support.</P
></DD
><DT
>Pro: Image smaller due to services being provided by ROM
monitor</DT
><DD
><P
>All service functions except HAL IO are included in the
default configuration. But if these are all disabled the
image for download will be a little smaller. Probably
doesn't matter much for regular development, but it is a
worthwhile saving for the 20000 daily tests run in the Red
Hat eCos test farm.</P
></DD
><DT
>Con: The vectors add a layer of indirection, increasing application
size and reducing performance.</DT
><DD
><P
>The size increase is a fraction of what is required to
implement the services. So for RAM configurations there is
a net saving, while for ROM configurations there is a small
overhead.</P
><P
>The performance loss means little for most of the
services (of which the most commonly used is diagnostic IO
which happens via polled routines
anyway).</P
></DD
><DT
>Con: The layer of indirection is another point of
failure.</DT
><DD
><P
> The concern primarily being that of vectors being
trashed by rogue writes from bad code, causing a complete
loss of the service and possibly a crash. But this does
not differ much from a rogue write to anywhere else in the
address space which could cause the same amount of
mayhem. But it is arguably an additional point of failure
for the service in question.</P
></DD
><DT
>Con: All the indirection stuff makes it harder to bring a HAL
up</DT
><DD
><P
> This is a valid concern. However, seeing as most of the
code in question is shared between all HALs and should
remain unchanged over time, the risk of it being broken
when a new HAL is being worked on should be
minimal.</P
><P
> When starting a new port, be sure to implement the HAL
IO drivers according to the scheme used in other drivers,
and there should be no problem.</P
><P
> However, it is still possible to circumvent the vectors
if they are suspect of causing problems: simply change the
HAL_DIAG_INIT and HAL_DIAG_WRITE_CHAR macros to use the raw
IO functions.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9018">Available services</H3
><P
>The <TT
CLASS="FILENAME"
>hal_if.h</TT
> file in the common HAL defines the
complete list of available services. A few worth mentioning in
particular:</P
><P
></P
><UL
><LI
><P
>COMMS services. All HAL IO happens via the communication
channels.</P
></LI
><LI
><P
>uS delay. Fine granularity (busy wait) delay function.</P
></LI
><LI
><P
>Reset. Allows a software initiated reset of the board.</P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9029">The COMMS channels</H2
><P
>As all HAL IO happens via the COMMS channels these deserve to be
described in a little more detail. In particular the controls of where
diagnostic output is routed and how it is treated to allow for display
in debuggers.</P
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9032">Console and Debugging Channels</H3
><P
>There are two COMMS channels - one for console IO and one for
debugging IO. They can be individually configured to use any of the
actual IO ports (serial or Ethernet) available on the platform.</P
><P
>The console channel is used for any IO initiated by calling the
<TT
CLASS="FUNCTION"
>diag_*()</TT
> functions. Note that these should only be used during
development for debugging, assertion and possibly tracing
messages. All proper IO should happen via proper devices. This means
it should be possible to remove the HAL device drivers from production
configurations where assertions are disabled.</P
><P
>The debugging channel is used for communication between the
debugger and the stub which remotely controls the target for the
debugger (the stub runs on the target). This usually happens via some
protocol, encoding commands and replies in some suitable form.</P
><P
>Having two separate channels allows, e.g., for simple logging
without conflicts with the debugger or interactive IO which some
debuggers do not allow.</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9039">Mangling</H3
><P
>As debuggers usually have a protocol using specialized commands
when communicating with the stub on the target, sending out text as
raw ASCII from the target on the same channel will either result in
protocol errors (with loss of control over the target) or the text may
just be ignored as junk by the debugger.</P
><P
>To get around this, some debuggers have a special command for text
output. Mangling is the process of encoding diagnostic ASCII text
output in the form specified by the debugger protocol.</P
><P
>When it is necessary to use mangling, i.e. when writing console
output to the same port used for debugging, a mangler function is
installed on the console channel which mangles the text and passes it
on to the debugger channel.</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN9044">Controlling the Console Channel</H3
><P
>Console output configuration is either inherited from the ROM
monitor launching the application, or it is specified by the
application. This is controlled by the new option
<TT
CLASS="LITERAL"
>CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE</TT
> which
defaults to enabled when the configuration is set to use a ROM
monitor.</P
><P
>If the user wants to specify the console configuration in the
application image, there are two new options that are used for
this.</P
><P
>Defaults are to direct diagnostic output via a mangler to the
debugging channel (<TT
CLASS="LITERAL"
>CYGDBG_HAL_DIAG_TO_DEBUG_CHAN</TT
>
enabled). The mangler type is controlled by the option
<TT
CLASS="LITERAL"
>CYGSEM_HAL_DIAG_MANGLER</TT
>. At present there are only
two mangler types:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="ACRONYM"
>GDB</SPAN
></DT
><DD
><P
> This causes a mangler appropriate for debugging with GDB to be
installed on the console channel.</P
></DD
><DT
>None</DT
><DD
><P
> This causes a NULL mangler to be installed on the console
channel. It will redirect the IO to/from the debug channel
without mangling of the data. This option differs from setting
the console channel to the same IO port as the debugging
channel in that it will keep redirecting data to the debugging
channel even if that is changed to some other port.</P
></DD
></DL
></DIV
><P
>Finally, by disabling <TT
CLASS="LITERAL"
>CYGDBG_HAL_DIAG_TO_DEBUG_CHAN</TT
>, the diagnostic
output is directed in raw form to the specified console IO port.</P
><P
>In summary this results in the following common configuration
scenarios for RAM startup configurations:</P
><P
></P
><UL
><LI
><P
> For regular debugging with diagnostic output appearing in the
debugger, mangling is enabled and stubs disabled.</P
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -