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 | |
---|
13 | The Real Time Executive for Multiprocessor Systems |
---|
14 | (RTEMS) is designed to be portable across multiple processor |
---|
15 | architectures. However, the nature of real-time systems makes |
---|
16 | it essential that the application designer understand certain |
---|
17 | processor dependent implementation details. These processor |
---|
18 | dependencies include calling convention, board support package |
---|
19 | issues, interrupt processing, exact RTEMS memory requirements, |
---|
20 | performance data, header files, and the assembly language |
---|
21 | interface to the executive. |
---|
22 | |
---|
23 | This document discusses the PowerPC architecture |
---|
24 | dependencies in this port of RTEMS. |
---|
25 | |
---|
26 | It is highly recommended that the PowerPC RTEMS |
---|
27 | application developer obtain and become familiar with the |
---|
28 | documentation for the processor being used as well as the |
---|
29 | specification for the revision of the PowerPC architecture which |
---|
30 | corresponds to that processor. |
---|
31 | |
---|
32 | @subheading PowerPC Architecture Documents |
---|
33 | |
---|
34 | For information on the PowerPC architecture, refer to |
---|
35 | the 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 |
---|
45 | Unit 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 | |
---|
67 | Motorola maintains an on-line electronic library for the PowerPC |
---|
68 | at the following URL: |
---|
69 | |
---|
70 | @itemize @code{ } |
---|
71 | @item @cite{http://www.mot.com/powerpc/library/library.html} |
---|
72 | @end itemize |
---|
73 | |
---|
74 | This site has a a wealth of information and examples. Many of the |
---|
75 | manuals are available from that site in electronic format. |
---|
76 | |
---|
77 | @subheading PowerPC Processor Simulator Information |
---|
78 | |
---|
79 | PSIM is a program which emulates the Instruction Set Architecture |
---|
80 | of the PowerPC microprocessor family. It is reely available in source |
---|
81 | code form under the terms of the GNU General Public License (version |
---|
82 | 2 or later). PSIM can be integrated with the GNU Debugger (gdb) to |
---|
83 | execute and debug PowerPC executables on non-PowerPC hosts. PSIM |
---|
84 | supports the addition of user provided device models which can be |
---|
85 | used to allow one to develop and debug embedded applications using |
---|
86 | the simulator. |
---|
87 | |
---|
88 | The latest version of PSIM is made available to the public via |
---|
89 | anonymous ftp at ftp://ftp.ci.com.au/pub/psim or |
---|
90 | ftp://cambridge.cygnus.com/pub/psim. There is also a mailing list |
---|
91 | at 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 | |
---|
105 | Microprocessors are generally classified into |
---|
106 | families with a variety of CPU models or implementations within |
---|
107 | that family. Within a processor family, there is a high level |
---|
108 | of binary compatibility. This family may be based on either an |
---|
109 | architectural specification or on maintaining compatibility with |
---|
110 | a popular processor. Recent microprocessor families such as the |
---|
111 | SPARC, and PowerPC are based on an architectural specification |
---|
112 | which is independent or any particular CPU model or |
---|
113 | implementation. Older families such as the M68xxx and the iX86 |
---|
114 | evolved as the manufacturer strived to produce higher |
---|
115 | performance processor models which maintained binary |
---|
116 | compatibility with older models. |
---|
117 | |
---|
118 | RTEMS takes advantage of the similarity of the |
---|
119 | various models within a CPU family. Although the models do vary |
---|
120 | in significant ways, the high level of compatibility makes it |
---|
121 | possible to share the bulk of the CPU dependent executive code |
---|
122 | across the entire family. |
---|
123 | |
---|
124 | @subsection CPU Model Feature Flags |
---|
125 | |
---|
126 | Each processor family supported by RTEMS has a |
---|
127 | list of features which vary between CPU models |
---|
128 | within a family. For example, the most common model dependent |
---|
129 | feature regardless of CPU family is the presence or absence of a |
---|
130 | floating point unit or coprocessor. When defining the list of |
---|
131 | features present on a particular CPU model, one simply notes |
---|
132 | that floating point hardware is or is not present and defines a |
---|
133 | single constant appropriately. Conditional compilation is |
---|
134 | utilized to include the appropriate source code for this CPU |
---|
135 | model's feature set. It is important to note that this means |
---|
136 | that RTEMS is thus compiled using the appropriate feature set |
---|
137 | and compilation flags optimal for this CPU model used. The |
---|
138 | alternative would be to generate a binary which would execute on |
---|
139 | all family members using only the features which were always |
---|
140 | present. |
---|
141 | |
---|
142 | This section presents the set of features which vary |
---|
143 | across PowerPC implementations and are of importance to RTEMS. |
---|
144 | The set of CPU model feature macros are defined in the file |
---|
145 | cpukit/score/cpu/ppc/ppc.h based upon the particular CPU |
---|
146 | model defined on the compilation command line. |
---|
147 | |
---|
148 | @subsubsection CPU Model Name |
---|
149 | |
---|
150 | The macro CPU_MODEL_NAME is a string which designates |
---|
151 | the name of this CPU model. For example, for the PowerPC 603e |
---|
152 | model, this macro is set to the string "PowerPC 603e". |
---|
153 | |
---|
154 | @subsubsection Floating Point Unit |
---|
155 | |
---|
156 | The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model |
---|
157 | has a hardware floating point unit and 0 otherwise. |
---|
158 | |
---|
159 | @subsubsection Alignment |
---|
160 | |
---|
161 | The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment |
---|
162 | requirement for data types on a byte boundary. This value is used |
---|
163 | to derive the alignment restrictions for memory allocated from |
---|
164 | regions and partitions. |
---|
165 | |
---|
166 | @subsubsection Cache Alignment |
---|
167 | |
---|
168 | The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is |
---|
169 | used to align the entry point of critical routines so that as much code |
---|
170 | as possible can be retrieved with the initial read into cache. This |
---|
171 | is done for the interrupt handler as well as the context switch routines. |
---|
172 | |
---|
173 | In addition, the "shortcut" data structure used by the PowerPC implementation |
---|
174 | to ease access to data elements frequently accessed by RTEMS routines |
---|
175 | implemented in assembly language is aligned using this value. |
---|
176 | |
---|
177 | @subsubsection Maximum Interrupts |
---|
178 | |
---|
179 | The macro PPC_INTERRUPT_MAX is set to the number of exception sources |
---|
180 | supported by this PowerPC model. |
---|
181 | |
---|
182 | @subsubsection Has Double Precision Floating Point |
---|
183 | |
---|
184 | The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model |
---|
185 | has support for double precision floating point numbers. This is |
---|
186 | important because the floating point registers need only be four bytes |
---|
187 | wide (not eight) if double precision is not supported. |
---|
188 | |
---|
189 | @subsubsection Critical Interrupts |
---|
190 | |
---|
191 | The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model |
---|
192 | has the Critical Interrupt capability as defined by the IBM 403 models. |
---|
193 | |
---|
194 | @subsubsection Use Multiword Load/Store Instructions |
---|
195 | |
---|
196 | The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and |
---|
197 | store instructions should be used to perform context switch operations. |
---|
198 | The relative efficiency of multiword load and store instructions versus |
---|
199 | an equivalent set of single word load and store instructions varies based |
---|
200 | upon the PowerPC model. |
---|
201 | |
---|
202 | @subsubsection Instruction Cache Size |
---|
203 | |
---|
204 | The macro PPC_I_CACHE is set to the size in bytes of the instruction cache. |
---|
205 | |
---|
206 | @subsubsection Data Cache Size |
---|
207 | |
---|
208 | The macro PPC_D_CACHE is set to the size in bytes of the data cache. |
---|
209 | |
---|
210 | @subsubsection Debug Model |
---|
211 | |
---|
212 | The macro PPC_DEBUG_MODEL is set to indicate the debug support features |
---|
213 | present in this CPU model. The following debug support feature sets |
---|
214 | are currently supported: |
---|
215 | |
---|
216 | @table @b |
---|
217 | |
---|
218 | @item @code{PPC_DEBUG_MODEL_STANDARD} |
---|
219 | indicates that the single-step trace enable (SE) and branch trace |
---|
220 | enable (BE) bits in the MSR are supported by this CPU model. |
---|
221 | |
---|
222 | @item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY} |
---|
223 | indicates that only the single-step trace enable (SE) bit in the MSR |
---|
224 | is supported by this CPU model. |
---|
225 | |
---|
226 | @item @code{PPC_DEBUG_MODEL_IBM4xx} |
---|
227 | indicates that the debug exception enable (DE) bit in the MSR is supported |
---|
228 | by this CPU model. At this time, this particular debug feature set |
---|
229 | has only been seen in the IBM 4xx series. |
---|
230 | |
---|
231 | @end table |
---|
232 | |
---|
233 | @subsubsection Low Power Model |
---|
234 | |
---|
235 | The macro PPC_LOW_POWER_MODE is set to indicate the low power model |
---|
236 | supported by this CPU model. The following low power modes are currently |
---|
237 | supported. |
---|
238 | |
---|
239 | @table @b |
---|
240 | |
---|
241 | @item @code{PPC_LOW_POWER_MODE_NONE} |
---|
242 | indicates that this CPU model has no low power mode support. |
---|
243 | |
---|
244 | @item @code{PPC_LOW_POWER_MODE_STANDARD} |
---|
245 | indicates that this CPU model follows the low power model defined for |
---|
246 | the 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 | |
---|
260 | Each high-level language compiler generates |
---|
261 | subroutine entry and exit code based upon a set of rules known |
---|
262 | as the compiler's calling convention. These rules address the |
---|
263 | following 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 | |
---|
273 | A compiler's calling convention is of importance when |
---|
274 | interfacing to subroutines written in another language either |
---|
275 | assembly or high-level. Even when the high-level language and |
---|
276 | target processor are the same, different compilers may use |
---|
277 | different calling conventions. As a result, calling conventions |
---|
278 | are both processor and compiler dependent. |
---|
279 | |
---|
280 | RTEMS supports the Embedded Application Binary Interface (EABI) |
---|
281 | calling convention. Documentation for EABI is available by sending |
---|
282 | a message with a subject line of "EABI" to eabi@@goth.sis.mot.com. |
---|
283 | |
---|
284 | @subsection Programming Model |
---|
285 | |
---|
286 | This section discusses the programming model for the |
---|
287 | PowerPC architecture. |
---|
288 | |
---|
289 | @subsubsection Non-Floating Point Registers |
---|
290 | |
---|
291 | The PowerPC architecture defines thirty-two non-floating point registers |
---|
292 | directly visible to the programmer. In thirty-two bit implementations, each |
---|
293 | register is thirty-two bits wide. In sixty-four bit implementations, each |
---|
294 | register is sixty-four bits wide. |
---|
295 | |
---|
296 | These registers are referred to as @code{gpr0} to @code{gpr31}. |
---|
297 | |
---|
298 | Some of the registers serve defined roles in the EABI programming model. |
---|
299 | The 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&¶meter 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 | |
---|
371 | The PowerPC architecture includes thirty-two, sixty-four bit |
---|
372 | floating point registers. All PowerPC floating point instructions |
---|
373 | interpret these registers as 32 double precision floating point registers, |
---|
374 | regardless of whether the processor has 64-bit or 32-bit implementation. |
---|
375 | |
---|
376 | The floating point status and control register (fpscr) records exceptions |
---|
377 | and the type of result generated by floating-point operations. |
---|
378 | Additionally, it controls the rounding mode of operations and allows the |
---|
379 | reporting of floating exceptions to be enabled or disabled. |
---|
380 | |
---|
381 | @subsubsection Special Registers |
---|
382 | |
---|
383 | The PowerPC architecture includes a number of special registers |
---|
384 | which are critical to the programming model: |
---|
385 | |
---|
386 | @table @b |
---|
387 | |
---|
388 | @item Machine State Register |
---|
389 | |
---|
390 | The MSR contains the processor mode, power management mode, endian mode, |
---|
391 | exception information, privilege level, floating point available and |
---|
392 | floating point excepiton mode, address translation information and |
---|
393 | the exception prefix. |
---|
394 | |
---|
395 | @item Link Register |
---|
396 | |
---|
397 | The LR contains the return address after a function call. This register |
---|
398 | must be saved before a subsequent subroutine call can be made. The |
---|
399 | use of this register is discussed further in the @b{Call and Return |
---|
400 | Mechanism} section below. |
---|
401 | |
---|
402 | @item Count Register |
---|
403 | |
---|
404 | The CTR contains the iteration variable for some loops. It may also be used |
---|
405 | for indirect function calls and jumps. |
---|
406 | |
---|
407 | @end table |
---|
408 | |
---|
409 | @subsection Call and Return Mechanism |
---|
410 | |
---|
411 | The PowerPC architecture supports a simple yet effective call |
---|
412 | and return mechanism. A subroutine is invoked |
---|
413 | via the "branch and link" (@code{bl}) and |
---|
414 | "brank and link absolute" (@code{bla}) |
---|
415 | instructions. This instructions place the return address |
---|
416 | in the Link Register (LR). The callee returns to the caller by |
---|
417 | executing a "branch unconditional to the link register" (@code{blr}) |
---|
418 | instruction. Thus the callee returns to the caller via a jump |
---|
419 | to the return address which is stored in the LR. |
---|
420 | |
---|
421 | The previous contents of the LR are not automatically saved |
---|
422 | by either the @code{bl} or @code{bla}. It is the responsibility |
---|
423 | of the callee to save the contents of the LR before invoking |
---|
424 | another subroutine. If the callee invokes another subroutine, |
---|
425 | it must restore the LR before executing the @code{blr} instruction |
---|
426 | to return to the caller. |
---|
427 | |
---|
428 | It is important to note that the PowerPC subroutine |
---|
429 | call and return mechanism does not automatically save and |
---|
430 | restore any registers. |
---|
431 | |
---|
432 | The 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 | |
---|
438 | All RTEMS directives are invoked using the regular |
---|
439 | PowerPC EABI calling convention via the @code{bl} or |
---|
440 | @code{bla} instructions. |
---|
441 | |
---|
442 | @subsection Register Usage |
---|
443 | |
---|
444 | As discussed above, the call instruction does not |
---|
445 | automatically save any registers. It is the responsibility |
---|
446 | of the callee to save and restore any registers which must be preserved |
---|
447 | across subroutine calls. The callee is responsible for saving |
---|
448 | callee-preserved registers to the program stack and restoring them |
---|
449 | before returning to the caller. |
---|
450 | |
---|
451 | @subsection Parameter Passing |
---|
452 | |
---|
453 | RTEMS assumes that arguments are placed in the |
---|
454 | general purpose registers with the first argument in |
---|
455 | register 3 (@code{r3}), the second argument in general purpose |
---|
456 | register 4 (@code{r4}), and so forth until the seventh |
---|
457 | argument is in general purpose register 10 (@code{r10}). |
---|
458 | If there are more than seven arguments, then subsequent arguments |
---|
459 | are placed on the program stack. The following pseudo-code |
---|
460 | illustrates the typical sequence used to call a RTEMS directive |
---|
461 | with three (3) arguments: |
---|
462 | |
---|
463 | @example |
---|
464 | load third argument into r5 |
---|
465 | load second argument into r4 |
---|
466 | load first argument into r3 |
---|
467 | invoke directive |
---|
468 | @end example |
---|
469 | |
---|
470 | @subsection User-Provided Routines |
---|
471 | |
---|
472 | All user-provided routines invoked by RTEMS, such as |
---|
473 | user extensions, device drivers, and MPCI routines, must also |
---|
474 | adhere 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 | |
---|
488 | A processor may support any combination of memory |
---|
489 | models ranging from pure physical addressing to complex demand |
---|
490 | paged virtual memory systems. RTEMS supports a flat memory |
---|
491 | model which ranges contiguously over the processor's allowable |
---|
492 | address space. RTEMS does not support segmentation or virtual |
---|
493 | memory of any kind. The appropriate memory model for RTEMS |
---|
494 | provided by the targeted processor and related characteristics |
---|
495 | of that model are described in this chapter. |
---|
496 | |
---|
497 | @subsection Flat Memory Model |
---|
498 | |
---|
499 | The PowerPC architecture supports a variety of memory models. |
---|
500 | RTEMS supports the PowerPC using a flat memory model with |
---|
501 | paging disabled. In this mode, the PowerPC automatically |
---|
502 | converts every address from a logical to a physical address |
---|
503 | each time it is used. The PowerPC uses information provided |
---|
504 | in the Block Address Translation (BAT) to convert these addresses. |
---|
505 | |
---|
506 | Implementations of the PowerPC architecture may be thirty-two or sixty-four bit. |
---|
507 | The PowerPC architecture supports a flat thirty-two or sixty-four bit address |
---|
508 | space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 |
---|
509 | gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF |
---|
510 | in sixty-four bit implementations. Each address is represented |
---|
511 | by either a thirty-two bit or sixty-four bit value and is byte addressable. |
---|
512 | The address may be used to reference a single byte, half-word |
---|
513 | (2-bytes), word (4 bytes), or in sixty-four bit implementations a |
---|
514 | doubleword (8 bytes). Memory accesses within the address space are |
---|
515 | performed in big or little endian fashion by the PowerPC based |
---|
516 | upon the current setting of the Little-endian mode enable bit (LE) |
---|
517 | in the Machine State Register (MSR). While the processor is in |
---|
518 | big endian mode, memory accesses which are not properly aligned |
---|
519 | generate an "alignment exception" (vector offset 0x00600). In |
---|
520 | little endian mode, the PowerPC architecture does not require |
---|
521 | the processor to generate alignment exceptions. |
---|
522 | |
---|
523 | The following table lists the alignment requirements for a variety |
---|
524 | of 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 | |
---|
579 | Doubleword load and store operations are only available in |
---|
580 | PowerPC CPU models which are sixty-four bit implementations. |
---|
581 | |
---|
582 | RTEMS does not directly support any PowerPC Memory Management |
---|
583 | Units, therefore, virtual memory or segmentation systems |
---|
584 | involving 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 | |
---|
597 | Different types of processors respond to the |
---|
598 | occurrence of an interrupt in its own unique fashion. In |
---|
599 | addition, each processor type provides a control mechanism to |
---|
600 | allow for the proper handling of an interrupt. The processor |
---|
601 | dependent response to the interrupt modifies the current |
---|
602 | execution state and results in a change in the execution stream. |
---|
603 | Most processors require that an interrupt handler utilize some |
---|
604 | special control mechanisms to return to the normal processing |
---|
605 | stream. Although RTEMS hides many of the processor dependent |
---|
606 | details of interrupt processing, it is important to understand |
---|
607 | how the RTEMS interrupt manager is mapped onto the processor's |
---|
608 | unique architecture. Discussed in this chapter are the PowerPC's |
---|
609 | interrupt response and control mechanisms as they pertain to |
---|
610 | RTEMS. |
---|
611 | |
---|
612 | RTEMS and associated documentation uses the terms |
---|
613 | interrupt and vector. In the PowerPC architecture, these terms |
---|
614 | correspond to exception and exception handler, respectively. The terms will |
---|
615 | be used interchangeably in this manual. |
---|
616 | |
---|
617 | @subsection Synchronous Versus Asynchronous Exceptions |
---|
618 | |
---|
619 | In the PowerPC architecture exceptions can be either precise or |
---|
620 | imprecise and either synchronous or asynchronous. Asynchronous |
---|
621 | exceptions occur when an external event interrupts the processor. |
---|
622 | Synchronous exceptions are caused by the actions of an |
---|
623 | instruction. During an exception SRR0 is used to calculate where |
---|
624 | instruction processing should resume. All instructions prior to |
---|
625 | the resume instruction will have completed execution. SRR1 is used to |
---|
626 | store the machine status. |
---|
627 | |
---|
628 | There are two asynchronous nonmaskable, highest-priority exceptions |
---|
629 | system reset and machine check. There are two asynchrononous maskable |
---|
630 | low-priority exceptions external interrupt and decrementer. Nonmaskable |
---|
631 | execptions are never delayed, therefore if two nonmaskable, asynchronous |
---|
632 | exceptions occur in immediate succession, the state information saved by |
---|
633 | the first exception may be overwritten when the subsequent exception occurs. |
---|
634 | |
---|
635 | The PowerPC arcitecure defines one imprecise exception, the imprecise |
---|
636 | floating point enabled exception. All other synchronous exceptions are |
---|
637 | precise. The synchronization occuring during asynchronous precise |
---|
638 | exceptions conforms to the requirements for context synchronization. |
---|
639 | |
---|
640 | @subsection Vectoring of Interrupt Handler |
---|
641 | |
---|
642 | Upon determining that an exception can be taken the PowerPC automatically |
---|
643 | performs 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 |
---|
649 | specific to the exception. |
---|
650 | |
---|
651 | @item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding |
---|
652 | bits 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 | |
---|
660 | If the interrupt handler was installed as an RTEMS |
---|
661 | interrupt handler, then upon receipt of the interrupt, the |
---|
662 | processor passes control to the RTEMS interrupt handler which |
---|
663 | performs 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 |
---|
669 | by the calling sequence so the user's interrupt service |
---|
670 | routine can be written in a high-level language. |
---|
671 | |
---|
672 | @item if this is the outermost (i.e. non-nested) interrupt, |
---|
673 | then the RTEMS interrupt handler switches from the current stack |
---|
674 | to 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 | |
---|
681 | Asynchronous interrupts are ignored while exceptions are |
---|
682 | disabled. Synchronous interrupts which occur while are |
---|
683 | disabled result in the CPU being forced into an error mode. |
---|
684 | |
---|
685 | A nested interrupt is processed similarly with the |
---|
686 | exception that the current stack need not be switched to the |
---|
687 | interrupt stack. |
---|
688 | |
---|
689 | @subsection Interrupt Levels |
---|
690 | |
---|
691 | The PowerPC architecture supports only a single external |
---|
692 | asynchronous interrupt source. This interrupt source |
---|
693 | may be enabled and disabled via the External Interrupt Enable (EE) |
---|
694 | bit in the Machine State Register (MSR). Thus only two level (enabled |
---|
695 | and disabled) of external device interrupt priorities are |
---|
696 | directly supported by the PowerPC architecture. |
---|
697 | |
---|
698 | Some PowerPC implementations include a Critical Interrupt capability |
---|
699 | which is often used to receive interrupts from high priority external |
---|
700 | devices. |
---|
701 | |
---|
702 | The RTEMS interrupt level mapping scheme for the PowerPC is not |
---|
703 | a numeric level as on most RTEMS ports. It is a bit mapping in |
---|
704 | which the least three significiant bits of the interrupt level |
---|
705 | are mapped directly to the enabling of specific interrupt |
---|
706 | sources as follows: |
---|
707 | |
---|
708 | @table @b |
---|
709 | |
---|
710 | @item Critical Interrupt |
---|
711 | Setting bit 0 (the least significant bit) of the interrupt level |
---|
712 | enables the Critical Interrupt source, if it is available on this |
---|
713 | CPU model. |
---|
714 | |
---|
715 | @item Machine Check |
---|
716 | Setting bit 1 of the interrupt level enables Machine Check execptions. |
---|
717 | |
---|
718 | @item External Interrupt |
---|
719 | Setting bit 2 of the interrupt level enables External Interrupt execptions. |
---|
720 | |
---|
721 | @end table |
---|
722 | |
---|
723 | All other bits in the RTEMS task interrupt level are ignored. |
---|
724 | |
---|
725 | @subsection Disabling of Interrupts by RTEMS |
---|
726 | |
---|
727 | During the execution of directive calls, critical |
---|
728 | sections of code may be executed. When these sections are |
---|
729 | encountered, RTEMS disables Critical Interrupts, External Interrupts |
---|
730 | and Machine Checks before the execution of this section and restores |
---|
731 | them to the previous level upon completion of the section. RTEMS has been |
---|
732 | optimized to insure that interrupts are disabled for less than |
---|
733 | RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a |
---|
734 | RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e with zero |
---|
735 | wait states. These numbers will vary based the number of wait |
---|
736 | states and processor speed present on the target board. |
---|
737 | [NOTE: The maximum period with interrupts disabled is hand calculated. This |
---|
738 | calculation was last performed for Release |
---|
739 | RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
---|
740 | |
---|
741 | If a PowerPC implementation provides non-maskable interrupts (NMI) |
---|
742 | which cannot be disabled, ISRs which process these interrupts |
---|
743 | MUST NEVER issue RTEMS system calls. If a directive is invoked, |
---|
744 | unpredictable results may occur due to the inability of RTEMS |
---|
745 | to protect its critical sections. However, ISRs that make no |
---|
746 | system calls may safely execute as non-maskable interrupts. |
---|
747 | |
---|
748 | @subsection Interrupt Stack |
---|
749 | |
---|
750 | The PowerPC architecture does not provide for a |
---|
751 | dedicated interrupt stack. Thus by default, exception handlers would |
---|
752 | execute on the stack of the RTEMS task which they interrupted. |
---|
753 | This artificially inflates the stack requirements for each task |
---|
754 | since EVERY task stack would have to include enough space to |
---|
755 | account for the worst case interrupt stack requirements in |
---|
756 | addition to it's own worst case usage. RTEMS addresses this |
---|
757 | problem on the PowerPC by providing a dedicated interrupt stack |
---|
758 | managed by software. |
---|
759 | |
---|
760 | During system initialization, RTEMS allocates the |
---|
761 | interrupt stack from the Workspace Area. The amount of memory |
---|
762 | allocated for the interrupt stack is determined by the |
---|
763 | interrupt_stack_size field in the CPU Configuration Table. As |
---|
764 | part of processing a non-nested interrupt, RTEMS will switch to |
---|
765 | the 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 | |
---|
780 | Upon detection of a fatal error by either the |
---|
781 | application or RTEMS the fatal error manager is invoked. The |
---|
782 | fatal error manager will invoke the user-supplied fatal error |
---|
783 | handlers. If no user-supplied handlers are configured, the |
---|
784 | RTEMS provided default fatal error handler is invoked. If the |
---|
785 | user-supplied fatal error handlers return to the executive the |
---|
786 | default fatal error handler is then invoked. This chapter |
---|
787 | describes the precise operations of the default fatal error |
---|
788 | handler. |
---|
789 | |
---|
790 | @subsection Default Fatal Error Handler Operations |
---|
791 | |
---|
792 | The default fatal error handler which is invoked by |
---|
793 | the @code{rtems_fatal_error_occurred} directive when there is no user handler |
---|
794 | configured or the user handler returns control to RTEMS. The |
---|
795 | default 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 | |
---|
805 | If 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 | |
---|
826 | An RTEMS Board Support Package (BSP) must be designed |
---|
827 | to support a particular processor and target board combination. |
---|
828 | This chapter presents a discussion of PowerPC specific BSP issues. |
---|
829 | For more information on developing a BSP, refer to the chapter |
---|
830 | titled Board Support Packages in the RTEMS |
---|
831 | Applications User's Guide. |
---|
832 | |
---|
833 | @subsection System Reset |
---|
834 | |
---|
835 | An RTEMS based application is initiated or |
---|
836 | re-initiated when the PowerPC processor is reset. The PowerPC |
---|
837 | architecture defines a Reset Exception, but leaves the |
---|
838 | details of the CPU state as implementation specific. Please |
---|
839 | refer to the User's Manual for the CPU model in question. |
---|
840 | |
---|
841 | In general, at power-up the PowerPC begin execution at address |
---|
842 | 0xFFF00100 in supervisor mode with all exceptions disabled. For |
---|
843 | soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100 |
---|
844 | depending upon the setting of the Exception Prefix bit in the MSR. |
---|
845 | If during a soft reset, a Machine Check Exception occurs, then the |
---|
846 | CPU may execute a hard reset. |
---|
847 | |
---|
848 | @subsection Processor Initialization |
---|
849 | |
---|
850 | It is the responsibility of the application's |
---|
851 | initialization code to initialize the CPU and board |
---|
852 | to a quiescent state before invoking the @code{rtems_initialize_executive} |
---|
853 | directive. It is recommended that the BSP utilize the @code{predriver_hook} |
---|
854 | to install default handlers for all exceptions. These default handlers |
---|
855 | may be overwritten as various device drivers and subsystems install |
---|
856 | their own exception handlers. Upon completion of RTEMS executive |
---|
857 | initialization, all interrupts are enabled. |
---|
858 | |
---|
859 | If this PowerPC implementation supports on-chip caching |
---|
860 | and this is to be utilized, then it should be enabled during the |
---|
861 | reset application initialization code. On-chip caching has been |
---|
862 | observed to prevent some emulators from working properly, so it |
---|
863 | may be necessary to run with caching disabled to use these emulators. |
---|
864 | |
---|
865 | In addition to the requirements described in the |
---|
866 | @b{Board Support Packages} chapter of the RTEMS C |
---|
867 | Applications User's Manual for the reset code |
---|
868 | which is executed before the call to @code{rtems_initialize_executive}, |
---|
869 | the 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 |
---|
873 | to 0 so the PowerPC remains in the supervisor state. |
---|
874 | |
---|
875 | @item Must set stack pointer (sp or r1) such that a minimum stack |
---|
876 | size 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) |
---|
880 | bit of the machine state register). |
---|
881 | |
---|
882 | @item Must enable traps so window overflow and underflow |
---|
883 | conditions can be properly handled. |
---|
884 | |
---|
885 | @item Must initialize the PowerPC's initial Exception Table with default |
---|
886 | handlers. |
---|
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 | |
---|
901 | Any highly processor dependent information required |
---|
902 | to describe a processor to RTEMS is provided in the CPU |
---|
903 | Dependent Information Table. This table is not required for all |
---|
904 | processors supported by RTEMS. This chapter describes the |
---|
905 | contents, if any, for a particular processor type. |
---|
906 | |
---|
907 | @subsection CPU Dependent Information Table |
---|
908 | |
---|
909 | The PowerPC version of the RTEMS CPU Dependent |
---|
910 | Information Table is given by the C structure definition is |
---|
911 | shown below: |
---|
912 | |
---|
913 | @example |
---|
914 | typedef 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 |
---|
931 | is the address of the user provided routine which is invoked |
---|
932 | once RTEMS APIs are initialized. This routine will be invoked |
---|
933 | before any system tasks are created. Interrupts are disabled. |
---|
934 | This field may be NULL to indicate that the hook is not utilized. |
---|
935 | |
---|
936 | @item predriver_hook |
---|
937 | is the address of the user provided |
---|
938 | routine that is invoked immediately before the |
---|
939 | the device drivers and MPCI are initialized. RTEMS |
---|
940 | initialization is complete but interrupts and tasking are disabled. |
---|
941 | This field may be NULL to indicate that the hook is not utilized. |
---|
942 | |
---|
943 | @item postdriver_hook |
---|
944 | is the address of the user provided |
---|
945 | routine that is invoked immediately after the |
---|
946 | the device drivers and MPCI are initialized. RTEMS |
---|
947 | initialization is complete but interrupts and tasking are disabled. |
---|
948 | This field may be NULL to indicate that the hook is not utilized. |
---|
949 | |
---|
950 | @item idle_task |
---|
951 | is the address of the optional user |
---|
952 | provided routine which is used as the system's IDLE task. If |
---|
953 | this field is not NULL, then the RTEMS default IDLE task is not |
---|
954 | used. This field may be NULL to indicate that the default IDLE |
---|
955 | is to be used. |
---|
956 | |
---|
957 | @item do_zero_of_workspace |
---|
958 | indicates whether RTEMS should |
---|
959 | zero the Workspace as part of its initialization. If set to |
---|
960 | TRUE, the Workspace is zeroed. Otherwise, it is not. |
---|
961 | |
---|
962 | @item idle_task_stack_size |
---|
963 | is the size of the RTEMS idle task stack in bytes. |
---|
964 | If this number is less than MINIMUM_STACK_SIZE, then the |
---|
965 | idle task's stack will be MINIMUM_STACK_SIZE in byte. |
---|
966 | |
---|
967 | @item interrupt_stack_size |
---|
968 | is the size of the RTEMS allocated interrupt stack in bytes. |
---|
969 | This value must be at least as large as MINIMUM_STACK_SIZE. |
---|
970 | |
---|
971 | @item extra_mpci_receive_server_stack |
---|
972 | is the extra stack space allocated for the RTEMS MPCI receive server task |
---|
973 | in bytes. The MPCI receive server may invoke nearly all directives and |
---|
974 | may require extra stack space on some targets. |
---|
975 | |
---|
976 | @item stack_allocate_hook |
---|
977 | is the address of the optional user provided routine which allocates |
---|
978 | memory for task stacks. If this hook is not NULL, then a stack_free_hook |
---|
979 | must be provided as well. |
---|
980 | |
---|
981 | @item stack_free_hook |
---|
982 | is the address of the optional user provided routine which frees |
---|
983 | memory for task stacks. If this hook is not NULL, then a stack_allocate_hook |
---|
984 | must be provided as well. |
---|
985 | |
---|
986 | @end table |
---|
987 | |
---|