📄 tgtsvr.html
字号:
<html><head><!-- /vobs/wpwr/docs/tornado/tools/tgtsvr.html - generated by refgen from tgtsvr.c --> <title> tgtsvr </title></head><body bgcolor="#FFFFFF"> <hr><a name="top"></a><p align=right><a href="libIndex.html"><i>Tornado Reference : Tornado Tools</i></a></p></blockquote><h1>tgtsvr</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote> <p><strong>tgtsvr</strong> - the target board server </p></blockquote><h4>SYNOPSIS</h4><blockquote><p><pre>tgtsvr [-A.llsyms] [-B.ackend <i>backendName</i>] [-Bd.ebug <i>fileName</i>] [-Bm.ax <i>size</i>] [-b.ps <i>linespeed</i>] [-Br.esend <i>number</i>] [-Bt.imeout <i>timeout</i>] [-C.onsole] [-c.ore <i>fileName</i>] [-d.evice <i>device</i>] [-display <hostName:0>] [-f.ormat <i>formatName</i>] [-h.elp] [-hfc] [-L.ock] [-m.emory <i>nbytes</i>] [-n.ame <i>serverName</i>] [-N.osyms] [-p.ort <i>portNumber</i>] [-R <i>TSFS_root</i>] [-redirectIO] [-redirectShell] [-RW] [-s.ynchro] [-use_portmapper] [-u.sers <i>fileName</i>] [-V.erbose] [-v.ersion] [-Wd.ebug <i>fileName</i>] [-Wf.ilter <i>request</i>] [-Wm.ax <i>size</i>] <i>targetName</i> [backend specific options]</pre><p></blockquote><h4>DESCRIPTION</h4><blockquote><p>The target server is the Tornado component that allows development tools,such as the shell (see <b><a href="./windsh.html#top">windsh</a></b>) or a debugger, to communicate with aremote target system, such as VxWorks. The Tornado tools areautonomous programs running on a cross-development host. They areattached to a particular target server when they begin executing.<p>The server communicates with the target system through an interfacecalled the<i>target agent. </i>This agent is either integrated with the target system (for instance, as atask), or independent from it. When <b><a href="./tgtsvr.html#top">tgtsvr</a></b> is started, it identifiesthe target agent by means of the only required argument: the name of atarget board running the target agent.<p>The name of the target board is linked with the name of the hostmachine where the target server runs, to form a unique identifier usedthroughout the working session by all tools. This name is recorded inthe name database of the Tornado<i>Service Registry </i>(see <b><a href="./wtxregd.html#top">wtxregd</a></b>).The form of this identifier is <i>targetName</i>@<i>serverHost</i>. For instance,<b>tPad@aven</b> refers to the target named <b>tPad</b> as represented by a targetserver running on the host <b>aven</b>.<p>An alternative target name, however, may be specified with the <b>-n</b> optionif the board name is already in use.<p>Tools may use truncated identifiers, if the short names match a uniquename among all names registered by the Tornado Registry (see <b><a href="./launch.html#top">launch</a></b>and <b><a href="./wtxregd.html#top">wtxregd</a></b>). Any unique substring in the board name is sufficient,and the "@" extension may be omitted as well.<p>The target server gets requests from the Tornado tools. Theserequests, depending on their type, may either be satisfied by thetarget server itself, or require that the target server in turn sendrequests to the target agent.<p></blockQuote><h4>Locating the Target Executable</h4><blockQuote>The target server depends on a host-resident image of the targetexecutable. By default (if the <b>-c</b> option is not specified), thetarget server queries the agent running on the target for thispath name. The default works well for the common situation where theruntime code is downloaded from the host. However, in somesituations (for example, if the target is running a standaloneversion of VxWorks generated from another host), the target agentcannot supply a useful path for the executable on the host. In thissituation, use the <b>-c</b> option to specify the path explicitly. Environmentvariables and <b>~</b> are recognized and expanded by the target server as follow:<p><b>`~`</b>, if given as first character of the pathname, is expanded to the user's homedirectory, or if another user is specified (<b>"~joe"</b>), <b>`~`</b> will expanded to joe'shome directory. <b>WIN32 users</b>, <b>`~`</b> will be expanded to the environmentvariable <b>"$HOME"</b>, or <b>"$HOMEDRIVE$HOMEPATH"</b> if <b>"$HOME"</b> is not defined. Ifnone of these variables are defined, <b>`~`</b> will be ignored.<p>Environment variables can be set by using <b>"$VAR"</b>, <b>"$(VAR)"</b> and <b>"{VAR}"</b> notation.They will be expanded to the value set up on the target server's environment,or will be ignored if they are not defined.<p><b>"~/$(VXWORKS).exe"</b> pathname will be expanded to <b>"/home/joe/proj/vxWorks.exe"</b> ifthe user's home directory is <b>"/home/joe"</b>, and <b>VXWORKS</b> is set to<b>"proj/vxWorks"</b>.<p></blockQuote><h4>Authentication and Access Permission</h4><blockQuote>The target server allows for user access permission to be restricted.The resource file <b>$<b>WIND_BASE</b>/.wind/userlock</b>can be created to hold a list of authorized user IDs (a single + signmeans that universal access is allowed). If this file does not exist, the target server will assume that no user restriction will apply. Alternative resource files may be specified with the <b>-u</b> option. A targetserver restricted in this way refuses any requests from tools started by an unauthorized user.<p>It is also possible to lock a target server with the <b>-L</b>option. Then only the user that starts the target server can connecttools to that server (see also the Reserve and Unreserve menu items of<b><a href="./launch.html#top">launch</a></b>).<p></blockQuote><h4>Target Server Components</h4><blockQuote>The target server is made up of the following units:<ul><li>communication unit with the tools.</li><li>communication unit, or<i>back end, </i>with the target agent.</li><li>object module management unit (loader, unloader).</li><li>target symbol table management unit.</li><li>target memory management unit.</li><li>virtual input/output management unit. </ul><p><p></blockQuote><h4>WTX Protocol</h4><blockQuote>Communication between the target server and the Tornado tools is done via theRPC/XDR mechanism. Tools' requests and target servers' answers or events followthe formats defined by the Wind River Tool Exchange (WTX) messaging protocol.There is no requirement for the Tornado tools and the target server to operatefrom the same host machine. They may be distributed across a network.<p>If the <b>-Wd</b> option is specified, all WTX requests are logged in a log file.The default behaviour is to append log messages at the end of the log file (ifit does not exists, it will be created).If the <b>-Wm</b> option is also specified, the file size will be limited to thegiven value, and written as a circular file: i.e. when this value is reached,the file is rewritten from the begining. If the file exists, it will be erased.<p>Note that a tool can be connected to more than one target server allowing formanaging data coming from several remote target systems.<p>The <b>-Wf</b> option can be used to filter a particular WTX request in the logfile. The default filter is set to "<b><a href="../../tornado-api/wtxpcl/wtx.html#WTX_EVENT_GET" >WTX_EVENT_GET</a></b>" to avoid thousands ofsuch request when a wind shell version 1 is connected to the targetserver.<p></blockQuote><h4>Back Ends</h4><blockQuote>The target server's back end is the intermediary for all communicationwith the target agent. Thus, the back end must be designed to usewhatever communication protocol and transport layer the agentuses. Because not all agents can use the default protocol (WDB overRPC/XDR) and transport layer (Ethernet), alternative back ends can bespecified explicitly. Custom back ends are also possible.<p>The following back ends are supported by Wind River Systems(see <$<b>WIND_BASE</b>>/host/<$<b>WIND_HOST_TYPE</b>>/lib/backend):<p><dl><dt><b>wdbrpc</b> (default)<dd>The Tornado WDB RPC back end. It is the most frequently used, and supportseither Ethernet or serial connections. This back end supports eithersystem-level or task-level views of the target.<p><dt><b>wdbpipe</b><dd>This back end is to be used on all simulators. It is based on named pipeson UNIX hosts and mailslots for windows hosts.<p><dt><b>wdbserial</b><dd>A version of the WDB back end supporting only serial hardware connection.Note that in order to use this back end the serial connection should only use the "Tx", "Rx" and "Gnd" signals by default. When the <b>-hfc</b>(hardware flow control) optionis used, the "RTS", "CTS" and "DTR" signals are also supported.<p><dt><b>netrom</b><dd>A proprietary communications protocol for NetROM, a networked ROM emulatorfrom Applied Microsystems Corporation.<p><dt><b>loopback</b><dd>A testing back end. This back end is not useful for connecting to targets;it is used only to exercise the target server daemon during tests. </dl><p>Use the <b>-B</b> option to select an alternative back end.<p>If the target agent is connected through the <b>wdbserial</b> back end, target serveroptions <b>-d</b> and <b>-b</b> allow the tty device and the serial line speed to be specified,respectively. The <b>-hfc</b> option activates hardware flow control on theserial link.<p>If the target agent is connected through the <b>wdbrpc</b> backend, the <b>-p</b> optionallows to specify the UDP port number.<p>If the communication link between the target server and the target agentis slow, it may be necessary to adjust the back end timeout value (withthe <b>-Bt</b> option), as well as the back-end retry count (with the <b>-Br</b> option).<p>Back ends may also provide their own set of options (see <i>Tornado API Guide </i>for details). The back end options are shown first. These options can beviewed with:<pre> tgtsvr -B <bkendName> -h</pre>The WDB requests can be logged on a file by using the <b>-Bd</b> option.The default behaviour is to append log messages at the end of the log file (ifit does not exists, it will be created).If the <b>-Bm</b> option is also specified, the file size will be limited to thegiven value, and written as a circular file: i.e. when this value is reached,the file is rewritten from the begining. If the file exists, it will be erased.<p></blockQuote><h4>Object Module Management</h4><blockQuote>The target server may handle object modules from various format (currently, a.out COFF, ELF, SOM, and pecoff). The core fileis analyzed in order to determine what object module format will be used for theworking session. It is possible to bypass this determination with the <b>-f</b> option followed by a format name. Supported format names can be found in theresource file:<b>$<b>WIND_BASE</b>/host/resource/target/architecturedb</b>.The target server can be extended to support new Object Module Format (see "Object Module Loader" in <i>Tornado API Guide </i>).<p></blockQuote><h4>Target Symbol Table</h4><blockQuote>The target server maintains (on the host) a symbol table for thetarget executable. It builds this symbol table from an input filecalled the<i>core file. </i>The symbols and memory locations obtained from this file are used tocalculate relocation information when linking other user modules. Thetarget server normally obtains the location of the core file from thetarget agent (in which case it is the file originally used as theexecutable for the agent itself). However, because the core file mayno longer be in the location where it was used to load the agent, apath name for it can also be specified explicitly with the <b>-c</b> option (see <i>Locating the Target Executable </i>above for giving an alternate path name).<p>It is also possible to prevent the target server from building thetarget symbol table from the core file with the <b>-N</b> option.If the target server is started with this option, the first file to beloaded must be a "fully-linked" object file (an object file with no externalreferences). Any subsequent modules loaded may be relocatable; theserver calculates relocation information by reference to that first loadedobject file.<p>Using the <b>-A</b> option forces the target server to include all globaland local symbols from the core file in the target server symbol table.<p></blockQuote><h4>Target Memory Management</h4><blockQuote>The target server manages the target agent memory pool on the remote system.This memory pool is mainly used by the loader when object files are downloaded.The target server automatically increases the size of the agent memory poolwhen necessary (when there is not enough room to load a file, for example).A cache is implemented so that memory-related requests from Tornadotools may be satisfied at the target server level, avoiding the transfer ofdata from the real target memory. This cache has a default maximumsize of 1 MB.<p>The <b>-m</b> option allows to specify a maximum size for the cache. This may berequired when the agent memory pool size becomes greater than the maximum sizeof the cache. In this situation, the memory-related requests that fall outsidethe cache are satisfied at the target level, and thus are substantially slower.<p>The Tornado <b><a href="./browser.html#top">browser</a></b> provides a graphical view of the target agent memorypool utilization.<p></blockQuote><h4>Virtual Input/Output Mechanism</h4><blockQuote>The target server can redirect data through<i>virtual Input/Output channels. </i>For target tasks to have access to this mechanism, a<i>Virtual I/O Driver </i>must be included in the target system. When this driver is included, anytask on the target may open a virtual channel to read from, or write to,that channel. On the host, any tool may open the same virtual channel towrite to, or read from, that channel. Thus the target server acts as anI/O dispatcher, multiplexing whatever physical communications layer isavailable to allow run-time tasks and host tools to communicate easily.<p>When the target server is started with the <b>-C</b> option, a console windowattached to virtual channel 0 is displayed. On UNIX, this window can bedisplayed on a specified X server (including a host other than where thetarget server is running) with the <b>-display</b> option. The number of bufferedlines (default 88) can be changed by setting the environment variable<b>WTX_CONSOLE_LINES</b> to the number of desired buffered line. Set this variablebefore starting your UNIX target server.<p>This permits any task on the target to open virtual I/O channel 0 to sendcharacters to, or read characters from, this window. If started with<b>-redirectIO</b>, a redirection of target standard I/O is automatically done.If <b>-redirectIO</b> is set, but <b>-C</b> flag is not set, the target I/O will beredirected to the target server, but, since no console will be present todisplay the informations, events will be sent to the connected WTX tools.<p>The target server can also be used as a virtual target shell console: Theshell is running on the target, and its I/O are done from the target servervirtual console. To do this, use the <b>-redirectShell</b> flag in conjonctionwith <b>-C</b> flag. The target server will automatically redirect the targetshell I/O into the default target server console. The shell must beincluded in the target system. This feature is usefull if target is onlyaccessible through back end and actions which cannot be done via windsh(like loading object from a file system local to the target) have to beperformed.<p><dl><dt><b>CAVEAT</b><dd> </dl><p>Redirecting target I/O into the target server's console may lead side effects:<ul><li>If you use <b>-redirectIO</b> when a target shell is running, its I/O will alsoget redirected in the target server's console. You will see a double echo (oneecho for the target server console, and another one by the target shell itself),and the target Shell input will be lost when the target server stops. Use the<b>-redirectShell</b> in conjonction with <b>-redirectIO</b> option to avoid this.</li><li><b>-redirectIO</b> and <b>-redirectShell</b> flags are not exclusives. They can be jointly used. But in this case, only the target shell will get its input from the target server's console. Other tasks pending on a read on their <b>stdin</b> willpend forever (unless the targetShell is destroyed).</li><li>If you use Windsh with a target server which has <b>-redirectIO</b> and <b>-C</b> set,remember that windsh also redirects the I/O. So if you try <pre> scanf ("%s", buf)</pre>from the command line the input will be done by the windsh, not from the targetserver's console.</li><li>If you use windsh with a target server which has not set <b>-redirectIO</b> and try a command which launches another task which wants to write messages, you won't see them: the child tasks get their I/O reset to the global I/Odescriptors (if the target server was launched with <b>-C</b>, those outputs will besent in the target server's console). Setting <b>-redirectIO</b> without <b>-C</b> will permit to see the task's child output into the windsh which launched them.But be aware that ALL TOOLS will be notified of the target's task ouptut.</li><li>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -