RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

2008-06-02 Joel Sherrill <joel.sherrill@oarcorp.com>

Browse Source 
* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
	cpu_supplement/arm.t, cpu_supplement/bfin.t,
	cpu_supplement/cpu_supplement.texi, cpu_supplement/i386.t,
	cpu_supplement/m68k.t, cpu_supplement/mips.t,
	cpu_supplement/powerpc.t, cpu_supplement/preface.texi,
	cpu_supplement/sh.t: Remove duplicated text from each CPU specific
	chapter. This text was necessary when each CPU was a separate manual
	but now only needs to be one place and that is in an introductory
	chapter.
	* cpu_supplement/general.t: New file.
This commit is contained in:
Joel Sherrill
2008-06-02 16:09:56 +00:00
parent 7a1c9cf3d7
commit 42cf7c7c41
13 changed files with 706 additions and 2089 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/ChangeLog
View File

@@ -1,3 +1,16 @@
2008-06-02 Joel Sherrill <joel.sherrill@oarcorp.com>
* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
cpu_supplement/arm.t, cpu_supplement/bfin.t,
cpu_supplement/cpu_supplement.texi, cpu_supplement/i386.t,
cpu_supplement/m68k.t, cpu_supplement/mips.t,
cpu_supplement/powerpc.t, cpu_supplement/preface.texi,
cpu_supplement/sh.t: Remove duplicated text from each CPU specific
chapter. This text was necessary when each CPU was a separate manual
but now only needs to be one place and that is in an introductory
chapter.
* cpu_supplement/general.t: New file.
2008-06-02 Joel Sherrill <joel.sherrill@oarcorp.com>
* user/bsp.t, user/init.t: Rework initialization and BSP chapters to

1
doc/cpu_supplement/.cvsignore
View File

@@ -21,6 +21,7 @@ cpu_supplement.ps
cpu_supplement.toc
cpu_supplement.tp
cpu_supplement.vr
general.texi
i386.texi
index.html
m68k.texi

9
doc/cpu_supplement/Makefile.am
View File

@@ -21,7 +21,7 @@ TEXI2WWW_ARGS=\
-header rtems_header.html \
-footer rtems_footer.html \
-icons ../images
GENERATED_FILES = arm.texi bfin.texi i386.texi m68k.texi mips.texi \
GENERATED_FILES = general.texi arm.texi bfin.texi i386.texi m68k.texi mips.texi \
powerpc.texi sh.texi sparc.texi tic4x.texi
COMMON_FILES += $(top_srcdir)/common/cpright.texi
@@ -35,11 +35,16 @@ cpu_supplement_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
# Chapters which get automatic processing
#
arm.texi: arm.t
general.texi: general.t
$(BMENU2) -p "Preface" \
-u "Top" \
-n "" < $< > $@
arm.texi: arm.t
$(BMENU2) -p "" \
-u "Top" \
-n "" < $< > $@
bfin.texi: bfin.t
$(BMENU2) -p "" \
-u "Top" \

317
doc/cpu_supplement/arm.t
View File

@@ -10,34 +10,17 @@
@end ifinfo
@chapter ARM Specific Information
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
This chapter 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.
there are many, many CPU models within it.
@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:
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."
@@ -47,54 +30,16 @@ Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.}
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section CPU Model Dependent Features
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 PowerPC 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
This section 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.
@code{cpukit/score/cpu/arm/rtems/score/arm.h} based upon the particular CPU
model flags specified on the compilation command line.
@subsection CPU Model Name
@@ -128,53 +73,24 @@ point support is incorporated on-chip or is an external
coprocessor.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Calling Conventions
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.
@subsection 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.
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.
@subsection Calling Mechanism
All RTEMS directives are invoked using the @code{bl}
instruction and return to the user application via the
mechanism described above.
All RTEMS directives are invoked using the @code{bl} instruction and
return to the user application via the mechanism described above.
@subsection Register Usage
@@ -193,71 +109,32 @@ 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.
@subsection 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.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Memory Model
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.
@subsection 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.
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.
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.
@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
@section Interrupt Processing
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
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 ARM's
@@ -265,6 +142,7 @@ interrupt response and control mechanisms as they pertain to
RTEMS.
The ARM has 7 exception types:
@itemize @bullet
@item Reset
@@ -282,7 +160,6 @@ vectoring.
@subsection Vectoring of an Interrupt Handler
Unlike many other architectures, the ARM has seperate stacks for each
interrupt. When the CPU receives an interrupt, it:
@@ -328,62 +205,17 @@ Setting bit 7 (0 is least significant bit) disables the IRQ.
@end table
@subsection 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.
@subsection Interrupt Stack
RTEMS expects the interrupt stacks to be set up in bsp_start(). The memory
for the stacks is reserved in the linker script.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Default Fatal Error Processing
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.
@subsection 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
The default fatal error handler for this architecture performs the
following actions:
@itemize @bullet
@@ -394,94 +226,21 @@ simulate a halt processor instruction.
@end itemize
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Board Support Packages
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.
@subsection 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:
An RTEMS based application is initiated or re-initiated when the processor
is reset. When the processor is reset, the processor performs the
following actions:
@itemize @bullet
@item The tracing bits of the status register are cleared to
disable tracing.
@item TBD
@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
@subsection 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.
TBD

165
doc/cpu_supplement/bfin.t
View File

