1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-1999. |
---|
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 Texas Instruments C3x/C4x Specific Information |
---|
12 | |
---|
13 | The Real Time Executive for Multiprocessor Systems (RTEMS) |
---|
14 | 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 Texas Instrument C3x/C4x |
---|
24 | architecture dependencies in this port of RTEMS. The C3x/C4x |
---|
25 | family has a wide variety of CPU models within it. The following |
---|
26 | CPU model numbers could be supported by this port: |
---|
27 | |
---|
28 | @itemize |
---|
29 | @item C30 - TMSXXX |
---|
30 | @item C31 - TMSXXX |
---|
31 | @item C32 - TMSXXX |
---|
32 | @item C41 - TMSXXX |
---|
33 | @item C44 - TMSXXX |
---|
34 | @end itemize |
---|
35 | |
---|
36 | Initiially, this port does not include full support for C4x models. |
---|
37 | Primarily, the C4x specific implementations of interrupt flag and |
---|
38 | mask management routines have not been completed. |
---|
39 | |
---|
40 | It is highly recommended that the RTEMS application developer obtain |
---|
41 | and become familiar with the documentation for the processor being |
---|
42 | used as well as the documentation for the family as a whole. |
---|
43 | |
---|
44 | @subheading Architecture Documents |
---|
45 | |
---|
46 | For information on the Texas Instruments C3x/C4x architecture, |
---|
47 | refer to the following documents available from VENDOR |
---|
48 | (@file{http//www.ti.com/}): |
---|
49 | |
---|
50 | @itemize @bullet |
---|
51 | @item @cite{XXX Family Reference, Texas Instruments, PART NUMBER}. |
---|
52 | @end itemize |
---|
53 | |
---|
54 | @subheading MODEL SPECIFIC DOCUMENTS |
---|
55 | |
---|
56 | For information on specific processor models and |
---|
57 | their associated coprocessors, refer to the following documents: |
---|
58 | |
---|
59 | @itemize @bullet |
---|
60 | @item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}. |
---|
61 | @item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}. |
---|
62 | @end itemize |
---|
63 | |
---|
64 | @c |
---|
65 | @c COPYRIGHT (c) 1988-1999. |
---|
66 | @c On-Line Applications Research Corporation (OAR). |
---|
67 | @c All rights reserved. |
---|
68 | @c |
---|
69 | @c $Id$ |
---|
70 | @c |
---|
71 | |
---|
72 | @section CPU Model Dependent Features |
---|
73 | |
---|
74 | |
---|
75 | Microprocessors are generally classified into |
---|
76 | families with a variety of CPU models or implementations within |
---|
77 | that family. Within a processor family, there is a high level |
---|
78 | of binary compatibility. This family may be based on either an |
---|
79 | architectural specification or on maintaining compatibility with |
---|
80 | a popular processor. Recent microprocessor families such as the |
---|
81 | SPARC or PowerPC are based on an architectural specification |
---|
82 | which is independent or any particular CPU model or |
---|
83 | implementation. Older families such as the M68xxx and the iX86 |
---|
84 | evolved as the manufacturer strived to produce higher |
---|
85 | performance processor models which maintained binary |
---|
86 | compatibility with older models. |
---|
87 | |
---|
88 | RTEMS takes advantage of the similarity of the |
---|
89 | various models within a CPU family. Although the models do vary |
---|
90 | in significant ways, the high level of compatibility makes it |
---|
91 | possible to share the bulk of the CPU dependent executive code |
---|
92 | across the entire family. Each processor family supported by |
---|
93 | RTEMS has a list of features which vary between CPU models |
---|
94 | within a family. For example, the most common model dependent |
---|
95 | feature regardless of CPU family is the presence or absence of a |
---|
96 | floating point unit or coprocessor. When defining the list of |
---|
97 | features present on a particular CPU model, one simply notes |
---|
98 | that floating point hardware is or is not present and defines a |
---|
99 | single constant appropriately. Conditional compilation is |
---|
100 | utilized to include the appropriate source code for this CPU |
---|
101 | model's feature set. It is important to note that this means |
---|
102 | that RTEMS is thus compiled using the appropriate feature set |
---|
103 | and compilation flags optimal for this CPU model used. The |
---|
104 | alternative would be to generate a binary which would execute on |
---|
105 | all family members using only the features which were always |
---|
106 | present. |
---|
107 | |
---|
108 | This chapter presents the set of features which vary |
---|
109 | across the various implementations of the C3x/C4x architecture |
---|
110 | that are of importance to rtems. |
---|
111 | the set of cpu model feature macros are defined in the file |
---|
112 | cpukit/score/cpu/c4x/rtems/score/c4x.h and are based upon |
---|
113 | the particular cpu model defined in the bsp's custom configuration |
---|
114 | file as well as the compilation command line. |
---|
115 | |
---|
116 | @subsection CPU Model Name |
---|
117 | |
---|
118 | The macro @code{CPU_MODEL_NAME} is a string which designates |
---|
119 | the name of this cpu model. for example, for the c32 |
---|
120 | processor, this macro is set to the string "c32". |
---|
121 | |
---|
122 | @subsection Floating Point Unit |
---|
123 | |
---|
124 | The Texas Instruments C3x/C4x family makes little distinction |
---|
125 | between the various cpu registers. Although floating point |
---|
126 | operations may only be performed on a subset of the cpu registers, |
---|
127 | these same registers may be used for normal integer operations. |
---|
128 | as a result of this, this port of rtems makes no distinction |
---|
129 | between integer and floating point contexts. The routine |
---|
130 | @code{_CPU_Context_switch} saves all of the registers that |
---|
131 | comprise a task's context. the routines that initialize, |
---|
132 | save, and restore floating point contexts are not present |
---|
133 | in this port. |
---|
134 | |
---|
135 | Moreover, there is no floating point context pointer and |
---|
136 | the code in @code{_Thread_Dispatch} that manages the |
---|
137 | floating point context switching process is disabled |
---|
138 | on this port. |
---|
139 | |
---|
140 | This not only simplifies the port, it also speeds up context |
---|
141 | switches by reducing the code involved and reduces the code |
---|
142 | space footprint of the executive on the Texas Instruments |
---|
143 | C3x/C4x. |
---|
144 | |
---|
145 | @c |
---|
146 | @c COPYRIGHT (c) 1988-1999. |
---|
147 | @c On-Line Applications Research Corporation (OAR). |
---|
148 | @c All rights reserved. |
---|
149 | @c |
---|
150 | @c $Id$ |
---|
151 | @c |
---|
152 | |
---|
153 | @section Calling Conventions |
---|
154 | |
---|
155 | |
---|
156 | Each high-level language compiler generates |
---|
157 | subroutine entry and exit code based upon a set of rules known |
---|
158 | as the compiler's calling convention. These rules address the |
---|
159 | following issues: |
---|
160 | |
---|
161 | @itemize @bullet |
---|
162 | @item register preservation and usage |
---|
163 | @item parameter passing |
---|
164 | @item call and return mechanism |
---|
165 | @end itemize |
---|
166 | |
---|
167 | A compiler's calling convention is of importance when |
---|
168 | interfacing to subroutines written in another language either |
---|
169 | assembly or high-level. Even when the high-level language and |
---|
170 | target processor are the same, different compilers may use |
---|
171 | different calling conventions. As a result, calling conventions |
---|
172 | are both processor and compiler dependent. |
---|
173 | |
---|
174 | The GNU Compiler Suite follows the same calling conventions |
---|
175 | as the Texas Instruments toolset. |
---|
176 | |
---|
177 | @subsection Processor Background |
---|
178 | |
---|
179 | The TI C3x and C4x processors support a simple yet |
---|
180 | effective call and return mechanism. A subroutine is invoked |
---|
181 | via the branch to subroutine (@code{XXX}) or the jump to subroutine |
---|
182 | (@code{XXX}) instructions. These instructions push the return address |
---|
183 | on the current stack. The return from subroutine (@code{XXX}) |
---|
184 | instruction pops the return address off the current stack and |
---|
185 | transfers control to that instruction. It is important to |
---|
186 | note that the call and return mechanism for the C3x/C4x does not |
---|
187 | automatically save or restore any registers. It is the |
---|
188 | responsibility of the high-level language compiler to define the |
---|
189 | register preservation and usage convention. |
---|
190 | |
---|
191 | XXX other supplements may have "is is". |
---|
192 | |
---|
193 | @subsection Calling Mechanism |
---|
194 | |
---|
195 | All subroutines are invoked using either a @code{XXX} |
---|
196 | or @code{XXX} instruction and return to the user application via the |
---|
197 | @code{XXX} instruction. |
---|
198 | |
---|
199 | @subsection Register Usage |
---|
200 | |
---|
201 | XXX |
---|
202 | |
---|
203 | As discussed above, the @code{XXX} and @code{XXX} instructions do |
---|
204 | not automatically save any registers. Subroutines use the registers |
---|
205 | @b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers. These registers are |
---|
206 | not preserved by subroutines therefore, the contents of |
---|
207 | these registers should not be assumed upon return from any subroutine |
---|
208 | call including but not limited to an RTEMS directive. |
---|
209 | |
---|
210 | The GNU and Texas Instruments compilers follow the same conventions |
---|
211 | for register usage. |
---|
212 | |
---|
213 | @subsection Parameter Passing |
---|
214 | |
---|
215 | Both the GNU and Texas Instruments compilers support two conventions |
---|
216 | for passing parameters to subroutines. Arguments may be passed in |
---|
217 | memory on the stack or in registers. |
---|
218 | |
---|
219 | @subsubsection Parameters Passed in Memory |
---|
220 | |
---|
221 | When passing parameters on the stack, the calling convention assumes |
---|
222 | that arguments are placed on the current stack before the subroutine |
---|
223 | is invoked via the @code{XXX} instruction. The first argument is |
---|
224 | assumed to be closest to the return address on the stack. This means |
---|
225 | that the first argument of the C calling sequence is pushed last. The |
---|
226 | following pseudo-code illustrates the typical sequence used to call a |
---|
227 | subroutine with three (3) arguments: |
---|
228 | |
---|
229 | @example |
---|
230 | @group |
---|
231 | push third argument |
---|
232 | push second argument |
---|
233 | push first argument |
---|
234 | invoke subroutine |
---|
235 | remove arguments from the stack |
---|
236 | @end group |
---|
237 | @end example |
---|
238 | |
---|
239 | The arguments to RTEMS are typically pushed onto the |
---|
240 | stack using a @code{sti} instruction with a pre-incremented stack |
---|
241 | pointer as the destination. These arguments must be removed |
---|
242 | from the stack after control is returned to the caller. This |
---|
243 | removal is typically accomplished by subtracting the size of the |
---|
244 | argument list in words from the current stack pointer. |
---|
245 | |
---|
246 | @c XXX XXX instruction .. XXX should be code format. |
---|
247 | |
---|
248 | With the GNU Compiler Suite, parameter passing via the |
---|
249 | stack is selected by invoking the compiler with the |
---|
250 | @code{-mmemparm XXX} argument. This argument must be |
---|
251 | included when linking the application in order to |
---|
252 | ensure that support libraries also compiled assuming |
---|
253 | parameter passing via the stack are used. The default |
---|
254 | parameter passing mechanism is XXX. |
---|
255 | |
---|
256 | When this parameter passing mecahanism is selected, the @code{XXX} |
---|
257 | symbol is predefined by the C and C++ compilers |
---|
258 | and the @code{XXX} symbol is predefined by the assembler. |
---|
259 | This behavior is the same for the GNU and Texas Instruments |
---|
260 | toolsets. RTEMS uses these predefines to determine how |
---|
261 | parameters are passed in to those C3x/C4x specific routines |
---|
262 | that were written in assembly language. |
---|
263 | |
---|
264 | @subsubsection Parameters Passed in Registers |
---|
265 | |
---|
266 | When passing parameters via registers, the calling convention assumes |
---|
267 | that the arguments are placed in particular registers based upon |
---|
268 | their position and data type before the subroutine is invoked via |
---|
269 | the @code{XXX} instruction. |
---|
270 | |
---|
271 | The following pseudo-code illustrates |
---|
272 | the typical sequence used to call a subroutine with three (3) arguments: |
---|
273 | |
---|
274 | @example |
---|
275 | @group |
---|
276 | move third argument to XXX |
---|
277 | move second argument to XXX |
---|
278 | move first argument to XXX |
---|
279 | invoke subroutine |
---|
280 | @end group |
---|
281 | @end example |
---|
282 | |
---|
283 | With the GNU Compiler Suite, parameter passing via |
---|
284 | registers is selected by invoking the compiler with the |
---|
285 | @code{-mregparm XXX} argument. This argument must be |
---|
286 | included when linking the application in order to |
---|
287 | ensure that support libraries also compiled assuming |
---|
288 | parameter passing via the stack are used. The default |
---|
289 | parameter passing mechanism is XXX. |
---|
290 | |
---|
291 | When this parameter passing mecahanism is selected, the @code{XXX} |
---|
292 | symbol is predefined by the C and C++ compilers |
---|
293 | and the @code{XXX} symbol is predefined by the assembler. |
---|
294 | This behavior is the same for the GNU and Texas Instruments |
---|
295 | toolsets. RTEMS uses these predefines to determine how |
---|
296 | parameters are passed in to those C3x/C4x specific routines |
---|
297 | that were written in assembly language. |
---|
298 | |
---|
299 | @subsection User-Provided Routines |
---|
300 | |
---|
301 | All user-provided routines invoked by RTEMS, such as |
---|
302 | user extensions, device drivers, and MPCI routines, must also |
---|
303 | adhere to these calling conventions. |
---|
304 | |
---|
305 | @c |
---|
306 | @c COPYRIGHT (c) 1988-1999. |
---|
307 | @c On-Line Applications Research Corporation (OAR). |
---|
308 | @c All rights reserved. |
---|
309 | @c |
---|
310 | @c $Id$ |
---|
311 | @c |
---|
312 | |
---|
313 | @section Memory Model |
---|
314 | |
---|
315 | |
---|
316 | A processor may support any combination of memory |
---|
317 | models ranging from pure physical addressing to complex demand |
---|
318 | paged virtual memory systems. RTEMS supports a flat memory |
---|
319 | model which ranges contiguously over the processor's allowable |
---|
320 | address space. RTEMS does not support segmentation or virtual |
---|
321 | memory of any kind. The appropriate memory model for RTEMS |
---|
322 | provided by the targeted processor and related characteristics |
---|
323 | of that model are described in this chapter. |
---|
324 | |
---|
325 | @subsection Byte Addressable versus Word Addressable |
---|
326 | |
---|
327 | Processor in the Texas Instruments C3x/C4x family are |
---|
328 | word addressable. This is in sharp contrast to CISC and |
---|
329 | RISC processors that are typically byte addressable. In a word |
---|
330 | addressable architecture, each address points not to an |
---|
331 | 8-bit byte or octet but to 32 bits. |
---|
332 | |
---|
333 | On first glance, byte versus word addressability does not |
---|
334 | sound like a problem but in fact, this issue can result in |
---|
335 | subtle problems in high-level language software that is ported |
---|
336 | to a word addressable processor family. The following is a |
---|
337 | list of the commonly encountered problems: |
---|
338 | |
---|
339 | @table @b |
---|
340 | |
---|
341 | @item String Optimizations |
---|
342 | Although each character in a string occupies a single address just |
---|
343 | as it does on a byte addressable CPU, each character occupies |
---|
344 | 32 rather than 8 bits. The most significant 24 bytes are |
---|
345 | of each address are ignored. This in and of itself does not |
---|
346 | cause problems but it violates the assumption that two |
---|
347 | adjacent characters in a string have no intervening bits. |
---|
348 | This assumption is often implicit in string and memory comparison |
---|
349 | routines that are optimized to compare 4 adjacent characters |
---|
350 | with a word oriented operation. This optimization is |
---|
351 | invalid on word addressable processors. |
---|
352 | |
---|
353 | @item Sizeof |
---|
354 | The C operation @code{sizeof} returns very different results |
---|
355 | on the C3x/C4x than on traditional RISC/CISC processors. |
---|
356 | The @code{sizeof(char)}, @code{sizeof(short)}, and @code{sizeof(int)} |
---|
357 | are all 1 since each occupies a single addressable unit that is |
---|
358 | thirty-two bits wide. On most thirty-two bit processors, |
---|
359 | @code{sizeof(char} is one, @code{sizeof(short)} is two, |
---|
360 | and @code{sizeof(int)} is four. Just as software makes assumptions |
---|
361 | about the sizes of the primitive data types has problems |
---|
362 | when ported to a sixty-four bit architecture, these same |
---|
363 | assumptions cause problems on the C3x/C4x. |
---|
364 | |
---|
365 | @item Alignment |
---|
366 | Since each addressable unit is thirty-two bit wide, there |
---|
367 | are no alignment restrictions. The native integer type |
---|
368 | need only be aligned on a "one unit" boundary not a "four |
---|
369 | unit" boundary as on numerous other processors. |
---|
370 | |
---|
371 | @end table |
---|
372 | |
---|
373 | @subsection Flat Memory Model |
---|
374 | |
---|
375 | XXX check actual bits on the various processor families. |
---|
376 | |
---|
377 | The XXX family supports a flat 32-bit address |
---|
378 | space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 |
---|
379 | gigabytes). Each address is represented by a 32-bit value and |
---|
380 | is byte addressable. The address may be used to reference a |
---|
381 | single byte, word (2-bytes), or long word (4 bytes). Memory |
---|
382 | accesses within this address space are performed in big endian |
---|
383 | fashion by the processors in this family. |
---|
384 | |
---|
385 | @subsection Compiler Memory Models |
---|
386 | |
---|
387 | The Texas Instruments C3x/C4x processors include a Data Page |
---|
388 | (@code{dp}) register that logically is a base address. The |
---|
389 | @code{dp} register allows the use of shorter offsets in |
---|
390 | instructions. Up to 64K words may be addressed using |
---|
391 | offsets from the @code{dp} register. In order to address |
---|
392 | words not addressable based on the current value of |
---|
393 | @code{dp}, the register must be loaded with a different |
---|
394 | value. |
---|
395 | |
---|
396 | The @code{dp} register is managed automatically by |
---|
397 | the high-level language compilers. |
---|
398 | The various compilers for this processor family support |
---|
399 | two memory models that manage the @code{dp} register |
---|
400 | in very different manners. The large and small memory |
---|
401 | models are discussed in the following sections. |
---|
402 | |
---|
403 | NOTE: The C3x/C4x port of RTEMS has been written |
---|
404 | so that it should support either memory model. |
---|
405 | However, it has only been tested using the |
---|
406 | large memory model. |
---|
407 | |
---|
408 | @subsubsection Small Memory Model |
---|
409 | |
---|
410 | The small memory model is the simplest and most |
---|
411 | efficient. However, it includes a limitation that |
---|
412 | make it inappropriate for numerous applications. The |
---|
413 | small memory model assumes that the application needs |
---|
414 | to access no more than 64K words. Thus the @code{dp} |
---|
415 | register can be loaded at application start time |
---|
416 | and never reloaded. Thus the compiler will not |
---|
417 | even generate instructions to load the @code{dp}. |
---|
418 | |
---|
419 | This can significantly reduce the code space |
---|
420 | required by an application but the application |
---|
421 | is limited in the amount of data it can access. |
---|
422 | |
---|
423 | With the GNU Compiler Suite, small memory model is |
---|
424 | selected by invoking the compiler with either the |
---|
425 | @code{-msmall} or @code{-msmallmemoryXXX} argument. |
---|
426 | This argument must be included when linking the application |
---|
427 | in order to ensure that support libraries also compiled |
---|
428 | for the large memory model are used. |
---|
429 | The default memory model is XXX. |
---|
430 | |
---|
431 | When this memory model is selected, the @code{XXX} |
---|
432 | symbol is predefined by the C and C++ compilers |
---|
433 | and the @code{XXX} symbol is predefined by the assembler. |
---|
434 | This behavior is the same for the GNU and Texas Instruments |
---|
435 | toolsets. RTEMS uses these predefines to determine the proper handling |
---|
436 | of the @code{dp} register in those C3x/C4x specific routines |
---|
437 | that were written in assembly language. |
---|
438 | |
---|
439 | @subsubsection Large Memory Model |
---|
440 | |
---|
441 | The large memory model is more complex and less efficient |
---|
442 | than the small memory model. However, it removes the |
---|
443 | 64K uninitialized data restriction from applications. |
---|
444 | The @code{dp} register is reloaded automatically |
---|
445 | by the compiler each time data is accessed. This leads |
---|
446 | to an increase in the code space requirements for the |
---|
447 | application but gives it access to much more data space. |
---|
448 | |
---|
449 | With the GNU Compiler Suite, large memory model is |
---|
450 | selected by invoking the compiler with either the |
---|
451 | @code{-mlarge} or @code{-mlargememoryXXX} argument. |
---|
452 | This argument must be included when linking the application |
---|
453 | in order to ensure that support libraries also compiled |
---|
454 | for the large memory model are used. |
---|
455 | The default memory model is XXX. |
---|
456 | |
---|
457 | When this memory model is selected, the @code{XXX} |
---|
458 | symbol is predefined by the C and C++ compilers |
---|
459 | and the @code{XXX} symbol is predefined by the assembler. |
---|
460 | This behavior is the same for the GNU and Texas Instruments |
---|
461 | toolsets. RTEMS uses these predefines to determine the proper handling |
---|
462 | of the @code{dp} register in those C3x/C4x specific routines |
---|
463 | that were written in assembly language. |
---|
464 | @c |
---|
465 | @c Interrupt Stack Frame Picture |
---|
466 | @c |
---|
467 | @c COPYRIGHT (c) 1988-1999. |
---|
468 | @c On-Line Applications Research Corporation (OAR). |
---|
469 | @c All rights reserved. |
---|
470 | @c |
---|
471 | @c $Id$ |
---|
472 | @c |
---|
473 | |
---|
474 | @section Interrupt Processing |
---|
475 | |
---|
476 | |
---|
477 | Different types of processors respond to the |
---|
478 | occurrence of an interrupt in its own unique fashion. In |
---|
479 | addition, each processor type provides a control mechanism to |
---|
480 | allow for the proper handling of an interrupt. The processor |
---|
481 | dependent response to the interrupt modifies the current |
---|
482 | execution state and results in a change in the execution stream. |
---|
483 | Most processors require that an interrupt handler utilize some |
---|
484 | special control mechanisms to return to the normal processing |
---|
485 | stream. Although RTEMS hides many of the processor dependent |
---|
486 | details of interrupt processing, it is important to understand |
---|
487 | how the RTEMS interrupt manager is mapped onto the processor's |
---|
488 | unique architecture. Discussed in this chapter are the XXX's |
---|
489 | interrupt response and control mechanisms as they pertain to |
---|
490 | RTEMS. |
---|
491 | |
---|
492 | @subsection Vectoring of an Interrupt Handler |
---|
493 | |
---|
494 | Depending on whether or not the particular CPU |
---|
495 | supports a separate interrupt stack, the XXX family has two |
---|
496 | different interrupt handling models. |
---|
497 | |
---|
498 | @subsubsection Models Without Separate Interrupt Stacks |
---|
499 | |
---|
500 | Upon receipt of an interrupt the XXX family |
---|
501 | members without separate interrupt stacks automatically perform |
---|
502 | the following actions: |
---|
503 | |
---|
504 | @itemize @bullet |
---|
505 | @item To Be Written |
---|
506 | @end itemize |
---|
507 | |
---|
508 | @subsubsection Models With Separate Interrupt Stacks |
---|
509 | |
---|
510 | Upon receipt of an interrupt the XXX family |
---|
511 | members with separate interrupt stacks automatically perform the |
---|
512 | following actions: |
---|
513 | |
---|
514 | @itemize @bullet |
---|
515 | @item saves the current status register (SR), |
---|
516 | |
---|
517 | @item clears the master/interrupt (M) bit of the SR to |
---|
518 | indicate the switch from master state to interrupt state, |
---|
519 | |
---|
520 | @item sets the privilege mode to supervisor, |
---|
521 | |
---|
522 | @item suppresses tracing, |
---|
523 | |
---|
524 | @item sets the interrupt mask level equal to the level of the |
---|
525 | interrupt being serviced, |
---|
526 | |
---|
527 | @item pushes an interrupt stack frame (ISF), which includes |
---|
528 | the program counter (PC), the status register (SR), and the |
---|
529 | format/exception vector offset (FVO) word, onto the supervisor |
---|
530 | and interrupt stacks, |
---|
531 | |
---|
532 | @item switches the current stack to the interrupt stack and |
---|
533 | vectors to an interrupt service routine (ISR). If the ISR was |
---|
534 | installed with the interrupt_catch directive, then the RTEMS |
---|
535 | interrupt handler will begin execution. The RTEMS interrupt |
---|
536 | handler saves all registers which are not preserved according to |
---|
537 | the calling conventions and invokes the application's ISR. |
---|
538 | @end itemize |
---|
539 | |
---|
540 | A nested interrupt is processed similarly by these |
---|
541 | CPU models with the exception that only a single ISF is placed |
---|
542 | on the interrupt stack and the current stack need not be |
---|
543 | switched. |
---|
544 | |
---|
545 | The FVO word in the Interrupt Stack Frame is examined |
---|
546 | by RTEMS to determine when an outer most interrupt is being |
---|
547 | exited. Since the FVO is used by RTEMS for this purpose, the |
---|
548 | user application code MUST NOT modify this field. |
---|
549 | |
---|
550 | The following shows the Interrupt Stack Frame for |
---|
551 | XXX CPU models with separate interrupt stacks: |
---|
552 | |
---|
553 | @ifset use-ascii |
---|
554 | @example |
---|
555 | @group |
---|
556 | +----------------------+ |
---|
557 | | Status Register | 0x0 |
---|
558 | +----------------------+ |
---|
559 | | Program Counter High | 0x2 |
---|
560 | +----------------------+ |
---|
561 | | Program Counter Low | 0x4 |
---|
562 | +----------------------+ |
---|
563 | | Format/Vector Offset | 0x6 |
---|
564 | +----------------------+ |
---|
565 | @end group |
---|
566 | @end example |
---|
567 | @end ifset |
---|
568 | |
---|
569 | @ifset use-tex |
---|
570 | @sp 1 |
---|
571 | @tex |
---|
572 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
573 | \strut\vrule#& |
---|
574 | \hbox to 2.00in{\enskip\hfil#\hfil}& |
---|
575 | \vrule#& |
---|
576 | \hbox to 0.50in{\enskip\hfil#\hfil} |
---|
577 | \cr |
---|
578 | \multispan{3}\hrulefill\cr |
---|
579 | & Status Register && 0x0\cr |
---|
580 | \multispan{3}\hrulefill\cr |
---|
581 | & Program Counter High && 0x2\cr |
---|
582 | \multispan{3}\hrulefill\cr |
---|
583 | & Program Counter Low && 0x4\cr |
---|
584 | \multispan{3}\hrulefill\cr |
---|
585 | & Format/Vector Offset && 0x6\cr |
---|
586 | \multispan{3}\hrulefill\cr |
---|
587 | }}\hfil} |
---|
588 | @end tex |
---|
589 | @end ifset |
---|
590 | |
---|
591 | @ifset use-html |
---|
592 | @html |
---|
593 | <CENTER> |
---|
594 | <TABLE COLS=2 WIDTH="40%" BORDER=2> |
---|
595 | <TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD> |
---|
596 | <TD ALIGN=center>0x0</TD></TR> |
---|
597 | <TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD> |
---|
598 | <TD ALIGN=center>0x2</TD></TR> |
---|
599 | <TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD> |
---|
600 | <TD ALIGN=center>0x4</TD></TR> |
---|
601 | <TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD> |
---|
602 | <TD ALIGN=center>0x6</TD></TR> |
---|
603 | </TABLE> |
---|
604 | </CENTER> |
---|
605 | @end html |
---|
606 | @end ifset |
---|
607 | |
---|
608 | @subsection Interrupt Levels |
---|
609 | |
---|
610 | Eight levels (0-7) of interrupt priorities are |
---|
611 | supported by XXX family members with level seven (7) being |
---|
612 | the highest priority. Level zero (0) indicates that interrupts |
---|
613 | are fully enabled. Interrupt requests for interrupts with |
---|
614 | priorities less than or equal to the current interrupt mask |
---|
615 | level are ignored. |
---|
616 | |
---|
617 | Although RTEMS supports 256 interrupt levels, the |
---|
618 | XXX family only supports eight. RTEMS interrupt levels 0 |
---|
619 | through 7 directly correspond to XXX interrupt levels. All |
---|
620 | other RTEMS interrupt levels are undefined and their behavior is |
---|
621 | unpredictable. |
---|
622 | |
---|
623 | @subsection Disabling of Interrupts by RTEMS |
---|
624 | |
---|
625 | During the execution of directive calls, critical |
---|
626 | sections of code may be executed. When these sections are |
---|
627 | encountered, RTEMS disables interrupts to level seven (7) before |
---|
628 | the execution of this section and restores them to the previous |
---|
629 | level upon completion of the section. RTEMS has been optimized |
---|
630 | to insure that interrupts are disabled for less than |
---|
631 | RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a |
---|
632 | RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz XXX with |
---|
633 | zero wait states. These numbers will vary based the |
---|
634 | number of wait states and processor speed present on the target board. |
---|
635 | [NOTE: The maximum period with interrupts disabled is hand calculated. This |
---|
636 | calculation was last performed for Release |
---|
637 | RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
---|
638 | |
---|
639 | Non-maskable interrupts (NMI) cannot be disabled, and |
---|
640 | ISRs which execute at this level MUST NEVER issue RTEMS system |
---|
641 | calls. If a directive is invoked, unpredictable results may |
---|
642 | occur due to the inability of RTEMS to protect its critical |
---|
643 | sections. However, ISRs that make no system calls may safely |
---|
644 | execute as non-maskable interrupts. |
---|
645 | |
---|
646 | @subsection Interrupt Stack |
---|
647 | |
---|
648 | RTEMS allocates the interrupt stack from the |
---|
649 | Workspace Area. The amount of memory allocated for the |
---|
650 | interrupt stack is determined by the interrupt_stack_size field |
---|
651 | in the CPU Configuration Table. During the initialization |
---|
652 | process, RTEMS will install its interrupt stack. |
---|
653 | |
---|
654 | The XXX port of RTEMS supports a software managed |
---|
655 | dedicated interrupt stack on those CPU models which do not |
---|
656 | support a separate interrupt stack in hardware. |
---|
657 | |
---|
658 | |
---|
659 | @c |
---|
660 | @c COPYRIGHT (c) 1988-1999. |
---|
661 | @c On-Line Applications Research Corporation (OAR). |
---|
662 | @c All rights reserved. |
---|
663 | @c |
---|
664 | @c $Id$ |
---|
665 | @c |
---|
666 | |
---|
667 | @section Default Fatal Error Processing |
---|
668 | |
---|
669 | |
---|
670 | Upon detection of a fatal error by either the |
---|
671 | application or RTEMS the fatal error manager is invoked. The |
---|
672 | fatal error manager will invoke the user-supplied fatal error |
---|
673 | handlers. If no user-supplied handlers are configured, the |
---|
674 | RTEMS provided default fatal error handler is invoked. If the |
---|
675 | user-supplied fatal error handlers return to the executive the |
---|
676 | default fatal error handler is then invoked. This chapter |
---|
677 | describes the precise operations of the default fatal error |
---|
678 | handler. |
---|
679 | |
---|
680 | @subsection Default Fatal Error Handler Operations |
---|
681 | |
---|
682 | The default fatal error handler which is invoked by |
---|
683 | the @code{rtems_fatal_error_occurred} directive when there is |
---|
684 | no user handler configured or the user handler returns control to |
---|
685 | RTEMS. The default fatal error handler disables processor interrupts, |
---|
686 | places the error code in @b{XXX}, and executes a @code{XXX} |
---|
687 | instruction to simulate a halt processor instruction. |
---|
688 | |
---|
689 | @c |
---|
690 | @c COPYRIGHT (c) 1988-1999. |
---|
691 | @c On-Line Applications Research Corporation (OAR). |
---|
692 | @c All rights reserved. |
---|
693 | @c |
---|
694 | @c $Id$ |
---|
695 | @c |
---|
696 | |
---|
697 | @section Board Support Packages |
---|
698 | |
---|
699 | |
---|
700 | An RTEMS Board Support Package (BSP) must be designed |
---|
701 | to support a particular processor and target board combination. |
---|
702 | This chapter presents a discussion of XXX specific BSP |
---|
703 | issues. For more information on developing a BSP, refer to the |
---|
704 | chapter titled Board Support Packages in the RTEMS |
---|
705 | Applications User's Guide. |
---|
706 | |
---|
707 | @subsection System Reset |
---|
708 | |
---|
709 | An RTEMS based application is initiated or |
---|
710 | re-initiated when the XXX processor is reset. When the |
---|
711 | XXX is reset, the processor performs the following actions: |
---|
712 | |
---|
713 | @itemize @bullet |
---|
714 | @item The tracing bits of the status register are cleared to |
---|
715 | disable tracing. |
---|
716 | |
---|
717 | @item The supervisor interrupt state is entered by setting the |
---|
718 | supervisor (S) bit and clearing the master/interrupt (M) bit of |
---|
719 | the status register. |
---|
720 | |
---|
721 | @item The interrupt mask of the status register is set to |
---|
722 | level 7 to effectively disable all maskable interrupts. |
---|
723 | |
---|
724 | @item The vector base register (VBR) is set to zero. |
---|
725 | |
---|
726 | @item The cache control register (CACR) is set to zero to |
---|
727 | disable and freeze the processor cache. |
---|
728 | |
---|
729 | @item The interrupt stack pointer (ISP) is set to the value |
---|
730 | stored at vector 0 (bytes 0-3) of the exception vector table |
---|
731 | (EVT). |
---|
732 | |
---|
733 | @item The program counter (PC) is set to the value stored at |
---|
734 | vector 1 (bytes 4-7) of the EVT. |
---|
735 | |
---|
736 | @item The processor begins execution at the address stored in |
---|
737 | the PC. |
---|
738 | @end itemize |
---|
739 | |
---|
740 | @subsection Processor Initialization |
---|
741 | |
---|
742 | The address of the application's initialization code |
---|
743 | should be stored in the first vector of the EVT which will allow |
---|
744 | the immediate vectoring to the application code. If the |
---|
745 | application requires that the VBR be some value besides zero, |
---|
746 | then it should be set to the required value at this point. All |
---|
747 | tasks share the same XXX's VBR value. Because interrupts |
---|
748 | are enabled automatically by RTEMS as part of the initialize |
---|
749 | executive directive, the VBR MUST be set before this directive |
---|
750 | is invoked to insure correct interrupt vectoring. If processor |
---|
751 | caching is to be utilized, then it should be enabled during the |
---|
752 | reset application initialization code. |
---|
753 | |
---|
754 | In addition to the requirements described in the |
---|
755 | Board Support Packages chapter of the Applications User's |
---|
756 | Manual for the reset code which is executed before the call to |
---|
757 | initialize executive, the XXX version has the following |
---|
758 | specific requirements: |
---|
759 | |
---|
760 | @itemize @bullet |
---|
761 | @item Must leave the S bit of the status register set so that |
---|
762 | the XXX remains in the supervisor state. |
---|
763 | |
---|
764 | @item Must set the M bit of the status register to remove the |
---|
765 | XXX from the interrupt state. |
---|
766 | |
---|
767 | @item Must set the master stack pointer (MSP) such that a |
---|
768 | minimum stack size of MINIMUM_STACK_SIZE bytes is provided for |
---|
769 | the initialize executive directive. |
---|
770 | |
---|
771 | @item Must initialize the XXX's vector table. |
---|
772 | @end itemize |
---|
773 | |
---|
774 | Note that the BSP is not responsible for allocating |
---|
775 | or installing the interrupt stack. RTEMS does this |
---|
776 | automatically as part of initialization. If the BSP does not |
---|
777 | install an interrupt stack and -- for whatever reason -- an |
---|
778 | interrupt occurs before initialize_executive is invoked, then |
---|
779 | the results are unpredictable. |
---|
780 | |
---|
781 | @c |
---|
782 | @c COPYRIGHT (c) 1988-1999. |
---|
783 | @c On-Line Applications Research Corporation (OAR). |
---|
784 | @c All rights reserved. |
---|
785 | @c |
---|
786 | @c $Id$ |
---|
787 | @c |
---|
788 | |
---|
789 | @section Processor Dependent Information Table |
---|
790 | |
---|
791 | |
---|
792 | Any highly processor dependent information required |
---|
793 | to describe a processor to RTEMS is provided in the CPU |
---|
794 | Dependent Information Table. This table is not required for all |
---|
795 | processors supported by RTEMS. This chapter describes the |
---|
796 | contents, if any, for a particular processor type. |
---|
797 | |
---|
798 | @subsection CPU Dependent Information Table |
---|
799 | |
---|
800 | The XXX version of the RTEMS CPU Dependent |
---|
801 | Information Table contains the information required to interface |
---|
802 | a Board Support Package and RTEMS on the XXX. This |
---|
803 | information is provided to allow RTEMS to interoperate |
---|
804 | effectively with the BSP. The C structure definition is given |
---|
805 | here: |
---|
806 | |
---|
807 | @example |
---|
808 | @group |
---|
809 | typedef struct @{ |
---|
810 | unsigned32 interrupt_stack_size; |
---|
811 | /* end of fields required on all CPUs */ |
---|
812 | @} rtems_cpu_table; |
---|
813 | @end group |
---|
814 | @end example |
---|
815 | |
---|
816 | @table @code |
---|
817 | |
---|
818 | @item interrupt_stack_size |
---|
819 | is the size of the RTEMS |
---|
820 | allocated interrupt stack in bytes. This value must be at least |
---|
821 | as large as MINIMUM_STACK_SIZE. |
---|
822 | |
---|
823 | @end table |
---|