Filter
Top Products
Intel® PXA27x Processor Family Specification Update 13
Errata
Errata
E1. CORE: IFU misses an external abort when a lock command is
outstanding.
Problem: A bus abort occurs on a code fetch while an I-TLB lock mcr is outstanding. The IFU fails to abort,
instead executing the instruction returned on the aborting transaction. Parity errors are not affected.
The bus abort might be due to either an ABORT pin assertion or a multi-bit ECC error on the core.
On the core, the bus abort can occur as the result of a master abort, a target abort, or a single data
phase disconnect on the system bus.
Implication: TBD
Workaround: Branch flush after every ITLB or I-cache lock.
Status: No Fix
E2. CORE: Aborted store that hits D-cache might mark write-back data as
dirty.
Problem: If an aborted store hits clean data in the data cache (data in an aligned four-word range that has not
been modified from the core since it was last loaded in from memory or cleaned), the data in the
array will not be modified (the store will be blocked), but the dirty bit will be set.
When that line is then aged out of the data cache or explicitly cleaned, the data in that four-word
range will be evicted to external memory, even though it has never been changed. In normal
operation, this will be nothing more than an extra store on the bus that writes the same data to
memory as is already there.
This problem might be visible at the following boundary condition:
1. A cache line is loaded into the cache at address A
2. Another master externally modifies address A
3. An Intel XScale® core store instruction attempts to modify A, hits the cache, aborts because of
MMU permissions, and is backed out the of cache. That line should not be marked “dirty”, but
because of this defect it will be.
4. The cache line at A then ages out or is explicitly cleaned. The original data from location A
will be evicted to external memory, overwriting the data written by the external master.
This situation happen sonly if software is allowing an external master to modify memory that is
write-back or write-allocate in the XScale page tables, and depending on the fact that the data is not
dirty in the XScale cache to preclude the cached version from overwriting the external memory
version. If there are any semaphores or any other handshaking to prevent collisions on shared
memory, this should not be a problem.
Implication: TBD
Workaround: For a shared memory region, mark it as write-through memory in the XScale page table to prevent
the data from ever being written out as dirty, so the defect does not appear. Alternatively, ensure
that any cached copy of the data in external memory is invalidated if an external agent modifies the
external copy.
Status: No Fix