NXP Semiconductors i.MX 6Dual, i.MX 6Quad, i.MX 6DualPlus, i.MX 6QuadPlus Reference Manual

NXP Semiconductors

Chip Errata

Rev. 6.1, 06/2016

IMX6DQCE

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus

This document details the silicon errata known at the time of publication for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus multimedia applications processors.

Table 2 provides a revision history for this document. Table 3 contains a summary of the silicon errata. Bolded rows are specific to either i.MX 6Dual/6Quad or

i.MX 6DualPlus/6QuadPlus (see the errata description column).

Table 4 lists the ARM errata excluded from detailed description in this document.

To identify the silicon revision, refer to the last letter of the part number. See Table 1 for examples.

Table 1. Part number/silicon revision examples

Example Part Numbers Silicon Revision

MCIMX6Q6AVT10AC i.MX 6Quad, Revision 1.2 MCIMX6D6AVT10AD i.MX 6Dual, Revision 1.3 MCIMX6QP6AVT1AA i.MX 6QuadPlus, Revision 1.0 MCIMX6DP6AVT1AA i.MX 6DualPlus, Revision 1.0

For additional information, see either the i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM) or the i.MX 6DualPlus/6QuadPlus Applications Processor Reference Manual (IMX6DQPRM).

NOTE

BSP functionality in some configurations and use cases, or your own/added software functionality, may be affected by an erratum. We have made our best attempt at providing software workaround requirements and BSP status for each erratum in this document. Whether a software workaround has been implemented in the BSP or not, the user should evaluate his specific use cases and take any (additional) necessary actions to prevent the occurrence or impact of each erratum. Go through your support channel if you have any questions or concerns.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

2 NXP Semiconductors

The following table provides a revision history for this document.

Table 2. Document Revision History

Rev.

Number

Rev. 6.1 06/2016 • Updated ERR004536 in Table 3 and ERR004536 changing from: Silicon revision 1.3 to; No fix

Rev. 6 02/2016 • Updated the following i.MX 6Dual/6Quad-specific errata:

Rev. 5 06/2015 • Update to ERR006282 Rev. 4 06/2014 • Added ERR007805

Date Substantive Changes

scheduled and removing i.MX 6Dual/6Quad Only.

– ERR004300, ERR004484, ERR004536, ERR005216, ERR005723, ERR005768, ERR005908,

ERR006282, ERR006687, ERR007966, ERR008506,

• Added the following i.MX 6Dual/6Quad-specific errata: – ERR007926, ERR008587, ERR009219

• Added the following i.MX 6DualPlus/6QuadPlus-specific errata: – ERR009619, ERR009623, ERR009624

• Added the following i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus-specific errata:

– ERR007555, ERR007556, ERR007557, ERR007573, ERR007575, ERR007577 , ERR007881,

ERR008990, ERR009165, ERR009218, ERR009535, ERR009596, ERR009598, ERR009604, ERR009605, ERR009606, ERR009678, ERR009704, ERR009742, ERR009743, ERR009858

• Updated the following i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus-specific errata: – ERR004366

• Added Table 4 describing ARM errata not documented in this deliverable.

• Updated the following ARM errata:

• ERR003717, ERR003718, ERR003719, ERR003720, ERR003721, ERR003723, ERR003724,

ERR003725, ERR003726, ERR003727, ERR003728, ERR003729, ERR00 3730, ERR003731, ERR003732, ERR003735, ERR003736, ERR003737, ERR003738, ERR00 3740, ERR003741, ERR004324, ERR004326, ERR004327, ERR005175, ERR005183, ERR00 5185, ERR005187, ERR005199, ERR005200, ERR005382, ERR005383, ERR005385, ERR00 5386, ERR005387, ERR007006, ERR007007, ERR007008

• Removed errata: – ERR005779

• Added ERR008001

• Added ERR008000

• Added ERR007554

• Added ERR007926

• Added ERR007966

• Removed ERR003742. This item was ARM erratum 732672. Access to this information must come directly from ARM.

• Removed ERR007005. This item was ARM erratum 791420. Access to this information must come directly from ARM.

Rev. 3 11/2013 • Added the following: ERR007005, ERR007006, ERR007007, ERR007008, ER007117, ER007220,

ERR007265, ERR007266

• Updated the following: ERR003740, ERR003742, ERR003778, ERR004512

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 3

Table 2. Document Revision History (continued)

Rev.

Number

Rev. 2 5/2013 • Deleted ERR003775—Addressed in rev. 1 of the i.MX 6Dual/6Quad Applications Processor Reference

Rev. 1.1 2/2013 Restored pages omitted in Rev. 1.

Rev. 1 1/2013 • Added the following:

Rev. 0 10/2012 Initial public release.

Date Substantive Changes

Manual (IMX6DQRM).

• Added the following errata:

– ERR006282

– ERR006308

– ERR006358

– ERR006687

• Updated the following:

– ERR004353 – ERR004446

– ERR005829

– ERR006223 – ERR006259 – ERR006281

• Updated ERR004367 – Deleted ERR005384 (not relevant to this Freescale implementation of the ARM® core)

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

4 NXP Semiconductors

Table 3. Summary of Silicon Errata

Errata Name Solution Page

Analog

ERR005852 Analog: Transition from Deep Sleep Mode to LDO Bypass Mode may cause the slow

No fix scheduled

response of the VDDARM_CAP output

ARM

ERR003717 ARM: 740657—Global Timer can send two interrupts for the same event No fix scheduled ERR003718 ARM: 743622—Faulty logic in the Store Buffer may lead to data corruption No fix scheduled ERR003719 ARM/MP: 751469 — Overflow in PMU counters may not be detected No fix scheduled ERR003720 ARM/MP: 751472—An interrupted ICIALLUIS operation may prevent the completion

No fix scheduled

of a following broadcast operation

ERR003721 ARM: 751473—Under very rare circumstances, Automatic Data prefetcher can lead

No fix scheduled

to deadlock or data corruption

ERR003723 ARM: 751476—May miss a watchpoint on the second part of an unaligned access

No fix scheduled

that crosses a page boundary

ERR003724 ARM: 754322—Possible faulty MMU translations following an ASID switch No fix scheduled ERR003725 ARM: 725631—ISB is counted in Performance Monitor events 0x0C and 0x0D No fix scheduled ERR003726 ARM: 729817—MainID register alias addresses are not mapped on Debug APB

No fix scheduled

interface

ERR003727 ARM: 729818—In debug state, next instruction is stalled when sdabort flag is set,

No fix scheduled

instead of being discarded

ERR003728 ARM: 740661—Event 0x74 / PMUEVENT[38:37] may be inaccurate No fix scheduled

16 18 20 22

26 28 29

ERR003729 ARM: 740663—Event 0x68 / PMUEVENT[9:8] may be inaccurate No fix scheduled ERR003730 ARM: 743623—Bad interaction between a minimum of seven PLDs and one

No fix scheduled

Non-Cacheable LDM can lead to a deadlock

ERR003731 ARM: 743626—An imprecise external abort, received while the processor enters

No fix scheduled

WFI, may cause a processor deadlock

ERR003732 ARM: 751471—DBGPCSR format is incorrect No fix scheduled ERR003733 ARM: 751480—Conditional failed LDREXcc can set the exclusive monitor No fix scheduled ERR003734 ARM: 752519—An imprecise abort may be reported twice on non-cacheable reads No fix scheduled ERR003735 ARM: 754323—Repeated Store in the same cache line may delay the visibility of the

No fix scheduled

Store

ERR003736 ARM: 756421—Sticky Pipeline Advance bit cannot be cleared from debug APB

No fix scheduled

accesses

ERR003737 ARM: 757119—Some “Unallocated memory hint” instructions generate an

No fix scheduled

UNDEFINED exception instead of being treated as NOP

ERR003738 ARM/MP: 751475—Parity error may not be reported on full cache line access

No fix scheduled

(eviction / coherent data transfer / cp15 clean operations)

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

32 34

37 39 40 41

NXP Semiconductors 5

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

ERR003739 ARM: 751470—Imprecise abort on the last data of a cache linefill may not be

No fix scheduled

detected

ERR003740 ARM/PL310: 752271—Double linefill feature can cause data corruption [i.MX

No fix scheduled

6Dual/6Quad only]

ERR003741 ARM/PL310: 729815—The “High Priority for SO and Dev reads” feature can cause

No fix scheduled

Quality of Service issues to cacheable read transactions

ERR003743 ARM/PL310: 754670—A continuous write flow can stall a read targeting the same

No fix scheduled

memory area

ERR004324 ARM/MP: 761319—Ordering of read accesses to the same memory location may not

No fix scheduled

be ensured

ERR004325 ARM/MP: 764369—Data or unified cache line ma intenance operation by MVA may

No fix scheduled

not succeed on an Inner Shareable memory region

ERR004326 ARM/MP: 761321—MRC and MCR are not coun ted in event 0x68 No fix scheduled ERR004327 ARM/MP: 764319—Read accesses to DBGPRSR and DBGOSLSR may generate

No fix scheduled

an unexpected UNDEF

ERR005175 ARM/MP: 771221—PLD instructions may allocate data in the Data Cache regardless

No fix scheduled

of the Cache Enable bit value

ERR005183 ARM/MP: 771224—Visibility of Debug Enable access rights to enable/disable tracing

No fix scheduled

is not ensured by an ISB

ERR005185 ARM/MP: 771225—Speculative cacheable reads to aborting memory region clear

No fix scheduled

the internal exclusive monitor, may lead to livelock

53 54

ERR005187 ARM/MP: 771223—Parity errors on BTAC and GHB are reported on

PARITYFAIL[7:6], regardless of the Parity Enable bit value

ERR005198 ARM/PL310: 780370—DATAERR, TAGERR, and Tag parity errors are incorrectly

sampled by the eviction buffer, leading to data corruption

ERR005199 ARM/MP: 769419—No automatic Store Buf fer drain, visibility of written data requires

an explicit Cache Sync operation [i.MX 6Dual/6Quad Only]

ERR005200 ARM/MP: 765569—Prefetcher can cross 4 KB boundary if offset is programmed with

value 23

ERR005382 ARM/MP: 775419—PMU event 0x0A (exception return) might count twice the LDM

PC ^ instructions with base address register write-back

ERR005383 ARM/MP: 775420—A data cache maintenance operation that aborts, followed by an

ISB and without any DSB in-between, might lead to deadlock

ERR005385 ARM/MP: 782772—A speculative execution of a Load-Exclusive or Store-Exclusive

instruction after a write to Strongly Ordered memory might deadlock the processor

ERR005386 ARM/MP: 782773—Upd ating a translation entry to move a page mapping might

erroneously cause an unexpected translation fault

ERR005387 ARM/MP: 782774—A spurious event 0x63, “STREX passed,” can be reported on an

LDREX that is preceded by a write to Strongly Ordered memory region

No fix scheduled

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

6 NXP Semiconductors

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

ERR006259 ARM: Debug/trace functions (PMU, PTM and ETB) are disabled with absence of

No fix scheduled

JT AG_TCK clock after POR

ERR007006 ARM/MP:794072-- Short loop including a DMB instruction might cause a denial of

No fix scheduled

service

ERR007007 ARM/MP: 794073 -- Speculative instruction fetches with MMU disabled might not

No fix scheduled

comply with architectural requirements

ERR007008 ARM/MP: 794074 --A write request to Uncacheable Shareable memory region might

No fix scheduled

be executed twice

ERR009604 ARM (CA9): 845369 — Unde r very rare timing circumstances, transition into

No fix scheduled

streaming mode might create a data corruption

ERR009605 ARM (CA9): 761320—Full cache line writes to the same memory region from at least

No fix scheduled

two processors might deadlock the processor

ERR009742 ARM: 795769 - “Write Context ID" event is updated on read access No fix scheduled ERR009743 ARM: 799770 - DBGPRSR Sticky Reset st atus bit is set to 1 by the CPU debug reset

No fix scheduled

instead of by the CPU non-debug reset

ERR009858 ARM/PL310: 796171 When data banking is implemented, data parity errors can be

No fix scheduled

incorrectly generated

CAAM

ERR004320 CAAM: Three encryption functions may show up as available, even though they are

No fix scheduled

not

82 83

ERR004347 CAAM: False read access error No fix scheduled ERR004348 CAAM: Internal 16 Kb RAM (CAAM) does not support wrapped accesses No fix scheduled ERR005766 CAAM: CAAM cannot handle interleaved READ data “beats” returned by two different

No fix scheduled

slaves in the system, in reply to two different AXI-ID accesses

CCM

ERR006223 CCM: Failure to resume from Wait/Stop mode with power gating No fix scheduled ERR007265 CCM: When improper low-power sequence is used, the SoC enters low power mode

No fix scheduled

before the ARM core executes WFI

ERR009219 CCM: Asynchronous clock switching can ca use unpredictable behavior [i.MX

No fix scheduled

6Dual/6Quad Only]

eCSPI

ERR009165 ERR009535 ERR009606

eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to be sent twice No fix scheduled 93

eCSPI: Burst completion by SS signal in slave mode is not functional No fix scheduled 94

eCSPI: In master mode, burst lengths of 32n+1 will transmit incorrect data No fix scheduled 95

EIM

ERR004446 EIM: AUS mode is nonfunctional for devices larger than 32 MB No fix scheduled

86 87 88

89 90

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 7

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

ERR009218 EIM: Signals fail to drive as outp uts during boundary scan test No fix scheduled

ENET

ERR004512 ENET: 1 Gb Ethernet MAC (ENET) system limitation No fix scheduled ERR005783 ENET: ENET Status FIFO may overflow due to consecutive short frames No fix scheduled ERR005895 ENET: ENET 1588 channel 2 event capture mode not functional No fix sch eduled ERR006358 ENET: Write to Transmit Descriptor Active Register (ENET_TDAR) is ignored No fix scheduled ERR006687 ENET: Only the ENET wake-up interrupt request can wake the system from Wait

No fix scheduled

mode [i.MX 6Dual/6Quad Only]

ESAI

ERR008000

ESAI: ESAI may encounter channel swap when overrun/underrun occurs No fix scheduled 103

EXSC

ERR004365 EXSC: Exclusive accesses to certain memories are not supported to full AXI

No fix scheduled

specification

ERR005828 EXSC: Protecting the EIM memory map region causes unpredictable behavior No fix scheduled

FlexCAN

ERR005829 FlexCAN: FlexCAN does not transmit a message that is enabled to be transmitted in

No fix scheduled

a specific moment during the arbitration process

99 100 101 102

104

105

106

GPMI

ERR008001

GPMI: GPMI does not support the Set Feature command in Toggle mode No fix scheduled 108

GPU

ERR004341 GPU2D: Accessing GPU2D when it is power-gated will cause a deadlock in the

No fix scheduled

system

ERR005908 GPU2D: Image quality degradation observed for stretch blits when the stretch factor

No fix scheduled

is exactly an integer [i.MX 6Dual/6Quad Only]

ERR004300 GPU3D: L1 cach e performance drop [i.MX 6Dual/6Quad Only] No fix scheduled ERR004484 GPU3D: L1 cach e “Write Address Data” pairing error [i.MX 6Dual/6Quad Only] No fix scheduled ERR005216 GPU3D: Black texels in Android App Singularity 3D [i.MX 6Dual/6Quad Only] No fix scheduled

HDMI

ERR003744 HDMI: 9000446457—Audio DMA does not generate an interrupt after software stops

No fix scheduled

DMA transaction

ERR003745 HDMI: 9000440660—Audio DMA fails to stop after ERROR detection No fix scheduled ERR004308 HDMI: 8000504668—The arithmetic unit may get wrong video timing values although

No fix scheduled

the FC_* registers hold correct values

109

110

111 112 113

114

115 116

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

8 NXP Semiconductors

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

ERR004323 HDMI: The DMA burst read transaction address region is limited to 8 KB No fix scheduled ERR004366 HDMI: 9000482480—ARM core read operation returns incorrect data for certain

No fix scheduled

HDCP registers

ERR005171 HDMI: HDMI Tx audio may have noise due to audio DMA FIFO overflow No fix scheduled ERR005172 HDMI: Under certain circumstances, the HDCP may transmit incorrect Ainfo value,

No fix scheduled

causing a failure on the receiver side

ERR005173 HDMI: Clarification on HDMI programming procedure to avoid FIFO overflow No fix scheduled ERR005174 HDMI: HDMI AHB Audio DMA stream misalign m ent on system initialization No fix scheduled

I2C

ERR007805

I2C: When the I2C clock speed is configured for 400 kHz, the SCL low period violates

the I2C specification

No fix scheduled 126

I/O

ERR004307 I/O: MIPI_HSI, USB_HSIC, and ENET I/O interfaces should not be configured to

No fix scheduled

Differential input mode

IPU

