Freescale Semiconductor Chip Errata MPC8548ECE Rev. 6, 6/2012 MPC8548E Chip Errata This document details all known silicon errata for MPC8548E PowerQUICC III devices. Table 1. Revision history Revision Date Substantive changes 6 6/2012 * Renamed DUART 1 to A-004737 and CPU-A005 to A-001428. * Added CPU erratum A-005125. * In Table 2, updated the PVR value for 3.1.x from 0x8021_0023 to 0x8021_0022. 5 1/2012 * * * * * * * * 4 4/2011 Added Rev 3.1.x silicon information Added CPU erratum A-003477 Removed eTSEC 102, fixed in Rev 2.0 silicon Updated Fix plan for for CPU-A005, eTSEC 34, eTSEC 38, eTSEC 57, eTSEC 58, eTSEC 59, eTSEC 62, eTSEC 63, eTSEC 64, eTSEC 65, eTSEC 66, eTSEC 67,eTSEC68, eTSEC 69, eTSEC 71, eTSEC 72, eTSEC 73, eTSEC 74, eTSEC 76, eTSEC 77, eTSEC 78, eTSEC 79, eTSEC 81, eTSEC 82, eTSEC 83, eTSEC 84, eTSEC 85, eTSEC 87, eTSEC 88, eTSEC 89, eTSEC 90, eTSEC 92, eTSEC 93,eTSEC 94, eTSEC 95, eTSEC 98, eTSEC 99, eTSEC 101, eTSEC 104, eTSEC 105, eTSEC 106, eTSEC 107, eTSEC-A001, eTSEC-A004, PCI-Ex 35, PCI-Ex 37, PCI-Ex 38, PCI-Ex 39, PCI-Ex 42, PCIe-A001, SRIO-A002, GEN 11, GEN13, I2C 2, DMA 1, and DMA 2 In Table 2, Corrected SVR values for 'without security.' The leading digit was missing. Modified CPU 4 workaround In Table 3, corrected silicon revisions impacted for JTAG 2 Modified eTSEC 93 description * Added eTSEC-A005 * Modified impact for CPU 3 and SEC-A001 Table continues on the next page... (c) 2012 Freescale Semiconductor, Inc. General Business Information Table 1. Revision history (continued) Revision Date Substantive changes 3 10/2010 * Added CPU-A001, CPU-A005, eTSEC 106, eTSEC 107, eTSEC-A001, eTSECA002, eTSEC-A004, PCI-Ex 42, PCIe-A001, SEC-A001, SRIO-A002, SRIO-A004, I2C 2 and I2C 3. * Added OMnDATR note to Description on SRIO42. * Removed PCI-Ex 40 due to duplicate entry. * Updated disposition for eTSEC 104, SEC 5, SEC 6. * Updated workaround for eTSEC 79. * In Table 3, removed Rev. 1.1, 1.1.1, and 1.1.2 columns. * In DUART 1, removed stray text after fixplan, incorrectly showing in Rev. 2. * In SEC 8, changed byte to bit throughout. * In PM2, changed PMCx value in workaround. * Removed PM3, it was fixed in Rev. 2.0. * In eTSEC72, changed "Compound Rule Example" table entry 2, RQPROP value in workaround. 2 02/2009 * Changed DDR 20 by adding note explaining location of debug registers used in work around. * Added SRIO 41. * Added SerDes 1. * Added eTSEC 105. * Modified disposition for eTSEC 39. * Modified workaround for eTSEC 79. * Removed eTSEC 103. * Added SRIO 42. * Updated information in Table 2, "Revision Level to Part Marking CrossReference." 1 01/2009 * Added PCI-Ex 41 and SEC 8. * Changed 5M to 6M for supported mask set in Table 2. 0 12/2008 Initial release The following table provides a cross-reference to match the revision code in the processor version register to the revision level marked on the device. Table 2. Revision Level to Part Marking Cross-Reference Revision 2.0.1 2.1.1 e500v2 Core Revision 2.0 2.2 Processor Version Register Value 0x8021_0020 0x8021_0022 System Version Register Value Device Marking With security 0x8039_0020 2M39E Without security 0x8031_0020 3M39E With security 0x8039_0021 6M39E Without security 0x8031_0021 2.1.2 2.2 0x8021_0022 With security 0x8039_0021 7M39E Without security 0x8031_0021 3.1.x 2.3 0x8021_0022 With security 0x8039_0031 1N06D, 2N06d Without security 0x8031_0031 MPC8548E Chip Errata, Rev. 6, 6/2012 2 Freescale Semiconductor, Inc. General Business Information The following table summarizes all known errata on the MPC8548E device and lists the corresponding silicon revision level to which it applies. A `Yes' entry indicates the erratum applies to a particular revision level, while a 'No' entry means it does not apply. Table 3. Summary of Silicon Errata and Applicable Revision Errata Name Projected Solution Silicon Rev. 2.0 2.1.x 3.1.x CPU CPU 2 A core hang possible while executing a msync or mbar 0 instruction and a snoopable transaction from an I/O master tagged to make quick forward progress is present. Fixed in Rev 2.1 Yes No No CPU 3 "mbar MO = 1" instruction fails to order caching-inhibited guarded loads and stores No plans to fix Yes Yes Yes CPU 4 Single-precision floating-point zero value may have the wrong sign No plans to fix Yes Yes Yes CPU 5 Branch Fails to Decrement CTR in Presence of D-cache Parity Error No plans to fix Yes Yes Yes CPU 6 Incorrect Value May be Loaded Into SRR0 on ITLB Miss When Executing icbtls No plans to fix Yes Yes Yes Flash-Invalidation of TLB1 with "mtspr MMUCSR0" may fail No plans to fix Yes Yes Yes Enabling IEEE 754 exceptions can cause errors Fixed in Rev 3.1.x Yes Yes No A-003477 Phantom branches in the BTB may not be correctly invalidated No plans to fix Yes Yes Yes A-005125 In a very rare condition, a system hang is possible when the No plans to fix e500 core initiates a guarded load to PCI/PCIe/sRIO while the PCI/PCIe/sRIO performs a coherent write to memory. Yes Yes Yes CPU-A001 A-001428(CPUA005) eTSEC eTSEC 29 Frame is dropped with collision and HALFDUP[Excess Defer] = 0 No plans to fix Yes Yes Yes eTSEC 34 Transmit frames aborted under 16-bit FIFO GMII-style mode Fixed in Rev 3.1.x Yes Yes No eTSEC 36 TX_EN of eTSEC1 and eTSEC2 may be driven randomly during reset Fixed in Rev 2.1 Yes No No eTSEC 37 eTSEC Parser does not properly parse L3 fields Fixed in Rev 2.1 Yes No No eTSEC 38 WWR bit Anomaly Fixed in Rev 3.1.x Yes Yes No eTSEC 39 Parsing of tunneled IP packets not supported No plans to fix Yes Yes Yes eTSEC 40 Magic packet does not wake device from a SLEEP state No plans to fix Yes Yes Yes eTSEC 44 FIFO8, FIFO16 TX hang Fixed in Rev 2.1 Yes No No eTSEC 45 Tx data corruption in FIFO16 mode Fixed in Rev 2.1 Yes No No eTSEC 46 RSTAT[RXF0] set regardless of destination ring if WWR=0 Fixed in Rev 2.1 Yes No No eTSEC 47 VLAN strip must be disabled if the parser is disabled Documentation update Yes No No eTSEC 48 Receive frame filer must be disabled if the parser is disabled Documentation update Yes No No Table continues on the next page... MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 3 General Business Information Table 3. Summary of Silicon Errata and Applicable Revision (continued) Errata Name Projected Solution Fixed in Rev 2.1 Silicon Rev. 2.0 2.1.x 3.1.x Yes No No eTSEC 49 Tx IP and TCP/UDP Checksum Generation not supported for some Tx FCB offsets eTSEC 50 Value of TBYT register may not match bytes transmitted for Documentation truncated frames update Yes No No eTSEC 51 Missing basic integrity check for parsing Tunneled IP packets No plans to fix Yes Yes Yes eTSEC 52 Error in arbitrary extraction offset Fixed in Rev 2.1 Yes No No eTSEC 55 Transmit jumbo frames greater than 2400 bytes may cause Fixed in Rev 2.1 lost data, loss of BD synchronization, or false underrun error Yes No No eTSEC 56 Parser results may be lost if TCP/UDP checksum checking is enabled Fixed in Rev 2.1 Yes No No eTSEC 57 RQUEUE[EXn] bits have no effect Fixed in Rev 3.1.x Yes Yes No eTSEC 58 Parsing of MPLS label stack or non-IPv4/IPv6 label not supported Fixed in Rev 3.1.x Yes Yes No eTSEC 59 Arbitrary extraction on short frames uses data from previous Fixed in Rev 3.1.x frame Yes Yes No eTSEC 60 Some combinations of Tx packets may trigger a false Data Parity Error (DPE) Fixed in Rev 2.1 Yes No No eTSEC 61 eTSEC Data Parity Error (DPE) does not abort transmit frames Partial fix in Rev 2.1 Yes Yes Yes eTSEC 62 eTSEC half duplex receiver packet corruption Fixed in Rev 3.1.x Yes Yes No eTSEC 63 May drop Rx packets in non-FIFO modes with lossless flow Fixed in Rev 3.1.x control enabled Yes Yes No eTSEC 64 Back-to-back IPv6 routing headers not supported by parser Fixed in Rev 3.1.x Yes Yes No eTSEC 65 RxBD[TR] not asserted during truncation when last 4 bytes match CRC Fixed in Rev 3.1.x Yes Yes No eTSEC 66 Parser continues parsing L4 fields when RCTRL[PRSDEP] set for L2 and L3 fields only Fixed in Rev 3.1.x Yes Yes No eTSEC 67 Fetches with errors not flagged, may cause livelock or false Partially fixed in halt Rev 3.1.x Yes Yes Yes eTSEC 68 Rx TCP/UDP checksum checking may be incorrect while operating at low frequencies in FIFO mode Fixed in Rev 3.1.x Yes Yes No eTSEC 69 Filer does not support matching against broadcast address flag PID1[EBC] Fixed in Rev 3.1.x Yes Yes No eTSEC 70 eTSEC does not support parsing of LLC/SNAP/VLAN packets No plans to fix Yes Yes Yes eTSEC 71 eTSEC filer reports incorrect Ether-types with certain MPLS Fixed in Rev 3.1.x frames Yes Yes No eTSEC 72 Compound filer rules do not roll back the mask Fixed in Rev 3.1.x Yes Yes No eTSEC 73 Incomplete frame with error causes false CR error on next frame Fixed in Rev 3.1.x Yes Yes No eTSEC 74 Parser does not check VER/TYPE of PPPoE packets Fixed in Rev 3.1.x Yes Yes No Table continues on the next page... MPC8548E Chip Errata, Rev. 6, 6/2012 4 Freescale Semiconductor, Inc. General Business Information Table 3. Summary of Silicon Errata and Applicable Revision (continued) Errata Name Projected Solution Silicon Rev. 2.0 2.1.x 3.1.x eTSEC 75 Back-to-back Rx frames may lose parser results of second frame Fixed in Rev 2.1 Yes No No eTSEC 76 RMCA, RBCA counters do not correctly count valid VLAN tagged frames Fixed in Rev 3.1.x Yes Yes No eTSEC 77 Tx errors truncate packets without error in 8-bit Encoded FIFO mode Fixed in Rev 3.1.x Yes Yes No eTSEC 78 No parser error for packets containing invalid IPv6 routing header packet Partially fixed in Rev 3.1.x Yes Yes Yes eTSEC 79 Generation of Ethernet pause frames may cause Tx lockup Fixed in Rev 3.1.x and false BD close Yes Yes No eTSEC 80 eTSEC parser does not perform length integrity checks No plans to fix Yes Yes Yes eTSEC 81 eTSEC does not verify IPv6 routing header type field Fixed in Rev 3.1.x Yes Yes No eTSEC 82 Transmission of truncated frames may cause hang or lost data Fixed in Rev 3.1.x Yes Yes No eTSEC 83 L3 fragment frame files on non-existent source/destination ports Fixed in Rev 3.1.x Yes Yes No eTSEC 84 Multiple BD frame may cause hang Fixed in Rev 3.1.x if multiple Tx queues enabled. Yes Yes Yes eTSEC 85 TxBD[TC] is not reliable in 16-bit FIFO modes Fixed in Rev 3.1.x Yes Yes No eTSEC 86 eTSEC receivers may not be properly initialized Fixed in Rev 2.1 Yes No No eTSEC 87 Arbitrary Extraction cannot extract last data bytes of frame Fixed in Rev 3.1.x Yes Yes No eTSEC 88 False TCP/UDP and IP checksum error in FIFO mode without CRC appending Fixed in Rev 3.1.x Yes Yes No eTSEC 89 Frames greater than 9600 bytes with TOE = 1 will hang controller Fixed in Rev 3.1.x Yes Yes No eTSEC 90 Setting RCTRL[LFC] = 0 may not immediately disable LFC Fixed in Rev 3.1.x Yes Yes No eTSEC 91 VLAN Insertion corrupts frame if user-defined Tx preamble enabled No plans to fix Yes Yes Yes eTSEC 92 False parity error at Tx startup Fixed in Rev 3.1.x Yes Yes No eTSEC 93 Transmit fails to utilize 100% of line bandwidth Partially fixed in Rev 3.1.x Yes Yes Yes eTSEC 94 Rx packet padding limitations at low clock ratios Fixed in Rev 3.1.x Yes Yes No eTSEC 95 False TCP/UDP checksum error for some values of pseudo Fixed in Rev 3.1.x header Source Address Yes Yes No eTSEC 96 Unexpected babbling receive error in FIFO modes No plans to fix Yes Yes Yes eTSEC 97 User-defined Tx preamble incompatible with Tx Checksum No plans to fix Yes Yes Yes eTSEC 98 FIFO16 interface encoded mode maximum frequency is 1/4.2 platform clock Fixed in Rev 3.1.x Yes Yes No eTSEC 99 ECNTRL[AUTOZ] not guaranteed if reading MIB counters with software Fixed in Rev 3.1.x Yes Yes No eTSEC 100 Half-duplex collision on FCS of Short Frame may cause Tx lockup Documentation update Yes Yes Yes Table continues on the next page... MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 5 General Business Information Table 3. Summary of Silicon Errata and Applicable Revision (continued) Errata Name Projected Solution Silicon Rev. 2.0 2.1.x 3.1.x eTSEC 101 Magic Packet Sequence Embedded in Partial Sequence Not Recognized Partially fixed in Rev 3.1.x Yes Yes Yes eTSEC 104 Rx may hang if RxFIFO overflows Fixed in Rev 3.1.x Yes Yes No eTSEC 105 MAC: Malformed Magic Packet Triggers Magic Packet Exit Fixed in Rev 3.1.x Yes Yes No eTSEC 106 Excess delays when transmitting TOE=1 large frames Fixed in Rev 3.1.x Yes Yes No eTSEC 107 Controller may not be able to transmit pause frame during pause state Fixed in Rev 3.1.x Yes Yes No eTSEC-A001 MAC: Pause time may be shorter than specified if transmit in progress Fixed in Rev 3.1.x Yes Yes No eTSEC-A002 Incomplete GRS or invalid parser state after receiving a 1or 2-byte frame No plans to fix Yes Yes Yes eTSEC-A004 User-defined preamble not supported at low clock ratios Fixed in Rev 3.1.x Yes Yes No eTSEC-A005 Rx may hang on eTSEC3 and eTSEC4 under extreme temperature, low Vdd and heavy traffic Fixed in Rev 2.1.3 Yes No No PEX PCI-Ex 35 Rx detection by transmitter does not pass high receiver impedance test Fixed in Rev 3.1.x Yes Yes No PCI-Ex 37 Completion Timeout error disable corrupts CRS threshold error data Fixed in Rev 3.1.x Yes Yes No PCI-Ex 38 PCI Express LTSSM may fail to properly train with a link partner following HRESET Fixed in Rev 3.1.x Yes Yes No PCI-Ex 39 No mechanism for recovery from hang after access to down Fixed in Rev 3.1.x link Yes Yes No PCI-Ex 41 PCI Express x8 mode requires minimum platform frequency No plans to fix of 527 MHz Yes Yes Yes PCI-Ex 42 Reads to PCI Express CCSRs or local config space temporarily return all Fs Fixed in Rev 3.1.x Yes Yes No PCIe-A001 PCI Express Hot Reset event may cause data corruption Fixed in Rev 3.1.x Yes Yes No SEC SEC 5 AES-CTR mode data size error Fixed in Rev 2.1 Yes No No SEC 6 Single descriptor SRTP error Fixed in Rev 2.1 Yes No No SEC 7 AES-CCM ICV checking write-back error No plans to fix Yes Yes Yes SEC 8 Kasumi hardware ICV checking does not work No plans to fix Yes Yes Yes Channel Hang with Zero Length Data No plans to fix Yes Yes Yes SEC-A001 SRIO SRIO 39 Serial RapidIO atomic operation erratum No plans to fix Yes Yes Yes SRIO 41 Serial RapidIO Packets with errors are not ignored by the controller while in input-retry-stopped state No plans to fix Yes Yes Yes SRIO 42 Message unit cannot generate messages with priority 0 No plans to fix Yes Yes Yes SRIO-A002 SRIO reset command does not result in device reset Fixed in Rev 3.1.x Yes Yes No SRIO-A004 SRIO controller may incorrectly transmit or block responses No plans to fix when PmCCSR[OPE] = 0 Yes Yes Yes Table continues on the next page... MPC8548E Chip Errata, Rev. 6, 6/2012 6 Freescale Semiconductor, Inc. General Business Information Table 3. Summary of Silicon Errata and Applicable Revision (continued) Errata Name Projected Solution Silicon Rev. 2.0 2.1.x 3.1.x DDR DDR 13 Memory contents may not be retained during HRESET sequence No plans to fix Yes Yes Yes DDR 14 The automatic CAS-to-Preamble feature of the DDR controller can calibrate to incorrect values No plans to fix Yes Yes Yes DDR 15 Automatic calibration hardware may calibrate to an invalid driver impedance Fixed in Rev 2.1 Yes No No DDR 16 On-die termination at the DDR IOs has been measured 75 too high Fixed in Rev 2.1 Yes No No DDR 17 DDR performance monitoring and tracing functionality does Fixed in Rev 2.1 not work Yes No No DDR 18 Automatic data initialization and DLL resets to DRAM are not performed correctly if CS2 and CS3 are interleaved No plans to fix Yes Yes Yes DDR 19 DDR IOs default receiver biasing may not work across voltage and temperature Fixed in Rev 2.1 Yes No No DDR 20 MCKE signal may not function correctly at assertion of HRESET No plans to fix Yes Yes Yes GEN GEN 10 Device may fail DDR pins during IEEE Std 1149.1TM EXTEST mode No plans to fix Yes Yes Yes GEN 11 Some pins do not meet 500V CDM ESD criteria Fixed in Rev 3.1.x Yes Yes No GEN 13 CPU write to platform failures in all core, platform, and SYSCLK frequency combinations Fixed in Rev 3.1.x Yes Yes No GEN 14 CPU-only reset may result in a failure in the platform logic No plans to fix Yes Yes Yes SerDes lane power down function may cause training to fail. No plans to fix Yes Yes Yes SerDes SERDES 1 LBC LBIU 3 LBIU Transactions when clock divider LCRR[CLKDIV] is changing No plans to fix Yes Yes Yes LBIU 4 LGTA/LUPWAIT assertion in PLL-bypass mode misrepresented No plans to fix Yes Yes Yes LBIU 5 UPM does not have indication of completion of a RUN PATTERN special operation No plans to fix Yes Yes Yes PIC PIC 4 PIC soft reset not clearing MSIRn registers correctly No plans to fix Yes Yes Yes PIC 5 MSIMR De-featured Documentation update Yes Yes Yes PIC 6 MER, Interrupt will not be forwarded to destination No plans to fix Yes Yes Yes PIC 7 PCI Express MSI other than interrupt 0 not supported via hardware No plans to fix Yes Yes Yes PM 1 Some local bus events are not counted correctly in the performance monitor No plans to fix Yes Yes Yes PMON Table continues on the next page... MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 7 General Business Information Table 3. Summary of Silicon Errata and Applicable Revision (continued) Errata PM 2 Name Projected Solution A performance monitor time base transition event will not freeze the performance monitor counters and may not cause an exception Silicon Rev. 2.0 2.1.x 3.1.x No plans to fix Yes Yes Yes Fixed in Rev 3.1.x Yes Yes No Fixed on Rev 2.1 Yes No No I2C I2C I2C bus freeze when other I2C I2C 2 Enabling could cause devices communicate I2C 3 I2C boot sequencer cannot issue snoopable writes DMA DMA 1 DMA_DACK bus timing violation when operating in external Partially fixed in DMA master mode Rev 3.1.x Yes Yes Yes DMA 2 Transfer error reported for wrong channel Yes Yes No Yes Yes Yes Fixed in Rev 3.1.x DUART A-004737 BREAK detection triggered multiple times for a single break No plans to fix assertion PCI PCI 4 PCI-X inbound reads resulting in a split completion response can cause a corrupted response No plans to fix Yes Yes Yes PCI 5 Assertion of STOP by a target device on the last beat of a PCI memory write transaction can cause a hang No plans to fix Yes Yes Yes PCI 6 PCI/PCI-X erroneous error detection Fixed in Rev 2.1 Yes No No PCI 7 Asynchronous mode PCI1 and PCI2 input hold violation Fixed in Rev 2.1 Yes No No PCI 8 Device reports wrong PCI Vendor ID No plans to fix Yes Yes Yes PCI 9 Master-Abort issued incorrectly for outbound DAC with subtractive decode No plans to fix Yes Yes Yes Fixed in Rev 2.1 Yes No No JTAG JTAG 2 TMS requires hold time beyond the fall of TCK MPC8548E Chip Errata, Rev. 6, 6/2012 8 Freescale Semiconductor, Inc. General Business Information CPU 2: A core hang possible while executing a msync or mbar 0 instruction and a snoopable transaction from an I/O master tagged to make quick forward progress is present. Description: Transactions from I/O masters (eTSEC, Security, DMA, PCI, PCI-X, SRIO, PCI-Exp, HT) are sometimes elevated in priority in the Coherency Module. If a msync or mbar 0 instruction is being executed inside of the core while one of these high priority transactions from I/O is "snooped" to the core's cache, a hang can result. Impact: The core hangs and all I/O traffic going through the Coherency Module comes to a halt. The application must be using msync or mbar 0 instructions inside of the core for this problem to appear. Note also that ATMU and or setting of the buffer descriptors must be setup to permit I/ O masters to perform coherent transfers for such a core hang to occur. Note that peer-to-peer type traffic across the OCN complex continues without lockup. Workaround: Setting the Coherency Module debug register at CCSR offset 0x0_1010, bit 15 to a logic 1 prevents this type of lockup. This disables the state machine inside of the Coherency Module that elevates these transactions from I/O masters to highest priority. The result is that all transactions that the core initiates are always permitted to compete on an equal basis on the Core Connect Bus (CCB) so that the core will not hang. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 9 General Business Information CPU 3: "mbar MO = 1" instruction fails to order caching-inhibited guarded loads and stores Description: This errata describes a failure of the e500 mbar instruction when the MO field is one. In particular, the "mbar MO = 1" instruction fails to act as a barrier which cannot be bypassed by caching-inhibited loads. Assume the following instruction sequence: * stw caching-inhibited, guarded address A * mbar MO = 1 * lwz caching-inhibited, guarded address B The "mbar MO = 1" instruction is intended to be a barrier which prevents the lwz from executing before the stw has been performed. However, the e500 does not behave as intended, and allows the lwz to be executed before the stw has been performed. Impact: This errata is most likely to affect device drivers that depend on "mbar MO = 1" to ensure that the effects of caching-inhibited stores are seen by a device before a subsequent cachinginhibited guarded load is executed. The "mbar MO = 1" instruction is intended to order: * Cacheable stores * Cache-inhibited loads * Cache-inhibited stores The only case where the instruction may not behave correctly is where cache-inhibited loads may erroneously bypass cache-inhibited stores. Workaround: Use one of the following options: Use "mbar MO = 0" , the preferred workaround to ensure that caching-inhibited guarded loads do not bypass the memory barrier. The msync instruction can also be used as barrier, independent of the memory control attributes (for example, presence or absence of the caching inhibited attribute). Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 10 Freescale Semiconductor, Inc. General Business Information CPU 4: Single-precision floating-point zero value may have the wrong sign Description: When performing single-precision floating-point operations that produce a result of zero, the sign of the zero value may be incorrect. Impact: Single-precision floating-point operations that result in zero may not be compatible with IEEE Std 754TM. Workaround: Use double-precision floating-point Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 11 General Business Information CPU 5: Branch Fails to Decrement CTR in Presence of D-cache Parity Error Description: There is a potential confluence of events that results in a failure to decrement the CTR when the branch instruction is executed. The necessary conditions are as follows: * The branch is mispredicted, which can occur if branch prediction is either of the following: * Enabled * Disabled, and the branch is actually taken * There is a load instruction in the branch's mispredicted path, and that load hits in the L1 D-Cache, and the cache line has a parity error. * The parity error is detected within a narrow timing window of when the branch is deallocated. Under these conditions, the branch redirects the instruction stream to the correct branch target, but the CTR is not decremented. The speculative load that hits the parity error is flushed when the branch is resolved. D-Cache parity errors cause precise machine check interrupts. Therefore, because the load instruction is flushed, no machine check occurs. After the mispredicted branch is resolved, the core begins executing from the corrected path. However, if an interrupt occurs during the execution of one of the first few instructions in the corrected path, there is a possibility that SRR0 points to an instruction in the mispredicted path. Impact: This errata may cause undetected, erroneous program behavior in the presence of L1 DCache parity errors. Workaround: None Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 12 Freescale Semiconductor, Inc. General Business Information CPU 6: Incorrect Value May be Loaded Into SRR0 on ITLB Miss When Executing icbtls Description: When executing the icbtls, if the instruction fetch unit fetches a line that results in an ITLB Miss interrupt, the value loaded into SRR0 will be incorrect. Impact: This failure could cause the handler to return (rfi) to the wrong address. This errata does not apply to icbtls instructions if CT ! = 0. Workaround: This problem can be avoided by executing isync after icbtls. The program must ensure that no ITLB Miss can occur between the execution of the icbtls and the execution of the isync. This implies that the isync should reside on the same page as the icbtls. A sequence of icbtls instructions can be followed by a single isync to avoid this problem. No ITLB Miss exceptions should be allowed between the execution of the first icbtls in this sequence and the isync at the end of the sequence. There is no need to avoid asynchronous interrupts between the execution of icbtls and the following isync. The occurrence of the interrupt has the same effect as the isync and prevents the problem. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 13 General Business Information CPU-A001: Flash-Invalidation of TLB1 with "mtspr MMUCSR0" may fail Description: The e500v1 and v2 specification says that writing a 1 to MMUCSR0[TLB1_FI] will flashinvalidate all TLB1 entries that are not marked with "IPROT". However, this flash-invalidate mechanism may fail if the execution of the mtspr loosely coincides with the execution of a tlbivax that invalidates entries in the TLB1 (i.e., a tlbivax with bits 60-61 of the effective address set to binary 10). This tlbivax may be executed either on the same processor or on a different processor than the "mtmsr MMUCSR0" instruction. Impact: Failure to invalidate all of the intended lines can result in operating system failure. In most operating systems, invalidation of TLB entries is restricted to a couple of places in the OS, and they are usually performed under controlled circumstances. Therefore, this bug may not impact a particular OS. Workaround: Use one of the following options: * Always invalidate the entire TLB1 with tlbivax with bits 60-61 = 11 instead of "mtspr MMUCSR0". * Ensure that tlbivax and "mtspr MMUCSR0" cannot be executed simultaneously by using mutual exclusion locks around any code that invalidates TLB1. * In a single-core environment, it is sufficient to ensure that tlbivax does not closely follow the mtspr that sets MMUCSR0[TLB1_FI] = 1 without an intervening msync. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 14 Freescale Semiconductor, Inc. General Business Information A-001428: Enabling IEEE 754 exceptions can cause errors Affects: CPU Description: This issue can occur if a single-precision floating-point, double-precision floating-point, or vector floating-point instruction on a mispredicted branch path signals one of the floating-point data interrupts enabled by the SPEFSCR (FINVE, FDBZE, FUNFE or FOVFE bits). This interrupt must be recorded in a one-cycle window when the misprediction is resolved. If this extremely rare event should occur, the result could be that the SPE Data Exception from the mispredicted path may be reported erroneously if a single-precision floating-point, doubleprecision floating-point, or vector floating-point instruction is the second instruction on the correct branch path. It is only possible for this erratum to occur if any of the SPEFSCR exception enable bits (FINVE, FDBZE, FUNFE or FOVFE) are set to one. Impact: A correctly executing floating point instruction that is the second instruction on the correct path may take an unexpected data exception. This is caused by an unrelated floating point instruction that has been cancelled on the mispredicted path. Workaround: Use one of the following options: * Ensure that the floating-point data exceptions are disabled by clearing the SPEFSCR exception enable bits (FINVE, FDBZE, FUNFE or FOVFE). * Have the exception handler make the hardware re-execute the instruction, if a floating point instruction causes an unexpected data exception. If the exception was a result of this erratum, there will be no exception on re-execution. Freescale will make this modification to the exception handler we provide to the open source community. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 15 General Business Information A-003477: Phantom branches in the BTB may not be correctly invalidated Affects: CPU Description: The branch target buffer (BTB) holds effective addresses associated with a branch instruction. A process context switch might bring in another task whose MMU translations are such that it uses the same effective address for another nonbranch instruction for which the BTB has an entry for a previously encountered branch. This causes the fetch unit to redirect instruction fetch to the BTB's target address. When this occurs it is called a phantom branch. Later, during execution of the instruction, the hardware realizes the error and is supposed to evict the BTB entry. However, with this erratum, a BTB entry of a phantom branch may not be invalidated when the phantom branch is decoded from instruction buffer 0, and 1. the BTB hit a phantom branch and the branch address does not equal the fetch group address, that is, the branch is not the first instruction in the fetch group, OR, 2. the BTB hit a phantom branch and the branch address equals the fetch group address. In case 1, where the fetch group address and branch address are not equal, the BTB will not be invalidated. In case 2, after two attempts to issue the phantom branch, the BTB entry will be properly invalidated. In both cases, it is possible that a valid entry will be invalidated instead. Impact: Performance may be impacted. This errata could occur when switching across processes that share the same effective address space. Workaround: Select one of the following options, depending on which results in the best performance: * Continue to use the BTB as it currently operates. * Invalidate the BTB (BUCSR [BBFI] =1) at the appropriate points to ensure a phantom branch never occurs. (Possible scenarios that can cause phantom branches include, but are not limited to, the following: switching contexts where an exception handler address space overlaps with user code space, while running self-modifying code, 64-bit programs executing across 4G segments, during any process switch, etc.) * Disable the BTB (BUCSR[BPEN] = 0) temporarily without invalidating the BTB when switching to other contexts that may cause phantom branches. Re-enable the BTB when switching back to the main context. This allows the BTB contents to remain intact for the main context such that when returning back to the main context, the BTB is valid. * Disable BTB (BUCSR[BPEN] = 0) completely for all contexts. Each workaround impacts performance depending on the application. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 16 Freescale Semiconductor, Inc. General Business Information A-005125: In a very rare condition, a system hang is possible when the e500 core initiates a guarded load to PCI/PCIe/sRIO while the PCI/PCIe/sRIO performs a coherent write to memory. Affects: CPU Description: When the e500 core initiates a guarded load to PCI/PCIe/sRIO near the time that PCI/PCIe/ sRIO performs a write to cacheable, coherent memory, and that write is behind (or is one of) multiple full cache line writes from an IO device that hit modified in the e500's L1 data cache, it is possible for the CCB bus arbiter to enter into an invalid state and hang the system. A very specific sequence of streamed IO snoops and retries from a congested memory system must occur just before the PCI/PCIe/sRIO write reaches the core for the hang to occur. Impact: When no further forward progress is made to and from the e500 coherency module (ECM), the system may hang. If set, the watch dog timer then triggers the system to reboot. Workaround: Set SPR976[40:41] to b'10. Setting these bits avoids the hang condition by forcing the core to process all snoops of IO device full cache line writes to DDR differently. This setting does not impact performance. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 17 General Business Information eTSEC 29: Frame is dropped with collision and HALFDUP[Excess Defer] = 0 Description: eTSEC drops excessively deferred frames without reporting error status when HALFDUP[Excess Defer] = 0. This erratum affects 10/100 Half Duplex modes only. Impact: The eTSEC does not correctly abort frames that are excessively deferred. Instead it closes the BD as if the frame is transmitted successfully. This results in the frame being dropped (because it is never transmitted) without any error status being reported to software. Workaround: Do not change HALFDUP[Excess Defer] from its default of 1.Thus eTSEC always tries to transmit frames regardless of the length of time the transmitter defers to carrier. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 18 Freescale Semiconductor, Inc. General Business Information eTSEC 34: Transmit frames aborted under 16-bit FIFO GMII-style mode Description: If the eTSEC is connected via a 16-bit FIFO packet interface with GMII signaling, and the CCB (platform) clock to Tx clock ratio is less than 4.2:1, transmit packets may be lost due to underrun. For example, for CCB (platform) clock of 533 MHz, the maximum speed of the Tx clock is 125 MHz. Also the minimum Inter Packet Gap (IPG) between packets at this ratio is 8 cycles. The logic in the transmit synchronizer needs the extra timing margin to recover between data beats when in 16-bit FIFO mode. This limitation is restricted to the FIFO16 GMII transmit path only. The receive path will operate with the CCB clock: Tx clock ratios as low as 3.2:1. FIFO8 and FIFO16 encoded modes can also operate at 3.2:1. Impact: FIFO16 GMII is limited to a maximum transmit clock frequency of 125 MHz with platform clock at 533 MHz and a maximum transmit clock frequency of 155 MHz with platform clock at 667 MHz in Rev 2.0 silicon. Workaround: Use of encoded mode for any 16 bit FIFO packet interface instead of GMII style signaling is recommended. The FIFO Encoded mode will not abort packets if underrun occurs; instead, it will assert idle bytes during the data stream. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 19 General Business Information eTSEC 36: TX_EN of eTSEC1 and eTSEC2 may be driven randomly during reset Description: During POR, pin TX_EN of eTSEC1 & eTSEC2 may be driven randomly for a period before being driven LOW while eTSEC3 & eTSEC4 tri-state this pin during the whole period where HRESET is asserted. Impact: The PHY or external ASIC/FPGA would see the false active TX_EN during reset when connected to eTSEC1 and eTSEC2. Workaround: To prevent unexpected behavior from the external devices (PHY or ASIC/FPGA) due to invalid TX_EN, software can reset the external devices after resetting the MPC8548E. This is required only if the external devices use a different reset source than one for MPC8548E. Fix plan: Fixed in Rev 2.1 All TX_EN pins will be tri-stated during HRESET. assertion. MPC8548E Chip Errata, Rev. 6, 6/2012 20 Freescale Semiconductor, Inc. General Business Information eTSEC 37: eTSEC Parser does not properly parse L3 fields Description: The eTSEC parser does not properly process tunneled IP frames, resulting in loss of parser synchronization. Impact: Tunneled IP frames received on the eTSEC Ethernet MAC and FIFO interfaces cannot be properly parsed and filed into receive queues. Workaround: Do not enable parser recognition for L3 field, PRSDEP = 00 or 01 in Receive Control Register (RCTRL). Parsing and filling on L2 fields continues to be supported. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 21 General Business Information eTSEC 38: WWR bit Anomaly Description: DMACTRL[WWR] is intended to delay setting of IEVENT bits TXB, TXF, XFUN, LC, CRL, RXB, RXF until the system acknowledges that the buffer descriptor write data is actually in memory (L2 cache or DDR SDRAM), and not in flight in the system. There are certain cases when there are multiple outstanding BD updates, particularly in high latency memory scenarios, where an IEVENT can be lost when using DMACTRL[WWR] = 1. Impact: If DMACTRL[WWR] = 1, then there is on occasion a missed IEVENT, or possibly an incorrect IEVENT assertion. This means that the interrupt could be missed altogether (BD still correctly updated in memory), or the IEVENT could be incorrect. In the case of it being incorrect, the IEVENT would not correspond to the BD at the head of the list, but would correspond to the BD second or third in the list. Workaround: Set DMACTRL[WWR] = 0. The effect of setting DMACTRL[WWR] = 0 is that the interrupt may arrive at the processor before the update to the BD for the received packet that caused the interrupt has been completed in memory. This may or may not have any impact on the system depending on how packets are processed. If the CPU reads the BD immediately after the interrupt, then in heavily congested systems it is possible that the CPU completes a read of the BD before the BD is closed by the eTSEC so that the BD's Empty bit is still set. In this case, software can either exit the packet processing routine and service the packet upon receiving the next interrupt, or it can schedule another interrupt to process the packet later. Use of Rx interrupt coalescing of even a few packets reduce the chance of the CPU reading a BD whose update is still in flight to virtually zero, though it is still possible if multiple receive rings are in use. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 22 Freescale Semiconductor, Inc. General Business Information eTSEC 39: Parsing of tunneled IP packets not supported Description: Encapsulation of IP in IP in either TCP or UDP packets is not supported by eTSEC parser. This applies to both IPv4 and IPv6. A tunneled IP packet is an IP/TCP or IP/UDP packet and one of the following: 1. IPv4 header with a value of either 4 or 41 in the Protocol field, indicating that the next header is either another IPv4 header or IPv6 header, respectively 2. IPv6 header with a value of either 4 or 41 in the Next Header field, indicating that the next header is either a IPv4 header or another IPv6 header, respectively Impact: Validly encapsulated tunneled IP packets may cause a false parser error or false TCP/UDP checksum error. Malformed tunneled packets may be received without a parser error. Tunneled packets with an actual TCP/UDP checksum error may fail to report a checksum error. Workaround: If L3 or L4 parsing is enabled and tunneled packets are expected, software must examine each packet header to see if it is a tunneled IP packet. If the packet is a tunneled IP packet, software should ignore any parser or checksum error. Fix plan: No plans to fix Revision 2.1.x will continue to not support parsing of tunneled IP packets. However, false checksum and parser errors on tunneled IP packets will not occur. The inner header of those packets will not be parsed. The FCB will contain the correct parser information for the outer header and the next header field will correctly indicate the tunneled type. If tunneled packets are expected, software will need to check the FCB and flag any IP packets with the next header field = IP for further processing. Software will no longer need to check every packet. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 23 General Business Information eTSEC 40: Magic packet does not wake device from a SLEEP state Description: There is a problem waking the device from a SLEEP state with a magic packet. When a magic packet is received on an eTSEC which is configured to come out of a low-power state (DOZE, NAP, SLEEP), the device is supposed to generate an interrupt to the interrupt controller which in turn gets the chip out of the low power state. Current versions of the device perform the correct action for DOZE and NAP, but not for SLEEP. Impact: Magic packet cannot be used to get the device out of a SLEEP state. Workaround: There is no work around for this erratum. Use DOZE or NAP low-power states for applications that use the magic packet to get the device out of a low-power state. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 24 Freescale Semiconductor, Inc. General Business Information eTSEC 44: FIFO8, FIFO16 TX hang Description: The transmit state machine can hang in FIFO8 or FIFO16 mode. Impact: Both encoded- and GMII-type FIFO8 and FIFO16 modes are non-functional in silicon revision 2.0. Workaround: None. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 25 General Business Information eTSEC 45: Tx data corruption in FIFO16 mode Description: The eTSEC may occasionally corrupt data on transmit in FIFO16 encoded mode when TX flow control is enabled. Impact: The problem only occurs when the platform is running at less than 4.2x the GTX_CLK in silicon revision 2.0 devices. Workaround: Run the FIFO interface slower than 1/4.2 the platform frequency or run in the configuration Tx flow control disabled (FIFOCFG[TFC]=0). The eTSEC may experience underruns when running at less than 1/4.2, and TFC=0. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 26 Freescale Semiconductor, Inc. General Business Information eTSEC 46: RSTAT[RXF0] set regardless of destination ring if WWR=0 Description: If WWR=0, RSTAT[RXF0] may be set when a receive frame event occurs, even if the event actually occurs on a different RxBD ring. Impact: Software cannot rely on RSTAT[RXF0] to indicate that a ring-0 receive-frame event occurred, or that receive-frame events on other RxBD rings will set the correct RSTAT[RXFn] bit. Workaround: When RSTAT[RXF0] is set, software should check all active rings for the updated RxBD. If RSTAT[RXF1:RXF7] is set, only the corresponding ring needs to be checked. See also eTSEC 38 (WWR Bit Anomaly) for a description of other software requirements when WWR=0. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 27 General Business Information eTSEC 47: VLAN strip must be disabled if the parser is disabled Description: The current documentation says that VLAN tags are deleted only if RCTRL[VLEX]=1 and RCTRL[PRSDEP] != 0. In fact, the VLAN tag is deleted regardless of the setting of RCTRL[PRSDEP]. Since there is no way to recover the deleted VLAN tag if the parser is disabled, RCTL[VLEX] should never be set to 1 if RCTRL[PRSDEP]=0. Impact: VLAN tags may be deleted if parser is disabled under illegal configuration setting. Workaround: Always set RCTRL[VLEX]=0 if RCTRL[PRSDEP]=0. Fix plan: Documentation update MPC8548E Chip Errata, Rev. 6, 6/2012 28 Freescale Semiconductor, Inc. General Business Information eTSEC 48: Receive frame filer must be disabled if the parser is disabled Description: The current documentation states that receive frame filing is enabled only if RCTRL[FILREN]=1 and RCTRL[PRSDEP] != 0. This is not true. The receive frame filer is enabled regardless of the setting of RCTRL[PRSDEP]. Since the filer is not intended to function if the parser is disabled, RCTL[FILREN] should never be set to 1 if RCTRL[PRSDEP]=0. Impact: Improper filer behavior. Workaround: User code must clear RCTRL[FILREN]=0 if RCTRL[PRSDEP]=0. Fix plan: Documentation update MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 29 General Business Information eTSEC 49: Tx IP and TCP/UDP Checksum Generation not supported for some Tx FCB offsets Description: If the Tx FCB (Frame Control Block) 32-byte offset is 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E or 0x1F, IP and TCP/UDP header checksum generation do not function properly. The checksum value may be inserted in the wrong location or not inserted at all. Impact: IP and TCP/UDP header checksum generation is not supported in LINUX and other systems in which headers are prepended to pre-aligned packet data, or where the alignment of the Tx FCB cannot be controlled. This behavior applies to pseudo-header checksum insertion as well as checksum generation. Workaround: Align Tx FCB to a 16 or 32-byte boundary. If the alignment of TxFCB is not controllable, set TCTRL[TUCSEN]=0 and TCTRL[IPCSEN]=0 to disable IP and TCP/UDP header checksum generation. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 30 Freescale Semiconductor, Inc. General Business Information eTSEC 50: Value of TBYT register may not match bytes transmitted for truncated frames Description: The value of the TBYT register may not match the actual number of bytes transmitted if the frame is truncated because it exceeds MAXFRM. Impact: TBYT may be incremented for several bytes after MAXFRM limit is exceeded. The amount TBYT is incremented for a frame is guaranteed to be less than or equal to the original frame size. Workaround: Do not transmit data larger than MAXFRM size. Fix plan: Documentation update Update documentation to indicate TBYT may be larger than the actual number of bytes transmitted if a frame is truncated because it exceeds MAXFRM. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 31 General Business Information eTSEC 51: Missing basic integrity check for parsing Tunneled IP packets Description: eTSEC verifies basic integrity in outer IP headers, but not inner ones. It is good practice to verify packet header integrity on fields that are defined to contain certain values. Two basic integrity checks involve the following: * Ensuring that the version field of the IP header is a 4 or a 6, and corresponds to the previous headers encoding. Else, this is a parse error. For non-tunneled packets eTSEC perform this functionality properly. * In the case of IPv4, the minimum header length allowed by the standard is 20 bytes, encoded as 0x5 in the header length field. Values less that 5 should be considered parse error. For non-tunneled packets eTSEC perform this functionality properly. Impact: eTSEC will parse and file these irregular packets as valid encodings. Workaround: If L3 or L4 parsing is enabled and tunneled packets are expected, software should perform basic checking on receive packets to see if they are tunneled IP packets. If so, the software should perform these checks. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 32 Freescale Semiconductor, Inc. General Business Information eTSEC 52: Error in arbitrary extraction offset Description: The byte offset for the arbitrary extraction filer feature is shifted such that the wrong bytes are extracted in some cases and some byte offsets cannot be extracted. The problem only applies to L2 extraction. Impact: The following bytes cannot be extracted: * With no VLAN/MPLS/SNAP/PPOE tag: Packet bytes 20-21 cannot be extracted. * With 1 tag: Packet bytes 24-25 cannot be extracted. * With 2 tags: Packet bytes 28-29 cannot be extracted. Note that PPOE and SNAP count as two tags each. L2 extraction of bytes other than the above requires software assistance as described in the workaround. Workaround: Software must understand the shifting of bytes described below and compensate accordingly. With one tag (VLAN/MPLS/PPOE): * * * * BxFFSET=0-7 extract preamble bytes 0-7. BxFFSET=8-27 extract bytes 0-19 of packet. Byte 0 is the first byte of the DA. BxFFSET=28-33 extract bytes 18-23 of packet. Beginning at offset 34, the pattern is criss-crossed within a 4-byte granularity and is repeated after every 4 bytes. For example: * BxFFSET=34 extract byte 28 of packet. * BxFFSET=35 extract byte 29 of packet. * BxFFSET=36 extract byte 26 of packet. * BxFFSET=37 extract byte 27 of packet. * BxFFSET=38 extract byte 32 of packet. * BxFFSET=39 extract byte 33 of packet. * BxFFSET=40 extract byte 30 of packet. * BxFFSET=41 extract byte 31 of packet. With 2 tags (VLAN/MPLS/PPOE): * * * * Fix plan: BxFFSET=0-7 extract preamble bytes 0-7. BxFFSET=8-31 extract bytes 0-23 of packet. Byte 0 is the first byte of the DA. BxFFSET=32-37 extract bytes 18-27 of packet. Beginning at offset 38, the pattern is criss-crossed within a 4-byte granularity and is repeated after every 4 bytes. For example: * BxFFSET=38 extract byte 32 of packet. * BxFFSET=39 extract byte 33 of packet. * BxFFSET=40 extract byte 30 of packet. * BxFFSET=41 extract byte 31 of packet. * BxFFSET=42 extract byte 36 of packet. * BxFFSET=43 extract byte 37 of packet. * BxFFSET=44 extract byte 34 of packet. * BxFFSET=45 extract byte 35 of packet. Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 33 General Business Information eTSEC 55: Transmit jumbo frames greater than 2400 bytes may cause lost data, loss of BD synchronization, or false underrun error Description: If the transmit processes a combination of up to four active frames which together exceed 9600 bytes, the Tx FIFO may overflow. When the TxFIFO overflows, one of several error conditions may occur. The scenarios below are representative, and may occur singly or in combination: Scenario 1 (Lost data): The eTSEC overwrites part of a frame that has already started transmitting. The controller terminates the transmitting frame early without signaling an error condition or aborting the frame with bad CRC. In this scenario, the frame being loaded into the TxFIFO has TOE=1. [original eTSEC-55] Scenario 2 (Lost BD synchronization): The eTSEC overwrites part of a frame that has already started transmitting. The controller transmits parts of two frames as a single frame with good CRC. Only the first frame's BD is closed. As each subsequent frame is transmitted, the BD of the previous frame is closed. The controller never recovers synchronization of BD to transmitted frame. This can occur with TOE=1 or TOE=0. Scenario 3 (False underrun error): The eTSEC overwrites part of a frame that has already started transmitting. The controller terminates the transmitting frame with invalid CRC and halts (TSTAT[THLTn]=1). In addition, a transmit underrun error is falsely reported (IEVENT[XFUN]=1 and TxBD[UN]=1). This can occur with TOE=1 or TOE=0. Impact: Combinations of frames that include jumbo frames greater than 2400 bytes may cause lost data, lost frames or false underrun indication in systems where the transmit throughput can fall behind the memory fetch throughput. This can occur with a fast memory subsystem, a slow interface, or collisions on the interface. Workaround: Option 1: Limit jumbo frames to 2400 bytes maximum size on transmit. Option 2: If using jumbo frames larger than 2400 bytes, limit the active TxBDs so no combination of up to four frames exceeds 9600 bytes. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 34 Freescale Semiconductor, Inc. General Business Information eTSEC 56: Parser results may be lost if TCP/UDP checksum checking is enabled Description: When the parser is enabled and RCTRL[TUCSEN]=1, if the first RxBD data arrives from memory the same cycle that parsing of the packet completes, all the fields of the RxFCB except the receive queue index will be written with zeroes instead of the parser results. Impact: When a single-cycle collision of first RxBD prefetch and parsing complete occurs, the parser results other than receive queue index are lost and the VLN, IP, IP6, TUP, CIP, CTU, EIP, ETU, PERR, PRO, VLCTL bits of the RxFCB are set to all zeroes. If VLAN extraction is enabled (RCTRL[VLEX]), the VLAN ID is lost. Workaround: Option 1: Disable TCP/UDP checksum checking by setting RCTRL[TUCSEN]=0. Option 2: Disable VLAN extraction by setting RCTRL[VLEX] and check the contents of the RxFCB. If the contents are zero, replicate the parser algorithm in software to determine the correct parser results. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 35 General Business Information eTSEC 57: RQUEUE[EXn] bits have no effect Description: The RQUEUE[EXn] bits are intended to allow ring-by-ring control of stashing (allocate into L2 cache) function. The EXn bits have no effect in the eTSEC IP, so stashing is completely controlled by the settings of the DMA ATTR register. Impact: Stashing cannot be disabled per ring. Stashing is a performance hint to the L2 cache to allocate data expected to be accessed by the CPU. If stashing is unsuccessful or disabled, the data is fetched from main memory. Workaround: None Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 36 Freescale Semiconductor, Inc. General Business Information eTSEC 58: Parsing of MPLS label stack or non-IPv4/IPv6 label not supported Description: The parser does not continue parsing beyond multi-label stack, or MPLS frame with a label other than IPv4 or IPv6. The RxFCB is written as 0x0000_00ff_0000_0000 (no layer 3 header recognized). Impact: The eTSEC cannot parse beyond an MPLS stack of greater than depth 1. It also cannot parse beyond an MPLS header with label other than IPv4 or IPv6. Workaround: Limit MPLS Ether-type packets to MPLS label stack depth = 1 with IPv4 or IPv6 label. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 37 General Business Information eTSEC 59: Arbitrary extraction on short frames uses data from previous frame Description: If the Ethernet controller receives a frame which is smaller than one of the defined offsets for arbitrary extraction (RBIFX), it should set the corresponding byte of the ARB property sent to the filer to 0. Instead it returns the corresponding byte extracted from the previous frame. Impact: If filing based on arbitrary extraction of bytes, frames shorter than the byte offset may be improperly filed: filed to the wrong queue, rejected when they should be accepted, or accepted when they should be rejected. Workaround: Option 1: Use only RBIFX[BnCTL]=01 (extract from offset of DA-8 bytes). For valid Ethernet frames (minimum length 64 bytes), the 6-bit offset cannot go beyond the end of the frame. Option 2: Do not use the ARB filer property to reject frames if the controller may receive frames shorter than the location of any arbitrary extraction byte offset. Software must handle short frames which may be filed in the wrong queue Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 38 Freescale Semiconductor, Inc. General Business Information eTSEC 60: Some combinations of Tx packets may trigger a false Data Parity Error (DPE) Description: Some combinations of Tx packets may incorrectly generate parity when loading the Tx FIFO. When the data is unloaded from the FIFO to be transmitted, if parity detection is enabled (EDIS[DPEDIS] = 0), a false parity error is flagged (IEVENT[DPE]). The packet combinations that trigger the error are as follows: 1. An initial frame (X) which is not a multiple of 8 bytes in size, and 2. A subsequent shorter frame (Y) which is not a multiple of 8 bytes in size, and 3. A specific relationship between TxFIFO write pointer used for frame (Y) relative to frame (X) just prior to EOF (which cannot be controlled by the user), and 4. A data dependency between frames (X) and (Y) - on average only 50% of the scenarios matching (1)-(3) result in a false DPE being reported. Impact: Systems which transmit packet combinations that trigger this false parity error may see some performance degradation due to false parity error interrupt service processing. No actual data corruption occurs as a result of the false parity error. Workaround: Although it is possible to prevent false parity error indications by disabling SRAM parity detection (accomplished by setting EDIS[DPEDIS] = 1), this can have the undesirable effect of masking indications of real parity errors. Unless the specific application is experiencing a significant number of false parity errors that are resulting in unsatisfactory performance degradation, it is recommended that SRAM parity detection remain enabled. Please refer to eTSEC 61 for more information. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 39 General Business Information eTSEC 61: eTSEC Data Parity Error (DPE) does not abort transmit frames Description: eTSEC supports parity protection on its TX FIFO to protect against memory errors of two types: soft errors and hard errors. Soft errors can be caused by a RAM bit cell temporarily losing its value due to an event such as an alpha particles or neutron impact, but it holds the next write. Hard errors can be caused by a RAM bit cell no longer reliably holding a 0 and/or 1 written to it. In either case, the parity error indicates that either at least one bit in a 16-bit word of the frame data to be transmitted is incorrect, or that the parity bit itself is incorrect. The correct behavior is to make sure that the peer on the other end of the link or connection is notified of this data corruption. This can by done by making sure that FCS at the end of the frame is incorrect, asserting TX_ER, or, in 16-bit FIFO encoded mode, sending an error code group. The controller does assert a local error event (IEVENT[DPE]), but does not give the link peer any error indication. In 8-bit and 16-bit GMII-style packet FIFO mode the TSECn_TX_ER signal should be asserted to indicate there was an error. However, due to this erratum a parity error will not cause the eTSEC to assert this signal. In 8-bit encoded packet FIFO mode, due to the limited number of pins, the device is not designed to signal a packet was sent with errors. Therefore, this erratum does not apply when operating in this mode. In 16-bit encoded packet FIFO mode TXC[2:0] = 011 indicates a packet was sent with an error, where TXC[2:0] = {TX_ENn+1, TX_ERn, TX_ENn}. However, due to this erratum a parity error will not set TXC[2:0] = 011 to indicate an error. Impact: If a parity error occurs on a data bit, the corrupted packet is transmitted masked as a good packet with good FCS. Higher layer protocols that have additional error checking such as TCP/UDP checksums may detect the corrupted data, depending on the location of the bad bit. Workaround: None Fix plan: Partial fix in Rev 2.1 Silicon revision 2.1 performs as follows: On detecting a Tx parity error, the controller does the following: 1. Abort the transmitting packet with an error, and all of the applicable: a. truncate frame without CRC appended in FIFO modes b. generate bad FCS in MAC modes c. assert TX_ER in MAC and GMII-style FIFO modes d. in some, but not all, cases, error code group in 16-bit encoded FIFO mode 2. Flush all active frames in the Tx FIFO and close all open BDs with an underrun error (TxBD[UN]=1). The controller may have up to 3 frames active in the Tx FIFO in addition to the frame with the parity error. The transmit buffer descriptor pointers (TBPTRn) may end up pointing to any of the up to 4 BDs open at the time the error occurred. 3. Halt all Tx queues 4. Set the TXE, DPE, and EBERR bits of the EVENT register. May also set IEVENT[XFUN]. Note: if the parity error occurs near the beginning of the frame, before frame transmission starts, the entire frame is discarded without being transmitted, and the TxBD closed with an underrun error. MPC8548E Chip Errata, Rev. 6, 6/2012 40 Freescale Semiconductor, Inc. General Business Information In order to recover normal operation, software must do the following: 1. Clear the DPE, EBERR, XFUN and TXE bits in IEVENT 2. For each enabled ring, if the BD that the TBPTRn points to has the underrun bit set, rewind the TBPTRn back to the first BD with the underrun bit set. 3. Set each "rewound" BD with underrun back to ready state, including clearing the underrun and any other bits written by the controller. 4. Do an abbreviated soft reset of the controller. In MAC modes: a. b. c. d. e. Clear MACCFG1[Tx_Flow] Wait 256 TX_CLK cycles Clear MACCFG1[Tx_EN] Wait 3 TX_CLK cycles Set MACCFG1[TX_EN] and, if desired, MACCFG1[Tx_Flow] In FIFO modes: a. Clear FIFOCFG[TXE] b. Set FIFOCFG[TXE] 5. Clear all TSTAT[THLTn] bits MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 41 General Business Information eTSEC 62: eTSEC half duplex receiver packet corruption Description: When eTSEC is configured to run in half-duplex configuration, it relies on the PHY to isolate its receiver from receive data during packet transmission. If the eTSEC receives data (RX_DV=1) on a port while eTSEC is simultaneously transmitting (TX_EN=1) on that same port, it will receive the corrupted packet data. If the receive port is operating in promiscuous mode where no frame filtering is done at the MAC, corrupted packet data may be written to system memory. This issue may arise from the transmit data being wrapped at the PHY and sent to the eTSEC receiver. This issue impacts running internal and external loopback while the eTSEC is configured for half-duplex operation. Impact: Receive data corruption occurs during simultaneous packet transmission and reception in halfduplex. Additionally, the corruption ends up with various receive MIB counters counting invalid errors depending upon the original packet size and the type of corruption (RFCS, RXCF, RXPF, RXUO, RALN, RFLR, ROVR, RJBR). Also, the receive byte counters indicate packets larger than those transmitted were received. Workaround: The eTSEC can be configured through either the MAC address filter or the filer to discard such packets that are received in this manner through the use of MAC addresses filtering match and drop. The receive MIB counters may still incorrectly count packet errors. Use eTSEC loopback mode configuration for full-duplex operation. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 42 Freescale Semiconductor, Inc. General Business Information eTSEC 63: May drop Rx packets in non-FIFO modes with lossless flow control enabled Description: Lossless Flow Control (enabled by setting RCTRL[LFC] = 1, is intended to ensure zero packet loss of receive packets due to lack of RxBDs. This is done by applying back pressure when the number of free RxBDs drops below a critical threshold set by software. In FIFO modes (both GMII-style and encoded), the back pressure is applied by asserting receive flow control (CRS pin) until the number of RxBDs exceeds the critical threshold. In non-FIFO modes, the back pressure is applied by transmitting a pause control frame with the pause time as in PTV[PT]. If the number of free RxBDs is still below the critical threshold when half the pause time has expired, the controller sends another pause frame and resets the counter. If another pause frame is transmitted during the critical window when the 1/2 PTV pause counter expires, either due to software setting TCTRL[TFC_PAUSE] or through basic flow control when the data in the RxFIFO exceeds its threshold, then the 1/2 PTV pause counter may stop counting and the state machine may cease generating automated pause extensions. If the pause time associated with the last pause control frame expires with the number of free BDs still below the critical threshold, then frames may be dropped with the IEVENT[BSY] bit set indicating frame loss due to lack of buffer descriptors. Only the transmission of another pause frame due to TCTRL[TFC_PAUSE] or data in RxFIFO exceeding threshold restarts the 1/2 PTV counter and state machine for lossless flow control. Impact: Workaround: The Ethernet controller may run out of RxBDs and drop receive packets even if lossless flow control is enabled, in a MAC mode (GMII, RGMII, SGMII, MII, RMII, TBI, RTBI). * Option 1: Enable interrupts on transmit of pause frames (IMASK[TXCEN] = 1). For every interrupt due to pause frame transmission (IEVENT[TXC] = 1), enable a counter such as a cycle count in the Performance Monitor block which would overflow and generate an interrupt after 2/3 of PVT time. If the counter is already enabled, reset the count to 2/3 of PTV time. In the overflow event interrupt handler, check the current number of free receive buffer descriptors versus the threshold. If the number of free BDs are below the threshold, manually transmit a pause frame by setting TCTRL[TFC_PAUSE] = 1. This also restarts the lossless flow control state machine. In either case (free BDs above or below threshold), disable the counter until the next transmit control frame event. * Option 2: Enable interrupts on dropped packets due to lack of RxBDs (EDIS[BSYDIS] = 0, IMASK[BSYEN] = 1). On detecting a busy dropped packet event (IEVENT[BSY] = 1), manually transmit a pause frame by setting TCTRL[TFC_PAUSE] to restart the lossless flow control state machine. NOTE The probability of packet loss in MAC modes can be reduced by increasing the pause time value in PTV[PT], or increasing the critical RxBD threshold in RQPRMn[PBTHR], or both. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 43 General Business Information eTSEC 64: Back-to-back IPv6 routing headers not supported by parser Description: Upon encountering back to back IPv6 routing extension headers following an IPv6 header, the eTSEC stops further parsing, and place 0xFF in the RxFCB[PRO], and RQFPR,pid = 0xB[L4P]. If there are 2 or more IPv6 routing extension headers, and there is either an IPv6 hop-by-hop extension header (see reference to RFC2460 below) or an IPv6 destination options header or both between the routing headers, then the eTSEC continues to parse the sequence. According to RFC2460 (current version of IPv6 specification), "Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header)." However, it goes on further to state, "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only." Impact: Upon encountering a packet with 2 or more IPv6 routing extension headers that are back to back, the eTSEC parser indicates RxFCB[IP] = 1, RxFCB[IP6] = 1, and RxFCB[PRO] = 0xFF. All layer 4 related information is zero (TUP, CIP, CTU, ETU), even if there is a recognizable L4 protocol field following the extension headers. Workaround: Software must parse the L4 information out of packets that indicate PRO = 0xFF. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 44 Freescale Semiconductor, Inc. General Business Information eTSEC 65: RxBD[TR] not asserted during truncation when last 4 bytes match CRC Description: The eTSEC truncates any receive frame larger than MAXFRM, unless Huge Frame Enable is set (MACCFG2[Huge Frame] = 1). The proper behavior for the controller is to set the RxBD[TR] bit (and RxBD[LG], if RxBD[L] = 1) for any truncated frame. If the last 4 data bytes received before truncation happens to match the running CRC, then RxBD[TR] (and RxBD[LG]) is not set even though the frame has been truncated. Impact: If the 4 data bytes just before MAXFRM bytes into the frame match the running CRC for the frame, the packet is silently truncated (no error indication via RxBD[TR]). Workaround: None Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 45 General Business Information eTSEC 66: Parser continues parsing L4 fields when RCTRL[PRSDEP] set for L2 and L3 fields only Description: RCTRL[PRSDEP] has encodings for the following: * * * * Disabling the parser (b00) Enabling parsing for L2 fields only (b01) Enabling parsing for L2 and L3 fields only (b10) Enabling parsing for L2, L3 and L4 fields (b11) In the case of setting RCTRL[PRSDEP] = b10, the eTSEC does not stop its parsing activity after the L3 fields have been identified. Instead, it continues to parse the L4 fields, attempting to identify any supported L4 protocols and updating the RxFCB and filer PID = 1 fields TCP and UDP. Impact: L4 protocols are parsed and status bits are set when the eTSEC is programmed to not include L4 parsing. Workaround: Knowing this behavior, the user can simply ignore the information associated with L4 protocols. In the case of filer PID = 1, the user must mask bits associated with TCP and UDP. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 46 Freescale Semiconductor, Inc. General Business Information eTSEC 67: Fetches with errors not flagged, may cause livelock or false halt Description: The error management for address (for example, unmapped address) and data (for example, multi-bit ECC) errors in the Ethernet controller does not properly handle all scenarios. The behavior is as follows: Scenario 1 * First TxBD fetch for queue 0 with polling enabled (DMACTRL[WOP] = 0), or, * Any fetch if EDIS[EBERRDIS] = 1 * The Ethernet controller keeps refetching the same address, resulting in a livelock of the transmit or receive state machines. If the source of the error (for example, address mapping unit in the case or unmapped address, DDR controller in the case of ECC on memory data) has interrupts enabled for the error condition, the interrupt handler can resolve the error (by for example, mapping the unmapped address or writing the memory location with good ECC). The controller resumes normal function when it receives the fetch data without an error. * The controller can also recover from the livelock condition by toggling MACCFG1[TX_EN] for Tx livelock or MACCFG1[RX_EN] for Rx livelock. Scenario 2 * First TxBD fetch for queue 0 with polling disabled * The Ethernet controller halts all Tx queues (TSTAT[THLTn] = 1, n = 0-7), but does not set IEVENT[EBERR]. Software can determine that the halt was due to an error rather than processing complete by examining the rings for ready TxBDs. EDIS[EBERRDIS] must be 0. Scenario 3 * Tx data fetch * The Ethernet controller does not detect errors on Tx data fetches. IEVENT[EBERR] is not set for an address or data error on Tx data fetches, and the queues are not halted. The error is handled at the platform level, via an interrupt from the source of the error (for example, DDRC multibit ECC error or address mapping error). Scenario 4 * Non-first TxBD fetch for queue 0, or, * TxBD fetch for queues 1-7 * The Ethernet controller sets IEVENT[EBERR] and halts all Tx queues (TSTAT[THLTn] = 1, n = 0 - 7]. This is the correct operation for Tx fetch error conditions. EDIS[EBERRDIS] must be 0. Scenario 5 * RxBD fetch * The Ethernet controller sets IEVENT[EBERR] and halts the queue with the error (RSTAT[QHLTn] = 1). This is the correct operation for Rx fetch error conditions. EDIS[EBERRDIS] must be 0. Impact: The Ethernet controller may stop transmitting packets without setting IEVENT[EBERR] if a buffer descriptor or data fetch has an uncorrectable error. The transmit scheduler may halt queues without setting IEVENT[EBERR] if a buffer descriptor fetch has an uncorrectable error. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 47 General Business Information The controller does not detect errors on Tx data fetches and transmits corrupted data without an error indicator. Workaround: All scenarios: 1. Make sure all eTSEC BD and data addresses map to valid regions of memory. 2. Ensure EDIS[EBERRDIS] = 0. Transmit buffer descriptor work around: Have software periodically check the state of the Tx queue halt bits. If a queue is halted, but still contains ready BDs, resolve any pending address or data error conditions before restarting the queues. * Option 1 for Tx queue 0: Disable polling (set DMACTRL[WOP] = 1). Queue 0 error management then follows queue 1-7 error management (queue halt without error indicator, but no livelock). * Option 2 for Tx queue 0: Enable all error interrupt enables for address and data errors in regions of memory used by TxBDs. Ensure error interrupt handlers resolve each error condition (unmapped address, uncorrectable ECC error, etc.) so the controller would eventually receive data without error and continue. * Option 3 for Tx queue 0: If error interrupt handlers cannot resolve address or data errors without changing Tx state (for example, BD address), execute a Tx reset to recover from Tx livelock condition. Fix plan: Partially fixed in Rev 3.1.x Scenarios 1 and 2 fixed Scenario 3 applies to all revisions of silicon. Scenarios 4 and 5 function properly as described above. MPC8548E Chip Errata, Rev. 6, 6/2012 48 Freescale Semiconductor, Inc. General Business Information eTSEC 68: Rx TCP/UDP checksum checking may be incorrect while operating at low frequencies in FIFO mode Description: In FIFO mode operation, a portion of the Rx TCP/UDP checksum checking state machine assumes that the controller has two cycles to respond to certain events on the Rx interface. If the controller runs slower than twice the Rx clock frequency, it may be unable to respond to an event and could either report a false Rx TCP/UDP checksum error (RxFCB[ETU] = 1) for a good packet, or fail to report a true TCP/UDP checksum error (RxFCB[ETU] = 0). The false or missing checksum errors only occur on frames of size 4n + 1 byte (8-bit FIFO) or 4n + 2 bytes (16-bit FIFO), and the last byte(s) of data are to be included in the checksum calculation (note that frames truncated due to size>MAXFRM may not report a checksum error). Impact: Rx TCP/UDP checksum checking is not supported for low clock ratios in FIFO modes (both GMII-style and encoded). Truncated frames may fail to report a checksum error. Workaround: Option 1: Turn off Rx checksum checking by setting RCTRL[TUCSEN] = 0. Option 2: Ensure that the minimum platform frequency to eTSEC Rx_CLK ratio with Rx checksum checking enabled in FIFO mode is greater than or equal to 4:1 (for example, 500 MHz platform frequency with 125 MHz Rx_CLK). Option 3: Make sure that packets that are being checksummed have at least 4 bytes of data at the end of the packet that is not to be included in the checksum (such as a CRC) Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 49 General Business Information eTSEC 69: Filer does not support matching against broadcast address flag PID1[EBC] Description: The controller clears its copy of the Ethernet broadcast address before extracting filer properties, so the filer cannot correctly match based on broadcast address (PID1[EBC]). The frame itself is not affected. Impact: If broadcast address matching is enabled, frames may be incorrectly filed or rejected. Workaround: Mask off matching on broadcast address flag (PID1[EBC] = 1) by clearing the bit 16 of the mask_register. If the rule needs to be able to distinguish broadcast addresses as defined by IEEE Std 802.3TM-2005 is all 1's in the destination address field, then use a filer rule with PID3 and PID4 (destination MAC address) to match on broadcast Ethernet frames. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 50 Freescale Semiconductor, Inc. General Business Information eTSEC 70: eTSEC does not support parsing of LLC/SNAP/VLAN packets Description: eTSEC supports parsing of LLC/SNAP headers following the Ethernet 802.3 length field interpretation. It also supports 802.1p VLAN tags. However, it does not support the encapsulation defined as Ethernet length, followed by LLC/SNAP, followed by VLAN. The parser prematurely completes "normally" upon encountering the VLAN Ether-type at the end of the LLC/SNAP encoding. The erratum is that no layer 3, layer 4, or VLAN information is submitted to the filer or reported in the RxFCB. Impact: This unique packet type is not parsed beyond layer 2, including any VLAN processing, because the parser terminated before the VLAN tag was found. Workaround: Software running on the host has to parse these packets because they indicate no parsing functions performed by eTSEC. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 51 General Business Information eTSEC 71: eTSEC filer reports incorrect Ether-types with certain MPLS frames Description: The eTSEC filer gets a property under PID = 7 called ETY. This usually corresponds to the last Ether-type that was encountered in a packet as it was parsed. In the case that there is an MPLS label in the packet, then the Ether-type is incorrectly returned as the last 2 bytes of the MPLS label. The last 2 bytes correspond to the LSB 4 bits of the label, the EXP field, the S field, and the TTL field. The eTSEC does not know of any header types that follow other than IPv4 or IPv6 through the use of reserved label values "IPv4 Explicit Null" and "IPv6 Explicit Null." Hence the Ether-type is always left as the last 2 bytes of the MPLS label. Impact: MPLS tagged packets report the incorrect Ether-type (8847 for MPLS unicast or 8848 for MPLS multicast). Workaround: Use arbitrary extraction bytes to compare to the actual Ether-type if a filer rule is intending to file based on an MPLS label existence. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 52 Freescale Semiconductor, Inc. General Business Information eTSEC 72: Compound filer rules do not roll back the mask Description: The eTSEC filer has associated with it a mask value that is used when rules are comparing fields of the packet against properties in the RQFPR table. The mask sets "don't cares" in the comparison. When building a compound rule through the use of the AND bit either in or outside of a cluster guard rule (CLE = 1) you can set masks as appropriate for the subsequent rule by setting CMP = 00/01, PID = 0, and RQPROP = "desired mask." If however the chained rule fails for any single rule, the mask should revert back to what it was prior to entering the rule chain. The erratum is that the mask does not roll back and the resulting mask can be unknown. Impact: Some rules may falsely match or not match causing the filing of a frame to the wrong queue or incorrectly rejecting the frame in the case of an assumption of the mask being a certain value. Workaround: When using a compound rule that consists of SETMASK rules, the user must put another SETMASK rule after the last rule in the chain that resets the mask to the value it was prior to entering the chain. The following table shows a compound rule example for work arounds. Table 4. Compound Rule Example for Work Arounds Table Entry Fix plan: RQCTRL CLE REJ AND Q CMP PID RQPROP Comment 0 0 0 1 0 0 7 0x0000_0800 -- 1 0 0 1 0 0 0 0xFFFF_0000 Setmask 2 0 0 1 0 0 12 0xC054_1200 -- 3 0 0 1 0 0 0 0xFF00_0000 Setmask 4 0 0 0 5 0 13 0xC055_0000 -- 5 0 0 0 0 0 0 0xFFFF_FFFF Work around Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 53 General Business Information eTSEC 73: Incomplete frame with error causes false CR error on next frame Description: If a receive error (RX_ER = 1) occurs on an incomplete Ethernet frame which is truncated before start of frame, the error indicator persists and is reported on the following frame by setting RxBD[CR] = 1. The incomplete frames that can trigger the error are: 1. A junk frame (random data with arbitrary # of beats and no start-of-frame found) 2. A frame with preamble, start-of-frame and with no data after the start-of-frame 3. A frame with preamble-only (no start-of-frame) Incomplete frames can occur due to collisions in half-duplex mode, or during recovery after a link down condition. Impact: An incomplete frame with error causes a false CR (code group or CRC) error on the next frame. Workaround: To work around this problem when the link is down, typically the PHY generates a link down interrupt. When this link down interrupt is detected, software should 1. Perform a soft_reset (MACCFG1[Soft_Reset] = 1) or a receiver reset (MACCFG1[Reset Rx Func] = 1) 2. Keep the MAC in reset until the link is up again. 3. Discard any frames received during link down. 4. Re-enable the receiver once the link is up. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 54 Freescale Semiconductor, Inc. General Business Information eTSEC 74: Parser does not check VER/TYPE of PPPoE packets Description: The Ethernet controller supports PPPoE VER/TYPE = 1 packets. For PPPoE packets with VER/TYPE not equal to 1, the controller should stop Ethernet parsing and treat it as an unrecognized PPPoE packet. Instead, the controller does not check the VER/TYPE field, and assumes it is 1. Impact: PPPoE packets with VER/TYPE that are not type 1 are parsed as if they are type 1 PPPoE. Workaround: None Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 55 General Business Information eTSEC 75: Back-to-back Rx frames may lose parser results of second frame Description: In some circumstances, the parser results for a frame may be calculated when the controller is still processing the previous frame. If this scenario occurs, the parser results for the second frame are discarded, and the preloaded all zeroes value of RxFCB is returned instead. The circumstances are related to format of the two frames, but are not controllable by the receiver or the user. Impact: Under some conditions that are not controllable by the receiver or user, parser results for the second of a back-to-back frame may be lost. If VLAN extraction is enabled, the VLAN ID is lost. Workaround: Option 1: Disable all parsing functions (RCTRL[PRSDEP] = 00. Option 2: Because this erratum impacts the RxFCB only, the filer still gets the correct information and be able to file to the appropriate queue or reject. If software now finds RxFCB all zeros, it must assume that it encountered this error. The only other time the RxFCB is all zeros is when the eTSEC didn't find any L2-L4 information that is recognized. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 56 Freescale Semiconductor, Inc. General Business Information eTSEC 76: RMCA, RBCA counters do not correctly count valid VLAN tagged frames Description: According to the reference manual, RMCA increments for each multicast frame with valid CRC and a length between 64 and 1518 (non-VLAN tagged frames) or 1522 (single VLAN tagged frames) excluding broadcast frames. RBCA is the same definition except it counts broadcast frames and not multicast frames. The erratum is that for a valid VLAN tagged frame greater than 1518 the eTSEC does not increment these registers. Impact: RBCA and RMCA do not increment for validly VLAN tagged Ethernet frames greater than 1518. Workaround: There is currently no work around for counting these packets other than software running on the core. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 57 General Business Information eTSEC 77: Tx errors truncate packets without error in 8-bit Encoded FIFO mode Description: In 8-bit encoded FIFO mode, there is no error code group or error signal to indicate a Tx error. If FIFOCFG[CRCAPP] = 1, a Tx error should corrupt the appended CRC to indicate the error. The documentation of 8-bit encoded FIFO mode states that Tx FIFO under-runs cause the controller to transmit a stream of invalid bytes . Instead, the Tx simply truncates the frame without appending the CRC at all. Impact: Transmit under-run, bus error (invalid address or data error on Tx BD or data fetch) and Tx FIFO data parity errors (see also eTSEC 61 concerning data parity errors) cause truncated frames without CRC corruption or transmission of invalid bytes. Workaround: Enable CRC append on Tx by setting FIFOCFG[CRCAPP] = 1 and CRC checking on Rx by setting FIFOCFG[CRCCHK] = 1. The truncation of the packet at the error presents a smaller than 1 in 4 billion chance that the last four bytes of the packet match the running CRC32 calculation, ensuring that the packet is still seen as an error. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 58 Freescale Semiconductor, Inc. General Business Information eTSEC 78: No parser error for packets containing invalid IPv6 routing header packet Description: If a packet with an IPv6 routing header has the "segments left" field greater than the actual number of Destination Addresses (DA) contained in the routing header, then this is an invalid packet. The erratum is that the eTSEC uses the last destination address from the routing header as part of the pseudo-header calculation for the L4 checksum Because this is really an invalid packet, the checksum should not be checked and a parse error should be flagged. Impact: An IPv6 routing header with segments left greater than number of DAs is not flagged as an invalid packet. Workaround: Consistency checks for IPv6 routing header packets must be performed in software, or skipped. Fix plan: Partially fixed in Rev 3.1.x Fixed the issue of an invalid packet being flagged as having a valid checksum (RxFCB[CTU]=1). MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 59 General Business Information eTSEC 79: Generation of Ethernet pause frames may cause Tx lockup and false BD close Description: The process of generating a PAUSE control frame may cause the controller to stop transmitting (Tx lockup). Once the controller enters a Tx lockup state, only a reset of the eTSEC (toggle MACCFG1[Tx_EN]) will allow it to start transmitting frames again. In addition to locking up, the controller may transmit two pause control frames instead of one. If this occurs, the controller erroneously sees the second pause frame as a transmitted data frame and closes the next TxBD. Pause flow control frame generation can be triggered by reaching the Rx FIFO threshold (basic flow control: MACCFG1[Tx_Flow]), running out of Rx buffer descriptors (lossless flow control: RCTRL[LFC]), or direct software control (TCTRL[TFC_PAUSE]). Impact: Workaround: Transmit flow control, lossless flow control, and software generation of pause flow control frames may cause the Ethernet controller to stop transmitting and falsely close a TxBD for an un-transmitted frame. * Option 1: Disable transmit flow control by setting MACCFG1[Tx_flow] = 0. * Option 2: Run with a minimum platform (CCB) frequency of 500 MHz to insure correct Ethernet operation at gigabit data rates. This workaround only applies to Ver 2.1.x. * Option 3: Use the following method to detect TX lock up and recover from it. Monitor Transmit Packet Counter TPKT and or Transmit Buffer Descriptor Pointers TBPTRn by software and if no change is detected in expected time, (several multiple of maximum transition time) and the Transmit halt of ring n bits in the Transmit Status Register TSTAT[THLTn] is not set, assume the transmitter is stuck by the above condition and proceed with the following recovery mechanism: a. b. c. d. e. f. g. h. i. j. k. l. Fix plan: Set DMACTRL[GRS] = 1 to perform a graceful receive stop Wait for IEVENT[GRSC] to be set, indicating stop complete Set DMACTRL[GTS] = 1 to perform a graceful transmit stop Wait for IEVENT[GTSC] to be set, indicating stop complete Write a 1 to IEVENT[GTSC] to acknowledge the event Clear MACCFG1[Tx_Flow] Wait 256 TX_CLK cycles Clear MACCFG1[Tx_EN] Wait 3 TX_CLK cycles Set MACCFG1[TX_EN] and MACCFG1[Tx_Flow] Set DMACTRL[GTS] = 0 to clear the graceful transmit stop Set DMACTRL[GRS] = 0 to clear the graceful receive stop Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 60 Freescale Semiconductor, Inc. General Business Information eTSEC 80: eTSEC parser does not perform length integrity checks Description: The eTSEC currently only uses the total length reported in the IPv4 or IPv6 header when calculating checksums. This checksum calculation includes the length used in the pseudoheader, and the actual length of the data in the payload. Proper operation when parsing a subsequent L4 header that has a length field (be it payload and/or header) should be to check for consistency against what is reported in the outer IP header. If there is a mismatch, the eTSEC should signal a parse error and not perform the UDP or TCP payload checksum check (for example, RxFCB[PERR] = 10 and RxFCB[CTU] = 0). One simple example of this is that UDP has its own payload length. If eTSEC encounters a simple IPv4/UDP packet it should take the IP total length field, subtract IP header length and that should equal the UDP payload length. If it doesn't then this packet is malformed. Impact: Could get false checksum failures or false checksum passes. Workaround: False checksum fails can be worked around by rechecking them in software running on the host. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 61 General Business Information eTSEC 81: eTSEC does not verify IPv6 routing header type field Description: The RFC2460 (current referenced standard for IPv6 operation) states that when encountering a packet with an unrecognized Routing Type Value, and the field "segments left" is non-zero, the node must discard the packet and return an ICMP Parameter problem, Code 0, message to the packet's source address. The eTSEC only recognizes type0 routing headers, but incorrectly interprets all Routing Type fields as type0 (for example, ignores the type field and continues parsing the packet including upper layer protocol checksums). The correct behavior is to signal parser error, and not check upper layer checksums Impact: eTSEC parser/checksum engine incorrectly interprets non-type0 IPv6 routing headers. Functionally, this is a future-proof issue because there are currently no other type-fields defined. Workaround: If this device is operating in a network that is using non-type0 IPv6 routing headers, then the upper layer processing (IPv6 extension headers, and payload checksumming operations) must be performed in software. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 62 Freescale Semiconductor, Inc. General Business Information eTSEC 82: Transmission of truncated frames may cause hang or lost data Description: If all three of the following conditions are concurrently met the controller may hang, or drop some bytes from the second frame without any error indication: 1. The Ethernet controller truncates a transmitted frame which is larger than MAXFRM 2. The following frame has TOE = 1 3. The two frames together are large enough to fill the 10-Kbyte Tx FIFO without truncation See also eTSEC 65. Impact: Workaround: Fix plan: Truncating frames larger than MAXFRM may cause a transmit hang or lost data if combined with TOE = 1 frames. * Option 1: Disable truncation by setting MACCFG2[Huge Frame] = 1. * Option 2: Turn off TCP/IP offload enable by setting TxBD[TOE] = 0. Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 63 General Business Information eTSEC 83: L3 fragment frame files on non-existent source/destination ports Description: If the controller detects a L3 fragment, it should terminate parsing. Instead, it continues to the end of the header looking for a L4 header, extracts non-existent source and destination ports, and may file the fragment based on port match. Impact: Workaround: Fix plan: L3 fragment frames may be parsed and filed incorrectly. * Option 1: Include a filer rule to reject on PID1[IPF] at the beginning of the table. * Option 2: Limit parsing to L2 by setting RCTRL[PRSDEP] = 01. Note that limiting parsing to L3 by setting RCTRL[PRSDEP] = 10 is not a valid work around (refer to eTSEC 66). Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 64 Freescale Semiconductor, Inc. General Business Information eTSEC 84: Multiple BD frame may cause hang Description: In the device reference manual, it states the following: Software must expect eTSEC to prefetch multiple TxBDs, and for TCP/IP checksumming an entire frame must be read from memory before a checksum can be computed. Accordingly, the R bit of the first TxBD in a frame must not be set until at least one entire frame can be fetched from this TxBD onwards. If eTSEC prefetches TxBDs and fails to reach a last TxBD (with bit L set), it halts further transmission from the current TxBD ring and report an underrun error as IEVENT[XFUN]; this indicates that an incomplete frame was fetched, but remained unprocessed. If software sets up a frame with multiple BDs, and sets the first BD READY bit before the remaining BDs are marked ready, and if the controller happens to prefetch the BDs when some are marked ready and some marked unready, the controller may not halt or set IEVENT[XFUN], hanging the transmit. Impact: If software does not follow the guidelines for setting the ready bit of the first BD of a multiple TxBD frame, the Ethernet controller may hang. Workaround: Software must ensure that the ready bit of the first BD in a multiple TxBD frame is not set until after the remaining BDs of the frame are set ready. Fix plan: Fixed in Rev 3.1.x if multiple Tx queues enabled. No plans to fix for single queue case. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 65 General Business Information eTSEC 85: TxBD[TC] is not reliable in 16-bit FIFO modes Description: CRC append can be done in hardware, in software, or not at all in FIFO modes. If some frames have software CRC append, and some do not, customers may enable hardware-based CRC append on a frame-by-frame basis by setting TxBD[TC] = 1. In 16-bit FIFO modes (GMIIstyle or encoded), the TxBD[TC] setting for a frame is not properly pipelined, so some frames with TxBD[TC] = 1 end up transmitting without CRC appended and some frames with TxBD[TC] = 0 end up with CRC appended by the controller. Impact: Workaround: Fix plan: The Ethernet controller does not reliably append CRC based on TxBD[TC] in 16-bit FIFO modes. * Option 1: Set FIFOCFG[CRCAPP] = 1 in 16-bit FIFO modes to force hardware append of CRC on all frames, regardless of TxBD[TC] state. * Option 2: Set all TxBD[TC] = 0. Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 66 Freescale Semiconductor, Inc. General Business Information eTSEC 86: eTSEC receivers may not be properly initialized Description: When MACCFG1[Rx_EN] is enabled during system boot as part of the eTSEC port initialization sequence, the eTSEC Rx logic may not be properly initialized. Impact: When the eTSEC Rx logic is not properly initialized, packet data may be incorrectly received . When this occurs, the first packet received (and subsequent packets) will be affected. Failure modes can include eTSEC Rx logic "deadlock". Workaround: During system boot, prior to setting MACCFG1[Rx_EN] in each eTSEC, perform the following: 1. Configure the eTSEC for the expected operation (for example, if use of MAC address filtering is intended, then enable address filtering; if use of the filer is intended, then enable the filer), but do not set MACCFG1[Tx_EN] and MACCFG1[Rx_EN]. 2. Set MACCFG1[Loop Back]. 3. Set MACCFG1[Tx_EN] and MACCFG1[Rx_EN] 4. Transmit two (2) packets and compare the received packets to the transmitted packets. If packets are not received within 10 ms, toggle MACCFG1[Rx_EN] and repeat step (4). 5. If the comparison is not equal, toggle MACCFG1[Rx_EN] and repeat step (4) to reinitialize the eTSEC Rx logic. 6. Clear MACCFG1[Loop Back] for the eTSEC. NOTE While in Loop Back mode, the controller must also be in FullDuplex mode. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 67 General Business Information eTSEC 87: Arbitrary Extraction cannot extract last data bytes of frame Description: If the arbitrary extraction offset defined in the RBIFX register points to data in the last beat of a frame, the associated ARB property sent to the filer may be zero instead of the data at the designated offset, depending on packet type and length. The following packet and extraction types are affected: * L2, L3 or L4 extraction of packets with frame length 4n or 4n + 3 * L4 extraction of TCP/UDP packets with IP total length 4n + 1, 4n + 2, or 4n + 3. Impact: The following conditions apply to any type of frame and L2, L3 or L4 extraction: * For frame length of 4n, the last 2 bytes of the frame are not extractable. This applies to L2, L3 or L4 extraction in MAC or FIFO modes. * For frame length of 4n + 3, the last 1 byte of the frame is not extractable. This applies to L2, L3 or L4 extraction in MAC or FIFO modes. The following conditions apply to L4 extraction from a packet with TCP/UDP data (when RCTRL[PRSDEP] = 11, RCTRL[TUCSEN] = 1): * For IP total length of 4n + 1, the L4 byte offsets 4n + m - <IP header length> are not extractable, for m = 1, 2, or 3. * For IP total length of 4n + 2, the L4 byte offsets 4n + m - <IP header length> are not extractable, for m = 2 or 3. * For IP total length of 4n + 3, the L4 byte offset 4n + 3 - <IP header length> is not extractable Workaround: None Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 68 Freescale Semiconductor, Inc. General Business Information eTSEC 88: False TCP/UDP and IP checksum error in FIFO mode without CRC appending Description: Running the Ethernet controller in 8- or 16-bit FIFO mode (GMII-style or encoded) with CRC appending and checking disabled (FIFOCFG[CRCAPP] = 0 for Tx and FIFOCFG[CRCCHK] = 0 for Rx) may cause the IP or TCP/UDP checksum parsing to skip the last two bytes of the frame. This results in a false IP or TCP/UDP header checksum error because the parser may not read the data in the frame properly. Impact: IP or TCP/UDP checksum checking, enabled through RCTRL[IPCSEN] and RCTRL[TUCSEN], may generate false errors reported in the RxFCB in FIFO modes when a CRC is not appended to the frame. Workaround: Set FIFOCFG[CRCCHK] = 1 to enable CRC checking on Rx and enable CRC append on the corresponding Tx on the link (by setting the equivalent of FIFOCFG[CRCAPP] = 1). Having CRC in the frame ensures that the last data beat is properly aligned for IP or TCP/UDP checksum checking. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 69 General Business Information eTSEC 89: Frames greater than 9600 bytes with TOE = 1 will hang controller Description: The eTSEC supports frames up to 9600 bytes (huge or jumbo frame). If a frame has TOE = 1, it must be no more than 9600 bytes to fit entirely into the Tx FIFO. If the frame is larger, the controller hangs, because it must have the last byte of data in the FIFO to calculate the checksum and allow the frame to start transmission. Impact: A frame larger than 9600 bytes with TOE = 1 hangs the Ethernet controller. Workaround: For frames larger than 9600 bytes, set TxBD[TOE] = 0. For frames with TxBD[TOE] = 1, ensure Tx frame length 9600 bytes. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 70 Freescale Semiconductor, Inc. General Business Information eTSEC 90: Setting RCTRL[LFC] = 0 may not immediately disable LFC Description: Lossless flow control is controlled by RCTRL[LFC]. Setting RCTRL[LFC] = 0 should immediately disable the lossless flow control state machine and stop the sending of pause frames based on number of free RxBDs. The controller instead waits until the state machine is idle before disabling it. If the state machine has been triggered by the number of free RxBDs falling below the threshold, the controller continues sending pause frame extensions until the number of free RxBDs exceeds the threshold. Impact: Generation of pause frames due to lack of free RxBDs may continue for a time after setting RCTRL[LFC] = 0. Workaround: When disabling LFC, first set RCTRL[LFC] = 0, then poll the number of free RxBDs until it exceeds the threshold. Once the number of free RxBDs exceeds the threshold, the configuration for LFC may be safely modified. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 71 General Business Information eTSEC 91: VLAN Insertion corrupts frame if user-defined Tx preamble enabled Description: When TCTRL[VLINS] = 1, the VLAN is supposed to be inserted into the Tx frame 12 bytes after start of the Destination Address (after DA and SA). If user-defined Tx preamble is enabled (MACCFG2[PreAmTxEn] = 1), the VLAN ID is inserted 12 bytes after the start of the preamble (4 bytes after start of DA), thus overwriting part of DA and SA. Impact: If VLAN insertion is enabled with user-defined Tx preamble, the VLAN ID corrupts the Tx frame destination and source addresses. Workaround: Use one of the following workarounds: * Disable user-defined Tx preamble by setting MACCFG2[PreAmTxEn] = 0. * Disable VLAN insertion by setting TCTRL[VLINS] = 0. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 72 Freescale Semiconductor, Inc. General Business Information eTSEC 92: False parity error at Tx startup Description: The 10 KB TxFIFO comes out of reset in an unitialized state. Each FIFO entry is initialized as Tx frame data is written to it. Under certain internal resource contention conditions, the controller may read uninitialized data and falsely signal a parity error in IEVENT. Impact: If parity errors are enabled before the first 10KB of Tx frame data is written to the TxFIFO, pause frames or Tx frames may trigger a false data parity error event. On silicon version 2.1 only, the false parity error may cause FCS corruption on the transmitting frame, if there is one. Workaround: Disable parity error detection by setting EDIS[DPEDIS]=1 until at least 10 KB of Tx data has been transmitted. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 73 General Business Information eTSEC 93: Transmit fails to utilize 100% of line bandwidth Description: The minimum interpacket gap (IPG) between back-to-back frames is 96 bit times. To ensure 100% utilization of an interface, the maximum gap between back-to-back streaming frames should also be 96 bit times (12 cycles). The Tx portion of the Ethernet controller may fail to meet that requirement, depending on mode, clock ratio, and internal resource contention. * For revisions prior to 3.0 for single-queue operation, IPG varies between 12-15 cycles. * For revision 3.0, erratum is fixed for single queue operation and IPG is 12 cycles. * For multiple queue operation with fixed priority scheduling, IPG for back-to-back frames from different queues varies between 70-140 cycles. * For multiple queue operation with round-robin scheduling, IPG for back-to-back frames from different queues is on the order of 20-40 cycles longer than multiple queue operation with fixed priority. In all cases, the impact of longer IPG is greater for smaller frames. With multiple queue operation, small frames may also increase the gap, as the buffer descriptor (BD) prefetching may fall behind the data rate, especially at lower clock ratios. Impact: Tx bandwidth cannot achieve 100% line rate, especially for multiple queue operation or relatively small frames. Workaround: The following options maximize the bandwidth utilized by the Ethernet controller. * If multiple Tx queue operation is not required, use single Tx queue operation (thus eliminating the extra gap caused by switching queues) and use frames larger than 64 bytes (thus reducing the IPG as a portion of total bandwidth). * If multiple Tx queue operation is required, use priority arbitration by setting TCTRL[TXSCHED]=2'b01 and maximize the number of BDs enabled per ring to minimize switching between rings. Also, minimize use of small frames, thus reducing IPG as a portion of total bandwidth. Fix plan: Partially fixed in Rev 3.1.x Fixed for single queue operation and IPG is 12 cycles. MPC8548E Chip Errata, Rev. 6, 6/2012 74 Freescale Semiconductor, Inc. General Business Information eTSEC 94: Rx packet padding limitations at low clock ratios Description: There are two mechanisms that cause extra bytes to be inserted in front of the data in a received frame: 1. RCTRL[PAL] - packet alignment padding. A programmable mechanism for padding a frame with zeroes to achieve a particular alignment of data. 2. MACCFG2[PreamRxEn] - enables inserting the 8-byte preamble in front of the Rx frame data within the data buffer. These bytes are not accounted for in the value of RCTRL[PAL] setting. At low clock ratios (less than 2:1 eTSEC system clock to TSECn_TX_CLK), it is possible to overflow the receive buffer where the extra bytes are inserted before data is written to the 2 KB Rx FIFO. When this Rx buffer overflow occurs, the current Rx frame will be dropped and the subsequent frame may be passed to memory without the expected padding bytes inserted. Impact: If the eTSEC is running at less than 2:1 eTSEC system clock to TSECn_TX_CLK ratio, the controller cannot support inserting 24 or more total bytes (from padding, and the preamble) in front of the frame data Workaround: Limit total receive packet byte insertion via RCTRL[PAL] and Rx preamble enable to less than 24 bytes total when running at less than 2:1 eTSEC system clock:TSECn_TX_CLK ratio. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 75 General Business Information eTSEC 95: False TCP/UDP checksum error for some values of pseudo header Source Address Description: The Ethernet controller calculates the pseudo header checksum by first calculating the checksum for the individual fields of the pseudo header, then merging the checksums and carry bits. If the checksum for the Source Address (SA) field of the pseudo header is 0x1_0000 (16-bit checksum=0 with carry out=1), the carry bit is not included in the combined checksum, resulting in a false checksum error (RxFCB[ETU]=1). A pseudo header SA checksum of 0x1_0000 is only possible for IPv6frames, not IPv4. Impact: False ETU indication when check sum for pseudo header SA is 0x1_0000 for IPv6 frames. Workaround: If RxFCB[CTU]=1, RxFCB[ETU]=1 and RxFCB[IP6]=1, calculate the checksum for the SA field from the pseudo header. If this checksum equals 0x1_0000, then proceed to calculate the entire TCP checksum to be sure the checksum error is valid. If the SA checksum is not 0x1_0000, then the ETU is a valid checksum error indication. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 76 Freescale Semiconductor, Inc. General Business Information eTSEC 96: Unexpected babbling receive error in FIFO modes Description: In MAC modes, a babbling receive error occurs if MACCFG2[Huge Frame]=1 and a receive frame exceeds MAXFRM. There is no MAXFRM in FIFO modes, so there should be no babbling receive errors. However, the Ethernet controller does not qualify the babbling receive error with interface mode, so a babbling receive error will be reported if a receive frame on a FIFO interface exceeds the value of MAXFRM. Impact: The controller may erroneously report babbling receive errors in FIFO mode. Workaround: In FIFO modes, disable interrupts for babbling receive errors by setting IMASK[BREN]=0, and ignore any setting of IEVENT[BABR]. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 77 General Business Information eTSEC 97: User-defined Tx preamble incompatible with Tx Checksum Description: If user-defined Tx preamble is enabled (by setting MACCFG2[PreAmTxEn]=1), an extra 8 bytes of data is added to the frame in the Tx data FIFO. IP and TCP/UDP checksum generation do not take these extra bytes into account and write to the wrong locations in the frame. Impact: Enabling both user-defined Tx preamble and IP or TCP/UDP checksum causes corruption of part of the corresponding header. Workaround: Use one of the following workarounds: * Disable user-defined Tx preamble by setting MACCFG2[PreAmTxEn] = 0. * Disable IP and TCP/UDP checksum generation by setting TCTRL[IPCSEN]=0 and TCTRL[TUCSEN] = 0. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 78 Freescale Semiconductor, Inc. General Business Information eTSEC 98: FIFO16 interface encoded mode maximum frequency is 1/4.2 platform clock Description: The current specification for eTSEC running in FIFO16 encoded mode allows the FIFO interface to run as fast as 1/3.2 of the platform clock. For example, for a device running platform at 533 MHz, the maximum supported FIFO16 interface frequency would be 166 MHz. At FIFO16 interface frequencies faster than 1/4.2, the Ethernet controller may fail to process incoming frames properly, leading to corrupted frame data, parser results, or controller state. Note that GMII-style FIFO interfaces already specify a maximum interface frequency of 1/4.2 the platform clock. Impact: The maximum interface frequency for either encoded or GMII-style mode is 1/4.2 the platform frequency, as shown in the following table: Platform Frequency Max FIFO16 Interface Frequency 600 MHz 142 MHz 533 MHz 126 MHz 500 MHz 119 MHz Workaround: Run the FIFO16 interface no faster than 1/4.2 the platform clock. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 79 General Business Information eTSEC 99: ECNTRL[AUTOZ] not guaranteed if reading MIB counters with software Description: The MIB function of the Ethernet controller has a feature to automatically zero out the registers when reading them if ECNTRL[AUTOZ] = 1. If the register read occurs in the same cycle as a hardware update of the register, then the register clear will not occur. Any software periodically reading MIB registers would expect to read A the first time, B the second, and C the third, with each value representing only the events that occurred in the interval between reads. If the first read collides with a hardware update, the second read would return A + B instead of B. Hardware updates for MIB registers occur once per frame. For streaming 64-byte frames, the update would be every 84 Rx or Tx clocks (8 bytes of preamble, 64 bytes of data and 12 cycles of IPG). Impact: Software polling of MIB counters with ECNTRL[AUTOZ] = 1 will over an extended period read a larger number of events than actually seen by the controller. Workaround: Disable automatic clearing of the MIB counters by writing ECNTRL[AUTOZ] = 0. Software routines which periodically read MIB counters and accumulate the results should accumulate only when an MIB counter overflows, as in the description that follows: Assuming a 32-bit MIB counter (MIB_VALUE), a 64-bit accumulator consisting of two 32-bit registers (ACCUM_HI, ACCUM_LO), and a Carry Out bit (ACCUM_LO_CO), change the 64-bit accumulator update as follows: Previous accumulate method (with ECNTRL[AUTOZ] = 1): // Accumulate the MIB_VALUE into the lower half of the accumulator {ACCUM_LO_CO,ACCUM_LO} = {1'b0,ACCUM_LO} + {1'b0,MIB_VALUE}; // Accumulate the Carry Out from the step above, as well as the MIB register OVFRFLW, which is detected through the CARn register. {ACCUM_HI_CO,ACCUM_HI} = {1'b0,ACCUM_HI} + ACCUM_LO_CO + OVRFLW; New accumulate method (with ECNTRL[AUTOZ]=0): // Read instead of accumulate since we are not clearing MIB_VALUE ACCUM_LO = MIB_VALUE; // Accumulate the MIB register OVRFLW, which is detected through the CARn register {ACCUM_HI_CO,ACCUM_HI} = {1'b0,ACCUM_HI} + OVRFLW; Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 80 Freescale Semiconductor, Inc. General Business Information eTSEC 100: Half-duplex collision on FCS of Short Frame may cause Tx lockup Description: In half-duplex mode, if a collision occurs in the FCS bytes of a short (fewer than 64 bytes) frame, then the Ethernet MAC may lock up and stop transmitting data or control frames. Only a reset of the controller can restore proper operation once it is locked up. Impact: A collision on hardware-generated FCS bytes of a short frame in half-duplex mode may cause a Tx lockup. Workaround: Option 1: Set MACCFG2[PAD/CRC] = 1, which pads all short Tx frames to 64 bytes. Option 2: Use software-generated CRC (MACCFG2[PAD/CRC] = 0, MACCFG2[CRC EN] = 0 and TxBD[TC] = 0) Fix plan: Documentation update The reference manual will be updated to require padding of all short Tx frames when in halfduplex mode (MACCFG2[Full Duplex] = 0). MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 81 General Business Information eTSEC 101: Magic Packet Sequence Embedded in Partial Sequence Not Recognized Description: The Ethernet MAC should recognize Magic Packet sequences as follows: Any Ethernet frame containing a valid Ethernet header (Destination and Source Addresses) and valid FCS (CRC-32), and whose payload includes the specific Magic Packet byte sequence at any offset from the start of data payload. The specific byte sequence comprises an unbroken stream of 102 bytes, the first 6 bytes of which are 0xFFs, followed by 16 copies of the MAC's unique IEEE station address in the normal byte order for Ethernet addresses. If a complete Magic Packet sequence (including 6 bytes of 0xFF) immediately follows a partial Magic Packet sequence, however, the complete sequence will not be recognized and the MAC will not exit Magic Packet mode. The following are example partial sequences followed by the start of a complete sequence for station address 01_02_03_04_05_06: * Sequence a) FF_FF_FF_FF_FF_FF_FF_01_02_03_04_05_06_01... Seventh byte of 0xFF does not match next expected byte of Magic Packet Sequence (01). Pattern search restarts looking for 6 bytes of FF at byte 01. * Sequence b) FF_FF_FF_FF_FF_FF_01_FF_FF_FF_FF_FF_FF_01_02_03_04_05_06_01... First FF byte following 01 does not match Magic Packet sequence. Pattern search restarts looking for 6 bytes of FF at second byte of FF following 01. The following is an example partial sequence followed by the start of a complete sequence that is erroneously not recognized for station address 01_02_03_04_FF_06: * Sequence c) FF_FF_FF_FF_FF_FF_01_02_03_04_FF_FF_FF_FF_FF_FF_01... 11th byte (0xFF) is seen as the 11 byte of the partial pattern and is not recognized as the start of a complete sequence. Pattern search restarts looking for 6 bytes of 0xFF at 12th byte, but sees only 5. Impact: The Ethernet controller will not exit Magic Packet mode if the Magic Packet sequence is placed immediately after other frame data which partially matches the Magic Packet Sequence. Workaround: Place 1 byte of data that is not 0xFF and does not match any bytes of DA before the start of the Magic Packet sequence in the frame. Because the Magic Packet sequence pattern search starts at the 3rd byte after DA, the Magic Packet Sequence can be placed at the start of the data payload as long as the second byte of the length/type field follows the above rule. Fix plan: Partially fixed in Rev 3.1.x Sequences a) and b)--fixed Sequence c)--no plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 82 Freescale Semiconductor, Inc. General Business Information eTSEC 104: Rx may hang if RxFIFO overflows Description: If the memory subsystem is unable to keep up with incoming traffic, the Rx FIFO may fill up and overflow. If the RxFIFO fills up, the controller should gracefully drop packets. Instead, under certain conditions on the interface between the controller and the memory subsystem, the Rx will lock up and stop receiving without any error indication. Impact: For low ratios from platform to Rx_clk and slow memory systems, the Rx FIFO may overflow and hang the Rx controller. Workaround: To reduce the probability of an RxFIFO overflow, enable flow control by setting MACCFG1[Tx Flow] = 1. Statistical lockup detection and recovery: Lockup detection: 1. Enable debug mode in the controller by writing 0x00E00C00 to offset 0x000 (TSEC_ID1). 2. Periodically poll the state of the Ethernet controller by reading RPKT, RSTAT, and the register at offset 0xD1C. If RPKT has changed, the RSTAT[QHLTn] bits are clear, and the value of register offset 0xD1C has not changed, wait X*16 bit times, where X is the largest frame expected to be received on this interface, then read the value of register offset 0xD1C again. If it still has not changed, and RPKT has changed again, then the Rx controller may be locked up. If promiscuous mode is disabled (RCTRL[PROM] = 0), or if the controller is likely to receive and discard fragmentary packets (both of which may cause RPKT to increment for packets which are discarded before the RxFIFO) additional iterations may be required to reduce the probability of a false lockup detect. There is no guaranteed algorithm to detect Rx lockup with zero false positives. Lockup recovery: 1. Perform a graceful receive stop by setting DMACTL[GRS] = 1, and wait to ensure any outstanding prefetches are cleared. The wait time is system and memory dependent, but a reasonable worst-case time is the receive time for a 9.6 KB frame at 10/100/1000 Mbps). Note that if the Rx is truly locked up, IEVENT[GRSC] will never be set. The graceful receive stop also ensures that data and state are not corrupted during a soft reset if the lockup detection falsely detects a lockup due to rejected packets. 2. Toggle MACCFG1[Rx En] (set to 0, then set to 1). 3. Clear the graceful receive stop by setting DMACTL[GRS] = 0. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 83 General Business Information eTSEC 105: MAC: Malformed Magic Packet Triggers Magic Packet Exit Description: The Ethernet MAC should recognize Magic Packet sequences as follows: Any Ethernet frame containing a valid Ethernet header DA/SA (Destination and Source Addresses) and valid FCS (CRC-32), and whose payload includes the specific Magic Packet byte sequence at any offset from the start of data payload. The specific byte sequence comprises an unbroken stream of 102 bytes, the first 6 bytes of which are 0xFFs, followed by 16 copies of the MAC's unique IEEE station address in the normal byte order for Ethernet addresses. Once the Ethernet MAC has recognized a valid DA for one frame, it continues searching for valid 102-byte Magic Packet sequences through multiple frames without checking for valid DA on each frame. Therefore, a frame without a valid DA could erroneously cause the ethernet controller to exit Magic Packet mode. The only events that cause the MAC to go back to check for valid DA before checking for a Magic Packet sequence on new frames are: 1. A frame containing a recognized full Magic Packet sequence (with valid or invalid FCS) 2. Software disable of Magic Packet mode (MACCFG2[MPEN]=0) 3. MAC soft reset (MACCFG1[Soft_Reset]=1) The Ethernet controller may exit Magic Packet mode if it receives a frame with DA not matching station address, or invalid unicast or broadcast address, but a valid Magic Packet sequence for the device. Impact: A packet with a non-matching Destination Address may be incorrectly recognized as a Magic Packet. Workaround: None Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 84 Freescale Semiconductor, Inc. General Business Information eTSEC 106: Excess delays when transmitting TOE=1 large frames Description: The Ethernet controller supports generation of TCP or IP checksum in frames of all sizes. If TxBD[TOE]=1 and TCTRL[TUCSEN]=1 or TCTRL[IPCSEN]=1, the controller holds the frame in the TxFIFO while it fetches the data necessary to calculate the enabled checksum(s). Because the checksums are inserted near the beginning of the frame, transmission cannot start on a TOE=1 frame until the checksum calculation and insertion are complete. For TOE=1 huge or jumbo frames, the data required to generate the checksum may exceed the 2500-byte threshold beyond which the controller constrains itself to one memory fetch every 256 eTSEC system clocks. This throttling threshold is supposed to trigger only when the controller has sufficient data to keep transmit active for the duration of the memory fetches. The state machine handling this threshold, however, fails to take large TOE frames into account. As a result, TOE=1 frames larger than 2500 bytes often see excess delays before start of transmission. Impact: TOE=1 frames larger than 2500 bytes may see excess delays before start of transmission. Workaround: Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to memory throttling. When using packets larger than 2700 bytes, it is recommended to turn TOE off. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 85 General Business Information eTSEC 107: Controller may not be able to transmit pause frame during pause state Description: When the Ethernet controller pauses transmit of normal frames after receiving a pause control frame with PTV!=0, it should still be able to transmit pause control frames. The Ethernet controller, however, does not check whether the MAC is paused before initiating a start-offrame request to the MAC. Once it has initiated a start-of-frame request, the Ethernet controller cannot initiate a pause control frame request until the normal frame completes transmission. Since the MAC will not transmit the normal frame until the pause time expires, this means the controller may be unable to transmit a pause frame while it is in pause state if there is a normal frame ready to transmit. Impact: The Ethernet controller may be unable to transmit a pause frame during pause state if a normal frame is ready to transmit. This applies to pause frame generation as a result of RxFIFO over threshold (ordinary flow control), free BDs below threshold (lossless flow control), or software-generated pause frame (TCTRL[TFC_PAUSE]). Workaround: None Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 86 Freescale Semiconductor, Inc. General Business Information eTSEC-A001: MAC: Pause time may be shorter than specified if transmit in progress Description: When the Ethernet controller receives a pause frame with PTV!=0, and MACCFG1[Rx Flow]=1, it completes transmitting any current frame in progress, then should pause for PTV*512 bit times. The MAC, however, does not take the full transmission time of the current frame into account when calculating the Tx pause time, and may pause for 1-2 pause quanta (512-1024 bit times) less than the PTV value. Impact: The eTSEC transmitter may pause transmission for up to 1024 bit times less than requested in a receive pause frame. If the PTV value does not contain at least 2 pause quanta worth of margin, this may lead to receive buffer overflows in the link partner. Since the transmit pause does not take effect until after the current frame completes transmitting, the link partner's pause frame generator must already include the maximum frame size as margin when calculating the pause time value to use to prevent overflow of the receiver's buffers. Workaround: Add 2 pause quanta to the pause time value used when generating pause frames to prevent receive buffer overflow. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 87 General Business Information eTSEC-A002: Incomplete GRS or invalid parser state after receiving a 1- or 2-byte frame Description: Ethernet standards define the minimum frame size as 64 bytes. The eTSEC controller also supports receiving short frames less than 64B, and can accept frames more than 16B and less than 64B if RCTRL[RSF] = 1. Frames shorter than 17 bytes are supposed to be silently dropped with no side-effects. There are, however, two scenarios in which receiving frames <= 2B cause erroneous behavior in the controller. In the first scenario, if the last frame (such as an illegal runt packet or a packet with RX_ER asserted) received prior to asserting graceful receive stop (DMACTRL[GRS]=1) is <= 2 bytes, then the controller will fail to signal graceful receive stop complete (IEVENT[GRSC]) even though the GRS has successfully executed and the receive logic is completely idle. Any subsequent receive frame which is larger than 2 bytes will reset the state so the graceful stop can complete. An Rx reset will also reset the state. In the second scenario, the parser and filer are enabled (RCTRL[PRSDEP] = 01,10,11). If a 1 or 1.5B frame is received, the controller will carry over some state from that frame to the next, causing the next frame to be parsed incorrectly. This in turn may cause incorrect parser results in RxFCB and incorrect filing (accept versus reject, or accept to wrong queue) for that following frame. The parser state recovers itself after receiving any frame >= 2B in length. Impact: If software initiates a graceful receive stop after a 1- or 2-byte frame is received, the stop may not complete until another frame has been received. A frame following a 1 or 1.5B frame may be parsed and filed incorrectly. Workaround: For GRS scenario: After asserting graceful receive stop (DMACTRL[GRS] = 1), initiate a timeout counter. The wait time is system and memory dependent, but a reasonable worst-case time is the receive time for a 9.6 Kbyte frame at 10/100/1000 Mbps. If IEVENT[GRSC] is still not set after the timeout, read the eTSEC register at offset 0xD1C. If bits 7-14 are the same as bits 23-30, the eTSEC Rx is assumed to be idle and the Rx can be safely reset. If the register fields are not equal, wait for another timeout period and check again. MAX Rx reset procedure: 1) Clear MACCFG[RX_EN]. 2) Wait three Rx clocks. 3) Execute workaround for the following eTSEC erratum: eTSEC receivers may not be properly initialized. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 88 Freescale Semiconductor, Inc. General Business Information eTSEC-A004: User-defined preamble not supported at low clock ratios Description: The Ethernet controller is not designed to inject user-defined preambles into Tx frames at eTSEC system clock to Tx clock ratios of less than 1.8:1. If the controller is run with a slower eTSEC system clock, the eTSEC may hang, underrun, or corrupt the transmitting frame. Impact: User-defined Tx preamble may cause hang, underrun, or corrupted frames. Workaround: Disable user-defined preamble Tx injection by setting MACCFG2[PreAmTxEn]=0. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 89 General Business Information eTSEC-A005: Rx may hang on eTSEC3 and eTSEC4 under extreme temperature, low Vdd and heavy traffic Description: Affected Devices: All revs and part numbers of the MPC8548(E) or MPC8547(E) with platform frequencies of 533 MHz. Writes from either eTSEC3 or eTSEC4 to memory that require a stall due to platform bandwidth limitations can lead to a lockup of eTSEC3 and eTSEC4. Writes to memory can momentarily stall under multiple conditions that are difficult to predict. The probability of a stall increases with high eTSEC Rx utilization in combination with high platform bandwidth utilization. The problem is negatively effected by elevated device junction temperature or low operating voltage. eTSEC1 and eTSEC2 are not affected. Impact: Heavy traffic on eTSEC3 or eTSEC4 - particularly at high temperature - may result in eTSEC3 and eTSEC4 lock up. Only a hardware reset will unlock the controller. Workaround: Reduce platform frequency to 400MHz for full spec operation. There is no workaround for 533 MHz operation. If a lockup occurs, only a hardware reset will unlock the controller. Fix plan: Fixed in Rev 2.1.3 MPC8548E Chip Errata, Rev. 6, 6/2012 90 Freescale Semiconductor, Inc. General Business Information PCI-Ex 35: Rx detection by transmitter does not pass high receiver impedance test Description: The PCI Express specification high receiver impedance test (PHY Electrical Test Considerations, Revision 1.0) requires the receiver detect function to not detect a receiver when there is up to 3 nF of capacitance across a 200 k resistor. The PCI Express controller only supports up to 200 pF of capacitance. Impact: This has only been seen to cause problems with some mid-bus probes that exhibit a high capacitance. Workaround: None Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 91 General Business Information PCI-Ex 37: Completion Timeout error disable corrupts CRS threshold error data Description: Several attributes of enabled error conditions are written to the PEX Error Capture Status register (offset 0xE20) when an error condition is detected. If PEX_ERR_DISR[PCTD]=1 (disable detection of Completion Timeout threshold errors), then the global source ID attribute (PEX_ERR_CAP_R2[GSID]) for CRS Threshold errors will be incorrect. Impact: An incorrect global source ID is captured in PEX Error Capture Status register for CRS Threshold errors if Completion Timeout errors are disabled. Workaround: Enable Completion Timeout and CRS threshold error detection by keeping the default setting of PEX_ERR_DISR[PCTD]=0 and PEX_ERR_DISR[CRSTD] = 0. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 92 Freescale Semiconductor, Inc. General Business Information PCI-Ex 38: PCI Express LTSSM may fail to properly train with a link partner following HRESET Description: Following HRESET, the PCI Express controller will enter the internal LTSSM (link training and status state machine), and may fail to properly detect a receiver as defined in the PCI Express Base Specification. Failing to properly detect a receiver can be determined by reading the LTSSM state status registers (offset 0x404) in the PCI Express extended configuration space. When this failure has occurred the status code can be either 0 or 1h, indicating that it is still in a detect state. If the link has properly trained, the status code will read 0x16h. Impact: Following HRESET, (or a hot swap and/or dynamic power up/down on the link partner) the PCI Express controller may fail to properly train with an active link partner, causing the PCI Express controller to hang. Workaround: In the boot code perform the following function for both root complex and endpoint applications: 1. OR the value at CCSRBAR offset 0x0_AF00 with 0x0800_0000 2. Wait 1 ms 3. AND the value at the CCSRBAR offset 0x0_AF00 with 0xF7FF_FFFF. This sequence resets the PCI Express controllers only. There is no workaround for this erratum when booting from PCI Express. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 93 General Business Information PCI-Ex 39: No mechanism for recovery from hang after access to down link Description: When its link goes down, the PCI Express controller clears all outstanding transactions with an error indicator and sends a link down exception to the interrupt controller if PEX_PME_MES_DISR[LDDD] = 0. If, however, any transactions are sent to the controller after the link down event, they will be accepted by the controller and wait for the link to come back up before starting any timeout counters (e.g. completion timeout). There is no mechanism to cancel the new transactions short of a device HRESET. Impact: New transactions sent to a PCI Express link which is down will not complete or invoke a recoverable time out until the link recovers. The outstanding transactions may cause a core or other master (e.g. DMA) hang or a core watchdog timeout. Workaround: The problem can be mitigated by ensuring that link down exceptions are enabled (PEX_PME_MES_DISR[LDDD] = 0), and cause access to the PCI Express interface to be disabled for the duration of the link down. Note that PCI Express controller access can be via normal reads and writes (LAW/ATMU target) or by reads or writes to CONFIG_DATA in the PCI Express controller memory-mapped register space. Both types of access must be prevented. This does not completely eliminate the problem, because there could be accesses to the PCI Express interface between the time the link goes down and the time the interrupt handler disables access to the interface. In this instance device HRESET is required. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 94 Freescale Semiconductor, Inc. General Business Information PCI-Ex 41: PCI Express x8 mode requires minimum platform frequency of 527 MHz Description: Due to bandwidth requirements of the PCI Express port, a minimum platform frequency of 527 MHz is required for PCI Express to successfully operate in x8 mode. Current documentation includes the following equation for minimum platform frequency: * For proper PCI Express operation, the CCB clock frequency must be greater than: 500 MHz x (PCI-Express link width)/8. When running in x8 PEX mode this equation resulted in requiring a minimum platform frequency greater than 500 MHz. This equation, no longer holds true. This equation should actually read as follows: * For proper PCI Express operation, the CCB clock frequency must be greater than or equal to: 527 MHz x (PCI-Express link width)/8. When running in x8 PEX mode this equation results in requiring a minimum platform frequency greater than or equal to 527 MHz. If PCI Express operates in x8 mode at platform frequencies below 527 MHz, many correctable errors can occur. It is possible for these correctable errors to cause the link to go down and require to be re-trained. The possibility of this occuring increases with lower platform frequencies and higher PCI Express traffic. Note that data corruption is not a symptom of this erratum. Impact: PCI Express will not operate reliably in x8 mode when the platform frequency is between 500-527 MHz. Workaround: Operate the platform frequency at the required frequency calculated in the above updated equation. This equation is updated in the Hardware Specifications. Fix plan: No plans to fix The hardware specification documents reflect these platform frequency requirements. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 95 General Business Information PCI-Ex 42: Reads to PCI Express CCSRs or local config space temporarily return all Fs Description: When its link goes down the PCI Express controller clears all outstanding transactions and, if PEX_PME_MES_DISR[LDDD]=0 and PEX_PME_MES_IER[LDDIE]=1, sends a link down exception to the interrupt controller. Read transactions are cleared with an error indicator (transaction error to source for memory reads, return data all Fs for config reads). Write transactions are silently dropped. The canceling of config read or write transactions should not apply to accesses to configuration, control and status registers in memory-mapped space or local PCI Express config space. Writes to memory-mapped or local PCI Express config registers are handled normally. However, due to this erratum, reads return all Fs for the duration of the link down cleanup. If the controller is configured as an endpoint and receives a hot reset request, it also brings the link down and follows the same cleanup procedures as in an externally detected link down. Note that reads to PCI Express memory-mapped registers or config registers will return all Fs for the duration of the hot reset event, as well. Impact: Reads to configuration, control and status registers in the memory-mapped or config space of PCI Express return all Fs during link down cleanup or hot reset event. During this time, writes are handled normally, though the results of the write are not verifiable. The duration of the link down cleanup varies depending on the number and type of pending transactions. Cleanup for pending outbound transactions takes just a few cycles, regardless of the source. Pending inbound transactions wait for all responses from targets (data response for reads, or successful arbitration to the target queue for writes) before completing cleanup. Once all pending transactions have been cleared, new CCSR accesses and local config return to normal operation. Note that because of PCI-Ex 39 , any new accesses to PCI Express, including config reads to off-chip registers, will wait until the link resumes normal operation to complete. The config access state machine is serialized, so a config read to an off-chip register will prevent access to local CCSRs or local config operations while the link remains down. Workaround: If the configuration, control or status register cannot return all Fs as a legal value, but does, keep polling the register value until it is not all Fs. Note that PEX_PME_MES_DR, the detect register containing the link down detect bit, cannot return all Fs in normal operation. If the configuration, control or status register can return all Fs as a legal value, and does, read another register which is known not to contain all Fs (e.g. PEX_IP_BLK_REV1) to confirm that the link is not in hot reset or link down cleanup, then reread the original register. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 96 Freescale Semiconductor, Inc. General Business Information PCIe-A001: PCI Express Hot Reset event may cause data corruption Description: When the PCI Express controller is configured in EP Mode, if the controller detects an in-band Hot Reset event from its upstream device (either RC or Switch) before it finishes processing an inbound memory write TLP, the following may occur. * TLP received right before the Hot Reset event may be discarded * Data corruption may occur on the first inbound memory transaction received after the Hot Reset event. Depending on the type of the first inbound memory transaction received after Hot Reset, data corruption may occur as below: * If it is a memory write, the transaction may finish with data corruption at the target. * If it is a memory read, the transaction may be decoded incorrectly and the return data might be incorrect. Impact: This only affects devices with PCI Express controller configured in EP Mode. An inbound memory write TLP received by the PCI Express controller in EP Mode may be discarded, if a Hot Reset event is detected while the controller is still in the middle of moving the payload data of this memory write TLP from its receiver buffer toward the packet destination. As a consequence, data corruption may also occur on the first inbound memory transaction received right after this "inbound memory write followed immediately by a Hot Reset event" sequence. Note that after the data corruption occurs, the system will return to normal operating condition. If the first inbound transaction received is a configuration cycle, after the above mentioned "inbound memory write followed immediately by Hot Reset event" sequence, the configuration cycle will finish normally, with no error. Since a Hot Reset event resets all the configuration space registers in any PCI Express EP controller, per PCI Express base specification requirements, the upstream RC must re-configure all these registers after the Hot Reset event. Therefore, with the normal PCI Express programming model, there are always configuration cycles before the upstream device can send memory transactions to downstream EP controllers, which means the data corruption scenario after the Hot Reset event might not happen for most applications. However, the Memory Write TLP received immediately before the Hot Reset event might still be discarded. End product designers must check against their application programming model and determine the actual impact and appropriate workaround adoption. The above described error will not occur in any of the following conditions: * If the last inbound memory transaction received immediately before the Hot Reset event is a memory read, or, * If the system (PCI Express controller) is idle in its inbound path when the Hot Reset event occurs. Workaround: When possible, before issuing the Hot Reset, the upstream RC or Switch should quiesce the system first to ensure no inbound traffic is flowing into the Freescale PCI Express EP controller. This prevents the above mentioned "inbound memory write followed immediately by Hot Reset event" sequence from occurring. The exact requirement and action required to quiesce the system is dependent on system, application and software used. For example, some requirements may include, but not be limited to, using a software semaphore at the RC system side to stop the new memory requests targeting the downstream Freescale PCI Express EP controller from the RC system's software API layer or DMA controller. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 97 General Business Information Once such "quiescing system" actions have been finished, the RC system can send a configuration write cycle to clear the Memory Space bit in the Freescale PCI Express EP controller's Command Register, followed by a several micro-second delay to allow all previously received inbound memory writes to propagate through the EP controller. A Hot Reset command can then be applied. If an "inbound memory write followed immediately by Hot Reset event" sequence cannot be avoided, do the following. Right after the Hot Reset event, the upstream RC can issue a dummy memory write followed by another write or read to the read-only PEX_IP_BLK_REV1 memory-mapped register in the downstream Freescale device with PCI Express controller configured in EP Mode. The RC can then re-transfer the last memory write TLP that occurred right before the Hot Reset event and resume other normal traffic. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 98 Freescale Semiconductor, Inc. General Business Information SEC 5: AES-CTR mode data size error Description: The SEC 2.1 supports acceleration of AES Counter mode, an underlying algorithm in Secure Realtime Transport Protocol (SRTP), and optionally, IPSec. The SEC is designed to accelerate AES-CTR alone (using descriptor type 0001_0) or in parallel with an HMAC-SHA-1 using a special SRTP descriptor type 0010_1. SRTP uses AES-CTR with HMAC-SHA-1. Although AES in counter mode (AES-CTR) is meant to act as a stream cipher, the AESU considers any input data size that is not an even multiple of 16 bytes to be an error. Impact: None Workaround: Use one of the following options: * The AESU Data Size error can be disabled via the AESU Interrupt Control Register to prevent a nuisance interrupt. * The input data length (in the descriptor) can be rounded up to the nearest 16B. Set the data-in length (in the descriptor) to include X bytes of data beyond the payload. Set the data-out length to only output the relevant payload (don't need to output the padding). SEC reads from memory are not destructive, so the extra bytes included in the AES-CTR operation can be whatever bytes are contiguously trailing the payload. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 99 General Business Information SEC 6: Single descriptor SRTP error Description: The SRTP protocol specifies the use of AES-CTR with HMAC-SHA-1. The SEC 2.1 is designed to accelerate AES-CTR in parallel with HMAC-SHA-1 using a special SRTP descriptor type 0010_1. Single descriptor SRTP does not work for data sizes that are not even multiples of 16 bytes. Impact: When operating on input data which is N*16B, the AESU and MDEU can each read in the portion of the datastream relevant to their respective operations. When the input data is not N*16B, the AESU data size workaround described in SEC5 (rounding up to the next 16B) does not work because these excess bytes are `snooped' by the MDEU and corrupt the HMACSHA-1 operation. Workaround: Because the SRTP protocol does not require the payload to be N*16B, most packets will likely be of a data length that hits this erratum. The workaround is to use two descriptors to perform SRTP. Outbound: The first descriptor is type 0001_0 "common non-snoop" set for an AES-CTR operation using either of the workarounds described in SEC5. The second descriptor is type 0001_0 "common non-snoop" set for an HMAC-SHA-1 of the headers + unpadded encrypted payload + MKI (when present). Inbound: Same descriptors as outbound, but in reverse order. To minimize the performance impact of this workaround, these two descriptors should be created simultaneously and launched back-to-back. By configuring the SEC Crypto-channel to perform Done notification on selected descriptors, the first descriptor should be set to not generate a Done interrupt, while the second descriptor (which completes the SRTP operation) should be set to generate the Done interrupt. All the parameters required to build both descriptors are available at the start of the request to the SEC device driver, so there is no reason to wait for the first descriptor to complete before building and launching the second. By running these descriptors back to back with no interrupt in between, the data operated upon by the second descriptor will likely be fetched from L2, thereby reducing the memory bus utilization associated with the second descriptor. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 100 Freescale Semiconductor, Inc. General Business Information SEC 7: AES-CCM ICV checking write-back error Description: Most security protocols add an authentication tag to the frame or packet which provides the receiver with proof that the frame/packet has not been modified in transit. These authentication tags are also known as an HMACs or ICVs. The SEC is capable of generating these authentication tags for out-bound operations, and re-calculating the tag and comparing it to the received tag for in-bound operations. When performing in-bound authentication tag comparison, the SEC can notify software of a miscompare (which indicates an intentional modification of a frame/packet) by generating a crypto-channel error interrupt, or by writing a tag miscompare bit to the original descriptor header in memory. For authentication tags (ICVs) created by the AESU when in CCM mode, hardware can successfully perform the ICV comparison, but signaling of an ICV miscompare can only be performed via a channel error interrupt. When attempting to use the writeback method when an ICV miscompare is detected, all subsequent descriptors will be flagged as having ICV miscompares, whether they do or not. Impact: A full SEC reset is required to clear the ICV miscompare writeback logic. Workaround: For AES-CCM mode only, do not use the header writeback method for signaling authentication tag miscompare. Use the channel interrupt method. Alternately, perform ICV checking in software, as is required in all SEC cores 2.0 and below. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 101 General Business Information SEC 8: Kasumi hardware ICV checking does not work Description: SEC's execution units (EU) that generate integrity check values (ICVs) are also capable of comparing a received ICV with a calculated ICV. In the case of the KEU (Kasumi) F9 function, the SEC is not able to properly compare a received F9 MAC (another acronym for an ICV) with the calculated MAC. Impact: The Kasumi algorithm produces a 128-bit integrity check value, which is shortened in the 3G protocol to a 64-bits message authentication code (MAC). To verify a received MAC, the user copies the received MAC to the KEU's IV data, which the SEC fetches (along with other parameters) in order to generate the calculated MAC. The KEU is supposed to compare the upper 64 bits of the calculated MAC with the 64 bits received MAC; however, it attempts to compare the full 128 bits and consequently always reports an ICV comparison failure, for example, integrity check comparison result (ICCR) returns binary "10." Workaround: Users are not required to use the hardware ICV comparison feature. Rather than copying the 64 bits received MAC to the KEU's IV data, the user can merely have the SEC output the 128bit MAC generated by the KEU, and software can perform the comparison of the upper 64 bits. Performing the MAC comparison in software takes only a few more CPU cycles than copying the received MAC to the IV data and reading the SEC's comparison result from the descriptor header. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 102 Freescale Semiconductor, Inc. General Business Information SEC-A001: Channel Hang with Zero Length Data Description: Many algorithms have a minimum data size or block size on which they must operate. The SEC EUs detect when the input data size is not a legal value and signal this as an error. For most EUs, a zero byte length data input should be considered illegal, however the EUs do not properly notify the crypto-channel using the CHA of a data size error. Instead, the EUs wait forever for a valid data length, leading to an apparent channel hang condition. Impact: When EUs detect illegal input data size, EUs wait forever for a valid data length, leading to an apparent channel hang condition. Workaround: Ensure that software does not create SEC descriptors to encrypt or decrypt zero length data. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 103 General Business Information SRIO 39: Serial RapidIO atomic operation erratum Description: Applications using lwarx/stwcx instructions in the core to compete for a software lock or semaphore with a device on RapidIO using read atomic set, clr, inc, or dec in a similar manner may falsely result in both masters seeing the lock as "available." This could result in data corruption as both masters try to modify the same piece of data protected by the lock. It is possible that a read atomic set, clr, inc, or dec from a RapidIO master may be bypassed by a read transaction on behalf of a lwarx instruction from the core. This can result in the core seeing the lock "not set", while allowing the read atomic operation to complete and report success back to the RapidIO master. It also never clears the reservation made by the core just prior to issuing the read transaction on behalf of its lwarx instruction. The reason for this lack of ordering between the two read transactions is that the transactions may queue in either of two separate read command queues of the memory scheduling block. Ordering is not enforced between each of the read queues. Note that ordering in both read queues is enforced with respect to the write queue. Impact: Both the core and Rapid IO master may attempt to modify a data structure at the same time that is protected by a software lock/semaphore. This can only occur if the core is using lwarx/ stwcx instructions and the RapidIO master is using read atomic set, clr, inc, or dec transactions to check and obtain ownership of the lock. Workaround: For any application where the core is issuing lwarx/stwcx instructions to the same cacheline address that a RapidIO master is sending read atomic set, clr, inc, or dec transactions, one of two software solutions below should be followed. The first solution retains maximum performance of the memory subsystem by temporarily disabling one of the read command queues during the lock sequence. The second solution doesn't require the core to precede its lwarx/stwcx routine with any special code sequence but requires permanently disabling one of the read command queues. First Solution--code sequence to be run: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Read CCSR offset 0x01010 (EEBPCR register of the ECM) into GPR A Bit-wise OR GPR A with 0x0004_0004 Write the result back to CCSR offset 0x01010 Read CCSR offset 0xE0F14 (DDRTQDCR0 register of Global Utilities) into GPR A Bit-wise AND GPR A with 0xF1FF_ E3FF Bit-wise OR GPR A with 0x0000_0001 Write the result back to CCSR offset 0xE0F14 Read CCSRBAR SYNC Run a loop for 5 microseconds Read CCSR offset 0xE0F14 into GPR A Bit-wise OR GPR A with 0x0600_0000 Bit-wise AND GPR A with 0xFFFF_FFFE Write the result back to CCSR offset 0xE0F14 Enter the lwarx/stwcx routine... If the core ever attempts to take ownership of this lock again, the same sequence must be repeated. Second Solution: MPC8548E Chip Errata, Rev. 6, 6/2012 104 Freescale Semiconductor, Inc. General Business Information A second software solution is to simply set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register of the ECM) during initialization and leave them set indefinitely. This may slightly degrade overall system performance. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 105 General Business Information SRIO 41: Serial RapidIO Packets with errors are not ignored by the controller while in input-retry-stopped state Description: The RapidIO 1.2 specification states, in part 6, section 5.6.2.1 "Input Retry-Stopped Recovery Process" that the input side of a port which retries a packet must immediately enter the inputretry-stopped state and while in this state it must discard the rejected packet without reporting a packet error and ignore all subsequently received packets. All packet errors received after the RapidIO controller enters input-retry-stopped state but before it sees a restart-from-retry control symbol should be ignored, but are not. Since the packets with errors are not ignored, the controller enters an input-error-stopped state. Note that some RapidIO switches have been observed to transmit a packet with an out-oforder AckID after receiving a packet-retry. Before the switch sends restart from-retry, a transmission of this out-of-order AckID causes frequent "packet with unexpected AckID" errors in devices which have entered an input-retry-stopped state due to a loaded system. A loaded system is defined as one that has its RapidIO input buffers filled with outstanding transactions. An example to this is a system in which 5 initiators across a switch make constant back-to-back NREAD requests into the receiving device without waiting for ACKs from the RapidIO controller. This will eventually fill the input buffers and cause the receiving device to enter input-retry-stopped state. Impact: Packets with errors which should be ignored in input-retry-stopped state are not ignored and reported as errors. This causes the controller to enter an input-error-stopped state that needs hardware error recovery procedures, triggers error counting, and generates error interrupts. Workaround: For systems using affected switches the preferred workaround is to disable error rate counting for packets with unexpected AckIDs. This leaves the hardware error recovery sequence in place for all errors, as well as error counting for the most common events associated with link degradation (CRC or invalid characters). The system will still enter the input-error-stopped state and the input-error-stopped recovery process will still need to be done, but no error counting will occur, and no error interrupt will be generated by the controller. To disable error rate counting for unexpected AckIDs clear PnERECSR[UA] (Port n Error Rate Enable Command and Status Register - Unexpected AckID). Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 106 Freescale Semiconductor, Inc. General Business Information SRIO 42: Message unit cannot generate messages with priority 0 Description: The priority of outbound messages is controlled by the DTFLOWLVL field of the outbound message destination attributes register (OMnDATR). If the DTFLOWLVL field is set to 0, however, the RMU generates a message of priority 1 instead of priority 0. The priority of outbound message transactions is set as follows: OMnDATR[DTFLOWLVL] 00 SRIO transaction priority of 1 01 SRIO transaction priority of 1 10 SRIO transaction priority of 2 11 Reserved Note that OMnDATR is set by a register write in direct mode, or by programming the Destination Attributes bits in the buffer descriptor in chaining mode. Impact: Outbound messages have a higher priority than expected if the programmed flow level is 00. Workaround: If the system requires all request packets to be of the same priority, use a flow level of 01 in all outbound ATMUs and destination attributes registers. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 107 General Business Information SRIO-A002: SRIO reset command does not result in device reset Description: The RapidIO (SRIO) Interconnect Specification specifies the following (e.g. in Part 6 section 3.5.5.1): " The reset-device command causes the receiving device to go through its reset or power-up sequence. All state machines and the configuration registers reset to the original power on states. " The affected Freescale devices implement this specification by asserting the HRESET_REQ output when a reset command is received over SRIO. Unfortunately, the HRESET_REQ output is not asserted long enough for the external reset circuit to assert the HRESET input. The net effect is that the SRIO reset command does not result in a device reset. The failure is only applicable when the product is configured as an agent. Impact: A SRIO master attempts to reset an SRIO agent by sending four consecutive maintenance reset control packets to the SRIO endpoint. The HRESET_REQ signal should be asserted long enough for an external device to detect the request and respond with HRESET. On the affected Freescale devices the HRESET_REQ signal is asserted only for one SRIO clock period and can be missed by the external reset logic. Workaround: The external SRIO device can write to the Global Utilities register RSTRSCR[SW_RR], which causes the HRESET_REQ output to assert, resulting in a device hard reset. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 108 Freescale Semiconductor, Inc. General Business Information SRIO-A004: SRIO controller may incorrectly transmit or block responses when PmCCSR[OPE] = 0 Description: The output port enable [OPE] field of the SRIO port m control command and status register (PmCCSR) is defined as follows: Output port transmit enable: * 0 - port is stopped and not enabled to issue any packets except to route or respond to I/O logical MAINTENANCE packets. Control symbols are not affected and are sent normally. This is the recommended state after device reset. * 1 - port is enabled to issue any packets When PmCCSR[OPE] = 0, the SRIO controller does not follow the expected behavior. Instead, the controller behaves as follows: - Outbound request packets will not be transmitted (maintenance request packets should be sent). - As long as no outbound request packets are pending (sent to SRIO, but not to the link), then all response packets (format type 8 and 13) will be transmitted (only responses for maintenance packets should be sent). - Any pending outbound request packets may prevent response packets from being transmitted, too (responses for maintenance packets should be sent). Examples of non-compliant scenarios: 1. An inbound IO read request packet (format type 2), packet 'B', arrives from a remote device. If there are no pending outbound request packets, the outbound response packet (format type 13), generated from packet 'B', will be transmitted. SRIO should only response to inbound maintenance request packets (format type 8). 2. An outbound maintenance request packet (format type 8) will not be transmitted. SRIO should transmit maintenance request packets (format type 8). 3. An outbound read request packet (format type 2), packet 'C', is pending in SRIO. Afterwards, an inbound maintenance request packet (format type 8), packet 'D', arrives from a remote device. There is one pending outbound request packet (packet 'C'), which blocks later responses, so the outbound maintenance response packet (format type 8), generated from packet 'D', will not be transmitted until software sets OPE=1. SRIO should be able to respond to inbound maintenance request packets (format type 8) while OPE=0. Impact: When PmCCSR[OPE] = 0 - Inbound non-maintenance request packets may be responded to. - If the device configuration allows outbound requests to be pending in the controller, inbound maintenance request packets may not be responded to. - Outbound maintenance request packets will not be transmitted. Workaround: Set PmCCSR[OPE]=1 to allow transmission of any request or response packets. To allow responding to inbound maintenance requests when PmCCSR[OPE] = 0, prevent outbound request packets from being sent to the SRIO controller by, for example, disabling any LAWs with SRIO target. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 109 General Business Information DDR 13: Memory contents may not be retained during HRESET sequence Description: It may be desirable for customers to have the DDR controller enter self refresh mode and HRESET the part shortly after, while retaining contents of memory. However, it is possible that CKE will not be driven active low during HRESET, bringing the DRAM out of self refresh. There are pin-sampled signals that may erroneously place the DDR into a test mode if they are not set to a valid state when HRESET is asserted. The DDR controller should drive the MCKE[0:3] pins active low throughout and after HRESET. However, when this test mode is entered, the DDR drivers will be inactive, and the MCKE[0:3] pins will be released to high impedance. This test mode will be entered if a value of 0xf is presented on LA[28:31] during HRESET, or if a value of 0x0 is presented on MSRCID[2] during HRESET. The MCKE[0:3] pins will remain released to high impedance until LA[28:31] and MSRCID[2] are set correctly for pin sampling. Impact: The DRAMs may erroneously exit self refresh mode if MCKE is released to high impedance and transitions above the minimum AC switching voltage level. Workaround: Depending upon the board application, it may be possible to use active components during HRESET to ensure that MCKE[0:3] will remain low throughout HRESET. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 110 Freescale Semiconductor, Inc. General Business Information DDR 14: The automatic CAS-to-Preamble feature of the DDR controller can calibrate to incorrect values Description: When the DDR controller executes the automatic CAS-to-preamble logic, it will be possible that the controller will calibrate to an erroneous value. In addition, there will not be an error reported in the ERR_DETECT register, and there is no valid way to tell if the calibrated value is valid. Impact: The automatic CAS-to-preamble function of the DDR controller can fail, which could lead to data corruption on the DDR interface if this feature is enabled. Workaround: The automatic CAS-to-preamble feature should not be enabled. Instead the CAS-to-preamble should be calculated (using examples shown in application note AN2583 from Freescale). Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 111 General Business Information DDR 15: Automatic calibration hardware may calibrate to an invalid driver impedance Description: The DDR controller will typically calibrate to half-strength drive mode (highest impedance setting) when calibrating the DDR IO drive strength. This same issue has been observed when calibrating the drive strength via software. Since this calibration uses an 18 resistor on the board, it is not expected to resolve to the highest impedance setting. Impact: This calibration was only intended for use with full-strength drivers. There was not a calibration option for half-strength drive mode. Therefore, applications using half-strength drive mode are not affected. Workaround: The automatic driver calibration should not be used: DDRCDR[DHC_EN] should be cleared. * For Full-strength Mode, the default driver impedance setting used by the controller will force the nominal 18 setting. * Half-strength mode can also be enabled via setting the DDR_SDRAM_CFG[HSE] bit in the DDR controller's memory mapped space, forcing a nominal 36 setting. Customers should not need to write the impedance overrides in DDRCDR register. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 112 Freescale Semiconductor, Inc. General Business Information DDR 16: On-die termination at the DDR IOs has been measured 75 too high Description: The DDR IOs provide termination options of 75 and 150 . Silicon measurements show about 150 and 225 , respectively. Impact: The termination at the DDR IOs will be inaccurate. By setting the 75 option, one can still get termination of about 150 . However, there is no way to get 75 . Workaround: When trying to obtain 150 termination, the 75 termination option can be set by clearing DDRCDR[ODT]. However, there is no workaround to obtain 75 termination. Note that this issue has been present on all previous revisions of the device. Customers who designed using simulation results should not have to alter impedance settings via software in fixed silicon, as the lines will simply be better balanced using fixed silicon. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 113 General Business Information DDR 17: DDR performance monitoring and tracing functionality does not work Description: Performance Monitor and Watchpoint/Trace functionality does not work correctly with respect to certain types of DDR-related information. Impact: The following functionality is not supported in 2.0 silicon only: DDR Performance Monitor events: Counter 1: Event 0 Counter 2: Event 0, 1 Counter 3: Event 0, 1, 2, 60 Counter 4: Event 0, 1, 3, 4 Counter 5: Event 0, 2, 56 Counter 6: Event 0, 1, 2, 5 Counter 7: Event 1, 4, 57 Counter 8: Event 0, 2 Reference Events 11, 12, 13, 14, 1 Watchpoint/Trace buffer: when "internal DDR SDRAM interface" is selected (WMCR1[IFSEL] or TBCR1[IFSEL] = b'001). Workaround: Do not use the aforementioned DDR performance monitor events. The same Watchpoint/ Trace buffer information can be obtained from the e500 Coherency Module Dispatch selection (WMCR1[IFSEL] or TBCR1[IFSEL] = 3b'000). Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 114 Freescale Semiconductor, Inc. General Business Information DDR 18: Automatic data initialization and DLL resets to DRAM are not performed correctly if CS2 and CS3 are interleaved Description: CS2 and CS3 can be interleaved together by setting DDR_SDRAM_CFG[BA_INTLV_CTL] to 7'bx1xx0x0. In this mode, the DDR controller may operate incorrectly for 2 different features. First, the DDR controller will not initialize DRAM data properly if DDR_SDRAM_CFG_2[D_INIT] is set. If D_INIT is set with CS2 and CS3 interleaved together, then the memory spaced defined by CS2 and CS3 will not be initialized. Second, the DDR controller may not issue DLL reset commands to CS2 and CS3 when exiting self refresh. Note that this feature is typically enabled when DDR_SDRAM_CFG_2[DLL_RST_DIS] is cleared. If CS0 and CS1 are both disabled via CSn_CONFIG[CS_n_EN] (and CS2 and CS3 are interleaved together), then only CS3 will receive the DLL reset command when self refresh is exited. Note that neither of these issues will be present if all chip selects are enabled and CS0-CS3 are interleaved together. Impact: There are 2 results that can be observed from this erratum. If the first scenario listed above is present, then the memory space defined by CS2 and CS3 will not be initialized properly when DDR_SDRAM_CFG_2[D_INIT] is set. If the second scenario listed above is present, then the DLL reset command will not be issued as expected to CS2. It is not expected that this will cause any issues with DDR2 memories. DDR2 JEDEC specifications state that the DRAM's DLL is automatically disabled when entering self refresh, and the DLL is automatically reenabled when exiting self refresh. Although it would be possible for some vendors to vary, the DLL reset should not be required by the DRAMs when exiting self refresh. The DLL reset feature was originally added to support DDR1 memories. It appears that DDR1 memories will typically only require the DLL reset when the frequency is changed, but this scenario should still be avoided if possible to prevent any potential issues. Workaround: There are several workarounds for this erratum. The preferred workaround will be to disable interleaving between CS2 and CS3. CS0 and CS1 can still be interleaved together. In addition, CS0 and CS3 could still be interleaved together without any issues. If it is still preferred to interleave CS2 and CS3 together, then one of two workarounds can be used for initializing memory. First, software could be used to initialize memory (i.e., via the DMA) instead of using DDR_SDRAM_CFG_2[D_INIT]. In addition, the memory controller could be enabled without CS2 and CS3 interleaved while DDR_SDRAM_CFG_2[D_INIT] is set. After D_INIT is cleared by the hardware, CS2 and CS3 could then be programmed to be interleaved together (via DDR_SDRAM_CFG[BA_INTLV_CTL]). The memory space defined by the CS2_BNDS register would then need to be updated to include the entire memory space for CS2 and CS3. During this entire sequence, software would need to guarantee that no other transactions are issued to memory. Other than disabling interleaving between CS2 and CS3, the only other way to workaround the DLL reset issue is to ensure that either CS0 or CS1 is also enabled (via CSn_CONFIG[CS_n_EN]). Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 115 General Business Information DDR 19: DDR IOs default receiver biasing may not work across voltage and temperature Description: The DDR IO receiver biasing is controlled through settings in an engineering use only register. The current default settings may not work at cold temperature. The worst case condition for this erratum is TJ = 0 degC, GVDD = GVDD(min), VDD = VDD(max). When a failure occurs, a DDR input latches an incorrect value. Impact: The DDR interface may fail if the default receiver biasing value is not overridden. Workaround: Write register at CCSRBAR offset 0xE_0F24 with a value of 0x9000_0000 for DDR2 and a value of 0xA800_0000 for DDR1 before enabling the DDR controller. This will set the receiver to an acceptable bias point. Fix plan: Fixed in Rev 2.1 Note: the workaround for the Rev 2.0 device must be removed when running the Rev 2.1 device. MPC8548E Chip Errata, Rev. 6, 6/2012 116 Freescale Semiconductor, Inc. General Business Information DDR 20: MCKE signal may not function correctly at assertion of HRESET Description: During the assertion of HRESET (excluding the initial power-on-reset) the device may erroneously drive the state of MCKE to the incorrect level or release it to high impedance after removing the clocks from the DRAM. This could place the DRAMs into an undefined state causing future operations to fail. The primary fail mechanism is for the device to incorrectly train its I/O receivers during DDR initialization. There are power on reset configuration signals sampled during HRESET that do not quickly achieve correct values using their internal pull-ups. As a result, the device may be temporarily placed into a test mode. The POR configuration pins used to enter test mode are LA[28:31] and MSRCID[2]. If the LA[28:31] are driving a value of 0b1111 at the time of HRESET assertion, then MCKE[0:3] may be released to high impedance. If MSRCID[2] is driving a zero at the time of HRESET assertion, then MCKE[0:1] may be released to high impedance or drive a 1. Impact: The DRAMs may erroneously enter an undefined state preventing the completion of read operations during DRAM initialization sequence. This may result in an auto calibration error (ERR_DETECT[ACE]) or improper training during the initialization sequence. A failure to train properly may result in corrupted data transfers to and from DDR. Workaround: There are several possible workarounds. Depending on the application, select one of the following options: Option 1 Note that the following DDR DEBUG registers are used in this option: * D2--offset is CCSRBAR + DDR_OFFSET + 0xF04 * D3--offset is CCSRBAR + DDR_OFFSET + 0xF08 At assertion of HRESET, perform an alternative DDR controller initialization sequence. This clears the DRAM state machines and allows them to operate properly. Before this sequence is implemented, do not enable any DDR LAWBAR entries. Details of alternative sequence are as follows: 1. Configure DDR registers as is done in normal DDR configuration. Do not set DDR_SDRAM_CFG[MEM_EN]. 2. Set reserved bit EEBACR[3] at offset 0x1000. 3. Before DDR_SDRAM_CFG[MEM_EN] is set, write DDR_SDRAM_CFG_2[D_INIT]. 4. Before DDR_SDRAM_CFG[MEM_EN] is set, write D3[21] to disable data training. 5. Wait 200 s (as described in the "DDR SDRAM Initialization Sequence" section in the device reference manual). 6. Set DDR_SDRAM_CFG[MEM_EN]. 7. Poll DDR_SDRAM_CFG_2[D_INIT] until it is cleared by hardware. 8. Clear D3[21] to re-enable training. 9. Set D2[21] to force the data training to run. 10. Poll on D2[21] until it is cleared by hardware. After this step, there are two options that can be followed if ECC is enabled before continuing on to step 10 . If DDR ECC is not utilized, continue to step 10 . Sub-Option 1 requires a calculated delay. Sub-Option 2 does not require the delay, but it is not supported for applications with DDR interleaving enabled. Sub-Option 1: a. Wait calculated delay MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 117 General Business Information Required delay for 64-bit DDR2 can be calculated as follows: Delay = 400 ms/Gbytes x max memory size. For 32-bit data buses, multiply this number by 2. Example: Assume a 64-bit DDR2 with total memory size = 1 Gbyte. Delay = 400 ms/Gbytes x 1 Gbyte = 400 ms b. Set DDR_SDRAM_CFG_2[D_INIT]. c. Poll on DDR_SDRAM_CFG_2[D_INIT] until it is cleared by hardware, then the system can proceed. d. Enable any DDR LAWBAR entries and proceed to step 10 . Sub-Option 2: a. Enable any DDR LAWBAR entries. b. Set ERR_DISABLE[MBED] and ERR_DISABLE[SBED] to disable SBE and MBE detection. c. Complete a 32-byte, non-snoopable DMA transaction with the source and destination address equal to the DDR initialization address, which is either the starting address of CS0_BNDS by default or programmed in DDR_INIT_ADDR. d. After the DMA transaction has completed, clear ERR_DISABLE[MBED] and ERR_DISABLE[SBED] to enable SBE and MBE detection as desired for specific applications. 11. Clear reserved bit EEBACR[3] at offset 0x1000. Option 2 Use an active component (for example, CPLD) to drive MCKE signals to the DRAMs. Inputs to this logic should include MCKE and HRESET_REQ, both from the device. When HRESET_REQ asserts, the MCKE signal to the DRAMs should be driven low by the active component. When HRESET_REQ is negated, the MCKE value driven by the CPLD should match the value driven by the device. The JEDEC defined tDelay parameter between the MCKE and MCK/MCK signals must also be controlled by this workaround. In addition, note that MCKE must still meet all JEDEC-defined ADDR/CMD setup/hold requirements when using the external component to help drive MCKE. Option 3 Power cycle the DRAM during HRESET assertions. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 118 Freescale Semiconductor, Inc. General Business Information GEN 10: Device may fail DDR pins during IEEE Std 1149.1TM EXTEST mode Description: During IEEE Std 1149.1TM EXTEST mode, the DDR I/O drivers may be disabled due to uninitialized logic. These controls are correctly configured during functional POR, which is not a requirement for EXTEST testing. Impact: Using the EXTEST mode the DDR drivers may be randomly disabled. This may effect customer's manufacturing board tests, causing false failures on the DDR interconnect tests, while the device DDR pins are driving. Workaround: Freescale has provided an updated BSDL definition file [Revision R2B]. This updated BSDL is modified to define HRESET as a compliance pin for all JTAG testing. This removes the HRESET pin from the interconnect testing, but will allow all the DDR signals to be correctly tested. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 119 General Business Information GEN 11: Some pins do not meet 500V CDM ESD criteria Description: CDM (Charged Device Model) ESD testing has shown that some SerDes pins do not meet the 500V CDM ESD criteria. The following pins are impacted: * SD_TX[7:0], SD_TX_B[7:0], SD_RX[7:0], SD_RX_B[7:0], SD_REF_CLK, SD_REF_CLK_B, SD_PLL_TPD, SVDD, XVDD, AVDD_SRDS, SD_IMP_CAL_TX, SD_IMP_CAL_RX, SD_PLL_TPA * GND pins U27, L21, L23, N22, P20, R23, T21, U22, V20, W23, Y21, K28, L24, L26, N24, N27, P25, R28, T24, T26, U24, V25, W28, Y24, Y26, A24, AB25, AC28 Impact: None Workaround: Ensure equipment used in handling of the device is properly grounded. Ensure parts are handled in an environment that is compliant with current ESD standards. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 120 Freescale Semiconductor, Inc. General Business Information GEN 13: CPU write to platform failures in all core, platform, and SYSCLK frequency combinations Description: AVDD filter resistors must be increased on new builds to avoid data corruption for CPU writes to the platform. Impact: A problem originally thought to only impact systems that are running with a core frequency less than 1200 MHz, or a platform frequency less than 333 MHz, or a SYSCLK frequency greater than 133 MHz has been observed on systems operating at higher core frequencies, higher platform frequencies and lower SYSCLK frequencies. The issue manifests itself as corrupted data on CPU writes to the platform. The issue is exacerbated by high temperature and high VDD voltage. Workaround: Systems are restricted to the following configurations: 1. Core is limited to minimum frequency of 800 MHz. 2. Platform (CCB) is limited to minimum frequency of 333 MHz 3. SYSCLK is limited to maximum frequency of 133 MHz Affected systems must change the value of the PLL power supply filtering resistors (Section 21.2.1 of the hardware specification). The filter resistors must be increased from 10 ohm to 180 ohm for the AVDD_CORE filter resistor, and 150 ohm for the AVDD_PLAT filter resistor. The tolerance of these resistors must be +/-5% or better. Additionally, systems with an operating core frequency less than 1200 MHz must limit SYSCLK frequency to 100 MHz maximum. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 121 General Business Information GEN 14: CPU-only reset may result in a failure in the platform logic Description: The device provides the ability to assert the core_reset signal to the processor. Once done, the possibility exists that the platform logic may fail. Impact: If core_reset is asserted by setting PIR[P0] or DBCR0[RST], the possibility exists that the platform logic may fail. Workaround: The core must be reset via a full hard reset of the device. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 122 Freescale Semiconductor, Inc. General Business Information SERDES 1: SerDes lane power down function may cause training to fail. Description: SerDes Controller register 1 (SRDSCR1) provides a mechanism to power down individual lanes of the SerDes port. The HW specification recommends that unused lane(s) should be powered down by setting the appropriate bit(s) in this register. It was discovered that powering down lanes [via this mechanism] may cause the link not to train. Impact: Link training may fail causing the SerDes port to be inoperative. Workaround: Do not set any SDRSCR1 control register bits. Fix plan: No plans to fix Documentation will be updated to remove this feature from the MPC8548 Reference Manual. The MPC8548 Hardware Specification will be updated to remove the recommendation. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 123 General Business Information LBIU 3: LBIU Transactions when clock divider LCRR[CLKDIV] is changing Description: Functionally the LBIU should not accept transactions when the LBIU is changing the clock divider LCRR[CLKDIV]. Any read request from the core or the platform to the LBIU block should stall during the CLKDIV changing period. This is supposed to be invisible to software. The stall is supposed to clear once LBIU resynchronizes its clock counters, and the read (instruction fetches) from LBIU should resume. However, due to the erratum, the internal logic does not start to block the LBIU requests immediately, potentially letting a transaction start that will fail due to the LBIU resynchronization process. Impact: Any local bus transaction may fail during LBIU resynchronization process when the clock divider [CLKDIV] is changing. Workaround: Ensure there is no transaction on the local bus for at least 100 microseconds after changing clock divider LCRR[CLKDIV]. User can run instructions from L2SRAM or DDR memory when changing LBIU clock divider LCRR[CLKDIV]. This erratum applies to both LBIU PLL bypass mode and PLL enable mode. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 124 Freescale Semiconductor, Inc. General Business Information LBIU 4: LGTA/LUPWAIT assertion in PLL-bypass mode misrepresented Description: In the Local Bus section of the Hardware Specification document, the timing diagram figures for PLL-bypass mode show that the LGTA/LUPWAIT signal is latched on the falling edge of the internal launch/capture clock signal. This is a misrepresentation of the device functionality as LGTA/LUPWAIT is actually latched on the subsequent rising edge of the internal launch/ capture clock signal. Impact: Asserting LGTA/LUPWAIT for only the falling edge of the internal launch/capture clock signal in PLL-bypass mode will result in the local bus controller not registering the LGTA/LUPWAIT input. Workaround: Option 1: Asserting the LGTA/LUPWAIT signal for an additional LCLK cycle in PLL-bypass mode will guarantee the local bus controller registering the LGTA/LUPWAIT input correctly. OR Option 2: Assert the LGTA/LUPWAIT signal for only the rising edge of the internal launch/ capture clock signal in PLL-bypass mode. Fix plan: No plans to fix The Hardware Specification will be updated to show that the LGTA/LUPWAIT signal is latched 1/2 LCLK cycle later on the rising edge of the internal launch/capture clock signal. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 125 General Business Information LBIU 5: UPM does not have indication of completion of a RUN PATTERN special operation Description: A UPM special operation is initiated by writing to MxMR[OP] and then triggering the special operation by performing a dummy access to the bank. The UPM is expected to have an indication of when a special operation is completed. The UPM will see MxMR[MAD] increment when a write to or read from UPM array special operation completes. However, the UPM does not have any status indication of completion of the Run Pattern special operation. The following scenario could be affected by this erratum: * A UPM Run Pattern special operation is initiated and a second UPM command is issued before the Run Pattern is completed. If the above scenario occurs the programmed mode registers could be altered according to the second operation and cause the current/first operation to encounter errors due to mode changes in the middle of the operation. Note that if a second command issued is a Run Pattern operation and it does not change the mode registers, the first operation should not encounter errors. The behavior of the LBIU is unpredictable if the Run Pattern special operation mode is altered between initiation of the operation and the relevant memory controller completing the operation. Impact: Because of this erratum, when a UPM Run Pattern special operation is to be followed by any other UPM command for which MxMR needs to be changed, the run pattern operation may not be handled properly. Software does not have any means to confirm when the current Run Pattern special operation has completed so that register programming for the next operation can be done safely. Workaround: None Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 126 Freescale Semiconductor, Inc. General Business Information PIC 4: PIC soft reset does not clear MSIRn registers correctly Description: The MSIRn registers are not cleared by writing to the GCR[RST]. Impact: It is possible to falsely detect an interrupt after writing to the GCR[RST] bit to clear the PIC. Workaround: To perform a reset command, software should set the GCR[RST] bit and immediately follow this with reads to each of the MSIRn registers. Reads to the MSIRn registers will automatically clear the register contents. Data from each of the MSIRn reads should be discarded. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 127 General Business Information PIC 5: MSIMR De-featured Description: MSIIR register can set bits in MSIR when disabled in MSMIR. Interrupt will not be forwarded to its destination when masked using the MSIMR register. When a message shared interrupt is asserted while masked using the MSIMR register the respective interrupt will not be forwarded when subsequently unmasked. Impact: Interrupt will not be forwarded to its destination. Workaround: In order to mask the message shared interrupt without loss use the MSK bit in the MSIVPRn. Note that the MSIMR register defaults out of reset to zeros which is enabled. Software should prevent writes to this register. Fix plan: Documentation update This register will be de-featured from reference manual. MPC8548E Chip Errata, Rev. 6, 6/2012 128 Freescale Semiconductor, Inc. General Business Information PIC 6: MER, Interrupt will not be forwarded to destination Description: Interrupt will not be forwarded to its destination when masked using the MER register. When a message interrupt is asserted while masked using the MER register the respective interrupt will not be forwarded when subsequently unmasked. Impact: Interrupt will not be forwarded to its destination in Ver.1.x and Ver.2.0. Workaround: No workaround. In order to mask the interrupt without loss, use the MSK bit in the MIVPRn. Note that the MER register defaults out of reset to zeros which is disabled. Therefore, during the initialization, set certain MER bit(s) to enable desired message interrupts. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 129 General Business Information PIC 7: PCI Express MSI other than interrupt 0 not supported via hardware Description: PCI Express MSI memory write is defined as a 32-bit write to the address location in the Message Address Register of the MSI Capability Register. The (little-endian) data format of the write is 31:16 - all zeroes, 15:0 from the Message Data Register of the MSI Capability Register, with lower bits modified as necessary to indicate the particular message. The MPIC implements MSI via the Message Shared Interrupt Index Register (MSIIR), which is big-endian with two fields: Shared Interrupt Register Select (SRS - bits 24:26) and Interrupt Bit Select (IBS - bits 27:31). The PCI Express Root Complex logic swaps the bytes of inbound writes to big-endian memory space, so the msi_data[31:24] is written to MSIIR[24:31], msi_data[23:16] to MSIIR[16:23], msi_data[15:8] to MSIIR[8:15], and msi_data[7:0] to MSIIR[0:7]. Since msi_data[31:16] are defined as all zeroes, MSIIR[SRS] and MSIIR[IBS] are always set to zero on an MSI write, and all standard MSIs trigger interrupt 0 (MSIR0[SH0]=1, MSISR[S0]=1). The contents of msi_data[15:0] are lost. Impact: The only MSI that can be triggered through the standard PCI Express hardware mechanism and configuration is interrupt 0. Workaround: Option 1: If no other devices or mechanisms write to the 1 MB memory-mapped register region defined by CCSRBAR through PCI Express, use an inbound ATMU window with the attributes set as follows: 1. Set PEXIWBAR0 to some memory region unused by PCI Express 2. Enable an inbound ATMU (example using window 1): a. PEXIWBAR1 = previous value of PEXIWBAR0 b. PEXIWTAR1[8:31] = CCSRBAR[8:23]||8'b0 c. PEXIWAR1[0:31] = 0xC0F4_4013 (Enable, No prefetch, Local Memory No snoop, 1 MB window) Please notice that workaround option 1 might not be compatible with future versions of the IP. Option 2: Use a software or other programmable mechanism to generate the 32-bit MSI memory write with MSI[31:24] set to the value of MSI[7:0]. Duplicating the MSI data in the LSB and MSB allows the workaround to be compatible with future versions of the IP which correct the definition and implementation of MSIIR. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 130 Freescale Semiconductor, Inc. General Business Information PM 1: Some local bus events are not counted correctly in the performance monitor Description: The followings events are not counted correctly: * Bank 1-8 hits (chip-select) * Request granted to ECM port * Cycles atomic reservation for ECM port is enabled Impact: These local bus events can not be used in the performance monitor. Workaround: None Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 131 General Business Information PM 2: A performance monitor time base transition event will not freeze the performance monitor counters and may not cause an exception Description: The performance monitor counters will not freeze when a time base transition occurs even though PMGC0[TBEE] and PMGC0[FCECE] are enabled. Also, a performance monitor exception may not happen when a time base transition occurs even though PMGC0[TBEE] and PMGC0[PMIE] are enabled. Impact: Performance monitor information about processor activity cannot be gathered during a precise interval based on the time base timer. Workaround: The counters freeze when the msb = 1 in PMCx, PMLCax[CE] = 1, and PMGC0[FCECE] is enabled. Exceptions occur when the msb = 1 in PMCx, PMCLCax[CE] = 1, and PMGC0[PMIE] is enabled. Therefore, one of the performance monitor counters can be set to count a specific number of processor cycles that corresponds to the time interval desired. After calculating the specific number of processor cycles required, program PMCx to 0x8000_0000 minus this number. This causes PMCx to overflow after the desired amount of cycles. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 132 Freescale Semiconductor, Inc. General Business Information I2C 2: Enabling I2C could cause I2C bus freeze when other I2C devices communicate Description: When the I2C controller is enabled by software, if the signal SCL is high, the signal SDA is low, and the I2C address matches the data pattern on the SDA bus right after enabling, an ACK is issued on the bus. The ACK is issued because the I2C controller detects a START condition due to the nature of the SCL and SDA signals at the point of enablement. When this occurs, it may cause the I2C bus to freeze. However, it happens very rarely due to the need for two conditions to occur at the same time. Impact: Enabling the I2C controller may cause the I2C bus to freeze while other I2C devices communicate on the bus. Workaround: Use one of the following workarounds: * Enable the I2C controller before starting any I2C communications on the bus. This is the preferred solution. * If the I2C controller is configured as a slave, implement the following steps: a. Software enables the device by setting I2CnCR[MEN] = 1 and starts a timer. b. Delay for 4 I2C bus clocks. c. Check Bus Busy bit (I2CnSR[MBB]) if MBB == 0 jump to Step f; (Good condition. Go to Normal operation) else Disable Device (I2CnCR[MEN] = 0) d. Reconfigure all I2C registers if necessary. e. Go back to Step a. f. Normal operation. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 133 General Business Information I2C 3: I2C boot sequencer cannot issue snoopable writes Description: The I2C boot sequencer cannot issue snoopable writes. Boot sequencer transactions are therefore not presented on the CCB. Impact: There is no possible way to use the I2C boot sequencer to initialize regions of the L2 configured as SRAM. Note that only being able to issue Non-snoopable transactions causes no cache coherency issues since the core is not permitted to perform its initial boot vector fetch until after the boot sequencer completes its initialization process. Workaround: None Fix plan: Fixed on Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 134 Freescale Semiconductor, Inc. General Business Information DMA 1: DMA_DACK bus timing violation when operating in external DMA master mode Description: The specification requires the external DMA master signal DMA_DACK to be held for at least three system clocks. The DMA violates this requirement. The DMA_DACK signal is directly associated with the channel MR[CS] bit while in external mode. The MR[CS] is "simulated" while in external mode by hardware setting the bit when DMA_DREQ is asserted, and clearing the bit when the channel wins arbitration. In normal DMA mode, a transfer in progress is determined by seeing bit MR[CS] and bit MR[CB] asserted together. In external mode this is not the case, the MR[CS] bit is asserted to short of a time and does not truly reflect transfer in progress. This problem causes the DMA_DACK to assert for a very short time. In addition to the problem above, there is no logic to force the assertion of DMA_DACK to be at least three system clock cycles. Impact: DMA_DACK held for six CCB_clocks. Workaround: None. Fix plan: Partially fixed in Rev 3.1.x If the CCB Clock PLL Ratio is not configured to either the 9:1 or 20:1 setting, this erratum is fixed. MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 135 General Business Information DMA 2: Transfer error reported for wrong channel Description: The DMA controller has resources that are shared between all channels. Each channel is given a time period in the shared resources corresponding to the value of the bandwidth control specified in MR[BWC]. The last write transaction corresponding to the transfer of a block (specified by the byte count register in the channel) is a write that requires a response from the target port (WRFTP). This type of write is referred to here as an WRFTP. While a channel that sent its last write data is waiting for the write response, another channel is allowed to start using the shared resources. When the WRFTP gets an error response, it is the channel that is active in the shared resources that will get the transfer error bit set, not the channel that is waiting for the response of the WRFTP transaction. Sources of error responses for an WRFTP are: * The write gets a translation error from an outbound ATMU translation window at the target port (Serial RapidIO, PCI Express). * The WRFTP translates to a non-posted write on PCI Express, and the non-posted write receives an error response from the attached device (WRFTP translation is controlled by ATMU configuration). * The WRFTP translates to an NWRITE_R on Serial RapidIO and the write receives an error response from the attached device (WRFTP translation is controlled by ATMU configuration). Note that an error response on a DMA read will set the transfer error bit in the correct channel. This problem is limited to getting an error on WRFTP response. Impact: The wrong channel could have Transfer Error set. The actual failing channel will complete normally, when data may not actually have been written to the destination successfully. When the Transfer error bit is set for one channel, software will have to assume that it could be have been caused by any other channel. Workaround: A few work arounds have been identified with varying performance and software impact: * Do not configure the ATMUs as described above, or * When a channel completes a block transfer or descriptor chain, check that no other channel has its transfer error set, or * Use one channel at a time. Not very practical since it reduces the DMA to a one channel DMA. Fix plan: Fixed in Rev 3.1.x MPC8548E Chip Errata, Rev. 6, 6/2012 136 Freescale Semiconductor, Inc. General Business Information A-004737: BREAK detection triggered multiple times for a single break assertion Affects: DUART Description: Previously DUART 1 A UART break signal is defined as a logic zero being present on the UART data pin for a time longer than (START bit + Data bits + Parity bit + Stop bits). The break signal persists until the data signal rises to a logic one. A received break is detected by reading the ULSR and checking for BI = 1. This read to ULSR clears the BI bit. After the break is detected, the normal handling of the break condition is to read the URBR to clear the ULSR[DR] bit. The expected behavior is that the ULSR[BI] and ULSR[DR] bits do not get set again for the duration of the break signal assertion. However, the ULSR[BI] and ULSR[DR] bits continue to get set each character period after they are cleared. This continues for the entire duration of the break signal. At the end of the break signal, a random character may be falsely detected and received in the URBR, with the ULSR[DR] being set. Impact: The ULSR[BI] and ULSR[DR] bits get set multiple times, approximately once every character period, for a single break signal. A random character may be mistakenly received at the end of the break. Workaround: The break is first detected when ULSR is read and ULSR[BI]=1. To prevent the problem from occurring, perform the following sequence when a break is detected: 1. Read URBR, which returns a value of zero, and clears the ULSR[DR] bit 2. Delay at least 1 character period 3. Read URBR again, which return a value of zero, and clears the ULSR[DR] bit ULSR[BI] remains asserted for the duration of the break. The UART block does not trigger any additional interrupts for the duration of the break. This workaround requires that the break signal be at least 2 character-lengths in duration. This work around applies to both polling and interrupt-driven implementations. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 137 General Business Information PCI 4: PCI-X inbound reads resulting in a split completion response can cause a corrupted response Description: PCI-X inbound reads that result in a split completion response from the PCI-X logic during or after PCI-X outbound traffic has occurred can cause a corrupted response from the PCI-X device. If the requester of the inbound read transaction retries the split completion response, the PCI-X logic may corrupt the outbound command queue. Instead of sending the last split completion response, the PCI-X logic may send out a Dual Address Cycle (DAC) with an upper 32-bit address of 0xFFFF_FFFF. The lower 32-bit address will contain the attribute phase information of the original read request. If the requester does not retry the split completion response, this erratum will not apply. Clock speed will not affect this issue. Also, outbound traffic must be present sometime during this situation in order to see this errata. Please keep in mind that outbound traffic that has already completed may still affect our internal logic and corrupt the last split completion response. Impact: Per the PCI-X specification, only a PCI-X bridge is allowed to retry a split completion response. This issue will only affect these systems. Workaround: To work around this issue, the requestor of the original read transaction must accept all split completion responses. Another possible workaround is to request smaller blocks of data so the logic will not respond with a split completion response. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 138 Freescale Semiconductor, Inc. General Business Information PCI 5: Assertion of STOP by a target device on the last beat of a PCI memory write transaction can cause a hang Description: As a master, the PCI IP block can combine a memory write to the last PCI double word (4 bytes) of a cacheline with a 4 byte memory write to the first PCI double word of the subsequent cacheline. This only occurs if the second memory write arrives to the PCI IP block before the deassertion of FRAME for the first write transaction. If the writes are combined, the PCI IP block masters a single memory-write transaction on the PCI bus. If for this transaction, the PCI target asserts STOP during the last data beat of the transaction (FRAME is deasserted, but TRDY and IRDYare asserted), the transaction completes correctly. A subsequent write transaction other than an 8-byte write transaction causes a hang on the bus. Two different hang conditions can occur: * If the target disconnects with data on the first beat of this last write transaction, the PCI IP block deasserts IRDY on the same cycle as it deasserts FRAME (PCI protocol violation), and no more transactions will be mastered by the PCI IP block. * If the target does not disconnect with data on the first beat of this last write transaction, IRDY will be deasserted after the first beat is transferred and will not be asserted anymore after that, causing a hang. Impact: This affects 32-bit PCI target devices that blindly assert STOP on memory-write transactions, without detecting that the data beat being transferred is the last data beat of the transaction. It can cause a hang. If the PCI transaction is a one data beat transaction and the target asserts STOP during the transfer of that beat, there is no impact. PCI-X operation is not affected by this erratum. Workaround: A PCI target device could avoid asserting STOP# during the last beat of a PCI memory write transaction that is greater than one data beat and crosses a cacheline boundary. It could assert STOP# during the last data beat of the cacheline or not assert STOP# at all. A software workaround for this problem is to set the PCI Latency Timer Register (offset 0x0D) to zero. A value of zero is the reset value for this register, so if this register is kept unmodified after reset, it will prevent the PCI IP block from ever combining writes. A debug bit, bit 10 of the PCI Bus Function Register (address 0x44) has been identified as another workaround. This bit, MDS (Master disable streaming), when set, will disable the combining of crossing cacheline boundary requests into one burst transaction,. Therefore, it can prevent the errata scenario from occurring. When this bit 10 is set, customer can program the PCI Latency Timer to achieve full cacheline burst even with one request in the PCI pipe. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 139 General Business Information PCI 6: PCI/PCI-X erroneous error detection Description: PCI/X ERR_DR[OWMSV] and ERR_DR[ORMSV] (offsets 0x0_8E00, 0x0_9E00) bits can erroneously set and may trigger an interrupt if capturing and reporting of these events are enabled. Impact: ERR_DR[OWMSV] cannot be used to alert the user of an outbound write memory space violation. ERR_DR[ORMSV] cannot be used to alert the user of an outbound read memory space violation. This bug results in less coverage for programming errors, but does not affect the functionality of the controller when the checking is disabled. Workaround: Set ERR_CAP_DR[27] and ERR_CAP_DR[28] to disable OWMSV, ORMSV error capture. Also clear ERR_EN[27] and ERR_EN[28] to disable OWMSV, ORMSV error reporting. It is also permissible to immediately return from interrupt when ERR_DR[OWMSV] or ERR_DR[ORMSV] is set. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 140 Freescale Semiconductor, Inc. General Business Information PCI 7: Asynchronous mode PCI1 and PCI2 input hold violation Description: PCI1 and PCI2 fail input hold by 250 ps in asynchronous mode Impact: A board which has less than 250 ps of hold time when driving data to the MPC8548E and running PCI1 or PCI2 in asynchronous mode may fail. Workaround: Provide 250 ps or greater input hold to the MPC8548E when running PCI1 or PCI2 in asynchronous mode. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 141 General Business Information PCI 8: Device reports wrong PCI Vendor ID Description: The device provides the wrong PCI Vendor ID. The value returned is 0x1057, instead of the correct value of 0x1957. Impact: The device indicates Motorola as the PCI Vendor instead of Freescale. Workaround: None. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 142 Freescale Semiconductor, Inc. General Business Information PCI 9: Master-Abort issued incorrectly for outbound DAC with subtractive decode Description: If an outbound command is issued by a PCI host and no response to the transaction occurs through the subtractive decoding cycle, then per the PCI specification a Master-Abort command should be issued by the host on the cycle subsequent to the subtractive decoding cycle. The device does not conform to the PCI standard for DAC transactions, and instead issues the Master-Abort one cycle earlier. Impact: This device is not fully compliant with PCI rev2.2 specification regarding Master-Abort for DEVSEL not asserted, for DAC transactions. However, in most cases the subtractive decoding is used in error condition (when no device answers). Workaround: Do not use subtractive decoding for DAC transactions other than error conditions. Fix plan: No plans to fix MPC8548E Chip Errata, Rev. 6, 6/2012 Freescale Semiconductor, Inc. 143 General Business Information JTAG 2: TMS requires hold time beyond the fall of TCK Description: If the SAMPLE/PRELOAD or EXTEST instruction is the current instruction in the JTAG TAP, and the JTAG state machine is moving into the UPDATE-DR state, TMS must be held past the falling edge of TCK. Impact: This requirement violates the IEEE 1149.1 spec which only requires TMS to be valid at the rise of TCK. The boundary scan update register will not update, and interconnect testing will fail. This primarily affects 3rd party JTAG and hardware tool vendors because this only affects the SAMPLE/PRELOAD and EXTEST JTAG instructions, as these are the only ones required to update the boundary register. Workaround: Option 1: Hold the TMS signal 2ns past the falling edge of TCK. Option 2: If the SAMPLE/PRELOAD or EXTEST instruction is the current instruction in the JTAG TAP, and the JTAG state machine is in the UPDATE-DR state, move to the SELECTDR state instead of to RUN-TEST-IDLE. Moving from UPDATE-DR to RUN-TEST-IDLE requires TMS to change from a `1' to a `0'. In this case, care must be taken to ensure that TMS is held at `1' for 2 ns past the falling edge of TCK before changing to the `0' value. If the JTAG tool has the option to move to the SELECT-DR state instead of the RUN-TESTIDLE state from the UPDATEDR state, then the value on the TMS pin does not change, because TMS will be a `1' moving into the UPDATE-DR state and a `1' moving into the SELECT-DR state. Keeping TMS at a `1' value will satisfy the hold time requirement. Then, go through the IR route to go back to the RUN-TEST-IDLE state. Fix plan: Fixed in Rev 2.1 MPC8548E Chip Errata, Rev. 6, 6/2012 144 Freescale Semiconductor, Inc. General Business Information How to Reach Us: Information in this document is provided solely to enable system and software Home Page: freescale.com implementers to use Freescale products. There are no express or implied copyright Web Support: freescale.com/support information in this document. licenses granted hereunder to design or fabricate any integrated circuits based on the Freescale reserves the right to make changes without further notice to any products herein. Freescale makes no warranty, representation, or guarantee regarding the suitability of its products for any particular purpose, nor does Freescale assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. "Typical" parameters that may be provided in Freescale data sheets and/or specifications can and do vary in different applications, and actual performance may vary over time. All operating parameters, including "typicals," must be validated for each customer application by customer's technical experts. Freescale does not convey any license under its patent rights nor the rights of others. Freescale sells products pursuant to standard terms and conditions of sale, which can be found at the following address: http://www.reg.net/v2/webservices/Freescale/Docs/TermsandConditions.htm. Freescale, the Freescale logo, and PowerQUICC are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. The Power Architecture and Power.org word marks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org. (c) 2008-2012 Freescale Semiconductor, Inc. Document Number: MPC8548ECE Rev. 6 06/2012