source: rtems/doc/cpu_supplement/general.t @ 42cf7c7

4.104.114.95
Last change on this file since 42cf7c7 was 42cf7c7, checked in by Joel Sherrill <joel.sherrill@…>, on 06/02/08 at 16:09:56

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

  • 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.
  • Property mode set to 100644
File size: 14.4 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@ifinfo
10@end ifinfo
11@chapter Port Specific Information
12
13This chaper provides a general description of the type of
14architecture specific information which is in each of
15the architecture specific chapters that follow.  The outline
16of this chapter is identical to that of the architecture
17specific chapters.
18
19In each of the architecture specific chapters, this
20introductory section will provide an overview of the
21architecture
22
23@subheading Architecture Documents
24
25In each of the architecture specific chapters, this
26section will provide pointers on where to obtain
27documentation.
28
29@c
30@c
31@c
32@section CPU Model Dependent Features
33
34Microprocessors are generally classified into families with a variety of
35CPU models or implementations within that family.  Within a processor
36family, there is a high level of binary compatibility.  This family
37may be based on either an architectural specification or on maintaining
38compatibility with a popular processor.  Recent microprocessor families
39such as the SPARC or PowerPC are based on an architectural specification
40which is independent or any particular CPU model or implementation.
41Older families such as the M68xxx and the iX86 evolved as the manufacturer
42strived to produce higher performance processor models which maintained
43binary compatibility with older models.
44
45RTEMS takes advantage of the similarity of the various models within a
46CPU family.  Although the models do vary in significant ways, the high
47level of compatibility makes it possible to share the bulk of the CPU
48dependent executive code across the entire family.  Each processor family
49supported by RTEMS has a list of features which vary between CPU models
50within a family.  For example, the most common model dependent feature
51regardless of CPU family is the presence or absence of a floating point
52unit or coprocessor.  When defining the list of features present on a
53particular CPU model, one simply notes that floating point hardware
54is or is not present and defines a single constant appropriately.
55Conditional compilation is utilized to include the appropriate source
56code for this CPU model's feature set.  It is important to note that
57this means that RTEMS is thus compiled using the appropriate feature set
58and compilation flags optimal for this CPU model used.  The alternative
59would be to generate a binary which would execute on all family members
60using only the features which were always present.
61
62The set of CPU model feature macros are defined in the file
63@code{cpukit/score/cpu/CPU/rtems/score/cpu.h} based upon the GNU tools
64multilib variant that is appropriate for the particular CPU model defined
65on the compilation command line.
66
67In each of the architecture specific chapters, this section presents
68the set of features which vary across various implementations of the
69architecture that may be of importance to RTEMS application developers.
70
71The subsections will vary amongst the target architecture chapters as
72the specific features may vary.  However, each port will include a few
73common features such as the CPU Model Name and presence of a hardware
74Floating Point Unit.  The common features are described here.
75
76@subsection CPU Model Name
77
78The macro @code{CPU_MODEL_NAME} is a string which designates
79the name of this CPU model.  For example, for the MC68020
80processor model from the m68k architecture, this macro
81is set to the string "mc68020".
82
83@subsection Floating Point Unit
84
85In most architectures, the presence of a floating point unit is an option.
86It does not matter whether the hardware floating point support is
87incorporated on-chip or is an external coprocessor as long as it
88appears an FPU per the ISA.  However, if a hardware FPU is not present,
89it is possible that the floating point emulation library for this
90CPU is not reentrant and thus context switched by RTEMS.
91
92RTEMS provides two feature macros to indicate the FPU configuration:
93
94@itemize @bullet
95
96@item CPU_HARDWARE_FP
97is set to TRUE to indicate that a hardware FPU is present.
98
99@item CPU_SOFTWARE_FP
100is set to TRUE to indicate that a hardware FPU is not present and that
101the FP software emulation will be context switched.
102
103@end itemize
104
105@c
106@c
107@c
108@section Calling Conventions
109
110Each high-level language compiler generates subroutine entry and exit
111code based upon a set of rules known as the compiler's calling convention.
112These rules address the following issues:
113
114@itemize @bullet
115@item register preservation and usage
116@item parameter passing
117@item call and return mechanism
118@end itemize
119
120A compiler's calling convention is of importance when
121interfacing to subroutines written in another language either
122assembly or high-level.  Even when the high-level language and
123target processor are the same, different compilers may use
124different calling conventions.  As a result, calling conventions
125are both processor and compiler dependent.
126
127@subsection Calling Mechanism
128
129In each of the architecture specific chapters, this subsection will
130describe the instruction(s) used to perform a @i{normal} subroutine
131invocation.  All RTEMS directives are invoked as @i{normal} C language
132functions so it is important to the user application to understand the
133call and return mechanism.
134
135@subsection Register Usage
136
137In each of the architecture specific chapters, this subsection will
138detail the set of registers which are @b{NOT} preserved across subroutine
139invocations.  The registers which are not preserved are assumed to be
140available for use as scratch registers.  Therefore, the contents of these
141registers should not be assumed upon return from any RTEMS directive.
142
143In some architectures, there may be a set of registers made available
144automatically as a side-effect of the subroutine invocation
145mechanism.
146
147@subsection Parameter Passing
148
149In each of the architecture specific chapters, this subsection will
150describe the mechanism by which the parameters or arguments are passed
151by the caller to a subroutine.  In some architectures, all parameters
152are passed on the stack while in others some are passed in registers.
153
154@subsection User-Provided Routines
155
156All user-provided routines invoked by RTEMS, such as
157user extensions, device drivers, and MPCI routines, must also
158adhere to these calling conventions.
159
160@c
161@c
162@c
163@section Memory Model
164
165A processor may support any combination of memory
166models ranging from pure physical addressing to complex demand
167paged virtual memory systems.  RTEMS supports a flat memory
168model which ranges contiguously over the processor's allowable
169address space.  RTEMS does not support segmentation or virtual
170memory of any kind.  The appropriate memory model for RTEMS
171provided by the targeted processor and related characteristics
172of that model are described in this chapter.
173
174@subsection Flat Memory Model
175
176Most RTEMS target processors can be initialized to support a flat address
177space.  Although the size of addresses varies between architectures, on
178most RTEMS targets, an address is 32-bits wide which defines addresses
179ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes).  Each address is
180represented by a 32-bit value and is byte addressable.  The address may be
181used to reference a single byte, word (2-bytes), or long word (4 bytes).
182Memory accesses within this address space may be performed in little or
183big endian fashion.
184
185On smaller CPU architectures supported by RTEMS, the address space
186may only be 20 or 24 bits wide. 
187
188If the CPU model has support for virtual memory or segmentation, it is
189the responsibility of the Board Support Package (BSP) to initialize the
190MMU hardware to perform address translations which correspond to flat
191memory model.
192
193In each of the architecture specific chapters, this subsection will
194describe any architecture characteristics that differ from this general
195description.
196
197@c
198@c
199@c
200@section Interrupt Processing
201
202Different types of processors respond to the occurrence of an interrupt
203in its own unique fashion. In addition, each processor type provides
204a control mechanism to allow for the proper handling of an interrupt.
205The processor dependent response to the interrupt modifies the current
206execution state and results in a change in the execution stream.  Most
207processors require that an interrupt handler utilize some special control
208mechanisms to return to the normal processing stream.  Although RTEMS
209hides many of the processor dependent details of interrupt processing,
210it is important to understand how the RTEMS interrupt manager is mapped
211onto the processor's unique architecture.
212
213RTEMS supports a dedicated interrupt stack for all architectures.
214On architectures with hardware support for a dedicated interrupt stack,
215it will be initialized such that when an interrupt occurs, the processor
216automatically switches to this dedicated stack.  On architectures without
217hardware support for a dedicated interrupt stack which is separate from
218those of the tasks, RTEMS will support switching to a dedicated stack
219for interrupt processing.
220
221Without a dedicated interrupt stack, every task in
222the system MUST have enough stack space to accommodate the worst
223case stack usage of that particular task and the interrupt
224service routines COMBINED.  By supporting a dedicated interrupt
225stack, RTEMS significantly lowers the stack requirements for
226each task.
227
228A nested interrupt is processed similarly with the exception that since
229the CPU is already executing on the interrupt stack, there is no need
230to switch to the interrupt stack.
231
232In some configurations, RTEMS allocates the interrupt stack from the
233Workspace Area.  The amount of memory allocated for the interrupt stack
234is user configured and based upon the @code{confdefs.h} parameter
235@code{CONFIGURE_INTERRUPT_STACK_SIZE}.  This parameter is described
236in detail in the Configuring a System chapter of the User's Guide.
237On configurations in which RTEMS allocates the interrupt stack, during
238the initialization process, RTEMS will also install its interrupt stack.
239In other configurations, the interrupt stack is allocated and installed
240by the Board Support Package (BSP).
241
242In each of the architecture specific chapters, this section discesses
243the interrupt response and control mechanisms of the architecture as
244they pertain to RTEMS.
245
246@subsection Vectoring of an Interrupt Handler
247
248In each of the architecture specific chapters, this subsection will
249describe the architecture specific details of the interrupt vectoring
250process.  In particular, it should include a description of the
251Interrupt Stack Frame (ISF).
252
253@subsection Interrupt Levels
254
255In each of the architecture specific chapters, this subsection will
256describe how the interrupt levels available on this particular architecture
257are mapped onto the 255 reserved in the task mode.  The interrupt level
258value of zero (0) should always mean that interrupts are enabled.
259
260Any use of an  interrupt level that is is not undefined on a particular
261architecture may result in behavior that is unpredictable.
262
263@subsection Disabling of Interrupts by RTEMS
264
265During the execution of directive calls, critical sections of code may
266be executed.  When these sections are encountered, RTEMS disables all
267external interrupts before the execution of this section and restores
268them to the previous level upon completion of the section.  RTEMS has
269been optimized to ensure that interrupts are disabled for the shortest
270number of instructions possible.  Since the precise number of instructions
271and their execution time varies based upon target CPU family, CPU model,
272board memory speed, compiler version, and optimization level, it is
273not practical to provide the precise number for all possible RTEMS
274configurations.
275
276Historically, the measurements were made by hand analyzing and counting
277the execution time of instruction sequences during interrupt disable
278critical sections.  For reference purposes, on a 16 Mhz Motorola
279MC68020, the maximum interrupt disable period was typically approximately
280ten (10) to thirteen (13) microseconds.  This architecture was memory bound
281and had a slow bit scan instruction.  In contrast, during the same
282period a 14 Mhz SPARC would have a worst case disable time of approximately
283two (2) to three (3) microseconds because it had a single cycle bit scan
284instruction and used fewer cycles for memory accesses.
285
286If you are interested in knowing the worst case execution time for
287a particular version of RTEMS, please contact OAR Corporation and
288we will be happy to product the results as a consulting service.
289
290Non-maskable interrupts (NMI) cannot be disabled, and
291ISRs which execute at this level MUST NEVER issue RTEMS system
292calls.  If a directive is invoked, unpredictable results may
293occur due to the inability of RTEMS to protect its critical
294sections.  However, ISRs that make no system calls may safely
295execute as non-maskable interrupts.
296
297
298@c
299@c
300@c
301@section Default Fatal Error Processing
302
303Upon detection of a fatal error by either the application or RTEMS during
304initialization the @code{rtems_fatal_error_occurred} directive supplied
305by the Fatal Error Manager is invoked.  The Fatal Error Manager will
306invoke the user-supplied fatal error handlers.  If no user-supplied
307handlers are configured or all of them return without taking action to
308shutdown the processor or reset, a default fatal error handler is invoked.
309
310Most of the action performed as part of processing the fatal error are
311described in detail in the Fatal Error Manager chapter in the User's
312Guide.  However, the if no user provided extension or BSP specific fatal
313error handler takes action, the final default action is to invoke a
314CPU architecture specific function.  Typically this function disables
315interrupts and halts the processor.
316
317In each of the architecture specific chapters, this describes the precise
318operations of the default CPU specific fatal error handler.
319
320@c
321@c
322@c
323
324@section Board Support Packages
325
326An RTEMS Board Support Package (BSP) must be designed to support a
327particular processor model and target board combination.
328
329In each of the architecture specific chapters, this section will present
330a discussion of architecture specific BSP issues.   For more information
331on developing a BSP, refer to BSP and Device Driver Development Guide
332and the chapter titled Board Support Packages in the RTEMS
333Applications User's Guide.
334
335@subsection System Reset
336
337An RTEMS based application is initiated or re-initiated when the processor
338is reset or transfer is passed to it from a boot monitor or ROM monitor.
339
340In each of the architecture specific chapters, this subsection describes
341the actions that the BSP must tak assuming the application gets control
342when the microprocessor is reset.
Note: See TracBrowser for help on using the repository browser.