Specification Update

December 2008

18

5.0

1.

Abort is Missed When Lock Command is Outstanding

Problem:

A bus abort occurs on a code fetch while an instruction TLB or I-Cache lock Move to

Coprocessor from Intel XScale processor Register (MCR) command is outstanding. The

processor fails to abort and instead executes the instruction returned on the aborting

transaction. Parity errors are not affected. The bus abort may be due to an abort pin

assertion.

does this: SUB PC, PC #4;flush the pipe.

Status:

No Fix.

2.

Aborted Store that Hits the Data Cache May Mark Write-Back Data as

‘Dirty’

Problem:

When there is an aborted store that hits clean data in the data cache (data in an

aligned 4-word range that has not been modified from the processor since it was last

loaded from memory or cleaned), the data in the array is not modified (the store is

blocked), but the “dirty” bit is set. When the line is then aged out of the data cache or

explicitly cleaned, the data in that four-word range is evicted to external memory, even

though it has never been changed. In normal operation this is nothing more than an

extra store on the bus that writes the same data to memory that is already there.

The boundary condition where this might occur:

1. A cache line is loaded into the cache at Address A.

2. Another master externally modifies Address A.

3. A processor store instruction attempts to modify A, hits the cache, aborts because

of MMU permissions, and is backed out of the cache. That line normally is not

marked dirty, but because of this errata, is marked as dirty.

4. The cache line at A then ages out or is explicitly cleaned. The original data from the

location A is evicted to external memory, overwriting the data written by the

external master. This happens only when software is allowing an external master to

modify memory, that is, write-back or write-allocate in the processor page tables,

and, depending on the fact that the data is not dirty in the cache, to preclude the

cached version from overwriting the external memory version. When there are any

semaphores or any other handshaking to prevent collisions on shared memory, this

is not a problem.

table. This prevents the data from ever being written out as dirty.

Status:

No Fix.

3.

Performance Monitor Unit Event 0x1 Can be Incremented

Erroneously by Unrelated Events

Problem:

Event 0x1 in the performance monitor unit (PMU) can be used to count cycles in which

the instruction cache cannot deliver an instruction. The cycles counted should be only

those due to an instruction cache miss or an instruction TLB miss. The following

unrelated events in the processor also causes the corresponding count to increment

when event number 0x1 is being monitored:

• Any architectural event (for example, IRQ, data abort)

• MSR instructions that alter the CPSR control bits

• Some branch instructions, including indirect branches and those mispredicted by

the BTB

• CP15 MCR instructions to registers 7, 8, 9, or 10 that involve the instruction cache

or the instruction TLB