2002-07-30 Joel Sherrill <joel@OARcorp.com>

	* BSP_TIMES, ChangeLog, Makefile.am, arm.texi, bsp.t, callconv.t,
	cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t,
	preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi,
	wksheets.texi: New files as ARM supplement initial version added.

17 files changed, 2175 insertions, 0 deletions

diff --git a/doc/supplements/arm/BSP_TIMES b/doc/supplements/arm/BSP_TIMES
new file mode 100644
index 0000000000..1ddb23ca5a
--- /dev/null
+++ b/doc/supplements/arm/BSP_TIMES
@@ -0,0 +1,247 @@
+#
+#  CPU MODEL/BSP Timing and Size Information
+#
+#  $Id$
+#
+
+#
+#  CPU Model Information
+#
+RTEMS_BSP       generic-arm9dtmi
+RTEMS_CPU_MODEL arm9dtmi
+#
+#  Interrupt Latency
+#
+#  NOTE:  In general, the text says it is hand-calculated to be
+#         RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
+#         Mhz and this was last calculated for Release 
+#         RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
+#
+RTEMS_MAXIMUM_DISABLE_PERIOD TBD
+RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 100
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD ss-20020730
+#
+#  Context Switch Times
+#
+RTEMS_NO_FP_CONTEXTS 35
+RTEMS_RESTORE_1ST_FP_TASK 39
+RTEMS_SAVE_INIT_RESTORE_INIT 66
+RTEMS_SAVE_IDLE_RESTORE_INIT 66
+RTEMS_SAVE_IDLE_RESTORE_IDLE 68
+#
+#  Task Manager Times
+#
+RTEMS_TASK_CREATE_ONLY 148
+RTEMS_TASK_IDENT_ONLY 350
+RTEMS_TASK_START_ONLY 76
+RTEMS_TASK_RESTART_CALLING_TASK 95
+RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89
+RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124
+RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92
+RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125
+RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149
+RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142
+RTEMS_TASK_DELETE_CALLING_TASK 170
+RTEMS_TASK_DELETE_SUSPENDED_TASK 138
+RTEMS_TASK_DELETE_BLOCKED_TASK 143
+RTEMS_TASK_DELETE_READY_TASK 144
+RTEMS_TASK_SUSPEND_CALLING_TASK 71
+RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43
+RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45
+RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67
+RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31
+RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64
+RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106
+RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14
+RTEMS_TASK_MODE_NO_RESCHEDULE 16
+RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23
+RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60
+RTEMS_TASK_GET_NOTE_ONLY 33
+RTEMS_TASK_SET_NOTE_ONLY 33
+RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16
+RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56
+RTEMS_TASK_WAKE_WHEN_ONLY 117
+#
+#  Interrupt Manager
+#
+RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
+RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9
+RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9
+RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1
+RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8
+RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54
+#
+#  Clock Manager
+#
+RTEMS_CLOCK_SET_ONLY 86
+RTEMS_CLOCK_GET_ONLY 1
+RTEMS_CLOCK_TICK_ONLY 17
+#
+#  Timer Manager
+#
+RTEMS_TIMER_CREATE_ONLY 28
+RTEMS_TIMER_IDENT_ONLY 343
+RTEMS_TIMER_DELETE_INACTIVE 43
+RTEMS_TIMER_DELETE_ACTIVE 47
+RTEMS_TIMER_FIRE_AFTER_INACTIVE 58
+RTEMS_TIMER_FIRE_AFTER_ACTIVE 61
+RTEMS_TIMER_FIRE_WHEN_INACTIVE 88
+RTEMS_TIMER_FIRE_WHEN_ACTIVE 88
+RTEMS_TIMER_RESET_INACTIVE 54
+RTEMS_TIMER_RESET_ACTIVE 58
+RTEMS_TIMER_CANCEL_INACTIVE 31
+RTEMS_TIMER_CANCEL_ACTIVE 34
+#
+#  Semaphore Manager
+#
+RTEMS_SEMAPHORE_CREATE_ONLY 60
+RTEMS_SEMAPHORE_IDENT_ONLY 367
+RTEMS_SEMAPHORE_DELETE_ONLY 58
+RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38
+RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38
+RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109
+RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44
+RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66
+RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87
+#
+#  Message Manager
+#
+RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200
+RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341
+RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80
+RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97
+RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101
+RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123
+RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96
+RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101
+RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123
+RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
+RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111
+RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133
+RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79
+RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43
+RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114
+RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
+RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39
+#
+#  Event Manager
+#
+RTEMS_EVENT_SEND_NO_TASK_READIED 24
+RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
+RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
+RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
+RTEMS_EVENT_RECEIVE_AVAILABLE 28
+RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23
+RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84
+#
+#  Signal Manager
+#
+RTEMS_SIGNAL_CATCH_ONLY 15
+RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37
+RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55
+RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37
+RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54
+#
+#  Partition Manager
+#
+RTEMS_PARTITION_CREATE_ONLY 70
+RTEMS_PARTITION_IDENT_ONLY 341
+RTEMS_PARTITION_DELETE_ONLY 42
+RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35
+RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
+RTEMS_PARTITION_RETURN_BUFFER_ONLY 43
+#
+#  Region Manager
+#
+RTEMS_REGION_CREATE_ONLY 63
+RTEMS_REGION_IDENT_ONLY 348
+RTEMS_REGION_DELETE_ONLY 39
+RTEMS_REGION_GET_SEGMENT_AVAILABLE 52
+RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49
+RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123
+RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54
+RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114
+RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136
+#
+#  Dual-Ported Memory Manager
+#
+RTEMS_PORT_CREATE_ONLY 35
+RTEMS_PORT_IDENT_ONLY 340
+RTEMS_PORT_DELETE_ONLY 39
+RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
+RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27
+#
+#  IO Manager
+#
+RTEMS_IO_INITIALIZE_ONLY 4
+RTEMS_IO_OPEN_ONLY 2
+RTEMS_IO_CLOSE_ONLY 1
+RTEMS_IO_READ_ONLY 2
+RTEMS_IO_WRITE_ONLY 3
+RTEMS_IO_CONTROL_ONLY 2
+#
+#  Rate Monotonic Manager
+#
+RTEMS_RATE_MONOTONIC_CREATE_ONLY 32
+RTEMS_RATE_MONOTONIC_IDENT_ONLY 341
+RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
+RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51
+RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48
+RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54
+RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74
+RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31
+#
+#  Size Information
+#
+#
+#  xxx alloted for numbers
+#
+RTEMS_DATA_SPACE 723
+RTEMS_MINIMUM_CONFIGURATION 18,980
+RTEMS_MAXIMUM_CONFIGURATION 36,438
+#  x,xxx alloted for numbers
+RTEMS_CORE_CODE_SIZE 12,674
+RTEMS_INITIALIZATION_CODE_SIZE 970
+RTEMS_TASK_CODE_SIZE 3,562
+RTEMS_INTERRUPT_CODE_SIZE 54
+RTEMS_CLOCK_CODE_SIZE 334
+RTEMS_TIMER_CODE_SIZE 1,110
+RTEMS_SEMAPHORE_CODE_SIZE 1,632
+RTEMS_MESSAGE_CODE_SIZE 1,754
+RTEMS_EVENT_CODE_SIZE 1,000
+RTEMS_SIGNAL_CODE_SIZE 418
+RTEMS_PARTITION_CODE_SIZE 1,164
+RTEMS_REGION_CODE_SIZE 1,494
+RTEMS_DPMEM_CODE_SIZE 724
+RTEMS_IO_CODE_SIZE 686
+RTEMS_FATAL_ERROR_CODE_SIZE 24
+RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212
+RTEMS_MULTIPROCESSING_CODE_SIZE 6.952
+#  xxx alloted for numbers
+RTEMS_TIMER_CODE_OPTSIZE 184
+RTEMS_SEMAPHORE_CODE_OPTSIZE 172
+RTEMS_MESSAGE_CODE_OPTSIZE 288
+RTEMS_EVENT_CODE_OPTSIZE 56
+RTEMS_SIGNAL_CODE_OPTSIZE 56
+RTEMS_PARTITION_CODE_OPTSIZE 132
+RTEMS_REGION_CODE_OPTSIZE 160
+RTEMS_DPMEM_CODE_OPTSIZE 132
+RTEMS_IO_CODE_OPTSIZE 00
+RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184
+RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332
+#  xxx alloted for numbers
+RTEMS_BYTES_PER_TASK 400
+RTEMS_BYTES_PER_TIMER 68
+RTEMS_BYTES_PER_SEMAPHORE 124
+RTEMS_BYTES_PER_MESSAGE_QUEUE 148
+RTEMS_BYTES_PER_REGION 144
+RTEMS_BYTES_PER_PARTITION 56
+RTEMS_BYTES_PER_PORT 36
+RTEMS_BYTES_PER_PERIOD 36
+RTEMS_BYTES_PER_EXTENSION 64
+RTEMS_BYTES_PER_FP_TASK 332
+RTEMS_BYTES_PER_NODE 48
+RTEMS_BYTES_PER_GLOBAL_OBJECT 20
+RTEMS_BYTES_PER_PROXY 124
+#  x,xxx alloted for numbers
+RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872
diff --git a/doc/supplements/arm/ChangeLog b/doc/supplements/arm/ChangeLog
new file mode 100644
index 0000000000..b62a0bcbeb
--- /dev/null
+++ b/doc/supplements/arm/ChangeLog
@@ -0,0 +1,7 @@
+2002-07-30	Joel Sherrill <joel@OARcorp.com>
+
+	* BSP_TIMES, ChangeLog, Makefile.am, arm.texi, bsp.t, callconv.t,
+	cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t,
+	preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi,
+	wksheets.texi: New files as ARM supplement initial version added.
+
diff --git a/doc/supplements/arm/Makefile.am b/doc/supplements/arm/Makefile.am
new file mode 100644
index 0000000000..ba10564e53
--- /dev/null
+++ b/doc/supplements/arm/Makefile.am
@@ -0,0 +1,109 @@
+#
+#  COPYRIGHT (c) 1988-2002.
+#  On-Line Applications Research Corporation (OAR).
+#  All rights reserved.
+#
+#  $Id$
+#
+
+
+PROJECT = arm
+EDITION = 1
+
+include $(top_srcdir)/project.am
+include $(top_srcdir)/supplements/supplement.am
+
+GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
+    fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \
+    timeBSP.texi
+COMMON_FILES = $(top_srcdir)/common/setup.texi \
+    $(top_srcdir)/common/cpright.texi $(top_srcdir)/common/timemac.texi
+
+FILES = preface.texi
+
+info_TEXINFOS = arm.texi
+arm_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
+
+#
+#  Chapters which get automatic processing
+#
+
+$(srcdir)/cpumodel.texi: cpumodel.t
+	$(BMENU2) -p "Preface" \
+	    -u "Top" \
+	    -n "Calling Conventions" < $< > $@
+
+$(srcdir)/callconv.texi: callconv.t
+	$(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \
+	    -u "Top" \
+	    -n "Memory Model" < $< > $@
+
+$(srcdir)/memmodel.texi: memmodel.t
+	$(BMENU2) -p "Calling Conventions User-Provided Routines" \
+	    -u "Top" \
+	    -n "Interrupt Processing" < $< > $@
+
+# Interrupt Chapter:
+#  1.  Replace Times and Sizes
+#  2.  Build Node Structure
+$(srcdir)/intr.texi: intr_NOTIMES.t BSP_TIMES
+	${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t  | \
+	$(BMENU2) -p "Memory Model Flat Memory Model" \
+	    -u "Top" \
+	    -n "Default Fatal Error Processing" > $@
+
+$(srcdir)/fatalerr.texi: fatalerr.t
+	$(BMENU2) -p "Interrupt Processing Interrupt Stack" \
+	    -u "Top" \
+	    -n "Board Support Packages" < $< > $@
+
+$(srcdir)/bsp.texi: bsp.t
+	$(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
+	    -u "Top" \
+	    -n "Processor Dependent Information Table" < $< > $@
+
+$(srcdir)/cputable.texi: cputable.t
+	$(BMENU2) -p "Board Support Packages Processor Initialization" \
+	    -u "Top" \
+	    -n "Memory Requirements" < $< > $@
+
+# Worksheets Chapter:
+#  1.  Obtain the Shared File
+#  2.  Replace Times and Sizes
+#  3.  Build Node Structure
+
+$(srcdir)/wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES
+	${REPLACE2} -p $(srcdir)/BSP_TIMES \
+          $(top_srcdir)/common/wksheets.t | \
+	$(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
+	    -u "Top" \
+	    -n "Timing Specification" > $@
+
+# Timing Specification Chapter:
+#  1.  Copy the Shared File
+#  3.  Build Node Structure
+
+$(srcdir)/timing.texi: $(top_srcdir)/common/timing.t
+	$(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
+	    -u "Top" \
+	    -n "MYBSP Timing Data" < $< > $@
+
+# Timing Data for BSP BSP Chapter:
+#  1.  Copy the Shared File
+#  2.  Replace Times and Sizes
+#  3.  Build Node Structure
+
+$(srcdir)/timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t
+	cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t      >timeBSP_.t
+	@echo                                               >>timeBSP_.t
+	@echo "@tex"                                        >>timeBSP_.t
+	@echo "\\global\\advance \\smallskipamount by 4pt"  >>timeBSP_.t
+	@echo "@end tex"                                    >>timeBSP_.t
+	${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \
+	$(BMENU2) -p "Timing Specification Terminology" \
+	    -u "Top" \
+	    -n "Command and Variable Index" > $@
+CLEANFILES += timeBSP_.t
+
+EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
+    intr_NOTIMES.t memmodel.t timeBSP.t
diff --git a/doc/supplements/arm/arm.texi b/doc/supplements/arm/arm.texi
new file mode 100644
index 0000000000..12624f1e29
--- /dev/null
+++ b/doc/supplements/arm/arm.texi
@@ -0,0 +1,114 @@
+\input texinfo   @c -*-texinfo-*-
+@c %**start of header
+@setfilename arm
+@setcontentsaftertitlepage
+@syncodeindex vr fn
+@synindex ky cp
+@paragraphindent 0
+@c %**end of header
+
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@c
+@c   Master file for the ARM Applications Supplement
+@c
+
+@include version.texi
+@include common/setup.texi
+
+@ifset use-ascii
+@dircategory RTEMS Target Supplements
+@direntry
+* RTEMS ARM Applications Supplement: (arm).
+@end direntry
+@end ifset
+
+@c
+@c  Title Page Stuff
+@c
+
+@c
+@c  I don't really like having a short title page.  --joel
+@c
+@c @shorttitlepage RTEMS ARM Applications Supplement 
+
+@setchapternewpage odd
+@settitle RTEMS ARM Applications Supplement 
+@titlepage
+@finalout
+
+@title RTEMS ARM Applications Supplement 
+@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
+@sp 1
+@subtitle @value{UPDATED}
+@author On-Line Applications Research Corporation
+@page
+
+@include common/cpright.texi
+@end titlepage
+
+@c  This prevents a black box from being printed on "overflow" lines.
+@c  The alternative is to rework a sentence to avoid this problem.
+
+@include preface.texi
+@include cpumodel.texi
+@include callconv.texi
+@include memmodel.texi
+@include intr.texi
+@include fatalerr.texi
+@include bsp.texi
+@include cputable.texi
+@include wksheets.texi
+@include timing.texi
+@include timeBSP.texi
+@ifinfo
+@node Top, Preface, (dir), (dir)
+@top arm
+
+This is the online version of the RTEMS ARM
+Applications Supplement.
+
+@menu
+* Preface::
+* CPU Model Dependent Features::
+* Calling Conventions::
+* Memory Model::
+* Interrupt Processing::
+* Default Fatal Error Processing::
+* Board Support Packages::
+* Processor Dependent Information Table::
+* Memory Requirements::
+* Timing Specification::
+* MYBSP Timing Data::
+* Command and Variable Index::
+* Concept Index::
+@end menu
+
+@end ifinfo
+@c 
+@c 
+@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
+@c
+
+@node Command and Variable Index, Concept Index, MYBSP Timing Data Rate Monotonic Manager, Top
+@unnumbered Command and Variable Index
+
+There are currently no Command and Variable Index entries.
+
+@c @printindex fn
+
+@node Concept Index, , Command and Variable Index, Top
+@unnumbered Concept Index
+
+There are currently no Concept Index entries.
+@c @printindex cp
+
+@contents
+@bye
+
diff --git a/doc/supplements/arm/bsp.t b/doc/supplements/arm/bsp.t
new file mode 100644
index 0000000000..657c359a96
--- /dev/null
+++ b/doc/supplements/arm/bsp.t
@@ -0,0 +1,93 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@chapter Board Support Packages
+
+@section Introduction
+
+An RTEMS Board Support Package (BSP) must be designed
+to support a particular processor and target board combination.
+This chapter presents a discussion of XXX specific BSP
+issues.   For more information on developing a BSP, refer to the
+chapter titled Board Support Packages in the RTEMS
+Applications User's Guide.
+
+@section System Reset
+
+An RTEMS based application is initiated or
+re-initiated when the XXX processor is reset.  When the
+XXX is reset, the processor performs the following actions:
+
+@itemize @bullet
+@item The tracing bits of the status register are cleared to
+disable tracing.
+
+@item The supervisor interrupt state is entered by setting the
+supervisor (S) bit and clearing the master/interrupt (M) bit of
+the status register.
+
+@item The interrupt mask of the status register is set to
+level 7 to effectively disable all maskable interrupts.
+
+@item The vector base register (VBR) is set to zero.
+
+@item The cache control register (CACR) is set to zero to
+disable and freeze the processor cache.
+
+@item The interrupt stack pointer (ISP) is set to the value
+stored at vector 0 (bytes 0-3) of the exception vector table
+(EVT).
+
+@item The program counter (PC) is set to the value stored at
+vector 1 (bytes 4-7) of the EVT.
+
+@item The processor begins execution at the address stored in
+the PC.
+@end itemize
+
+@section Processor Initialization
+
+The address of the application's initialization code
+should be stored in the first vector of the EVT which will allow
+the immediate vectoring to the application code.  If the
+application requires that the VBR be some value besides zero,
+then it should be set to the required value at this point.  All
+tasks share the same XXX's VBR value.  Because interrupts
+are enabled automatically by RTEMS as part of the initialize
+executive directive, the VBR MUST be set before this directive
+is invoked to insure correct interrupt vectoring.  If processor
+caching is to be utilized, then it should be enabled during the
+reset application initialization code.
+
+In addition to the requirements described in the
+Board Support Packages chapter of the Applications User's
+Manual for the reset code which is executed before the call to
+initialize executive, the XXX version has the following
+specific requirements:
+
+@itemize @bullet
+@item Must leave the S bit of the status register set so that
+the XXX remains in the supervisor state.
+
+@item Must set the M bit of the status register to remove the
+XXX from the interrupt state.
+
+@item Must set the master stack pointer (MSP) such that a
+minimum stack size of MINIMUM_STACK_SIZE bytes is provided for
+the initialize executive directive.
+
+@item Must initialize the XXX's vector table.
+@end itemize
+
+Note that the BSP is not responsible for allocating
+or installing the interrupt stack.  RTEMS does this
+automatically as part of initialization.  If the BSP does not
+install an interrupt stack and -- for whatever reason -- an
+interrupt occurs before initialize_executive is invoked, then
+the results are unpredictable.
+
diff --git a/doc/supplements/arm/callconv.t b/doc/supplements/arm/callconv.t
new file mode 100644
index 0000000000..167f5b8fa5
--- /dev/null
+++ b/doc/supplements/arm/callconv.t
@@ -0,0 +1,73 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@chapter Calling Conventions
+
+@section Introduction
+
+Each high-level language compiler generates
+subroutine entry and exit code based upon a set of rules known
+as the compiler's calling convention.   These rules address the
+following issues:
+
+@itemize @bullet
+@item register preservation and usage
+@item parameter passing
+@item call and return mechanism
+@end itemize
+
+A compiler's calling convention is of importance when
+interfacing to subroutines written in another language either
+assembly or high-level.  Even when the high-level language and
+target processor are the same, different compilers may use
+different calling conventions.  As a result, calling conventions
+are both processor and compiler dependent.
+
+@section Processor Background
+
+The ARM architecture supports a simple yet
+effective call and return mechanism.  A subroutine is invoked
+via the branch and link (@code{bl}) instruction.  This instruction
+saves the return address in the @code{lr} register.  Returning
+from a subroutine only requires that the return address be
+moved into the program counter (@code{pc}), possibly with
+an offset.  It is is important to
+note that the @code{bl} instruction does not
+automatically save or restore any registers.  It is the
+responsibility of the high-level language compiler to define the
+register preservation and usage convention.
+
+@section Calling Mechanism
+
+All RTEMS directives are invoked using the @code{bl}
+instruction and return to the user application via the
+mechanism described above.
+
+@section Register Usage
+
+As discussed above, the ARM's call and return mechanism dos
+not automatically save any registers.  RTEMS uses the registers
+@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and
+per ARM calling convention, the @code{lr} register is altered
+as well.  These registers are not preserved by RTEMS directives
+therefore, the contents of these registers should not be assumed
+upon return from any RTEMS directive. 
+
+@section Parameter Passing
+
+RTEMS assumes that ARM calling conventions are followed and that
+the first four arguments are placed in registers @code{r0} through
+@code{r3}.  If there are more arguments, than that, then they
+are place on the stack.
+
+@section User-Provided Routines
+
+All user-provided routines invoked by RTEMS, such as
+user extensions, device drivers, and MPCI routines, must also
+adhere to these calling conventions.
+
diff --git a/doc/supplements/arm/cpumodel.t b/doc/supplements/arm/cpumodel.t
new file mode 100644
index 0000000000..c19b879d49
--- /dev/null
+++ b/doc/supplements/arm/cpumodel.t
@@ -0,0 +1,85 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@chapter CPU Model Dependent Features
+
+@section Introduction
+
+Microprocessors are generally classified into
+families with a variety of CPU models or implementations within
+that family.  Within a processor family, there is a high level
+of binary compatibility.  This family may be based on either an
+architectural specification or on maintaining compatibility with
+a popular processor.  Recent microprocessor families such as the
+ARM, SPARC, and PA-RISC are based on an architectural specification
+which is independent or any particular CPU model or
+implementation.  Older families such as the M68xxx and the iX86
+evolved as the manufacturer strived to produce higher
+performance processor models which maintained binary
+compatibility with older models.
+
+RTEMS takes advantage of the similarity of the
+various models within a CPU family.  Although the models do vary
+in significant ways, the high level of compatibility makes it
+possible to share the bulk of the CPU dependent executive code
+across the entire family.  Each processor family supported by
+RTEMS has a list of features which vary between CPU models
+within a family.  For example, the most common model dependent
+feature regardless of CPU family is the presence or absence of a
+floating point unit or coprocessor.  When defining the list of
+features present on a particular CPU model, one simply notes
+that floating point hardware is or is not present and defines a
+single constant appropriately.  Conditional compilation is
+utilized to include the appropriate source code for this CPU
+model's feature set.  It is important to note that this means
+that RTEMS is thus compiled using the appropriate feature set
+and compilation flags optimal for this CPU model used.  The
+alternative would be to generate a binary which would execute on
+all family members using only the features which were always
+present.
+
+This chapter presents the set of features which vary
+across ARM implementations and are of importance to RTEMS.
+The set of CPU model feature macros are defined in the file
+cpukit/score/cpu/arm/rtems/score/arm.h based upon the particular CPU
+model defined on the compilation command line.
+
+@section CPU Model Name
+
+The macro @code{CPU_MODEL_NAME} is a string which designates
+the architectural level of this CPU model.  The following is
+a list of the settings for this string based upon @code{gcc}
+CPU model predefines:
+
+@example
+__ARM_ARCH4__   "ARMv4"
+__ARM_ARCH4T__  "ARMv4T"
+__ARM_ARCH5__   "ARMv5"
+__ARM_ARCH5T__  "ARMv5T"
+__ARM_ARCH5E__  "ARMv5E"
+__ARM_ARCH5TE__ "ARMv5TE"
+@end example
+
+@section Count Leading Zeroes Instruction
+
+The macro @code{ARM_HAS_CLZ} is set to 1 to indicate that
+the architectural version has the @code{clz} instruction.
+On ARM architectural version 5 and above, the count
+leading zeroes instruction (@code{clz}) is available and
+can be used to speed up the find first bit operation.  
+The use of this instruction significantly speeds up the
+scheduling associated with a thread blocking.
+
+@section Floating Point Unit
+
+The macro ARM_HAS_FPU is set to 1 to indicate that
+this CPU model has a hardware floating point unit and 0
+otherwise.  It does not matter whether the hardware floating
+point support is incorporated on-chip or is an external
+coprocessor.
+
diff --git a/doc/supplements/arm/cputable.t b/doc/supplements/arm/cputable.t
new file mode 100644
index 0000000000..75d0fc15f6
--- /dev/null
+++ b/doc/supplements/arm/cputable.t
@@ -0,0 +1,109 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@chapter Processor Dependent Information Table
+
+@section Introduction
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table.  This table is not required for all
+processors supported by RTEMS.  This chapter describes the
+contents, if any, for a particular processor type.
+
+@section CPU Dependent Information Table
+
+The XXX version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the XXX.  This
+information is provided to allow RTEMS to interoperate
+effectively with the BSP.  The C structure definition is given
+here:
+
+@example
+@group
+typedef struct @{
+  void       (*pretasking_hook)( void );
+  void       (*predriver_hook)( void );
+  void       (*postdriver_hook)( void );
+  void       (*idle_task)( void );
+  boolean      do_zero_of_workspace;
+  unsigned32   idle_task_stack_size;
+  unsigned32   interrupt_stack_size;
+  unsigned32   extra_mpci_receive_server_stack;
+  void *     (*stack_allocate_hook)( unsigned32 );
+  void       (*stack_free_hook)( void* );
+  /* end of fields required on all CPUs */
+
+  /* XXX CPU family dependent stuff */
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized.  This routine will be invoked
+before any system tasks are created.  Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task.  If
+this field is not NULL, then the RTEMS default IDLE task is not
+used.  This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization.  If set to
+TRUE, the Workspace is zeroed.  Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.  
+If this number is less than MINIMUM_STACK_SIZE, then the 
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes.  This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes.  The MPCI receive server may invoke nearly all directives and 
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates 
+memory for task stacks.  If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees 
+memory for task stacks.  If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item XXX
+is where the CPU family dependent stuff goes.
+
+@end table
diff --git a/doc/supplements/arm/fatalerr.t b/doc/supplements/arm/fatalerr.t
new file mode 100644
index 0000000000..8a703718ea
--- /dev/null
+++ b/doc/supplements/arm/fatalerr.t
@@ -0,0 +1,37 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@chapter Default Fatal Error Processing
+
+@section Introduction
+
+Upon detection of a fatal error by either the
+application or RTEMS the fatal error manager is invoked.  The
+fatal error manager will invoke the user-supplied fatal error
+handlers.  If no user-supplied handlers are configured,  the
+RTEMS provided default fatal error handler is invoked.  If the
+user-supplied fatal error handlers return to the executive the
+default fatal error handler is then invoked.  This chapter
+describes the precise operations of the default fatal error
+handler.
+
+@section Default Fatal Error Handler Operations
+
+The default fatal error handler which is invoked by
+the @code{rtems_fatal_error_occurred} directive when there is
+no user handler configured or the user handler returns control to
+RTEMS.  The default fatal error handler performs the
+following actions:
+
+@itemize @bullet
+@item disables processor interrupts,
+@item places the error code in @b{r0}, and
+@item executes an infinite loop (@code{while(0);} to
+simulate a halt processor instruction.
+@end itemize
+
diff --git a/doc/supplements/arm/intr_NOTIMES.t b/doc/supplements/arm/intr_NOTIMES.t
new file mode 100644
index 0000000000..4efc1d80b4
--- /dev/null
+++ b/doc/supplements/arm/intr_NOTIMES.t
@@ -0,0 +1,196 @@
+@c
+@c  Interrupt Stack Frame Picture
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@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
+RTEMS.
+
+@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
+switched.
+
+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
+@example
+@group
+               +----------------------+
+               |    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
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\strut\vrule#&
+\hbox to 2.00in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 0.50in{\enskip\hfil#\hfil}
+\cr
+\multispan{3}\hrulefill\cr
+& Status Register && 0x0\cr
+\multispan{3}\hrulefill\cr
+& Program Counter High && 0x2\cr
+\multispan{3}\hrulefill\cr
+& Program Counter Low && 0x4\cr
+\multispan{3}\hrulefill\cr
+& Format/Vector Offset && 0x6\cr
+\multispan{3}\hrulefill\cr
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+  <TABLE COLS=2 WIDTH="40%" BORDER=2>
+<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>
+</CENTER>
+@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
+unpredictable.
+
+@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 
+RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 
+RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor with 
+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 
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
+
+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/arm/memmodel.t b/doc/supplements/arm/memmodel.t
new file mode 100644
index 0000000000..bf543364c7
--- /dev/null
+++ b/doc/supplements/arm/memmodel.t
@@ -0,0 +1,38 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@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
+
+Members of the ARM family newer than Version 3 support 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 the endian
+mode that the processor is configured for.   In general, ARM
+processors are used in little endian mode.
+
+Some of the ARM family members such as the 
+920 and 720 include an MMU and thus support virtual memory and
+segmentation.  RTEMS does not support virtual memory or
+segmentation on any of the ARM family members.
+
diff --git a/doc/supplements/arm/preface.texi b/doc/supplements/arm/preface.texi
new file mode 100644
index 0000000000..27bb11a558
--- /dev/null
+++ b/doc/supplements/arm/preface.texi
@@ -0,0 +1,49 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@ifinfo
+@node Preface, CPU Model Dependent Features, Top, Top
+@end ifinfo
+@unnumbered Preface
+
+The Real Time Executive for Multiprocessor Systems (RTEMS)
+is designed to be portable across multiple processor
+architectures.  However, the nature of real-time systems makes
+it essential that the application designer understand certain
+processor dependent implementation details.  These processor
+dependencies include calling convention, board support package
+issues, interrupt processing, exact RTEMS memory requirements,
+performance data, header files, and the assembly language
+interface to the executive.
+
+This document discusses the ARM architecture dependencies
+in this port of RTEMS.  The ARM family has a wide variety
+of implementations by a wide range of vendors.  Consequently,
+there are 100's of CPU models within it.
+
+It is highly recommended that the ARM
+RTEMS application developer obtain and become familiar with the
+documentation for the processor being used as well as the
+documentation for the ARM architecture as a whole.
+
+@subheading Architecture Documents
+
+For information on the ARM architecture,
+refer to the following documents available from Arm, Limited
+(@file{http//www.arm.com/}).  There does not appear to
+be an electronic version of a manual on the architecture
+in general on that site.  The following book is a good 
+resource:
+
+@itemize @bullet
+@item @cite{David Seal. "ARM Architecture Reference Manual."
+Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.}
+
+@end itemize
+
+
diff --git a/doc/supplements/arm/stamp-vti b/doc/supplements/arm/stamp-vti
new file mode 100644
index 0000000000..e7474b6acc
--- /dev/null
+++ b/doc/supplements/arm/stamp-vti
@@ -0,0 +1,4 @@
+@set UPDATED 30 July 2002
+@set UPDATED-MONTH July 2002
+@set EDITION ss-20020717
+@set VERSION ss-20020717
diff --git a/doc/supplements/arm/timeBSP.t b/doc/supplements/arm/timeBSP.t
new file mode 100644
index 0000000000..742272f775
--- /dev/null
+++ b/doc/supplements/arm/timeBSP.t
@@ -0,0 +1,113 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@include common/timemac.texi
+@tex
+\global\advance \smallskipamount by -4pt
+@end tex
+
+@chapter MYBSP Timing Data
+
+@section Introduction
+
+The timing data for the ARM version of RTEMS is
+provided along with the target dependent aspects concerning the
+gathering of the timing data.  The hardware platform used to
+gather the times is described to give the reader a better
+understanding of each directive time provided.  Also, provided
+is a description of the interrupt latency and the context switch
+times as they pertain to the ARM version of RTEMS.
+
+@section Hardware Platform
+
+All times reported except for the maximum period
+interrupts are disabled by RTEMS were measured using a Motorola
+MYBSP CPU board.  The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
+Mhz board with SDRAM and no numeric coprocessor.  A
+countdown timer on this board was used to measure
+elapsed time with a 20 nanosecond resolution.  All
+sources of hardware interrupts were disabled, although the
+interrupt level of the ARM microprocessor allows all interrupts.
+
+The maximum period interrupts are disabled was
+measured by summing the number of CPU cycles required by each
+assembly language instruction executed while interrupts were
+disabled.  The worst case times of the ARM9DTMI microprocessor
+were used for each instruction.  Zero wait state memory was
+assumed.  The total CPU cycles executed with interrupts
+disabled, including the instructions to disable and enable
+interrupts, was divided by TBD to simulate a TBD Mhz processor.  It
+should be noted that the worst case instruction times 
+assume that the internal cache is disabled and that no
+instructions overlap.
+
+@section Interrupt Latency
+
+The maximum period with interrupts disabled within
+RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD 
+microseconds including the instructions
+which disable and re-enable interrupts.  The time required for
+the processor to vector an interrupt and for the RTEMS entry
+overhead before invoking the user's interrupt handler are a
+total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 
+microseconds.  These combine to yield a worst case
+interrupt latency of less than 
+RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 
+microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
+Mhz.  [NOTE:  The maximum period with interrupts
+disabled was last determined for Release 
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
+
+It should be noted again that the maximum period with
+interrupts disabled within RTEMS is hand-timed and based upon
+worst case (i.e. CPU cache disabled and no instruction overlap)
+times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor.  
+The interrupt vector and entry
+overhead time was generated on an MYBSP benchmark platform
+using the Multiprocessing Communications registers to generate
+as the interrupt source.
+
+@section Context Switch
+
+The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
+microseconds on the MYBSP benchmark platform when no floating
+point context is saved or restored.  Additional execution time
+is required when a TASK_SWITCH user extension is configured.
+The use of the TASK_SWITCH extension is application dependent.
+Thus, its execution time is not considered part of the raw
+context switch time.
+
+The ARM processor benchmarked does not have a floating point
+unit and consequently no FPU results are reported.
+
+@c Since RTEMS was designed specifically for embedded
+@c missile applications which are floating point intensive, the
+@c executive is optimized to avoid unnecessarily saving and
+@c restoring the state of the numeric coprocessor.  The state of
+@c the numeric coprocessor is only saved when an FLOATING_POINT
+@c task is dispatched and that task was not the last task to
+@c utilize the coprocessor.  In a system with only one
+@c FLOATING_POINT task, the state of the numeric coprocessor will
+@c never be saved or restored.  When the first FLOATING_POINT task
+@c is dispatched, RTEMS does not need to save the current state of
+@c the numeric coprocessor.
+
+@c The exact amount of time required to save and restore
+@c floating point context is dependent on whether an XXX or
+@c XXX is being used as well as the state of the numeric
+@c coprocessor.  These numeric coprocessors define three operating
+@c states: initialized, idle, and busy.  RTEMS places the
+@c coprocessor in the initialized state when a task is started or
+@c restarted.  Once the task has utilized the coprocessor, it is in
+@c the idle state when floating point instructions are not
+@c executing and the busy state when floating point instructions
+@c are executing.  The state of the coprocessor is task specific.
+
+The following table summarizes the context switch
+times for the MYBSP benchmark platform:
+
diff --git a/doc/supplements/arm/timing.texi b/doc/supplements/arm/timing.texi
new file mode 100644
index 0000000000..302a1391a8
--- /dev/null
+++ b/doc/supplements/arm/timing.texi
@@ -0,0 +1,460 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+
+@node Timing Specification, Timing Specification Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
+
+@chapter Timing Specification
+@ifinfo
+@menu
+* Timing Specification Introduction::
+* Timing Specification Philosophy::
+* Timing Specification Methodology::
+@end menu
+@end ifinfo
+
+
+@node Timing Specification Introduction, Timing Specification Philosophy, Timing Specification, Timing Specification
+
+@section Introduction
+
+This chapter provides information pertaining to the
+measurement of the performance of RTEMS, the methods of
+gathering the timing data, and the usefulness of the data.  Also
+discussed are other time critical aspects of RTEMS that affect
+an applications design and ultimate throughput.  These aspects
+include determinancy, interrupt latency and context switch times.
+
+
+@node Timing Specification Philosophy, Timing Specification Determinancy, Timing Specification Introduction, Timing Specification
+
+@section Philosophy
+@ifinfo
+@menu
+* Timing Specification Determinancy::
+* Timing Specification Interrupt Latency::
+* Timing Specification Context Switch Time::
+* Timing Specification Directive Times::
+@end menu
+@end ifinfo
+
+Benchmarks are commonly used to evaluate the
+performance of software and hardware.  Benchmarks can be an
+effective tool when comparing systems.  Unfortunately,
+benchmarks can also be manipulated to justify virtually any
+claim.  Benchmarks of real-time executives are difficult to
+evaluate for a variety of reasons.  Executives vary in the
+robustness of features and options provided.  Even when
+executives compare favorably in functionality, it is quite
+likely that different methodologies were used to obtain the
+timing data.  Another problem is that some executives provide
+times for only a small subset of directives,  This is typically
+justified by claiming that these are the only time-critical
+directives.  The performance of some executives is also very
+sensitive to the number of objects in the system.  To obtain any
+measure of usefulness, the performance information provided for
+an executive should address each of these issues.
+
+When evaluating the performance of a real-time
+executive, one typically considers the following areas:
+determinancy, directive times, worst case interrupt latency, and
+context switch time.  Unfortunately, these areas do not have
+standard measurement methodologies.  This allows vendors to
+manipulate the results such that their product is favorably
+represented.  We have attempted to provide useful and meaningful
+timing information for RTEMS.  To insure the usefulness of our
+data, the methodology and definitions used to obtain and
+describe the data are also documented.
+
+
+@node Timing Specification Determinancy, Timing Specification Interrupt Latency, Timing Specification Philosophy, Timing Specification Philosophy
+
+@subsection Determinancy
+
+The correctness of data in a real-time system must
+always be judged by its timeliness.  In many real-time systems,
+obtaining the correct answer does not necessarily solve the
+problem.  For example, in a nuclear reactor it is not enough to
+determine that the core is overheating.  This situation must be
+detected and acknowledged early enough that corrective action
+can be taken and a meltdown avoided.
+
+Consequently, a system designer must be able to
+predict the worst-case behavior of the application running under
+the selected executive.  In this light, it is important that a
+real-time system perform consistently regardless of the number
+of tasks, semaphores, or other resources allocated.  An
+important design goal of a real-time executive is that all
+internal algorithms be fixed-cost.  Unfortunately, this goal is
+difficult to completely meet without sacrificing the robustness
+of the executive's feature set.
+
+Many executives use the term deterministic to mean
+that the execution times of their services can be predicted.
+However, they often provide formulas to modify execution times
+based upon the number of objects in the system.  This usage is
+in sharp contrast to the notion of deterministic meaning fixed
+cost.
+
+Almost all RTEMS directives execute in a fixed amount
+of time regardless of the number of objects present in the
+system.  The primary exception occurs when a task blocks while
+acquiring a resource and specifies a non-zero timeout interval.
+
+Other exceptions are message queue broadcast,
+obtaining a variable length memory block, object name to ID
+translation, and deleting a resource upon which tasks are
+waiting.  In addition, the time required to service a clock tick
+interrupt is based upon the number of timeouts and other
+"events" which must be processed at that tick.  This second
+group is composed primarily of capabilities which are inherently
+non-deterministic but are infrequently used in time critical
+situations.  The major exception is that of servicing a clock
+tick.  However, most applications have a very small number of
+timeouts which expire at exactly the same millisecond (usually
+none, but occasionally two or three).
+
+
+@node Timing Specification Interrupt Latency, Timing Specification Context Switch Time, Timing Specification Determinancy, Timing Specification Philosophy
+
+@subsection Interrupt Latency
+
+Interrupt latency is the delay between the CPU's
+receipt of an interrupt request and the execution of the first
+application-specific instruction in an interrupt service
+routine.  Interrupts are a critical component of most real-time
+applications and it is critical that they be acted upon as
+quickly as possible.
+
+Knowledge of the worst case interrupt latency of an
+executive aids the application designer in determining the
+maximum period of time between the generation of an interrupt
+and an interrupt handler responding to that interrupt.  The
+interrupt latency of an system is the greater of the executive's
+and the applications's interrupt latency.  If the application
+disables interrupts longer than the executive, then the
+application's interrupt latency is the system's worst case
+interrupt disable period.
+
+The worst case interrupt latency for a real-time
+executive is based upon the following components:
+
+@itemize @bullet
+@item the longest period of time interrupts are disabled
+by the executive,
+
+@item the overhead required by the executive at the
+beginning of each ISR,
+
+@item the time required for the CPU to vector the
+interrupt, and
+
+@item for some microprocessors, the length of the longest
+instruction.
+@end itemize
+
+The first component is irrelevant if an interrupt
+occurs when interrupts are enabled, although it must be included
+in a worst case analysis.  The third and fourth components are
+particular to a CPU implementation and are not dependent on the
+executive.  The fourth component is ignored by this document
+because most applications use only a subset of a
+microprocessor's instruction set.  Because of this the longest
+instruction actually executed is application dependent.  The
+worst case interrupt latency of an executive is typically
+defined as the sum of components (1) and (2).  The second
+component includes the time necessry for RTEMS to save registers
+and vector to the user-defined handler.  RTEMS includes the
+third component, the time required for the CPU to vector the
+interrupt, because it is a required part of any interrupt.
+
+Many executives report the maximum interrupt disable
+period as their interrupt latency and ignore the other
+components.  This results in very low worst-case interrupt
+latency times which are not indicative of actual application
+performance.  The definition used by RTEMS results in a higher
+interrupt latency being reported, but accurately reflects the
+longest delay between the CPU's receipt of an interrupt request
+and the execution of the first application-specific instruction
+in an interrupt service routine.
+
+The actual interrupt latency times are reported in
+the Timing Data chapter of this supplement.
+
+
+@node Timing Specification Context Switch Time, Timing Specification Directive Times, Timing Specification Interrupt Latency, Timing Specification Philosophy
+
+@subsection Context Switch Time
+
+An RTEMS context switch is defined as the act of
+taking the CPU from the currently executing task and giving it
+to another task.  This process involves the following components:
+
+@itemize @bullet
+@item Saving the hardware state of the current task.
+
+@item Optionally, invoking the TASK_SWITCH user extension.
+
+@item Restoring the hardware state of the new task.
+@end itemize
+
+RTEMS defines the hardware state of a task to include
+the CPU's data registers, address registers, and, optionally,
+floating point registers.
+
+Context switch time is often touted as a performance
+measure of real-time executives.  However, a context switch is
+performed as part of a directive's actions and should be viewed
+as such when designing an application.  For example, if a task
+is unable to acquire a semaphore and blocks, a context switch is
+required to transfer control from the blocking task to a new
+task.  From the application's perspective, the context switch is
+a direct result of not acquiring the semaphore.  In this light,
+the context switch time is no more relevant than the performance
+of any other of the executive's subroutines which are not
+directly accessible by the application.
+
+In spite of the inappropriateness of using the
+context switch time as a performance metric, RTEMS context
+switch times for floating point and non-floating points tasks
+are provided for comparison purposes.  Of the executives which
+actually support floating point operations, many do not report
+context switch times for floating point context switch time.
+This results in a reported context switch time which is
+meaningless for an application with floating point tasks.
+
+The actual context switch times are reported in the
+Timing Data chapter of this supplement.
+
+
+@node Timing Specification Directive Times, Timing Specification Methodology, Timing Specification Context Switch Time, Timing Specification Philosophy
+
+@subsection Directive Times
+
+Directives are the application's interface to the
+executive, and as such their execution times are critical in
+determining the performance of the application.  For example, an
+application using a semaphore to protect a critical data
+structure should be aware of the time required to acquire and
+release a semaphore.  In addition, the application designer can
+utilize the directive execution times to evaluate the
+performance of different synchronization and communication
+mechanisms.
+
+The actual directive execution times are reported in
+the Timing Data chapter of this supplement.
+
+
+@node Timing Specification Methodology, Timing Specification Software Platform, Timing Specification Directive Times, Timing Specification
+
+@section Methodology
+@ifinfo
+@menu
+* Timing Specification Software Platform::
+* Timing Specification Hardware Platform::
+* Timing Specification What is measured?::
+* Timing Specification What is not measured?::
+* Timing Specification Terminology::
+@end menu
+@end ifinfo
+
+
+@node Timing Specification Software Platform, Timing Specification Hardware Platform, Timing Specification Methodology, Timing Specification Methodology
+
+@subsection Software Platform
+
+The RTEMS timing suite is written in C.  The overhead
+of passing arguments to RTEMS by C is not timed.  The times
+reported represent the amount of time from entering to exiting
+RTEMS.
+
+The tests are based upon one of two execution models:
+(1) single invocation times, and (2) average times of repeated
+invocations.  Single invocation times are provided for
+directives which cannot easily be invoked multiple times in the
+same scenario.  For example, the times reported for entering and
+exiting an interrupt service routine are single invocation
+times.  The second model is used for directives which can easily
+be invoked multiple times in the same scenario.  For example,
+the times reported for semaphore obtain and semaphore release
+are averages of multiple invocations.  At least 100 invocations
+are used to obtain the average.
+
+
+@node Timing Specification Hardware Platform, Timing Specification What is measured?, Timing Specification Software Platform, Timing Specification Methodology
+
+@subsection Hardware Platform
+
+Since RTEMS supports a variety of processors, the
+hardware platform used to gather the benchmark times must also
+vary.  Therefore, for each processor supported the hardware
+platform must be defined.  Each definition will include a brief
+description of the target hardware platform including the clock
+speed, memory wait states encountered, and any other pertinent
+information.  This definition may be found in the processor
+dependent timing data chapter within this supplement.
+
+
+@node Timing Specification What is measured?, Timing Specification What is not measured?, Timing Specification Hardware Platform, Timing Specification Methodology
+
+@subsection What is measured?
+
+An effort was made to provide execution times for a
+large portion of RTEMS.  Times were provided for most directives
+regardless of whether or not they are typically used in time
+critical code.  For example, execution times are provided for
+all object create and delete directives, even though these are
+typically part of application initialization.
+
+The times include all RTEMS actions necessary in a
+particular scenario.  For example, all times for blocking
+directives include the context switch necessary to transfer
+control to a new task.  Under no circumstances is it necessary
+to add context switch time to the reported times.
+
+The following list describes the objects created by
+the timing suite:
+
+@itemize @bullet
+@item All tasks are non-floating point.
+
+@item All tasks are created as local objects.
+
+@item No timeouts are used on blocking directives.
+
+@item All tasks wait for objects in FIFO order.
+
+@end itemize
+
+In addition, no user extensions are configured.
+
+
+@node Timing Specification What is not measured?, Timing Specification Terminology, Timing Specification What is measured?, Timing Specification Methodology
+
+@subsection What is not measured?
+
+The times presented in this document are not intended
+to represent best or worst case times, nor are all directives
+included.  For example, no times are provided for the initialize
+executive and fatal_error_occurred directives.  Other than the
+exceptions detailed in the Determinancy section, all directives
+will execute in the fixed length of time given.
+
+Other than entering and exiting an interrupt service
+routine, all directives were executed from tasks and not from
+interrupt service routines.  Directives invoked from ISRs, when
+allowable, will execute in slightly less time than when invoked
+from a task because rescheduling is delayed until the interrupt
+exits.
+
+
+@node Timing Specification Terminology, MYBSP Timing Data, Timing Specification What is not measured?, Timing Specification Methodology
+
+@subsection Terminology
+
+The following is a list of phrases which are used to
+distinguish individual execution paths of the directives taken
+during the RTEMS performance analysis:
+
+@table @b
+@item another task
+The directive was performed
+on a task other than the calling task.
+
+@item available
+A task attempted to obtain a resource and
+immediately acquired it.
+
+@item blocked task
+The task operated upon by the
+directive was blocked waiting for a resource.
+
+@item caller blocks
+The requested resoure was not
+immediately available and the calling task chose to wait.
+
+@item calling task
+The task invoking the directive.
+
+@item messages flushed
+One or more messages was flushed
+from the message queue.
+
+@item no messages flushed
+No messages were flushed from
+the message queue.
+
+@item not available
+A task attempted to obtain a resource
+and could not immediately acquire it.
+
+@item no reschedule
+The directive did not require a
+rescheduling operation.
+
+@item NO_WAIT
+A resource was not available and the
+calling task chose to return immediately via the NO_WAIT option
+with an error.
+
+@item obtain current
+The current value of something was
+requested by the calling task.
+
+@item preempts caller
+The release of a resource caused a
+task of higher priority than the calling to be readied and it
+became the executing task.
+
+@item ready task
+The task operated upon by the directive
+was in the ready state.
+
+@item reschedule
+The actions of the directive
+necessitated a rescheduling operation.
+
+@item returns to caller
+The directive succeeded and
+immediately returned to the calling task.
+
+@item returns to interrupted task
+The instructions
+executed immediately following this interrupt will be in the
+interrupted task.
+
+@item returns to nested interrupt
+The instructions
+executed immediately following this interrupt will be in a
+previously interrupted ISR.
+
+@item returns to preempting task
+The instructions
+executed immediately following this interrupt or signal handler
+will be in a task other than the interrupted task.
+
+@item signal to self
+The signal set was sent to the
+calling task and signal processing was enabled.
+
+@item suspended task
+The task operated upon by the
+directive was in the suspended state.
+
+@item task readied
+The release of a resource caused a
+task of lower or equal priority to be readied and the calling
+task remained the executing task.
+
+@item yield
+The act of attempting to voluntarily release
+the CPU.
+
+@end table
+
+
diff --git a/doc/supplements/arm/version.texi b/doc/supplements/arm/version.texi
new file mode 100644
index 0000000000..e7474b6acc
--- /dev/null
+++ b/doc/supplements/arm/version.texi
@@ -0,0 +1,4 @@
+@set UPDATED 30 July 2002
+@set UPDATED-MONTH July 2002
+@set EDITION ss-20020717
+@set VERSION ss-20020717
diff --git a/doc/supplements/arm/wksheets.texi b/doc/supplements/arm/wksheets.texi
new file mode 100644
index 0000000000..dd7dcd74b1
--- /dev/null
+++ b/doc/supplements/arm/wksheets.texi
@@ -0,0 +1,437 @@
+@c ******   This comment is here to remind you not to edit the wksheets.t
+@c ******   in any directory but common.
+@c
+@c Figures ...
+@c   RTEMS RAM Workspace Worksheet
+@c   RTEMS Code Space Worksheet
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+
+@node Memory Requirements, Memory Requirements Introduction, Processor Dependent Information Table CPU Dependent Information Table, Top
+
+@chapter Memory Requirements
+@ifinfo
+@menu
+* Memory Requirements Introduction::
+* Memory Requirements Data Space Requirements::
+* Memory Requirements Minimum and Maximum Code Space Requirements::
+* Memory Requirements RTEMS Code Space Worksheet::
+* Memory Requirements RTEMS RAM Workspace Worksheet::
+@end menu
+@end ifinfo
+
+
+@node Memory Requirements Introduction, Memory Requirements Data Space Requirements, Memory Requirements, Memory Requirements
+
+@section Introduction
+
+Memory is typically a limited resource in real-time
+embedded systems, therefore, RTEMS can be configured  to utilize
+the minimum amount of memory while meeting all of the
+applications requirements.  Worksheets are provided which allow
+the RTEMS application developer to determine the amount of RTEMS
+code and RAM workspace which is required by the particular
+configuration.  Also provided are the minimum code space,
+maximum code space,  and the constant data space required by
+RTEMS.
+
+
+@node Memory Requirements Data Space Requirements, Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements Introduction, Memory Requirements
+
+@section Data Space Requirements
+
+RTEMS requires a small amount of memory for its
+private variables.  This data area must be in RAM and is
+separate from the RTEMS RAM Workspace.  The following
+illustrates the data space required for all configurations of
+RTEMS:
+
+@itemize @bullet
+@item Data Space: 723
+@end itemize
+
+
+@node Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements RTEMS Code Space Worksheet, Memory Requirements Data Space Requirements, Memory Requirements
+
+@section Minimum and Maximum Code Space Requirements
+
+A maximum configuration of RTEMS includes the core
+and all managers, including the multiprocessing manager.
+Conversely, a minimum configuration of RTEMS includes only the
+core and the following managers: initialization, task, interrupt
+and fatal error.  The following illustrates the code space
+required by these configurations of RTEMS:
+
+@itemize @bullet
+@item Minimum Configuration: 18,980
+@item Maximum Configuration: 36,438
+@end itemize
+
+
+@node Memory Requirements RTEMS Code Space Worksheet, Memory Requirements RTEMS RAM Workspace Worksheet, Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements
+
+@section RTEMS Code Space Worksheet
+
+The RTEMS Code Space Worksheet is a tool provided to
+aid the RTEMS application designer to accurately calculate the
+memory required by the RTEMS run-time environment.  RTEMS allows
+the custom configuration of the executive by optionally
+excluding managers which are not required by a particular
+application.  This worksheet provides the included and excluded
+size of each manager in tabular form allowing for the quick
+calculation of any custom configuration of RTEMS.  The RTEMS
+Code Space Worksheet is below:
+
+@ifset use-ascii
+@page
+@end ifset
+@ifset use-tex
+@page
+@end ifset
+
+@page
+@center @b{RTEMS Code Space Worksheet}
+@sp 1
+
+@ifset use-ascii
+
+The following is a list of the components of the RTEMS code space.  The first
+number in parentheses is the size when the component is included,
+while the second number indicates its size when not included.  If the second
+number is "NA", then the component must always be included.
+
+@itemize @bullet
+@item Core (12,674, NA)
+@item Initialization (970, NA)
+@item Task (3,562, NA)
+@item Interrupt (54, NA)
+@item Clock (334, NA)
+@item Timer (1,110, 184)
+@item Semaphore (1,632, 172)
+@item Message (1,754, 288)
+@item Event (1,000, 56)
+@item Signal (418, 56)
+@item Partition (1,164, 132)
+@item Region (1,494, 160)
+@item Dual Ported Memory (724, 132)
+@item I/O (686, 00)
+@item Fatal Error (24, NA)
+@item Rate Monotonic (1,212, 184)
+@item Multiprocessing (6.952, 332)
+@end itemize
+@end ifset
+
+@ifset use-tex
+
+@tex
+\line{\hskip 0.50in\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 2.25in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.00in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.00in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.25in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Component && \bf Included && \bf Not Included && \bf Size &\cr\noalign{\hrule}
+&Core && 12,674 && NA && &\cr\noalign{\hrule}
+&Initialization && 970 && NA && &\cr\noalign{\hrule}
+&Task && 3,562 && NA && &\cr\noalign{\hrule}
+&Interrupt && 54 && NA && &\cr\noalign{\hrule}
+&Clock && 334 && NA && &\cr\noalign{\hrule}
+&Timer && 1,110 && 184 && &\cr\noalign{\hrule}
+&Semaphore && 1,632 && 172 && &\cr\noalign{\hrule}
+&Message && 1,754 && 288 && &\cr\noalign{\hrule}
+&Event && 1,000 && 56 && &\cr\noalign{\hrule}
+&Signal && 418 && 56 && &\cr\noalign{\hrule}
+&Partition && 1,164 && 132 && &\cr\noalign{\hrule}
+&Region && 1,494 && 160 && &\cr\noalign{\hrule}
+&Dual Ported Memory && 724 && 132 && &\cr\noalign{\hrule}
+&I/O && 686 && 00 && &\cr\noalign{\hrule}
+&Fatal Error && 24 && NA && &\cr\noalign{\hrule}
+&Rate Monotonic && 1,212 && 184 && &\cr\noalign{\hrule}
+&Multiprocessing && 6.952 && 332 && &\cr\noalign{\hrule}
+&\multispan 5 \bf\hfil Total Code Space Requirements\qquad\hfil&&&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+  <TABLE COLS=4 WIDTH="80%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Component</STRONG></TD>
+    <TD ALIGN=center><STRONG>Included</STRONG></TD>
+    <TD ALIGN=center><STRONG>Not Included</STRONG></TD>
+    <TD ALIGN=center><STRONG>Size</STRONG></TD></TR>
+<TR><TD ALIGN=center>Core</TD>
+    <TD ALIGN=center>12,674</TD>
+    <TD ALIGN=center>NA</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Initialization</TD>
+    <TD ALIGN=center>970</TD>
+    <TD ALIGN=center>NA</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Task</TD>
+    <TD ALIGN=center>3,562</TD>
+    <TD ALIGN=center>NA</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Interrupt</TD>
+    <TD ALIGN=center>54</TD>
+    <TD ALIGN=center>NA</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Clock</TD>
+    <TD ALIGN=center>334</TD>
+    <TD ALIGN=center>NA</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Timer</TD>
+    <TD ALIGN=center>1,110</TD>
+    <TD ALIGN=center>184</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Semaphore</TD>
+    <TD ALIGN=center>1,632</TD>
+    <TD ALIGN=center>172</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Message</TD>
+    <TD ALIGN=center>1,754</TD>
+    <TD ALIGN=center>288</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Event</TD>
+    <TD ALIGN=center>1,000</TD>
+    <TD ALIGN=center>56</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Signal</TD>
+    <TD ALIGN=center>418</TD>
+    <TD ALIGN=center>56</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Partition</TD>
+    <TD ALIGN=center>1,164</TD>
+    <TD ALIGN=center>132</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Region</TD>
+    <TD ALIGN=center>1,494</TD>
+    <TD ALIGN=center>160</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Dual Ported Memory</TD>
+    <TD ALIGN=center>724</TD>
+    <TD ALIGN=center>132</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>I/O</TD>
+    <TD ALIGN=center>686</TD>
+    <TD ALIGN=center>00</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Fatal Error</TD>
+    <TD ALIGN=center>24</TD>
+    <TD ALIGN=center>NA</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Rate Monotonic</TD>
+    <TD ALIGN=center>1,212</TD>
+    <TD ALIGN=center>184</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center>Multiprocessing</TD>
+    <TD ALIGN=center>6.952</TD>
+    <TD ALIGN=center>332</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=center COLSPAN=3>
+      <STRONG>Total Code Space Requirements</STRONG></TD>
+     <TD><BR></TD></TR>
+  </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+@page
+
+@c ******   Next node is set by a sed script in the document Makefile.
+@c ******   This comment is here to remind you not to edit the wksheets.t
+@c ******   in any directory but common.
+
+
+@node Memory Requirements RTEMS RAM Workspace Worksheet, Timing Specification, Memory Requirements RTEMS Code Space Worksheet, Memory Requirements
+
+@section RTEMS RAM Workspace Worksheet
+
+The RTEMS RAM Workspace Worksheet is a tool provided
+to aid the RTEMS application designer to accurately calculate
+the minimum memory block to be reserved for RTEMS use.  This
+worksheet provides equations for calculating the amount of
+memory required based upon the number of objects configured,
+whether for single or multiple processor versions of the
+executive.  This information is presented in tabular form, along
+with the fixed system requirements, allowing for quick
+calculation of any application defined configuration of RTEMS.
+The RTEMS RAM Workspace Worksheet is provided below:
+
+@ifset use-ascii
+@page
+@end ifset
+@ifset use-tex
+@sp 2
+@end ifset
+
+@center @b{RTEMS RAM Workspace Worksheet}
+@sp 2
+
+@ifset use-ascii
+The total RTEMS RAM Workspace required is the sum of the following:
+
+@itemize @bullet
+@item maximum_tasks * 400
+@item maximum_timers * 68
+@item maximum_semaphores * 124
+@item maximum_message_queues * 148
+@item maximum_regions * 144
+@item maximum_partitions * 56
+@item maximum_ports * 36
+@item maximum_periods * 36
+@item maximum_extensions * 64
+@item Floating Point Tasks * 332
+@item Task Stacks
+@item maximum_nodes * 48
+@item maximum_global_objects * 20
+@item maximum_proxies * 124
+@item Fixed System Requirements of 8,872
+@end itemize
+@end ifset
+
+@ifset use-tex
+@tex
+\line{\hskip 0.75in\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 3.0in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 0.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.25in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+& \bf Description && \bf Equation && \bf Bytes Required &\cr\noalign{\hrule}
+& maximum\_tasks &&  * 400 = &&&\cr\noalign{\hrule}
+& maximum\_timers &&  * 68 = &&&\cr\noalign{\hrule}
+& maximum\_semaphores &&  * 124 = &&&\cr\noalign{\hrule}
+& maximum\_message\_queues &&  * 148 = &&&\cr\noalign{\hrule}
+& maximum\_regions &&  * 144 = &&&\cr\noalign{\hrule}
+& maximum\_partitions &&  * 56 = &&&\cr\noalign{\hrule}
+& maximum\_ports &&  * 36 = &&&\cr\noalign{\hrule}
+& maximum\_periods &&  * 36 = &&&\cr\noalign{\hrule}
+& maximum\_extensions &&  * 64 = &&&\cr\noalign{\hrule}
+& Floating Point Tasks &&  * 332 = &&&\cr\noalign{\hrule}
+& Task Stacks &&\hskip 2.3em=&&&\cr\noalign{\hrule}
+& Total Single Processor Requirements &&&&&\cr\noalign{\hrule}
+}}\hfil}
+
+\line{\hskip 0.75in\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 3.0in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 0.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.25in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+& \bf Description && \bf Equation && \bf Bytes Required &\cr\noalign{\hrule}
+& maximum\_nodes &&  * 48 = &&&\cr\noalign{\hrule}
+& maximum\_global\_objects &&  * 20 = &&&\cr\noalign{\hrule}
+& maximum\_proxies &&  * 124 = &&&\cr\noalign{\hrule}
+}}\hfil}
+
+\line{\hskip 0.75in\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 3.0in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 0.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.25in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+& Total Multiprocessing Requirements &&&&&\cr\noalign{\hrule}
+& Fixed System Requirements && 8,872 &&&\cr\noalign{\hrule}
+& Total Single Processor Requirements &&&&&\cr\noalign{\hrule}
+& Total Multiprocessing Requirements &&&&&\cr\noalign{\hrule}
+& Minimum Bytes for RTEMS Workspace &&&&&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+  <TABLE COLS=3 WIDTH="80%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Description</STRONG></TD>
+    <TD ALIGN=center><STRONG>Equation</STRONG></TD>
+    <TD ALIGN=center><STRONG>Bytes Required</STRONG></TD></TR>
+<TR><TD ALIGN=left>maximum_tasks</TD>
+    <TD ALIGN=right>* 400 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_timers</TD>
+    <TD ALIGN=right>* 68 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_semaphores</TD>
+    <TD ALIGN=right>* 124 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_message_queues</TD>
+    <TD ALIGN=right>* 148 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_regions</TD>
+    <TD ALIGN=right>* 144 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_partitions</TD>
+    <TD ALIGN=right>* 56 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_ports</TD>
+    <TD ALIGN=right>* 36 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_periods</TD>
+    <TD ALIGN=right>* 36 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_extensions</TD>
+    <TD ALIGN=right>* 64 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>Floating Point Tasks</TD>
+    <TD ALIGN=right>* 332 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left COLSPAN=2>Task Stacks</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left COLSPAN=2>
+      <STRONG>Total Single Processor Requirements</STRONG></TD>
+     <TD><BR></TD></TR>
+<TR></TR>
+<TR><TD ALIGN=center><STRONG>Description</STRONG></TD>
+    <TD ALIGN=center><STRONG>Equation</STRONG></TD>
+    <TD ALIGN=center><STRONG>Bytes Required</STRONG></TD></TR>
+<TR><TD ALIGN=left>maximum_nodes</TD>
+    <TD ALIGN=right>* 48 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_global_objects</TD>
+    <TD ALIGN=right>* 20 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left>maximum_proxies</TD>
+    <TD ALIGN=right>* 124 =</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left COLSPAN=2>
+      <STRONG>Total Multiprocessing Requirements</STRONG></TD>
+     <TD><BR></TD></TR>
+<TR></TR>
+<TR><TD ALIGN=left COLSPAN=2>Fixed System Requirements</TD>
+    <TD ALIGN=center>8,872</TD></TR>
+<TR><TD ALIGN=left COLSPAN=2>Total Single Processor Requirements</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left COLSPAN=2>Total Multiprocessing Requirements</TD>
+     <TD><BR></TD></TR>
+<TR><TD ALIGN=left COLSPAN=2>
+      <STRONG>Minimum Bytes for RTEMS Workspace</STRONG></TD>
+     <TD><BR></TD></TR>
+  </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+