Filter
Top Products
140 SPARC JPS1 Implementation Supplement: Fujitsu SPARC64 V • Release 1.0, 1 July 2002
O.2.1 RED_state
Once the processor enters RED_state for any reason except when a power-on reset
(POR) is performed, the software should not attempt to return to execute_state;
if software attempts a return, then the state of the processor is unpredictable.
When the processor processes a reset or a trap that enters RED_state, it takes a trap
at an offset relative to the RED_state trap table (RSTVaddr); in the processor this is
at virtual address VA = FFFFFFFFF0000000
16
and physical address
PA = 000007FFF0000000
16
.
The following list further describes the processor behavior upon entry into
RED_state, and during RED_state:
■
Whenever the processor enters RED_state, all fetch buffers are invalidated.
■
When the processor enters RED_state because of a trap or reset, the DCUCR
register is updated by hardware to disable several hardware features. Software
must set these bits when required (for example, when the processor exits from
RED_state).
■
When the processor enters RED_state not because of a trap or reset (that is,
when the PSTATE.RED bit has been set by WRPR), these register bits are
unchanged—unlike the case above. The only side effect is the disabling of the
instruction MMU.
■
When the processor is in RED_state, it behaves as if the IMMU is disabled
(DCUCR.IM is clear), regardless of the actual values in the respective control
register.
■
Caches continue to snoop and maintain coherence while the processor is in
RED_state.
O.2.2 error_state
The processor enters error_state when a trap occurs and TL = MAXTL (5) or when
the second watchdog timeout has occurred.
On the normal setting, the processor immediately generates a watchdog reset trap
(WDR) and transitions to RED_state. Otherwise, the OPSR (Operating Status
Register) specifies the stop on error_state, that is, the processor does not
generate a watchdog reset after error_state transition and remains in the
error_state.