MIPS Interrupt Discussion
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Dec 12 19:20:54 UTC 2000
As I am debugging the TX39 BSP, I am running into things I would
like to hear opinions on...
1. Meaning of the interrupt level portion of the task mode. This
is an 8 bit field (0-255) which by convention is used on all
ports as 0 == All interrupts on. Non-zero is some or all interrupts
disabled. On CPUs like the m68k, this maps to ISR level.
On CPUs like the i386, you get a simple all on, all off model.
MIPS issue: It looks like convention was broken. My reading of
the old mips64orion port shows task mode mapped to the IEC bit
of the SR where 1 is enabled, 0 is disabled.
I am in the process of making the MIPS port follow convention.
2. Comments wanted on the best way to treat the IM bits of the SR.
I am leaning to making them a system wide resource which means
they are NOT part of the per-task context.
3. Vectoring interrupt handlers. The basic mips interrupt model
is simple. 8 bits to decode in a largely cpu model and board
dependent fashion. It appears that two bits always indicate
software interrupt sources. The other 6 bits are up for grabs.
Some models place no restrictions, others (TX39) tie them to
an on-CPU interrupt controller.
The problem is that this means that the decision on which interrupt
to vector can not be made by simply scanning these bits to see
which are set. The logic can be worse. I am leaning to a
CPU model dependent vectoring routine in C. This could be
overridden by the BSP.
4. IDT/Sim/Monitors: Could some explain to me what needs to be done
in this case? :)
Comments/advice definitely appreciated.
I now am getting clock tick interrupts from the TX39 and
trying to decide what to do about vectoring it. :)
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list