ERR009623 IPU: IDMAC burst errors when crossing a 4k boundary using NI/PI 420/422 formats

No fix scheduled

[i.MX 6DualPlus/6QuadPlus Only]

MIPI

117 124

118 119

120 122

126

127

ERR004310 MIPI: Glitch or unknown clock frequency on MIPI input clock may occur in case the

No fix scheduled

CCM source clock is modified

ERR005190 MIPI: CSI2 Data lanes are activated before th e HS clock from the CSI Tx side

No fix scheduled

(camera) starts

ERR005191 MIPI: Corruption of short command packets with Word Count (WC) greater than

No fix scheduled

16’hFFEE, during video mode transmission by the MIPI Generic Interface

ERR005192 MIPI: Reverse direction long packets with no payload incorrectly issue a CRC error

No fix scheduled

for MIPI DSI

ERR005193 MIPI: The bits for setting the MIPI DSI video mode cannot be changed on the fly No fix scheduled ERR005194 MIPI: On MIPI DSI, there is a possible corruption of the video packets caused by

No fix scheduled overlapping of the current line over the next line, if the configuration is programmed incorrectly when using the DPI interface

ERR005195 MIPI: Incorrect blanking packet may be sent by the MIPI DSI interface No fix scheduled ERR005196 MIPI: Error Interrupt generated by the MIPI CSI interface for certain legal packet

No fix scheduled types

ERR005197 MIPI: Null and Blanking data packets activate ‘dvalid’ signal No fix scheduled ERR009704 MIPI: CSI-2: CRC error produced in 4-lane configuration No fix scheduled

128

129

130

131

132 133

134 135

136 137

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 9

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

MLB

ERR004312 MLB: Multi fram e per sub-buffer mode is not supported No fix scheduled

MMDC

ERR005778 MMDC: DDR Controller’s measure unit may return an incorrect value when operating

No fix scheduled below 100 MHz

ERR009596 MMDC: ARCR_GUARD bits of MMDC Core AXI Re-ordering Control register

No fix scheduled (MMDC_MAARCR) doesn't behave as expected

PCIe

ERR003747 PCIe: 9000436491—Reading the Segmented Buffer Depth Port Logic registers

No fix scheduled returns all zeros

ERR003748 PCIe: 9000427578—Root ports with address translation drop inbound requests,

No fix scheduled without reporting an error

ERR003749 PCIe: 9000426180—MSI Interrupt Controller Status Register bit not cleared after

No fix scheduled being written by software

ERR003751 PCIe: 9000413207—PME Requester ID overwritten when two PMEs are received

No fix scheduled consecutively

ERR003753 PCIe: 9000405932—AXI/AHB Bridge Slave does not return a response to an

No fix scheduled outbound non-posted request

ERR003754 PCIe: 9000403702—AHB/AXI Bridge Master responds with UR status instead of CA

No fix scheduled status for inbound MRd requesting greater than CX_REMOTE_RD_REQ_SIZE

138

139

140

141

142

143

144

145

146

ERR003755 PCIe: 9000402443—Uncorrectable Internal Error Severity register bit has incorrect

No fix scheduled default value

ERR003756 PCIe: 9000387484—LTSSM: Software-initiated transitions to Disabled, Hot Reset,

No fix scheduled Configuration, or Loopback states sometimes take longer than expected

ERR003757 PCIe: 9000448152—Internal Address Translation Unit (iATU): Inbound Vendor

No fix scheduled Defined Message (VDM) ‘ID Match Mode’ is not functional

ERR003758 PCIe: 9000441819—Upstream Port does not transition to Recovery after receiving

No fix scheduled TS OSs during “ENTER_L2 negotiation”

ERR003759 PCIe: 9000439510—Internal Address Translation Unit (iATU) can sometimes

No fix scheduled overwrite Outbound (Tx) Vendor Messages and MSIs

ERR003760 PCIe: 9000439175—Poisoned Atomic Op requests targeting RTRGT0 receive UR

No fix scheduled response instead of CA response

ERR004297 PCIe: 9000336356—Link configuration sometimes proceeds when incorrect TS

No fix scheduled Ordered Sets are received

ERR004298 PCIe: 9000471173—Bad DLLP error status checking is too strict No fix scheduled ERR004299 PCIe: 9000493959—L1 ASPM incorrectly entered after link down event during L1

No fix scheduled ASPM entry negotiation

ERR004321 PCIe: 9000470913—Power Management Control: Core might enter L0s/L1 before

No fix scheduled Retry buffer is empty

147

148

149

150

151

152

153

154 155

156

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

10 NXP Semiconductors

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

ERR004374 PCIe: 9000487440—TLP sometimes unnecessarily replayed No fix scheduled ERR004489 PCIe: 9000505660—PCIe2 receiver equalizer settings No fix scheduled ERR004490 PCIe: 9000514662—LTSSM delay when moving from L0 to recovery upon receipt of

No fix scheduled insufficient TS1 Ordered Sets

ERR004491 PCIe: 9000507633—TLP might be replayed an extra time before core enters

No fix scheduled recovery

ERR005184 PCIe: Clock pointers can lose sync during clock rate changes No fix scheduled ERR005186 PCIe: The PCIe Controll er Core Does Not Send Enough TS2 Ordered Sets During

No fix scheduled Link Retrain And Speed Change

ERR005188 PCIe: The PCIe Controller cannot exit successfully L1 state of L TSSM when the Core

No fix scheduled Clock is removed

ERR005189 PCIe: PCIe Gen2/Gen3 Hardware Autonomous Speed Disable Bit In Configuration

No fix scheduled Register is not sticky

ERR005723 PCIe: PCIe does not support L2 power down [i.MX 6Dual/6Quad Only] No fix scheduled ERR007554 PCIe: MSI Mask Register Reserved Bits not read-only No fix scheduled. ERR007555 PCIe: iATU - Optional programmable CFG Shift feature for ECAM is not correctly

No fix scheduled updating address (9000642041)

ERR007556 PCIe: Core Delays Transition From L0 To Recovery After Receiving Two TS OS And

No fix scheduled Erroneous Data (9000597455)

158 159 160

162

163 165

166

167

168 169 170

171

ERR007557 PCIe: Extra FTS sent when Extended Sync h bit is set (9000588281) No fix scheduled ERR007559 PCIe: Core sends TS1 with non-PAD lane number too early in

No fix scheduled Configuration.Linkwidth.Accept State (9000574708)

ERR007573 PCIe: Link and lane number-match not checked in recovery (9000569433) No fix scheduled ERR007575 PCIe: LTSSM delay when moving from L0 to recovery upon receipt of insufficient TS1

No fix scheduled Ordered Sets (9000514662)

ERR007577 PCIe: DLLP/T LP can be missed on RX path when immediately followed by EIOS

No fix scheduled (9000487440)

ERR008587 PCIe: Random link down after warm reset [i.MX 6Dual/6Quad Only] No fix scheduled

PRE

ERR009619 PRE: GPU3D, GPU2D and VPU cannot be power-gated if the PRE is in use [i.MX

No fix scheduled 6DualPlus/6QuadPlus Only]

ERR009624 PRE: ENABLE bit cannot be set in a special case, when the EN_REPEAT bit is set

No fix scheduled [i.MX 6DualPlus/6QuadPlus Only]

ROM

ERR007117 ROM: When booting from NAND flash, enfc_clk_root clock is not gated off when

doing the clock source switch [i.MX 6Dual/6Quad Only]

ERR007220 ROM: NAND boot may fail due to incorrect Hamming Checking implementation in the

ROM code [i.MX 6Dual/6Quad Only]

Fixed in silicon

revision 1.3.

Fixed in silicon

revision 1.3

172 173

174 175

176

177

178

179

180

181

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 11

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

ERR007926 ROM: 32 kHz internal oscillator timing inaccuracy may affect SD/MMC, NAND, and

No fix scheduled OneNAND boot [i.MX 6Dual/6Quad Only]

ERR005645 ROM: Normal SD clock speed (SDR12) not selectable in SD/SDXC boot mode No fix scheduled ERR005768 ROM: In rare cases, secondary image boot flow may not work due to mis-sampling

No fix scheduled of the WDOG reset [i.MX 6Dual/6Quad Only]

ERR006282 ROM: ROM code uses nonreset PFDs to generate clocks, which may lead to random

boot failures [i.MX 6Dual/6Quad Only]

Fixed in silicon

revision 1.3

ERR007266 ROM: EIM NOR boot may fail if plug-in is used No fix scheduled ERR008506 ROM: Incorrect NAND BAD Block Management [i.MX 6Dual/6Quad Only] No fix scheduled ERR009678 ROM: SD/EMMC/NAND prematurely times out during boot [i.MX 6Dual/6Quad Only] No fix scheduled

SATA

ERR003761 SAT A: 9000433864—COMRESET and COMWAKE do not always contain six bursts No fix scheduled ERR003762 SATA: 9000450053—In SDB FIS with N-bit set, non-matching PMP field is not

No fix scheduled discarded

ERR003763 SATA: 9000448817—Soft Reset command does not SYNC-escape incoming data

No fix scheduled FIS

ERR003764 SATA: 9000447882—ERR_I bit set when PhyRdy goes low during non-data FIS

No fix scheduled reception

ERR003765 SATA: 9000447627—Global reset does not clear IS.IPS register bits when P#IS is

No fix scheduled non-zero

182

184 185

186

190 191 192

193 194

195

196

197

ERR003766 SATA: 9000446485—phy_partial, phy_slumber incorrectly asserted for a power

No fix scheduled mode

ERR003767 SATA: 9000446482—hCccComplete cleared, incorrectly incremented No fix scheduled ERR003769 SATA: 9000445811—Erroneous PRD interrupt assertion No fix scheduled ERR003770 SATA: 9000451535—Hang due to FIFO count change, when FIFO is cleared No fix scheduled ERR003771 SATA: 9000451305—Hang after incoming FIS and soft reset No fix scheduled ERR003772 SAT A: 9000451274—Power mode request collision causes assertion of phy_partial,

No fix scheduled phy_slumber

ERR003773 SATA: 9000451526—Hang after Soft Reset and PM Request from the Device No fix scheduled ERR007966 SAT A:SAT A speed negotiation fails after suspend and resume —[i.MX 6Dual/6Quad

No fix scheduled Only]

ERR009598 SATA: PRD not flushed from PRD FIFO at command list underflow No fix scheduled

SNVS

ERR004367 SNVS: SNVS_LP resets to the power OFF state No fix scheduled

SSI

ERR003778 SSI: In AC97, 16-bit mode, received da ta is shifted by 4-bit locations No fix scheduled

198

199 200 201 202 203

204 205

207

208

209

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

12 NXP Semiconductors

Table 3. Summary of Silicon Errata (continued)

Errata Name Solution Page

ERR005764 SSI: AC97 receive data may be wrong when clock ratio between external clock to ipg

No fix scheduled is higher than 1:8

ERR008990 SSI: Channel swap in single FIFO mode when an underrun or overrun occurs No fix scheduled

USB

ERR004534 USB: Wrong HS disconnection may be generated after resume No fix scheduled ERR006281 USB: Incorrect DP/DN state when only VBUS is applied No fix scheduled ERR006308 USB: Host non-doubleword –aligned buffer address can cause host to hang on OUT

No fix scheduled Retry

ERR004535 USB: USB suspend and resume flow clarifications No fix scheduled ERR007881 USB: Timeout error in Device mode No fix scheduled

uSDHC

ERR004364 uSDHC: Limitations on uSDHC3 and uSDHC4 clock-gating No fix scheduled ERR004536 uSDHC: ADMA Length Mismatch Error may occur for longer read latencies No fix scheduled

VPU

ERR004345 VPU: Wrong interrupt is generated sometimes whe n context switchi ng to H.2 64

No fix scheduled encoder, during multi-instance

ERR004349 VPU: Cannot decode Sorenson Spark Version 0 bitstream No fix scheduled

210

211

212 213 214

215 216

217 218

219

220

ERR004361 VPU: VPU does not work in case of smaller chunk size in SSP (streaming pump

No fix scheduled processing)

ERR004363 VPU: Causes a macro-block of P-picture decoding error No fix scheduled

WDOG

ERR004346 WDOG: WDOG SRS bit requires to be written twice No fix scheduled

XTAL

ERR005777 XTAL: In some cases, the 24 MHz oscillator start-up is slow or may fail to start No fix scheduled

221

222

223

224

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 13

Table 4. Excluded ARM Errata

ARM Errata Reference Title

743625 A coherent ACP request might interfere with a

non-cacheable SWP/SWPB from the processor, Potentially causing deadlock

754319 A sequence of cancelled Advanced-SIMD or

VFP stores might deadlock

754320 A cancelled Advanced-SIMD or VFP load

multiple of more than 8 beats might deadlock

745320 A Floating Point write following a failed

conditional read might write corrupted da ta

751469 Overflow in PMU counters may not be detected i.MX6 does not support PMU (Performance

751475 Parity error may not be reported on full cache

line access (eviction / coherent data transfer / cp15 clean operations)

761321 MRC and MCR are not counted in event 0x68 i.MX6 does not support PMU (Performance

Reason why excluded from this errata

document

i.MX6 does not support the ACP (Accelerator Coherency Port) hence errata not applicable.

Errata was fixed in the Floating Point Unit (FPU) Revision 0x4 which is used across i.MX6, hence not applicable.

Monitoring Unit) hence this ARM errata is not applicable.

i.MX6 does not implement parity hence errata not applicable. The parity feature is disabled by default and should not be enabled.

Monitoring Unit) hence this ARM errata is not applicable.

764269 Under very rare circumstances, a sequence of

at least three writes merging in the same 64-bit address range might cause data corruption

791420 Possible denial of service for coherent requests

on a cache line which is continuously written by a processor

756420 Instruction Cache parity error reporting on

PARITYF AIL[5:4] output is one cycle earlier than the other PARITY FAIL bits

732672 An abort on the second part of a double linefill

can cause data corruption on the first part

ARM has not managed to reproduce the failure in actual Silicon and no software workaround available for this erratum.

Freescale cannot disclose this errata per ARM requirements, however software workaround has been implemented in the Freescale Linux BSP for this erratum. OS vendors/users must approach ARM if further information is required.

i.MX6 does not implement parity hence errata not applicable. The parity feature is disabled by default and should not be enabled.

Freescale cannot disclose this errata per ARM requirements, however software workaround has been implemented in the Freescale Linux BSP for impacted devices. OS vendors/users must approach ARM if further information is required.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

14 NXP Semiconductors

ERR005852

ERR005852 Analog: Transition from Deep Sleep Mode to LDO Byp a ss Mode may

cause the slow response of the VDDARM_CAP output

Description:

Normally, the VDDARM_CAP supply takes only approximately 40 μs to raise to the correct voltage when exiting from Deep Sleep (DSM) mode, if the LDO is enabled. If the LDO bypass mode is selected, the VDDARM_CAP supply voltage will drop to approximately 0 V when entering and when exiting from DSM, even though the VDDARM_IN supply is already stable, the VDDARM_CAP supply will take about 2 ms to rise to the correct voltage.

Projected Impact:

ARM core might fail to resume.

Workarounds:

The software workaround to prevent this issue it to switch to analog bypass mode (0x1E), prior to entering DSM, and then, revert to the normal bypass mode, when exiting from DSM.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 15

ERR003717

ERR003717 ARM: 740657—Global Timer can send two interrupts for the same

event

Description:

The Global Timer can be programmed to generate an interrupt request to the processor when it reaches a given programmed value. Due to the erratum, when the Global Timer is programmed not to use the auto-increment feature, it might generate two interrupt requests instead of one.

Conditions:

The Global Timer Control register is programmed with the following settings:

• Bit[3] = 1’b0 – Global Timer is programmed in “single-shot” mode

• Bit[2] = 1’b1 – Global Timer IRQ generation is enabled

• Bit[1] = 1’b1 – Global Timer value comparison with Comparator registers is enabled

• Bit[0] = 1’b1 – Global Timer count is enabled With these settings, an IRQ is generated to the processor when the Global T imer value reaches the

value programmed in the Comparator registers. The Interrupt Handler then performs the following sequence:

1. Read the ICCIAR (Interrupt Acknowledge) register

2. Clear the Global Timer flag

3. Modify the comparator value to set it to a higher value

4. Write the ICCEOIR (End of Interrupt) register Under these conditions, due to the erratum, the Global Timer might generate a second (spurious)

interrupt request to the processor at the end of this Interrupt Handler sequence.

Projected Impact:

The erratum creates spurious interrupt requests in the system.

Workarounds:

Because the erratum only happens when the Global Timer is programmed in “single-shot” mode, that is, when it does not use the auto-increment feature, a first possible workaround could be to program the Global Timer to use the auto-increment feature.

If this solution does not work, a second workaround could be to modify the Interrupt Handler to avoid the offending sequence. This is achieved by clearing the Global Timer flag after having incremented the Comparator register value.

