1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2002. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | |
---|
6 | @ifinfo |
---|
7 | @end ifinfo |
---|
8 | @chapter SPARC Specific Information |
---|
9 | |
---|
10 | The Real Time Executive for Multiprocessor Systems |
---|
11 | (RTEMS) is designed to be portable across multiple processor |
---|
12 | architectures. However, the nature of real-time systems makes |
---|
13 | it essential that the application designer understand certain |
---|
14 | processor dependent implementation details. These processor |
---|
15 | dependencies include calling convention, board support package |
---|
16 | issues, interrupt processing, exact RTEMS memory requirements, |
---|
17 | performance data, header files, and the assembly language |
---|
18 | interface to the executive. |
---|
19 | |
---|
20 | This document discusses the SPARC architecture dependencies in this |
---|
21 | port of RTEMS. This architectural port is for SPARC Version 7 and |
---|
22 | 8. Implementations for SPARC V9 are in the sparc64 target. |
---|
23 | |
---|
24 | It is highly recommended that the SPARC RTEMS |
---|
25 | application developer obtain and become familiar with the |
---|
26 | documentation for the processor being used as well as the |
---|
27 | specification for the revision of the SPARC architecture which |
---|
28 | corresponds to that processor. |
---|
29 | |
---|
30 | @subheading SPARC Architecture Documents |
---|
31 | |
---|
32 | For information on the SPARC architecture, refer to |
---|
33 | the following documents available from SPARC International, Inc. |
---|
34 | (http://www.sparc.com): |
---|
35 | |
---|
36 | @itemize @bullet |
---|
37 | @item SPARC Standard Version 7. |
---|
38 | |
---|
39 | @item SPARC Standard Version 8. |
---|
40 | @end itemize |
---|
41 | |
---|
42 | @subheading ERC32 Specific Information |
---|
43 | |
---|
44 | The European Space Agency's ERC32 is a three chip |
---|
45 | computing core implementing a SPARC V7 processor and associated |
---|
46 | support circuitry for embedded space applications. The integer |
---|
47 | and floating-point units (90C601E & 90C602E) are based on the |
---|
48 | Cypress 7C601 and 7C602, with additional error-detection and |
---|
49 | recovery functions. The memory controller (MEC) implements |
---|
50 | system support functions such as address decoding, memory |
---|
51 | interface, DMA interface, UARTs, timers, interrupt control, |
---|
52 | write-protection, memory reconfiguration and error-detection. |
---|
53 | The core is designed to work at 25MHz, but using space qualified |
---|
54 | memories limits the system frequency to around 15 MHz, resulting |
---|
55 | in a performance of 10 MIPS and 2 MFLOPS. |
---|
56 | |
---|
57 | Information on the ERC32 and a number of development |
---|
58 | support tools, such as the SPARC Instruction Simulator (SIS), |
---|
59 | are freely available on the Internet. The following documents |
---|
60 | and SIS are available via anonymous ftp or pointing your web |
---|
61 | browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. |
---|
62 | |
---|
63 | @itemize @bullet |
---|
64 | @item ERC32 System Design Document |
---|
65 | |
---|
66 | @item MEC Device Specification |
---|
67 | @end itemize |
---|
68 | |
---|
69 | Additionally, the SPARC RISC User's Guide from Matra |
---|
70 | MHS documents the functionality of the integer and floating |
---|
71 | point units including the instruction set information. To |
---|
72 | obtain this document as well as ERC32 components and VHDL models |
---|
73 | contact: |
---|
74 | |
---|
75 | @example |
---|
76 | Matra MHS SA |
---|
77 | 3 Avenue du Centre, BP 309, |
---|
78 | 78054 St-Quentin-en-Yvelines, |
---|
79 | Cedex, France |
---|
80 | VOICE: +31-1-30607087 |
---|
81 | FAX: +31-1-30640693 |
---|
82 | @end example |
---|
83 | |
---|
84 | Amar Guennon (amar.guennon@@matramhs.fr) is familiar with the ERC32. |
---|
85 | |
---|
86 | @c |
---|
87 | @c COPYRIGHT (c) 1988-2002. |
---|
88 | @c On-Line Applications Research Corporation (OAR). |
---|
89 | @c All rights reserved. |
---|
90 | |
---|
91 | @section CPU Model Dependent Features |
---|
92 | |
---|
93 | |
---|
94 | Microprocessors are generally classified into |
---|
95 | families with a variety of CPU models or implementations within |
---|
96 | that family. Within a processor family, there is a high level |
---|
97 | of binary compatibility. This family may be based on either an |
---|
98 | architectural specification or on maintaining compatibility with |
---|
99 | a popular processor. Recent microprocessor families such as the |
---|
100 | SPARC or PowerPC are based on an architectural specification |
---|
101 | which is independent or any particular CPU model or |
---|
102 | implementation. Older families such as the M68xxx and the iX86 |
---|
103 | evolved as the manufacturer strived to produce higher |
---|
104 | performance processor models which maintained binary |
---|
105 | compatibility with older models. |
---|
106 | |
---|
107 | RTEMS takes advantage of the similarity of the |
---|
108 | various models within a CPU family. Although the models do vary |
---|
109 | in significant ways, the high level of compatibility makes it |
---|
110 | possible to share the bulk of the CPU dependent executive code |
---|
111 | across the entire family. |
---|
112 | |
---|
113 | @subsection CPU Model Feature Flags |
---|
114 | |
---|
115 | Each processor family supported by RTEMS has a |
---|
116 | list of features which vary between CPU models |
---|
117 | within a family. For example, the most common model dependent |
---|
118 | feature regardless of CPU family is the presence or absence of a |
---|
119 | floating point unit or coprocessor. When defining the list of |
---|
120 | features present on a particular CPU model, one simply notes |
---|
121 | that floating point hardware is or is not present and defines a |
---|
122 | single constant appropriately. Conditional compilation is |
---|
123 | utilized to include the appropriate source code for this CPU |
---|
124 | model's feature set. It is important to note that this means |
---|
125 | that RTEMS is thus compiled using the appropriate feature set |
---|
126 | and compilation flags optimal for this CPU model used. The |
---|
127 | alternative would be to generate a binary which would execute on |
---|
128 | all family members using only the features which were always |
---|
129 | present. |
---|
130 | |
---|
131 | This section presents the set of features which vary |
---|
132 | across SPARC implementations and are of importance to RTEMS. |
---|
133 | The set of CPU model feature macros are defined in the file |
---|
134 | cpukit/score/cpu/sparc/sparc.h based upon the particular CPU |
---|
135 | model defined on the compilation command line. |
---|
136 | |
---|
137 | @subsubsection CPU Model Name |
---|
138 | |
---|
139 | The macro CPU_MODEL_NAME is a string which designates |
---|
140 | the name of this CPU model. For example, for the European Space |
---|
141 | Agency's ERC32 SPARC model, this macro is set to the string |
---|
142 | "erc32". |
---|
143 | |
---|
144 | @subsubsection Floating Point Unit |
---|
145 | |
---|
146 | The macro SPARC_HAS_FPU is set to 1 to indicate that |
---|
147 | this CPU model has a hardware floating point unit and 0 |
---|
148 | otherwise. |
---|
149 | |
---|
150 | @subsubsection Bitscan Instruction |
---|
151 | |
---|
152 | The macro SPARC_HAS_BITSCAN is set to 1 to indicate |
---|
153 | that this CPU model has the bitscan instruction. For example, |
---|
154 | this instruction is supported by the Fujitsu SPARClite family. |
---|
155 | |
---|
156 | @subsubsection Number of Register Windows |
---|
157 | |
---|
158 | The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to |
---|
159 | indicate the number of register window sets implemented by this |
---|
160 | CPU model. The SPARC architecture allows a for a maximum of |
---|
161 | thirty-two register window sets although most implementations |
---|
162 | only include eight. |
---|
163 | |
---|
164 | @subsubsection Low Power Mode |
---|
165 | |
---|
166 | The macro SPARC_HAS_LOW_POWER_MODE is set to one to |
---|
167 | indicate that this CPU model has a low power mode. If low power |
---|
168 | is enabled, then there must be CPU model specific implementation |
---|
169 | of the IDLE task in cpukit/score/cpu/sparc/cpu.c. The low |
---|
170 | power mode IDLE task should be of the form: |
---|
171 | |
---|
172 | @example |
---|
173 | while ( TRUE ) @{ |
---|
174 | enter low power mode |
---|
175 | @} |
---|
176 | @end example |
---|
177 | |
---|
178 | The code required to enter low power mode is CPU model specific. |
---|
179 | |
---|
180 | @subsection CPU Model Implementation Notes |
---|
181 | |
---|
182 | The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602 |
---|
183 | chipset. This CPU has a number of on-board peripherals and was developed by |
---|
184 | the European Space Agency to target space applications. RTEMS currently |
---|
185 | provides support for the following peripherals: |
---|
186 | |
---|
187 | @itemize @bullet |
---|
188 | @item UART Channels A and B |
---|
189 | @item General Purpose Timer |
---|
190 | @item Real Time Clock |
---|
191 | @item Watchdog Timer (so it can be disabled) |
---|
192 | @item Control Register (so powerdown mode can be enabled) |
---|
193 | @item Memory Control Register |
---|
194 | @item Interrupt Control |
---|
195 | @end itemize |
---|
196 | |
---|
197 | The General Purpose Timer and Real Time Clock Timer provided with the ERC32 |
---|
198 | share the Timer Control Register. Because the Timer Control Register is write |
---|
199 | only, we must mirror it in software and insure that writes to one timer do not |
---|
200 | alter the current settings and status of the other timer. Routines are |
---|
201 | provided in erc32.h which promote the view that the two timers are completely |
---|
202 | independent. By exclusively using these routines to access the Timer Control |
---|
203 | Register, the application can view the system as having a General Purpose |
---|
204 | Timer Control Register and a Real Time Clock Timer Control Register |
---|
205 | rather than the single shared value. |
---|
206 | |
---|
207 | The RTEMS Idle thread take advantage of the low power mode provided by the |
---|
208 | ERC32. Low power mode is entered during idle loops and is enabled at |
---|
209 | initialization time. |
---|
210 | @c |
---|
211 | @c COPYRIGHT (c) 1988-2002. |
---|
212 | @c On-Line Applications Research Corporation (OAR). |
---|
213 | @c All rights reserved. |
---|
214 | |
---|
215 | @section Calling Conventions |
---|
216 | |
---|
217 | Each high-level language compiler generates subroutine entry and exit code |
---|
218 | based upon a set of rules known as the application binary interface (ABI) |
---|
219 | calling convention. These rules address the following issues: |
---|
220 | |
---|
221 | @itemize @bullet |
---|
222 | @item register preservation and usage |
---|
223 | |
---|
224 | @item parameter passing |
---|
225 | |
---|
226 | @item call and return mechanism |
---|
227 | @end itemize |
---|
228 | |
---|
229 | An ABI calling convention is of importance when interfacing to subroutines |
---|
230 | written in another language either assembly or high-level. It determines also |
---|
231 | the set of registers to be saved or restored during a context switch and |
---|
232 | interrupt processing. |
---|
233 | |
---|
234 | The ABI relevant for RTEMS on SPARC is defined by SYSTEM V APPLICATION BINARY |
---|
235 | INTERFACE, SPARC Processor Supplement, Third Edition. |
---|
236 | |
---|
237 | @subsection Programming Model |
---|
238 | |
---|
239 | This section discusses the programming model for the |
---|
240 | SPARC architecture. |
---|
241 | |
---|
242 | @subsubsection Non-Floating Point Registers |
---|
243 | |
---|
244 | The SPARC architecture defines thirty-two |
---|
245 | non-floating point registers directly visible to the programmer. |
---|
246 | These are divided into four sets: |
---|
247 | |
---|
248 | @itemize @bullet |
---|
249 | @item input registers |
---|
250 | |
---|
251 | @item local registers |
---|
252 | |
---|
253 | @item output registers |
---|
254 | |
---|
255 | @item global registers |
---|
256 | @end itemize |
---|
257 | |
---|
258 | Each register is referred to by either two or three |
---|
259 | names in the SPARC reference manuals. First, the registers are |
---|
260 | referred to as r0 through r31 or with the alternate notation |
---|
261 | r[0] through r[31]. Second, each register is a member of one of |
---|
262 | the four sets listed above. Finally, some registers have an |
---|
263 | architecturally defined role in the programming model which |
---|
264 | provides an alternate name. The following table describes the |
---|
265 | mapping between the 32 registers and the register sets: |
---|
266 | |
---|
267 | @ifset use-ascii |
---|
268 | @example |
---|
269 | @group |
---|
270 | +-----------------+----------------+------------------+ |
---|
271 | | Register Number | Register Names | Description | |
---|
272 | +-----------------+----------------+------------------+ |
---|
273 | | 0 - 7 | g0 - g7 | Global Registers | |
---|
274 | +-----------------+----------------+------------------+ |
---|
275 | | 8 - 15 | o0 - o7 | Output Registers | |
---|
276 | +-----------------+----------------+------------------+ |
---|
277 | | 16 - 23 | l0 - l7 | Local Registers | |
---|
278 | +-----------------+----------------+------------------+ |
---|
279 | | 24 - 31 | i0 - i7 | Input Registers | |
---|
280 | +-----------------+----------------+------------------+ |
---|
281 | @end group |
---|
282 | @end example |
---|
283 | @end ifset |
---|
284 | |
---|
285 | @ifset use-tex |
---|
286 | @sp 1 |
---|
287 | @tex |
---|
288 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
289 | \vrule\strut#& |
---|
290 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
291 | \vrule#& |
---|
292 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
293 | \vrule#& |
---|
294 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
295 | \vrule#\cr |
---|
296 | \noalign{\hrule} |
---|
297 | &\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} |
---|
298 | &0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} |
---|
299 | &8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} |
---|
300 | &16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} |
---|
301 | &24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} |
---|
302 | }}\hfil} |
---|
303 | @end tex |
---|
304 | @end ifset |
---|
305 | |
---|
306 | @ifset use-html |
---|
307 | @html |
---|
308 | <CENTER> |
---|
309 | <TABLE COLS=3 WIDTH="80%" BORDER=2> |
---|
310 | <TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD> |
---|
311 | <TD ALIGN=center><STRONG>Register Names</STRONG></TD> |
---|
312 | <TD ALIGN=center><STRONG>Description</STRONG></TD> |
---|
313 | <TR><TD ALIGN=center>0 - 7</TD> |
---|
314 | <TD ALIGN=center>g0 - g7</TD> |
---|
315 | <TD ALIGN=center>Global Registers</TD></TR> |
---|
316 | <TR><TD ALIGN=center>8 - 15</TD> |
---|
317 | <TD ALIGN=center>o0 - o7</TD> |
---|
318 | <TD ALIGN=center>Output Registers</TD></TR> |
---|
319 | <TR><TD ALIGN=center>16 - 23</TD> |
---|
320 | <TD ALIGN=center>l0 - l7</TD> |
---|
321 | <TD ALIGN=center>Local Registers</TD></TR> |
---|
322 | <TR><TD ALIGN=center>24 - 31</TD> |
---|
323 | <TD ALIGN=center>i0 - i7</TD> |
---|
324 | <TD ALIGN=center>Input Registers</TD></TR> |
---|
325 | </TABLE> |
---|
326 | </CENTER> |
---|
327 | @end html |
---|
328 | @end ifset |
---|
329 | |
---|
330 | As mentioned above, some of the registers serve |
---|
331 | defined roles in the programming model. The following table |
---|
332 | describes the role of each of these registers: |
---|
333 | |
---|
334 | @ifset use-ascii |
---|
335 | @example |
---|
336 | @group |
---|
337 | +---------------+----------------+----------------------+ |
---|
338 | | Register Name | Alternate Name | Description | |
---|
339 | +---------------+----------------+----------------------+ |
---|
340 | | g0 | na | reads return 0 | |
---|
341 | | | | writes are ignored | |
---|
342 | +---------------+----------------+----------------------+ |
---|
343 | | o6 | sp | stack pointer | |
---|
344 | +---------------+----------------+----------------------+ |
---|
345 | | i6 | fp | frame pointer | |
---|
346 | +---------------+----------------+----------------------+ |
---|
347 | | i7 | na | return address | |
---|
348 | +---------------+----------------+----------------------+ |
---|
349 | @end group |
---|
350 | @end example |
---|
351 | @end ifset |
---|
352 | |
---|
353 | @ifset use-tex |
---|
354 | @sp 1 |
---|
355 | @tex |
---|
356 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
357 | \vrule\strut#& |
---|
358 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
359 | \vrule#& |
---|
360 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
361 | \vrule#& |
---|
362 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
363 | \vrule#\cr |
---|
364 | \noalign{\hrule} |
---|
365 | &\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} |
---|
366 | &g0&&NA&&reads return 0; &\cr |
---|
367 | &&&&&writes are ignored&\cr\noalign{\hrule} |
---|
368 | &o6&&sp&&stack pointer&\cr\noalign{\hrule} |
---|
369 | &i6&&fp&&frame pointer&\cr\noalign{\hrule} |
---|
370 | &i7&&NA&&return address&\cr\noalign{\hrule} |
---|
371 | }}\hfil} |
---|
372 | @end tex |
---|
373 | @end ifset |
---|
374 | |
---|
375 | @ifset use-html |
---|
376 | @html |
---|
377 | <CENTER> |
---|
378 | <TABLE COLS=3 WIDTH="80%" BORDER=2> |
---|
379 | <TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD> |
---|
380 | <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD> |
---|
381 | <TD ALIGN=center><STRONG>Description</STRONG></TD></TR> |
---|
382 | <TR><TD ALIGN=center>g0</TD> |
---|
383 | <TD ALIGN=center>NA</TD> |
---|
384 | <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR> |
---|
385 | <TR><TD ALIGN=center>o6</TD> |
---|
386 | <TD ALIGN=center>sp</TD> |
---|
387 | <TD ALIGN=center>stack pointer</TD></TR> |
---|
388 | <TR><TD ALIGN=center>i6</TD> |
---|
389 | <TD ALIGN=center>fp</TD> |
---|
390 | <TD ALIGN=center>frame pointer</TD></TR> |
---|
391 | <TR><TD ALIGN=center>i7</TD> |
---|
392 | <TD ALIGN=center>NA</TD> |
---|
393 | <TD ALIGN=center>return address</TD></TR> |
---|
394 | </TABLE> |
---|
395 | </CENTER> |
---|
396 | @end html |
---|
397 | @end ifset |
---|
398 | |
---|
399 | The registers g2 through g4 are reserved for applications. GCC uses them as |
---|
400 | volatile registers by default. So they are treated like volatile registers in |
---|
401 | RTEMS as well. |
---|
402 | |
---|
403 | The register g6 is reserved for the operating system and contains the address |
---|
404 | of the per-CPU control block of the current processor. This register is |
---|
405 | initialized during system start and then remains unchanged. It is not |
---|
406 | saved/restored by the context switch or interrupt processing code. |
---|
407 | |
---|
408 | The register g7 is reserved for the operating system and contains the thread |
---|
409 | pointer used for thread-local storage (TLS) as mandated by the SPARC ABI. |
---|
410 | |
---|
411 | @subsubsection Floating Point Registers |
---|
412 | |
---|
413 | The SPARC V7 architecture includes thirty-two, |
---|
414 | thirty-two bit registers. These registers may be viewed as |
---|
415 | follows: |
---|
416 | |
---|
417 | @itemize @bullet |
---|
418 | @item 32 single precision floating point or integer registers |
---|
419 | (f0, f1, ... f31) |
---|
420 | |
---|
421 | @item 16 double precision floating point registers (f0, f2, |
---|
422 | f4, ... f30) |
---|
423 | |
---|
424 | @item 8 extended precision floating point registers (f0, f4, |
---|
425 | f8, ... f28) |
---|
426 | @end itemize |
---|
427 | |
---|
428 | The floating point status register (fpsr) specifies |
---|
429 | the behavior of the floating point unit for rounding, contains |
---|
430 | its condition codes, version specification, and trap information. |
---|
431 | |
---|
432 | A queue of the floating point instructions which have |
---|
433 | started execution but not yet completed is maintained. This |
---|
434 | queue is needed to support the multiple cycle nature of floating |
---|
435 | point operations and to aid floating point exception trap |
---|
436 | handlers. Once a floating point exception has been encountered, |
---|
437 | the queue is frozen until it is emptied by the trap handler. |
---|
438 | The floating point queue is loaded by launching instructions. |
---|
439 | It is emptied normally when the floating point completes all |
---|
440 | outstanding instructions and by floating point exception |
---|
441 | handlers with the store double floating point queue (stdfq) |
---|
442 | instruction. |
---|
443 | |
---|
444 | @subsubsection Special Registers |
---|
445 | |
---|
446 | The SPARC architecture includes two special registers |
---|
447 | which are critical to the programming model: the Processor State |
---|
448 | Register (psr) and the Window Invalid Mask (wim). The psr |
---|
449 | contains the condition codes, processor interrupt level, trap |
---|
450 | enable bit, supervisor mode and previous supervisor mode bits, |
---|
451 | version information, floating point unit and coprocessor enable |
---|
452 | bits, and the current window pointer (cwp). The cwp field of |
---|
453 | the psr and wim register are used to manage the register windows |
---|
454 | in the SPARC architecture. The register windows are discussed |
---|
455 | in more detail below. |
---|
456 | |
---|
457 | @subsection Register Windows |
---|
458 | |
---|
459 | The SPARC architecture includes the concept of |
---|
460 | register windows. An overly simplistic way to think of these |
---|
461 | windows is to imagine them as being an infinite supply of |
---|
462 | "fresh" register sets available for each subroutine to use. In |
---|
463 | reality, they are much more complicated. |
---|
464 | |
---|
465 | The save instruction is used to obtain a new register |
---|
466 | window. This instruction decrements the current window pointer, |
---|
467 | thus providing a new set of registers for use. This register |
---|
468 | set includes eight fresh local registers for use exclusively by |
---|
469 | this subroutine. When done with a register set, the restore |
---|
470 | instruction increments the current window pointer and the |
---|
471 | previous register set is once again available. |
---|
472 | |
---|
473 | The two primary issues complicating the use of |
---|
474 | register windows are that (1) the set of register windows is |
---|
475 | finite, and (2) some registers are shared between adjacent |
---|
476 | registers windows. |
---|
477 | |
---|
478 | Because the set of register windows is finite, it is |
---|
479 | possible to execute enough save instructions without |
---|
480 | corresponding restore's to consume all of the register windows. |
---|
481 | This is easily accomplished in a high level language because |
---|
482 | each subroutine typically performs a save instruction upon |
---|
483 | entry. Thus having a subroutine call depth greater than the |
---|
484 | number of register windows will result in a window overflow |
---|
485 | condition. The window overflow condition generates a trap which |
---|
486 | must be handled in software. The window overflow trap handler |
---|
487 | is responsible for saving the contents of the oldest register |
---|
488 | window on the program stack. |
---|
489 | |
---|
490 | Similarly, the subroutines will eventually complete |
---|
491 | and begin to perform restore's. If the restore results in the |
---|
492 | need for a register window which has previously been written to |
---|
493 | memory as part of an overflow, then a window underflow condition |
---|
494 | results. Just like the window overflow, the window underflow |
---|
495 | condition must be handled in software by a trap handler. The |
---|
496 | window underflow trap handler is responsible for reloading the |
---|
497 | contents of the register window requested by the restore |
---|
498 | instruction from the program stack. |
---|
499 | |
---|
500 | The Window Invalid Mask (wim) and the Current Window |
---|
501 | Pointer (cwp) field in the psr are used in conjunction to manage |
---|
502 | the finite set of register windows and detect the window |
---|
503 | overflow and underflow conditions. The cwp contains the index |
---|
504 | of the register window currently in use. The save instruction |
---|
505 | decrements the cwp modulo the number of register windows. |
---|
506 | Similarly, the restore instruction increments the cwp modulo the |
---|
507 | number of register windows. Each bit in the wim represents |
---|
508 | represents whether a register window contains valid information. |
---|
509 | The value of 0 indicates the register window is valid and 1 |
---|
510 | indicates it is invalid. When a save instruction causes the cwp |
---|
511 | to point to a register window which is marked as invalid, a |
---|
512 | window overflow condition results. Conversely, the restore |
---|
513 | instruction may result in a window underflow condition. |
---|
514 | |
---|
515 | Other than the assumption that a register window is |
---|
516 | always available for trap (i.e. interrupt) handlers, the SPARC |
---|
517 | architecture places no limits on the number of register windows |
---|
518 | simultaneously marked as invalid (i.e. number of bits set in the |
---|
519 | wim). However, RTEMS assumes that only one register window is |
---|
520 | marked invalid at a time (i.e. only one bit set in the wim). |
---|
521 | This makes the maximum possible number of register windows |
---|
522 | available to the user while still meeting the requirement that |
---|
523 | window overflow and underflow conditions can be detected. |
---|
524 | |
---|
525 | The window overflow and window underflow trap |
---|
526 | handlers are a critical part of the run-time environment for a |
---|
527 | SPARC application. The SPARC architectural specification allows |
---|
528 | for the number of register windows to be any power of two less |
---|
529 | than or equal to 32. The most common choice for SPARC |
---|
530 | implementations appears to be 8 register windows. This results |
---|
531 | in the cwp ranging in value from 0 to 7 on most implementations. |
---|
532 | |
---|
533 | |
---|
534 | The second complicating factor is the sharing of |
---|
535 | registers between adjacent register windows. While each |
---|
536 | register window has its own set of local registers, the input |
---|
537 | and output registers are shared between adjacent windows. The |
---|
538 | output registers for register window N are the same as the input |
---|
539 | registers for register window ((N - 1) modulo RW) where RW is |
---|
540 | the number of register windows. An alternative way to think of |
---|
541 | this is to remember how parameters are passed to a subroutine on |
---|
542 | the SPARC. The caller loads values into what are its output |
---|
543 | registers. Then after the callee executes a save instruction, |
---|
544 | those parameters are available in its input registers. This is |
---|
545 | a very efficient way to pass parameters as no data is actually |
---|
546 | moved by the save or restore instructions. |
---|
547 | |
---|
548 | @subsection Call and Return Mechanism |
---|
549 | |
---|
550 | The SPARC architecture supports a simple yet |
---|
551 | effective call and return mechanism. A subroutine is invoked |
---|
552 | via the call (call) instruction. This instruction places the |
---|
553 | return address in the caller's output register 7 (o7). After |
---|
554 | the callee executes a save instruction, this value is available |
---|
555 | in input register 7 (i7) until the corresponding restore |
---|
556 | instruction is executed. |
---|
557 | |
---|
558 | The callee returns to the caller via a jmp to the |
---|
559 | return address. There is a delay slot following this |
---|
560 | instruction which is commonly used to execute a restore |
---|
561 | instruction -- if a register window was allocated by this |
---|
562 | subroutine. |
---|
563 | |
---|
564 | It is important to note that the SPARC subroutine |
---|
565 | call and return mechanism does not automatically save and |
---|
566 | restore any registers. This is accomplished via the save and |
---|
567 | restore instructions which manage the set of registers windows. |
---|
568 | |
---|
569 | In case a floating-point unit is supported, then floating-point return values |
---|
570 | appear in the floating-point registers. Single-precision values occupy %f0; |
---|
571 | double-precision values occupy %f0 and %f1. Otherwise, these are scratch |
---|
572 | registers. Due to this the hardware and software floating-point ABIs are |
---|
573 | incompatible. |
---|
574 | |
---|
575 | @subsection Calling Mechanism |
---|
576 | |
---|
577 | All RTEMS directives are invoked using the regular |
---|
578 | SPARC calling convention via the call instruction. |
---|
579 | |
---|
580 | @subsection Register Usage |
---|
581 | |
---|
582 | As discussed above, the call instruction does not |
---|
583 | automatically save any registers. The save and restore |
---|
584 | instructions are used to allocate and deallocate register |
---|
585 | windows. When a register window is allocated, the new set of |
---|
586 | local registers are available for the exclusive use of the |
---|
587 | subroutine which allocated this register set. |
---|
588 | |
---|
589 | @subsection Parameter Passing |
---|
590 | |
---|
591 | RTEMS assumes that arguments are placed in the |
---|
592 | caller's output registers with the first argument in output |
---|
593 | register 0 (o0), the second argument in output register 1 (o1), |
---|
594 | and so forth. Until the callee executes a save instruction, the |
---|
595 | parameters are still visible in the output registers. After the |
---|
596 | callee executes a save instruction, the parameters are visible |
---|
597 | in the corresponding input registers. The following pseudo-code |
---|
598 | illustrates the typical sequence used to call a RTEMS directive |
---|
599 | with three (3) arguments: |
---|
600 | |
---|
601 | @example |
---|
602 | load third argument into o2 |
---|
603 | load second argument into o1 |
---|
604 | load first argument into o0 |
---|
605 | invoke directive |
---|
606 | @end example |
---|
607 | |
---|
608 | @subsection User-Provided Routines |
---|
609 | |
---|
610 | All user-provided routines invoked by RTEMS, such as |
---|
611 | user extensions, device drivers, and MPCI routines, must also |
---|
612 | adhere to these calling conventions. |
---|
613 | |
---|
614 | @c |
---|
615 | @c COPYRIGHT (c) 1988-2002. |
---|
616 | @c On-Line Applications Research Corporation (OAR). |
---|
617 | @c All rights reserved. |
---|
618 | |
---|
619 | @section Memory Model |
---|
620 | |
---|
621 | |
---|
622 | A processor may support any combination of memory |
---|
623 | models ranging from pure physical addressing to complex demand |
---|
624 | paged virtual memory systems. RTEMS supports a flat memory |
---|
625 | model which ranges contiguously over the processor's allowable |
---|
626 | address space. RTEMS does not support segmentation or virtual |
---|
627 | memory of any kind. The appropriate memory model for RTEMS |
---|
628 | provided by the targeted processor and related characteristics |
---|
629 | of that model are described in this chapter. |
---|
630 | |
---|
631 | @subsection Flat Memory Model |
---|
632 | |
---|
633 | The SPARC architecture supports a flat 32-bit address |
---|
634 | space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 |
---|
635 | gigabytes). Each address is represented by a 32-bit value and |
---|
636 | is byte addressable. The address may be used to reference a |
---|
637 | single byte, half-word (2-bytes), word (4 bytes), or doubleword |
---|
638 | (8 bytes). Memory accesses within this address space are |
---|
639 | performed in big endian fashion by the SPARC. Memory accesses |
---|
640 | which are not properly aligned generate a "memory address not |
---|
641 | aligned" trap (type number 7). The following table lists the |
---|
642 | alignment requirements for a variety of data accesses: |
---|
643 | |
---|
644 | @ifset use-ascii |
---|
645 | @example |
---|
646 | @group |
---|
647 | +--------------+-----------------------+ |
---|
648 | | Data Type | Alignment Requirement | |
---|
649 | +--------------+-----------------------+ |
---|
650 | | byte | 1 | |
---|
651 | | half-word | 2 | |
---|
652 | | word | 4 | |
---|
653 | | doubleword | 8 | |
---|
654 | +--------------+-----------------------+ |
---|
655 | @end group |
---|
656 | @end example |
---|
657 | @end ifset |
---|
658 | |
---|
659 | @ifset use-tex |
---|
660 | @sp 1 |
---|
661 | @tex |
---|
662 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
663 | \vrule\strut#& |
---|
664 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
665 | \vrule#& |
---|
666 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
667 | \vrule#\cr |
---|
668 | \noalign{\hrule} |
---|
669 | &\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} |
---|
670 | &byte&&1&\cr\noalign{\hrule} |
---|
671 | &half-word&&2&\cr\noalign{\hrule} |
---|
672 | &word&&4&\cr\noalign{\hrule} |
---|
673 | &doubleword&&8&\cr\noalign{\hrule} |
---|
674 | }}\hfil} |
---|
675 | @end tex |
---|
676 | @end ifset |
---|
677 | |
---|
678 | @ifset use-html |
---|
679 | @html |
---|
680 | <CENTER> |
---|
681 | <TABLE COLS=2 WIDTH="60%" BORDER=2> |
---|
682 | <TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD> |
---|
683 | <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR> |
---|
684 | <TR><TD ALIGN=center>byte</TD> |
---|
685 | <TD ALIGN=center>1</TD></TR> |
---|
686 | <TR><TD ALIGN=center>half-word</TD> |
---|
687 | <TD ALIGN=center>2</TD></TR> |
---|
688 | <TR><TD ALIGN=center>word</TD> |
---|
689 | <TD ALIGN=center>4</TD></TR> |
---|
690 | <TR><TD ALIGN=center>doubleword</TD> |
---|
691 | <TD ALIGN=center>8</TD></TR> |
---|
692 | </TABLE> |
---|
693 | </CENTER> |
---|
694 | @end html |
---|
695 | @end ifset |
---|
696 | |
---|
697 | Doubleword load and store operations must use a pair |
---|
698 | of registers as their source or destination. This pair of |
---|
699 | registers must be an adjacent pair of registers with the first |
---|
700 | of the pair being even numbered. For example, a valid |
---|
701 | destination for a doubleword load might be input registers 0 and |
---|
702 | 1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE: |
---|
703 | Some assemblers for the SPARC do not generate an error if an odd |
---|
704 | numbered register is specified as the beginning register of the |
---|
705 | pair. In this case, the assembler assumes that what the |
---|
706 | programmer meant was to use the even-odd pair which ends at the |
---|
707 | specified register. This may or may not have been a correct |
---|
708 | assumption.] |
---|
709 | |
---|
710 | RTEMS does not support any SPARC Memory Management |
---|
711 | Units, therefore, virtual memory or segmentation systems |
---|
712 | involving the SPARC are not supported. |
---|
713 | |
---|
714 | @c |
---|
715 | @c COPYRIGHT (c) 1988-2002. |
---|
716 | @c On-Line Applications Research Corporation (OAR). |
---|
717 | @c All rights reserved. |
---|
718 | |
---|
719 | @section Interrupt Processing |
---|
720 | |
---|
721 | |
---|
722 | Different types of processors respond to the |
---|
723 | occurrence of an interrupt in its own unique fashion. In |
---|
724 | addition, each processor type provides a control mechanism to |
---|
725 | allow for the proper handling of an interrupt. The processor |
---|
726 | dependent response to the interrupt modifies the current |
---|
727 | execution state and results in a change in the execution stream. |
---|
728 | Most processors require that an interrupt handler utilize some |
---|
729 | special control mechanisms to return to the normal processing |
---|
730 | stream. Although RTEMS hides many of the processor dependent |
---|
731 | details of interrupt processing, it is important to understand |
---|
732 | how the RTEMS interrupt manager is mapped onto the processor's |
---|
733 | unique architecture. Discussed in this chapter are the SPARC's |
---|
734 | interrupt response and control mechanisms as they pertain to |
---|
735 | RTEMS. |
---|
736 | |
---|
737 | RTEMS and associated documentation uses the terms |
---|
738 | interrupt and vector. In the SPARC architecture, these terms |
---|
739 | correspond to traps and trap type, respectively. The terms will |
---|
740 | be used interchangeably in this manual. |
---|
741 | |
---|
742 | @subsection Synchronous Versus Asynchronous Traps |
---|
743 | |
---|
744 | The SPARC architecture includes two classes of traps: |
---|
745 | synchronous and asynchronous. Asynchronous traps occur when an |
---|
746 | external event interrupts the processor. These traps are not |
---|
747 | associated with any instruction executed by the processor and |
---|
748 | logically occur between instructions. The instruction currently |
---|
749 | in the execute stage of the processor is allowed to complete |
---|
750 | although subsequent instructions are annulled. The return |
---|
751 | address reported by the processor for asynchronous traps is the |
---|
752 | pair of instructions following the current instruction. |
---|
753 | |
---|
754 | Synchronous traps are caused by the actions of an |
---|
755 | instruction. The trap stimulus in this case either occurs |
---|
756 | internally to the processor or is from an external signal that |
---|
757 | was provoked by the instruction. These traps are taken |
---|
758 | immediately and the instruction that caused the trap is aborted |
---|
759 | before any state changes occur in the processor itself. The |
---|
760 | return address reported by the processor for synchronous traps |
---|
761 | is the instruction which caused the trap and the following |
---|
762 | instruction. |
---|
763 | |
---|
764 | @subsection Vectoring of Interrupt Handler |
---|
765 | |
---|
766 | Upon receipt of an interrupt the SPARC automatically |
---|
767 | performs the following actions: |
---|
768 | |
---|
769 | @itemize @bullet |
---|
770 | @item disables traps (sets the ET bit of the psr to 0), |
---|
771 | |
---|
772 | @item the S bit of the psr is copied into the Previous |
---|
773 | Supervisor Mode (PS) bit of the psr, |
---|
774 | |
---|
775 | @item the cwp is decremented by one (modulo the number of |
---|
776 | register windows) to activate a trap window, |
---|
777 | |
---|
778 | @item the PC and nPC are loaded into local register 1 and 2 |
---|
779 | (l0 and l1), |
---|
780 | |
---|
781 | @item the trap type (tt) field of the Trap Base Register (TBR) |
---|
782 | is set to the appropriate value, and |
---|
783 | |
---|
784 | @item if the trap is not a reset, then the PC is written with |
---|
785 | the contents of the TBR and the nPC is written with TBR + 4. If |
---|
786 | the trap is a reset, then the PC is set to zero and the nPC is |
---|
787 | set to 4. |
---|
788 | @end itemize |
---|
789 | |
---|
790 | Trap processing on the SPARC has two features which |
---|
791 | are noticeably different than interrupt processing on other |
---|
792 | architectures. First, the value of psr register in effect |
---|
793 | immediately before the trap occurred is not explicitly saved. |
---|
794 | Instead only reversible alterations are made to it. Second, the |
---|
795 | Processor Interrupt Level (pil) is not set to correspond to that |
---|
796 | of the interrupt being processed. When a trap occurs, ALL |
---|
797 | subsequent traps are disabled. In order to safely invoke a |
---|
798 | subroutine during trap handling, traps must be enabled to allow |
---|
799 | for the possibility of register window overflow and underflow |
---|
800 | traps. |
---|
801 | |
---|
802 | If the interrupt handler was installed as an RTEMS |
---|
803 | interrupt handler, then upon receipt of the interrupt, the |
---|
804 | processor passes control to the RTEMS interrupt handler which |
---|
805 | performs the following actions: |
---|
806 | |
---|
807 | @itemize @bullet |
---|
808 | @item saves the state of the interrupted task on it's stack, |
---|
809 | |
---|
810 | @item insures that a register window is available for |
---|
811 | subsequent traps, |
---|
812 | |
---|
813 | @item if this is the outermost (i.e. non-nested) interrupt, |
---|
814 | then the RTEMS interrupt handler switches from the current stack |
---|
815 | to the interrupt stack, |
---|
816 | |
---|
817 | @item enables traps, |
---|
818 | |
---|
819 | @item invokes the vectors to a user interrupt service routine (ISR). |
---|
820 | @end itemize |
---|
821 | |
---|
822 | Asynchronous interrupts are ignored while traps are |
---|
823 | disabled. Synchronous traps which occur while traps are |
---|
824 | disabled result in the CPU being forced into an error mode. |
---|
825 | |
---|
826 | A nested interrupt is processed similarly with the |
---|
827 | exception that the current stack need not be switched to the |
---|
828 | interrupt stack. |
---|
829 | |
---|
830 | @subsection Traps and Register Windows |
---|
831 | |
---|
832 | One of the register windows must be reserved at all |
---|
833 | times for trap processing. This is critical to the proper |
---|
834 | operation of the trap mechanism in the SPARC architecture. It |
---|
835 | is the responsibility of the trap handler to insure that there |
---|
836 | is a register window available for a subsequent trap before |
---|
837 | re-enabling traps. It is likely that any high level language |
---|
838 | routines invoked by the trap handler (such as a user-provided |
---|
839 | RTEMS interrupt handler) will allocate a new register window. |
---|
840 | The save operation could result in a window overflow trap. This |
---|
841 | trap cannot be correctly processed unless (1) traps are enabled |
---|
842 | and (2) a register window is reserved for traps. Thus, the |
---|
843 | RTEMS interrupt handler insures that a register window is |
---|
844 | available for subsequent traps before enabling traps and |
---|
845 | invoking the user's interrupt handler. |
---|
846 | |
---|
847 | @subsection Interrupt Levels |
---|
848 | |
---|
849 | Sixteen levels (0-15) of interrupt priorities are |
---|
850 | supported by the SPARC architecture with level fifteen (15) |
---|
851 | being the highest priority. Level zero (0) indicates that |
---|
852 | interrupts are fully enabled. Interrupt requests for interrupts |
---|
853 | with priorities less than or equal to the current interrupt mask |
---|
854 | level are ignored. Level fifteen (15) is a non-maskable interrupt |
---|
855 | (NMI), which makes it unsuitable for standard usage since it can |
---|
856 | affect the real-time behaviour by interrupting critical sections |
---|
857 | and spinlocks. Disabling traps stops also the NMI interrupt from |
---|
858 | happening. It can however be used for power-down or other |
---|
859 | critical events. |
---|
860 | |
---|
861 | Although RTEMS supports 256 interrupt levels, the |
---|
862 | SPARC only supports sixteen. RTEMS interrupt levels 0 through |
---|
863 | 15 directly correspond to SPARC processor interrupt levels. All |
---|
864 | other RTEMS interrupt levels are undefined and their behavior is |
---|
865 | unpredictable. |
---|
866 | |
---|
867 | Many LEON SPARC v7/v8 systems features an extended interrupt controller |
---|
868 | which adds an extra step of interrupt decoding to allow handling of |
---|
869 | interrupt 16-31. When such an extended interrupt is generated the CPU |
---|
870 | traps into a specific interrupt trap level 1-14 and software reads out from |
---|
871 | the interrupt controller which extended interrupt source actually caused the |
---|
872 | interrupt. |
---|
873 | |
---|
874 | @subsection Disabling of Interrupts by RTEMS |
---|
875 | |
---|
876 | During the execution of directive calls, critical |
---|
877 | sections of code may be executed. When these sections are |
---|
878 | encountered, RTEMS disables interrupts to level fifteen (15) |
---|
879 | before the execution of the section and restores them to the |
---|
880 | previous level upon completion of the section. RTEMS has been |
---|
881 | optimized to ensure that interrupts are disabled for less than |
---|
882 | RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ |
---|
883 | Mhz ERC32 with zero wait states. |
---|
884 | These numbers will vary based the number of wait states and |
---|
885 | processor speed present on the target board. |
---|
886 | [NOTE: The maximum period with interrupts disabled is hand calculated. This |
---|
887 | calculation was last performed for Release |
---|
888 | RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
---|
889 | |
---|
890 | [NOTE: It is thought that the length of time at which |
---|
891 | the processor interrupt level is elevated to fifteen by RTEMS is |
---|
892 | not anywhere near as long as the length of time ALL traps are |
---|
893 | disabled as part of the "flush all register windows" operation.] |
---|
894 | |
---|
895 | Non-maskable interrupts (NMI) cannot be disabled, and |
---|
896 | ISRs which execute at this level MUST NEVER issue RTEMS system |
---|
897 | calls. If a directive is invoked, unpredictable results may |
---|
898 | occur due to the inability of RTEMS to protect its critical |
---|
899 | sections. However, ISRs that make no system calls may safely |
---|
900 | execute as non-maskable interrupts. |
---|
901 | |
---|
902 | Interrupts are disabled or enabled by performing a system call |
---|
903 | to the Operating System reserved software traps 9 |
---|
904 | (SPARC_SWTRAP_IRQDIS) or 10 (SPARC_SWTRAP_IRQDIS). The trap is |
---|
905 | generated by the software trap (Ticc) instruction or indirectly |
---|
906 | by calling sparc_disable_interrupts() or sparc_enable_interrupts() |
---|
907 | functions. Disabling interrupts return the previous interrupt level |
---|
908 | (on trap entry) in register G1 and sets PSR.PIL to 15 to disable |
---|
909 | all maskable interrupts. The interrupt level can be restored by |
---|
910 | trapping into the enable interrupt handler with G1 containing the |
---|
911 | new interrupt level. |
---|
912 | |
---|
913 | @subsection Interrupt Stack |
---|
914 | |
---|
915 | The SPARC architecture does not provide for a |
---|
916 | dedicated interrupt stack. Thus by default, trap handlers would |
---|
917 | execute on the stack of the RTEMS task which they interrupted. |
---|
918 | This artificially inflates the stack requirements for each task |
---|
919 | since EVERY task stack would have to include enough space to |
---|
920 | account for the worst case interrupt stack requirements in |
---|
921 | addition to it's own worst case usage. RTEMS addresses this |
---|
922 | problem on the SPARC by providing a dedicated interrupt stack |
---|
923 | managed by software. |
---|
924 | |
---|
925 | During system initialization, RTEMS allocates the |
---|
926 | interrupt stack from the Workspace Area. The amount of memory |
---|
927 | allocated for the interrupt stack is determined by the |
---|
928 | interrupt_stack_size field in the CPU Configuration Table. As |
---|
929 | part of processing a non-nested interrupt, RTEMS will switch to |
---|
930 | the interrupt stack before invoking the installed handler. |
---|
931 | |
---|
932 | @c |
---|
933 | @c COPYRIGHT (c) 1988-2002. |
---|
934 | @c On-Line Applications Research Corporation (OAR). |
---|
935 | @c All rights reserved. |
---|
936 | |
---|
937 | @section Default Fatal Error Processing |
---|
938 | |
---|
939 | |
---|
940 | Upon detection of a fatal error by either the |
---|
941 | application or RTEMS the fatal error manager is invoked. The |
---|
942 | fatal error manager will invoke the user-supplied fatal error |
---|
943 | handlers. If no user-supplied handlers are configured, the |
---|
944 | RTEMS provided default fatal error handler is invoked. If the |
---|
945 | user-supplied fatal error handlers return to the executive the |
---|
946 | default fatal error handler is then invoked. This chapter |
---|
947 | describes the precise operations of the default fatal error |
---|
948 | handler. |
---|
949 | |
---|
950 | @subsection Default Fatal Error Handler Operations |
---|
951 | |
---|
952 | The default fatal error handler which is invoked by |
---|
953 | the fatal_error_occurred directive when there is no user handler |
---|
954 | configured or the user handler returns control to RTEMS. |
---|
955 | |
---|
956 | If the BSP has been configured with @code{BSP_POWER_DOWN_AT_FATAL_HALT} |
---|
957 | set to true, the default handler will disable interrupts |
---|
958 | and enter power down mode. If power down mode is not available, |
---|
959 | it goes into an infinite loop to simulate a halt processor instruction. |
---|
960 | |
---|
961 | If @code{BSP_POWER_DOWN_AT_FATAL_HALT} is set to false, the default |
---|
962 | handler will place the value @code{1} in register @code{g1}, the |
---|
963 | error source in register @code{g2}, and the error code in register |
---|
964 | @code{g3}. It will then generate a system error which will |
---|
965 | hand over control to the debugger, simulator, etc. |
---|
966 | |
---|
967 | @section Thread-Local Storage |
---|
968 | |
---|
969 | Thread-local storage is supported. |
---|
970 | |
---|
971 | @c |
---|
972 | @c COPYRIGHT (c) 1988-2002. |
---|
973 | @c On-Line Applications Research Corporation (OAR). |
---|
974 | @c All rights reserved. |
---|
975 | |
---|
976 | @section Board Support Packages |
---|
977 | |
---|
978 | |
---|
979 | An RTEMS Board Support Package (BSP) must be designed |
---|
980 | to support a particular processor and target board combination. |
---|
981 | This chapter presents a discussion of SPARC specific BSP issues. |
---|
982 | For more information on developing a BSP, refer to the chapter |
---|
983 | titled Board Support Packages in the RTEMS |
---|
984 | Applications User's Guide. |
---|
985 | |
---|
986 | @subsection System Reset |
---|
987 | |
---|
988 | An RTEMS based application is initiated or |
---|
989 | re-initiated when the SPARC processor is reset. When the SPARC |
---|
990 | is reset, the processor performs the following actions: |
---|
991 | |
---|
992 | @itemize @bullet |
---|
993 | @item the enable trap (ET) of the psr is set to 0 to disable |
---|
994 | traps, |
---|
995 | |
---|
996 | @item the supervisor bit (S) of the psr is set to 1 to enter |
---|
997 | supervisor mode, and |
---|
998 | |
---|
999 | @item the PC is set 0 and the nPC is set to 4. |
---|
1000 | @end itemize |
---|
1001 | |
---|
1002 | The processor then begins to execute the code at |
---|
1003 | location 0. It is important to note that all fields in the psr |
---|
1004 | are not explicitly set by the above steps and all other |
---|
1005 | registers retain their value from the previous execution mode. |
---|
1006 | This is true even of the Trap Base Register (TBR) whose contents |
---|
1007 | reflect the last trap which occurred before the reset. |
---|
1008 | |
---|
1009 | @subsection Processor Initialization |
---|
1010 | |
---|
1011 | It is the responsibility of the application's |
---|
1012 | initialization code to initialize the TBR and install trap |
---|
1013 | handlers for at least the register window overflow and register |
---|
1014 | window underflow conditions. Traps should be enabled before |
---|
1015 | invoking any subroutines to allow for register window |
---|
1016 | management. However, interrupts should be disabled by setting |
---|
1017 | the Processor Interrupt Level (pil) field of the psr to 15. |
---|
1018 | RTEMS installs it's own Trap Table as part of initialization |
---|
1019 | which is initialized with the contents of the Trap Table in |
---|
1020 | place when the @code{rtems_initialize_executive} directive was invoked. |
---|
1021 | Upon completion of executive initialization, interrupts are |
---|
1022 | enabled. |
---|
1023 | |
---|
1024 | If this SPARC implementation supports on-chip caching |
---|
1025 | and this is to be utilized, then it should be enabled during the |
---|
1026 | reset application initialization code. |
---|
1027 | |
---|
1028 | In addition to the requirements described in the |
---|
1029 | Board Support Packages chapter of the C |
---|
1030 | Applications Users Manual for the reset code |
---|
1031 | which is executed before the call to |
---|
1032 | @code{rtems_initialize_executive}, the SPARC version has the following |
---|
1033 | specific requirements: |
---|
1034 | |
---|
1035 | @itemize @bullet |
---|
1036 | @item Must leave the S bit of the status register set so that |
---|
1037 | the SPARC remains in the supervisor state. |
---|
1038 | |
---|
1039 | @item Must set stack pointer (sp) such that a minimum stack |
---|
1040 | size of MINIMUM_STACK_SIZE bytes is provided for the |
---|
1041 | @code{rtems_initialize_executive} directive. |
---|
1042 | |
---|
1043 | @item Must disable all external interrupts (i.e. set the pil |
---|
1044 | to 15). |
---|
1045 | |
---|
1046 | @item Must enable traps so window overflow and underflow |
---|
1047 | conditions can be properly handled. |
---|
1048 | |
---|
1049 | @item Must initialize the SPARC's initial trap table with at |
---|
1050 | least trap handlers for register window overflow and register |
---|
1051 | window underflow. |
---|
1052 | @end itemize |
---|