@@ -10,174 +10,121 @@
@end ifinfo
@chapter Blackfin Specific Information
This chapter discusses the Blackfin architecture dependencies
in this port of RTEMS.
This chapter discusses the Blackfin architecture dependencies in this
port of RTEMS.
@subheading Architecture Documents
For information on the Blackfin architecture,
refer to the following documents available from
Analog Devices.
For information on the Blackfin architecture, refer to the following
documents available from Analog Devices.
TBD
@c @itemize @bullet
@c @item @cite{"ADSP-BF533 Blackfin Processor Hardware Reference."
@c @file{http://www.analog.com/UploadedFiles/Associated_Docs/892485982bf533_hwr.pdf}
@c
@c @end itemize
@itemize @bullet
@item @cite{"ADSP-BF533 Blackfin Processor Hardware Reference."}
@file{http://www.analog.com/UploadedFiles/Associated_Docs/892485982bf533_hwr.pdf}
@end itemize
@section CPU Model Dependent Features
CPUs of the Blackfin 53X only differ in the perifericals
and thus in the device drivers. This port does not yet
support the 56X dual core variants.
@subsection 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
"BF533"
@end example
CPUs of the Blackfin 53X only differ in the peripherals and thus in the
device drivers. This port does not yet support the 56X dual core variants.
@subsection Count Leading Zeroes Instruction
The Blackfin CPU has the BITTST instruction
which could be used to speed up the find first bit
operation. The use of this instruction should significantly speed up
the scheduling associated with a thread blocking.
@subsection Floating Point Unit
The macro BF_HAS_FPU is set to 0 to indicate that
this CPU model has no hardware floating point unit.
Blackfin CPUs don't have floating point so
The Blackfin CPU has the BITTST instruction which could be used to speed
up the find first bit operation. The use of this instruction should
significantly speed up the scheduling associated with a thread blocking.
@section Calling Conventions
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.
This section is heavily based on content taken from the
Blackfin uCLinux documentation wiki which is edited
by Analog Devices and Arcturus Networks.
@file{http://docs.blackfin.uclinux.org/}
This section is heavily based on content taken from the Blackfin uCLinux
documentation wiki which is edited by Analog Devices and Arcturus
Networks. @file{http://docs.blackfin.uclinux.org/}
@subsection Processor Background
The Blackfin architecture supports a simple call and return mechanism.
A subroutine is invoked via the call (@code{call}) instruction.
This instruction saves the return address in the @code{RETS} register
and transfers the execution to the given address.
It is the called funcions responsability to use the link instruction to
reserve space on the stack for the local variables.
Returning from a subroutine is done by using the RTS (@code{RTS})
instruction which loads the PC with the adress stored in RETS.
It is the called funcions responsability to use the link instruction
to reserve space on the stack for the local variables. Returning from
a subroutine is done by using the RTS (@code{RTS}) instruction which
loads the PC with the adress stored in RETS.
It is is important to note that the @code{call} 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.
automatically save or restore any registers. It is the responsibility
of the high-level language compiler to define the register preservation
and usage convention.
@subsection Register Usage
A called function may clobber all registers, except RETS, R4-R7, P3-P5, FP and SP.
It may also modify the first 12 bytes in the caller’s stack frame which is used as
an argument area for the first three arguments (which are passed in R0...R3 but may
be placed on the stack by the called function).
A called function may clobber all registers, except RETS, R4-R7, P3-P5,
FP and SP. It may also modify the first 12 bytes in the caller’s stack
frame which is used as an argument area for the first three arguments
(which are passed in R0...R3 but may be placed on the stack by the
called function).
@subsection Parameter Passing
RTEMS assumes that the Blackfin GCC calling convention is followed.
The first three parameters are stored in registers R0, R1, and R2.
All other parameters are put pushed on the stack.
The result is returned through register R0.
@subsection 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.
All other parameters are put pushed on the stack. The result is returned
through register R0.
@section Memory Model
The Blackfin family architecutre support a single unified 4
G byte address space using 32-bit addresses. It maps all
resources like internal and external memory and IO registers
into separate sections of this common address space.
The Blackfin family architecutre support a single unified 4 GB byte
address space using 32-bit addresses. It maps all resources like internal
and external memory and IO registers into separate sections of this
common address space.
The Blackfin architcture supporst some form of memory
The Blackfin architcture supports some form of memory
protection via its Memory Management Unit. Since the
Blackfin port runs in supervisior mode this memory
protection mechanisms are not used.
@section Interrupt Processing
Discussed in this chapter are the Blackfin's
interrupt response and control mechanisms as they pertain to
RTEMS. The Blackfin architecture support 16 kinds of
interrupts broken down into Core and general-purpose
Discussed in this chapter are the Blackfin's interrupt response and
control mechanisms as they pertain to RTEMS. The Blackfin architecture
support 16 kinds of interrupts broken down into Core and general-purpose
interrupts.
@subsection Vectoring of an Interrupt Handler
RTEMS maps levels 0 -15 directly to Blackfins event
vectors EVT0 - EVT15. Since EVT0 - EVT6 are core
events and it is suggested to use EVT15 and EVT15 for
Software interrupts, 7 Interrupts (EVT7-EVT13) are left
for periferical use.
RTEMS maps levels 0 -15 directly to Blackfins event vectors EVT0 -
EVT15. Since EVT0 - EVT6 are core events and it is suggested to use
EVT15 and EVT15 for Software interrupts, 7 Interrupts (EVT7-EVT13)
are left for periferical use.
When installing an RTEMS interrupt handler RTEMS installs
a generic Interrupt Handler which saves some context and
enables nested interrupt servicing and then vectors
to the users interrupt handler.
When installing an RTEMS interrupt handler RTEMS installs a generic
Interrupt Handler which saves some context and enables nested interrupt
servicing and then vectors to the users interrupt handler.
@subsection 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 four (4) before
the execution of this section and restores them to the previous
level upon completion of the section. RTEMS uses the instructions
CLI and STI to enable and disable Interrupts. Emulation,
During interrupt disable critical sections, RTEMS disables interrupts to
level four (4) before the execution of this section and restores them
to the previous level upon completion of the section. RTEMS uses the
instructions CLI and STI to enable and disable Interrupts. Emulation,
Reset, NMI and Exception Interrupts are never disabled.
@subsection Interrupt Stack
The Blackfin Architecuter works with two different kind of stacks,
The Blackfin Architecture works with two different kind of stacks,
User and Supervisor Stack. Since RTEMS and its Application run
in supervisor mode, all interrupts will use the interrupted
tasks stack for execution.
@section Default Fatal Error Processing
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:
The default fatal error handler for the Blackfin performs the following
actions:
@itemize @bullet
@item disables processor interrupts,
@@ -192,9 +139,3 @@ simulate a halt processor instruction.
@subsection System Reset
TBD
@subsection Processor Initialization
TBD

6
doc/cpu_supplement/cpu_supplement.texi
View File

@@ -59,6 +59,7 @@
@contents
@include preface.texi
@include general.texi
@include arm.texi
@include bfin.texi
@include i386.texi
@@ -72,14 +73,15 @@
@node Top, Preface, (dir), (dir)
@top cpu_supplement
This is the online version of the RTEMS CPU Architecture Supplement
This is the online version of the RTEMS CPU Architecture Supplement.
@menu
* Preface::
* Port Specific Information::
* ARM Specific Information::
* Blackfin Specific Information::
* Intel/AMD x86 Specific Information::
* Motorola M68xxx and Coldfire Specific Information::
* M68xxx and Coldfire Specific Information::
* MIPS Specific Information::
* PowerPC Specific Information::
* SuperH Specific Information::

342
doc/cpu_supplement/general.t Normal file
View File

@@ -0,0 +1,342 @@
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@end ifinfo
@chapter Port Specific Information
This chaper provides a general description of the type of
architecture specific information which is in each of
the architecture specific chapters that follow. The outline
of this chapter is identical to that of the architecture
specific chapters.
In each of the architecture specific chapters, this
introductory section will provide an overview of the
architecture
@subheading Architecture Documents
In each of the architecture specific chapters, this
section will provide pointers on where to obtain
documentation.
@c
@c
@c
@section CPU Model Dependent Features
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 PowerPC 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.
The set of CPU model feature macros are defined in the file
@code{cpukit/score/cpu/CPU/rtems/score/cpu.h} based upon the GNU tools
multilib variant that is appropriate for the particular CPU model defined
on the compilation command line.
In each of the architecture specific chapters, this section presents
the set of features which vary across various implementations of the
architecture that may be of importance to RTEMS application developers.
The subsections will vary amongst the target architecture chapters as
the specific features may vary. However, each port will include a few
common features such as the CPU Model Name and presence of a hardware
Floating Point Unit. The common features are described here.
@subsection CPU Model Name
The macro @code{CPU_MODEL_NAME} is a string which designates
the name of this CPU model. For example, for the MC68020
processor model from the m68k architecture, this macro
is set to the string "mc68020".
@subsection Floating Point Unit
In most architectures, the presence of a floating point unit is an option.
It does not matter whether the hardware floating point support is
incorporated on-chip or is an external coprocessor as long as it
appears an FPU per the ISA. However, if a hardware FPU is not present,
it is possible that the floating point emulation library for this
CPU is not reentrant and thus context switched by RTEMS.
RTEMS provides two feature macros to indicate the FPU configuration:
@itemize @bullet
@item CPU_HARDWARE_FP
is set to TRUE to indicate that a hardware FPU is present.
@item CPU_SOFTWARE_FP
is set to TRUE to indicate that a hardware FPU is not present and that
the FP software emulation will be context switched.
@end itemize
@c
@c
@c
@section Calling Conventions
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.
@subsection Calling Mechanism
In each of the architecture specific chapters, this subsection will
describe the instruction(s) used to perform a @i{normal} subroutine
invocation. All RTEMS directives are invoked as @i{normal} C language
functions so it is important to the user application to understand the
call and return mechanism.
@subsection Register Usage
In each of the architecture specific chapters, this subsection will
detail the set of registers which are @b{NOT} preserved across subroutine
invocations. The registers which are not preserved are assumed to be
available for use as scratch registers. Therefore, the contents of these
registers should not be assumed upon return from any RTEMS directive.
In some architectures, there may be a set of registers made available
automatically as a side-effect of the subroutine invocation
mechanism.
@subsection Parameter Passing
In each of the architecture specific chapters, this subsection will
describe the mechanism by which the parameters or arguments are passed
by the caller to a subroutine. In some architectures, all parameters
are passed on the stack while in others some are passed in registers.
@subsection 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.
@c
@c
@c
@section Memory Model
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.
@subsection Flat Memory Model
Most RTEMS target processors can be initialized to support a flat address
space. Although the size of addresses varies between architectures, on
most RTEMS targets, an address is 32-bits wide which defines 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 may be performed in little or
big endian fashion.
On smaller CPU architectures supported by RTEMS, the address space
may only be 20 or 24 bits wide.
If the CPU model has support for virtual memory or segmentation, it is
the responsibility of the Board Support Package (BSP) to initialize the
MMU hardware to perform address translations which correspond to flat
memory model.
In each of the architecture specific chapters, this subsection will
describe any architecture characteristics that differ from this general
description.
@c
@c
@c
@section Interrupt Processing
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.
RTEMS supports a dedicated interrupt stack for all architectures.
On architectures with hardware support for a dedicated interrupt stack,
it will be initialized such that when an interrupt occurs, the processor
automatically switches to this dedicated stack. On architectures without
hardware support for a dedicated interrupt stack which is separate from
those of the tasks, RTEMS will support switching to a dedicated stack
for interrupt processing.
Without a dedicated interrupt stack, every task in
the system MUST have enough stack space to accommodate the worst
case stack usage of that particular task and the interrupt
service routines COMBINED. By supporting a dedicated interrupt
stack, RTEMS significantly lowers the stack requirements for
each task.
A nested interrupt is processed similarly with the exception that since
the CPU is already executing on the interrupt stack, there is no need
to switch to the interrupt stack.
In some configurations, RTEMS allocates the interrupt stack from the
Workspace Area. The amount of memory allocated for the interrupt stack
is user configured and based upon the @code{confdefs.h} parameter
@code{CONFIGURE_INTERRUPT_STACK_SIZE}. This parameter is described
in detail in the Configuring a System chapter of the User's Guide.
On configurations in which RTEMS allocates the interrupt stack, during
the initialization process, RTEMS will also install its interrupt stack.
In other configurations, the interrupt stack is allocated and installed
by the Board Support Package (BSP).
In each of the architecture specific chapters, this section discesses
the interrupt response and control mechanisms of the architecture as
they pertain to RTEMS.
@subsection Vectoring of an Interrupt Handler
In each of the architecture specific chapters, this subsection will
describe the architecture specific details of the interrupt vectoring
process. In particular, it should include a description of the
Interrupt Stack Frame (ISF).
@subsection Interrupt Levels
In each of the architecture specific chapters, this subsection will
describe how the interrupt levels available on this particular architecture
are mapped onto the 255 reserved in the task mode. The interrupt level
value of zero (0) should always mean that interrupts are enabled.
Any use of an interrupt level that is is not undefined on a particular
architecture may result in behavior that is unpredictable.
@subsection 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 all
external interrupts before the execution of this section and restores
them to the previous level upon completion of the section. RTEMS has
been optimized to ensure that interrupts are disabled for the shortest
number of instructions possible. Since the precise number of instructions
and their execution time varies based upon target CPU family, CPU model,
board memory speed, compiler version, and optimization level, it is
not practical to provide the precise number for all possible RTEMS
configurations.
Historically, the measurements were made by hand analyzing and counting
the execution time of instruction sequences during interrupt disable
critical sections. For reference purposes, on a 16 Mhz Motorola
MC68020, the maximum interrupt disable period was typically approximately
ten (10) to thirteen (13) microseconds. This architecture was memory bound
and had a slow bit scan instruction. In contrast, during the same
period a 14 Mhz SPARC would have a worst case disable time of approximately
two (2) to three (3) microseconds because it had a single cycle bit scan
instruction and used fewer cycles for memory accesses.
If you are interested in knowing the worst case execution time for
a particular version of RTEMS, please contact OAR Corporation and
we will be happy to product the results as a consulting service.
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.
@c
@c
@c
@section Default Fatal Error Processing
Upon detection of a fatal error by either the application or RTEMS during
initialization the @code{rtems_fatal_error_occurred} directive supplied
by 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 or all of them return without taking action to
shutdown the processor or reset, a default fatal error handler is invoked.
Most of the action performed as part of processing the fatal error are
described in detail in the Fatal Error Manager chapter in the User's
Guide. However, the if no user provided extension or BSP specific fatal
error handler takes action, the final default action is to invoke a
CPU architecture specific function. Typically this function disables
interrupts and halts the processor.
In each of the architecture specific chapters, this describes the precise
operations of the default CPU specific fatal error handler.
@c
@c
@c
@section Board Support Packages
An RTEMS Board Support Package (BSP) must be designed to support a
particular processor model and target board combination.
In each of the architecture specific chapters, this section will present
a discussion of architecture specific BSP issues. For more information
on developing a BSP, refer to BSP and Device Driver Development Guide
and the chapter titled Board Support Packages in the RTEMS
Applications User's Guide.
@subsection System Reset
An RTEMS based application is initiated or re-initiated when the processor
is reset or transfer is passed to it from a boot monitor or ROM monitor.
In each of the architecture specific chapters, this subsection describes
the actions that the BSP must tak assuming the application gets control
when the microprocessor is reset.

256
doc/cpu_supplement/i386.t
View File

@@ -10,15 +10,10 @@
@end ifinfo
@chapter Intel/AMD x86 Specific Information
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 chapter discusses the Intel x86 architecture dependencies
in this port of RTEMS. This family has multiple implementations
from multiple vendors and suffers more from having evolved rather
than being designed for growth.
For information on the i386 processor, refer to the
following documents:
@@ -34,118 +29,36 @@ Order No. 231732-003}.
@item @cite{80387 Programmer's Reference Manual, Intel, Order No. 231917-001}.
@end itemize
It is highly recommended that the i386 RTEMS
application developer obtain and become familiar with Intel's
386 Programmer's Reference Manual.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section CPU Model Dependent Features
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 PowerPC 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
This section presents the set of features which vary
across i386 implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
cpukit/score/cpu/i386/i386.h based upon the particular CPU
model defined on the compilation command line.
@subsection CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the Intel i386 without an
i387 coprocessor, this macro is set to the string "i386 with i387".
@code{cpukit/score/cpu/i386/i386.h} based upon the particular CPU
model specified on the compilation command line.
@subsection bswap Instruction
The macro I386_HAS_BSWAP is set to 1 to indicate that
The macro @code{I386_HAS_BSWAP} is set to 1 to indicate that
this CPU model has the @code{bswap} instruction which
endian swaps a thirty-two bit quantity. This instruction
appears to be present in all CPU models
i486's and above.
@subsection Floating Point Unit
The macro I386_HAS_FPU is set to 1 to indicate that
this CPU model has a hardware floating point unit and 0
otherwise. The hardware floating point may be on-chip (as in the
case of an i486DX or Pentium) or as a coprocessor (as in the case of
an i386/i387 combination).
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Calling Conventions
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.
@subsection Processor Background
The i386 architecture supports a simple yet effective
call and return mechanism. A subroutine is invoked via the call
(call) instruction. This instruction pushes the return address
on the stack. The return from subroutine (ret) instruction pops
(@code{call}) instruction. This instruction pushes the return address
on the stack. The return from subroutine (@code{ret}) instruction pops
the return address off the current stack and transfers control
to that instruction. It is is important to note that the i386
call and return mechanism does not automatically save or restore
@@ -155,18 +68,16 @@ convention.
@subsection Calling Mechanism
All RTEMS directives are invoked using a call
instruction and return to the user application via the ret
instruction.
All RTEMS directives are invoked using a call instruction and return to
the user application via the ret instruction.
@subsection Register Usage
As discussed above, the call instruction does not
automatically save any registers. RTEMS uses the registers EAX,
ECX, and EDX as scratch registers. These registers are not
preserved by RTEMS directives therefore, the contents of these
registers should not be assumed upon return from any RTEMS
directive.
As discussed above, the call instruction does not automatically save
any registers. RTEMS uses the registers EAX, ECX, and EDX as scratch
registers. These registers are not preserved by RTEMS directives
therefore, the contents of these registers should not be assumed upon
return from any RTEMS directive.
@subsection Parameter Passing
@@ -192,32 +103,12 @@ from the stack after control is returned to the caller. This
removal is typically accomplished by adding the size of the
argument list in bytes to the stack pointer.
@subsection 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.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Memory Model
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.
@subsection Flat Memory Model
RTEMS supports the i386 protected mode, flat memory
@@ -247,48 +138,13 @@ gigabytes). 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), or word (4 bytes).
RTEMS does not require that logical addresses map
directly to physical addresses, although it is desirable in many
applications to do so. If logical and physical addresses are
not the same, then an additional selector will be required so
RTEMS can access the Interrupt Descriptor Table to install
interrupt service routines. The selector number of this segment
is provided to RTEMS in the CPU Dependent Information Table.
By not requiring that logical addresses map directly
to physical addresses, the memory space of an RTEMS application
can be separated from that of a ROM monitor. For example, on
the Force Computers CPU386, the ROM monitor loads application
programs into a logical address space where logical address
0x00000000 corresponds to physical address 0x0002000. On this
board, RTEMS and the application use virtual addresses which do
not map to physical addresses.
RTEMS assumes that the DS and ES registers contain
the selector for the single data segment when a directive is
invoked. This assumption is especially important when
developing interrupt service routines.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Interrupt Processing
Different types of processors respond to the
occurrence of an interrupt in their 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 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
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
@@ -392,27 +248,6 @@ RTEMS interrupt levels 0 and 1 such that level zero
that interrupts are disabled. All other RTEMS interrupt levels
are undefined and their behavior is unpredictable.
@subsection 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 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 i386 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 within RTEMS was last calculated 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.
@subsection Interrupt Stack
The i386 family does not support a dedicated hardware
@@ -424,69 +259,26 @@ non-nested interrupt returns, RTEMS switches back to the stack
of the interrupted stack. The current stack pointer is not
altered by RTEMS on nested interrupt.
Without a dedicated interrupt stack, every task in
the system MUST have enough stack space to accommodate the worst
case stack usage of that particular task and the interrupt
service routines COMBINED. By supporting a dedicated interrupt
stack, RTEMS significantly lowers the stack requirements for
each task.
RTEMS allocates the dedicated 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.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Default Fatal Error Processing
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.
@subsection 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,
places the error code in EAX, and executes a HLT instruction to
halt the processor.
The default fatal error handler for this architecture disables processor
interrupts, places the error code in EAX, and executes a HLT instruction
to halt the processor.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Board Support Packages
An RTEMS Board Support Package (BSP) must be designed to support a
particular processor and target board combination. This chapter presents a
discussion of i386 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.
@subsection System Reset
An RTEMS based application is initiated when the i386
processor is reset. When the i386 is reset,
An RTEMS based application is initiated when the i386 processor is reset.
When the i386 is reset,
@itemize @bullet
@@ -571,6 +363,6 @@ enabled during the reset application initialization code. The reset code
which is executed before the call to initialize_executive has the following
requirements:
For more information regarding the i386s data structures and their
For more information regarding the i386 data structures and their
contents, refer to Intel's 386 Programmer's Reference Manual.

404
doc/cpu_supplement/m68k.t
View File

@@ -8,212 +8,105 @@
@ifinfo
@end ifinfo
@chapter Motorola M68xxx and Coldfire Specific Information
@chapter M68xxx and Coldfire Specific Information
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 Motorola MC68xxx
architecture dependencies in this port of RTEMS. The MC68xxx
family has a wide variety of CPU models within it. The part
numbers for these models are generally divided into MC680xx and
MC683xx. The MC680xx models are more general purpose processors
with no integrated peripherals. The MC683xx models, on the
other hand, are more specialized and have a variety of
peripherals on chip including sophisticated timers and serial
This chapter discusses the Freescale (formerly Motorola) MC68xxx
and Coldfire architectural dependencies. The MC68xxx family has a
wide variety of CPU models within it based upon different CPU core
implementations. Ignoring the Coldfire parts, the part numbers for
these models are generally divided into MC680xx and MC683xx. The MC680xx
models are more general purpose processors with no integrated peripherals.
The MC683xx models, on the other hand, are more specialized and have a
variety of peripherals on chip including sophisticated timers and serial
communications controllers.
It is highly recommended that the Motorola MC68xxx
RTEMS application developer obtain and become familiar with the
documentation for the processor being used as well as the
documentation for the family as a whole.
@subheading Architecture Documents
For information on the Motorola MC68xxx architecture,
refer to the following documents available from Motorola
(@file{http//www.moto.com/}):
For information on the MC68xxx and Coldfire architecture, refer to the following documents available from Freescale website (@file{http//www.freescale.com/}):
@itemize @bullet
@item @cite{M68000 Family Reference, Motorola, FR68K/D}.
@end itemize
@subheading MODEL SPECIFIC DOCUMENTS
For information on specific processor models and
their associated coprocessors, refer to the following documents:
@itemize @bullet
@item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}.
@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's
Manual, Motorola, MC68881UM/AD}.
@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's Manual,
Motorola, MC68881UM/AD}.
@end itemize
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section CPU Model Dependent Features
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 PowerPC 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 SPARC implementations and are of importance to RTEMS.
This section presents the set of features which vary
across m68k/Coldfire implementations that are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
cpukit/score/cpu/m68k/m68k.h based upon the particular CPU
model defined on the compilation command line.
@subsection CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the MC68020
processor, this macro is set to the string "mc68020".
@subsection Floating Point Unit
The macro M68K_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.
@code{cpukit/score/cpu/m68k/m68k.h} based upon the particular CPU
model selected on the compilation command line.
@subsection BFFFO Instruction
The macro M68K_HAS_BFFFO is set to 1 to indicate that
The macro @code{M68K_HAS_BFFFO} is set to 1 to indicate that
this CPU model has the bfffo instruction.
@subsection Vector Base Register
The macro M68K_HAS_VBR is set to 1 to indicate that
The macro @code{M68K_HAS_VBR} is set to 1 to indicate that
this CPU model has a vector base register (vbr).
@subsection Separate Stacks
The macro M68K_HAS_SEPARATE_STACKS is set to 1 to
The macro @code{M68K_HAS_SEPARATE_STACKS} is set to 1 to
indicate that this CPU model has separate interrupt, user, and
supervisor mode stacks.
@subsection Pre-Indexing Address Mode
The macro M68K_HAS_PREINDEXING is set to 1 to indicate that
The macro @code{M68K_HAS_PREINDEXING} is set to 1 to indicate that
this CPU model has the pre-indexing address mode.
@subsection Extend Byte to Long Instruction
The macro M68K_HAS_EXTB_L is set to 1 to indicate that this CPU model
The macro @code{M68K_HAS_EXTB_L} is set to 1 to indicate that this CPU model
has the extb.l instruction. This instruction is supposed to be available
in all models based on the cpu32 core as well as mc68020 and up models.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@c
@c
@c
@section Calling Conventions
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.
@subsection Processor Background
The MC68xxx architecture supports a simple yet
effective call and return mechanism. A subroutine is invoked
via the branch to subroutine (bsr) or the jump to subroutine
(jsr) instructions. These instructions push the return address
on the current stack. The return from subroutine (rts)
instruction pops the return address off the current stack and
transfers control to that instruction. It is is important to
note that the MC68xxx call and return mechanism 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.
The MC68xxx architecture supports a simple yet effective call and
return mechanism. A subroutine is invoked via the branch to subroutine
(@code{bsr}) or the jump to subroutine (@code{jsr}) instructions.
These instructions push the return address on the current stack.
The return from subroutine (@code{rts}) instruction pops the return
address off the current stack and transfers control to that instruction.
It is is important to note that the MC68xxx call and return mechanism 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.
@subsection Calling Mechanism
All RTEMS directives are invoked using either a bsr
or jsr instruction and return to the user application via the
rts instruction.
All RTEMS directives are invoked using either a @code{bsr} or @code{jsr}
instruction and return to the user application via the rts instruction.
@subsection Register Usage
As discussed above, the bsr and jsr instructions do
not automatically save any registers. RTEMS uses the registers
D0, D1, A0, and A1 as scratch registers. These registers are
not preserved by RTEMS directives therefore, the contents of
these registers should not be assumed upon return from any RTEMS
directive.
As discussed above, the @code{bsr} and @code{jsr} instructions do not
automatically save any registers. RTEMS uses the registers D0, D1,
A0, and A1 as scratch registers. These registers are not preserved by
RTEMS directives therefore, the contents of these registers should not
be assumed upon return from any RTEMS directive.
@subsection Parameter Passing
RTEMS assumes that arguments are placed on the
current stack before the directive is invoked via the bsr or jsr
instruction. The first argument is assumed to be closest to the
return address on the stack. This means that the first argument
of the C calling sequence is pushed last. The following
pseudo-code illustrates the typical sequence used to call a
RTEMS directive with three (3) arguments:
RTEMS assumes that arguments are placed on the current stack before
the directive is invoked via the bsr or jsr instruction. The first
argument is assumed to be closest to the return address on the stack.
This means that the first argument of the C calling sequence is pushed
last. The following pseudo-code illustrates the typical sequence used
to call a RTEMS directive with three (3) arguments:
@example
@group
@@ -225,41 +118,17 @@ remove arguments from the stack
@end group
@end example
The arguments to RTEMS are typically pushed onto the
stack using a move instruction with a pre-decremented stack
pointer as the destination. These arguments must be removed
from the stack after control is returned to the caller. This
removal is typically accomplished by adding the size of the
argument list in bytes to the current stack pointer.
@subsection 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.
The arguments to RTEMS are typically pushed onto the stack using a move
instruction with a pre-decremented stack pointer as the destination.
These arguments must be removed from the stack after control is returned
to the caller. This removal is typically accomplished by adding the
size of the argument list in bytes to the current stack pointer.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Memory Model
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.
@subsection Flat Memory Model
The MC68xxx family supports a flat 32-bit address
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
gigabytes). Each address is represented by a 32-bit value and
@@ -277,44 +146,23 @@ these systems. RTEMS does not support virtual memory or
segmentation on any of the MC68xxx family members.
@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
@section Interrupt Processing
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 MC68xxx's
interrupt response and control mechanisms as they pertain to
RTEMS.
Discussed in this section are the MC68xxx's interrupt response and
control mechanisms as they pertain to RTEMS.
@subsection Vectoring of an Interrupt Handler
Depending on whether or not the particular CPU
supports a separate interrupt stack, the MC68xxx family has two
different interrupt handling models.
Depending on whether or not the particular CPU supports a separate
interrupt stack, the MC68xxx family has two different interrupt handling
models.
@subsubsection Models Without Separate Interrupt Stacks
Upon receipt of an interrupt the MC68xxx family
members without separate interrupt stacks automatically perform
the following actions:
Upon receipt of an interrupt the MC68xxx family members without separate
interrupt stacks automatically perform the following actions:
@itemize @bullet
@item To Be Written
@@ -322,9 +170,8 @@ the following actions:
@subsubsection Models With Separate Interrupt Stacks
Upon receipt of an interrupt the MC68xxx family
members with separate interrupt stacks automatically perform the
following actions:
Upon receipt of an interrupt the MC68xxx family members with separate
interrupt stacks automatically perform the following actions:
@itemize @bullet
@item saves the current status register (SR),
@@ -425,19 +272,18 @@ MC68xxx CPU models with separate interrupt stacks:
This is from a post by Zoltan Kocsi <zoltan@@bendor.com.au> and is
a nice trick in certain situations. In his words:
I think somebody on this list asked about the interupt vector
handling w/o VBR and RAM at 0. The usual trick is
to initialise the vector table (except the first 2 two entries, of
course) to point to the same location BUT you also add the vector
number times 0x1000000 to them. That is, bits 31-24 contain the vector
number and 23-0 the address of the common handler.
Since the PC is 32 bit wide but the actual address bus is only 24,
the top byte will be in the PC but will be ignored when jumping
onto your routine.
I think somebody on this list asked about the interupt vector handling
w/o VBR and RAM at 0. The usual trick is to initialise the vector table
(except the first 2 two entries, of course) to point to the same location
BUT you also add the vector number times 0x1000000 to them. That is,
bits 31-24 contain the vector number and 23-0 the address of the common
handler. Since the PC is 32 bit wide but the actual address bus is only
24, the top byte will be in the PC but will be ignored when jumping onto
your routine.
Then your common interrupt routine gets this info by loading the PC
into some register and based on that info, you can jump to a vector
in a vector table pointed by a virtual VBR:
into some register and based on that info, you can jump to a vector in
a vector table pointed by a virtual VBR:
@example
//
@@ -505,95 +351,26 @@ through 7 directly correspond to MC68xxx interrupt levels. All
other RTEMS interrupt levels are undefined and their behavior is
unpredictable.
@subsection 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 MC68020 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.
@subsection 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 MC68xxx port of RTEMS supports a software managed
dedicated interrupt stack on those CPU models which do not
support a separate interrupt stack in hardware.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Default Fatal Error Processing
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.
@subsection 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 7, places the error code in D0, and executes a stop
instruction to simulate a halt processor instruction.
The default fatal error handler for this architecture disables processor
interrupts to level 7, places the error code in D0, and executes a
@code{stop} instruction to simulate a halt processor instruction.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Board Support Packages
An RTEMS Board Support Package (BSP) must be designed
to support a particular processor and target board combination.
This chapter presents a discussion of MC68020 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.
@subsection System Reset
An RTEMS based application is initiated or
re-initiated when the MC68020 processor is reset. When the
MC68020 is reset, the processor performs the following actions:
An RTEMS based application is initiated or re-initiated when the MC68020
processor is reset. When the MC68020 is reset, the processor performs
the following actions:
@itemize @bullet
@item The tracing bits of the status register are cleared to
@@ -624,17 +401,16 @@ the PC.
@subsection 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 MC68020'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.
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 MC68020's VBR value. Because interrupts
are enabled automatically by RTEMS as part of the context switch to the
first task, the VBR MUST be set by either RTEMS of the BSP before this
occurs ensure 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
@@ -656,9 +432,3 @@ the initialize executive directive.
@item Must initialize the MC68020'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.

482
doc/cpu_supplement/mips.t
View File

@@ -10,231 +10,68 @@
@end ifinfo
@chapter MIPS Specific Information
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 VENDOR XXX
architecture dependencies in this port of RTEMS. The XXX
family has a wide variety of CPU models within it. The part
numbers ...
XXX fill in some things here
It is highly recommended that the XXX
RTEMS application developer obtain and become familiar with the
documentation for the processor being used as well as the
documentation for the family as a whole.
This chapter discusses the MIPS architecture dependencies
in this port of RTEMS. The MIPS family has a wide variety
of implementations by a wide range of vendors. Consequently,
there are many, many CPU models within it.
@subheading Architecture Documents
IDT docs are online at http://www.idt.com/products/risc/Welcome.html
For information on the XXX architecture,
refer to the following documents available from VENDOR
(@file{http//www.XXX.com/}):
For information on the XXX architecture, refer to the following documents
available from VENDOR (@file{http//www.XXX.com/}):
@itemize @bullet
@item @cite{XXX Family Reference, VENDOR, PART NUMBER}.
@end itemize
@subheading MODEL SPECIFIC DOCUMENTS
For information on specific processor models and
their associated coprocessors, refer to the following documents:
@itemize @bullet
@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
@end itemize
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section CPU Model Dependent Features
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 PowerPC 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 SPARC implementations and are of importance to RTEMS.
This section presents the set of features which vary
across MIPS implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
cpukit/score/cpu/XXX/XXX.h based upon the particular CPU
model defined on the compilation command line.
@subsection CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the MODEL
processor, this macro is set to the string "XXX".
@subsection Floating Point Unit
The macro XXX_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.
@code{cpukit/score/cpu/mips/mips.h} based upon the particular CPU
model specified on the compilation command line.
@subsection Another Optional Feature
The macro XXX
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Calling Conventions
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.
@subsection Processor Background
The MC68xxx architecture supports a simple yet
effective call and return mechanism. A subroutine is invoked
via the branch to subroutine (@code{XXX}) or the jump to subroutine
(@code{XXX}) instructions. These instructions push the return address
on the current stack. The return from subroutine (@code{XXX})
instruction pops the return address off the current stack and
transfers control to that instruction. It is is important to
note that the XXX call and return mechanism 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.
TBD
@subsection Calling Mechanism
All RTEMS directives are invoked using either a @code{XXX}
or @code{XXX} instruction and return to the user application via the
@code{XXX} instruction.
TBD
@subsection Register Usage
As discussed above, the @code{XXX} and @code{XXX} instructions do
not automatically save any registers. RTEMS uses the registers
@b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers. These registers are
not preserved by RTEMS directives therefore, the contents of
these registers should not be assumed upon return from any RTEMS
directive.
TBD
@subsection Parameter Passing
RTEMS assumes that arguments are placed on the
current stack before the directive is invoked via the @code{XXX} or @code{XXX}
instruction. The first argument is assumed to be closest to the
return address on the stack. This means that the first argument
of the C calling sequence is pushed last. The following
pseudo-code illustrates the typical sequence used to call a
RTEMS directive with three (3) arguments:
@example
@group
push third argument
push second argument
push first argument
invoke directive
remove arguments from the stack
@end group
@end example
The arguments to RTEMS are typically pushed onto the
stack using a move instruction with a pre-decremented stack
pointer as the destination. These arguments must be removed
from the stack after control is returned to the caller. This
removal is typically accomplished by adding the size of the
argument list in bytes to the current stack pointer.
@subsection 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.
TBD
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Memory Model
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.
@subsection Flat Memory Model
The XXX family supports a flat 32-bit address
The MIPS family supports a flat 32-bit address
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
gigabytes). Each address is represented by a 32-bit value and
is byte addressable. The address may be used to reference a
@@ -242,88 +79,32 @@ single byte, word (2-bytes), or long word (4 bytes). Memory
accesses within this address space are performed in big endian
fashion by the processors in this family.
Some of the XXX family members such as the
XXX, XXX, and XXX support virtual memory and
segmentation. The XXX requires external hardware support
such as the XXX Paged Memory Management Unit coprocessor
which is typically used to perform address translations for
these systems. RTEMS does not support virtual memory or
segmentation on any of the XXX family members.
Some of the MIPS family members such as the support virtual memory and
segmentation. RTEMS does not support virtual memory or
segmentation on any of these family members.
@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
@section Interrupt Processing
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
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
unique architecture. Discussed in this chapter are the MIPS's
interrupt response and control mechanisms as they pertain to
RTEMS.
@subsection 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.
@subsubsection 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
@subsubsection 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 TBD
@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
@@ -331,238 +112,35 @@ 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
@subsection 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.
@subsection 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.
@subsection 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 mips port of RTEMS supports a software managed
dedicated interrupt stack on those CPU models which do not
support a separate interrupt stack in hardware.
TBD
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Default Fatal Error Processing
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.
@subsection 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 disables processor interrupts,
places the error code in @b{XXX}, and executes a @code{XXX}
instruction to simulate a halt processor instruction.
The default fatal error handler for this target architecture disables
processor interrupts, places the error code in @b{XXX}, and executes a
@code{XXX} instruction to simulate a halt processor instruction.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Board Support Packages
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.
@subsection 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:
re-initiated when the processor is reset. When the
processor is reset, it performs the following actions:
@itemize @bullet
@item The tracing bits of the status register are cleared to
disable tracing.
@item TBD
@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
@subsection 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.
TBD

258
doc/cpu_supplement/powerpc.t
View File

@@ -10,18 +10,10 @@
@end ifinfo
@chapter PowerPC Specific Information
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 PowerPC architecture
dependencies in this port of RTEMS.
This chapter discusses the PowerPC architecture dependencies
in this port of RTEMS. The PowerPC family has a wide variety
of implementations by a range of vendors. Consequently,
there are many, many CPU models within it.
It is highly recommended that the PowerPC RTEMS
application developer obtain and become familiar with the
@@ -61,7 +53,6 @@ Unit Reference Manual} (Motorola Document RCPUURM/AD).
@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
@end itemize
Motorola maintains an on-line electronic library for the PowerPC
@@ -85,85 +76,28 @@ supports the addition of user provided device models which can be
used to allow one to develop and debug embedded applications using
the simulator.
The latest version of PSIM is made available to the public via
anonymous ftp at ftp://ftp.ci.com.au/pub/psim or
ftp://cambridge.cygnus.com/pub/psim. There is also a mailing list
at powerpc-psim@@ci.com.au.
The latest version of PSIM is included in GDB and enabled on pre-built
binaries provided by the RTEMS Project.
@c
@c COPYRIGHT (c) 1989-2007.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section CPU Model Dependent Features
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, and PowerPC 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.
@subsection CPU Model Feature Flags
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 section presents the set of features which vary
across PowerPC implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
cpukit/score/cpu/ppc/ppc.h based upon the particular CPU
model defined on the compilation command line.
@code{cpukit/score/cpu/powerpc/powerpc.h} based upon the particular CPU
model specified on the compilation command line.
@subsubsection CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the PowerPC 603e
model, this macro is set to the string "PowerPC 603e".
@subsubsection Floating Point Unit
The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model
has a hardware floating point unit and 0 otherwise.
@subsubsection Alignment
@subsection Alignment
The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment
requirement for data types on a byte boundary. This value is used
to derive the alignment restrictions for memory allocated from
regions and partitions.
@subsubsection Cache Alignment
@subsection Cache Alignment
The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is
used to align the entry point of critical routines so that as much code
@@ -174,24 +108,24 @@ In addition, the "shortcut" data structure used by the PowerPC implementation
to ease access to data elements frequently accessed by RTEMS routines
implemented in assembly language is aligned using this value.
@subsubsection Maximum Interrupts
@subsection Maximum Interrupts
The macro PPC_INTERRUPT_MAX is set to the number of exception sources
supported by this PowerPC model.
@subsubsection Has Double Precision Floating Point
@subsection Has Double Precision Floating Point
The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model
has support for double precision floating point numbers. This is
important because the floating point registers need only be four bytes
wide (not eight) if double precision is not supported.
@subsubsection Critical Interrupts
@subsection Critical Interrupts
The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
has the Critical Interrupt capability as defined by the IBM 403 models.
@subsubsection Use Multiword Load/Store Instructions
@subsection Use Multiword Load/Store Instructions
The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and
store instructions should be used to perform context switch operations.
@@ -199,15 +133,15 @@ The relative efficiency of multiword load and store instructions versus
an equivalent set of single word load and store instructions varies based
upon the PowerPC model.
@subsubsection Instruction Cache Size
@subsection Instruction Cache Size
The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
@subsubsection Data Cache Size
@subsection Data Cache Size
The macro PPC_D_CACHE is set to the size in bytes of the data cache.
@subsubsection Debug Model
@subsection Debug Model
The macro PPC_DEBUG_MODEL is set to indicate the debug support features
present in this CPU model. The following debug support feature sets
@@ -246,37 +180,13 @@ indicates that this CPU model follows the low power model defined for
the PPC603e.
@end table
@c
@c COPYRIGHT (c) 1989-2007.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Calling Conventions
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.
RTEMS supports the Embedded Application Binary Interface (EABI)
calling convention. Documentation for EABI is available by sending
a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
@@ -467,33 +377,12 @@ load first argument into r3
invoke directive
@end example
@subsection User-Provided Routines
All user-provided routines invoked by RTEMS, such as
user extensions, device drivers, and MPCI routines, must also
adhere to these same calling conventions.
@c
@c COPYRIGHT (c) 1989-2007.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Memory Model
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.
@subsection Flat Memory Model
The PowerPC architecture supports a variety of memory models.
@@ -593,26 +482,17 @@ involving the PowerPC are not supported.
@section Interrupt Processing
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
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 PowerPC's
interrupt response and control mechanisms as they pertain to
RTEMS.
RTEMS and associated documentation uses the terms
interrupt and vector. In the PowerPC architecture, these terms
correspond to exception and exception handler, respectively. The terms will
be used interchangeably in this manual.
RTEMS and associated documentation uses the terms interrupt and vector.
In the PowerPC architecture, these terms correspond to exception and
exception handler, respectively. The terms will be used interchangeably
in this manual.
@subsection Synchronous Versus Asynchronous Exceptions
@@ -722,77 +602,14 @@ Setting bit 2 of the interrupt level enables External Interrupt execptions.
All other bits in the RTEMS task interrupt level are ignored.
@subsection 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 Critical Interrupts, External Interrupts
and Machine Checks 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 PowerPC 603e 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.]
If a PowerPC implementation provides non-maskable interrupts (NMI)
which cannot be disabled, ISRs which process these interrupts
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.
@subsection Interrupt Stack
The PowerPC architecture does not provide for a
dedicated interrupt stack. Thus by default, exception handlers would
execute on the stack of the RTEMS task which they interrupted.
This artificially inflates the stack requirements for each task
since EVERY task stack would have to include enough space to
account for the worst case interrupt stack requirements in
addition to it's own worst case usage. RTEMS addresses this
problem on the PowerPC by providing a dedicated interrupt stack
managed by software.
During system initialization, 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. As
part of processing a non-nested interrupt, RTEMS will switch to
the interrupt stack before invoking the installed handler.
@c
@c COPYRIGHT (c) 1989-2007.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Default Fatal Error Processing
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.
@subsection 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:
The default fatal error handler for this architecture performs the
following actions:
@itemize @bullet
@@ -813,23 +630,11 @@ If the Program Exception returns, then the following actions are performed:
@end itemize
@c
@c COPYRIGHT (c) 1989-2007.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Board Support Packages
An RTEMS Board Support Package (BSP) must be designed
to support a particular processor and target board combination.
This chapter presents a discussion of PowerPC 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.
@subsection System Reset
An RTEMS based application is initiated or
@@ -847,15 +652,6 @@ CPU may execute a hard reset.
@subsection Processor Initialization
It is the responsibility of the application's
initialization code to initialize the CPU and board
to a quiescent state before invoking the @code{rtems_initialize_executive}
directive. It is recommended that the BSP utilize the @code{predriver_hook}
to install default handlers for all exceptions. These default handlers
may be overwritten as various device drivers and subsystems install
their own exception handlers. Upon completion of RTEMS executive
initialization, all interrupts are enabled.
If this PowerPC implementation supports on-chip caching
and this is to be utilized, then it should be enabled during the
reset application initialization code. On-chip caching has been
@@ -873,8 +669,8 @@ the PowrePC version has the following specific requirements:
to 0 so the PowerPC remains in the supervisor state.
@item Must set stack pointer (sp or r1) such that a minimum stack
size of MINIMUM_STACK_SIZE bytes is provided for the
@code{rtems_initialize_executive} directive.
size of MINIMUM_STACK_SIZE bytes is provided for the RTEMS initialization
sequence.
@item Must disable all external interrupts (i.e. clear the EI (EE)
bit of the machine state register).

36
doc/cpu_supplement/preface.texi
View File

@@ -7,7 +7,7 @@
@c
@ifinfo
@node Preface, ARM Specific Information, Top, Top
@node Preface, Port Specific Information, Top, Top
@end ifinfo
@unnumbered Preface
@@ -21,5 +21,35 @@ issues, interrupt processing, exact RTEMS memory requirements,
performance data, header files, and the assembly language
interface to the executive.
Each chapter in this document discusses the details of how
RTEMS was ported.
Each architecture represents a CPU family and usually there are
a wide variety of CPU models within it. These models share a
common Instruction Set Architecture (ISA) which often varies
based upon some well-defined rules. There are often
multiple implementations of the ISA and these may be from
one or multiple vendors.
On top of variations in the ISA, there may also be variations
which occur when a CPU core implementation is combined with
a set of peripherals to form a system on chip. For example,
there are many ARM CPU models from numerous semiconductor
vendors and a wide variety of peripherals. But at the
ISA level, they share a common compaability.
RTEMS depends upon this core similarity across the CPU models
and leverages that to minimize the source code that is specific
to any particular CPU core implementation or CPU model.
This manual is separate and distinct from the RTEMS Porting
Guide. That manual is a guide on porting RTEMS to a new
architecture. This manual is focused on the more mundane
CPU architecture specific issues that may impact
application development. For example, if you need to write
a subroutine in assembly language, it is critical to understand
the calling conventions for the target architecture.
The first chapter in this manual describes these issues
in general terms. In a sense, it is posing the questions
one should be aware may need to be answered and understood
when porting an RTEMS application to a new architecture.
Each subsequent chapter gives the answers to those questions
for a particular CPU architecture.

504
doc/cpu_supplement/sh.t
View File

@@ -10,239 +10,84 @@
@end ifinfo
@chapter SuperH Specific Information
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 chapter discusses the SuperH architecture dependencies
in this port of RTEMS. The SuperH family has a wide variety
of implementations by a wide range of vendors. Consequently,
there are many, many CPU models within it.
This document discusses the VENDOR XXX
architecture dependencies in this port of RTEMS. The XXX
family has a wide variety of CPU models within it. The part
numbers ...
XXX fill in some things here
It is highly recommended that the XXX
RTEMS application developer obtain and become familiar with the
documentation for the processor being used as well as the
documentation for the family as a whole.
@subheading Architecture Documents
For information on the XXX architecture,
For information on the SuperH architecture,
refer to the following documents available from VENDOR
(@file{http//www.XXX.com/}):
@itemize @bullet
@item @cite{XXX Family Reference, VENDOR, PART NUMBER}.
@end itemize
@subheading MODEL SPECIFIC DOCUMENTS
For information on specific processor models and
their associated coprocessors, refer to the following documents:
@itemize @bullet
@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
@item @cite{SuperH Family Reference, VENDOR, PART NUMBER}.
@end itemize
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section CPU Model Dependent Features
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 PowerPC 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 SPARC implementations and are of importance to RTEMS.
across SuperH implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
cpukit/score/cpu/XXX/XXX.h based upon the particular CPU
model defined on the compilation command line.
@subsection CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the MODEL
processor, this macro is set to the string "XXX".
@subsection Floating Point Unit
The macro XXX_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.
@code{cpukit/score/cpu/sh/sh.h} based upon the particular CPU
model specified on the compilation command line.
@subsection Another Optional Feature
The macro XXX
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Calling Conventions
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.
The Hitachi SH architecture supports a simple yet
effective call and return mechanism. A subroutine is invoked
via the branch to subroutine (XXX) or the jump to subroutine
(XXX) instructions. These instructions push the return address
on the current stack. The return from subroutine (rts)
instruction pops the return address off the current stack and
transfers control to that instruction. It is is important to
note that the MC68xxx call and return mechanism 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.
@subsection Calling Mechanism
All RTEMS directives are invoked using either a bsr
or jsr instruction and return to the user application via the
rts instruction.
All RTEMS directives are invoked using a @code{XXX}
instruction and return to the user application via the
@code{XXX} instruction.
@subsection Register Usage
As discussed above, the bsr and jsr instructions do
not automatically save any registers. RTEMS uses the registers
D0, D1, A0, and A1 as scratch registers. These registers are
not preserved by RTEMS directives therefore, the contents of
these registers should not be assumed upon return from any RTEMS
directive.
The SH1 has 16 general registers (r0..r15).
@itemize @bullet
> > The SH1 has 16 general registers (r0..r15)
> > r0..r3 used as general volatile registers
> > r4..r7 used to pass up to 4 arguments to functions, arguments above 4 are
> > passed via the stack)
> > r8..13 caller saved registers (i.e. push them to the stack if you need them
> > inside of a function)
> > r14 frame pointer
> > r15 stack pointer
>
@item r0..r3 used as general volatile registers
@item r4..r7 used to pass up to 4 arguments to functions, arguments
above 4 are
passed via the stack)
@item r8..13 caller saved registers (i.e. push them to the stack if you
need them inside of a function)
@item r14 frame pointer
@item r15 stack pointer
@end itemize
@subsection Parameter Passing
RTEMS assumes that arguments are placed on the
current stack before the directive is invoked via the bsr or jsr
instruction. The first argument is assumed to be closest to the
return address on the stack. This means that the first argument
of the C calling sequence is pushed last. The following
pseudo-code illustrates the typical sequence used to call a
RTEMS directive with three (3) arguments:
@example
@group
push third argument
push second argument
push first argument
invoke directive
remove arguments from the stack
@end group
@end example
The arguments to RTEMS are typically pushed onto the
stack using a move instruction with a pre-decremented stack
pointer as the destination. These arguments must be removed
from the stack after control is returned to the caller. This
removal is typically accomplished by adding the size of the
argument list in bytes to the current stack pointer.
@subsection 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.
XXX
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Memory Model
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.
@subsection Flat Memory Model
The XXX family supports a flat 32-bit address
The SuperH family supports a flat 32-bit address
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
gigabytes). Each address is represented by a 32-bit value and
is byte addressable. The address may be used to reference a
@@ -250,88 +95,34 @@ single byte, word (2-bytes), or long word (4 bytes). Memory
accesses within this address space are performed in big endian
fashion by the processors in this family.
Some of the XXX family members such as the
XXX, XXX, and XXX support virtual memory and
segmentation. The XXX requires external hardware support
such as the XXX Paged Memory Management Unit coprocessor
which is typically used to perform address translations for
these systems. RTEMS does not support virtual memory or
segmentation on any of the XXX family members.
Some of the SuperH family members support virtual memory and
segmentation. RTEMS does not support virtual memory or
segmentation on any of the SuperH family members. It is the
responsibility of the BSP to initialize the mapping for
a flat memory model.
@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
@section Interrupt Processing
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
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 SH's
unique architecture. Discussed in this chapter are the MIPS's
interrupt response and control mechanisms as they pertain to
RTEMS.
@subsection Vectoring of an Interrupt Handler
Depending on whether or not the particular CPU
supports a separate interrupt stack, the SH family has two
different interrupt handling models.
@subsubsection Models Without Separate Interrupt Stacks
Upon receipt of an interrupt the SH family
members without separate interrupt stacks automatically perform
the following actions:
@itemize @bullet
@item To Be Written
@end itemize
@subsubsection Models With Separate Interrupt Stacks
Upon receipt of an interrupt the SH family
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 TBD
@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
@@ -339,238 +130,35 @@ 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
@subsection 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.
@subsection 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 XXX 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.
@subsection 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.
TBD
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Default Fatal Error Processing
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.
@subsection 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 disables processor interrupts,
places the error code in @b{XXX}, and executes a @code{XXX}
The default fatal error handler for this architecture disables processor
interrupts, places the error code in @b{XXX}, and executes a @code{XXX}
instruction to simulate a halt processor instruction.
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@section Board Support Packages
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.
@subsection 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:
re-initiated when the processor is reset. When the
processor is reset, it performs the following actions:
@itemize @bullet
@item The tracing bits of the status register are cleared to
disable tracing.
@item TBD
@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
@subsection 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.
TBD