if_eihk.html

vxworks相关论文

<p>

</blockquote><h4>SYSTEM RESOURCE USAGE</h4><blockquote><p>
When implemented, this driver requires the following system resources:
<p>
&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;one&nbsp;mutual&nbsp;exclusion&nbsp;semaphore<br>
&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;one&nbsp;interrupt&nbsp;vector<br>
&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;one&nbsp;watchdog&nbsp;timer.<br>
&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;8&nbsp;bytes&nbsp;in&nbsp;the&nbsp;initialized&nbsp;data&nbsp;section&nbsp;(data)<br>
&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;912&nbsp;bytes&nbsp;in&nbsp;the&nbsp;uninitialized&nbsp;data&nbsp;section&nbsp;(BSS)
<p>
The above data and BSS requirements are for the MC68020 architecture 
and may vary for other architectures.  Code size (text) varies greatly between
architectures and is therefore not quoted here.
<p>
The driver uses <b><i><a href="./cacheLib.html#cacheDmaMalloc">cacheDmaMalloc</a></i>(&nbsp;)</b> to allocate memory to share with the 82596.  
The fixed-size pieces in this area total 160 bytes.  The variable-size 
pieces in this area are affected by the configuration parameters specified 
in the <b><i><a href="./if_eihk.html#eihkattach">eihkattach</a></i>(&nbsp;)</b> call.  The size of one RFD (Receive Frame
Descriptor) is 1536 bytes.  The size of one TFD (Transmit Frame Descriptor) 
is 1534 bytes.  For more information about RFDs and TFDs, see the 
<i>Intel 82596 User's Manual. </i>
<p>
The 82596 can be operated only if this shared memory region is non-cacheable
or if the hardware implements bus snooping.  The driver cannot maintain
cache coherency for the device because fields within the command
structures are asynchronously modified by both the driver and the device,
and these fields may share the same cache line.
<p>

</blockquote><h4>TUNING HINTS</h4><blockquote><p>
The only adjustable parameters are the number of TFDs and RFDs that will be
created at run-time.  These parameters are given to the driver when <b><i><a href="./if_eihk.html#eihkattach">eihkattach</a></i>(&nbsp;)</b>
is called.  There is one TFD and one RFD associated with each transmitted
frame and each received frame respectively.  For memory-limited applications,
decreasing the number of TFDs and RFDs may be desirable.  Increasing the number
of TFDs will provide no performance benefit after a certain point.
Increasing the number of RFDs will provide more buffering before packets are
dropped.  This can be useful if there are tasks running at a higher priority
than the net task.
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./if_eihk.html#top">if_eihk</a></b>, <b><a href="./ifLib.html#top">ifLib</a></b>,  
<i>Intel 82596 User's Manual, </i>
<i>Intel 32-bit Local Area Network (LAN) Component User's Manual </i>

