m8260fccend.c

Embedded Planet公司的ep8260单板计算机的BSP包（VxWorks）

/* m8260FccEnd.c - END style Motorola FCC Ethernet network interface driver */

/* Copyright 1989-2000 Wind River Systems, Inc. */
#include "copyright_wrs.h"

/*
modification history
--------------------
01g,17sep01,g_h  add support to use without DPRAM lib
01f,13sep01,gev  fix SPR 70254
01e,17jul01,g_h  change to use the DPRAM lib.
01d,10may01,g_h  rename to m8260FccEnd.c
01c,17apr01,g_h  in motFccInitMem() change the memory allocation from memalign() to
                 cacheDmaMalloc() 
01b,08mar01,g_h  modified to run from ROM
01a,18jan01,g_h  written from motFecEnd.c, 01c.
*/

/*
DESCRIPTION
This module implements a Motorola Fast Communication Controller (FCC) 
Ethernet network interface driver. The FCC supports several communication
protocols, and when progammed to operate in Ethernet mode, it is fully 
compliant with the IEEE 802.3u 10Base-T and 100Base-T specifications. 

The FCC establishes a shared memory communication system with the CPU,
which may be divided into three parts: a set of Control/Status Registers (CSR)
and FCC-specific parameters, the buffer descriptors (BD), and the data buffers. 

Both the CSRs and the internal parameters reside in the MPC8260's internal 
RAM. They are used for mode control and to extract status information 
of a global nature. For instance, the types of events that should 
generate an interrupt, or features like the promiscous mode or the 
hearthbeat control may be set programming some of the CSRs properly. 
Pointers to both the Transmit Buffer Descriptors ring (TBD) and the
Receive Buffer Descriptors ring (RBD) are stored in the internal parameter 
RAM. The latter also includes protocol-specific parameters, like the 
individual physical address of this station or the max receive frame length.

The BDs are used to pass data buffers and related buffer information
between the hardware and the software. They may reside either on the 60x
bus, or on the CPM local bus They include local status information and a 
pointer to the incoming or outgoing data buffers. These are located again 
in external memory, and the user may chose whether this is on the 60x bus, 
or the CPM local bus (see below).

This driver is designed to be moderately generic. Without modification, it can
operate across all the FCCs in the MPC8260, regardless of where the internal 
memory base address is located. To achieve this goal, this driver must be 
given several target-specific parameters, and some external support routines 
must be provided.  These parameters, and the mechanisms used to communicate 
them to the driver, are detailed below.

This network interface driver does not include support for trailer protocols
or data chaining.  However, buffer loaning has been implemented in an effort
to boost performance. In addition, no copy is performed of the outgoing packet
before it is sent.
 
BOARD LAYOUT
This device is on-board.  No jumpering diagram is necessary.

EXTERNAL INTERFACE

The driver provides the standard external interface, motFccEndLoad(), which
takes a string of colon-separated parameters. The parameters should be
specified in hexadecimal, optionally preceeded by "0x" or a minus sign "-".

The parameter string is parsed using strtok_r() and each parameter is
converted from a string representation to binary by a call to
strtoul(parameter, NULL, 16).

The format of the parameter string is:

"<immrVal>:<fccNum>:<bdBase>:<bdSize>:<bufBase>:<bufSize>:<fifoTxBase>:
<fifoRxBase> :<tbdNum>:<rbdNum>:<phyAddr>:<phyDefMode>:<userFlags>"

TARGET-SPECIFIC PARAMETERS

.IP <immrVal>
Indicates the address at which the host processor presents its internal 
memory (also known as the internal RAM base address). With this address, 
and the fccNum (see below), the driver is able to compute the location of 
the FCC parameter RAM, and, ultimately, to program the FCC for proper 
operations. 

.IP <fccNum>
This driver is written to support multiple individual device units.
This parameter is used to explicitly state which FCC is being used (on the
vads8260 board, FCC2 is wired to the Fast Ethernet tranceiver, thus this 
parameter equals "2").

.IP <bdBase>
The Motorola Fast Communication Controller is a DMA-type device and typically 
shares access to some region of memory with the CPU. This driver is designed
for systems that directly share memory between the CPU and the FCC.

This parameter tells the driver that space for both the TBDs and the 
RBDs needs not be allocated but should be taken from a cache-coherent 
private memory space provided by the user at the given address. The user 
should be aware that memory used for buffers descriptors must be 8-byte 
aligned and non-cacheable. Therefore, the given memory space should allow
for all the buffer descriptors and the 8-byte alignment factor.

If this parameter is "NONE", space for buffer descriptors is obtained 
by calling cacheDmaMalloc() in motFccEndLoad().

.IP <bdSize>
The memory size parameter specifies the size of the pre-allocated memory
region for the BDs. If <bdBase> is specified as NONE (-1), the driver ignores 
this parameter. Otherwise, the driver checks the size of the provided memory 
region is adequate with respect to the given number of Transmit Buffer
Descriptors and Receive Buffer Descriptors.

.IP <bufBase>
This parameter tells the driver that space for data buffers
needs not be allocated but should be taken from a cache-coherent 
private memory space provided by the user at the given address. The user 
should be aware that memory used for buffers must be 32-byte 
aligned and non-cacheable. The FCC poses one more constraint in that DMA
cycles may initiate even when all the incoming data have already been 
transferred to memory. This means at most 32 bytes of memory at the end of
each receive data buffer, may be overwritten during reception. The driver
pads that area out, thus consuming some additional memory.

If this parameter is "NONE", space for buffer descriptors is obtained 
by calling memalign() in sbcMotFccEndLoad().

.IP <bufSize>
The memory size parameter specifies the size of the pre-allocated memory
region for data buffers. If <bufBase> is specified as NONE (-1), the driver 
ignores this parameter. Otherwise, the driver checks the size of the provided 
memory region is adequate with respect to the given number of Receive Buffer 
Descriptors and a non-user-configurable number of trasmit buffers 
(MOT_FCC_TX_CL_NUM).  All the above should fit in the given memory space. 
This area should also include room for buffer management structures.

.IP <fifoTxBase>
Indicate the base location of the transmit FIFO, in internal memory.
The user does not need to initialize this parameter, as the default
value (see MOT_FCC_FIFO_TX_BASE) is highly optimized for best performance.
However, if the user wishes to reserve that very area in internal RAM for 
other purposes, he may set this parameter to a different value. 

If <fifoTxBase> is specified as NONE (-1), the driver uses the default
value.

.IP <fifoRxBase>
Indicate the base location of the receive FIFO, in internal memory.
The user does not need to initialize this parameter, as the default
value (see MOT_FCC_FIFO_TX_BASE) is highly optimized for best performance.
However, if the user wishes to reserve that very area in internal RAM for 
other purposes, he may set this parameter to a different value. 

If <fifoRxBase> is specified as NONE (-1), the driver uses the default
value.

.IP <tbdNum>
This parameter specifies the number of transmit buffer descriptors (TBDs). 
Each buffer descriptor resides in 8 bytes of the processor's external
RAM space, If this parameter is less than a minimum number specified in the 
macro MOT_FCC_TBD_MIN, or if it is "NULL", a default value of 64 (see
MOT_FCC_TBD_DEF_NUM) is used. This number is kept deliberately high, since 
each packet the driver sends may consume more than a single TBD. This 
parameter should always equal a even number.

.IP  <rbdNum>
This parameter specifies the number of receive buffer descriptors (RBDs). 
Each buffer descriptor resides in 8 bytes of the processor's external
RAM space, and each one points to a 1584-byte buffer again in external 
RAM. If this parameter is less than a minimum number specified in the 
macro MOT_FCC_RBD_MIN, or if it is "NULL", a default value of 32 (see
MOT_FCC_RBD_DEF_NUM) is used. This parameter should always equal a even number.

.IP  <phyAddr>
This parameter specifies the logical address of a MII-compliant physical
device (PHY) that is to be used as a physical media on the network.
Valid addresses are in the range 0-31. There may be more than one device
under the control of the same management interface. The default physical 
layer initialization routine will scan the whole range of PHY devices 
starting from the one in <phyAddr>. If this parameter is 
"MII_PHY_NULL", the default physical layer initialization routine will find 
out the PHY actual address by scanning the whole range. The one with the lowest
address will be chosen.

.IP  <phyDefMode>
This parameter specifies the operating mode that will be set up
by the default physical layer initialization routine in case all
the attempts made to establish a valid link failed. If that happens,
the first PHY that matches the specified abilities will be chosen to
work in that mode, and the physical link will not be tested.
 
.IP  <pAnOrderTbl>
This parameter may be set to the address of a table that specifies the 
order how different subsets of technology abilities should be advertised by
the auto-negotiation process, if enabled. Unless the flag <MOT_FCC_USR_PHY_TBL>
is set in the userFlags field of the load string, the driver ignores this
parameter.

The user does not normally need to specify this parameter, since the default
behaviour enables auto-negotiation process as described in IEEE 802.3u.

.IP  <userFlags>
This field enables the user to give some degree of customization to the
driver.
 
MOT_FCC_USR_PHY_NO_AN: the default physical layer initialization
routine will exploit the auto-negotiation mechanism as described in
the IEEE Std 802.3u, to bring a valid link up. According to it, all
the link partners on the media will take part to the negotiation
process, and the highest priority common denominator technology ability
will be chosen. It the user wishes to prevent auto-negotiation from
occurring, he may set this bit in the user flags.
 
MOT_FCC_USR_PHY_TBL: in the auto-negotiation process, PHYs
advertise all their technology abilities at the same time,
and the result is that the maximum common denominator is used. However,
this behaviour may be changed, and the user may affect the order how
each subset of PHY's abilities is negotiated. Hence, when the
MOT_FCC_USR_PHY_TBL bit is set, the default physical layer
initialization routine will look at the motFccAnOrderTbl[] table and
auto-negotiate a subset of abilities at a time, as suggested by the
table itself. It is worth noticing here, however, that if the
MOT_FCC_USR_PHY_NO_AN bit is on, the above table will be ignored.
 
MOT_FCC_USR_PHY_NO_FD: the PHY may be set to operate in full duplex mode,
provided it has this ability, as a result of the negotiation with other
link partners. However, in this operating mode, the FCC will ignore the
collision detect and carrier sense signals. If the user wishes not to
negotiate full duplex mode, he should set the MOT_FCC_USR_PHY_NO_FD bit
in the user flags.
 
MOT_FCC_USR_PHY_NO_HD: the PHY may be set to operate in half duplex mode,
provided it has this ability, as a result of the negotiation with other link
partners. If the user wishes not to negotiate half duplex mode, he should
set the MOT_FCC_USR_PHY_NO_HD bit in the user flags.
 
MOT_FCC_USR_PHY_NO_100: the PHY may be set to operate at 100Mbit/s speed,
provided it has this ability, as a result of the negotiation with
other link partners. If the user wishes not to negotiate 100Mbit/s speed,
he should set the MOT_FCC_USR_PHY_NO_100 bit in the user flags.
 
MOT_FCC_USR_PHY_NO_10: the PHY may be set to operate at 10Mbit/s speed,
provided it has this ability, as a result of the negotiation with
other link partners. If the user wishes not to negotiate 10Mbit/s speed,
he should set the MOT_FCC_USR_PHY_NO_10 bit in the user flags.
 
MOT_FCC_USR_PHY_ISO: some boards may have different PHYs controlled by the
same management interface. In some cases, there may be the need of
electrically isolating some of them from the interface itself, in order
to guarantee a proper behaviour on the medium layer. If the user wishes to
electrically isolate all PHYs from the MII interface, he should set the
MOT_FCC_USR_PHY_ISO bit. The default behaviour is to not isolate any
PHY on the board.
 
MOT_FCC_USR_LOOP: when the MOT_FCC_USR_LOOP bit is set, the driver will
configure the FCC to work in internal loopback mode, with the TX signal 
directly connected to the RX. This mode should only be used for testing.
 
MOT_FCC_USR_RMON: when the MOT_FCC_USR_RMON bit is set, the driver will
configure the FCC to work in RMON mode, thus collecting network statistics
required for RMON support without the need to receive all packets as in
promiscous mode.
 
MOT_FCC_USR_BUF_LBUS: when the MOT_FCC_USR_BUF_LBUS bit is set, the driver will
configure the FCC to work as though the data buffers were located in the 
CPM local bus.

MOT_FCC_USR_BD_LBUS: when the MOT_FCC_USR_BD_LBUS bit is set, the driver will
configure the FCC to work as though the buffer descriptors were located in the 
CPM local bus.

MOT_FCC_USR_HBC: if the MOT_FCC_USR_HBC bit is set, the driver will
configure the FCC to perform heartbeat check following end of transmisson
and the HB bit in the status field of the TBD will be set if the collision
input does not assert within the heartbeat window (also see _func_motFccHbFail,
below). The user does not normally need to set this bit.
 
.LP

EXTERNAL SUPPORT REQUIREMENTS
This driver requires several external support functions:
.IP sysFccEnetEnable()
.CS
    STATUS sysFccEnetEnable (UINT32 immrVal, UINT8 fccNum);
.CE
This routine is expected to handle any target-specific functions needed 
to enable the FCC. These functions typically include setting the Port B and C
on the MPC8260 so that the MII interface may be used. This routine is 
expected to return OK on success, or ERROR. The driver calls this routine, 
once per device, from the motFccStart () routine.
.IP sysFccEnetDisable()
.CS
    STATUS sysFccEnetDisable (UINT32 immrVal, UINT8 fccNum);
.CE
This routine is expected to perform any target specific functions required
to disable the MII interface to the FCC.  This involves restoring the 
default values for all the Port B and C signals. This routine is expected to 
return OK on success, or ERROR. The driver calls this routine from the 
motFccStop() routine each time a device is disabled.
.IP sysFccEnetAddrGet()
.CS
    STATUS sysFccEnetAddrGet (int unit,UCHAR *address);
.CE
The driver expects this routine to provide the six-byte Ethernet hardware 
address that is used by this device.  This routine must copy the six-byte 
address to the space provided by <enetAddr>.  This routine is expected to 
return OK on success, or ERROR.  The driver calls this routine, once per 
device, from the motFccEndLoad() routine.
.CS
    STATUS sysFccMiiBitWr (UINT32 immrVal, UINT8 fccNum, INT32 bitVal);
.CE
This routine is expected to perform any target specific functions required
to write a single bit value to the MII management interface of a MII-compliant
PHY device. The MII management interface is made up of two lines: management 
data clock (MDC) and management data input/output (MDIO). The former provides
the timing reference for transfer of information on the MDIO signal.
The latter is used to transfer control and status information between the
PHY and the FCC. For this transfer to be successful, the information itself 
has to be encoded into a frame format, and both the MDIO and MDC signals have
to comply with certain requirements as described in the 802.3u IEEE Standard.
There is not buil-in support in the FCC for the MII management interface.
This means that the clocking on the MDC line and the framing of the information
on the MDIO signal have to be done in software. Hence, this routine is 
expected to write the value in <bitVal> to the MDIO line while properly 
sourcing the MDC clock to a PHY, for one bit time.

.CS
    STATUS sysFccMiiBitRd (UINT32 immrVal, UINT8 fccNum, INT8 * bitVal);
.CE
This routine is expected to perform any target specific functions required
to read a single bit value from the MII management interface of a MII-compliant
PHY device. The MII management interface is made up of two lines: management 
data clock (MDC) and management data input/output (MDIO). The former provides
the timing reference for transfer of information on the MDIO signal.
The latter is used to transfer control and status information between the
PHY and the FCC. For this transfer to be successful, the information itself 
has to be encoded into a frame format, and both the MDIO and MDC signals have
to comply with certain requirements as described in the 802.3u IEEE Standard.
There is not buil-in support in the FCC for the MII management interface.
This means that the clocking on the MDC line and the framing of the information
on the MDIO signal have to be done in software. Hence, this routine is 
expected to read the value from the MDIO line in <bitVal>, while properly 
sourcing the MDC clock to a PHY, for one bit time.

.IP `_func_motFccPhyInit'
.CS
    FUNCPTR _func_motFccPhyInit
.CE
This driver sets the global variable `_func_motFccPhyInit' to the 
MII-compliant media initialization routine miiPhyInit(). If the user 
wishes to exploit a different way to configure the PHY, he may set