Notable CPU bugs (changes)

Showing changes from revision #6 to #7: Added | Removed | Changed

This page is intended to list CPU bugs that are notable to either application or OS developers. This includes actual bugs that are not listed in manuals (e.g. StrongARM conditional MSR CPSR_c), and some “gotchas” which are documented but may not apply to all architecture versions and so may easily be missed (e.g. MUL register restrictions).

Where possible, include a reference to some documentation which verifies the existence of the bug (e.g. official errata document, or newsgroup posting from an ARM/Acorn employee)

Bugs relevant to application development

List bugs relating to application development here; i.e. bugs/restrictions in the instruction set that an ordinary program may run into.

ARM2, ARM250 and ARM3 bugs

The Warnings on the use of ARM assembler chapter in PRM volume 4 contains a list of issues which affect these processors.

When reading the document, any mention of ARM3 should be treated as “ARM250 or ARM3”, because the list of issues is the same for both processors (ARM2-only bugs do not apply to ARM250)

StrongARM MSR bug

The StrongARM has a bug in its implementation of MSR which can result in the instruction following the MSR being executed twice.

The bug is triggered when:

• The processor is in a privileged mode,
• The last instruction was an MSR to the CPSR with the ‘c’ bit set,
• The MSR was not executed due to the condition test failing,
• And the MSR was not the last instruction in a cache line.

To avoid this problem, there are a number of approaches, depending on how cautious you wish to be:

• Follow all MSR CPSR_c[xsf] instructions with a NOP, much like for the ARM2 TEQP bug;
• Don’t use conditional MSR CPSR_c[xsf] instructions;
• Follow all conditional MSR CPSR_c[xsf] instructions with a NOP;
• Ensure all instructions following conditional MSR CPSR_c[xsf] instructions are idempotent, i.e. can be executed multiple times without ill effects. This then excludes instructions like BL or SWI, instructions with the same source and destination register, or loads and stores with base register writeback.

This bug only affects the StrongARM processor, but is present in all current revisions.

(Source: iyonix.com 32bit tech docs (archive), DDE 32bit tech docs)

STRB PC

On ARMv4 and later, STRB of PC has an undefined result. This has sometimes been used as a shortcut for storing a non-zero semaphore value in speed critical code. This instruction should no longer be used. Use STR PC or STRB of some other register.

(Application Note 295, ARM ARM)

StrongARM LDR/LDM PC

SA-110 CPUs prior to revision 3 contain a bug can be triggered under the following circumstances:

• The processor executes an LDR/LDM instruction which loads the PC
• The location after the LDR/LDM cannot be read (e.g. it’s the last instruction in a page, and the next page is unmapped or protected)

If the bug is triggered, a prefetch abort will occur, with R14_abt set to the PC value that was loaded by the LDR/LDM, minus 4.

Since RISC OS avoids activating lazy task swapping for pre-revision T StrongARMs (due to the LDMIB erratum described below), this bug is only likely to affect hand-crafted assembler programs/modules which have a LDR/LDM of PC as the last word of their binary. C programs should not be affected, as there will almost always be a data section following the code section.

(Source: November 1996 SA-110 errata (copy))

Bugs relevant to OS development

List bugs relating to low-level OS/systems software development here; e.g. bugs in the MMU or coprocessor interfaces, or CPU bugs that are only expected to be encountered by OS-level code (e.g. StrongARM abort restart bug).

Most modern CPUs have readily-available errata documentation, and that official documentation should be the go-to source for any OS developer (attempting to reproduce all errata notices here would be foolish). So this area should be limited to listing errata which apply to older processors (for which there’s no one-stop source of errata documentation), or for errata which are noteworthy enough that everyone should be reminded of them.

LDM^

The “load user mode registers” form of LDM has a restriction prior to ARMv6, which is that the instruction following the LDM must not access the banked registers. Inserting a NOP after the LDM is a safe way of avoiding this.

(Source: ARMv7 ARM “ARMv4 and ARMv5 Differences” appendix)

StrongARM STM^

The “store user mode registers” form of STM may fail on early StrongARMs (revision 2 in the ID register) if there is more than one register in the list.

(Source: November 1996 SA-110 errata (copy), Debugger module: 1, 2)

StrongARM STRB

When storing a byte, previous ARMs replicate the byte across the entire 32 bit data bus. StrongARM only outputs the byte on the relevant byte lane. The StrongARM processor card implements a compatibility fix for pre-Risc PC style podules as follows: bytes stored to word aligned addresses (byte 0) will be replicated on byte 2. This should allow most podules to work without firmware changes.

(Application Note 295)

StrongARM LDMIB abort

SA-110 CPUs prior to revision T contain a bug which is triggered under the following circumstances:

• The processor executes an LDMIB instruction which contains the base register in the register list
• The LDM crosses a page boundary
• A data abort is triggered after (at least) one register has been loaded successfully (e.g. the second page is unmapped)

When the abort is triggered, the CPU will attempt to restore the base register to its original value (i.e. base restored abort model). However in the above situation the base register will be restored to the wrong value (original address plus 4). For RISC OS, this means that lazy task swapping is disabled on pre-revision T StrongARMs, because there is no reliable way for the abort handler to determine the correct base register value (see also OS_PlatformFeatures 0 bit 17)

(Source: Intel document 278104-003: Intel® StrongARM® SA-110 Microprocessor Specification Update, March 1999)

ARM7 cache corruption

Early versions of ARM 7 series processors corrupt the cache when code performs a store multiple to the last word in a cache line, which is in the cache, but is not written through the write buffer. These processors are fitted only to a very few Acorn computers.

(full details in Warnings on the use of ARM Assembler in PRM volume 5A)

Intel 80321

The 80321, as used in the Iyonix, contains several errata which affect the cache, TLB/MMU, and CP15 interface.

(Source: Intel document 273519-010: Intel® 80321 I/O Processor Specification Update, March 2003)

Note that the B-0 stepping of the CPU, which fixed the majority of the issues, was released around April 2002, several months before the release of the Iyonix. So it’s unlikely that there are any A-0 based machines in existence.

External sources of errata documentation

List other sites here which provide errata information in an easy-to-find format.

• ARM
  • e.g. “Cortex-A series processors” contains errata documents for many Cortex-A processors
  • If errata documents are hidden in non-obvious places (e.g. the Application Notes), feel free to link to them here