Information

Enhanced Three-Speed Ethernet Controllers
MPC8308 PowerQUICC II Pro Processor Reference Manual, Rev. 1
Freescale Semiconductor 16-139
16.6.3 TCP/IP Off-Load
Each eTSEC provides hardware support for accelerating the basic functions of TCP/IP packet transmission
and reception. By default, these features are disabled and must be explicitly enabled through RCTRL and
TCTRL. In this configuration, the eTSEC processes frames as vanilla Ethernet frames and none of the
multi-ring QoS/CoS receive services or per-frame VLAN insertion and deletion are available. Operate
eTSEC in this default configuration when using existing TCP/IP stack software that has not been modified
to take advantage of TOE.
TOE can be enabled independently for Rx and Tx and at various levels. Receive TOE functions are
controlled by RCTRL and transmit functions through a combination of TCTRL[TUCSEN] and the Tx
frame control block.
On receive, according to RCTRL[PRSDEP], eTSEC can parse frames at layer 2 of the stack only (Ethernet
headers and switching headers), layers 2 to 3 (including IPv4 or IPv6), or layers 2 to 4 (including TCP and
UDP). TOE provides protocol header recognition, header verification (IPv4 header checksum
verification), and TCP/UDP payload checksum verification including verification of associated
pseudo-header checksums. For large frames off-load of checksum verification saves a significant fraction
Parser error If the receive frame parser is enabled, a parse error can be flagged as a result of inconsistencies
discovered between fields of the embedded packet headers. For example, the L2 header may indicate
an IPv4 header, but the IP version number fails to match. In the event of a parse error, parsing is
terminated at the inconsistent header, and the RxFCB[PERR] field indicates at which layer of the
protocol stack the error was discovered. Receiver function continues regardless of parse errors, but
IEVENT[PERR] is set. The receive queue filer may operate with reduced or default information in some
cases; therefore, filer rule sets should be constructed so as to be tolerant of misformed frames.
Note: Any values in the length/type field between 1500 and 1536 is treated as a length, however, only
illegal packets exist with this length/type since these are not valid lengths and not valid types.
These are treated by the MAC logic as out of range.
Software must confirm the parser and filer results by checking the type/length field after the packet has
been written to memory to see if it falls in this range.
Non-octet error
(dribbling bits)
The Ethernet controller handles a nibble of dribbling bits if the receive frame terminates as non-octet
aligned and it checks the CRC of the frame on the last octet boundary. If there is a CRC error, the
frame non-octet aligned (RxBD[NO]) error is reported, IEVENT[RXF] is set, and the alignment error
counter increments. The eTSEC relies on the statistics collector block to increment the receive
alignment error counter (RALN). If there is no CRC error, no error is reported.
CRC error If a CRC error occurs, the controller sets RxBD[CR], closes the buffer, and sets IEVENT[RXF]. This
eTSEC relies on the statistics collector block to record the event. After receiving a frame with a CRC
error, the receiver then enters hunt mode.
Memory read error A system bus error occurred during a DMA transaction. The controller sets IEVENT[EBERR] and
discards the frame and increments the discarded frame counter (RDRP). In addition the
RSTAT[QHLTn] bit is set. The halted queue resumes reception once the RSTAT[QHLTn] bit is cleared.
Data parity error Data in the receive FIFO or filer table was potentially corrupted. The controller sets IEVENT[DPE], but
otherwise continues reception until halted explicitly.
Babbling receive error A frame is received that exceeds the MAC’s maximum frame length. The controller sets
IEVENT[BABR] and continues.
Table 16-135. Reception Errors (continued)
Error Description