MPC8560CE MPC8560 TSEC18 DDR11 CPM13-16 DDR12 CPU29 CPU30 CPU31 CPU32 DDR10 - Datasheet Archive

 

MPC8560CE Rev 0.2, 10/2004 Errata MPC8560 PowerQUICC IIITM Device Errata This document details all known silicon errata for the

 

Freescale Semiconductor MPC8560CE MPC8560CE Rev 0.2, 10/2004 Errata MPC8560 MPC8560 PowerQUICC IIITM Device Errata This document details all known silicon errata for the MPC8560 MPC8560 PowerQUICC III device. It also includes errata for the e500 core. Table 1 provides a revision history for this document. Table 1. Document Revision History Document Revision Rev. 2.17 Rev. 0 Significant Changes Added errata item POR3. Public Release. Rev. 0.1 Added TSEC18 TSEC18. Updated DDR11 DDR11, GEN3. Rev. 0.2 Added CPM13-16 CPM13-16, DDR12 DDR12, and GEN6­8. Table 2 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 MPC8560 MPC8560 Revision e500 Core Revision Device Marking Processor Version Register Value System Version Register Value 2.0.2 2.0 MPC8560PXxxxLB 0x8020_0020 0x8070_0020 Table 3 summarizes all known errata for the e500 core and lists the corresponding silicon revision level to which it applies. A `Y' entry indicates that the erratum applies to a particular revision level, while a `-' entry means it does not apply. © Freescale Semiconductor, Inc., 2004. All rights reserved. Table 4 summarizes all known errata for other blocks on the MPC8560 MPC8560 device and lists the corresponding silicon revision level to which it applies. A `Y' entry indicates the erratum applies to a particular revision level, while a `N' entry means it does not apply. NOTE All references to Rev 2.0.1 can be assumed to also apply to Rev 2.0.2 and all subsequent silicon revisions. Table 3. Summary of e500 Core Silicon Errata and Applicable Revision Number Name Disposition Silicon Rev. 2.0.2 CPU29 CPU29 L1 instruction cache gets multiple entries for same line after change in MSR[IS] bit Doc as errata; fix in future rev. Y CPU30 CPU30 I-cache parity errors can be reported incorrectly Doc as errata; fix in future rev. Y CPU31 CPU31 e500 does not behave as documented when HID1[RFXE] = 0 No plans to fix this. Y CPU32 CPU32 e500 may perform invalid bus access after fetch to no-execute page No plans to fix this. Y Table 4. Summary of MPC8560 MPC8560 Silicon Errata and Applicable Revision Number Name Disposition Silicon Rev. 2.0.2 L2 cache L2C4 Lock clear to L2 cache may fail during error scenario No plans to fix this. Y none - - - - - - none - - - DDR8 DDR memory controller violates precharge command period (tRP) in auto-precharge mode Doc as errata; fix in future rev. Y DDR9 DDR DLL may lose lock Doc as errata; fix in future rev. Y DDR10 DDR10 DDR controller violates CKE timing for self refresh in 2T timing Doc as errata; fix in future rev. Y DDR11 DDR11 MSYNC_IN receiver control signals connected in 3.3v mode Doc as errata; fix in future rev. Y ECM RapidIO none ATMU DDR MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 2 Freescale Semiconductor Table 4. Summary of MPC8560 MPC8560 Silicon Errata and Applicable Revision (continued) Number Name Disposition Silicon Rev. 2.0.2 DDR12 DDR12 DDR controller may violate the JEDEC parameter for write preamble setup time (tWPRES) No plans to fix Y MII, half duplex collision causes Tx frames to lose data No plans to fix. Y TSEC TSEC18 TSEC18 PCI PCI1 PCI/PCI-X does not fully support RapidIO Interoperability Doc. as errata; partial fix Spec or strict bridge ordering rules for Rev. 2.0.1 Y PCI2 Outbound translation window must not overlap PCI memory-mapped configuration space Document in RM; will not be fixed Y PCI4 Inbound PCI configuration write with parity error corrupts PCI registers Document; will not be fixed Y PCI16 PCI16 Boot instructions fetched from PCI corrupted when parity enable bit updated Doc. as errata; fix in future rev. Y PCI17 PCI17 PCI high order bits driven incorrectly in debug mode Doc. as errata; fix in future rev. Y PCIX1 PCI-X non-posted writes that receive split response are not serialized Will not be changed Y PCIX3 PCI-X arbiter does not support broken master mode Will not be changed Y PCIX26 PCIX26 PCI-X does not report master or target abort in the status register on a misaligned split completion error message. Will not be changed Y PCIX27 PCIX27 PCI-X address field of an outbound split completion error message for a misaligned read is 0x04 instead of 0x00 Will not be changed Y PCIX28 PCIX28 PCI-X split completion error message data field is not stored in the data capture register Will not be changed Y PCIX29 PCIX29 PCI-X outbound reads with byte-enables crossing a 32 bit boundary are not supported Will not be changed Y PCIX30 PCIX30 Internal reads to invalid register locations 0x48 and 0x4C in the PCI-X configuration header may hang the configuration port Will not be changed Y PCIX31 PCIX31 Internally generated PCI-X configuration transactions may be corrupted by concurrent outbound PCI-X data transactions Will not be changed Y PCIX32 PCIX32 PCI-X parity error on last data beat leaves PCI_PERR signal asserted too long Will not be changed Y PCIX33 PCIX33 PCI-X special cycles or error response messages leave PCI_FRAME and PCI_IRDY asserted too long Will not be changed Y Will not be fixed Y PCI-X Local Bus LBC11 LBC11 LBC DLL may lose lock when enabled MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 3 Table 4. Summary of MPC8560 MPC8560 Silicon Errata and Applicable Revision (continued) Number Name Disposition Silicon Rev. 2.0.2 DMA none - - - none - - - none - - - Doc. as errata; no plans to fix Y PIC 2 I C POR Configuration POR3 MPC8560 MPC8560 is not enabled to enter the sleep mode General GEN2 GPIO control for PCIout and PCIin are mutually exclusive Doc. as errata; fix in future rev. Y GEN3 GPIO input failure caused by contention with PCI Doc. as errata; fix in future rev. Y GEN4 Some pins do not meet 500V CDM ESD criteria Doc. as errata; fix in future rev. Y GEN6 GPIO pins on TSEC2 interface not functioning as documented No plans to fix Y GEN7 CPM is reset by a watchdog timeout machine check Doc. as errata; fix in future rev. Y GEN8 Internal machine check to the e500 core is masked if the L2 cache is disabled using the DEVDISR register. Doc. as errata; fix in future rev. Y ECM target full event counter inaccurate when there is a programming error in transaction mapping Will not be changed Y CPM2 ATM performance monitoring problem with AAL1 CES No plans to fix this. Y CPM3 I2 C erratic behavior can occur if extra clock pulse is detected on SCL No plans to fix this. Y CPM9 FCC missing reset on an overrun No plans to fix this. Y CPM10 CPM10 FCC missing status No plans to fix this. Y CPM12 CPM12 MCC receiver may append aborted frame to a following good frame No plans to fix this. Y CPM13 CPM13 APC transmits unwanted idle cells No plans to fix this. Y CPM14 CPM14 The pointer value of 93 is not supported in PFM mode of AAL1 CES No plans to fix this. Y Performance Monitor PM1 CPM MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 4 Freescale Semiconductor Table 4. Summary of MPC8560 MPC8560 Silicon Errata and Applicable Revision (continued) Number Name Disposition Silicon Rev. 2.0.2 CPM15 CPM15 False address compression No plans to fix this. Y CPM16 CPM16 FCC Tx, Incorrect handling of ethernet collision No plans to fix this. Y MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 5 6 e500 Core CPU29 CPU29 L1 instruction cache gets multiple entries for same line after change in MSR[IS] bit Description: After execution of an mtmsr instruction that changes MSR[IS], it is possible for the L1 instruction cache to contain multiple copies of the same line. The problem occurs as the processor prefetches past the mtmsr instruction. Due to the branch prediction algorithm, the duplicate line could be from any location in memory where the supervisor has execute permissions. Projected Impact: After multiple entries have been established in the L1 I-cache, an attempt to execute instructions from the duplicated line will cause an illegal operation type of program interrupt. Or, if I-cache parity checking is enabled, a machine check will be signaled for an I-cache parity error (MCSR[ICPERR]=1). It is possible that instructions on the duplicated line may be executed multiple times before the program or machine check interrupt occurs. Work Arounds: The recommended work-around is to use rfi instead of mtmsr to change the MSR[IS] bit. Assuming that all the code below is within one page boundary (otherwise the system might get an itlb miss), all exceptions are disabled (by clearing the CE, DE, and EE bits in the MSR register), and r3, SRR0 and SRR1 have been saved away, the following code can be used. lis r3, rfi_addr@h ori r3, r3, rfi_addr@l mtsrr0 r3 mfmsr r3 rlwinm r3,r3,0,28,25 mtsrr1 r3 rfi rfi_addr: Disposition: This defect is present in Rev. 2.0 of the core (Rev 2.0.2 of the device); fixed in future revision of the core. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 6 Freescale Semiconductor e500 Core CPU30 CPU30 I-cache parity errors can be reported incorrectly Description: I-cache parity errors can have incorrect information about the faulting instruction. Keep in mind that an I-cache parity error probably means that the instruction being fetched is corrupted, possibly including changes in the opcode bits. The problem can occur whenever an instruction that is corrupted by a parity error appears to be an instruction that would cause an interrupt or write the SPEFSCR. In addition to reporting an incorrect value in MSRR0, it is possible for other architectural registers to be affected by this erratum. These might include registers like the SPEFSCR and the ESR. Projected Impact: It is not possible to recover gracefully from an I-cache parity error. Either application re-start, or system re-start would be required. Work Arounds: When the problem occurs, MSRR0 may point to the first instruction of an interrupt handler instead of the instruction that caused the interrupt, and SRR0 will point to the corrupted instruction. Therefore, the following steps should be followed: 1) Make all exception handlers to be resident in non-I-cache regions. 2) When an I-cache parity error is detected (if ICPERR is set in the MCSR upon a machine check exception), investigate if the MCSRR0 is pointing to the first instruction of any exception handler. 3) If case 2 is not true, then invalidate the I-cache entry that is pointed to by the MCSRR0 and execute an rfi instruction. 4) If case 2 is true and SRR0 is pointing to application code then terminate the application. 5) If case 2 is true and SRR0 is pointing to kernel code then initiate a reset sequence. Disposition: This defect is present in Rev. 2.0 of the core (Rev 2.0.2 of the device); plan to fix in future revision of the core. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 7 e500 Core CPU31 CPU31 e500 does not behave as documented when HID1[RFXE] = 0 Description: HID1[RFXE] is an enable bit that allows the e500 core to generate machine check interrupts when a fault is seen on the internal core complex bus. The HID1[RFXE] description in the MPC8560 MPC8560 Reference Manual indicates that the e500 core will stall the processor until an interrupt occurs when a fault occurs and RFXE is cleared . However, the e500 does not always behave in this way. If the bus fault occurs on an instruction fetch, it is possible for the e500 to continue processing the bad instructions until the interrupt occurs. If the bus fault occurs on a data read, the e500 may continue processing, using faulty data. Work Arounds: If HID1[RFXE] is set to one, the e500 core will generate a machine check internally when a bus fault occurs. This machine check occurs in time to avoid executing faulty instructions or using faulty data returned by load instructions. Care must be taken to deal with the possibility of multiple interrupts for the same bus fault (one generated internally by the core and one signalled through the PIC). Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 8 Freescale Semiconductor e500 Core CPU32 CPU32 e500 may perform invalid bus access after fetch to no-execute page Description: Under some circumstances, it is possible for the e500 to fetch instructions from addresses for which there is no valid MMU translation. This can occur immediately after an attempt to fetch instructions from a page that is not executable (i.e., depending on MSR[IS], if the appropriate UX or SX bit for the page is zero). The failure occurs under the following circumstances. Assume that the processor attempts to fetch from addresses A1, A2 and A3. Also assume that A1 is on a page that is not executable. If A2 and/or A3 happen to miss in the L1 TLB and miss in the L1 I-cache, the e500 will initiate a transaction on the core complex bus. The real address of this transaction will be in the range from 0xFFFF_F000 to 0xFFFF_FFFF. This transaction can occur even if there is no valid TLB mapping to this address, or there is a mapping and the page is not executable. A typical scenario for this failure might be as follows: 1) Branch prediction redirects the fetch stream to address A1. This address happens to be on the last cache line of a page that is not executable. 2) The fetch unit continues to sequentially fetch instructions from addresses A2 and A3. A2 and/or A3 will be on the next sequential cache line after A1 and will, therefore, be on a different page from A1. 3) The L1 TLB does not have a translation for the page containing A2 and/or A3, and it returns an invalid real address. 4) The cache line at the invalid real address is not in the L1 I-cache. 5) A transaction is queued on the core complex bus for the invalid real address. In another scenario, address A1 doesn't have to be at the end of a page. In this scenario, the branch prediction mechanism redirects the fetch unit to another page for address A2 or A3, and that page is not present in the L1 TLB. Projected Impact: The symptoms of this problem can vary. If the real address of the invalid fetch happens to be the address of an external device, unexpected side effects may occur due to reading the device. A less likely symptom can occur if the processor eventually tries to execute the instruction fetched from address A1. This will result in an instruction storage interrupt. Assume that the handler just sets the execute bit on the page and returns. If the interrupt handler is completely contained in the I-cache, the processor may attempt to execute the data that it fetched from the invalid address. The ISI handler can prevent this from occurring by performing an icbi to any address before returning. Work Arounds: Ensure that the addresses from 0xFFFF_F000 through 0xFFFF_FFFF will not cause side effects or address errors. Also, in the instruction storage interrupt handler, execute an icbi to any address to avoid executing any instructions that might be inadvertently fetched from this region. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 9 Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 10 Freescale Semiconductor L2 Cache L2C4 Lock clear to L2 cache may fail during error scenario Description: There is a scenario in which a lock clear operation appears to fail to clear a lock in the L2 cache. This failure only occurs when the attempt to set the lock results in some kind of bus error (e.g., PCI returns an error condition). Assume the following scenario: 1) The e500 core attempts to set a lock in the L2 cache (by executing a dcbtls or icbtls instruction with CT = 1). The line is not already present in the cache, so it must be read from external memory. This read encounters an error which, depending on the chip configuration, will be reported to the core (probably as an interrupt). 2) At (or near) the same time, a cache external write to the same cache line is being mastered by the ECM. 3) Very quickly after the cache external write, a transaction to clear the lock occurs. This can be caused by the processor executing a icblc or icblc instruction with CT = 1, or by the ECM mastering a lock clear transaction. If this scenario occurs within a tight timing window, the cache line may still be unexpectedly locked at the end of the sequence. Work Arounds: The interrupt handler may want to clear the erroneously remaining lock in this case. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 11 DDR DDR8 DDR memory controller violates precharge command period (tRP) in auto-precharge mode Description: After a read-with-auto-precharge or write-with-auto-precharge command is issued, the controller may issue a precharge-all command for a refresh before the precharge command period (tRP) for the previous command has passed. Projected Impact: This errata may impact any systems that use auto-precharge mode. Empirically, memories from some manufacturers fail more consistently than others and there appears to be a sensitivity to higher clock speeds. For example, in auto-precharge mode, manufacturer-A's memories fail at 333 MHz, but not at 266 MHz, while manufacturer-B's memories pass at all frequencies. Memory manufacturers have been consulted and it appears there is ambiguity in the JEDEC specification with regard to the behavior when a memory encounters a refresh during the refresh command period of a prior refresh. Work Arounds: The following work-arounds are presented: 1. Disable auto-precharge mode and use a low value for 'BSTOPRE' if performance similar to auto-precharge mode is desired (preferred work-around). 2. Limit auto-precharge mode to speeds less than or equal to 266 MHz. 3. Use a DRAM vendor's devices which work at all frequencies. Disposition: Fixed in future revision of the device. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 12 Freescale Semiconductor DDR DDR9 DDR DLL may lose lock Description: Note: for Rev. 2.0.2 silicon, this erratum is superseded by DDR11 DDR11. The DLL used by the DDR memory controller may lose lock due to insufficient supply noise rejection from noise both internal and external to the device. Projected Impact: When the DLL loses its lock, setup and hold times may be violated, resulting in corruption of the address/command bus during accesses to the DDR memory. While the DLL may regain its lock and the clock may appear to be clean, the corruption will already have occurred. Work Arounds: Refer to DDR11 DDR11 workaround. Disposition: Fixed in future revision of the device. Note that Rev 1.0 does not support 2T timing. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 13 DDR DDR10 DDR10 DDR controller violates CKE timing for self refresh in 2T timing Description: When 2T timing is enabled for the DDR controller, the CKE pin is deasserted one applied cycle early when entering self refresh. The CKE pin should have the same timing as the chip select signals, and it should be driven low the same cycle the chip selects are active for the self refresh command. However, it is driven one cycle earlier causing the DRAM to miss the self refresh command. This will cause the memory contents to be corrupted since no refresh takes place. Projected Impact: This bug affects device sleep. The core can still be put to sleep and it is not affected by this bug. Work Arounds: Do not put the device to sleep in 2T timing. Disposition: This behavior exists in Rev 2.0.2. Fixed in future revision of the device. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 14 Freescale Semiconductor DDR DDR11 DDR11 MSYNC_IN receiver control signals connected in 3.3v mode Description: The DDR DLL MSYNC_IN receiver, used for the DLL feedback input, is configured incorrectly (hardcoded to b'00' instead of the 2.5V DDR mode which is b'10). This causes the current source generator to see a bias voltage of GVDD/4 instead of GVDD/3 which is a difference of ~200mV of gate bias voltage. In this configuration, the receiver may fail at low temperature and low GVDD supply. Projected Impact: MSYNC_IN receiver may fail during POR preventing DDR PLL from locking memory clocks. This behavior can be observed by reading two bits at address offset 0xE_0E14 (DBGDDRDLL[WRAP,LOCK]). When bit 0 of this register is set, the DLL has wrapped past the end of its delay chain without finding a lock (this may happen repeatedly during the lock search process, but it should not be true when the lock search is complete). When bit 1 of this register is set, the DLL has completed the lock search process and should be locked. A failure to find a lock is indicated by the simultaneous assertion of both of these bits. The value at address offset 0xE_0E14 is read only, and other bits in this register should be ignored. Work Arounds: The workaround is to override the DLL with a coarse select of 1 and a fine select of 0 (DDRDLLCR=0x8100_0000). To ensure that the value was written as expected, a read following the setting of the register will show DDRDLLCR=0x8100_0100. Pseudo code to show how this is done is as follows: int i, x; x = 0; ddrdllcr = 0x81000000; // Write to DDRDLLCR to override DDR DLL udelay(200); while ( ddrdllcr != 0x81000100 ) { devdisr = devdisr | 0x00010000; for ( i = 0; i < x; i+ ); // Disable DDR controller // Wait-loop where x is defined in cycles devdisr = devdisr & 0xfffeffff; x+; // Verify write to DDRDLLCR // Enable DDR controller // Increment x to wait longer, if necesary } This workaround may require a redesign of existing boards if the interface signals (clocks and address/command) were not matched well at the board level. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 15 Because this workaround essentially bypasses the DDR DLL, and because the DDR SDRAM output AC timing specifications reference the now unused MSYNC_IN input, new timings are needed which reference the DDR SDRAM output clock MCK. The following new AC timings in Table 5 are to be used with respect to this DLL override mode. Table 5. DDR SDRAM Override Mode Output AC Timing Specifications At recommended operating conditions with GVDD of 2.5 V ± 5%. Parameter Symbol 1 Min Max Unit Notes MCK[n] cycle time, (MCK[n]/MCK[n] crossing) tMCK 6 10 ns 2 Skew between ADDR/CMD to any MCK tAOSKEW -1400 -200 ps 3 ADDR/CMD output setup with respect to MCK 333 MHz 266 MHz 200 MHz tDDKHAS - ns 4 ADDR/CMD output hold with respect to MCK 333 MHz 266 MHz 200 MHz tDDKHAX - ns 4 MCS(n) output setup with respect to MCK 333 MHz 266 MHz 200 MHz tDDKHCS - ns 4 MCS(n) output hold with respect to MCK 333 MHz 266 MHz 200 MHz tDDKHCX - ns 4 MDSQ to MCK tDDKHMH 1.2 ns 5 MDQ/MECC/MDM output setup with respect to MDQS 333 MHz 266 MHz 200 MHz tDDKHDS, tDDKLDS - ps 6 MDQ/MECC/MDM output hold with respect to MDQS 333 MHz 266 MHz 200 MHz tDDKHDX, tDDKLDX - ps 6 MDQS preamble start tDDKHMP -0.25 × tMCK + 1.2 ns 7 3.2 4.0 5.2 1.6 2.3 3.6 3.2 4.0 5.2 1.6 2.3 3.6 0 900 1100 1200 900 1100 1200 -0.25 × tMCK MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 16 Freescale Semiconductor Table 5. DDR SDRAM Override Mode Output AC Timing Specifications (continued) At recommended operating conditions with GVDD of 2.5 V ± 5%. Parameter MDQS epilogue end Symbol 1 Min Max Unit Notes tDDKHME 0 1.2 ns 7 Notes: 1.The symbols used for timing specifications follow the pattern of t(first two letters of functional block)(signal)(state) (reference)(state) for inputs and t(first two letters of functional block)(reference)(state)(signal)(state) for outputs. Output hold time can be read as DDR timing (DD) from the rising or falling edge of the reference clock (KH or KL) until the output went invalid (AX or DX). For example, tDDKHAS symbolizes DDR timing (DD) for the time tMCK memory clock reference (K) goes from the high (H) state until outputs (A) are setup (S) or output valid time. Also, tDDKLDX symbolizes DDR timing (DD) for the time tMCK memory clock reference (K) goes low (L) until data outputs (D) are invalid (X) or data output hold time. 2.All MCK/MCK referenced measurements are made from the crossing of the two signals ±0.1 V. 3.In the DLL override workaround mode, MCK/MCK can be shifted in 1/2 applied cycle increments through the DDR DLL Control Register. 4.ADDR/CMD includes all DDR SDRAM output signals except MCK/MCK, MCS, and MDQ/MECC/MDM/MDQS. For the ADDR/CMD setup and hold specifications, it is assumed that the DDR DLL Control Register is set to adjust the memory clocks by 1/2 applied clock cycle (coarse select = 1). 5.Note that tDDKHMH follows the symbol conventions described in note 1. For example, tDDKHMH describes the DDR timing (DD) from the rising edge of the MCK(n) clock (KH) until the MDQS signal is valid (MH). tDDKHMH can be modified through control of the DQSS override bits (WR_DATA_DELAY) in the TIMING_CFG_2 register. In the DLL override workaround mode, this will typically be set to the same delay (one-half) as the clock adjust (coarse select) in the DDR DLL Control Register. The timing parameters listed in the table assume that these 2 parameters have been set to the same adjustment value. See the MPC8560 MPC8560 PowerQUICC III Integrated Communications Processor Preliminary Reference Manual for a description and understanding of the timing modifications enabled by use of these bits. 6.Determined by maximum possible skew between a data strobe (MDQS) and any corresponding bit of data (MDQ), ECC (MECC), or data mask (MDM). The data strobe should be centered inside of the data eye at the pins of the MPC8560 MPC8560 7.All outputs are referenced to the rising edge of MCK(n) at the pins of the MPC8560 MPC8560. Note that tDDKHMP follows the symbol conventions described in note 1. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 17 Figure 1 shows the DDR SDRAM output timing for address skew with respect to any MCK. MCK[n] MCK[n] tMCK tAOSKEWmax) ADDR/CMD CMD NOOP tAOSKEW(min) ADDR/CMD CMD NOOP Figure 1. Timing Diagram for tAOSKEW Measurement Figure 2 shows the DDR SDRAM output timing diagram for the source synchronous mode. MCK[n] MCK[n] tMCK tDDKHAS ,tDDKHCS tDDKHAX ,tDDKHCX ADDR/CMD Write A0 NOOP tDDKHMP tDDKHMH MDQS[n] tDDKHME tDDKHDS tDDKLDS MDQ[x] D0 D1 tDDKLDX tDDKHDX Figure 2. DDR SDRAM Output Timing Diagram for Override Mode MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 18 Freescale Semiconductor After the register is written, software must wait 200µs as specified in the JEDEC spec before enabling the memory controller. Disposition: Fixed in future revision of the device. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 19 DDR DDR12 DDR12 DDR controller may violate the JEDEC parameter for write preamble setup time (tWPRES) Description: According to the DDR-I write preamble setup time specification, the data strobe(s) should be a valid high or low value, or transitioning to a valid value at the falling edge of clock after the write command is captured. Depending upon board delays and the setting of the TIMING_CFG_2[WR_DATA_DELAY] parameter, the DDR controller may not actively drive the strobe DQS at the falling edge of the clock MCK after the DDR-SDRAM has captured the write command - the strobe lines may be tri-stated which violates the "write preamble setup time (tWPRES)" JEDEC specification parameter. A delay value of 0 or 1 cycle in the TIMING_CFG_2[WR_DATA_DELAY] parameter is guaranteed to meet the DDR-I JEDEC specification. A value of 3/4 cycle delay is guaranteed to work as long as the strobe reaches the DDR-SDRAM 300 ps before tDQSS-MAX. As required by the specification, the strobe must reach the DRAM chip between 75% (tDQSS-MIN) and 125% (tDQSS-MAX) of a cycle after a write command is captured by the memory. Board designs should be such that the strobe is guaranteed to reach the memory with sufficient margin from both ends of this window such that it would be quite easy to meet the requirement of the 3/4 cycle setting. Projected Impact: It is currently unclear what the impact is on the memory since the behavior of the DDR-SDRAM is not specified when the tWPRES parameter is violated. Work Arounds: When using values of 1/4 or 1/2 for the TIMING_CFG_2[WR_DATA_DELAY] parameter, write to CCSR offset 0x0_2f00 the value 0x4000_0000. This value written to the internal register will add an extra dead cycle between reads and writes to resolve this issue. Disposition: No plans to fix this erratum. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 20 Freescale Semiconductor TSEC TSEC18 TSEC18 MII, half duplex collision causes Tx frames to lose data Description: A problem exists in the Ethernet controller in which frame data can be lost when running in half duplex mode and transferring frames that exceed the size of the FIFO (2KB in the TSEC). The problem manifests itself when a frame that exceeds the FIFO size gets retried multiple times. In such case, there is a possibility that the FIFO read and write pointers will fall out sync resulting in frame data being lost. A watermark indicator gets communicated from the FIFO to the DMA telling it that there is space available in the FIFO to write new data. In the default case, the FIFO asserts this indicator when it believes it has 64 bytes available in the FIFO. This indicator works fine when there is no retry. However, when a retry occurs within the collision window, and the FIFO is full, the FIFO may falsely indicate to the DMA that it has space available. Upon getting a retry, the FIFO resets the FIFO pointer back to the beginning of the frame to begin re-transmission, but at that point the DMA may have written new data into an already full FIFO causing the FIFO write and read pointers to get out of sync, and resulting in a loss of frame data. Projected Impact: Frames may be corrupted when the Ethernet controller is run in half-duplex mode and a collision occurs while transferring a frame that exceeds the FIFO size. For the TSEC, the first 2048 bytes are lost. Work Arounds: Program the TSEC's respective debug register with a value of 0x25. The TSEC1 register is located at offset 0x2_4094, and TSEC2 at offset 0x2_5094. This register is a debug register whose content is used to compare with the number of free entries left in the Tx FIFO. Once the number of free entries is less than what is programmed in this debug register, the DMA is then only allowed to write 64 more bytes of data. The DMA can only resume writing after the number of free space in the Tx FIFO exceeds what is programmed in the debug register. The value 0x25 is calculated from adding an additional 64-bytes of frame data plus 20 bytes of elastic FIFO used for boundary crossing logic to the default 64-byte value: 64 + 20 + 64 = 148 bytes or 0x25 entries This value will ensure that the DMA engine is held-off until the collision window is passed before writing more data into the Tx FIFO. Disposition: No plans to fix this. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 21 PCI PCI1 PCI/PCI-X does not fully support RapidIO Interoperability Spec or strict bridge ordering rules Description: The PCI-to-OCeaN circuitry does not currently support bridging from RapidIO according to the RapidIO Interoperability Spec. Specifically, if an external RapidIO device tries to target the PowereQUICC III with a RapidIO NWRITE-R transaction or with any RapidIO write at a priority level higher than 0, and the RapidIO inbound ATMU routes the transaction to the PCI/PCI-X interface, the PCI-to-OCeaN circuitry could deadlock. Projected Impact: Incomplete support for the RapidIO Interoperability spec and strict PCI bridging ordering rules. Work Arounds: Use of RapidIO NWRITE-R transactions must be avoided in bridging applications to the PCI/PCI-X controller, and all RapidIO writes targeting the PCI/PCI-X controller must be of priority level 0. Note that this means transaction ordering will be relaxed such that read responses will not necessarily push posted writes in the bridge, and writes will never bypass read requests. Disposition: Incompatibilities with the RapidIO Interoperability spec will be fixed for Rev 2.0.1 with the following exceptions: 1) Transaction ordering will continue to be "relaxed" such that read responses may bypass posted writes to the PCI/PCI-X interface, and writes will not bypass read requests to PCI/PCI-X. 2) Because writes will not bypass read requests, the PowerQUICC III will not support RapidIO to PCI/PCI-X bridging where a PCI/PCI-X target does not support writes bypassing read requests or does not allow read responses to bypass writes. This would not be standard behavior for a PCI device, but it specifically precludes the following topology: Two PowerQUICC IIIs communicating with each other via PCI or PCI-X may still deadlock when two RapidIO devices (one on each PowerQUICC III) are simultaneously performing priority-1 writes to targets on the remote PowerQUICC III via the PCI/PCI-X link between the devices. To support such a topology, RapidIO write transactions that bridge to the other PowerQUICC III would have to be priority 0. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 22 Freescale Semiconductor PCI PCI2 Outbound translation window must not overlap PCI memory-mapped configuration space Description: This errata exists also in the PQII silicon, and an errata has now been issued for that. The description below is taken from that errata. Overview:þ If an outbound translation window is programmed to have a translation that maps an address to any of the following addresses: CCSRBAR+0x08000, CCSRBAR+0x08004, or CCSRBAR+0x08008, a memory transaction is not generated on PCI. Instead the PCI CFG_ADDR, PCI CFG_DATA, or PCI INT_ACK registers of the memory-mapped configuration space are accessed. The decode for PCI CFG_ADDR, PCI CFG_DATA and PCI INT_ACK is performed after the address has gone through the outbound address translation units. Projected Impact: Unwanted accesses to PCI CFG_ADDR, PCI CFG_DATA or PCI INT_ACK are performed instead of outbound memory transactions if an outbound window overlaps with the internal configuration space. Note that previous devices (8245, 106, 107) require that outbound windows not overlap configuration space. Work Arounds: Choose one of the following restrictions: · Software must not program an outbound translation window such that it maps an address to CCSRBAR+08000, CCSRBAR+08004, or CCSRBAR+08008. · To make this more general, software can be restricted so an outbound translation window cannot overlap the configuration window. · A still more general solution would be toþ require that PCSRBAR = CCSRBAR, which would reserve this section of the PCIþaddress space for configuration only. Disposition: Restrictions documented in the Reference Manual. No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 23 PCI PCI4 Inbound PCI configuration write with parity error corrupts PCI registers Description: If an inbound configuration write arrives with a data parity error, the error is reported and captured and PERR is asserted as expected. However, the bad data is not squashed; it is written to the register specified in the transaction. Projected Impact: Data parity errors on PCI bus during configuration transactions can corrupt PCI registers. Work Arounds: A system trying to recover from a PCI data parity error must re-initialize the PCI interface if the error occurred during a configuration write. Disposition: There is currently no plan to fix this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 24 Freescale Semiconductor PCI PCI16 PCI16 Boot instructions fetched from PCI corrupted when parity enable bit updated Description: If the CPU is fetching instructions from PCI with the instruction cache disabled and the "Parity Error Response" bit in the PCI bus command register is changed from 0->1, then instruction fetches can be corrupted. This bug should only appear when the SYSCLK:device clock ratio exceeds 6:1. Projected Impact: This will typically only happen during boot. Instructions in the stream of boot code could be lost or corrupted causing boot to fail. Work Arounds: 1) Initialize the PCI bus command register via the boot sequencer to set the parity error response bit before the CPU's boot sequence starts or 2) Copy boot code from PCI to SRAM or DDR and execute the code that sets the parity error response bit from SRAM or DDR or 3) Leave the parity error response bit cleared (no parity error checking) at least until execution has shifted to code executing from another memory Disposition: Fixed in future revision of the device. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 25 PCI PCI17 PCI17 PCI high order bits driven incorrectly in debug mode Description: Transaction source ID information is supposed to be driven on PCI_AD[62:58]. However, if the PCI is in 32-bit mode, PCI_AD[58] is tristated. So the low order bit of the sourceID is not driven. Projected Impact: PCI debug information is not complete; some source ID's cannot be distinguished. Work Arounds: Debug mode works properly when PCI is in 64-bit mode. Disposition: Fixed in future revision of the device. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 26 Freescale Semiconductor PCI-X PCIX1 PCI-X non-posted writes that receive split response are not serialized Description: The PCI-X controller properly handles split responses to writes, but it does not serialize non-posted writes. This allows pipelining of I/O writes to targets. However, bridges that exhibit this behavior should also retry pipelined writes. This behavior is acceptable. Projected Impact: No impact expected. Work Arounds: None. Disposition: Will not be fixed. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 27 PCI-X PCIX3 PCI-X arbiter does not support broken master mode Description: The PCI spec describes arbiter behavior in which a master that does not assert FRAME after receiving a grant for 16 cycles is subsequently considered broken by the arbiter and is no longer given any grants. The PowerQUICC III PCI arbiter supports this, but the PCI-X arbiter does not. This can results in lowered performance if a broken master holds a request asserted. Projected Impact: The PCI-X arbiter operates in such a way that it will not continuously grant a device for greater than five consecutive cycles if there is another device requesting. Consequently, there is very little impact. Work Arounds: None. Disposition: No plans to fix this. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 28 Freescale Semiconductor PCI-X PCIX26 PCIX26 PCI-X does not report master or target abort in the status register on a misaligned split completion error message. Description: Split completion error messages do not update the PCI status register or the PCI secondary status register. This is a violation of the PCI-X 1.0 specification, Section 5.4.6. Projected Impact: The impact of this behavior is minimal as the same functionality can be achieved as described in the work around. Work Arounds: The work around for this problem is to read the PCI/X error data low capture register (ERR_DL) after an interrupt is triggered for a split completion message error. The relevant information with respect to message class, message index and message description is stored in ERR_DL which contains the split completion error message data field as described in Section 2.10.6 of the PCI-X 1.0 specification. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 29 PCI-X PCIX27 PCIX27 PCI-X address field of an outbound split completion error message for a misaligned read is 0x04 instead of 0x00 Description: The PCI-X logic does not set the split completion message bits [18:12] (remaining lower address) to zero during the SCM data phase for DWORD reads as described in the PCI-X 1.0 specification, Section 2.10.6. For DWORD read requests to the upper 32 bits of a quad-word, bit 14 is set to 1. Projected Impact: This has no impact on the system. Work Arounds: There are no work arounds required. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 30 Freescale Semiconductor PCI-X PCIX28 PCIX28 PCI-X split completion error message data field is not stored in the data capture register Description: Split completion error messages for outbound DWORD writes are incorrectly reported in the PCI/X error data low capture register (ERR_DL). Projected Impact: The PCI-X logic does not track split responses of outbound writes. Therefore this erratum should be of no consequence. Work Arounds: None. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 31 PCI-X PCIX29 PCIX29 PCI-X outbound reads with byte-enables crossing a 32 bit boundary are not supported Description: The PCI-X protocol supports byte enables on reads as 32-bit transactions only. The PowerQUICC III requires the following: 1) Reads to PCI-X of greater than 32 bits must be aligned to a 64-bit boundary and have a size that is a multiple of 8 bytes. 2) Reads to PCI-X of less than or equal to 32 bits must not cross a 32-bit boundary. A read to PCI-X that is not aligned to a 32-bit boundary and which crosses a 32-bit boundary will execute only to the 32-bit boundary. No mechanism is provided in hardware to split this type of read into multiple transactions with byte enables on the PCI-X bus. Care should be taken on the PowerQUICC III when writing software to meet these alignment restrictions. Projected Impact: The core can be programmed to avoid misaligned accesses to PCI-X space. However misaligned reads coming from RapidIO may generate an odd-sized read crossing a 32-bit boundary on PCI-X. This read would complete incorrectly, returning corrupt data. Work Arounds: Do not generate misaligned reads to PCI-X. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 32 Freescale Semiconductor PCI-X PCIX30 PCIX30 Internal reads to invalid register locations 0x48 and 0x4C in the PCI-X configuration header may hang the configuration port Description: Internal reads (reads originating from either the core, or other I/O ports on the device) to invalid register locations 0x48 and 0x4C in the PCI-X configuration header may hang the configuration port. This can in turn hang the rest of the system. Projected Impact: This should not be an issue as these are invalid register locations in the PCI-X configuration header. Work Arounds: Avoid accesses to invalid register locations in the PCI-X configuration header. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 33 PCI-X PCIX31 PCIX31 Internally generated PCI-X configuration transactions may be corrupted by concurrent outbound PCI-X data transactions Description: There is a rare situation where an internal access (originating from either the core, or other I/O ports on the device) to the 256-byte PCI-X configuration header may be corrupted by concurrent outbound PCI-X data transactions. The corruption does not occur if the PCI-X configuration transactions and the outbound PCI-X data transactions are not concurrent. The corruption does not occur with inbound PCI-X traffic. Projected Impact: This is an issue for any system that mixes internally generated PCI-X configuration transactions with outbound PCI-X data transactions. Work Arounds: Perform one of the following work arounds: 1. Ensure that PCI-X configuration transactions are completed before starting PCI-X data traffic, or 2. Ensure that all PCI-X outbound data traffic is quiesced before attempting PCI-X configuration transactions. The programmer must ensure all of the following: - Non-configuration transactions to PCI-X from the core are quiesced. - The core is not fetching instructions from PCI-X. - DMA transactions to PCI-X are quiesced. - RapidIO bridging transactions to PCI-X are quiesced. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 34 Freescale Semiconductor PCI-X PCIX32 PCIX32 PCI-X parity error on last data beat leaves PCI_PERR signal asserted too long Description: If a parity error occurs on the last data beat of a transaction with inbound data, the device asserts PCI_PERR. However, the PCI_PERR signal negates one cycle later than it should because it is not actively driven high before being tri-stated (it should be driven high). This is a problem for the following data transactions: - outbound reads with split completion data - inbound writes Projected Impact: A subsequent transaction may erroneously flag a parity error where there is none. Work Arounds: Choose one of the following: a). Disable parity error checking, or b) Use a stronger pull-up resister on PCI_PERR as follows: - 1 k for 133 MHz operation - 2 k for 66 MHz operation - 4 k for 33 MHz operation The pullup resistor values above are in violation of the specification which calls for a minimum of 5 k pull-up resistor values. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 Freescale Semiconductor 35 PCI-X PCIX33 PCIX33 PCI-X special cycles or error response messages leave PCI_FRAME and PCI_IRDY asserted too long Description: After a PCI-X special cycle instruction, the output enable for the PCI_FRAME and PCI_IRDY I/O drivers negates before the PCI_FRAME and PCI_IRDY signals have been actively driven negated. As a result the PCI_FRAME and PCI_IRDY signals remain asserted until the external pull-up resistor pulls the signals negated. A typical weak pull-up may not negate these signals fast enough to prevent subsequent transactions from being corrupted. This is also occurs when the device is driving a split completion error response message, and that error response message itself receives a parity error, SERR, or target abort error. Projected Impact: The PCI_FRAME and PCI_IRDY signals may be sampled as asserted by the system in subsequent cycles, causing a master abort failure of the subsequent transaction. Work Arounds: Use stronger pullup resistors on the PCI_FRAME and PCI_IRDY signals as follows: - 1 k for 133 MHz operation - 2 k for 66 MHz operation - 4 k for 33 MHz operation The pullup resistor values above are in violation of the PCI-X specification which calls for a minimum of 5 k pull-up resistor values. Disposition: No plans to change this behavior. MPC8560 MPC8560 PowerQUICC IIITM Device Errata, Rev 0.2 36 Freescale Semiconductor Local Bus LBC11 LBC11 LBC DLL may lose lock when enabled Description: When enabled, the DLL used by the local bus controller may lose lock due to insufficient supply noise rejection from noise both internal and external to the device.The local bus is designed to operate in two modes: DLL bypass and DLL enabled (as configured by the LCRR[DBYP] bit). Projected Impact: When the DLL loses its lock, setup and hold times may be violated, resulting in corruption of the address/command bus during local bus accesses. While the DLL may regain its lock and the clock may appear to be clean, the corruption will already have occurred. Work Arounds: The DLL must always be sampled and locked. This can be done in software during initialization using the following procedure to modify the LBC DLL control register (LBDLLCR): uint temp_lbdll = 0; int tap1, tap2; int maxiter = 10; int stable = 0; temp_lbdll = lbdllcr; tap1 = (temp_lbdll & 0x7ff); while (!stable && maxiter-) { //insert a delay loop here not to exceed 2500 CCB clock cycles temp_lbdll = lbdllcr; tap2 = (temp_lbdll & 0x7ff); if ( abs(tap1 - tap2)