forked from Imagelibrary/rtems
Renamed a lot of files.
This commit is contained in:
Joel Sherrill
@@ -20,6 +20,10 @@ dirs:
|
|||||||
|
|
||||||
COMMON_FILES=../../common/cpright.texi ../../common/setup.texi
|
COMMON_FILES=../../common/cpright.texi ../../common/setup.texi
|
||||||
|
|
||||||
|
#GENERATED_FILES=\
|
||||||
|
# cpumodel.texi callconv.texi memmodel.texi intr.texi fatalerr.texi \
|
||||||
|
# bsp.texi cputable.texi timing.texi wksheets.texi timeFORCE386.texi
|
||||||
|
|
||||||
GENERATED_FILES= \
|
GENERATED_FILES= \
|
||||||
timing.texi wksheets.texi
|
timing.texi wksheets.texi
|
||||||
|
|
||||||
@@ -50,21 +54,48 @@ replace: timedata.texi
|
|||||||
# Chapters which get automatic processing
|
# Chapters which get automatic processing
|
||||||
#
|
#
|
||||||
|
|
||||||
# CPU Model
|
cpumodel.texi: cpumodel.t Makefile
|
||||||
# Calling Conventions
|
$(BMENU) -p "Preface" \
|
||||||
# Memory Model
|
-u "Top" \
|
||||||
|
-n "Calling Conventions" ${*}.t
|
||||||
|
|
||||||
|
callconv.texi: callconv.t Makefile
|
||||||
|
$(BMENU) -p "CPU Model Dependent Features Floating Point Unit" \
|
||||||
|
-u "Top" \
|
||||||
|
-n "Memory Model" ${*}.t
|
||||||
|
|
||||||
|
memmodel.texi: memmodel.t Makefile
|
||||||
|
$(BMENU) -p "Calling Conventions User-Provided Routines" \
|
||||||
|
-u "Top" \
|
||||||
|
-n "Interrupt Processing" ${*}.t
|
||||||
|
|
||||||
# Interrupt Chapter:
|
# Interrupt Chapter:
|
||||||
# 1. Replace Times and Sizes
|
# 1. Replace Times and Sizes
|
||||||
# 2. Build Node Structure
|
# 2. Build Node Structure
|
||||||
|
intr.t: intr_NOTIMES.t CVME961_TIMES
|
||||||
|
${REPLACE} -p CVME961_TIMES intr_NOTIMES.t
|
||||||
|
mv intr_NOTIMES.t.fixed intr.t
|
||||||
|
|
||||||
intr.texi: intr.t CVME961_TIMES
|
intr.texi: intr.t Makefile
|
||||||
${REPLACE} -p CVME961_TIMES intr.t
|
$(BMENU) -p "Memory Model Flat Memory Model" \
|
||||||
mv intr.t.fixed intr.texi
|
-u "Top" \
|
||||||
|
-n "Default Fatal Error Processing" ${*}.t
|
||||||
|
|
||||||
|
fatalerr.texi: fatalerr.t Makefile
|
||||||
|
$(BMENU) -p "Interrupt Processing Interrupt Stack" \
|
||||||
|
-u "Top" \
|
||||||
|
-n "Board Support Packages" ${*}.t
|
||||||
|
|
||||||
|
bsp.texi: bsp.t Makefile
|
||||||
|
$(BMENU) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
|
||||||
|
-u "Top" \
|
||||||
|
-n "Processor Dependent Information Table" ${*}.t
|
||||||
|
|
||||||
|
cputable.texi: cputable.t Makefile
|
||||||
|
$(BMENU) -p "Board Support Packages Processor Initialization" \
|
||||||
|
-u "Top" \
|
||||||
|
-n "Memory Requirements" ${*}.t
|
||||||
|
|
||||||
# Fatal Error
|
|
||||||
# BSP
|
|
||||||
# CPU Table
|
|
||||||
|
|
||||||
# Worksheets Chapter:
|
# Worksheets Chapter:
|
||||||
# 1. Obtain the Shared File
|
# 1. Obtain the Shared File
|
||||||
@@ -119,7 +150,7 @@ clean:
|
|||||||
rm -f *.dvi *.ps *.log *.aux *.cp *.fn *.ky *.pg *.toc *.tp *.vr $(BASE)
|
rm -f *.dvi *.ps *.log *.aux *.cp *.fn *.ky *.pg *.toc *.tp *.vr $(BASE)
|
||||||
rm -f $(PROJECT) $(PROJECT)-*
|
rm -f $(PROJECT) $(PROJECT)-*
|
||||||
rm -f c_i960 c_i960-*
|
rm -f c_i960 c_i960-*
|
||||||
rm -f timedata.texi timetbl.texi timetbl.t intr.texi $(GENERATED_FILES)
|
rm -f timedata.texi timetbl.texi timetbl.t intr.t $(GENERATED_FILES)
|
||||||
rm -f wksheets.t wksheets_NOTIMES.t
|
rm -f wksheets.t wksheets_NOTIMES.t
|
||||||
rm -f *.fixed _* timing.t timing.texi
|
rm -f *.fixed _* timing.t timing.texi
|
||||||
|
|
||||||
|
|||||||
@@ -1,73 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Board Support Packages, Board Support Packages Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Top
|
|
||||||
@end ifinfo
|
|
||||||
@chapter Board Support Packages
|
|
||||||
@ifinfo
|
|
||||||
@menu
|
|
||||||
* Board Support Packages Introduction::
|
|
||||||
* Board Support Packages System Reset::
|
|
||||||
* Board Support Packages Processor Initialization::
|
|
||||||
@end menu
|
|
||||||
@end ifinfo
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Board Support Packages Introduction, Board Support Packages System Reset, Board Support Packages, Board Support Packages
|
|
||||||
@end ifinfo
|
|
||||||
@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 i960CA 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.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Board Support Packages System Reset, Board Support Packages Processor Initialization, Board Support Packages Introduction, Board Support Packages
|
|
||||||
@end ifinfo
|
|
||||||
@section System Reset
|
|
||||||
|
|
||||||
An RTEMS based application is initiated when the
|
|
||||||
i960CA processor is reset. When the i960CA is reset, the
|
|
||||||
processor reads an Initial Memory Image (IMI) to establish its
|
|
||||||
state. The IMI consists of the Initialization Boot Record (IBR)
|
|
||||||
and the Process Control Block (PRCB) from an Initial Memory
|
|
||||||
Image (IMI) at location 0xFFFFFF00. The IBR contains the
|
|
||||||
initial bus configuration data, the address of the first
|
|
||||||
instruction to execute after reset, the address of the PRCB, and
|
|
||||||
the checksum used by the processor's self-test.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
|
|
||||||
@end ifinfo
|
|
||||||
@section Processor Initialization
|
|
||||||
|
|
||||||
The PRCB contains the base addresses for system data
|
|
||||||
structures, and initial configuration information for the core
|
|
||||||
and integrated peripherals. In particular, the PRCB contains
|
|
||||||
the initial contents of the Arithmetic Control (AC) Register as
|
|
||||||
well as the base addresses of the Interrupt Vector Table, System
|
|
||||||
Procedure Entry Table, Fault Entry Table, and the Control Table.
|
|
||||||
In addition, the PRCB is used to configure the depth of the
|
|
||||||
instruction and register caches and the actions when certain
|
|
||||||
types of faults are encountered.
|
|
||||||
|
|
||||||
The Process Controls (PC) Register is initialized to
|
|
||||||
0xC01F2002 which sets the i960CA's interrupt level to 0x1F (31
|
|
||||||
decimal). In addition, the Interrupt Mask (IMSK) Register
|
|
||||||
(alternately referred to as Special Function Register 1 or sf1)
|
|
||||||
is set to 0x00000000 to mask all external and DMA interrupt
|
|
||||||
sources. Thus, all interrupts are disabled when the first
|
|
||||||
instruction is executed.
|
|
||||||
|
|
||||||
For more information regarding the i960CA's data
|
|
||||||
structures and their contents, refer to Intel's i960CA User's
|
|
||||||
Manual.
|
|
||||||
@@ -1,132 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Floating Point Unit, Top
|
|
||||||
@end ifinfo
|
|
||||||
@chapter Calling Conventions
|
|
||||||
@ifinfo
|
|
||||||
@menu
|
|
||||||
* Calling Conventions Introduction::
|
|
||||||
* Calling Conventions Processor Background::
|
|
||||||
* Calling Conventions Calling Mechanism::
|
|
||||||
* Calling Conventions Register Usage::
|
|
||||||
* Calling Conventions Parameter Passing::
|
|
||||||
* Calling Conventions User-Provided Routines::
|
|
||||||
* Calling Conventions Leaf Procedures::
|
|
||||||
@end menu
|
|
||||||
@end ifinfo
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions
|
|
||||||
@end ifinfo
|
|
||||||
@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.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions
|
|
||||||
@end ifinfo
|
|
||||||
@section Processor Background
|
|
||||||
|
|
||||||
All members of the i960 architecture family support
|
|
||||||
two methods for performing procedure calls: a RISC-style
|
|
||||||
branch-and-link and an integrated call and return mechanism.
|
|
||||||
|
|
||||||
On a branch-and-link, the processor branches to the
|
|
||||||
invoked procedure and saves the return address in a register,
|
|
||||||
G14. Typically, the invoked procedure will not invoke another
|
|
||||||
procedure and is referred to as a leaf procedure. Many
|
|
||||||
high-level language compilers for the i960 family recognize leaf
|
|
||||||
procedures and automatically optimize them to utilize the
|
|
||||||
branch-and-link mechanism. Branch-and-link procedures are
|
|
||||||
invoked using the bal and balx instructions and return control
|
|
||||||
via the bx instruction. By convention, G14 is zero when not in
|
|
||||||
a leaf procedure. It is the responsibility of the leaf
|
|
||||||
procedure to clear G14 before returning.
|
|
||||||
|
|
||||||
The integrated call and return mechanism also
|
|
||||||
branches to the invoked procedure and saves the return address
|
|
||||||
as did the branch and link mechanism. However, the important
|
|
||||||
difference is that the call, callx, and calls instructions save
|
|
||||||
the local register set (R0 through R15) before transferring
|
|
||||||
control to the invoked procedure. The ret instruction
|
|
||||||
automatically restores the previous local register set. The
|
|
||||||
i960CA provides a register cache which can be configured to
|
|
||||||
retain the last five to sixteen recent register caches. When
|
|
||||||
the register cache is full, the oldest cached register set is
|
|
||||||
written to the stack.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions
|
|
||||||
@end ifinfo
|
|
||||||
@section Calling Mechanism
|
|
||||||
|
|
||||||
All RTEMS directives are invoked using either a call
|
|
||||||
or callx instruction and return to the user via the ret
|
|
||||||
instruction.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
|
|
||||||
@end ifinfo
|
|
||||||
@section Register Usage
|
|
||||||
|
|
||||||
As discussed above, the call and callx instructions
|
|
||||||
automatically save the current contents of the local register
|
|
||||||
set (R0 through R15). The contents of the local registers will
|
|
||||||
be restored as part of returning to the application. The
|
|
||||||
contents of global registers G0 through G7 are not preserved by
|
|
||||||
RTEMS directives.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
|
|
||||||
@end ifinfo
|
|
||||||
@section Parameter Passing
|
|
||||||
|
|
||||||
RTEMS uses the standard i960 family C parameter
|
|
||||||
passing mechanism in which G0 contains the first parameter, G1
|
|
||||||
the second, and so on for the remaining parameters. No RTEMS
|
|
||||||
directive requires more than six parameters.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions User-Provided Routines, Calling Conventions Leaf Procedures, Calling Conventions Parameter Passing, Calling Conventions
|
|
||||||
@end ifinfo
|
|
||||||
@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.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Calling Conventions Leaf Procedures, Memory Model, Calling Conventions User-Provided Routines, Calling Conventions
|
|
||||||
@end ifinfo
|
|
||||||
@section Leaf Procedures
|
|
||||||
|
|
||||||
RTEMS utilizes leaf procedures internally to improve
|
|
||||||
performance. This improves execution speed as well as reducing
|
|
||||||
stack usage and the number of register sets which must be cached.
|
|
||||||
|
|
||||||
|
|
||||||
@@ -1,81 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node CPU Model Dependent Features, CPU Model Dependent Features Introduction, Preface, Top
|
|
||||||
@end ifinfo
|
|
||||||
@chapter CPU Model Dependent Features
|
|
||||||
@ifinfo
|
|
||||||
@menu
|
|
||||||
* CPU Model Dependent Features Introduction::
|
|
||||||
* CPU Model Dependent Features CPU Model Name::
|
|
||||||
* CPU Model Dependent Features Floating Point Unit::
|
|
||||||
@end menu
|
|
||||||
@end ifinfo
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features, CPU Model Dependent Features
|
|
||||||
@end ifinfo
|
|
||||||
@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
|
|
||||||
SPARC or 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 i960 implementations and are of importance to RTEMS.
|
|
||||||
The set of CPU model feature macros are defined in the file
|
|
||||||
c/src/exec/score/cpu/i960/i960.h based upon the particular CPU
|
|
||||||
model defined on the compilation command line.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features Introduction, CPU Model Dependent Features
|
|
||||||
@end ifinfo
|
|
||||||
@section CPU Model Name
|
|
||||||
|
|
||||||
The macro CPU_MODEL_NAME is a string which designates
|
|
||||||
the name of this CPU model. For example, for the Intel i960CA,
|
|
||||||
this macro is set to the string "i960ca".
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node CPU Model Dependent Features Floating Point Unit, Calling Conventions, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features
|
|
||||||
@end ifinfo
|
|
||||||
@section Floating Point Unit
|
|
||||||
|
|
||||||
The macro I960_HAS_FPU is set to 1 to indicate that
|
|
||||||
this CPU model has a hardware floating point unit and 0
|
|
||||||
otherwise.
|
|
||||||
@@ -1,140 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Processor Dependent Information Table, Processor Dependent Information Table Introduction, Board Support Packages Processor Initialization, Top
|
|
||||||
@end ifinfo
|
|
||||||
@chapter Processor Dependent Information Table
|
|
||||||
@ifinfo
|
|
||||||
@menu
|
|
||||||
* Processor Dependent Information Table Introduction::
|
|
||||||
* Processor Dependent Information Table CPU Dependent Information Table::
|
|
||||||
@end menu
|
|
||||||
@end ifinfo
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Processor Dependent Information Table Introduction, Processor Dependent Information Table CPU Dependent Information Table, Processor Dependent Information Table, Processor Dependent Information Table
|
|
||||||
@end ifinfo
|
|
||||||
@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.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Processor Dependent Information Table CPU Dependent Information Table, Memory Requirements, Processor Dependent Information Table Introduction, Processor Dependent Information Table
|
|
||||||
@end ifinfo
|
|
||||||
@section CPU Dependent Information Table
|
|
||||||
|
|
||||||
The i960CA version of the RTEMS CPU Dependent
|
|
||||||
Information Table contains the information required to interface
|
|
||||||
a Board Support Package and RTEMS on the i960CA. 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_free_hook)( void* );
|
|
||||||
/* end of fields required on all CPUs */
|
|
||||||
|
|
||||||
#if defined(__i960CA__) || defined(__i960_CA__) || defined(__i960CA)
|
|
||||||
i960ca_PRCB *Prcb;
|
|
||||||
#endif
|
|
||||||
|
|
||||||
@} rtems_cpu_table;
|
|
||||||
@end group
|
|
||||||
@end example
|
|
||||||
|
|
||||||
The contents of the i960CA Processor Control Block
|
|
||||||
are discussed in Intel's i960CA User's Manual. Structure
|
|
||||||
definitions for the i960CA PRCB and Control Table are provided
|
|
||||||
by including the file rtems.h.
|
|
||||||
|
|
||||||
@table @code
|
|
||||||
@item pretasking_hook
|
|
||||||
is the address of the
|
|
||||||
user provided routine which is invoked once RTEMS initialization
|
|
||||||
is complete but before interrupts and tasking are enabled. This
|
|
||||||
field may be NULL to indicate that the hook is not utilized.
|
|
||||||
|
|
||||||
@item predriver_hook
|
|
||||||
is the address of the user provided
|
|
||||||
routine which is invoked with tasking enabled immediately before
|
|
||||||
the MPCI and device drivers are initialized. RTEMS
|
|
||||||
initialization is complete, interrupts and tasking are enabled,
|
|
||||||
but no device drivers are initialized. This field may be NULL to
|
|
||||||
indicate that the hook is not utilized.
|
|
||||||
|
|
||||||
@item postdriver_hook
|
|
||||||
is the address of the user provided
|
|
||||||
routine which is invoked with tasking enabled immediately after
|
|
||||||
the MPCI and device drivers are initialized. RTEMS
|
|
||||||
initialization is complete, interrupts and tasking are enabled,
|
|
||||||
and the device drivers are initialized. 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 Prcb
|
|
||||||
is the base address of the i960CA's Processor
|
|
||||||
Control Block. It is primarily used by RTEMS to install
|
|
||||||
interrupt handlers.
|
|
||||||
@end table
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@@ -1,45 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Default Fatal Error Processing, Default Fatal Error Processing Introduction, Interrupt Processing Interrupt Stack, Top
|
|
||||||
@end ifinfo
|
|
||||||
@chapter Default Fatal Error Processing
|
|
||||||
@ifinfo
|
|
||||||
@menu
|
|
||||||
* Default Fatal Error Processing Introduction::
|
|
||||||
* Default Fatal Error Processing Default Fatal Error Handler Operations::
|
|
||||||
@end menu
|
|
||||||
@end ifinfo
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Default Fatal Error Processing Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Default Fatal Error Processing, Default Fatal Error Processing
|
|
||||||
@end ifinfo
|
|
||||||
@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 is 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.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing
|
|
||||||
@end ifinfo
|
|
||||||
@section Default Fatal Error Handler Operations
|
|
||||||
|
|
||||||
The default fatal error handler which is invoked by
|
|
||||||
the fatal_error_occurred directive when there is no user handler
|
|
||||||
configured or the user handler returns control to RTEMS. The
|
|
||||||
default fatal error handler disables processor interrupts to
|
|
||||||
level 31, places the error code in G0, and executes a branch to
|
|
||||||
self instruction to simulate a halt processor instruction.
|
|
||||||
@@ -1,228 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
|
|
||||||
@end ifinfo
|
|
||||||
@chapter Interrupt Processing
|
|
||||||
@ifinfo
|
|
||||||
@menu
|
|
||||||
* Interrupt Processing Introduction::
|
|
||||||
* Interrupt Processing Vectoring of Interrupt Handler::
|
|
||||||
* Interrupt Processing Interrupt Record::
|
|
||||||
* Interrupt Processing Interrupt Levels::
|
|
||||||
* Interrupt Processing Disabling of Interrupts by RTEMS::
|
|
||||||
* Interrupt Processing Register Cache Flushing::
|
|
||||||
* Interrupt Processing Interrupt Stack::
|
|
||||||
@end menu
|
|
||||||
@end ifinfo
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing Introduction, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing, Interrupt Processing
|
|
||||||
@end ifinfo
|
|
||||||
@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 the proper handling of an interrupt. The processor
|
|
||||||
dependent response to the interrupt which modifies the execution
|
|
||||||
state and results in the modification of the execution stream.
|
|
||||||
This modification usually requires that an interrupt handler
|
|
||||||
utilize the provided 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 the processor's response and control mechanisms as they
|
|
||||||
pertain to RTEMS.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Record, Interrupt Processing Introduction, Interrupt Processing
|
|
||||||
@end ifinfo
|
|
||||||
@section Vectoring of Interrupt Handler
|
|
||||||
|
|
||||||
Upon receipt of an interrupt the i960CA
|
|
||||||
automatically performs the following actions:
|
|
||||||
|
|
||||||
@itemize @bullet
|
|
||||||
@item saves the local register set,
|
|
||||||
|
|
||||||
@item sets the Frame Pointer (FP) to point to the interrupt
|
|
||||||
stack,
|
|
||||||
|
|
||||||
@item increments the FP by sixteen (16) to make room for the
|
|
||||||
Interrupt Record,
|
|
||||||
|
|
||||||
@item saves the current values of the arithmetic-controls (AC)
|
|
||||||
register, the process-controls (PC) register, and the interrupt
|
|
||||||
vector number are saved in the Interrupt Record,
|
|
||||||
|
|
||||||
@item the CPU sets the Instruction Pointer (IP) to the address
|
|
||||||
of the first instruction in the interrupt handler,
|
|
||||||
|
|
||||||
@item the return-status field of the Previous Frame Pointer
|
|
||||||
(PFP or R0) register is set to interrupt return,
|
|
||||||
|
|
||||||
@item sets the PC state bit to interrupted,
|
|
||||||
|
|
||||||
@item sets the current interrupt disable level in the PC to
|
|
||||||
the level of the current interrupt, and
|
|
||||||
|
|
||||||
@item disables tracing.
|
|
||||||
@end itemize
|
|
||||||
|
|
||||||
A nested interrupt is processed similarly by the
|
|
||||||
i960CA with the exception that the Frame Pointer (FP) already
|
|
||||||
points to the interrupt stack. This means that the FP is NOT
|
|
||||||
overwritten before space for the Interrupt Record is allocated.
|
|
||||||
|
|
||||||
The state flag bit of the saved PC register in the
|
|
||||||
Interrupt Record is examined by RTEMS to determine when an outer
|
|
||||||
most interrupt is being exited. Therefore, the user application
|
|
||||||
code MUST NOT modify this bit.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing Interrupt Record, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
|
|
||||||
@end ifinfo
|
|
||||||
@section Interrupt Record
|
|
||||||
|
|
||||||
The structure of the Interrupt Record for the i960CA
|
|
||||||
which is placed on the interrupt stack by the processor in
|
|
||||||
response to an interrupt is as follows:
|
|
||||||
|
|
||||||
@ifset use-ascii
|
|
||||||
@example
|
|
||||||
@group
|
|
||||||
+---------------------------+
|
|
||||||
| Saved Process Controls | NFP-16
|
|
||||||
+---------------------------+
|
|
||||||
| Saved Arithmetic Controls | NFP-12
|
|
||||||
+---------------------------+
|
|
||||||
| UNUSED | NFP-8
|
|
||||||
+---------------------------+
|
|
||||||
| UNUSED | NFP-4
|
|
||||||
+---------------------------+
|
|
||||||
@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 1.00in{\enskip\hfil#\hfil}
|
|
||||||
\cr
|
|
||||||
\multispan{3}\hrulefill\cr
|
|
||||||
& Saved Process Controls && NFP-16\cr
|
|
||||||
\multispan{3}\hrulefill\cr
|
|
||||||
& Saved Arithmetic Controls && NFP-12\cr
|
|
||||||
\multispan{3}\hrulefill\cr
|
|
||||||
& UNUSED && NFP-8\cr
|
|
||||||
\multispan{3}\hrulefill\cr
|
|
||||||
& UNUSED && NFP-4\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>Saved Process Controls</STRONG></TD>
|
|
||||||
<TD ALIGN=center>NFP-16</TD></TR>
|
|
||||||
<TR><TD ALIGN=center><STRONG>Saved Arithmetic Controls</STRONG></TD>
|
|
||||||
<TD ALIGN=center>NFP-12</TD></TR>
|
|
||||||
<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD>
|
|
||||||
<TD ALIGN=center>NFP-8</TD></TR>
|
|
||||||
<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD>
|
|
||||||
<TD ALIGN=center>NFP-4</TD></TR>
|
|
||||||
</TABLE>
|
|
||||||
</CENTER>
|
|
||||||
@end html
|
|
||||||
@end ifset
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Record, Interrupt Processing
|
|
||||||
@end ifinfo
|
|
||||||
@section Interrupt Levels
|
|
||||||
|
|
||||||
Thirty-two levels (0-31) of interrupt priorities are
|
|
||||||
supported by the i960CA microprocessor with level thirty-one
|
|
||||||
(31) 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
|
|
||||||
i960CA only supports thirty-two. RTEMS interrupt levels 0
|
|
||||||
through 31 directly correspond to i960CA interrupt levels. All
|
|
||||||
other RTEMS interrupt levels are undefined and their behavior is
|
|
||||||
unpredictable.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Register Cache Flushing, Interrupt Processing Interrupt Levels, Interrupt Processing
|
|
||||||
@end ifinfo
|
|
||||||
@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 thirty-one (31)
|
|
||||||
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 i960CA with zero wait states.
|
|
||||||
These numbers will vary based the number of wait states and
|
|
||||||
processor speed present on the target board. [NOTE: This
|
|
||||||
calculation was most recently 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.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing Register Cache Flushing, Interrupt Processing Interrupt Stack, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
|
|
||||||
@end ifinfo
|
|
||||||
@section Register Cache Flushing
|
|
||||||
|
|
||||||
The i960CA version of the RTEMS interrupt manager is
|
|
||||||
optimized to insure that the flushreg instruction is only
|
|
||||||
executed when a context switch is necessary. The flushreg
|
|
||||||
instruction flushes the i960CA register set cache and takes (14
|
|
||||||
+ 23 * number of sets flushed) cycles to execute. As the i960CA
|
|
||||||
supports caching of from five to sixteen register sets, this
|
|
||||||
instruction takes from 129 to 382 cycles (3.90 to 11.57
|
|
||||||
microseconds at 33 Mhz) to execute given no wait state memory.
|
|
||||||
RTEMS flushes the register set cache only at the conclusion of
|
|
||||||
the outermost ISR when a context switch is necessary. The
|
|
||||||
register set cache will not be flushed as part of processing a
|
|
||||||
nested interrupt or when a context switch is not necessary.
|
|
||||||
This optimization is essential to providing high-performance
|
|
||||||
interrupt management on the i960CA.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Register Cache Flushing, Interrupt Processing
|
|
||||||
@end ifinfo
|
|
||||||
@section Interrupt Stack
|
|
||||||
|
|
||||||
On the i960CA, 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.
|
|
||||||
|
|
||||||
|
|
||||||
@@ -1,55 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Memory Model, Memory Model Introduction, Calling Conventions Leaf Procedures, Top
|
|
||||||
@end ifinfo
|
|
||||||
@chapter Memory Model
|
|
||||||
@ifinfo
|
|
||||||
@menu
|
|
||||||
* Memory Model Introduction::
|
|
||||||
* Memory Model Flat Memory Model::
|
|
||||||
@end menu
|
|
||||||
@end ifinfo
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model
|
|
||||||
@end ifinfo
|
|
||||||
@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.
|
|
||||||
|
|
||||||
@ifinfo
|
|
||||||
@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model
|
|
||||||
@end ifinfo
|
|
||||||
@section Flat Memory Model
|
|
||||||
|
|
||||||
The i960CA supports a flat 32-bit address space with
|
|
||||||
addresses ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes).
|
|
||||||
Although the i960CA reserves portions of this address space,
|
|
||||||
application code and data may be placed in any non-reserved
|
|
||||||
areas. Each address is represented by a 32-bit value and is
|
|
||||||
byte addressable. The address may be used to reference a single
|
|
||||||
byte, half-word (2-bytes), word (4 bytes), double-word (8
|
|
||||||
bytes), triple-word (12 bytes) or quad-word (16 bytes). The
|
|
||||||
i960CA does not support virtual memory or segmentation.
|
|
||||||
|
|
||||||
The i960CA allows the memory space to be partitioned
|
|
||||||
into sixteen regions which may be configured individually as big
|
|
||||||
or little endian. RTEMS assumes that the memory regions in
|
|
||||||
which its code, data, and the RTEMS Workspace reside are
|
|
||||||
configured as little endian.
|
|
||||||
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user