<hr>
<a name="eihkattach"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>eihkattach</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>eihkattach</i>(&nbsp;)</strong> - publish the <b>ei</b> network interface and initialize the driver and device</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>STATUS eihkattach
    (
    int    unit,    /* unit number */
    int    ivec,    /* interrupt vector number */
    UINT8  sysbus,  /* sysbus field of SCP */
    char * memBase, /* address of memory pool or NONE */
    int    nTfds,   /* no. of transmit frames (0 = default) */
    int    nRfds    /* no. of receive frames (0 = default) */
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine publishes the <b>ei</b> interface by filling in a network interface
record and adding this record to the system list.  This routine also
initializes the driver and the device to the operational state.
<p>
The 82596 shares a region of memory with the driver.  The caller of this
routine can specify the address of this memory region, or can specify that
the driver must obtain this memory region from the system resources.
<p>
The <i>sysbus</i> parameter accepts values as described in the Intel manual
for the 82596.  A default number of transmit/receive frames of 32 can be
selected by passing zero in the parameters <i>nTfds</i> and <i>nRfds</i>.
In other cases, the number of frames selected should be greater than two.
<p>
The <i>memBase</i> parameter is used to inform the driver about the shared
memory region.  If this parameter is set to the constant "NONE," then this
routine will attempt to allocate the shared memory from the system.  Any
other value for this parameter is interpreted by this routine as the address
of the shared memory region to be used.
<p>
If the caller provides the shared memory region, then the driver assumes
that this region does not require cache coherency operations, nor does it
require conversions between virtual and physical addresses.
<p>
If the caller indicates that this routine must allocate the shared memory
region, then this routine will use <b><i><a href="./cacheLib.html#cacheDmaMalloc">cacheDmaMalloc</a></i>(&nbsp;)</b> to obtain
some  non-cacheable memory.  The attributes of this memory will be checked,
and if the memory is not both read and write coherent, this routine will
abort and return ERROR.
<p>
</blockquote><h4>RETURNS</h4><blockquote><p>
OK or ERROR.
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./if_eihk.html#top">if_eihk</a></b>, <b><a href="./ifLib.html#top">ifLib</a></b>,  
<i>Intel 82596 User's Manual </i>

<hr>
<a name="eiTxStartup"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>eiTxStartup</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>eiTxStartup</i>(&nbsp;)</strong> - start output on the chip</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>#ifdef BSD43_DRIVER static void eiTxStartup
    (
    int unit
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
Looks for any action on the queue, and begins output if there is anything
there.  This routine is called from several possible threads.  Each will be
described below.
<p>
The first, and most common thread, is when a user task requests the
transmission of data.  Under BSD 4.3, this will cause <b><i>eiOutput</i>(&nbsp;)</b> to be 
called, which calls <b><i>ether_output</i>(&nbsp;)</b>, which will usually call this routine.
This routine will not be called if <b><i>ether_output</i>(&nbsp;)</b> finds that our interface 
output queue is full. In this case, the outgoing data will be thrown out.
BSD 4.4 uses a slightly different model in which the generic <b><i>ether_output</i>(&nbsp;)</b>
routine is called directly, followed by a call to this routine.
<p>
The second, and most obscure thread, is when the reception of certain
packets causes an immediate (attempted) response.  For example, ICMP echo
packets (ping), and ICMP "no listener on that port" notifications.  All
functions in this driver that handle the reception side are executed in the
context of <b><i><a href="./netLib.html#netTask">netTask</a></i>(&nbsp;)</b>.  Always.  So, in the case being discussed, <b><i><a href="./netLib.html#netTask">netTask</a></i>(&nbsp;)</b> 
will receive these certain packets, cause IP to be stimulated, and cause the
generation of a response to be sent.  We then find ourselves following the
thread explained in the second example, with the important distinction that
the context is that of <b><i><a href="./netLib.html#netTask">netTask</a></i>(&nbsp;)</b>.
<p>
The third thread occurs when this routine runs out of TFDs and returns.  If
this occurs when our output queue is not empty, this routine would typically
not get called again until new output was requested.  Even worse, if the
output queue was also full, this routine would never get called again and
we would have a lock state.  It DOES happen.  To guard against this, the
transmit clean-up handler detects the out-of-TFDs state and calls this
function.  The clean-up handler also runs from netTask.
<p>
Note that this function is ALWAYS called between an <b><i>splnet</i>(&nbsp;)</b> and an <b><i>splx</i>(&nbsp;)</b>.
This is true because <b><i><a href="./netLib.html#netTask">netTask</a></i>(&nbsp;)</b>, and <b><i>ether_output</i>(&nbsp;)</b> take care of
this when calling this function.  Therefore, no calls to these spl functions
are needed anywhere in this output thread.
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./if_eihk.html#top">if_eihk</a></b>

<hr>
<a name="eiInt"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>eiInt</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>eiInt</i>(&nbsp;)</strong> - entry point for handling interrupts from the 82596</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>void eiInt
    (
    DRV_CTRL * pDrvCtrl
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
The interrupting events are acknowledged to the device, so that the device
will deassert its interrupt signal.  The amount of work done here is kept
to a minimum; the bulk of the work is defered to the netTask.  Several flags
are used here to synchronize with task level code and eliminate races.
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./if_eihk.html#top">if_eihk</a></b>

</body>
</html>