path: root/doc/supplements
diff options
authorJoel Sherrill <>1998-10-19 13:01:33 +0000
committerJoel Sherrill <>1998-10-19 13:01:33 +0000
commitad0f33160f3bf7c9322c8b145e415687b819a917 (patch)
tree91860772d0f5f6ef662ad36bbbe36c5b39bcc2ea /doc/supplements
parent887173dd8cc92dbd96a441f1b742da3dbc197166 (diff)
Added chapter.
Diffstat (limited to '')
4 files changed, 246 insertions, 5 deletions
diff --git a/doc/supplements/template/Makefile b/doc/supplements/template/Makefile
index b3f565b33e..27a93cdc1d 100644
--- a/doc/supplements/template/Makefile
+++ b/doc/supplements/template/Makefile
@@ -24,7 +24,7 @@ COMMON_FILES=../../common/cpright.texi ../../common/setup.texi \
FILES= $(PROJECT).texi preface.texi \
- cpumodel.texi callconv.texi memmodel.texi intr.texi
+ cpumodel.texi callconv.texi memmodel.texi intr.texi fatalerr.texi
# bsp.texi callconv.texi cpumodel.texi cputable.texi fatalerr.texi \
# intr.texi memmodel.texi preface.texi timetbl.texi timedata.texi wksheets.texi
@@ -71,6 +71,12 @@ intr.t: intr_NOTIMES.t BSP_TIMES
mv intr_NOTIMES.t.fixed intr.t
+fatalerr.texi: fatalerr.t Makefile
+ $(BMENU) -p "" \
+ -u "Top" \
+ -n "" ${*}.t
+intr.texi: intr.t Makefile
replace: timedata.texi
timetbl.t: ../../common/timetbl.t
diff --git a/doc/supplements/template/intr_NOTIMES.t b/doc/supplements/template/intr_NOTIMES.t
new file mode 100644
index 0000000000..deb645781a
--- /dev/null
+++ b/doc/supplements/template/intr_NOTIMES.t
@@ -0,0 +1,196 @@
+@c Interrupt Stack Frame Picture
+@c COPYRIGHT (c) 1988-1998.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c $Id$
+@chapter Interrupt Processing
+@section Introduction
+Different types of processors respond to the
+occurrence of an interrupt in its own unique fashion. In
+addition, each processor type provides a control mechanism to
+allow for the proper handling of an interrupt. The processor
+dependent response to the interrupt modifies the current
+execution state and results in a change in the execution stream.
+Most processors require that an interrupt handler utilize some
+special control mechanisms to return to the normal processing
+stream. Although RTEMS hides many of the processor dependent
+details of interrupt processing, it is important to understand
+how the RTEMS interrupt manager is mapped onto the processor's
+unique architecture. Discussed in this chapter are the XXX's
+interrupt response and control mechanisms as they pertain to
+@section Vectoring of an Interrupt Handler
+Depending on whether or not the particular CPU
+supports a separate interrupt stack, the XXX family has two
+different interrupt handling models.
+@subsection Models Without Separate Interrupt Stacks
+Upon receipt of an interrupt the XXX family
+members without separate interrupt stacks automatically perform
+the following actions:
+@itemize @bullet
+@item To Be Written
+@end itemize
+@subsection Models With Separate Interrupt Stacks
+Upon receipt of an interrupt the XXX family
+members with separate interrupt stacks automatically perform the
+following actions:
+@itemize @bullet
+@item saves the current status register (SR),
+@item clears the master/interrupt (M) bit of the SR to
+indicate the switch from master state to interrupt state,
+@item sets the privilege mode to supervisor,
+@item suppresses tracing,
+@item sets the interrupt mask level equal to the level of the
+interrupt being serviced,
+@item pushes an interrupt stack frame (ISF), which includes
+the program counter (PC), the status register (SR), and the
+format/exception vector offset (FVO) word, onto the supervisor
+and interrupt stacks,
+@item switches the current stack to the interrupt stack and
+vectors to an interrupt service routine (ISR). If the ISR was
+installed with the interrupt_catch directive, then the RTEMS
+interrupt handler will begin execution. The RTEMS interrupt
+handler saves all registers which are not preserved according to
+the calling conventions and invokes the application's ISR.
+@end itemize
+A nested interrupt is processed similarly by these
+CPU models with the exception that only a single ISF is placed
+on the interrupt stack and the current stack need not be
+The FVO word in the Interrupt Stack Frame is examined
+by RTEMS to determine when an outer most interrupt is being
+exited. Since the FVO is used by RTEMS for this purpose, the
+user application code MUST NOT modify this field.
+The following shows the Interrupt Stack Frame for
+XXX CPU models with separate interrupt stacks:
+@ifset use-ascii
+ +----------------------+
+ | Status Register | 0x0
+ +----------------------+
+ | Program Counter High | 0x2
+ +----------------------+
+ | Program Counter Low | 0x4
+ +----------------------+
+ | Format/Vector Offset | 0x6
+ +----------------------+
+@end group
+@end example
+@end ifset
+@ifset use-tex
+@sp 1
+\hbox to 2.00in{\enskip\hfil#\hfil}&
+\hbox to 0.50in{\enskip\hfil#\hfil}
+& Status Register && 0x0\cr
+& Program Counter High && 0x2\cr
+& Program Counter Low && 0x4\cr
+& Format/Vector Offset && 0x6\cr
+@end tex
+@end ifset
+@ifset use-html
+<TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD>
+ <TD ALIGN=center>0x0</TD></TR>
+<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD>
+ <TD ALIGN=center>0x2</TD></TR>
+<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD>
+ <TD ALIGN=center>0x4</TD></TR>
+<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD>
+ <TD ALIGN=center>0x6</TD></TR>
+ </TABLE>
+@end html
+@end ifset
+@section Interrupt Levels
+Eight levels (0-7) of interrupt priorities are
+supported by XXX family members with level seven (7) being
+the highest priority. Level zero (0) indicates that interrupts
+are fully enabled. Interrupt requests for interrupts with
+priorities less than or equal to the current interrupt mask
+level are ignored.
+Although RTEMS supports 256 interrupt levels, the
+XXX family only supports eight. RTEMS interrupt levels 0
+through 7 directly correspond to XXX interrupt levels. All
+other RTEMS interrupt levels are undefined and their behavior is
+@section Disabling of Interrupts by RTEMS
+During the execution of directive calls, critical
+sections of code may be executed. When these sections are
+encountered, RTEMS disables interrupts to level seven (7) before
+the execution of this section and restores them to the previous
+level upon completion of the section. RTEMS has been optimized
+to insure that interrupts are disabled for less than
+zero wait states. These numbers will vary based the
+number of wait states and processor speed present on the target board.
+[NOTE: The maximum period with interrupts disabled is hand calculated. This
+calculation was last performed for Release
+Non-maskable interrupts (NMI) cannot be disabled, and
+ISRs which execute at this level MUST NEVER issue RTEMS system
+calls. If a directive is invoked, unpredictable results may
+occur due to the inability of RTEMS to protect its critical
+sections. However, ISRs that make no system calls may safely
+execute as non-maskable interrupts.
+@section Interrupt Stack
+RTEMS allocates the interrupt stack from the
+Workspace Area. The amount of memory allocated for the
+interrupt stack is determined by the interrupt_stack_size field
+in the CPU Configuration Table. During the initialization
+process, RTEMS will install its interrupt stack.
+The XXX port of RTEMS supports a software managed
+dedicated interrupt stack on those CPU models which do not
+support a separate interrupt stack in hardware.
diff --git a/doc/supplements/template/memmodel.t b/doc/supplements/template/memmodel.t
new file mode 100644
index 0000000000..4cb46bab90
--- /dev/null
+++ b/doc/supplements/template/memmodel.t
@@ -0,0 +1,39 @@
+@c COPYRIGHT (c) 1988-1998.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c $Id$
+@chapter Memory Model
+@section Introduction
+A processor may support any combination of memory
+models ranging from pure physical addressing to complex demand
+paged virtual memory systems. RTEMS supports a flat memory
+model which ranges contiguously over the processor's allowable
+address space. RTEMS does not support segmentation or virtual
+memory of any kind. The appropriate memory model for RTEMS
+provided by the targeted processor and related characteristics
+of that model are described in this chapter.
+@section Flat Memory Model
+The XXX family supports a flat 32-bit address
+space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
+gigabytes). Each address is represented by a 32-bit value and
+is byte addressable. The address may be used to reference a
+single byte, word (2-bytes), or long word (4 bytes). Memory
+accesses within this address space are performed in big endian
+fashion by the processors in this family.
+Some of the XXX family members such as the
+XXX, XXX, and XXX support virtual memory and
+segmentation. The XXX requires external hardware support
+such as the XXX Paged Memory Management Unit coprocessor
+which is typically used to perform address translations for
+these systems. RTEMS does not support virtual memory or
+segmentation on any of the XXX family members.
diff --git a/doc/supplements/template/template.texi b/doc/supplements/template/template.texi
index 0f8e57bd25..2fd116b0aa 100644
--- a/doc/supplements/template/template.texi
+++ b/doc/supplements/template/template.texi
@@ -66,8 +66,8 @@ END-INFO-DIR-ENTRY
@include preface.texi
@include cpumodel.texi
@include callconv.texi
-@c @include memmodel.texi
-@c @include intr.texi
+@include memmodel.texi
+@include intr.texi
@c @include fatalerr.texi
@c @include bsp.texi
@c @include cputable.texi
@@ -85,8 +85,8 @@ Applications Supplement.
* Preface::
* CPU Model Dependent Features::
* Calling Conventions::
-** Memory Model::
-** Interrupt Processing::
+* Memory Model::
+* Interrupt Processing::
** Default Fatal Error Processing::
** Board Support Packages::
** Processor Dependent Information Table::