MIPS MIPS32 74K Series, Programming Manual

Page: 71 / 156

Kernel-mode (OS) programming and Release 2 of the MIPS32® Architecture
71 Programming the MIPS32® 74K™ Core Family, Revision 02.14
As before, the interrupt handler will see the interrupt request number in Cause[IP] bits - see Section B.1.3.1 “The
Cause register” ; the six MS of those bits are now relabelled as Cause[RIPL] (“requested IPL”). In EIC mode the soft-
ware interrupt bits are not used in interrupt selection or prioritization: see below. But there’s an important difference;
Cause[RIPL] holds a snapshot of the value presented to the CPU when it decided to take the interrupt, whereas the old
Cause[IP] bits simply reflected the real-time state of the input signals
17
.
When an exception is triggered the new IPL - as captured in Cause[RIPL] - is used directly as the interrupt number;
it’s multiplied by the interrupt spacing implied by IntCtl[RS] and added to the special interrupt entry point, as
described in the previous section. Cause[RIPL] retains its value until the CPU next takes any exception.
Software interrupts: the two bits in Cause[IP1-0] are still writable, but now become real signals which are fed out of
the CPU core, and in most cases will become inputs - presumably low-priority ones - to the EIC-compliant interrupt
controller.
In EIC mode the usual association of the internal timer, performance-counter overflow, and fast debug channel inter-
rupts with individual bits of
Cause[IP]
is lost. These interrupts are turned into output signals from the core, and will
themselves become inputs to the interrupt controller. Ask your system integrator how they are wired.
5.3 Exception Entry Points
Early versions of the MIPS architecture had a rather simple exception system, with a small number of architecture-
fixed entry points.
But there were already complications. When a CPU starts up main memory is typically random and the MIPS caches
are unusable until initialized; so MIPS CPUs start up in uncached ROM memory space and the exception entry points
are all there for a while (in fact, for so long as
Status[BEV]
is set); these “ROM entry points” are clustered near the
top of kseg1, corresponding to 0x1FC0.0000 physical
18
, which must decode as ROM.
ROM is slow and rigid; handlers for some exceptions are performance-critical, and OS’ want to handle exceptions
without relying on ROM code. So once the OS boots up it’s essential to be able to redirect OS-handled exceptions
into cached locations mapped to main memory (what exceptions are not OS-handled? well, there are no alternate
entry points for system reset, NMI, and EJTAG debug).
So when
Status[BEV]
is flipped to zero, OS-relevant exception entry points are moved to the bottom of kseg0, start-
ing from 0 in the physical map. The cache error exception is an exception... it would be silly to respond to a cache
error by transferring control to a cached location, so the cache error entry point is physically close to all the others,
but always mapped through the uncached “kseg1” region.
In MIPS CPUs prior to the MIPS32 architecture (with a few infrequent special cases) only common TLB miss excep-
tions got their own entry point; interrupts and all other OS-handled exceptions were all funneled through a single
“general” exception entry point.
The MIPS32® architecture: interrupts get their own entry point
Embedded systems often make heavy use of interrupts and the OS may be less centralized; so MIPS32 CPUs allow
you to redirect all interrupts to a new “special interrupt” entry point; you just set a new bit in the
Cause
register,
Cause[IV]
— see Section B.1.3 “Exception control: Cause and EPC registers” .
17. Since the incoming IPL can change at any time - depending on the priority views of the interrupt controller - this is essential
if the handler is going to know which interrupt it’s servicing.
18. Even this address can be changed by a brave and determined SoC integrator, see the note on RBASE in Section
5.3.1 “Summary of exception entry points” .