VxWorks API Reference : Driver Libraries
motFcc2End - Second Generation Motorola FCC Ethernet network interface.
motFccEndLoad( ) - initialize the driver and device
motFccRxStallCheck( ) - Check for a Receive stall.
motFccMiiShow( ) - Debug Function to show the Mii settings in the Phy Info
motFccMibShow( ) - Debug Function to show MIB statistics.
motFccShow( ) - Debug Function to show driver specific contol data.
motFccIramShow( ) - Debug Function to show FCC CP internal ram parameters.
motFccPramShow( ) - Debug Function to show FCC CP parameter ram.
motFccEramShow( ) - Debug Function to show FCC CP ethernet parameter ram.
motFccDrvShow( ) - Debug Function to show FCC parameter ram addresses,
This module implements a Motorola Fast Communication Controller (FCC) Ethernet network interface driver. This is a second generation driver that is based off motFccEnd.c. It differs from the original in initialization, performance, features and SPR fixes.
The driver "load string" interface differs from its predecessor. A parameter, that contains a pointer to a predefined array of function pointers, was added to the end of the load string. Adding this structure removed a layer of ambiguity between the driver and the BSP interface. Multiple global function pointers were used previously to provide hooks for the BSP to DPRAM (dual port ram) allocation, mii, duplex mode, heart beat and disconnect functions. See the load string interface below Trying to link a modified version of the previous driver results in link errors. This was due to the global funtion definitions in the driver.
Performace of the driver was greately enhanced. A layer of unnecessary queuing was removed. Time critical functions were re-written to be more fluid and efficent. The drivers work load is distributed between the interrupt and the net job queue. Only one net job add is alowed per interrupt. Multiple events pending are sent as one call as an add to the job queue. TXBDs are freed in the interrupt code. Buffers for the RXBD ring are replenished in the interrupt. Allocation of the Mblks and Cblks happens in the code executing on the job context.
RFC 2233 and IPV6 support were added as features.
SPRs, written against the original motFccEnd driver, are fixed.
The FCC supports several communication protocols. This driver supports the FCC to operate in Ethernet mode which 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.
This device is on-board. No jumpering diagram is necessary.
The driver provides the standard external interface, motFccEnd2Load( ), 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: function table"
- 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.
- 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").
- 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( ).
- 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.
- 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( ).
- 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-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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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. The user does not normally need to set this bit.
This is a pointer to the structure FCC_END_FUNCS. The stucture contains mostly FUNCPTRs that are used as a communication mechanism between the driver and the BSP. If the pointer contains a NULL value, the driver will use system default functions for the m82xxDpram DPRAM alloction and, obviously, the driver will not support BSP function calls for heart beat errors, disconnect errors, and PHY status changes tat are harware specific.
FUNCPTR miiPhyInit; BSP Mii/Phy Init Function This funtion pointer is initialized by the BSP and call by the driver to initialize the mii driver. The driver sets up it's phy settings and then calls this routine. The BSP is responsible for setting BSP specific phy parameters and then calling the miiPhyInit. The BSP is responsible to set up any call to an interrupt. See miiPhyInt bellow.FUNCPTR miiPhyInt; Driver Function for BSP to Call on a Phy Status Change This function pointer is intialized by the driver and call by the BSP. The BSP calls this function when it handles a hardware mii specific interrupt. The driver initalizes this to the function motFccPhyLSCInt. The BSP may or may not choose to call this funtion. It will depend if the BSP supports an interrupt driven PHY. The BSP can also set up the miiLib driver to poll. In this case the miiPhy diver calls this funtion. See the miiLib for details. Note: Not calling this function when the phy duplex mode changes will result in a duplex mis-match. This will cause TX errors in the driver and a reduction in throughput.FUNCPTR miiPhyBitRead; MII Bit Read Funtion This function pointer is intialized by the BSP and call by the driver. The driver calls this function when it needs to read a bit from the mii interface. The mii interface is hardware specific.FUNCPTR miiPhyBitWrite; MII Bit Write Function This function pointer is intialized by the BSP and call by the driver. The driver calls this function when it needs to write a bit to the mii interface. This mii interface is hardware specific.FUNCPTR miiPhyDuplex; Duplex Status Call Back This function pointer is intialized by the BSP and call by the driver. The driver calls this function to obtain the status of the duplex setting in the phy.FUNCPTR miiPhySpeed; Speed Status Call Back This function pointer is intialized by the BSP and call by the driver. The driver calls this function to obtain the status of the speed setting in the phy. This interface is hardware specific.FUNCPTR hbFail; Heart Beat Fail Indicator This function pointer is intialized by the BSP and call by the driver. The driver calls this function to inticate an FCC heart beat error.FUNCPTR intDisc; Disconnect Function This function pointer is intialized by the BSP and call by the driver. The driver calls this function to inticate an FCC disconnect error.FUNCPTR dpramFree; DPRAM Free routine This function pointer is intialized by the BSP and call by the driver. The BSP allocates memory for the BDs from this pool. The Driver must free the bd area using this function.FUNCPTR dpramFccMalloc; DPRAM FCC Malloc routine This function pointer is intialized by the BSP and call by the driver. The Driver allocates memory from the FCC specific POOL using this function.FUNCPTR dpramFccFree; DPRAM FCC Free routine This function pointer is intialized by the BSP and call by the driver. The Driver frees memory from the FCC specific POOL using this function.
This driver requires several external support functions. Note: Funtion pointers _func_xxxxxxxx were removed and replaced with the FCC_END_FUNCS structure located in the load string. This is a major differencd between the old motFccEnd driver and this one.
- sysFccEnetEnable( )
- sysFccEnetDisable( )
- sysFccEnetAddrGet( )
If the driver allocates the memory for the BDs to share with the FCC, it does so by calling the cacheDmaMalloc( ) routine. For the default case of 64 transmit buffers and 32 receive buffers, the total size requested is 776 bytes, and this includes the 8-byte alignment requirement of the device. If a non-cacheable memory region is provided by the user, the size of this region should be this amount, unless the user has specified a different number of transmit or receive BDs.
This driver can operate only if this memory region is non-cacheable or if the hardware implements bus snooping. The driver cannot maintain cache coherency for the device because the BDs are asynchronously modified by both the driver and the device, and these fields share the same cache line.
If the driver allocates the memory for the data buffers to share with the FCC, it does so by calling the memalign () routine. The driver does not need to use cache-safe memory for data buffers, since the host CPU and the device are not allowed to modify buffers asynchronously. The related cache lines are flushed or invalidated as appropriate. For the default case of 7 transmit clusters and 32 receive clusters, the total size requested for this memory region is 112751 bytes, and this includes the 32-byte alignment and the 32-byte pad-out area per buffer of the device. If a non-cacheable memory region is provided by the user, the size of this region should be this amount, unless the user has specified a different number of transmit or receive BDs.
The only adjustable parameters are the number of TBDs and RBDs that will be created at run-time. These parameters are given to the driver when motFccEndLoad( ) is called. There is one RBD associated with each received frame whereas a single transmit packet normally uses more than one TBD. For memory-limited applications, decreasing the number of RBDs may be desirable. Decreasing the number of TBDs below a certain point will provide substantial performance degradation, and is not reccomended. An adequate number of loaning buffers are also pre-allocated to provide more buffering before packets are dropped, but this is not configurable.
The relative priority of the netTask and of the other tasks in the system may heavily affect performance of this driver. Usually the best performance is achieved when the netTask priority equals that of the other applications using the driver.
ifLib, MPC8260 Fast Ethernet Controller (Supplement to the MPC860 User's Manual) Motorola MPC860 User's Manual ,
motFccEndLoad( ) - initialize the driver and device
END_OBJ* motFcc2EndLoad ( char * initString )
This routine initializes both driver and device to an operational state using device specific parameters specified by initString.
The parameter string, initString, is an ordered list of parameters each separated by a colon. The format of initString is:
"immrVal:ivec:bufBase:bufSize:fifoTxBase:fifoRxBase :tbdNum:rbdNum:phyAddr:phyDefMode:pAnOrderTbl:userFlags"
The FCC 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.
A default number of transmit/receive buffer descriptors of 32 can be selected by passing zero in the parameters tbdNum and rbdNum. In other cases, the number of buffers selected should be greater than two.
The bufBase 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. The bufSize parameter is used to check that this region is large enough with respect to the provided values of both transmit/receive buffer descriptors.
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.
If the caller indicates that this routine must allocate the shared memory region, then this routine will use cacheDmaMalloc( ) to obtain some cache-safe memory. The attributes of this memory will be checked, and if the memory is not write coherent, this routine will abort and return NULL.
an END object pointer, or NULL on error.
motFcc2End, ifLib, MPC8260 Power QUICC II User's Manual
motFccRxStallCheck( ) - Check for a Receive stall.
STATUS motFccRxStallCheck ( DRV_CTRL * pDrvCtrl )
This function replenishes the RX BDs and then checks for a receive stall condition. A stall condition is entered when a replenish error is detected and the number of RX BDs full falls bellow a predetermined thresh hold. The stall condition is lifted when the number of RX BDs climbs above the high water mark. The rxStall flag is set accordingly.
ERROR if a stall condition is entered.
motFccMiiShow( ) - Debug Function to show the Mii settings in the Phy Info
void motFccMiiShow ( DRV_CTRL * pDrvCtrl )
structure.
This funtion is only available when MOT_FCC_DBG is defined. It should be used for debugging purposes only.
N/A
motFccMibShow( ) - Debug Function to show MIB statistics.
void motFccMibShow ( DRV_CTRL * pDrvCtrl )
This funtion is only available when MOT_FCC_DBG is defined. It should be used for debugging purposes only.
N/A
motFccShow( ) - Debug Function to show driver specific contol data.
void motFccShow ( DRV_CTRL * pDrvCtrl )
This funtion is only available when MOT_FCC_DBG is defined. It should be used for debugging purposes only.
N/A
motFccIramShow( ) - Debug Function to show FCC CP internal ram parameters.
void motFccIramShow ( DRV_CTRL * pDrvCtrl )
This funtion is only available when MOT_FCC_DBG is defined. It should be used for debugging purposes only.
N/A
motFccPramShow( ) - Debug Function to show FCC CP parameter ram.
void motFccPramShow ( DRV_CTRL * pDrvCtrl )
This funtion is only available when MOT_FCC_DBG is defined. It should be used for debugging purposes only.
N/A
motFccEramShow( ) - Debug Function to show FCC CP ethernet parameter ram.
void motFccEramShow ( DRV_CTRL * pDrvCtrl )
This funtion is only available when MOT_FCC_DBG is defined. It should be used for debugging purposes only.
N/A
motFccDrvShow( ) - Debug Function to show FCC parameter ram addresses,
void motFccDrvShow ( DRV_CTRL * pDrvCtrl )
initial BD and cluster settings.
This funtion is only available when MOT_FCC_DBG is defined. It should be used for debugging purposes only.
N/A