Then, the correct code sequence for the Interrupt Handler should look as below:

1. Read the ICCIAR (Interrupt Acknowledge) register

2. Modify the comparator value to set it to a higher value

3. Clear the Global Timer flag

4. Clear the Pending Status information for Interrupt 27 (Global Timer interrupt) in the Distributor of the Interrupt Controller.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

16 NXP Semiconductors

5. Write the ICCEOIR (End of Interrupt) register

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not needed in the BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. The BSP does not use ARM global timer. The configuration and logic of the kernel does not make use of the Global Timer. If the Global timer is used, the workaround documented by ARM should be followed. Due to limitations of this timer specifically in low power mode operation we do not recommend the use of this ARM Global timer.

ERR003717

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 17

ERR003718

ERR003718 ARM: 743622—Faulty logic in the Store Buffer may lead to data

corruption

Description:

Under very rare conditions, a faulty optimization in the Cortex®-A9 store buffer might lead to data corruption.

Conditions:

The code sequence which exhibits the failure requires at least five cacheable writes in 64-bit data chunk:

• Three of the writes must be in the same cache line

• Another write must be in a different cache line

• All of the above four writes hit in the L1 data cache

• A fifth write is required in any of the above two cache lines that fully writes a 64-bit data chunk

With the above code sequence, under very rare circumstances, this fifth write might get corrupted, with the written data either being lost, or being written in another cache line.

The conditions under which the erratum can occur are extremely rare, and require the coincidence of multiple events and states in the Cortex-A9 micro-architecture.

As an example: let’s assume A, A’, A”, and A’’’ are all in the same cache line—B and B’ are in another cache line. The following code sequence might trigger the erratum:

STR A STR A’ STR A’’ STR B STR A’’’ (or STR B’)

At the time where the first four STR are in the Cortex-A9 store buffer , and the fifth STR arrives at a very precise cycle in the Store Buffer input stage, then the fifth STR might not see its cache line dependency on the previous STR instructions. Because of this, in cases when the cache line A or B gets invalidated due to a coherent request from another CPU, the fifth STR might write in a faulty cache line, causing data corruption.

An alternative version of the erratum might happen even without a coherent request — In the case when the fifth STR is a 64-bit write in the same location as one of A, A’, A ’ ’, then the erratum might also be exhibited. Note that this is a quite uncommon scenario because it requires a first write to a memory location that is immediately and fully overwritten.

Projected Impact:

When it occurs, this erratum creates a data corruption.

Workarounds:

A software workaround is available for this erratum that requires setting bit[6] in the undocumented Diagnostic Control register, placed in CP15 c15 0 c0 1.

The bit can be written in Secure state only, with the following Read/Modify/W rite code sequence:

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

18 NXP Semiconductors

MRC p15,0,rt,c15,c0,1 ORR rt,rt,#0x40 MCR p15,0,rt,c15,c0,1

When this bit is set, the “fast lookup” optimization in the Store Buffer is disabled, which will prevent the failure to happen.

Setting this bit has no visible impact on the overall performance or power consumption of the processor.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround implemented in Linux BSP codebase (UBOOT) starting in release imx_3.0.35_4.1.0.

ERR003718

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 19

ERR003719

ERR003719 ARM/MP: 751469 — Overflow in PMU counters may not be detected

Description:

Overflow detection logic in the Performance Monitor Counters is faulty, and under certain timing conditions, the overflow may remain undetected. In this case, the Overflow Flag Status register (PMOVSR) is not updated as it should, and no interrupt is reported on the corresponding PMUIRQ line. It is important to notice that the Cycle counter is not affected by this erratum.

Projected Impact:

PMU overflow detection is not reliable.

Workarounds:

The main workaround for this erratum is to poll the performance counter . The maximum increment in a single cycle for a given event is 2. Therefore, polling can be infrequent as no counter can increment by more than 2^32 in fewer than 2 billion cycles. If the main usage model for performance counters is collecting values over a long period, then polling can be used to collect values (and reset the counter) rather than waiting for an overflow to occur. Polling can be done infrequently and overflow avoided. If the main usage model for performance counters relies on presetting the counter to some value and waiting for an overflow to occur, then polling can be used to detect when an overflow event has been missed. An overflow can be determined to have been missed if the unsigned value in the counter is less than the value preset into the counter. Again, polling can be done infrequently because of the number of cycles it would need for this check to fail. In the case that the erratum was triggered and an overflow event was missed, that counter sample can be thrown away or the true value can be reconstructed. An alternative workaround is to configure two counters to be triggered by the same event, staggering their initial count values by 1. This will result in the rollover being triggered by at least counter. This alternative workaround works for all Cortex-A9 events but the three following ones, due to the fact these three events can increment by 2 in a single cycle:

- 0x68 – Instructions coming out of the core renaming stage

- 0x73 – Floating-point instructions

- 0x74 – NEON instructions

For these 3 events, only the first workaround is applicable to fix the defect.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not needed because this erratum will not be encountered in normal device operation. The Freescale Linux BSP does not support this optional profiling feature. Users may add

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

20 NXP Semiconductors

ERR003719

support for this profiling feature as required, but should ensure the multiple errata impacting the ARM PMU are considered especially for multi-core usage.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 21

ERR003720

ERR003720 ARM/MP: 751472—An interrupted ICIALLUIS operation may prevent

the completion of a following broadcast operation

Description:

In an MPCore configuration with two or more processors working in SMP mode with maintenance operation broadcast enabled, if a processor is interrupted while executing an ICIALLUIS operation, and performs another broadcast maintenance operation during its Interrupt Service Routine, then this second operation might not be executed on other processors in the cluster.

Conditions:

The erratum requires an MPCore configuration with two or more CPUs working in SMP mode. One processor has interrupts enabled, and Cache and TLB maintenance broadcast enabled too (ACTLR.FW=1’b1). This processor executes an ICIALLUIS (invalidates all instruction caches Inner Shareable to Point of Unification). This instruction is executed on the processor, and also broadcast to other processors in the MPCore cluster . The processor then receives an interrupt (IRQ or FIQ), which interrupts the ICIALLUIS operation.

During the Interrupt Service Routine, the processor executes any other Cache or TLB maintenance operation which is also broadcast to other processors in the MPCore cluster . If the other processors in the cluster receive this second maintenance operation before having completed the first ICIALLUIS operation, then the erratum occurs, as the other processors will not execute the second maintenance operation. This is because there is no “stacking” mechanism for acknowledge answers between the processors, so that the acknowledge request sent to signify the completion of the ICIALLUIS will be interpreted by the originating processor as an acknowledge for the second maintenance operation.

Projected Impact:

Due to the erratum, the processor might end up with corrupted entries in the Cache or in the TLB, leading to possible failures in the system.

Workarounds:

A software workaround is available for this erratum that involves setting bit[11] in the undocumented Diagnostic Control register, placed in CP15 c15 0 c0 1.

This bit can be written in Secure state only, with the following Read/Modify/W rite code sequence:

MRC p15,0,rt,c15,c0,1 ORR rt,rt,#0x800 MCR p15,0,rt,c15,c0,1

When it is set, this bit prevents CP15 maintenance operations to be interrupted. Using this software workaround is not expected to cause any visible impact on the system.

Proposed Solution:

No fix scheduled

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

22 NXP Semiconductors

Linux BSP Status:

Software workaround implemented in Linux BSP codebase (UBOOT) starting in release imx_3.0.35_4.1.0.

ERR003720

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 23

ERR003721

ERR003721 ARM: 751473—Under very rare circumstances, Automatic Data

prefetcher can lead to deadlock or data corruption

Description:

Under very rare timing circumstances, the automatic Data prefetcher might cause address hazard issues, possibly leading to a data corruption or a deadlock of the processor.

Conditions:

The erratum can only happen when the Data Cache and MMU are enabled in the following cases:

• On all memory regions marked as Write-Back Non-Shared, when the Data Prefetcher in L1 is

enabled (ACTLR[2]=1’b1), regardless of the ACTLR.SMP bit.

• On all memory regions marked as Write-Back Shared, when the Data Prefetch Hint in L2 is

enabled (ACTLR[1]=1’b1), and when the processor is in SMP mode (ACTLR.SMP=1’b1).

Projected Impact:

When the bug happens, a data corruption or a processor deadlock can happen.

Workarounds:

The workaround for this erratum requires not enabling the automatic Data Prefetcher by keeping ACTRL[2:1]=2’b00, which is the default value on exit from reset.

Although this feature might show significant performance gain on a few synthetic benchmarks, it usually has no impact on real systems. It means, this workaround is not expected to cause any visible impact on final products.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not needed in the BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. Linux BSP keeps ACTRL[2:1]=2’b00.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

24 NXP Semiconductors

ERR003723

ERR003723 ARM: 751476—May miss a watchpoint on the second part of an

unaligned access that crosses a page boundary

Description:

Under rare conditions, a watchpoint on the second part of an unaligned access that crosses a 4 KB page boundary and that is missed in the micro-TLB for the second part of its request might be undetected.

The erratum requires a previous conditional instruction that accesses the second 4 KB memory region (= where the watchpoint is set), is missed in the micro-TLB, and is condition failed. The erratum also requires that no other micro-TLB miss occurs between this conditional failed instruction and the unaligned access. This implies that the unaligned access must hit in the micro-TLB for the first part of its request.

Projected Impact:

A valid watchpoint trigger is missed.

Workarounds:

In case, a watchpoint is set on any of the first 3 bytes of a 4 KB memory region, and unaligned accesses are not being faulted, then the erratum might happen.

The workaround then requires setting a guard watchpoint on the last byte of the previous page, and dealing with any “false positive” matches as and when they occur.

Proposed Solution:

No fix scheduled

Linux BSP Status:

The Linux BSP does not use this debug feature—the ARM workaround should be followed. Software workaround is not needed because this erratum will not be encountered in normal device operation.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 25

ERR003724

ERR003724 ARM: 754322—Possible faulty MMU translations following an ASID

switch

Description:

A microTLB entry might be corrupted following an ASID switch, possibly corrupting subsequent MMU translations.

The erratum requires execution of an explicit memory access, which might be speculative. This memory access misses in the TLB and cause a translation table walk. The erratum occurs when the translation table walk starts before the ASID switch code sequence, but completes after the ASID switch code sequence. In this case, a new entry is allocated in the microTLB for the TLB entry for this translation table walk, but corresponding to the old ASID. Because the microTLB does not record the ASID value, the new MMU translation, which should happen with the new ASID following the ASID switch, might hit this stale microTLB entry and become corrupted.

Note that there is no Trustzone Security risk because the Security state of the access is held in the microTLB, and cannot be corrupted.

Projected Impact:

The errata might cause MMU translation corruptions.

Workarounds:

The workaround for this erratum involves adding a DSB in the ASID switch code sequence. The ARM architecture only mandates ISB before and after the ASID switch. Adding a DSB prior to the ASID switch ensures that the Page T able W alk completes prior to the ASID change, so that no stale entry can be allocated in the micro-TLB.

The examples in the ARM Architecture Reference Manual for synchronizing the change in the ASID and TTBR need to be changed as follows:

The sequence:

becomes

the sequence:

Change ASID to 0 ISB Change Translation Table Base Register ISB Change ASID to new value

DSB Change ASID to 0 ISB Change Translation Table Base Register ISB DSB Change ASID to new value

Change Translation Table Base Register to the global-only mappings ISB Change ASID to new value

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

26 NXP Semiconductors

ISB Change Translation Table Base Register to new value

becomes

Change Translation Table Base Register to the global-only mappings ISB DSB Change ASID to new value ISB Change Translation Table Base Register to new value

and the sequence:

Set TTBCR.PD0 = 1 ISB Change ASID to new value Change Translation Table Base Register to new value ISB Set TTBCR.PD0 = 0

becomes

Set TTBCR.PD0 = 1 ISB DSB Change ASID to new value Change Translation Table Base Register to new value ISB Set TTBCR.PD0 = 0

ERR003724

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 27

ERR003725

ERR003725 ARM: 725631—ISB is counted in Performance Monitor events 0x0C

and 0x0D

Description:

The ISB is implemented as a branch in the Cortex-A9 micro-architecture. This implies that events 0x0C (software change of PC) and 0x0D (immediate branch) are asserted when an ISB occurs. This is not compliant with the ARM architecture.

Projected Impact:

The count of events 0x0C and 0x0D are not 100% precise when using the Performance Monitor counters, due to the ISB being counted in addition to the real software changes to PC (for 0x0C) and immediate branches (0x0D).

The erratum also causes the corresponding PMUEVENT bits to toggle in case an ISB is executed.

• PMUEVENT[13] relates to event 0x0C

• PMUEVENT[14] relates to event 0x0D

Workarounds:

Count ISB instructions along with event 0x90. The user should subtract this ISB count from the results obtained in events 0x0C and 0x0D, to obtain the precise count of software change of PC (0x0C) and immediate branches (0x0D).

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not needed because this erratum will not be encountered in normal device operation.The Freescale Linux BSP does not support this optional profiling feature. Users may add support for this profiling feature as required, but should ensure the multiple errata impacting the ARM PMU are considered especially for multi-core usage.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

28 NXP Semiconductors

ERR003726

ERR003726 ARM: 729817—MainID register alias addresses are not mapped on

Debug APB interface

Description:

The ARM Debug Architecture specifies registers 838 and 839 as “Alias of the MainID register”. They should be accessible through the APB Debug interface at addresses 0xD18 and 0xD1C.

In Cortex-A9, the two alias addresses are not implemented. A read access at any of these two addresses returns 0, instead of the MIDR value.

Note that read accesses to these two registers through the internal CP14 interface are trapped to UNDEF , which is compliant with the ARM Debug architecture. So, the erratum only applies to the alias addresses through the external Debug APB interface.

Projected Impact:

If the debugger or any other external agent tries to read the MIDR register using the alias addresses, it will get a faulty answer (0x0), which can cause all sorts of malfunction in the debugger afterwards.

Workarounds:

The workaround for this erratum requires always accessing the MIDR at its original address, 0xD00, and not at any of its alias addresses.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not needed because this erratum will not be encountered in normal device operation.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 29

ERR003727

ERR003727 ARM: 729818—In debug state, next instruction is st alled when sdabort

flag is set, instead of being discarded

Description:

When the processor is in debug state, an instruction written to the ITR after a Load/Store instruction that aborts gets executed on clearing the SDABORT_l, instead of being discarded.

Projected Impact:

Different failures can happen due to the instruction being executed when it should not. In most cases, it is expected that the failure will not cause any significant problem.

Workarounds:

There are a selection of workarounds with increasing complexity and decreasing impact. In each case, the impact is a loss of performance when debugging:

• Do not use stall mode

• Do not use stall mode when doing load/store operations

• Always check for a sticky abort after issuing a load/store operation in stall mode (the cost of this

probably means the above second workaround is a preferred alternative)

• Always check for a sticky abort after issuing a load/store operation in stall mode, before issuing

any further instructions that might corrupt important target state (such as, further load/store instructions, instructions that write to “live” registers [VFP, CP15, etc.])

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not needed because this erratum will not be encountered in normal device operation.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

30 NXP Semiconductors

ERR003728

ERR003728 ARM: 740661—Event 0x74 / PMUEVENT[38:37] may be inaccurate

Description:

Event 0x74 counts the total number of Neon instructions passing through the register rename pipeline stage. Due to the erratum, the “stall” information is not taken into account. So, one Neon instruction that remains for n cycles in the register rename stage is counted as n Neon instructions. As a consequence, the count of event 0x74 might be corrupted, and cannot be relied upon. The event is also reported externally on PMUEVENT[38:37], which suffers from the same inaccuracy.

Projected Impact:

The implication of this erratum is that Neon instructions cannot be counted reliably in the versions of the product that are affected by this erratum.

Workarounds:

No workaround is possible to achieve the required functionality of counting how many Neon instructions are executed (or renamed) in the processor.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not needed because this erratum will not be encountered in normal device operation. The Freescale Linux BSP does not support this optional profiling feature. Users may add support for this profiling feature as required, but should ensure the multiple errata impacting the ARM PMU (Performance Monitoring Unit) are considered especially for multi-core usage.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 31

ERR003729

ERR003729 ARM: 740663—Event 0x68 / PMUEVENT[9:8] may be inaccurate

Description:

Event 0x68 counts the total number of instructions passing through the register rename pipeline stage. Under certain conditions, some branch-related instructions might pass through this pipeline stage without being counted. As a consequence, event 0x68 might be inaccurate, lower than expected. The event is also reported externally on PMUEVENT[9:8], which suffers from the same inaccuracy.

Conditions:

The erratum occurs when the following conditions are met:

• Events are enabled

• One of the PMU counters is programmed to count event 0x68 — number of instructions passing

through the register rename stage. Alternatively, an external component counts, or relies on, PMUEVENT[9:8].

• A program, containing the following instructions, is executed:

— A Branch immediate, without Link — An ISB instruction — An HB instruction, without Link and without parameter, in Thumb2EE state — An ENTERX or LEAVEX instruction, in Thumb2 or Thumb2EE state

• The program executed is causing some stalls in the processor pipeline

Under certain timing conditions specific to the Cortex-A9 micro-architecture, a cycle stall in the processor pipeline might “hide” the instructions mentioned above, thus ending with a corrupted count for event 0x68, or a corrupted value on PMUEVENT[9:8] during this given cycle. If the “hidden” instruction appears in a loop, the count difference can be significant.

As an example, let’s consider the following loop:

loop mcr 15, 0, r2, cr9, cr12, {4}

The loop contains four instructions; so, the final instruction count should (approximately) be four times the number of executed loops. In practice, the MCR is causing a pipeline stall that “hides” the branch instruction (bne.n); so, only three instructions are counted per loop, and the final count appears as three times the number of executed loops.

Projected Impact:

The implication of this erratum is that the values of event 0x68 and PMUEVENT[9:8] are imprecise, and cannot be relied upon.

Workarounds:

adds r3, #1 cmp.w r3, #loop_number bne.n loop

No workaround is possible to achieve the required functionality of counting how many instructions are precisely passing through the register rename pipeline stage.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

32 NXP Semiconductors

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not needed because this erratum will never be encountered in normal device operation.The Freescale Linux BSP does not support this optional profiling feature. Users may add support for this profiling feature as required, but should ensure the multiple errata impacting the ARM PMU (Performance Monitoring Unit) are considered especially f or multi-core usage.

ERR003729

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 33

ERR003730

ERR003730 ARM: 743623—Bad interaction between a minimum of seven PLDs

and one Non-Cacheable LDM can lead to a deadlock

Description:

Under very rare circumstances, a deadlock can happen in the processor when it is handling a minimum of seven PLD instructions, shortly followed by one LDM to an uncacheable memory location.

The LDM is treated as uncacheable in the following cases:

• The LDM is performed while the Data Cache is OFF

• The LDM is targeting a memory region marked as Strongly Ordered, Device, Normal Memory

Non-Cacheable, or Normal Memory Write-Through

• The LDM is targeting a memory region marked as Shareable Normal Memory W rite-Back, and

the CPU is in AMP mode.

Conditions:

The code sequence that exhibits this erratum requires at least seven PLDs, shortly followed by one LDM, to an uncacheable memory region. The erratum happens when the LDM appears on the AXI bus before any of the seven PLDs. This can possibly happen if the first PLD is a miss in the micro-TLB; in that case, it needs to perform a TLB request which might not be serviced immediately because the mainTLB is already performing a Page T able Walk for another resource (for example, instruction side), or because the PLD request itself to the mainTLB is missing and causing a Page Table Walk.

Also note that the above conditions are not sufficient to recreate the failure, as additional rare conditions on the internal state of the processor are necessary to exhibit the errata.

Projected Impact:

The erratum might create a processor deadlock. However, the conditions that are required for this to occur are extremely unlikely to occur in real code sequences.

Workarounds:

The primary workaround might be to avoid the offending code sequence, that is, not to use uncacheable LDM when making intensive use of PLD instructions.

In case the above workaround cannot be done, another workaround for this erratum can be to set bit[20] in the undocumented Control register, which is placed in CP15 c15 0 c0 1.

This bit needs to be written with the following Read/Modify/Write code sequence:

MRC p15,0,r0,c15,c0,1 ORR r0,r0,#0x00100000 MCR p15,0,r0,c15,c0,1

Setting this bit causes all PLD instructions to be treated as NOPs, with the consequence that code sequences usually using the PLDs, such as the memcpy() routine, might suffer from a visible performance drop.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

34 NXP Semiconductors

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not needed in the BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. Users should check their custom OS and either avoid the code sequence or apply the ARM recommended workaround. The ARM recommended workaround does have a performance impact.

ERR003730

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 35

ERR003731

ERR003731 ARM: 743626—An imprecise external abort, received while the

processor enters WFI, may cause a processor deadlock

Description:

An imprecise external abort received while the processor is ready to enter into WFI state might cause a processor deadlock.

Explicit memory transactions can be completed by inserting a DSB before the WFI instruction. However, this does not prevent memo ry accesses generated by previously issued PLD instructions page table walks associated with previously issued PLD instructions or as a result of the PLE engine.

If an external abort is returned as a result of one of these memory accesses after executing a WFI instruction, the processor can cause a deadlock.

Projected Impact:

In case, the non-explicit memory request receives an external imprecise abort response while the processor is ready to enter into WFI state, the processor might cause a deadlock.

In practical systems, it is not expected that these memory transactions will generate an external abort, as external aborts are usually a sign of significant corruption in the system.

Workarounds:

A possible workaround for this erratum is to protect all memory regions that can return an imprecise external abort with the correct MMU settings, to prevent any external aborts.

Proposed Solution:

No fix scheduled

Linux BSP Status:

The BSP uses correct MMU settings and does not present conditions that can cause an imprecise external abort. BSP has exception handlers for such aborts.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

36 NXP Semiconductors

ERR003732 ARM: 751471—DBGPCSR format is incorrect

Description:

About the DBGPCSR register, the ARM architecture specifies that:

• DBGPCSR[31:2] contains sampled value of bits [31:2] of the PC.

The sampled value is an instruction address plus an offset that depends on the processor instruction set state.

• DBGPCSR[1:0] contains the meaning of PC sample value, with the following permitted values:

— 0b00 ((DBGPCSR[31:2] << 2) - 8) references an ARM state instruction — 0bx1 ((DBGPCSR[31:1] << 1) - 4) references a Thumb or ThumbEE state instruction — 0b10 IMPLEMENTATION DEFINED

This field encodes the processor instruction set state, so that the profiling tool can calculate the true instruction address by subtracting the appropriate offset from the value sampled in bits [31:2] of the register.

In Cortex-A9, the DBGPCSR samples the target address of executed branches (but possibly still speculative to data aborts), with the following encodings:

• DBGPCSR[31:2] contains the address of the target branch instruction, with no offset

• DBGPCSR[1:0] contains the execution state of the target branch instruction:

ERR003732

— 0xb00 for an ARM state instruction — 0xb01 for a Thumb2 state instruction — 0xb10 for a Jazelle state instruction — 0xb11 for a Thumb2EE state instruction

Projected Impact:

The implication of this erratum is that the debugger tools neither rely on the architected description for the value of DBGPCSR[1:0], nor remove any offset from DBGPCSR[31:2], to obtain the expected PC value.

Subtracting 4 or 8 to the DBGPCSR[31:2] value would lead to an area of code that is unlikely to have been recently executed, or that could even not contain any executable code.

The same might be true for Thumb instructions at half-word boundaries, in which case PC[1]=1 but DBGPCSR[1]=0, or ThumbEE instructions at word boundaries, with PC[1]=0 and DBGPCSR[1]=1.

In Cortex-A9, because the DBGPCSR is always a branch target (= start of a basic block to the tool), the debugger should be able to spot many of these cases and attribute the sample to the right basic block.

Workarounds:

The debugger tools can find the expected PC value and instruction state by reading the DBGPCSR register, and consider it as described in the Description section.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 37

ERR003732

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not needed because this erratum will never be encountered in normal device operation. Software workaround not applicable to the BSP since it is a debug feature. Users should use the ARM recommended workaround if using this debug feature in their application.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

38 NXP Semiconductors

ERR003733

ERR003733 ARM: 751480—Conditional failed LDREXcc can set the exclusive

monitor

Description:

A conditional LDREX might set the internal exclusive monitor of the Cortex-A9 even when its condition fails. So, any subsequent STREX that depends on this LDREXcc might succeed when it should not.

Projected Impact:

The implication of the erratum is that a subsequent STREX might succeed when it should not. So, the memory region protected by the exclusive mechanism can be corrupted if another agent is accessing it at the same time.

Workarounds:

The workaround for this erratum can be not to use conditional LDREX along with non-conditional STREX.

• If no conditional LDREX is used, the erratum cannot be triggered.

• If conditional LDREX is used, the associated STREX should be conditional too with the same

condition, so that even if the exclusive monitor is set by the condition failed LDREX, the following STREX will not be executed because it will be condition failed too. For most situations this will naturally be the case anyway.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not needed in the BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 39

ERR003734

ERR003734 ARM: 752519—An imprecise abort may be reported twice on

non-cacheable reads

Description:

When two outstanding read memory requests to device or non-cacheable normal memory regions are issued by the Cortex-A9, and the first one receives an imprecise external abort, then the second access might falsely report an imprecise external abort.

Conditions:

The erratum can only happen in systems which can generate imprecise external aborts on device or non-cacheable normal memory regions accesses.

Projected Impact:

When the erratum occurs, a second, spurious imprecise abort might be reported to the core when it should not.

In practice, the failure is not expected to cause any significant issues to the system because imprecise aborts are usually unrecoverable failures. Because the spurious abort can only happen following a first imprecise abort—either the first abort is ignored and the spurious abort is then ignored too, or it is acknowledged and probably generates a critical failure in the system.

Workarounds:

There is no practical software workaround for the failure.

Proposed Solution:

No fix scheduled

Linux BSP Status:

No software workaround can be implemented to mask or workaround this SoC issue. This erratum will result in impacted or reduced functionality as described above.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

40 NXP Semiconductors

ERR003735

ERR003735 ARM: 754323—Repeated Store in the same cache line may delay the

visibility of the Store

Description:

The Cortex-A9 implements a small counter that ensures the external visibility of all stores in a finite amount of time, causing an eventual drain of the merging store buffer. This is to avoid an earlier issue, where written data could potentially remain indefinitely in the Store Buffer.

This store buffer has merging capabilities, and will continue merging data as long as the write accesses are performed in the same cache line. The issue that causes this erratum is that the draining counter is reset each time a new data merging is performed.

When a code sequence is looping, and keeps on writing data in the same cache line, then the external visibility of the written data might not be ensured.

A livelock situation might consequently occur in case any external agent is relying on the visibility of the written data, and that the writing processor cannot be interrupted while doing its writing loop.

Conditions:

The erratum can only happen on normal memory regions. Two example scenario, which might trigger the erratum, are described below:

• The processor keeps on incrementing a counter: writing the same word at the same address. The

external agent (possibly another processor) is polling on this address, waiting for any update of the counter value to proceed. The store buffer will keep on merging the updated value of the counter in its cache line, so that the external agent will never see any updated value, possibly leading to livelock.

• The processor writes a value in a given word to indicate completion of its task, then keeps on

writing data in an adjacent word in the same cache line. The external agent keeps on polling the first word memory location to check when the processor has completed its task. The situation is the same as above, as the cache line might remain indefinitely in the merging store buffer, creating a possible livelock in the system.

Projected Impact:

This erratum might create performance issues, or worst case livelock scenario, in case the external agent relies on the automatic visibility of the written data in a finite amount of time.

Workarounds:

The recommended workaround for this erratum involves inserting a DMB operation after the faulty write operation in code sequences that might be affected by this erratum. This ensures visibility of the written data by any external agent.

Proposed Solution:

No fix scheduled

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 41

ERR003735

Linux BSP Status:

Software workaround is not needed because this erratum will not be encountered in normal device operation. However, the ARM Linux kernel common code has added the necessary DMB in places to ensure the visibility of the written data to any external agent.The workaround for this erratum is to insert a DMB operation after the faulty write operation in code sequences that this erratum might affect, to ensure the visibility of the written data to any external agent. The BSP does use DMBs however the specific condition or scenario is not seen in kernel code.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

42 NXP Semiconductors

ERR003736

ERR003736 ARM: 756421—Sticky Pipeline Advance bit cannot be cleared from

debug APB accesses

Description:

The Sticky Pipeline Advance bit is bit[25] of the DBGDSCR register . This bit enables the debugger to detect whether the processor is idle. This bit is set to 1 every time the processor pipeline retires one instruction.

A write to DBGDRCR[3] clears this bit. The erratum is that the Cortex-A9 does not implement any debug APB access to DBGDRCR[3].

Projected Impact:

Due to the erratum, the Sticky Pipeline Advance bit in the DBGDSCR cannot be cleared by the external debugger. In practice, this makes the Sticky Pipeline Advance bit concept unusable on Cortex-A9 processors.

Workarounds:

There is no practical workaround for this erratum. The only possible way to reset the Sticky Pipeline Advance bit is to assert the nDBGRESET input pin on the processor. This obviously has the side effect to reset all debug resources in the concerned processor, and any other additional Coresight components nDBGRESET is connected to.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not implemented because this erratum will never be encountered in normal device operation.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 43

ERR003737

ERR003737 ARM: 757119—Some “Unallocated memory hint” instructions

generate an UNDEFINED exception instead of being treated as NOP

Description:

The ARM architecture specifies that ARM opcodes of the form 11110 100x001 xxxx xxxx xxxx xxxx xxxx are “Unallocated memory hint (treat as NOP)” if the core supports the MP extensions, as the Cortex-A9 does.

The errata is that the Cortex-A9 generates an UNDEFINED exception when bits [15:12] of the instruction encoding are different from 4’b1111, instead of treating the instruction as a NOP.

Projected Impact:

Due to the erratum, an unexpected UNDEFINED exception might be generated. In practice, this erratum is not expected to cause any significant issue, as such instruction encodings are not supposed to be generated by any compiler, nor used by any handcrafted program.

Workarounds:

A possible workaround for this erratum is to modify the instruction encoding with bits[15:12]=4.b1111, so that the instruction is truly treated as a NOP by the Cortex-A9.

If the instruction encoding cannot be modified, the UNDEFINED exception handler has to cope with this case, and emulate the expected behavior of the instruction, that is, do nothing (NOP), before returning to normal program execution.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. Software workaround not applicable to the BSP as instruction encodings are not generated by compiler.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

44 NXP Semiconductors

ERR003738

ERR003738 ARM/MP: 751475—Parity error may not be reported on full cache line

access (eviction / coherent data transfer / cp15 clean operations)

Description:

In the Data cache, parity error detection is faulty . Parity error may not be not detected when the line exits from the Data cache, due to a line replacement, or due to a coherent request from another processor or from the ACP, or because of a CP15 cache clean operation.

Projected Impact:

Due to the erratum, a corrupted line may be evicted or transferred from the processor without the parity error being detected and reported.

Workarounds:

There is no workaround for this erratum.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. Parity is not supported on i.MX 6 series. See erratum ERR005187 regarding the BSP interaction with the parity interrupt.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 45

ERR003739

ERR003739 ARM: 751470—Imprecise abort on the last data of a cache linefill may

not be detected

Description:

Data linefills are returned as 4-beat bursts of 64-bit data on the AXI bus. When the first three beat of data are valid, and the fourth one aborts, then the abort is not detected by the processor logic and no abort exception is taken. The processor then behaves as if no abort is reported on the line. It can allocate the line in its Data Cache, and use the aborted data during its program flow.

Conditions:

The processor needs to work with Data Cache enabled, and access some cacheable memory regions (Write Back, either Shared or Non-Shared).

The memory system underneath the processor needs to be able to generate aborts in this memory region, and must be able to generate aborts with a granularity smaller than the cache line.

Projected Impact:

When the erratum triggers, the processor does not detect the abort, so it might use some invalid (aborted) data without entering the Data Abort exception handler as it should normally do.

Workarounds:

None

Proposed Solution:

No fix scheduled

Linux BSP Status:

W orkaround possible but not implemented in the BSP, impacting functionality as described above.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

46 NXP Semiconductors

ERR003740 ARM/PL310: 752271—Double linefill feature can cause data

corruption [i.MX 6Dual/6Quad only]

Description:

The double linefill feature is controlled by bit 30 of the Prefetch Control Register. The L2C-310 cache line length is 32-byte. Therefore, by default, on each L2 cache miss, L2C-310 issues 32-byte linefills, 4 x 64-bit read bursts, to the L3 memory system. L2C-310 can issue 64-byte linefills (double linefills), 8 x 64-bit read bursts, on an L2 cache miss. When the L2C-310 is waiting for the data from L3, it performs a lookup on the second cache line targeted by the 64-byte linefill. When it misses in the L2 cache, it identifies a victim for future allocation. If such a victim already contains a dirty entry, the latter must be evicted before the second part of the double linefill is allocated. For this purpose, the double linefill slot issues a request to the Eviction Buffer. Due to this erratum, such an eviction request can be missed, leading to the loss of dirty data in the L2 cache.

Conditions:

This problem occurs when the following conditions are met:

• The double linefill feature is enabled.

• The L2 cache contains dirty data.

ERR003740

Projected Impact:

