VxWorksCS8900-BSDdriver
所属分类:VxWorks
开发工具:C/C++
文件大小:39KB
下载次数:6
上传日期:2007-12-12 13:12:13
上 传 者:
ahua5
说明: VxWorks系统实现CS8900网卡的BSD驱动源码,Tornado 2.2
(VxWorks System CS8900 network card driver BSD source, Tornado 2.2)
文件列表:
if_cs.c (77779, 2000-10-09)
if_cs.h (10530, 2000-10-09)
config.h (12929, 1999-03-31)
note.txt (1731, 2000-10-09)
sysEnet.c (21780, 2000-10-09)
CRYSTAL LAN(tm) CS8900 VxWORKS NETWORK INTERFACE DRIVER
===============================================================================
This readme file describes how to install and configure the VxWorks network
interface driver, version 2.07a, for the Crystal Semiconductor CS8900 Ethernet
controller chip.
0.0 TABLE OF CONTENTS
=====================
1.0 DRIVER OVERVIEW
2.0 INSTALLATION
3.0 CONFIGURATION
4.0 DISPLAYING DRIVER STATISTICS and CONFIGURATION
5.0 PORTING TO A NEW BSP
6.0 CONTACTING CRYSTAL'S TECHNICAL SUPPORT
1.0 DRIVER OVERVIEW
=======================
The version 2.07a Crystal LAN(tm) CS8900 Driver for VxWorks provides a high
performance interface between the CS8900 Ethenet Controller and the VxWorks
network communication protocols. This driver has been tested on Intel
[3|4|5]86-based ISA systems and on an IDT R3041 (MIPS) based system. However,
the driver's organization facilitates porting to new BSPs.
The driver is organized in three source file modules: if_cs.c, if_cs.h, and
sysEnet.c. The if_cs.c and if_cs.h provide BSP-independent routines and
definitions while the sysEnet.c module consists of BSP-dependent routines.
Porting the driver to a new BSP requires modification of only the sysEnet.c
module.
The current version of the driver is distributed with the sysEnet.c module for
the x386-based ISA BSP. This module can be used for ISA systems as is or
used as an example for porting the driver to other VxWorks BSPs.
1. Features
-----------
* High Performance
* Supports "Early TX" feature of CS8900
* Automatic retransmission on TX underruns
* Local TX queue permits start of next TX immediately after completion of
previous TX (no ISR/Task level context switch required)
* Local RX frame queue minimizes missed frames
* Supports loaning of local RX buffers to protocol (build_cluster)
* Run-time configuration from NVRAM or compile-time configuration supported
(no NVRAM required)
* IO space or memory space models supported
* Supports "etherInput" and "etherOuput" hook routines
* Support Multicasting and Promiscuous Mode.
2. Limitations
--------------
* Autodetection of media type is not supported. A single media type must be
specified at compile time.
* Driver supports only one CS8900 per system.
3. Known Defects
----------------
No known defects.
4. System Requirements
----------------------
This driver has been designed to build and run using the following software
components:
Tornado Version 1.0.1 (or greater)
VxWorks Version 5.3.1 (or greater)
GNU Toolkit Version 2.7 (or greater)
2.0 INSTALLATION
================
The following installation procedure installs and builds the Crystal
Semiconductor CS8900 ver. 2.07a network interface driver. When the VxWorks
operating system loads and executes, the operating system startup code
automatically attaches and initializes the CS8900 network interface driver.
1. Copy the source files
------------------------
The CS8900 network interface driver consists of three source files:
if_cs.c -- BSP-independent driver routines
if_cs.h -- Header file: CS8900 driver and register defines
sysEnet.c -- BSP-specific driver routines
Copy all three files to BSP directory (e.g. c:\tornado\target\config\pc486).
Verify that the driver file name is "if_cs.c" (all lower case). If the
driver name is not lower case, the driver will not be built.
2. Modify the config.h file
---------------------------
Add the following lines to the config.h file in the BSP directory:
/* Include support for Crystal CS8900 Ethernet controller */
#include "if_cs.h"
#define CS8900_IOBASE 0x300
#define CS8900_MEMBASE 0x0000
#define CS8900_INT_LVL 0xA
#define CS8900_DMA_CHANNEL 0
#define INCLUDE_IF_USR
#define IF_USR_NAME "cs"
#define IF_USR_ATTACH csAttach
#define IF_USR_ARG1 (char*) CS8900_IOBASE /* int IOAddr */
#define IF_USR_ARG2 (INT_NUM_IRQ0 + CS8900_INT_LVL) /* int IntVector */
#define IF_USR_ARG3 CS8900_INT_LVL /* int IntLevel */
#define IF_USR_ARG4 CS8900_MEMBASE /* int MemAddr */
#define IF_USR_ARG5 MEDIA_10BASE2 /* int MediaType */
#define IF_USR_ARG6 CS8900_DMA_CHANNEL /* int DMA Channel */
#define IF_USR_ARG7 (CFGFLG_NOT_EEPROM) /* Config flags */
#define IF_USR_ARG8 NULL /* unused */
The definitions specifed here are an example configuration typical for an x86
ISA-based system. Change the definitions as appropriate for your BSP. See
the section on Configuration for more information.
If you want to boot the VxWorks operating system image over the LAN, then
modify the boot device in the DEFAULT_BOOT_LINE definition to be "cs". The
DEFAULT_BOOT_LINE definition should look similar to:
#define DEFAULT_BOOT_LINE \
"cs(0,0)host:/pc486/vxWorks h=1***.50.50.4 e=1***.50.50.2 u=user pw=password"
where
h = IP address of host (machine where vxWorks image resides)
e = IP address of target
u = ftp account user name on the host
pw = ftp account password on the host
Since the CS8900 driver is BSD 4.4 but not an Enhanced Network Driver(END),
comment out the INCLUDE_END and END_OVERRIDE definitions in the config.h file
to disable the END functions. The BSD 4.4 network interface will be enabled
automatically by VxWorks after END is disabled.
/* Optional ethernet devices */
/*#define INCLUDE_END */ /* Enhanced Network Driver see configNet.h */
/*#define END_OVERRIDE*/ /* define if you are using old boot ROMs. */
3. Modify the Makefile
----------------------
You must modify the Makefile in the BSP directory. Add the if_cs.o object file
to the MACH_EXTRA variable:
MACH_EXTRA = if_cs.o
This line causes the linker to include the CS8900 network interface driver
object file, if_cs.o, in the vxWorks (or bootrom_uncmp) image.
4. Build the Network Interface Driver
-------------------------------------
Add a dependency for the CS8900 network interface driver into the
dependency file for the BSP. You can do this by "cleaning" the BSP directory
and then making VxWorks. Change to the BSP directory on the host and issue the
following two commands:
make clean
make vxWorks
The first command deletes the dependency file, along with other files. The
second command makes the VxWorks image. While making the VxWorks image, the
make utility notices that the dependency file is missing and regenerates it.
The regenerated dependency file includes a dependency for the CS8900 network
interface driver, because the if_cs.c file is sitting in the BSP directory.
To make a boot diskette for an x86 ISA-based system, place a diskette in drive
A: and issuing the following two commands:
make bootrom_uncmp
mkboot a: bootrom_uncmp
3.0 CONFIGURATION
=================
The CS8900 network interface driver is configured via definitions in the
"config.h" and "sysenet.c" files. In addition, the driver can take
configuration information from non-volitale storage such as an EEPROM attached
to the CS8900 or from system ROM. (Refer to the CS8900 Technical Reference
Manual for the format required for configuration data stored in EEPROM.)
Parameters in "config.h"
-----------------------
The following definitions are used to configure the CS8900 and specify its
hardware interface to the driver and operating system:
INCLUDE_IF_USR Define to include support for configurable interface device
IF_USR_NAME The "name" of the device interface.
This value should always be "cs" (with quotes).
IF_USR_ATTACH Name of interface's "attach" routine.
This value should always be "csAttach" (without quotes).
IF_USR_ARG1 IO Base Address
This value is the base address of the CS8900 in IO space.
Define in hexidecimal.
IF_USR_ARG2 Interrupt vector used by CS8900
Define as INT_NUM_IRQ0
IF_USR_ARG3 CS8900 Interrupt Request Channel
Define as CS8900_INT_LVL. Valid values for CS8900_INT_LVL are:
0x5, 0xA, 0xB, or 0xC
IF_USR_ARG4 Base address of CS8900 in Memory space.
Define in hexidecimal.
If the memory address parameter is zero, the CS8900 operates in
the mode specified by EEPROM or the Configuration Flags parameter.
IF_USR_ARG5 Media type used by CS8900
Define as:
MEDIA_AUI for AUI connector
MEDIA_10BASE2 for 10Base-2 (BNC)
MEDIA_10BASET for 10Base-T (RJ45)
IF_USR_ARG6 CS8900 DMA Channel
Define as 0. This driver does not require DMA support.
IF_USR_ARG7 Configuration Flags
If any configuration flags are to be defined here, define as a
miminum the CFGFLG_NOT_EEPROM flag. Set multiple configuration
flags by ORing (adding) them inside of parenthesis. Example:
(CFCFLG_NOT_EEPROM + CFGFLG_MEM_MODE)
This example specifies operation in memory mode and to ignore
configuration data in EEPROM.
Valid configuration flag values:
CFGFLG_NOT_EEPROM
Override configuration flags in EEPROM (if present)
CFGFLG_MEM_MODE
Use memory mode to access the chip
CFGFLG_USE_SA
Use System Address lines to qualify MEMCS16 signal (ISA only)
CFGFLG_IOCHRDY
Extend time for IO access to CS8900 (ISA only)
CFGFLG_DCDC_POL
Specifies the signal level of the DC/DC converter's enable pin
is active high (DC/DC converter used by 10Base-2 transceiver)
CFGFLG_FDX
Configures the CS8900 to use full duplex for the 10Base-T
transmission mode.
CFGFLG_PROMISC_MODE
Configures the CS8900 to the Promiscuous Mode. The CS8900 will
accepts all good network frames in the mode.
IF_USR_ARG8 Unused
Define as NULL
Parameters in "sysEnet.c"
------------------------
CS_MAX_NUM_UNITS
This definition represents the number of CS8900s in the same system supported
by this driver. This value is always one (i.e. the current driver supports
only one CS8900).
CS_NUM_RX_BUFFERS
This value specifies the number of 1500-byte receive buffers allocated by the
driver for local storage of received frames. Receive frames are copied
from the chip into these local receive buffers at the ISR level and passed to
the protocol stack for processing at the task level. Also, by using the
OS's "build_cluster" routine, these receive buffers can be loaned to the
protocol stack during processing, thus preventing an extra copy of the receive
data (from the local receive buffer into a protocol mbuf chain). For best
ethernet throughput, set this value to largest number feasible based on your
system's memory constraints.
CS_MAX_QUEUE
This value is the maximum number of elements in the local TX and RX queue.
The RX queue holds pointers to local RX buffers to be passed to the protocol
stack for processing at task level. The TX queue holds pointers to mbuf
chains to be freed at the task level (frames that have been transmitted).
Typically, this value is set to the maximum number of mbufs specified for the
system (MAX_MBUFS -- defined in mbuf.h).
STRESS_TESTING
This boolean value controls the output of debug messages for RX frames that
are not processed by the CS8900 when on-chip buffer space is not available.
If driver debug messages are enabled, a message is output to the display device
for each RX frame that is missed. During extremely heavy traffic, such as
during stress testing, these messages can become numerous, adding to the
systems processing overhead and therby adding to the number of RX frames
missed. Setting this value to TRUE suppresses output of messages for missed
RX frames. However, statistics for RX misses are still updated and can be
output using the csShow() routine.
CS_INITIAL_START_CMD
The CS8900 is capable of starting the TX operation before the full frame is
copied to the on-chip TX buffer. However, this operation mode creates the
possibility of a "TX underrun", i.e. the transmitter may run out of data
before the full frame is buffered if the TX frame copy to chip is delayed or
slower than one byte per 0.8ms (wire data rate).
Part of the TX command to the CS8900 specifies the number of bytes to be
buffered before the transmission on the wire begins. If excessive TX
underruns occur, the driver automatically adjusts the TX command to start
the next TX after additional bytes are buffered. The possible values for
the number of bytes buffered before the TX starts are: 5, 381, 1021, or a
full frame.
CS_INIITIAL_START_CMD specifes which TX start command to use initially before
the driver makes any required automtic adjustments. Valid definitions for
CS_INITIAL_START_CMD are:
TX_CMD_START_5 (start after 5 bytes buffered)
TX_CMD_START_381 (start after 381 bytes buffered)
TX_CMD_START_1021 (start after 1021 bytes buffered)
TX_CMD_START_ALL (start after the full frame is buffered)
Refer to the CS8900 Datasheet for more information on transmit operation.
#define CS_TX_UNDRUN_TRHSHOLD 3
This value specifies the number of TX underruns allowed while using the
current TX start comand before the driver automatically adjusts the command
to start the next transmission after additional bytes are buffered.
4.0 DISPLAYING DRIVER STATISTICS AND CONFIGURATION
==================================================
The network interface driver includes a display routine, called csshow(), which
displays driver configuration and statistics information. To invoke the
display routine, at the shell prompt, type:
-> csshow
To reset the statistics to zero, type at the shell prompt:
-> csshow 0, 1
Another routine that you may find useful is:
-> ifshow "cs0"
Message Logging
---------------
If the network interface debug flag is set, then the network interface driver
logs significant events and error messages to the logging task. The default
behavior of the logging task is to display logging messages on the console.
To set the debug flag, issue the following command at the shell prompt:
-> ifflagchange "cs0", 4, 1
To clear the debug flag, issue the following command at the shell prompt:
-> ifflagchange "cs0", 4, 0
You can use the csshow() routine to view the current state of the debug flag.
5.0 PORTING TO A NEW BSP
========================
Starting with the version 2.01 driver, the driver has been divided into two
moduels: a BSP-independent module "if_cs.c" and a BSP-specific module
"sysenet.c". In order to port the driver to a new BSP, only the "sysenet.c"
file should need to be modifed. You should not modify the "if_cs.c" file.
This will ensure your port is compatible with any future releases of the driver from Crystal Semiconductor.
A "sysenet.c" module written for a 386 BSP is provided with this driver as an
example.
Big Endian and Little Endian Architectures
------------------------------------------
A macro for byte-swapping is defined based on the _byte_order definition in the
vxworks header file "arch.h". For "big endian" CPUs, the macro is defined to
swap the order of bytes for access to CS8900 registers. For "little endian"
CPUs, the macro does nothing.
Note: The use of this macro assumes that the hardware data lines to the CS8900
have been "byte swapped" in big endian systems. That is, CPU D0 connected to
CS8900 D8, CPU D1 connected to CS8900 D9, etc. Using this technique, only
counter-register values must be byte swapped in real time. All other values
are byte swapped at compile time using definitions in the header file. Network
data is never byte swapped in software. This is handled by the CS8900
hardware.
Macros
------
Three macros are used to communicate with the CS8900 in IO mode. For the
pc386/pc486 BSPs, they call system routines provided by VxWorks/PCX86 for
IO space access. For non x86-based BSPs, they need to be redefined as
appropriate for your BSP's architecture (e.g. a memory dereference if IO
space is not supported).
/* X86 BSP macro definitions used to provide IO mode accesses */
#define SYS_ENET_OUT_WORD(port, value) sysOutWord((port), (value))
#define SYS_ENET_IN_WORD(port) sysInWord(port)
#define SYS_ENET_IN_BYTE(port) sysInByte(port)
/* Example macros used to "emulate" io space access for non-Intel CPUs */
#define SYS_ENET_OUT_WORD(port, value) (*(volatile USHORT*)(port)) = (value)
#define SYS_ENET_IN_WORD(port) (*(volatile USHORT*)(port))
#define SYS_ENET_IN_BYTE(port) (*(volatile UCHAR*)(port))
BSP-specific Routines
---------------------
The following five BSP-specific routines are called from the main driver
module "if_cs.c" and must be replaced with routines appropriate for your
hardware configuration.
* sysEnetGetConfig( )
This routine takes configuration parameters not specifed to csAttach() through
the IF_USR definitions from non-volatile storage (e.g. an attached EEPROM) and
puts them in the cs_softc structure.
* sysEnetAddrGet( )
This routine obtains the Ethernet MAC address from non-volatile storage or from
the "csEnetAddr" array defined in sysEnet.c and saves it in the interface's
arpcom structure.
* sysEnetHWInit( )
This routine uses global variables in the cs_softc structure to configure the
adapter for the board-specific IO circuitry and supported media types.
* sysEnetIntEnable( )
This routine enables the interrupt used by the CS8900 at the system level. It
may not be required by your BSP. If not, implement as a stub (empty routine).
* sysEnetIntDisable( )
This routine disables the interrupt used by the CS8900 at the system level. It
may not be required by your BSP. If not, implement as a stub (empty routine).
You may add any support routines to be called by the above required routines
as you wish.
6.0 CONTACTING CRYSTAL'S TECHNICAL SUPPORT
==========================================
Crystal's CS8900 Technical Support can be reached at:
Telephone :(800) 888-5016 (from inside U.S. and Canada)
:(512) 442-7555 (from outside the U.S. and Canada)
Fax :(512) 912-3871
Email :ethernet@crystal.cirrus.com
Web :www.crystal.com
近期下载者:
相关文件:
收藏者: