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