文件列表:

VxWorks_CS_END (0, 2007-03-17)
VxWorks_CS_END\config.h (12205, 1999-05-07)
VxWorks_CS_END\configNet.h (1502, 2000-10-03)
VxWorks_CS_END\csEnd.c (90203, 2001-05-09)
VxWorks_CS_END\csEnd.h (10868, 2001-05-09)
VxWorks_CS_END\csSysEnd.c (23672, 2001-05-09)
VxWorks_CS_END\note.txt (1432, 2001-05-09)

CIRRUS LAN(tm) CS8900 VxWORKS MUX-Based ENHANCED NETWORK DRIVER (END) =============================================================================== This readme file describes how to install and configure the VxWorks enhanced network driver, version 3.04a, for the Cirrus Logic 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 Cirrus' TECHNICAL SUPPORT 1.0 DRIVER OVERVIEW ======================= The version 3.04a Cirrus LAN(tm) CS8900 MUX-based END Driver for VxWorks provides a high performance interface between the CS8900 Ethernet 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: csEnd.c, csEnd.h, and csSysEnd.c. The csEnd.c and csEnd.h provide BSP-independent routines and definitions while the csSysEnd.c module consists of BSP-dependent routines. Porting the driver to a new BSP requires modification of only the csSysEnd.c module. The current version of the driver is distributed with the csSysEnd.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 upper-layer protocols * Run-time configuration from NVRAM or compile-time configuration supported (no NVRAM required) * IO space or memory space models supported * Support END features: multicasting, polled-mode Ethernet, multi-network protocols, and promiscuous mode. 2. Limitations -------------- * Auto detection 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 Cirrus Logic CS8900 ver. 3.04a network interface driver. If the boot image is loaded through network via FTP, the VxWorks operating system startup code automatically attaches and initializes the CS8900 network interface driver and bind IP to it. 1. Copy the source files ------------------------ The CS8900 network interface driver consists of three source files: csEnd.c -- BSP-independent driver routines csEnd.h -- Header file: CS8900 driver and register defines csSysEnd.c -- BSP-specific driver routines Copy all three files to BSP directory (e.g. c:\tornado\target\config\pc486). 2. Modify the configuration files --------------------------------- The configNet.h and config.h files in the BSP directory needs to be modified. 2.1 Modify the configNet.h file -------------------------------- Comment out or delete the lines related to FEI82557 or other END drivers in the configNet.h file in the BSP directory. Add the following lines to the configNet.h file in the BSP directory: /* Parameters for loading the CS8900 Ethernet driver * * The initialization string format for LOAD_STRING is: * "0xIOAddr:0xIntLevel:0xMemAddr:MediaType:0xConfigFlags" * * where MediaType includes: * MEDIA_AUI 1 * MEDIA_10BASE2 2 * MEDIA_10BASET 3 */ #define CS_LOAD_FUNC csEndLoad #define CS_LOAD_STRING "0x300:0xa:0x0:3:0x0" IMPORT END_OBJ* CS_LOAD_FUNC(char*, void*); END_TBL_ENTRY endDevTbl [] = { { 0, CS_LOAD_FUNC, CS_LOAD_STRING, 1, NULL, FALSE}, { 0, END_TBL_END, NULL, 0, NULL, FALSE}, }; The initialization string specified here are an example configuration typical for an x86 ISA-based system. Change the initialization string as appropriate for your BSP. See the section on Configuration for more information. 2.2 Modify the config.h file -------------------------------- 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=90.0.0.1 e=90.0.0.2 u=userName pw=password" If you want to boot the VxWorks operating system image from the local disk and bind IP to CS8900, the DEFAULT_BOOT_LINE definition should look similar to: #define STANDALONE_NET #define DEFAULT_BOOT_LINE \ "fd=0,0(0,0)host:/fd0/vxWorks h=90.0.0.1 e=90.0.0.2 u=userName o=cs" 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 o = other options "cs" is the name of the CS8900 device. Since the CS8900 driver is an Enhanced Network Driver(END), make sure INCLUDE_END is defined in the config.h file to enable the END functions. Comment out the definition for the Intel's FEI network drivers if you don't need the FEI devices. /* Optional Ethernet devices */ #define INCLUDE_END /* Enhanced Network Driver see configNet.h */ #define END_OVERRIDE /* define if you are using old boot ROMs. */ /*#ifdef INCLUDE_END*/ /*#define INCLUDE_FEI*/ /* include Intel Ether Express PRO100B PCI */ /*#define INCLUDE_FEI_END */ /* END-style Intel Ether Express PRO100B PCI */ /*#define INCLUDE_PCI*/ /* include PCI bus library */ /*#else*/ /*#define INCLUDE_FEI*/ /* include Intel Ether Express PRO100B PCI */ /*#endif *//* INCLUDE_END */ 3. Modify the Makefile ---------------------- You must modify the Makefile in the BSP directory. Add the csEnd.o object file to the MACH_EXTRA variable: MACH_EXTRA = csEnd.o This line causes the linker to include the CS8900 network interface driver object file, csEnd.o, in the VxWorks (or bootrom_uncmp) image. Make sure that the file name of csEnd.c has the same upper or lower cases as csEnd.o defined in MACH_EXTRA. 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 csEnd.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 enhanced network driver is configured via definitions in the "configNet.h" and "csSysEnd.c" files. In addition, the driver can take configuration information from non-volatile 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 "configNet.h" ----------------------- The following definitions are used to configure the CS8900 and specify its hardware interface to the driver and operating system: /* Parameters for loading the CS8900 Ethernet driver * * The initialization string format for LOAD_STRING is: * "0xIOAdr:0xIntLevel:0xMemAddr:MediaType:0xConfigFlags" * * where MediaType includes: * MEDIA_AUI 1 * MEDIA_10BASE2 2 * MEDIA_10BASET 3 */ #define CS_LOAD_FUNC csEndLoad #define CS_LOAD_STRING "0x300:0xa:0x0:3:0x0" IMPORT END_OBJ* CS_LOAD_FUNC(char*, void*); END_TBL_ENTRY endDevTbl [] = { { 0, CS_LOAD_FUNC, CS_LOAD_STRING, 1, NULL, FALSE}, { 0, END_TBL_END, NULL, 0, NULL, FALSE}, }; CS_LOAD_FUNC Name of CS8900 driver's "Load" routine. This value should always be "csEndLoad" (without quotes). CS_LOAD_STRING The initialization string passed into csEndLoad() when the CS8900 driver is loaded. The initialization string format for LOAD_STRING is: "0xIOAddr:IntLevel:0xMemAddr:MediaType:0xConfigFlags" IOAddr IO Base Address This value is the base address of the CS8900 in IO space. Defined in hexadecimal. IntLevel CS8900 Interrupt Request Channel Define as CS8900_INT_LVL. Valid values for CS8900_INT_LVL are: 5, 0xa (10), 0xb (11), or 0xc (12). MemAddr Base address of CS8900 in Memory space. Defined in hexadecimal. If it is set to zero, then the CS8900 chip operates in the mode specified by the EEPROM or the configFlags parameter. MediaType Media type used by CS8900 Defined as: 1 for AUI connector 2 for 10Base-2 (BNC) 3 for 10Base-T (RJ45) configFlags Configuration Flags If any configuration flags are to be defined here, define as a minimum 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. Parameters in "csEnd.c" ------------------------ ALIGMENT_32BIT This definition needs to be defined for the processors that perform 32-bit read/write, such as ARM, Strong ARM, SH3, SH4, and MIPS. If the data buffer for transmission starts on an odd address boundary, copy it to a temporary buffer that starts on an even address boundary, and write the temporary buffer to the CS8900 Chip. Parameters in "csSysEnd.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, 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). 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 specifies which TX start command to use initially before the driver makes any required automatic 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 command 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 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. If you don't need the debug message any more, remove the debug message logging by undefining CS_DEBUG_ENABLE in the csEnd.c file. /*********************** debug macro *******************************/ /* this flag is used to turn DEBUG on or off */ /*#define CS_DEBUG_ENABLE*/ 5.0 PORTING TO A NEW BSP ======================== Starting with the version 2.01 driver, the driver has been divided into two modules: a BSP-independent module "csEnd.c" and a BSP-specific module "csSysEnd.c". In order to port the driver to a new BSP, only the "csSysEnd.c" file should need to be modified. You should not modify the "csEnd.c" file. This will ensure your port is compatible with any future releases of the driver from Cirrus Logic. A "csSysEnd.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 "csEnd.c" and must be replaced with routines appropriate for your hardware configuration. * sysEnetGetConfig( ) This routine takes configuration parameters not specified to csEndLoad() through the InitString from non-volatile storage (e.g. an attached EEPROM) and puts them in the CS_END_DEVICE 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 MIB2 structure. * sysEnetHWInit( ) This routine uses global variables in the CS_END_DEVICE 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 a ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：