📄 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"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="eCos Reference Manual"HREF="ecos-ref.html"><LINKREL="UP"TITLE=" Porting Guide"HREF="hal-porting-guide.html"><LINKREL="PREVIOUS"TITLE="HAL Structure"HREF="hal-porting-structure.html"><LINKREL="NEXT"TITLE="HAL Coding Conventions"HREF="hal-porting-coding-conventions.html"></HEAD><BODYCLASS="SECTION"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">eCos Reference Manual</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="hal-porting-structure.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 11. Porting Guide</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="hal-porting-coding-conventions.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECTION"><H1CLASS="SECTION"><ANAME="HAL-CALLING-IF">Virtual Vectors (eCos/ROM Monitor Calling Interface)</H1><P>Some eCos platforms have supported full debugging capabilities viaCygMon since day one. Platforms of the architectures PowerPC, ARM, andSH do not provide those features unless a GDB stub is included in theapplication.</P><P>This is going to change. All platforms will (eventually) supportall the debugging features by relying on a ROM/RAM calling interface(also referred to as virtual vector table) provided by the ROMmonitor. This calling interface is based on the tables used by libbspand is thus backwards compatible with the existing CygMon supportedplatforms.</P><DIVCLASS="SECTION"><H2CLASS="SECTION"><ANAME="HAL-PORTING-VIRTUAL-VECTORS">Virtual Vectors</H2><P>What are virtual vectors, what do they do, and why are theyneeded?</P><P>"Virtual vectors" is the name of a table located at a staticlocation in the target address space. This table contains 64 vectorsthat point to <SPANCLASS="emphasis"><ICLASS="EMPHASIS">service</I></SPAN> functions or data.</P><P>The fact that the vectors are always placed at the same location inthe address space means that both ROM and RAM startup configurationscan access these and thus the services pointed to.</P><P>The primary goal is to allow services to be provided by ROMconfigurations (ROM monitors such as RedBoot in particular) with<SPANCLASS="emphasis"><ICLASS="EMPHASIS">clients</I></SPAN> in RAM configurations being able to use theseservices.</P><P>Without the table of pointers this would be impossible since theROM and RAM applications would be linked separately - in effect havingseparate name spaces - preventing direct references from one to theother.</P><P>This decoupling of service from client is needed by RedBoot,allowing among other things debugging of applications which do notcontain debugging client code (stubs).</P><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN8971">Initialization (or Mechanism vs. Policy)</H3><P>Virtual vectors are a <SPANCLASS="emphasis"><ICLASS="EMPHASIS">mechanism</I></SPAN> for decoupling servicesfrom clients in the address space.</P><P>The mechanism allows services to be implemented by a ROMmonitor, a RAM application, to be switched out at run-time, to bedisabled by installing pointers to dummy functions, etc.</P><P>The appropriate use of the mechanism is specified loosely by a<SPANCLASS="emphasis"><ICLASS="EMPHASIS">policy</I></SPAN>. The general policy dictates that the vectors areinitialized in whole by ROM monitors (built for ROM or RAM), or bystand-alone applications.</P><P>For configurations relying on a ROM monitor environment, the policyis to allow initialization on a service by service basis. The defaultis to initialize all services, except COMMS services since these arepresumed to already be carrying a communication session to thedebugger / console which was used for launching the application. Thismeans that the bulk of the code gets tested in normal builds, and notjust once in a blue moon when building new stubs or a ROMconfiguration.</P><P>The configuration options are written to comply with this policy bydefault, but can be overridden by the user if desired. Defaultsare:</P><P></P><UL><LI><P>For application development: the ROM monitor providesdebugging and diagnostic IO services, the RAM application relieson these by default.</P></LI><LI><P>For production systems: the application contains all thenecessary services.</P></LI></UL></DIV><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN8985">Pros and Cons of Virtual Vectors</H3><P>There are pros and cons associated with the use of virtualvectors. We do believe that the pros generally outweigh the cons by agreat margin, but there may be situations where the opposite istrue.</P><P>The use of the services are implemented by way of macros, meaningthat it is possible to circumvent the virtual vectors ifdesired. There is (as yet) no implementation for doing this, but it ispossible.</P><P>Here is a list of pros and cons:</P><P></P><DIVCLASS="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><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN9018">Available services</H3><P>The <TTCLASS="FILENAME">hal_if.h</TT> file in the common HAL defines thecomplete list of available services. A few worth mentioning inparticular:</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><DIVCLASS="SECTION"><H2CLASS="SECTION"><ANAME="AEN9029">The COMMS channels</H2><P>As all HAL IO happens via the COMMS channels these deserve to bedescribed in a little more detail. In particular the controls of wherediagnostic output is routed and how it is treated to allow for displayin debuggers.</P><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN9032">Console and Debugging Channels</H3><P>There are two COMMS channels - one for console IO and one fordebugging IO. They can be individually configured to use any of theactual IO ports (serial or Ethernet) available on the platform.</P><P>The console channel is used for any IO initiated by calling the<TTCLASS="FUNCTION">diag_*()</TT> functions. Note that these should only be used duringdevelopment for debugging, assertion and possibly tracingmessages. All proper IO should happen via proper devices. This meansit should be possible to remove the HAL device drivers from productionconfigurations where assertions are disabled.</P><P>The debugging channel is used for communication between thedebugger and the stub which remotely controls the target for thedebugger (the stub runs on the target). This usually happens via someprotocol, encoding commands and replies in some suitable form.</P><P>Having two separate channels allows, e.g., for simple loggingwithout conflicts with the debugger or interactive IO which somedebuggers do not allow.</P></DIV><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN9039">Mangling</H3><P>As debuggers usually have a protocol using specialized commandswhen communicating with the stub on the target, sending out text asraw ASCII from the target on the same channel will either result inprotocol errors (with loss of control over the target) or the text mayjust be ignored as junk by the debugger.</P><P>To get around this, some debuggers have a special command for textoutput. Mangling is the process of encoding diagnostic ASCII textoutput in the form specified by the debugger protocol.</P><P>When it is necessary to use mangling, i.e. when writing consoleoutput to the same port used for debugging, a mangler function isinstalled on the console channel which mangles the text and passes iton to the debugger channel.</P></DIV><DIVCLASS="SECTION"><H3CLASS="SECTION"><ANAME="AEN9044">Controlling the Console Channel</H3><P>Console output configuration is either inherited from the ROMmonitor launching the application, or it is specified by theapplication. This is controlled by the new option<TTCLASS="LITERAL">CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE</TT> whichdefaults to enabled when the configuration is set to use a ROMmonitor.</P><P>If the user wants to specify the console configuration in theapplication image, there are two new options that are used forthis.</P><P>Defaults are to direct diagnostic output via a mangler to thedebugging channel (<TTCLASS="LITERAL">CYGDBG_HAL_DIAG_TO_DEBUG_CHAN</TT>enabled). The mangler type is controlled by the option<TTCLASS="LITERAL">CYGSEM_HAL_DIAG_MANGLER</TT>. At present there are onlytwo mangler types:</P><P></P><DIVCLASS="VARIABLELIST"><DL><DT><SPANCLASS="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 <TTCLASS="LITERAL">CYGDBG_HAL_DIAG_TO_DEBUG_CHAN</TT>, the diagnosticoutput is directed in raw form to the specified console IO port.</P><P>In summary this results in the following common configurationscenarios 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 + -