source: rtems/doc/cpu_supplement/powerpc.t @ f09b997

4.104.114.95
Last change on this file since f09b997 was f09b997, checked in by Joel Sherrill <joel.sherrill@…>, on 11/28/07 at 21:46:05

2007-11-28 Joel Sherrill <joel.sherrill@…>

  • cpu_supplement/powerpc.t: Eliminate PowerPC specific elements from the CPU Table. They have been replaced with variables named bsp_XXX as needed.
  • Property mode set to 100644
File size: 35.1 KB
Line 
1@c
2@c  COPYRIGHT (c) 1989-2007.
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 PowerPC Specific Information
12
13The Real Time Executive for Multiprocessor Systems
14(RTEMS) is designed to be portable across multiple processor
15architectures.  However, the nature of real-time systems makes
16it essential that the application designer understand certain
17processor dependent implementation details.  These processor
18dependencies include calling convention, board support package
19issues, interrupt processing, exact RTEMS memory requirements,
20performance data, header files, and the assembly language
21interface to the executive.
22
23This document discusses the PowerPC architecture
24dependencies in this port of RTEMS.
25
26It is highly recommended that the PowerPC RTEMS
27application developer obtain and become familiar with the
28documentation for the processor being used as well as the
29specification for the revision of the PowerPC architecture which
30corresponds to that processor.
31
32@subheading PowerPC Architecture Documents
33
34For information on the PowerPC architecture, refer to
35the following documents available from Motorola and IBM:
36
37@itemize @bullet
38
39@item @cite{PowerPC Microprocessor Family: The Programming Environment}
40(Motorola Document MPRPPCFPE-01).
41
42@item @cite{IBM PPC403GB Embedded Controller User's Manual}.
43
44@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing
45Unit Reference Manual} (Motorola Document RCPUURM/AD).
46
47@item @cite{PowerPC 601 RISC Microprocessor User's Manual}
48(Motorola Document MPR601UM/AD).
49
50@item @cite{PowerPC 603 RISC Microprocessor User's Manual}
51(Motorola Document MPR603UM/AD).
52
53@item @cite{PowerPC 603e RISC Microprocessor User's Manual}
54(Motorola Document MPR603EUM/AD).
55
56@item @cite{PowerPC 604 RISC Microprocessor User's Manual}
57(Motorola Document MPR604UM/AD).
58
59@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual}
60(Motorola Document MPC821UM/AD).
61
62@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
63
64
65@end itemize
66
67Motorola maintains an on-line electronic library for the PowerPC
68at the following URL:
69
70@itemize @code{ }
71@item @cite{http://www.mot.com/powerpc/library/library.html}
72@end itemize
73
74This site has a a wealth of information and examples.  Many of the
75manuals are available from that site in electronic format.
76
77@subheading PowerPC Processor Simulator Information
78
79PSIM is a program which emulates the Instruction Set Architecture
80of the PowerPC microprocessor family.  It is reely available in source
81code form under the terms of the GNU General Public License (version
822 or later).  PSIM can be integrated with the GNU Debugger (gdb) to
83execute and debug PowerPC executables on non-PowerPC hosts.  PSIM
84supports the addition of user provided device models which can be
85used to allow one to develop and debug embedded applications using
86the simulator.
87
88The latest version of PSIM is made available to the public via
89anonymous ftp at ftp://ftp.ci.com.au/pub/psim or
90ftp://cambridge.cygnus.com/pub/psim.  There is also a mailing list
91at powerpc-psim@@ci.com.au.
92
93
94@c
95@c  COPYRIGHT (c) 1989-2007.
96@c  On-Line Applications Research Corporation (OAR).
97@c  All rights reserved.
98@c
99@c  $Id$
100@c
101
102@section CPU Model Dependent Features
103
104
105Microprocessors are generally classified into
106families with a variety of CPU models or implementations within
107that family.  Within a processor family, there is a high level
108of binary compatibility.  This family may be based on either an
109architectural specification or on maintaining compatibility with
110a popular processor.  Recent microprocessor families such as the
111SPARC, and PowerPC are based on an architectural specification
112which is independent or any particular CPU model or
113implementation.  Older families such as the M68xxx and the iX86
114evolved as the manufacturer strived to produce higher
115performance processor models which maintained binary
116compatibility with older models.
117
118RTEMS takes advantage of the similarity of the
119various models within a CPU family.  Although the models do vary
120in significant ways, the high level of compatibility makes it
121possible to share the bulk of the CPU dependent executive code
122across the entire family.
123
124@subsection CPU Model Feature Flags
125
126Each processor family supported by RTEMS has a
127list of features which vary between CPU models
128within a family.  For example, the most common model dependent
129feature regardless of CPU family is the presence or absence of a
130floating point unit or coprocessor.  When defining the list of
131features present on a particular CPU model, one simply notes
132that floating point hardware is or is not present and defines a
133single constant appropriately.  Conditional compilation is
134utilized to include the appropriate source code for this CPU
135model's feature set.  It is important to note that this means
136that RTEMS is thus compiled using the appropriate feature set
137and compilation flags optimal for this CPU model used.  The
138alternative would be to generate a binary which would execute on
139all family members using only the features which were always
140present.
141
142This section presents the set of features which vary
143across PowerPC implementations and are of importance to RTEMS.
144The set of CPU model feature macros are defined in the file
145cpukit/score/cpu/ppc/ppc.h based upon the particular CPU
146model defined on the compilation command line.
147
148@subsubsection CPU Model Name
149
150The macro CPU_MODEL_NAME is a string which designates
151the name of this CPU model.  For example, for the PowerPC 603e
152model, this macro is set to the string "PowerPC 603e".
153
154@subsubsection Floating Point Unit
155
156The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model
157has a hardware floating point unit and 0 otherwise.
158
159@subsubsection Alignment
160
161The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment
162requirement for data types on a byte boundary.  This value is used
163to derive the alignment restrictions for memory allocated from
164regions and partitions.
165
166@subsubsection Cache Alignment
167
168The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache.  It is
169used to align the entry point of critical routines so that as much code
170as possible can be retrieved with the initial read into cache.  This
171is done for the interrupt handler as well as the context switch routines.
172
173In addition, the "shortcut" data structure used by the PowerPC implementation
174to ease access to data elements frequently accessed by RTEMS routines
175implemented in assembly language is aligned using this value.
176
177@subsubsection Maximum Interrupts
178
179The macro PPC_INTERRUPT_MAX is set to the number of exception sources
180supported by this PowerPC model.
181
182@subsubsection Has Double Precision Floating Point
183
184The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model
185has support for double precision floating point numbers.  This is
186important because the floating point registers need only be four bytes
187wide (not eight) if double precision is not supported.
188
189@subsubsection Critical Interrupts
190
191The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
192has the Critical Interrupt capability as defined by the IBM 403 models.
193
194@subsubsection Use Multiword Load/Store Instructions
195
196The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and
197store instructions should be used to perform context switch operations.
198The relative efficiency of multiword load and store instructions versus
199an equivalent set of single word load and store instructions varies based
200upon the PowerPC model.
201
202@subsubsection Instruction Cache Size
203
204The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
205
206@subsubsection Data Cache Size
207
208The macro PPC_D_CACHE is set to the size in bytes of the data cache.
209
210@subsubsection Debug Model
211
212The macro PPC_DEBUG_MODEL is set to indicate the debug support features
213present in this CPU model.  The following debug support feature sets
214are currently supported:
215
216@table @b
217
218@item @code{PPC_DEBUG_MODEL_STANDARD}
219indicates that the single-step trace enable (SE) and branch trace
220enable (BE) bits in the MSR are supported by this CPU model.
221
222@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
223indicates that only the single-step trace enable (SE) bit in the MSR
224is supported by this CPU model.
225
226@item @code{PPC_DEBUG_MODEL_IBM4xx}
227indicates that the debug exception enable (DE) bit in the MSR is supported
228by this CPU model.  At this time, this particular debug feature set
229has only been seen in the IBM 4xx series.
230
231@end table
232
233@subsubsection Low Power Model
234
235The macro PPC_LOW_POWER_MODE is set to indicate the low power model
236supported by this CPU model.  The following low power modes are currently
237supported.
238
239@table @b
240
241@item @code{PPC_LOW_POWER_MODE_NONE}
242indicates that this CPU model has no low power mode support.
243
244@item @code{PPC_LOW_POWER_MODE_STANDARD}
245indicates that this CPU model follows the low power model defined for
246the PPC603e.
247
248@end table
249@c
250@c  COPYRIGHT (c) 1989-2007.
251@c  On-Line Applications Research Corporation (OAR).
252@c  All rights reserved.
253@c
254@c  $Id$
255@c
256
257@section Calling Conventions
258
259
260Each high-level language compiler generates
261subroutine entry and exit code based upon a set of rules known
262as the compiler's calling convention.   These rules address the
263following issues:
264
265@itemize @bullet
266@item register preservation and usage
267
268@item parameter passing
269
270@item call and return mechanism
271@end itemize
272
273A compiler's calling convention is of importance when
274interfacing to subroutines written in another language either
275assembly or high-level.  Even when the high-level language and
276target processor are the same, different compilers may use
277different calling conventions.  As a result, calling conventions
278are both processor and compiler dependent.
279
280RTEMS supports the Embedded Application Binary Interface (EABI)
281calling convention.  Documentation for EABI is available by sending
282a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
283
284@subsection Programming Model
285
286This section discusses the programming model for the
287PowerPC architecture.
288
289@subsubsection Non-Floating Point Registers
290
291The PowerPC architecture defines thirty-two non-floating point registers
292directly visible to the programmer.  In thirty-two bit implementations, each
293register is thirty-two bits wide.  In sixty-four bit implementations, each
294register is sixty-four bits wide.
295
296These registers are referred to as @code{gpr0} to @code{gpr31}.
297
298Some of the registers serve defined roles in the EABI programming model. 
299The following table describes the role of each of these registers:
300
301@ifset use-ascii
302@example
303@group
304     +---------------+----------------+------------------------------+
305     | Register Name | Alternate Name |         Description          |
306     +---------------+----------------+------------------------------+
307     |      r1       |      sp        |         stack pointer        |
308     +---------------+----------------+------------------------------+
309     |               |                |  global pointer to the Small |
310     |      r2       |      na        |     Constant Area (SDA2)     |
311     +---------------+----------------+------------------------------+
312     |    r3 - r12   |      na        | parameter and result passing |
313     +---------------+----------------+------------------------------+
314     |               |                |  global pointer to the Small |
315     |      r13      |      na        |         Data Area (SDA)      |
316     +---------------+----------------+------------------------------+
317@end group
318@end example
319@end ifset
320
321@ifset use-tex
322@sp 1
323@tex
324\centerline{\vbox{\offinterlineskip\halign{
325\vrule\strut#&
326\hbox to 1.75in{\enskip\hfil#\hfil}&
327\vrule#&
328\hbox to 1.75in{\enskip\hfil#\hfil}&
329\vrule#&
330\hbox to 2.50in{\enskip\hfil#\hfil}&
331\vrule#\cr
332\noalign{\hrule}
333&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
334&r1&&sp&&stack pointer&\cr\noalign{\hrule}
335&r2&&NA&&global pointer to the Small&\cr
336&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
337&r3 - r12&&NA&&parameter and result passing&\cr\noalign{\hrule}
338&r13&&NA&&global pointer to the Small&\cr
339&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
340}}\hfil}
341@end tex
342@end ifset
343 
344@ifset use-html
345@html
346<CENTER>
347  <TABLE COLS=3 WIDTH="80%" BORDER=2>
348<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
349    <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
350    <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
351<TR><TD ALIGN=center>r1</TD>
352    <TD ALIGN=center>sp</TD>
353    <TD ALIGN=center>stack pointer</TD></TR>
354<TR><TD ALIGN=center>r2</TD>
355    <TD ALIGN=center>na</TD>
356    <TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
357<TR><TD ALIGN=center>r3 - r12</TD>
358    <TD ALIGN=center>NA</TD>
359    <TD ALIGN=center>parameter and result passing</TD></TR>
360<TR><TD ALIGN=center>r13</TD>
361    <TD ALIGN=center>NA</TD>
362    <TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
363  </TABLE>
364</CENTER>
365@end html
366@end ifset
367
368
369@subsubsection Floating Point Registers
370
371The PowerPC architecture includes thirty-two, sixty-four bit
372floating point registers.  All PowerPC floating point instructions
373interpret these registers as 32 double precision floating point registers,
374regardless of whether the processor has 64-bit or 32-bit implementation.
375
376The floating point status and control register (fpscr) records exceptions
377and the type of result generated by floating-point operations.
378Additionally, it controls the rounding mode of operations and allows the
379reporting of floating exceptions to be enabled or disabled.
380
381@subsubsection Special Registers
382
383The PowerPC architecture includes a number of special registers
384which are critical to the programming model:
385
386@table @b
387
388@item Machine State Register
389
390The MSR contains the processor mode, power management mode, endian mode,
391exception information, privilege level, floating point available and
392floating point excepiton mode, address translation information and
393the exception prefix.
394
395@item Link Register
396
397The LR contains the return address after a function call.  This register
398must be saved before a subsequent subroutine call can be made.  The
399use of this register is discussed further in the @b{Call and Return
400Mechanism} section below.
401
402@item Count Register
403
404The CTR contains the iteration variable for some loops.  It may also be used
405for indirect function calls and jumps.
406
407@end table
408
409@subsection Call and Return Mechanism
410
411The PowerPC architecture supports a simple yet effective call
412and return mechanism.  A subroutine is invoked
413via the "branch and link" (@code{bl}) and
414"brank and link absolute" (@code{bla})
415instructions.  This instructions place the return address
416in the Link Register (LR).  The callee returns to the caller by
417executing a "branch unconditional to the link register" (@code{blr})
418instruction.  Thus the callee returns to the caller via a jump
419to the return address which is stored in the LR.
420
421The previous contents of the LR are not automatically saved
422by either the @code{bl} or @code{bla}.  It is the responsibility
423of the callee to save the contents of the LR before invoking
424another subroutine.  If the callee invokes another subroutine,
425it must restore the LR before executing the @code{blr} instruction
426to return to the caller.
427
428It is important to note that the PowerPC subroutine
429call and return mechanism does not automatically save and
430restore any registers.
431
432The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
433"move from special register" (@code{mfspr}) and
434"move to special register" (@code{mtspr}) instructions.
435
436@subsection Calling Mechanism
437
438All RTEMS directives are invoked using the regular
439PowerPC EABI calling convention via the @code{bl} or
440@code{bla} instructions.
441
442@subsection Register Usage
443
444As discussed above, the call instruction does not
445automatically save any registers.  It is the responsibility
446of the callee to save and restore any registers which must be preserved
447across subroutine calls.  The callee is responsible for saving
448callee-preserved registers to the program stack and restoring them
449before returning to the caller.
450
451@subsection Parameter Passing
452
453RTEMS assumes that arguments are placed in the
454general purpose registers with the first argument in
455register 3 (@code{r3}), the second argument in general purpose
456register 4 (@code{r4}), and so forth until the seventh
457argument is in general purpose register 10 (@code{r10}). 
458If there are more than seven arguments, then subsequent arguments
459are placed on the program stack.  The following pseudo-code
460illustrates the typical sequence used to call a RTEMS directive
461with three (3) arguments:
462
463@example
464load third argument into r5
465load second argument into r4
466load first argument into r3
467invoke directive
468@end example
469
470@subsection User-Provided Routines
471
472All user-provided routines invoked by RTEMS, such as
473user extensions, device drivers, and MPCI routines, must also
474adhere to these same calling conventions.
475
476
477@c
478@c  COPYRIGHT (c) 1989-2007.
479@c  On-Line Applications Research Corporation (OAR).
480@c  All rights reserved.
481@c
482@c  $Id$
483@c
484
485@section Memory Model
486
487
488A processor may support any combination of memory
489models ranging from pure physical addressing to complex demand
490paged virtual memory systems.  RTEMS supports a flat memory
491model which ranges contiguously over the processor's allowable
492address space.  RTEMS does not support segmentation or virtual
493memory of any kind.  The appropriate memory model for RTEMS
494provided by the targeted processor and related characteristics
495of that model are described in this chapter.
496
497@subsection Flat Memory Model
498
499The PowerPC architecture supports a variety of memory models.
500RTEMS supports the PowerPC using a flat memory model with
501paging disabled.  In this mode, the PowerPC automatically
502converts every address from a logical to a physical address
503each time it is used.  The PowerPC uses information provided
504in the Block Address Translation (BAT) to convert these addresses.
505
506Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
507The PowerPC architecture supports a flat thirty-two or sixty-four bit address
508space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
509gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF
510in sixty-four bit implementations.  Each address is represented
511by either a thirty-two bit or sixty-four bit value and is byte addressable. 
512The address may be used to reference a single byte, half-word
513(2-bytes), word (4 bytes), or in sixty-four bit implementations a
514doubleword (8 bytes).  Memory accesses within the address space are
515performed in big or little endian fashion by the PowerPC based
516upon the current setting of the Little-endian mode enable bit (LE)
517in the Machine State Register (MSR).  While the processor is in
518big endian mode, memory accesses which are not properly aligned
519generate an "alignment exception" (vector offset 0x00600).  In
520little endian mode, the PowerPC architecture does not require
521the processor to generate alignment exceptions.
522
523The following table lists the alignment requirements for a variety
524of data accesses:
525
526@ifset use-ascii
527@example
528@group
529          +--------------+-----------------------+
530          |   Data Type  | Alignment Requirement |
531          +--------------+-----------------------+
532          |     byte     |          1            |
533          |   half-word  |          2            |
534          |     word     |          4            |
535          |  doubleword  |          8            |
536          +--------------+-----------------------+
537@end group
538@end example
539@end ifset
540
541@ifset use-tex
542@sp 1
543@tex
544\centerline{\vbox{\offinterlineskip\halign{
545\vrule\strut#&
546\hbox to 1.75in{\enskip\hfil#\hfil}&
547\vrule#&
548\hbox to 1.75in{\enskip\hfil#\hfil}&
549\vrule#\cr
550\noalign{\hrule}
551&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule}
552&byte&&1&\cr\noalign{\hrule}
553&half-word&&2&\cr\noalign{\hrule}
554&word&&4&\cr\noalign{\hrule}
555&doubleword&&8&\cr\noalign{\hrule}
556}}\hfil}
557@end tex
558@end ifset
559 
560@ifset use-html
561@html
562<CENTER>
563  <TABLE COLS=2 WIDTH="60%" BORDER=2>
564<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD>
565    <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR>
566<TR><TD ALIGN=center>byte</TD>
567    <TD ALIGN=center>1</TD></TR>
568<TR><TD ALIGN=center>half-word</TD>
569    <TD ALIGN=center>2</TD></TR>
570<TR><TD ALIGN=center>word</TD>
571    <TD ALIGN=center>4</TD></TR>
572<TR><TD ALIGN=center>doubleword</TD>
573    <TD ALIGN=center>8</TD></TR>
574  </TABLE>
575</CENTER>
576@end html
577@end ifset
578
579Doubleword load and store operations are only available in
580PowerPC CPU models which are sixty-four bit implementations.
581
582RTEMS does not directly support any PowerPC Memory Management
583Units, therefore, virtual memory or segmentation systems
584involving the PowerPC  are not supported.
585
586@c
587@c  COPYRIGHT (c) 1989-2007.
588@c  On-Line Applications Research Corporation (OAR).
589@c  All rights reserved.
590@c
591@c  $Id$
592@c
593
594@section Interrupt Processing
595
596
597Different types of processors respond to the
598occurrence of an interrupt in its own unique fashion. In
599addition, each processor type provides a control mechanism to
600allow for the proper handling of an interrupt.  The processor
601dependent response to the interrupt modifies the current
602execution state and results in a change in the execution stream.
603Most processors require that an interrupt handler utilize some
604special control mechanisms to return to the normal processing
605stream.  Although RTEMS hides many of the processor dependent
606details of interrupt processing, it is important to understand
607how the RTEMS interrupt manager is mapped onto the processor's
608unique architecture. Discussed in this chapter are the PowerPC's
609interrupt response and control mechanisms as they pertain to
610RTEMS.
611
612RTEMS and associated documentation uses the terms
613interrupt and vector.  In the PowerPC architecture, these terms
614correspond to exception and exception handler, respectively.  The terms will
615be used interchangeably in this manual.
616
617@subsection Synchronous Versus Asynchronous Exceptions
618
619In the PowerPC architecture exceptions can be either precise or
620imprecise and either synchronous or asynchronous.  Asynchronous
621exceptions occur when an external event interrupts the processor.
622Synchronous exceptions are caused by the actions of an
623instruction. During an exception SRR0 is used to calculate where
624instruction processing should resume.  All instructions prior to
625the resume instruction will have completed execution.  SRR1 is used to
626store the machine status.
627
628There are two asynchronous nonmaskable, highest-priority exceptions
629system reset and machine check.  There are two asynchrononous maskable
630low-priority exceptions external interrupt and decrementer.  Nonmaskable
631execptions are never delayed, therefore if two nonmaskable, asynchronous
632exceptions occur in immediate succession, the state information saved by
633the first exception may be overwritten when the subsequent exception occurs.
634
635The PowerPC arcitecure defines one imprecise exception, the imprecise
636floating point enabled exception.  All other synchronous exceptions are
637precise.  The synchronization occuring during asynchronous precise
638exceptions conforms to the requirements for context synchronization.
639
640@subsection Vectoring of Interrupt Handler
641
642Upon determining that an exception can be taken the PowerPC automatically
643performs the following actions:
644
645@itemize @bullet
646@item an instruction address is loaded into SRR0
647
648@item bits 33-36 and 42-47 of SRR1 are loaded with information
649specific to the exception.
650
651@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
652bits from the MSR.
653
654@item the MSR is set based upon the exception type.
655
656@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.
657
658@end itemize
659
660If the interrupt handler was installed as an RTEMS
661interrupt handler, then upon receipt of the interrupt, the
662processor passes control to the RTEMS interrupt handler which
663performs the following actions:
664
665@itemize @bullet
666@item saves the state of the interrupted task on it's stack,
667
668@item saves all registers which are not normally preserved
669by the calling sequence so the user's interrupt service
670routine can be written in a high-level language.
671
672@item if this is the outermost (i.e. non-nested) interrupt,
673then the RTEMS interrupt handler switches from the current stack
674to the interrupt stack,
675
676@item enables exceptions,
677
678@item invokes the vectors to a user interrupt service routine (ISR).
679@end itemize
680
681Asynchronous interrupts are ignored while exceptions are
682disabled.  Synchronous interrupts which occur while are
683disabled result in the CPU being forced into an error mode.
684
685A nested interrupt is processed similarly with the
686exception that the current stack need not be switched to the
687interrupt stack.
688
689@subsection Interrupt Levels
690
691The PowerPC architecture supports only a single external
692asynchronous interrupt source.  This interrupt source
693may be enabled and disabled via the External Interrupt Enable (EE)
694bit in the Machine State Register (MSR).  Thus only two level (enabled
695and disabled) of external device interrupt priorities are
696directly supported by the PowerPC architecture. 
697
698Some PowerPC implementations include a Critical Interrupt capability
699which is often used to receive interrupts from high priority external
700devices.
701
702The RTEMS interrupt level mapping scheme for the PowerPC is not
703a numeric level as on most RTEMS ports.  It is a bit mapping in
704which the least three significiant bits of the interrupt level
705are mapped directly to the enabling of specific interrupt
706sources as follows:
707
708@table @b
709
710@item Critical Interrupt
711Setting bit 0 (the least significant bit) of the interrupt level
712enables the Critical Interrupt source, if it is available on this
713CPU model.
714
715@item Machine Check
716Setting bit 1 of the interrupt level enables Machine Check execptions.
717
718@item External Interrupt
719Setting bit 2 of the interrupt level enables External Interrupt execptions.
720
721@end table
722
723All other bits in the RTEMS task interrupt level are ignored.
724
725@subsection Disabling of Interrupts by RTEMS
726
727During the execution of directive calls, critical
728sections of code may be executed.  When these sections are
729encountered, RTEMS disables Critical Interrupts, External Interrupts
730and Machine Checks before the execution of this section and restores
731them to the previous level upon completion of the section.  RTEMS has been
732optimized to insure that interrupts are disabled for less than
733RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a
734RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e with zero
735wait states.  These numbers will vary based the number of wait
736states and processor speed present on the target board.
737[NOTE:  The maximum period with interrupts disabled is hand calculated.  This
738calculation was last performed for Release
739RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
740
741If a PowerPC implementation provides non-maskable interrupts (NMI)
742which cannot be disabled, ISRs which process these interrupts
743MUST NEVER issue RTEMS system calls.  If a directive is invoked,
744unpredictable results may occur due to the inability of RTEMS
745to protect its critical sections.  However, ISRs that make no
746system calls may safely execute as non-maskable interrupts.
747
748@subsection Interrupt Stack
749
750The PowerPC architecture does not provide for a
751dedicated interrupt stack.  Thus by default, exception handlers would
752execute on the stack of the RTEMS task which they interrupted.
753This artificially inflates the stack requirements for each task
754since EVERY task stack would have to include enough space to
755account for the worst case interrupt stack requirements in
756addition to it's own worst case usage.  RTEMS addresses this
757problem on the PowerPC by providing a dedicated interrupt stack
758managed by software.
759
760During system initialization, RTEMS allocates the
761interrupt stack from the Workspace Area.  The amount of memory
762allocated for the interrupt stack is determined by the
763interrupt_stack_size field in the CPU Configuration Table.  As
764part of processing a non-nested interrupt, RTEMS will switch to
765the interrupt stack before invoking the installed handler.
766
767
768
769@c
770@c  COPYRIGHT (c) 1989-2007.
771@c  On-Line Applications Research Corporation (OAR).
772@c  All rights reserved.
773@c
774@c  $Id$
775@c
776
777@section Default Fatal Error Processing
778
779
780Upon detection of a fatal error by either the
781application or RTEMS the fatal error manager is invoked.  The
782fatal error manager will invoke the user-supplied fatal error
783handlers.  If no user-supplied handlers are configured,  the
784RTEMS provided default fatal error handler is invoked.  If the
785user-supplied fatal error handlers return to the executive the
786default fatal error handler is then invoked.  This chapter
787describes the precise operations of the default fatal error
788handler.
789
790@subsection Default Fatal Error Handler Operations
791
792The default fatal error handler which is invoked by
793the @code{rtems_fatal_error_occurred} directive when there is no user handler
794configured or the user handler returns control to RTEMS.  The
795default fatal error handler performs the following actions:
796
797@itemize @bullet
798
799@item places the error code in r3, and
800
801@item executes a trap instruction which results in a Program Exception.
802
803@end itemize
804
805If the Program Exception returns, then the following actions are performed:
806
807@itemize @bullet
808
809@item disables all processor exceptions by loading a 0 into the MSR, and
810
811@item goes into an infinite loop to simulate a halt processor instruction.
812
813@end itemize
814
815@c
816@c  COPYRIGHT (c) 1989-2007.
817@c  On-Line Applications Research Corporation (OAR).
818@c  All rights reserved.
819@c
820@c  $Id$
821@c
822
823@section Board Support Packages
824
825
826An RTEMS Board Support Package (BSP) must be designed
827to support a particular processor and target board combination.
828This chapter presents a discussion of PowerPC specific BSP issues.
829For more information on developing a BSP, refer to the chapter
830titled Board Support Packages in the RTEMS
831Applications User's Guide.
832
833@subsection System Reset
834
835An RTEMS based application is initiated or
836re-initiated when the PowerPC processor is reset.  The PowerPC
837architecture defines a Reset Exception, but leaves the
838details of the CPU state as implementation specific.  Please
839refer to the User's Manual for the CPU model in question.
840
841In general, at power-up the PowerPC begin execution at address
8420xFFF00100 in supervisor mode with all exceptions disabled.  For
843soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
844depending upon the setting of the Exception Prefix bit in the MSR.
845If during a soft reset, a Machine Check Exception occurs, then the
846CPU may execute a hard reset.
847
848@subsection Processor Initialization
849
850It is the responsibility of the application's
851initialization code to initialize the CPU and board
852to a quiescent state before invoking the @code{rtems_initialize_executive}
853directive.  It is recommended that the BSP utilize the @code{predriver_hook}
854to install default handlers for all exceptions.  These default handlers
855may be overwritten as various device drivers and subsystems install
856their own exception handlers.  Upon completion of RTEMS executive
857initialization, all interrupts are enabled.
858
859If this PowerPC implementation supports on-chip caching
860and this is to be utilized, then it should be enabled during the
861reset application initialization code.  On-chip caching has been
862observed to prevent some emulators from working properly, so it
863may be necessary to run with caching disabled to use these emulators.
864
865In addition to the requirements described in the
866@b{Board Support Packages} chapter of the RTEMS C
867Applications User's Manual for the reset code
868which is executed before the call to @code{rtems_initialize_executive},
869the PowrePC version has the following specific requirements:
870
871@itemize @bullet
872@item Must leave the PR bit of the Machine State Register (MSR) set
873to 0 so the PowerPC remains in the supervisor state.
874
875@item Must set stack pointer (sp or r1) such that a minimum stack
876size of MINIMUM_STACK_SIZE bytes is provided for the
877@code{rtems_initialize_executive} directive.
878
879@item Must disable all external interrupts (i.e. clear the EI (EE)
880bit of the machine state register).
881
882@item Must enable traps so window overflow and underflow
883conditions can be properly handled.
884
885@item Must initialize the PowerPC's initial Exception Table with default
886handlers.
887
888@end itemize
889
890@c
891@c  COPYRIGHT (c) 1989-2007.
892@c  On-Line Applications Research Corporation (OAR).
893@c  All rights reserved.
894@c
895@c  $Id$
896@c
897
898@section Processor Dependent Information Table
899
900
901Any highly processor dependent information required
902to describe a processor to RTEMS is provided in the CPU
903Dependent Information Table.  This table is not required for all
904processors supported by RTEMS.  This chapter describes the
905contents, if any, for a particular processor type.
906
907@subsection CPU Dependent Information Table
908
909The PowerPC version of the RTEMS CPU Dependent
910Information Table is given by the C structure definition is
911shown below:
912
913@example
914typedef struct @{
915  void       (*pretasking_hook)( void );
916  void       (*predriver_hook)( void );
917  void       (*postdriver_hook)( void );
918  void       (*idle_task)( void );
919  boolean      do_zero_of_workspace;
920  unsigned32   idle_task_stack_size;
921  unsigned32   interrupt_stack_size;
922  unsigned32   extra_mpci_receive_server_stack;
923  void *     (*stack_allocate_hook)( unsigned32 );
924  void       (*stack_free_hook)( void* );
925  /* end of fields required on all CPUs */
926@};
927@end example
928
929@table @code
930@item pretasking_hook
931is the address of the user provided routine which is invoked
932once RTEMS APIs are initialized.  This routine will be invoked
933before any system tasks are created.  Interrupts are disabled.
934This field may be NULL to indicate that the hook is not utilized.
935
936@item predriver_hook
937is the address of the user provided
938routine that is invoked immediately before the
939the device drivers and MPCI are initialized. RTEMS
940initialization is complete but interrupts and tasking are disabled.
941This field may be NULL to indicate that the hook is not utilized.
942
943@item postdriver_hook
944is the address of the user provided
945routine that is invoked immediately after the
946the device drivers and MPCI are initialized. RTEMS
947initialization is complete but interrupts and tasking are disabled.
948This field may be NULL to indicate that the hook is not utilized.
949
950@item idle_task
951is the address of the optional user
952provided routine which is used as the system's IDLE task.  If
953this field is not NULL, then the RTEMS default IDLE task is not
954used.  This field may be NULL to indicate that the default IDLE
955is to be used.
956
957@item do_zero_of_workspace
958indicates whether RTEMS should
959zero the Workspace as part of its initialization.  If set to
960TRUE, the Workspace is zeroed.  Otherwise, it is not.
961
962@item idle_task_stack_size
963is the size of the RTEMS idle task stack in bytes. 
964If this number is less than MINIMUM_STACK_SIZE, then the
965idle task's stack will be MINIMUM_STACK_SIZE in byte.
966
967@item interrupt_stack_size
968is the size of the RTEMS allocated interrupt stack in bytes.
969This value must be at least as large as MINIMUM_STACK_SIZE.
970
971@item extra_mpci_receive_server_stack
972is the extra stack space allocated for the RTEMS MPCI receive server task
973in bytes.  The MPCI receive server may invoke nearly all directives and
974may require extra stack space on some targets.
975
976@item stack_allocate_hook
977is the address of the optional user provided routine which allocates
978memory for task stacks.  If this hook is not NULL, then a stack_free_hook
979must be provided as well.
980
981@item stack_free_hook
982is the address of the optional user provided routine which frees
983memory for task stacks.  If this hook is not NULL, then a stack_allocate_hook
984must be provided as well.
985
986@end table
987
Note: See TracBrowser for help on using the repository browser.