When the conditions above are met and under very rare circumstances depending on the microarchitecture of L2C-310, the request/ack scheme existing between the Eviction Buffer and second parts of double linefill slots can go out of sync. As a result, the second part of a double linefill slot can get allocated into the L2 cache without waiting for the eviction of its victim. Dirty data are then lost, leading to data corruption.

Workarounds:

The only workaround to this erratum is to disable the double linefill feature. This is the behavior by default.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround which disables the double linefill feature is integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 47

ERR003741

ERR003741 ARM/PL310: 729815—The “High Priority for SO and Dev reads”

feature can cause Quality of Service issues to cacheable read transactions

Description:

The “High Priority for SO and Dev reads” feature can be enabled by setting the bit[10] of the PL310 Auxiliary Control Register to 1. When enabled, it gives priority to Strongly Ordered and Device reads over cacheable reads in the PL310 AXI master interfaces. When PL310 receives a continuous flow of SO or Device reads, this can prevent cacheable reads, which are misses in the L2 cache, from being issued to the L3 memory system.

Conditions:

The erratum occurs when the following conditions are met:

• The bit[10] “High Priority for SO and Dev reads enable” of the PL310 Auxiliary Control

• PL310 receives a cacheable read that is a miss in the L2 cache

• PL310 receives a continuous flow of SO or Device reads that take all address slots in the master

interface

Projected Impact:

When the above conditions are met, the linefill resulting from the L2 cache miss is not issued till the flow of SO/Device reads stops. Note that each PL310 master interface has four address slots, so that the Quality of Service issue only appears on the cacheable read, if the L1 is able to issue at least four outstanding SO/Device reads.

Workarounds:

A workaround is only necessary in systems that are able to issue a continuous flow of SO or Device reads. In such a case, the workaround is to disable the “High Priority for SO and Dev reads” feature. This is the behavior by default.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. The bit[10] “High Priority for SO and Dev reads enable” of the PL310 Auxiliary Control Register is not enabled in the BSP.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

48 NXP Semiconductors

ERR003743 ARM/PL310: 754670—A continuous write flow can stall a read

targeting the same memory area

Description:

In the ARM L2 cache controller, PL310, hazard checking is done on bits [31:5] of the address. When a read with Normal Memory (cacheable or not) attributes is received by PL310, hazard

checking is performed with the active writes of the store buffer . If an addre ss matching is detected, the read is stalled till the write completes.

Due to this erratum, a continuous flow of writes can stall a read targeting the same memory area.

Conditions:

The erratum occurs when the following conditions are met:

• PL310 receives a continuous write traffic targeting the same address marked with Normal

Memory attributes

• While treating this flow, PL310 receives a read targeting the same 32-byte memory area

Projected Impact:

ERR003743

When the conditions above are met, the read might be stalled till the write flow stops. Note that this erratum does not lead to any data corruption. Note also that normal software code is not expected to contain long write sequence like the one

causing this erratum to occur.

Workarounds:

There is no workaround for this erratum. A workaround is not expected to be necessary for this erratum either.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 49

ERR004324

ERR004324 ARM/MP: 761319—Ordering of read accesses to the same memory

location may not be ensured

Description:

The ARM architecture, and general rules of coherency , requires reads to the same memory location to be observed in order.

Due to some internal replay path mechanisms, the Cortex-A9 can see a read access bypassed by a following read access to the same memory location, thus not observing the values in program order .

Conditions:

It can only happen on memory regions marked as Normal Memory Write-Back Shared.

Projected Impact:

The erratum leads to data coherency failure.

Workarounds:

The vast majority of multi-processing code is not written in a style which exposes the erratum. So, the erratum is expected to affect very specific areas of code which rely on this read ordering behavior.

A first workaround for this erratum consists in using LDREX instead of standard LDR in volatile memory places where a strict read ordering is required.

An alternative solution consists in inserting a DMB between the affected LDR which requires this strict ordering rule. This is the recommended workaround for tool chains integration.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not implemented because this erratum will never be encountered in normal device operation. Users should ensure their tool chain has the recommended workaround. For more information about integrating the workaround inside tool chains, please refer to the Programmer Advice Notice related to this erratum, ARM UAN 0004A.

(http://infocenter.arm.com/help/topic/com.arm.doc.uan0004a/UAN0004A_a9_read_read.pdf)

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

50 NXP Semiconductors

ERR004325

ERR004325 ARM/MP: 764369—Data or unified cache line maintenance operation

by MVA may not succeed on an Inner Shareable memory region

Description:

Under certain timing circumstances, a data or unified cache line maintenance operation by MVA targeting an Inner Shareable memory region might fail to proceed up to either the Point of Coherency or to the Point of Unification of the system. This is likely to affect self modifying code.

Conditions:

The erratum requires a Cortex-A9 MPCore configuration with two processors or more, working in SMP mode, with the broadcasting of CP15 maintenance operations enabled.

The following scenario illustrates how the erratum can happen:

• One CPU performs a data or unified cache line maintenance operation by MVA targeting a

memory region that is locally dirty.

• A second CPU issues a memory request targeting this same memory location within the same

time frame.

A race condition might occur, resulting in the cache operation not being performed up to the specified Point, either Coherency or Unification.

The following maintenance operations are affected:

• DCIMVAC: Invalidate data or unified cache line by MVA to PoC

• DCCMVAC: Clean data or unified cache line by MVA to PoC

• DCCMVAU: Clean data or unified cache line by MVA to PoU

• DCCIMVAC: Clean and invalidate data or unified cache line by MVA to PoC

The erratum might arise when the second CPU is performing either of:

• A read request resulting from any Load instruction; the Load can be a speculative one.

• A write request resulting from any Store instruction.

• A data prefetch resulting from a PLD instruction; the PLD might be a speculative one.

Projected Impact:

Since the cache maintenance operation is not ensured to be executed to either the Point of Unification or the Point of Coherence, stale data might remain in the data cache, and not become visible to other cache agents who should have gained visibility on it.

As such, self modifying code might fail, the new code sequence written into the Data Cache not having been made visible to the Instruction Cache.

Note that the data remains coherent on the L1 Data side. Any data read from another processor in the Cortex-A9 MPCore cluster, or from the ACP, would see the correct data. Identically , any write from another processor in the Cortex-A9 MPCore cluster, or from the ACP, on the same cache line, will not cause a data corruption resulting from a loss of either data.

Note that false sharing on a memory region used for self modifying code is extremely unlikely to exist. As such, the write operation targeting the same cache line than the cache operation occurring

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 51

ERR004325

within the timing window , required to trigger this erratum, might not represent a real case. So, the erratum trigger in the case of self modifying code is probably restricted to read operations, being the consequence of either a speculative load, or a “blind” PLD instruction.

In addition, production of data to an agent external from the coherency domain might fail; particularly, the data target of the cache maintenance operation might not have been made visible to an external DMA engine when it completes. Again, false sharing on a memory region also accessed by an external agent, like a DMA engine, is extremely unlikely to exist. As such, the erratum trigger, when producing data for an external DMA agent, is probably restricted to read operations, being the consequence of either a speculative load, or a “blind” PLD instruction.

Workarounds:

To work around this erratum, ARM recommends to:

• Ensure there is no false sharing (on a cache line size alignment) for both self modifying code

and data to be cleaned to an external agent, like a DMA engine.

• Set bit[0] in the undocumented SCU diagnostic control register located at offset 0x30 from the

PERIPHBASE address. Setting this bit disables the “migratory bit” feature. This forces a dirty cache line to be evicted to the lower memory subsystem—which is both the point of coherency and the point of unification—when it is being read by another processor. Note that this bit can be written, but is always Read as Zero.

• Insert a DSB instruction in front of the cache maintenance operation. Note that if the cache

maintenance operation is executed within a loop with no other memory operations, ARM only recommends adding a DSB prior to entering the loop.

Note that the atomicity between the DSB and the cache maintenance operation might not be ensured because an interrupt may still be taken between the two instructions. However , setting the “disable migratory line” bit and inserting the DSB in front of the cache maintenance operation will very significantly decrease the probability to trigger the erratum when false sharing for writes to either self-modifying code memory regions or DMA regions, on a cache line granularity , which is likely to be the case.

With these workarounds, the likely occurrence of this erratum is sufficiently low that the erratum does not limit or severely impair the intended use of specified features.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

52 NXP Semiconductors

ERR004326

ERR004326 ARM/MP: 761321—MRC and MCR are not counted in event 0x68

Description:

Event 0x68 counts the total number of instructions passing through the Register rename pipeline stage. The erratum is that MRC and MCR instructions are not counted in this event.

The event is also reported externally on PMUEVENT[9:8], which suffers from the same defect.

Projected Impact:

The implication of this erratum is that the values of event 0x68 and PMUEVENT[9:8] are imprecise, omitting the number of MCR and MRC instructions. The inaccuracy of the total count depends on the rate of MRC and MCR instructions in the code.

Workarounds:

No workaround is possible to achieve the required functionality of counting how many instructions are precisely passing through the register rename pipeline stage, when the code contains some MRC or MCR instructions.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.The Freescale Linux BSP does not support this optional profiling feature. Users may add support for this profiling feature as required, but should ensure the multiple errata impacting the ARM PMU (Performance Monitoring Unit) are considered especially for multi-core usage

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 53

ERR004327

ERR004327 ARM/MP: 764319—Read accesses to DBGPRSR and DBGOSLSR may

generate an unexpected UNDEF

Description:

CP14 read accesses to the DBGPRSR and DBGOSLSR registers generate an unexpected UNDEFINED exception when the DBGSWENABLE external pin is set to 0, even when the CP14 accesses are performed from a privileged mode.

Projected Impact:

Due to the erratum, the DBGPRSR and DBGOSLSR registers are not accessible when DBGSWENABLE=0.

This is, however, not expected to cause any significant issue in Cortex-A 9 based systems because these accesses are mainly intended to be used as part of debug over power-down sequences, which is not a feature supported by the Cortex-A9.

Workarounds:

The workaround for this erratum consists in temporarily setting the DBGSWENABLE bit to 1 so that the DBGPRSR and DBGOSLSR registers can be accessed as expected.

There is no other workaround for this erratum.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not implemented because this erratum will never be encountered in normal device operation. Users that require this debug feature should implement the recommended ARM workaround.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

54 NXP Semiconductors

ERR005175

ERR005175 ARM/MP: 771221—PLD instructions may allocate data in the Data

Cache regardless of the Cache Enable bit value

Description:

Preload Data (PLD) instructions prefetch and allocate any data marked as Write-Back (either Write-Allocate or Non-Write-Allocate, Shared or Non-Shared), regardless of the processor configuration settings, including the Data Cache Enable bit value.

Projected Impact:

Due to this erratum, unexpected memory cacheability aliasing is created which might result in various data consistency issues.

In practice, this erratum is not expected to cause any significant issue. The Data Cache is expected to be enabled as soon as possible in most systems, and not dynamically modified. So, only boot-up code would possibly be impacted by this erratum, but such code is usually carefully controlled and not expected to contain any PLD instruction while Data Cache is not enabled.

Workarounds:

In the case where a system is impacted by this erratum, a software workaround is available which consists in setting bit [20] in the undocumented Control register, which is placed in CP15 c15 0 c0

This bit needs to be written with the following Read/Modify/Write code sequence: MRC p15,0,r0,c15,c0,1 ORR r0,r0,#0x00100000 MCR p15,0,r0,c15,c0,1 Setting this bit causes all PLD instructions to be treated as NOPs, with the consequence that code

sequences usually using the PLDs, such as the memcpy() routine, might suffer from a visible performance drop. So, if this workaround is applied, ARM strongly recommends restricting its usage to periods of time where the Data Cache is disabled.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. The BSP does not dynamically enable/disable data cache during run-time and thus avoids the PLD instruction with the data cache off.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 55

ERR005183

ERR005183 ARM/MP: 771224—Visibility of Debug Enable access rights to

enable/disable tracing is not ensured by an ISB

Description:

According to the ARM architecture, any change in the Authentication Status Register should be made visible to the processor after an exception entry or return, or an ISB.

Although this is correctly achieved for all debug-related features, the ISB is not sufficient to make the changes visible to the trace flow . As a consequence, the WP TTRACEPROHIBITEDn signal(s) remain stuck to their old value up to the next exception entry or return, or to the next serial branch, even when an ISB is executed.

A serial branch is one of the following:

• Data processing to PC with the S bit set (for example, MOVS pc, r14)

• LDM pc ^

Projected Impact:

Due to the erratum, the trace flow might not start or stop, as expected by the program.

Workarounds:

To work around the erratum, the ISB must be replaced by one of the events causing the change to be visible. In particular, replacing the ISB by a MOVS PC to the next instruction will achieve the correct functionality.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not implemented because this erratum will never be encountered in normal device operation. Users should use ARM recommended workaround if using this debug trace feature.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

56 NXP Semiconductors

ERR005185

ERR005185 ARM/MP: 771225—Speculative cacheable reads to aborting memory

region clear the internal exclusive monitor, may lead to livelock

Description:

On Cortex-A9, when a cacheable read receives an external abort, the aborted line is allocated as invalid in the Data Cache, and any allocation in the Data Cache clears the internal exclusive monitor.

So, if a program executes a LDREX/STREX loop which keeps on receiving an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds, leading to a possible processor livelock.

As an example, the following code sequence might exhibit the erratum: loop LDREX ... DSB STREX CMP BNE loop

....

LDR (into aborting region) The LDREX/STREX does not succeed on the first pass of the loop, and the BNE is mispredicted,

so, the LDR afterwards is speculatively executed. So, the processor keeps on executing: LDR to aborting region (this speculative LDR now appears “before” the LDREX and DSB) LDREX DSB STREX The LDR misses in L1, and never gets allocated as valid because it is aborting The LDREX is executed, and sets the exclusive monitor The DSB is executed. It waits for the LDR to complete, which aborts, causing an allocation (as

invalid) in the Data Cache, which clears the exclusive monitor The STREX is executed, but the exclusive monitor is now cleared, so the STREX fails The BNE might be mispredicted again, so the LDR is speculatively executed again, and the code

loops back on the same failing LDREX/STREX sequence.

Conditions:

The erratum happens in systems which might generate external aborts in answer to cacheable memory requests.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 57

ERR005185

Projected Impact:

If the program reaches a stable state where the internal exclusive monitor keeps on being cleared in the middle of the LDREX/STREX sequence, then the processor might encounter a livelock situation.

In practice, this scenario seems very unlikely to happen because several conditions might prevent the erratum from happening:

• Usual LDREX/STREX code sequences do not contain any DSB, so that it is very unlikely that

the system would return the abort answer precisely in the middle of the LDREX/STREX sequence on each iteration.

• Some external irritators (for example, interrupts) might happen and cause timing changes which

might exit the processor from its livelock situation.

• Branch prediction is very usually enabled, so the final branch in the loop will usually be

correctly predicted after a few iterations of the loop, preventing the speculative LDR to be issued, so that the next iteration of the LDREX/STREX sequence will succeed.

Workarounds:

The following two workarounds are available for this erratum:

• Turn on the branch prediction.

• Remove the DSB in the middle of the LDREX/STREX sequence. If a DSB is truly required, it

is strongly recommended to place it before the LDREX/STREX sequence, and implement the LDREX/STREX sequence as recommended by the ARM architecture.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround implemented in Linux BSP codebase in all releases. Software workaround is to enable branch prediction which is enabled by default in the BSP GA release.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

58 NXP Semiconductors

ERR005187

ERR005187 ARM/MP: 771223—Parity errors on BTAC and GHB are reported on

PARITYFAIL[7:6], regardless of the Parity Enable bit value

Description:

PARITYFAIL signal bits [7] and [6] are expected to report parity errors occurring on the BTAC and GHB RAMs, when the parity error detection logic is enabled (ACTLR[9]=1’b1).

The erratum is that the Parity Enable bit, ACTLR[9], is not taken into account by the logic driving PARITYFAIL[7:6]. As a consequence, any parity error on the BTAC or GHB RAM will be reported on PARITYFAIL[7] or [6], even when parity error detection is not enabled.

Conditions:

The erratum happens on all configurations that have implemented parity support on the BTAC or GHB RAMs when dynamic branch prediction is enabled (SCTLR[11]=1’b1).

Projected Impact:

Due to the erratum, unexpected parity errors might be reported when parity is not enabled, if any parity error happens on the BTAC or GHB RAMs.

Note that implementing parity error detection is not mandatory on the BTAC and GHB RAMs because such errors might cause a branch mispredict, but no functional failure.

In systems which are implementing parity error detection on the BTAC and GHB RAMs, the erratum is not expected to cause any significant issue because parity is likely to be enabled very soon in the boot process.

Workarounds:

Because parity errors on the BTAC and GHB RAMs are not reported when the dynamic branch prediction is not enabled, the workaround consists in enabling parity error detection (ACTLR[9]), prior to enabling dynamic branch prediction (SCTLR[11]).

In systems where branch prediction is enabled while parity error detection remains disabled, the workaround consists in ignoring any assertion on the PARITYFAIL[7:6] bits.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not needed in the BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. BSP ignores any assertion on the PARITYFAIL[7:6] bits by masking the ARM -GIC parity interrupt 125.

Please note that the i.MX6 does not support the parity feature and hence should not be enabled.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 59

ERR005198

ERR005198 ARM/PL310: 780370—DATAERR, TAGERR, and Tag parity errors are

incorrectly sampled by the eviction buffer, leading to data corruption

Description:

The PL310 L2 cache controller implements error logic to indicate errors have occurred when accessing the L2 cache RAM array. The following error information is available when accessing the RAM array:

• DATAERR (or DATAERR[3:0] if data banking is implemented) from Data RAM

• TAGERR[7:0] (or TAGERR[15:0] if 16 ways are implemented) from Tag RAM

• Parity error on Tag or Data RAM if parity is implemented

This information is associated with each individual RAM access, and is only meant to be sampled by the PL310 internal access requestor at precise cycles, depending on the programmable latencies of the accessed RAM (see Technical Reference Manual (TRM) for more information on RAM latencies).

More specifically, when an eviction is handled by the PL310 eviction buffer, both Tag and Data RAMs are accessed to get the whole eviction information. When either DATAERR or TAGERR is asserted high, or a tag parity error is detected during that process, the error information is captured by the eviction buffer, which cancels the corresponding eviction as a result.

Due to this erratum, the eviction buffer can incorrectly sample error information. As a result, an eviction can be wrongly cancelled and dirty data can be lost, leading to data corruption.

Note that data parity error is not part of this erratum. The reason is that this type of error information is not taken into account by the eviction buffer. This means that an eviction is always sent to the L3 memory system, regardless of whether a Data parity error has been detected or not, when accessing its data in the L2 cache.

Conditions:

The erratum occurs when the following conditions are met:

• The L2 cache contains dirty cache lines

• The eviction buffer accesses Tag and Data RAMs to get dirty cache line information before

replacement

• While the eviction buffer accesses the RAMs, a tag parity error is detected, or DATAERR or

TAGERR are asserted HIGH, but this error information is not meant to be captured by the eviction buffer (it may be directed to another PL310 block or DATAERR may be transiently asserted high before the end of the Data RAM latency period)

• The eviction buffer incorrectly samples the error information and cancels the corresponding

eviction

Projected Impact:

When the above conditions are met, dirty data can be lost, leading to data corruption.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

60 NXP Semiconductors

ERR005198

The implications of this data corruption depend on the error information and the PL310 configuration. All cases listed below need to be carefully assessed to know the exact impact of the erratum on a particular system.

DATAERR In a system where DATAERR is tied low, this erratum does not apply as far as DATAERR is

concerned. In a system not implementing banking on the Data RAM and not driving DATAERR constantly

low , the eviction buf fer can sample transient and unstable high values of DAT AERR, even if there is actually no expected error reported to PL310. This case is the most serious consequence of this erratum because it leads to a silent data corruption without any actual data error.

In a system using DATAERR for indicating Data RAM error and implementing banking on the Data RAM, the eviction buffer can only sample a true error coming from the Data RAM. However , this error may actually target another PL310 sub-block or another eviction slot. The erratum can thus still lead to data corruption, but the latter must be put in perspective relative to the true data error the overall system is facing. This is up to the system to assess how serious the data corruption is compared to the RAM error.

TAGERR In a system where TAGERR is tied low, this erratum does not apply as far as TAGERR is

concerned. In a system using TAGERR for indicating Tag RAM error , the eviction buffer can only sample a

true error coming from the Tag RAM. However, this error may actually target another PL310 sub-block or another eviction slot. The erratum can thus still lead to data corruption, but the latter must be put in perspective relative to the true tag error the overall system is facing. This is up to the system to assess how serious the data corruption is compared to the RAM error.

Tag parity error In a system not implementing parity configuration in PL310, this erratum does not apply as far as

the tag parity error is concerned. In a system implementing parity , the eviction buffer can only sample a true tag parity error detected

by the PL310 parity logic. However, this error may actually target another PL310 sub-block or another eviction slot. The erratum can thus still lead to a data corruption, but the latter must be put in perspective relative to the true parity error the overall system is facing. This is up to the system to assess how serious the data corruption is compared to the error.

Workarounds:

The following two software workarounds are available for systems affected by this erratum:

• Use write-through memory attributes for all cacheable accesses targeting PL310.

• Disable the logic responsible for generating RAM errors. This can imply disabling parity in

PL310 and/or disabling DATAERR and TAGERR generation in the RAM array, depending on the implementation.

Proposed Solution:

No fix scheduled

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 61

ERR005198

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. The erratum only affects configurations which implement the parity support option. i.MX6 parity is not supported. In the Freescale Linux implementation, the parity error detection is disabled and GIC parity interrupt 125, is masked in the BSP. The parity feature is disabled by default and should not be enabled.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

62 NXP Semiconductors

ERR005199 ARM/MP: 769419—No automatic Store Buffer drain, visibility of

written data requires an explicit Cache Sync operation [i.MX 6Dual/6Quad Only]

Description:

The PL310 Store Buffer does not have any automatic draining mechanism. Any written data might consequently remain in this buffer , invisible to the rest of the system. In case an L3 external agent keeps on polling this memory location, waiting to see the update of the written data to make any further progress, then a system livelock might happen.

Conditions:

The erratum can only happen on Normal Memory regions. The following scenario is an example which can exhibit the erratum, where an L3 agent might loop infinitely waiting for the notification from CPU for an unbounded amount of time:

• An L3 agent is waiting for notification from CPU before making progress.

• CPU attached to PL310 issues such notification via a write access, which stays in PL310 store

buffer.

• No additional activity forcing the store buffer to drain is received by PL310.

ERR005199

Projected Impact:

Due to the erratum, a livelock situation might be encountered in the system.

Workarounds:

If a write access needs to be made visible to an L3 external agent, the workaround for this erratum consists of using a Cache Sync operation in order to force the PL310 Store Buffer to drain. This is illustrated in the following pseudo-code sequence:

STR // to be made visible to L3 DSB CACHE_SYNC. In r3p2, a counter is implemented so that slots are automatically drained after 256 cycles of

presence in the store buffer. The i.MX 6Dual/6Quad has PL310-BU-00000-r3p1-50rel0.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 63

ERR005200

ERR005200 ARM/MP: 765569—Prefetcher can cross 4 KB boundary if offset is

programmed with value 23

Description:

When prefetch feature is enabled (bits [29:28] of the Auxiliary or Prefetch Control Register set HIGH), the prefetch offset bits of the Prefetch Control Register (bits [4:0]) permits to configure the advance taken by the prefetcher compared to the current cache line. Refer to the TRM for more information. One requirement for the prefetcher is not to go beyond a 4 KB boundary. If the prefetch offset is set to 23 (5'b101 1 1), this requirement is not fulfilled and the prefetcher can cross a 4 KB boundary.

This problem occurs when the following conditions are met:

1. One of the Prefetch Enable bits (bits [29:28] of the Auxiliary or Prefetch Control Register) is set HIGH.

2. The prefetch offset bits are programmed with value 23 (5'b10111).

Projected Impact:

When the conditions above are met, the prefetcher can issue linefills beyond a 4 KB boundary compared to original transaction. This can cause system issues because those linefills can target a new 4 KB page of memory space, regardless of page attribute settings in L1 MMU.

Workarounds:

A workaround for this erratum is to program the prefetch offset with any value except 23.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0. BSP software workaround sets prefetch offset to 0 or 15 to avoid this erratum.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

64 NXP Semiconductors

ERR005382

ERR005382 ARM/MP: 775419—PMU event 0x0A (exception return) might count

twice the LDM PC ^ instructions with base address register write-back

Description:

The LDM PC ^ instructions with base address register write-back might be counted twice in the PMU event 0x0A, which is counting the number of exception returns.

The associated PMUEVENT[11] signal is also affected by this erratum, and might be asserted twice by a single LDM PC ^ instruction with base address register write-back.

Projected Impact:

Due to the erratum, the count of exception returns is imprecise. The error rate depends on the ratio between exception returns of the form LDM PC ^ with base address register write-back and the total number of exceptions returns.

Workarounds:

There is no workaround to this erratum.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 65

ERR005383

ERR005383 ARM/MP: 775420—A data cache maintenance operation that aborts,

followed by an ISB and without any DSB in-between, might lead to deadlock

Description:

Under certain micro-architectural circumstances, a data cache maintenance operation that aborts, followed by an ISB and with no DSB occurring between these events, might lead to processor deadlock.

Conditions:

The erratum occurs when the following conditions are met:

• Some write operations are handled by the processor, and take a long time to complete. The

typical situation is when the write operation (STR, STM, …) has missed in the L1 Data Cache.

• No memory barrier (DMB or DSB) is inserted between the write operation and the data cache

maintenance operation mentioned in condition 3.

• A data cache maintenance operation is performed, which aborts due to its MMU settings.

• No memory barrier (DMB or DSB) is inserted between the data cache maintenance operation

in previous condition and the ISB in next condition. Any other kind of code can be executed here, starting with the abort exception handler, following the aborted cache maintenance operation.

• An ISB instruction is executed by the processor.

• No memory barrier (DMB or DSB) is inserted between the ISB in previous condition and the

read or write operation in next condition.

• A read or write operation is executed.

With the above conditions, an internal “Data Side drain request” signal might remain sticky, causing the ISB to wait for the Data Side to be empty, which never happens because the last read or write operation waits for the ISB to complete.

Projected Impact:

The erratum can lead to processor deadlock.

Workarounds:

A simple workaround for this erratum is to add a DSB at the beginning of the abort exception handler.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround, adding a DSB at the beginning of the abort exception handler) is integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

66 NXP Semiconductors

ERR005385

ERR005385 ARM/MP: 782772—A speculative execution of a Load-Exclusive or

Store-Exclusive instruction after a write to Strongly Ordered memory might deadlock the processor

Description:

Under certain timing circumstances, a processor might deadlock when the execution of a write to a Strongly Ordered memory region is followed by the speculative execution of a Load-Exclusive or a Store-Exclusive instruction that is mis-speculated.

The mis-speculation can be due to either the Load-Exclusive or S tore-Exclusive instruction being conditional, and failing its condition code check, or to the Load-Exclusive or Store-Exclusive instruction being speculatively executed in the shadow of a mispredicted branch.

Conditions:

The erratum requires the following conditions:

— The processor executes a write instruction to a Strongly Ordered memory region — The processor speculatively executes a Load-Exclusive or Store-Exclusive instruction that

is either: a) A conditional instruction b) An instruction in the shadow of a conditional branch.

— The Load-Exclusive or Store-Exclusive instruction is cancelled because the speculation

was incorrect, because either: a) The conditional Load-Exclusive or Store-Exclusive instruction failed its condition-code

check b) The conditional branch was mispredicted, so that all subsequent instructions speculatively

executed must be flushed, including the Load-Exclusive or Store-Exclusive.

The erratum also requires additional timing conditions to be met. These are specific to each platform, and are not controllable by software. These timing conditions includes the fact that the response to the Strongly Ordered write from the external memory system must be received at the same time as the mis-speculation is identified in the processor.

Projected Impact:

The erratum causes processor deadlock.

Workarounds:

The recommended workaround is to place a DMB instruction before each Load-Exclusive / Store-Exclusive loop sequence, to ensure that no pending write request can interfere with the execution of the Load-Exclusive or Store-Exclusive instructions. The implementation of this workaround can be restricted to code regions which have access to Strongly Ordered memory.

Proposed Solution:

No fix scheduled

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 67

ERR005385

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. There are some cases where Linux ends up with Strongly Ordered memory (MT_UNCACHED or pgprot_noncached). Freescale has checked that these are not used in the BSP. Users should check their application and OS to see if errata conditions met and apply recommended ARM work around if applicable.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

68 NXP Semiconductors

ERR005386 ARM/MP: 782773—Updating a translation entry to move a page

mapping might erroneously cause an unexpected translation fault

Description:

Under certain conditions specific to the Cortex-A9 micro-architecture, a write operation that updates a Cacheable translation table entry might cause both the old and the new translation entry to be temporarily invisible to translation table walks, thus erroneously causing a translation fault.

Conditions:

The erratum occurs when the following conditions are met:

• The processor has its Data Cache and MMU enabled.

• The TTB registers are set to work on Cacheable descriptors memory regions.

• The processor is updating an existing Cacheable translation table entry , and this write operation hits in the L1 Data Cache.

• A hardware translation table walk is attempted. The hardware translation table walk can be either due to an Instruction fetch, or due to any other instruction execution that requires an address translation, including any load or store operation. This hardware translation walk must attempt to access the entry being updated in condition 2, and that access must hit in the L1 Data Cache.

ERR005386

In practice, this scenario can happen when an operating system (OS) is changing the mapping of a physical page. The OS might have an existing mapping to a physical page (the old mapping), but wants to move the mapping to a new page (the new mapping). To do this, the OS might:

1. W rite a new translation entry, without cancelling the old one. At this point the physical page is

accessible using either the old mapping or the new mapping.

2. Execute a DSB instruction followed by an ISB instruction pair, to ensure that the new

translation entry is fully visible.

3. Remove the old entry.

Due to the erratum, this sequence might fail because it can happen that neither the new mapping, nor the old mapping, is visible after the new entry is written, causing a Translation fault.

Projected Impact:

The erratum causes a Translation fault.

Workarounds:

The recommended workaround is to perform a clean and invalidate operation on the cache line that contains the translation entry before updating the entry , to ensure that the write operation misses in the Data Cache. This workaround prevents the micro-architectural conditions for the erratum from happening. Interrupts must be temporarily disabled so that no interrupt can be taken between the maintenance operation and the translation entry update. This avoids the possibility of the interrupt service routine bringing the cache line back in the cache.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 69

ERR005386

Another possible workaround is to place the translation table entries in Non-Cacheable memory areas, but this workaround is likely to have a noticeable performance penalty.

Note that inserting a DSB instruction immediately after writing the new translation table entry significantly reduces the probability of hitting the erratum, but it is not a complete workaround.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Workaround possible but not implemented in the BSP, impacting functionality as described above.The Linux community has not incorporated a workaround for this erratum

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

70 NXP Semiconductors

ERR005387

ERR005387 ARM/MP: 782774—A spurious event 0x63, “STREX passed,” can be

reported on an LDREX that is preceded by a write to Strongly Ordered memory region

Description:

A write to Strongly Ordered memory region, followed by the execution of an LDREX instruction, can cause the “STREX passed” event to be signaled even if no STREX instruction is executed.

As a result, the event 0x63 count might be faulty, reporting too many “STREX passed” events. This erratum also affects the associated PMUEVENT[27] signal. This signal will report the same

spurious events.

Conditions:

The erratum occurs when the following conditions are met:

• The processor executes a write instruction to a Strongly Ordered memory region.

• The processor executes an LDREX instruction.

• No DSB instruction is executed, and there is no exception call or exception return, between the write and the STREX instructions.

Under these conditions, if the write instruction to Strongly Ordered memory region receives its acknowledge (BRESP response on AXI) while the LDREX is being executed, the erratum can happen.

Projected Impact:

The erratum leads to a faulty count of event 0x63, or incorrect signaling of PMUEVENT[27].

Workarounds:

The workaround for this erratum is to insert a DMB or DSB instruction between the write to Strongly Ordered memory region and the LDREX instruction.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 71

ERR006259

ERR006259 ARM: Debug/trace functions (PMU, PTM and ETB) are disabled with

absence of JTAG_TCK clock after POR

Description:

When JT AG_TCK is not toggling after power-on reset (POR), the ARM PMU, P TM, and ETB stay in their disabled states so various debug and trace functions are not available.

Projected Impact:

Limited debug/trace capability

Workarounds:

Provide at least 4 JTAG_TCK clock cycles following POR if the PMU, PTM and ETB functions will be used. A free-running JTAG_TCK can also be used.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

72 NXP Semiconductors

ERR007006

ERR007006 ARM/MP:794072-- Short loop including a DMB instruction might

cause a denial of service

Description:

A processor which continuously executes a short loop containing a DMB instruction might prevent a CP15 operation broadcast by another processor from making further progress, thus causing a denial of service.

The erratum requires the following conditions:

• Two or more processors are working in SMP mode (ACTLR.SMP=1)

• One of the processors continuously executes a short loop containing at least one DMB instruction.

• Another processor executes a CP15 maintenance operation that is broadcast. This requires that this processor has enabled the broadcasting of CP15 operations (ACTLR.FW=1)

For the erratum to occur, the short loop containing the DMB instruction must meet all of the following additional conditions:

• No more than 10 instructions other than the DMB are executed between each DMB

• No nonconditional Load or Store, or conditional Load or Store which pass the condition code check, are executed between each DMB

When all the conditions for the erratum are met, the short loop creates a continuous stream of DMB instructions. This might cause a denial of service, by preventing the processor executing the short loop from executing the received broadcast CP15 operation. As a result, the processor that originally executed the broadcast CP15 operation is stalled until the execution of the loop is interrupted.

Note that because the process issuing the CP15 broadcast operation cannot complete operation, it cannot enter any debug mode, and cannot take any interrupt. If the processor executing the short loop also cannot be interrupted—for example if it has disabled its interrupts—or if no interrupts are routed to this processor, this erratum might cause a system livelock.

Projected Impact:

The erratum might create performance issues, or in the worst case it might cause a system livelock, if the processor executing the DMB is in an infinite loop that cannot be interrupted.

Workarounds:

This erratum can be worked around by setting bit[4] of the undocumented Diagnostic Control register to 1. This register is encoded as CP15 c15 0 c0 1.

This bit can be written in Secure state only, with the following Read/Modify/W rite code sequence:

MRC p15,0,rt,c15,c0,1 ORR rt,rt,#0x10 MCR p15,0,rt,c15,c0,1

When it is set, this bit causes the DMB instruction to be decoded and executed like a DSB. Using this software workaround is not expected to have any impact on the overall performance of

the processor on a typical code base.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 73

ERR007006

Other workarounds are also available for this erratum, to either prevent or interrupt the continuous stream of DMB instructions that causes the deadlock. For example:

- Inserting a nonconditional Load or Store instruction in the loop between each DMB

- Inserting additional instructions in the loop, such as NOPs, to prevent the processor from seeing

back-to-back DMB instructions.

- Making the processor executing the short loop take regular interrupts.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

74 NXP Semiconductors

ERR007007 ARM/MP: 794073 -- Speculative instruction fetches with MMU

disabled might not comply with architectural requirements

Description:

When the MMU is disabled, the ARM processor must follow some architectural rules regarding speculative fetches and the addresses to which these can be initiated. These rules avoid potential read accesses to read-sensitive areas. For more information about these rules, see the description of “Behavior of instruction fetches when all associated MMUs are disabled” in the ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition.

A Cortex-A9 processor usually operates with both the MMU and branch prediction enabled. If the processor operates in this condition for any significant amount of time, the BTAC (branch target address cache) will contain branch predictions. If the MMU is then disabled, but branch prediction remains enabled, these stale BTAC entries can cause the processor to violate the rules for speculative fetches.

The erratum can occur only if the following sequence of conditions is met:

1. MMU and branch prediction are enabled.

2. Branches are executed.

3. MMU is disabled, and branch prediction remains enabled.

ERR007007

Projected Impact:

If the above conditions occur, it is possible that, after the MMU is disabled, speculative instruction fetches might occur to read-sensitive locations.

Workarounds:

The recommended workaround is to invalidate all entries in the BTAC, by executing a BPIALL operation (invalidate entire branch prediction array) followed by a DSB, before disabling the MMU.

Another possible workaround is to disable branch prediction when disabling the MMU, and keep branch prediction disabled until the MMU is re-enabled.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not needed in the BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. The BSP has the MMU enabled when it performs BTAC flush in LPM entry. When kernel is running, the MMU is kept enabled until DSM is entered and ARM core power is gated.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 75

ERR007008

ERR007008 ARM/MP: 794074 --A write request to Uncacheable Shareable memory

region might be executed twice

Description:

Under certain timing circumstances specific to the Cortex-A9 microarchitecture, a write request to an Uncacheable, Shareable, Normal memory region might be executed twice, causing the write request to be sent twice on the AXI bus. This might happen when the write request is followed by another write into the same naturally aligned doubleword memory region, without a DMB between the two writes.

The repetition of the write usually has no impact on the overall behavior of the system, unless the repeated write is used for synchronization purposes.

The erratum requires the following conditions:

• A write request is performed to an Uncacheable, Shareable, Normal memory region.

• Another write request is performed into the same naturally doubleword-aligned memory region. This second write request must not be performed to the exact same bytes as the first store.

A write request to Normal memory region is treated as Uncacheable in the following cases:

1. The write request occurs while the data cache is disabled.

2. The write request is targeti ng a memory region marked as Normal Memory Non-Cacheable or

Cacheable Write-Through.

3. The write request is targeting a memory region marked as Normal Memory Cacheable

Write-Back and Shareable, and the CPU is in AMP mode.

Projected Impact:

This erratum might have implications in a multimaster system where control information is passed between several processing elements in memory using a communication variable, for example a semaphore. In such a system, it is common for communication variables to be claimed using a Load-Exclusive/Store-Exclusive, but for the communication variable to be cleared using a non-Exclusive store. This erratum means that the clearing of such a communication variable might occur twice. This might lead to two masters apparently claiming a communication variable, and therefore might cause data corruption to shared data.

Here is a scenario in which this might happen:

MOV r1,#0x40 ; address is double-word aligned, mapped in normal noncacheable

shareable memory Loop: LDREX r5, [r1,#0x0] ; read the communication variable CMP r5, #0 ; check if 0 STREXEQ r5, r0, [r1] ; attempt to store new value CMPEQ r5, #0 ; test if store succeeded BNE Loop ; retry if not DMB ; ensures that all subsequent accesses are observed when gaining

of the communication variable has been observed

; loads and stores in the critical region can now be performed MOV r2,#0 MOV r0, #0

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

76 NXP Semiconductors

ERR007008

DMB ; ensure all previous accesses are observed before the

communication variable is cleared STR r0, [r1] ; clear the communication variable with normal store STR r2, [r1,#0x4] ; previous STR might merge and be sent again, which might cause

undesired release of the communication variable.

This scenario is valid when the communication variable is a byte, a half-word, or a word.

Workarounds:

There are several possible workarounds:

1. Add a DMB after clearing a communication variable: STR r0, [r1] ; clear the communication variable DMB ; ensure the previous STR is complete Also, any IRQ or FIQ handler must execute a DMB at the start to ensure the clearing of any

communication variable is complete.

2. Ensure there is no other data using the same naturally aligned 64-bit memory location as the communication variable:

ALIGN 64 communication_variable DCD 0 unused_data DCD 0 LDR r1,= communication_variable

3. Use a Store-Exclusive to clear the communication variable, rather than a non-Exclusive store.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. Users should confirm if the conditions apply in their specific OS and apply the ARM recommended workaround if necessary.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 77

ERR009604

ERR009604 ARM (CA9): 845369 — Under very rare timing circumstances,

transition into streaming mode might create a data corruption

Description:

Under very rare timing circumstances, a data corruption might occur on a dirty cache line that is evicted from the L1 Data Cache due to another cache line being entirely written. The erratum requires the following conditions:

• The CPU contains a dirty line in its data cache.

• The CPU performs at least four full cache line writes, one of which is causing the eviction of

the dirty line.

• Another CPU, or the ACP, is performing a read or write operation on the dirty line.

The defect requires very rare timing conditions to reach the point of failure. These timing conditions depend on the CPU micro-architecture, and are not controllable in software:

• The CPU must be in a transitional mode that might be triggered by the detection of the first two

full cache line writes.

• The evicted line must remain stalled in the eviction buffer, which is likely to be caused by a

congested write traffic.

• The other coherent agent, either another CPU in the cluster or the ACP, must perform its

coherency request on the evicted line while it is in the eviction buffer.

This erratum only occurs when two or more processors are enabled.

Projected Impact:

The erratum might lead to data corruption.

Workarounds:

This erratum can be worked round by setting bit[22] of the undocumented Diagnostic Control Register to 1. This register is encoded as CP15 c15 0 c0 1.

The bit can be written in Secure state only, with the following Read/Modify/W rite code sequence:

MRC p15,0,rt,c15,c0,1

ORR rt,rt,#0x00400000

MCR p15,0,rt,c15,c0,1

When this bit is set, the processor is unable to switch into Read-Allocate (streaming) mode, which means this erratum cannot occur.

Setting this bit could possibly result in a visible drop in performance for routines that perform intensive memory accesses, such as memset() or memcpy(). However, the workaround is not expected to create any significant performance degradation in most standard applications.

Proposed Solution:

No fix scheduled

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

78 NXP Semiconductors

Linux BSP Status:

Software workaround implemented in Linux BSP codebase starting in release imx_3.14.38_6qp_ga.

ERR009604

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 79

ERR009605

ERR009605 ARM (CA9): 761320—Full cache line writes to the same memory

region from at least two processors might deadlock the processor

Description:

Under very rare circumstances, full cache line writes from (at least) 2 processors on cache lines in hazard with other requests may cause arbitration issues in the SCU, leading to processor deadlock. To trigger the erratum, at least three agents need to be working in SMP mode, and accessing coherent memory regions. Two or more processors need to perform full cache line writes, to cache lines which are in hazard with other access requests in the SCU. The hazard in the SCU happens when another processor , or the ACP, is performing a read or a write of the same cache line. The following example describes one scenario that might cause this deadlock:

- CPU0 performs a full cache line write to address A, then a full cache line write to address B

- CPU1 performs a full cache line write to address B, then a full cache line write to address A

- CPU2 performs read accesses to addresses A and B

Under certain rare timing circumstances, the requests might create a loop of dependencies, causing a processor deadlock.

Projected Impact:

When the erratum happens, it leads to system deadlock. It is important to note that any scenario leading to this deadlock situation is uncommon. It requires two (or more) processors writing full cache lines to a coherent memory region, without taking any semaphore, with another processor or the ACP accessing the same lines at the same time, meaning that these latter accesses are not deterministic. This, combined with the extremely rare microarchitectural timing conditions under which the defect can happen, explains why the erratum is not expected to cause any significant malfunction in real systems.

Workarounds:

This erratum can be worked around by setting bit[21] of the undocumented Diagnostic Control Register to 1. This register is encoded as CP15 c15 0 c0 1. The bit can be written in Secure state only , with the following Read/Modify/Write code sequence:

MRC p15,0,rt,c15,c0,1 ORR rt,rt,#0x200000

When this bit is set, the “direct eviction” optimization in the Bus Interface Unit is disabled, which means this erratum cannot occur. Setting this bit might prevent the Cortex-A9 from utilizing the full bandwidth when performing intensive full cache line writes, and therefore a slight performance drop might be visible. In addition, this erratum cannot occur if at least one of the following bits in the Diagnostic Control Register is set to 1:

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

80 NXP Semiconductors

- bit [23] – Disable Read-Allocate mode

- bit [22] – Disable Write Allocate Wait mode

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround implemented in Linux BSP codebase starting in release imx_3.10.53_1.1.0_ga.

ERR009605

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 81

ERR009742

ERR009742 ARM: 795769 - “Write Context ID" event is updated on read access

Description:

When selected, the Write Context ID event (event 0x0B) of the Performance Monitoring Unit (PMU) increments a counter whenever an instruction that writes to the Context ID register, CONTEXTIDR, is architecturally executed. However this erratum means that an instruction that reads the Context ID register also updates this counter. The erratum can happen under the following conditions:

1. A PMU counter is enabled, by setting the PMCNTENSET .Px bit to 1 (x identifies a single event

counter, and takes a value from 0 to 7).

2. The “Write Context ID” event is mapped to this selected PMU counter:

a. The chosen PMU counter is selected, by setting PMSELR.SEL to x (the same value as in condition 1). b. The “Write Context ID” event is mapped to this selected PMU, by setting PMXEVTYPER.evtCount to 0x0B.

3. The PMU is enabled, by setting the PMCR.E bit to 1.

4. A read access occurs to the CONTEXTIDR.

In this situation the PMU updates the counter when it should not.

Projected Impact:

The erratum affects the accuracy of the “Write Context ID" event, and its associated PMUEVENT[12] output signal.

Workarounds:

There is no workaround for this erratum. The Freescale Linux BSP does not enable this optional profiling feature by default. Users may add support for this profiling feature as required, but should ensure the multiple ARM errata impacting the ARM PMU are considered.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not implemented because this erratum will never be encountered in normal device operation.The Freescale Linux BSP does not support this optional profiling feature.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

82 NXP Semiconductors

ERR009743

ERR009743 ARM: 799770 - DBGPRSR Sticky Reset status bit is set to 1 by the CPU

debug reset instead of by the CPU non-debug reset

Description:

DBGPRSR.SR, bit [3], is the Sticky Reset status bit. The ARM architecture specifies that the processor sets this bit to 1 when the non-debug logic of the processor is in reset state. Because of this erratum, the Cortex-A9 processor sets this bit to 1 when the debug logic of the processor is in reset state, instead of when the non-debug logic of the processor is in reset state.

Projected Impact:

- DBGPRSR.SR might not be set to 1 when it should, when the non-debug logic of the processor

is in reset state.

- DBGPRSR.SR might be set to 1 when it should not, when the debug logic of the processor is in

reset state. In both cases, the DBGPRSR.SR bit value might be corrupted, which might prevent the debug logic from correctly detecting when the non-debug logic of the processor has been reset.

Workarounds:

No software workaround available as this erratum is related to a debug feature. Users should not rely on the DBGPRSR.SR bit during the debug session.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not implemented because this erratum will never be encountered in normal device operation, as this erratum is related to a debug feature.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 83

ERR009858

ERR009858 ARM/PL310: 796171 When data banking is implemented, data parity

errors can be incorrectly generated

Description:

When parity is implemented and enabled in the PL310 Level-2 Cache Controller, for each read from the Data RAM, parity of the read data DATARD[255:0] is compared with stored parity bits in dedicated RAMs present on DATAPRD[31:0]. If the comparison does not match, the error is reported using an interrupt mechanism consisting of dedicated registers (Raw and Masked Interrupt registers).

This erratum occurs when the following conditions exist:

1) Parity is enabled (bit[21] of the Auxiliary Control Register is set to 1)

2) Read access latency on Data RAM is programmed with a value > 0x0 (bits [6:4] of the Data

RAM Latency Register) When the conditions above are met, parity checking between DATARD and DATAPRD occurs

during a two cycle window, including one cycle earlier than expected. If, in the early cycle, DATARD and DATAPRD are not stable yet, parity comparison migh t fail. In this case, an error is reported by the Interrupt registers, where no actual error exists.

Projected Impact:

Because of this erratum, false data parity errors might be reported by the PL310 Level-2 Cache Controller and can cause system instability.

Workarounds:

The following software workarounds can be used to avoid this erratum:

1) Disable parity by setting bit [21] of the Auxiliary Control Register to 0 (this is the default

condition).

2) Program the read access latency of the Data RAM to the minimum value acceptable for the

implementation plus one (bits [6:4] of the Data RAM Latency Control Register). Note that this workaround can affect performance.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.The Freescale Linux BSP does not enable this Parity feature and is disabled by default in all BSP releases. The BSP also ignores any assertion on the P ARITYF AIL [7:6] bits by masking the ARM-GIC parity interrupt 125. Please note that the i.MX6 does not support the parity feature (disabled by default) and hence should not be enabled by users.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

84 NXP Semiconductors

ERR004320

ERR004320 CAAM: Three encryption functions may show up as available, even

though they are not

Description:

In the CAAM block, the availability of the AES, DES and RC4 crypto accelerators are controlled by the EXPORT_CONTROL fuse.

If this fuse is blown these crypto accelerators are not available. There is also a CAAM CHANUM register (AES is bits [3:0], DES is bits [7:4] and RC4 is bits [11:8]) that shows the number of crypto accelerators available for each type of crypto operation.

When this fuse is blown, this register should show that there are 0 of each encryption accelerator. However, it actually shows that 1 is available.

Projected Impact:

The three encryption functions might show up as available, even though they are not.

Workarounds:

Software should check the EXPORT_CONTROL fuse in OCOTP to determine if the crypto accelerators are available or not instead of reading the CAAM CHANUM register.

Proposed Solution:

No fix scheduled

Linux BSP Status:

W orkaround possible but not implemented in the BSP, impacting functionality as described above.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 85

ERR004347

ERR004347 CAAM: False read access error

Description:

CAAM secure memory has settable access permissions. One setting is to create a protected key partition, which can be accessed by CAAM to read a key , but that cannot be read or written by any other hosts. The purpose is to provide a place to store secret keys that cannot be compromised by any software.

In order to store a key into such a partition, which does not allow a write access to occur, there is an access bit labeled SMBLOB (Secure Memory Blob), which allows CAAM to write data to the partition from a decapsulated blob, or to read the data from the partition in order to package it into a blob.

The issue found is that CAAM logs a read access error into a status register when it decapsulates a blob and writes the contents to the protected key partition. This logging of the read access error into a status register does not appear to have any other affect. It does not prevent the blob contents from being correctly written to the protected key partition.

Projected Impact:

False error indication when CAAM decapsulates a blob and writes the contents to the protected key partition.

Workarounds:

The software workaround for this erratum is to clear the error code after the blob is decapsulated by reading the status register and ignoring its contents.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

86 NXP Semiconductors

ERR004348 CAAM: Internal 16 Kb RAM (CAAM) does not support wrapped

accesses

Description:

The internal 16 Kb RAM (CAAM - Secure memory) does not support wrapped accesses.

Projected Impact:

Wrapped accesses to the internal 16 Kb RAM (CAAM) will res ult in incorrect read /write from/to the RAM.

Workarounds:

The Internal 16 Kb RAM accesses (CAAM) should not be cached. Users should ensure that the MMU table does not have this 16 Kb region mapped as cacheable memory region to prevent incorrect accesses.

Proposed Solution:

No fix scheduled

ERR004348

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 87

ERR005766

ERR005766 CAAM: CAAM cannot handle interleaved READ data “beats” returned

by two different slaves in the system, in reply to two different AXI-ID accesses

Description:

The CAAM can issue several transactions with different AXI-IDs but its AXI master port does not handle interleaved data properly. The faulty behavior is expected to occur when working in DDR interleaving mode. For example, one access with ID X is directed to DDR0, while almost simultaneously , another access with different AXI-ID is passed to the second DDR controller . This way the data “beats” of the two AXI-IDs may be replied interleaved.

CAAM has two sources of transactions—first, the Job Queue controller, which fetches jobs and prepares descriptors to be run, and second, the DECO, which executes the descriptors. With a single DECO, there are less chances of the Job Queue controller and DECO to overlap while performing AXI read requests.

Projected Impact:

CAAM might read wrong data.

Workarounds:

There are two workarounds for this issue. They both prevent CAAM from issuing multiple AXI read transactions with different AXI-IDs. The workarounds are as follows:

• Workaround 1: The first workaround is to only issue a single descriptor to CAAM at a time.

CAAM will not pre-fetch a second descriptor, as there is no second descriptor. HAB uses this approach. HAB in i.MX 6 Series only issues one descriptor at a time.

• W orkaround 2: The second workaround is for cases where multiple descriptors will be issued to

CAAM, (for example, a Linux device driver). In this case, CAAM can be configured to only issue one AXI transaction at a time by setting the CAAM AXI pipeline depth to 1. This will prevent multiple outstanding transactions, and thus multiple transactions with different AXI-IDs. This is done by setting the AXIPIPE field of the CAAM Master Configuration Register (MCFGR) to 1. The workaround seems to have minimal impact on the performance.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not needed in the BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

88 NXP Semiconductors

ERR006223

ERR006223 CCM: Failure to resume from Wait/Stop mode with power gating

Description:

When entering Wait/Stop mode with power gating of the ARM core(s), if an interrupt arrives during the power-down sequence, the system could enter an unexpected state and fail to resume.

Projected Impact:

Device might fail to resume from low-power state.

Workarounds:

Use REG_BYPASS_COUNTER (RBC) to hold off interrupts when the PGC unit is in the middle of the power-down sequence. The counter needs to be set/cleared only when there are no interrupts pending. The counter needs to be enabled as close to the WFI (W ait For Interrupt) state as possible.

The following equation can be used to aid determination of the RBC counter value: RBC_COUNT × (1/32K R TC Frequency) ≥ (25 + PDNSCR_SW2ISO) × (1/IPG_CLK Frequency) PDNSCR_ISO2SW = PDNSCR_ISO = 1 (counts in IPG_CLK clock domain)

Proposed Solution:

No fix scheduled.

Linux BSP Status:

Software workaround implemented in Linux BSP codebase starting in release GA L3.0.35_1.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 89

ERR007265

ERR007265 CCM: When improper low-power sequence is used, the SoC enters

low power mode before the ARM core executes WFI

Description:

When software tries to enter Low-Power mode with the following sequence, the SoC enters Low-Power mode before the ARM core executes the WFI instruction:

1. Set CCM_CLPCR[1:0] to 2’b00

2. ARM core enters WFI

3. ARM core wakeup from an interrupt event, which is masked by GPC or not visible to GPC, such as an interrupt from a local timer

4. Set CCM_CLPCR[1:0] to 2’b01 or 2’b10

5. ARM core executes WFI

Before the last step, the SoC enters WAIT mode if CCM_CLPCR[1:0] is set to 2’b01, or STOP mode if CCM_CLPCR[1:0] is set to 2’b10.

Projected Impact:

This issue can lead to errors ranging from module underrun errors to system hangs, depending on the specific use case.

Workarounds:

Software workaround:

1) Software should trigger IRQ #32 (IOMUX) to be always pending by setting

IOMUX_GPR1_GINT

2) Software should then unmask IRQ #32 in GPC before setting CCM Low-Power mode

3) Software should mask IRQ #32 right after CCM Low-Power mode is set (set bits 0–1 of

CCM_CLPCR)

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround implemented in Linux BSP codebase. A patch is included in both BSP kernels v3.10.9 and v3.0.35.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

90 NXP Semiconductors

ERR009219 CCM: Asynchronous clock switching can cause unpredictable

behavior [i.MX 6Dual/6Quad Only]

Description:

Certain applications require the source clock of the LVDS Display Bridge (LDB) to be modified to accommodate various display clock frequency requirements. The clock source can be modified by programming an asynchronous clock multiplexer (CCM_CS2CDR[LDB_DIx_CLK_SEL]) in software.

Asynchronous multiplexers or glitchy multiplexers, enable the clock to switch immediately after the multiplexer select is changed. Because both clock sources to the multiplexer are asynchronous, switching the clocks from one source to the other can cause a glitch to be generated, regardless of the input clock source. This immediate switch of two asynchronous clock domains can cause the output clock to glitch. If the input and output clocks are not gated, this clock glitch can propagate to the logic that follows the clock multiplexer, causing the logic to behave unpredictably.

A clock gate has not been implemented after the asynchronous clock multiplexer for the LDB_DI0_IPU clock and LDB_DI1_IPU clocks. Due to the absence of this clock gate on this LDB_DIx_IPU clock path, a glitch generated when the clock source is switched, can lock up the LDB divider causing a loss of the LDB_DIx_IPU clock under certain conditions.

ERR009219

Projected Impact:

Switching LDB clock sources on an asynchronous clock multiplexer without gating the input and output clock can cause clock glitches to propagate to the logic that follows the clock multiplexers, causing the logic to behave unpredictably. With an ungated input clock, under certain conditions the clock divider in the LDB_DIx_IPU clock path can incorrectly lock up. This can therefore cause a loss of the LDB_DIx_IPU clock which can result in a blank LVDS display screen in the user application.

Workarounds:

The input and output clocks to the asynchronous clock multiplexer are required to be gated prior to switching the source clock. The recommended software workaround is to shut down the clocks to the asynchronous clock multiplexor (CS2CDR: LDB_DIx_CLK_SEL) by disabling the respective PLLs and PFDs prior to performing the clock switch. After the clock switch is performed the input and output clocks of the multiplexer are re-enabled. Users must ensure that the PFDs are reset after the respective PLLs are locked. It is recommended to perform the LDB clock switch early in the boot process to minimize the clocking impact.

Please refer to Engineering Bulletin EB821 : LDB Clock Switch Procedure and i.MX6 Asynchronous Clock Switching Guidelines for further details on the issue and recommended software workaround procedure.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 91

ERR009219

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.0.35_4.1.0.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

92 NXP Semiconductors

ERR009165

ERR009165 eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer

to be sent twice

Description:

When using DMA to transfer data to the TXFIFO, if the data is written to the TXFIFO during an active eCSPI data exchange, this can cause a glitch in the TXFIFO empty signal, resulting in the TXFIFO read pointer (TXCNT) not updating correctly , which in turn results in the current transfer getting resent a second time.

Projected Impact:

Incorrect data transfer when using DMA to transfer data to the eCSPI TXFIFO.

Workarounds:

This errata is only seen when the SMC (Start Mode Control) bit is set. A modified SDMA script with TX_THRESHOLD = 0 and using only the XCH (SPI Exchange) bit to initiate transfers prevents this errata from occurring. There is an associated performance impact with this workaround. Testing transfers to a SPI-NOR flash showed approximately a 5% drop in write data rates and a 25% drop in read data rates.

Proposed Solution:

No fix scheduled.

Linux BSP Status:

Software workaround integrated in Linux BSP codebase starting in release imx_3.14.38_6qp_ga.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 93

ERR009535

ERR009535 eCSPI: Burst completion by SS signal in slave mode is not functional

Description:

According to the eCSPI specifications, when eCSPI is set to operate in the Slave mode (CHANNEL_MODE[x] = 0), the SS_CTL[x] bit controls the behavior of burst completion. In the Slave mode, the SS_CTL bit should control the behavior of SPI burst completion as follows:

• 0—SPI burst completed when (BURST_LENGTH + 1) bits are received

• 1—SPI burst completed when the SS input is negated

Also, in BURST_LENGTH definition, it is stated “In the Slave mode, this field takes effect in SPI transfer only when SS_CTL is cleared.”

However, the mode SS_CTL[x] = 1 is not functional in Slave mode. Currently, BURST_LENGTH always defines the burst length.

According to the SPI protocol, negation of SSB always causes completion of the burst. However, due to the above issue, the data is not sampled correctly in RxFIFO when {BURST_LENGTH+1}mod32 is not equal to {actual burst length}mod32. Therefore, setting the BURST_LENGTH parameter to a value greater than the actual burst does not resolve the issue.

Projected Impact:

Slave mode with unspecified burst length cannot be supported due to this issue. The burst length should always be specified with the BURST_LENGTH parameter and the SS_CTL[x] should be set to zero.

Workarounds:

There is no workaround except for not using the SS_CTL[x] = 1 option in the Slave mode. The accurate burst length should always be specified using the BURST_LENGTH parameter.

Proposed Solution:

No fix scheduled.

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

94 NXP Semiconductors

ERR009606

ERR009606 eCSPI: In master mode, burst lengths of 32n+1 will transmit incorrect

data

Description:

When the ECSPI is configured in master mode and the burst length is configured to a value 32n+1 (where n=0,1, 2,…), the ECSPI will transmit the portions of the first word in the FIFO twice. For example, if the transmit FIFO is loaded with: [0] 0x00000001 [1] 0xAAAAAAAA And the burst length is configured for 33 bits (ECSPIx_CONREG[BURST_LENGTH]=0x020), the ECSPI will transmit the first bit of word [0] followed by the entire word [0], then transmit the data as expected. The transmitted sequence in this example will be: [0] 0x00000001 [1] 0x00000001 [2] 0x00000000 [3] 0xAAAAAAAA

Projected Impact:

Incorrect data transmission.

Workarounds:

Do not use burst lengths of 32n+1 (where n=0,1, 2,…).

Proposed Solution:

No fix scheduled.

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used. The driver limits the burst length up to 32 bits.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 95

ERR004446

ERR004446 EIM: AUS mode is nonfunctional for devices larger than 32 MB

Description:

When the AUS bit is set, the address lines of the EIM are unshifted. By default, the AUS bit is cleared and address lines are shifted according to port size (8, 16 or 32 bits). Due to an error, the address bits 27:24 are shifted when AUS=1. For example, CPU address 0xBD00_0000 ([A27:20]=1101 0000 becomes 0xB600_0000 ([A27:20]=0110 0000) on the EIM bus, because A[27:25] is shifted to [A26:24] and A[23:0] is not shifted. As a result A[24] is missed.

Projected Impact:

If the memory used does not exceed 32 MB, there is no impact. This mode is related to a unique memory configuration that is not often used. Most systems can

work in the default mode (AUS=0). Board designers should connect the EIM address bus without a shift (for example, A0→A0 and A1→A1), while working in AUS=0 mode.

Workarounds:

• Use the AUS = 0 mode (default) while connecting the address signals without a shift (for

example, A0→A0 and A1→A1).

• For AUS=1, for devices larger than 32 MB, it is necessary to build a memory map that takes this

shifting into consideration and does not include A[24] line.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround not implemented in Linux BSP. Functionality or mode of operation in which the erratum may manifest itself is not used.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

96 NXP Semiconductors

ERR009218 EIM: Signals fail to drive as outputs during boundary scan test

Description:

During boundary scan test, a subset of the EIM signals will not be driven as outputs causing the test to fail. The affected signals are: EIM_A[24:16], EIM_DA[15:0], EIM_EB[3:0], EIM_RW, EIM_WAIT and EIM_LBA. This group of signals is incorrectly configured with a drive strength value (DSE) of 3’b000, which causes the signals to be Hi-Z.

Projected Impact:

Boundary scan test will fail to drive outputs on the signals listed above. These signals can be tested as input-only.

Workarounds:

Because the signals listed above cannot be driven as outputs, interconnect tests on these signals can only be performed if the external devices connected to these pins can drive them as inputs. The boundary scan test generation tool should be configured to test these signals as input-only, if possible. Test of any of the signals that cannot be driven by an external device should be disabled in the boundary scan test generation tool to prevent generation of an incorrect test pattern.

ERR009218

Proposed Solution:

No fix scheduled

Linux BSP Status:

Software workaround is not implemented because this erratum will never be encountered in normal device operation.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 97

ERR004512

ERR004512 ENET: 1 Gb Ethernet MAC (ENET) system limitation

Description:

The theoretical maximum performance of 1 Gbps ENET is limited to 470 Mbps (total for Tx and Rx). The actual measured performance in an optimized environment is up to 400 Mbps.

Projected Impact:

Minor. Limitation of ENET throughput to around 400 Mbps. ENET remains fully compatible to 1Gb standard in terms of protocol and physical signaling. If the TX and RX peak data rate is higher than 400 Mbps, there is a risk of ENET RX FIFO overrun.

Workarounds:

There is no workaround for the throughput limitation. T o prevent overrun of the ENET RX FIFO, enable pause frame.

Proposed Solution:

No fix scheduled

Linux BSP Status:

W orkaround possible but not implemented in the BSP, impacting functionality as described above.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

98 NXP Semiconductors

ERR005783

ERR005783 ENET: ENET Status FIFO may overflow due to consecutive short

frames

Description:

When the MAC receives shorter frames (size 64 bytes) at a rate exceeding the average line-rate burst traffic of 400 Mbps the DMA is able to absorb, the receiver might drop incoming frames before a Pause frame is issued.

Projected Impact:

No malfunction will result aside from the frame drops.

Workarounds:

The application might want to implement some flow control to ensure the line-rate bur st traffic is below 400 Mbps if it only uses consecutive small frames with minimal (96 bit times) or short Inter-frame gap (IFG) time following large frames at such a high rate. The limit does not exist f or frames of size larger than 800 bytes.

Proposed Solution:

No fix scheduled

Linux BSP Status:

W orkaround possible but not implemented in the BSP, impacting functionality as described above.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

NXP Semiconductors 99

ERR005895

ERR005895 ENET: ENET 1588 channel 2 event capture mode not functional

Description:

The ENET module provides a 4-channel IEEE 1588 compliant timer that supports event input capture and output compare mode. The capture/compare feature requires the ENET 1588 clock to latch in the correct IEEE 1588 counter value to the Timer Compare Capture Register (ENET_TCCRn). Due to an integration issue, the ENET 1588 clock and Channel 2 event capture/compare signal are both connected to the same GPIO16 pin.

Projected Impact:

ENET 1588 channel 2 event capture/compare mode cannot be used.

Workarounds:

None. Channels 1, 3, and 4 can be used for the event capture instead.

Proposed Solution:

No fix scheduled

Linux BSP Status:

Workaround cannot be implemented to mask this SoC issue, impacting functionality as described above.

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus, Rev. 6.1, 06/2016

100 NXP Semiconductors

NXP Semiconductors i.MX 6Dual, i.MX 6Quad, i.MX 6DualPlus, i.MX 6QuadPlus Reference Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus

ERR005852

ERR003717

ERR003718

ERR003719

ERR003720

ERR003721

ERR003723

ERR003724

ERR003725

ERR003726

ERR003727

ERR003728

ERR003729

ERR003730

ERR003731

ERR003732

ERR003733

ERR003734

ERR003735

ERR003736

ERR003737

ERR003738

ERR003739

ERR003740

ERR003741

ERR003743

ERR004324

ERR004325

ERR004326

ERR004327

ERR005175

ERR005183

ERR005185

ERR005187

ERR005198

ERR005199

ERR005200

ERR005382

ERR005383

ERR005385

ERR005386

ERR005387

ERR006259

ERR007006

ERR007007

ERR007008

ERR009604

ERR009605

ERR009742

ERR009743

ERR009858

ERR004320

ERR004347

ERR004348

ERR005766

ERR006223

ERR007265

ERR009219

ERR009165

ERR009535

ERR009606

ERR004446

ERR009218

ERR004512

ERR005783

ERR005895