BCM1250/BCM1125/BCM1125H
User Manual
10/21/02
B r o a d c o m C o r p o r a t i o n
Page
18
Section 3: System Overview
Document
1250_1125-UM100CB-R
B
US
E
RROR
E
XCEPTIONS
The bus error exception is raised on the CPU by external errors that are not reporting data corruption. The
main cause is when an access is detected to a non-existent address. Cacheable accesses that result in a bus
error will be put in the cache with uncorrectable ECC errors (as described for the cache error exception). As
with cache errors, both CPU and Bus Watcher registers are useful.
The error registers within the CPU are in the CP0 set and are described in the “Error Reporting Registers” part
of Section 9 of the SB-1 User Manual. The
BusErr-DPA
(register 26, select 1) contains the address of the bus
error (or first detected bus error) and the error control register
ErrCtl
(register 26, select 0) indicates if multiple
bus errors have been seen. In the Bus Watcher the bus error counter (
bus_mem_io_errors
) indicate how
many errors happened and the
bus_err_status
register will indicate the type of error and participants involved.
I f t he b u s e r r o r i s g e n e r a t e d f r o m t h e g e n e r i c b u s ( a d d r e s s i n t h e r a n g e 0 0 _ 1 00 9 _ 0 0 0 0 -
00_3FFF_FFFF responder id=Br1) then the
io_interrupt_status
register contains more information on the
cause of the bus error. Again, error reporting code can usefully dump all these registers.
There are a couple of interesting corner cases for bus errors. The first occurs when code is executed out of
some physical address and at a later time that physical address is no longer valid (this is only likely to happen
for unmapped addresses such as kseg0 and xkphys, since the software would presumably have removed any
TLB entries that point to invalid physical addresses). For example the generic bus chip select or memory
controller address parameters may have been changed. If any branches were executed while the address was
valid the CPU will store the branch target information in its branch prediction structures. At a later time it may
predict that a branch destination is at the now invalid address and issue a speculative instruction fetch. In this
case the CPU will
not take a bus error exception (because it will discover the speculation was incorrect), but
an interrupt may come in from the peripheral indicating a bad access was made and the Bus Watcher will
record and report that the error passed over the bus (the transaction ID recorded by the Bus Watcher will help
i n d i c a t e t h i s h a s h a p p e n e d , s e e
T a b l e 5 1 : “ D e c o d e o f s o m e T I D s f o r s y s t e m r e v i s i o n
and
Section: “Overview of the ZBbus Protocol” on page 20
The second case arises because the bus error exception is imprecise. It can be reported on any instruction
from the load that causes the bus error until a few instructions after the use of the register that was the target
of the load. In most cases the bus error is a programming error and causes the process to be terminated or
the system to enter error recovery. However, in systems with devices that can be hot-swapped the first
indication of device removal may be a time out or target abort during an access to the device. In this case the
imprecise reporting of the bus error may make it hard to determine that the exception handler should signal
the device driver to clean up its state and resume operation (
eret
). One approach to solving this is to have a
sync
instruction after each load to the hot-swappable device which will force the bus error to be reported on
the
sync
instruction. Alternatively, if two
ssnop
instructions are put after the instruction that uses the target of
the load then the bus error will be signalled on one of the instructions between the load and the second
ssnop
.