Changeset 03c8223 in rtems
- Timestamp:
- Jul 31, 1997, 6:45:32 PM (24 years ago)
- Branches:
- 4.10, 4.11, 4.8, 4.9, 5, master
- Children:
- db91520
- Parents:
- c3fec1c
- Location:
- doc/supplements/powerpc
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/supplements/powerpc/bsp.t
rc3fec1c r03c8223 26 26 An RTEMS Board Support Package (BSP) must be designed 27 27 to support a particular processor and target board combination. 28 This chapter presents a discussion of SPARC specific BSP issues.28 This chapter presents a discussion of PowerPC specific BSP issues. 29 29 For more information on developing a BSP, refer to the chapter 30 30 titled Board Support Packages in the RTEMS … … 37 37 38 38 An RTEMS based application is initiated or 39 re-initiated when the SPARC processor is reset. When the SPARC39 re-initiated when the PowerPC processor is reset. When the PowerPC 40 40 is reset, the processor performs the following actions: 41 41 42 42 @itemize @bullet 43 @item the enable trap (ET) of the psr is set to 0 to disable 44 traps, 43 @item TBD 45 44 46 @item the supervisor bit (S) of the psr is set to 1 to enter 47 supervisor mode, and 45 @item TBD 48 46 49 @item the PC is set 0 and the nPC is set to 4.47 @item TBD 50 48 @end itemize 51 49 52 The processor then begins to execute the code at 53 location 0. It is important to note that all fields in the psr 50 The processor then begins to execute the code at location 0x00100. 51 By using the SRR1 bit corresponding to MSR[RI] the softwere may 52 distinguish between power-on reset and other types of system resets. 53 54 It is important to note that all fields in the psr 54 55 are not explicitly set by the above steps and all other 55 56 registers retain their value from the previous execution mode. … … 80 81 81 82 In addition to the requirements described in the 82 Board Support Packages chapter of the @value{ RTEMS-LANGUAGE}83 Board Support Packages chapter of the @value{LANGUAGE} 83 84 Applications User's Manual for the reset code 84 85 which is executed before the call to -
doc/supplements/powerpc/bsp.texi
rc3fec1c r03c8223 26 26 An RTEMS Board Support Package (BSP) must be designed 27 27 to support a particular processor and target board combination. 28 This chapter presents a discussion of SPARC specific BSP issues.28 This chapter presents a discussion of PowerPC specific BSP issues. 29 29 For more information on developing a BSP, refer to the chapter 30 30 titled Board Support Packages in the RTEMS … … 37 37 38 38 An RTEMS based application is initiated or 39 re-initiated when the SPARC processor is reset. When the SPARC39 re-initiated when the PowerPC processor is reset. When the PowerPC 40 40 is reset, the processor performs the following actions: 41 41 42 42 @itemize @bullet 43 @item the enable trap (ET) of the psr is set to 0 to disable 44 traps, 43 @item TBD 45 44 46 @item the supervisor bit (S) of the psr is set to 1 to enter 47 supervisor mode, and 45 @item TBD 48 46 49 @item the PC is set 0 and the nPC is set to 4.47 @item TBD 50 48 @end itemize 51 49 52 The processor then begins to execute the code at 53 location 0. It is important to note that all fields in the psr 50 The processor then begins to execute the code at location 0x00100. 51 By using the SRR1 bit corresponding to MSR[RI] the softwere may 52 distinguish between power-on reset and other types of system resets. 53 54 It is important to note that all fields in the psr 54 55 are not explicitly set by the above steps and all other 55 56 registers retain their value from the previous execution mode. … … 80 81 81 82 In addition to the requirements described in the 82 Board Support Packages chapter of the @value{ RTEMS-LANGUAGE}83 Board Support Packages chapter of the @value{LANGUAGE} 83 84 Applications User's Manual for the reset code 84 85 which is executed before the call to -
doc/supplements/powerpc/cpumodel.t
rc3fec1c r03c8223 57 57 * CPU Model Dependent Features Critical Interrupts:: 58 58 * CPU Model Dependent Features MSR Values:: 59 * CPU Model Dependent Features FPU Status Control Register Values::60 59 * CPU Model Dependent Features Use Multiword Load/Store Instructions:: 61 60 * CPU Model Dependent Features Instruction Cache Size:: 62 61 * CPU Model Dependent Features Data Cache Size:: 62 * CPU Model Dependent Features Debug Model:: 63 * CPU Model Dependent Features Low Power Model:: 63 64 @end menu 64 65 @end ifinfo … … 100 101 @subsection Floating Point Unit 101 102 102 The macro PPC_HAS_FPU is set to 1 to indicate that 103 this CPU model has a hardware floating point unit and 0 104 otherwise. 103 The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model 104 has a hardware floating point unit and 0 otherwise. 105 105 106 106 @ifinfo … … 109 109 @subsection Alignment 110 110 111 The macro PPC_ALIGNMENT is set to 111 The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment 112 requirement for data types on a byte boundary. This value is used 113 to derive the alignment restrictions for memory allocated from 114 regions and partitions. 112 115 113 116 @ifinfo … … 116 119 @subsection Cache Alignment 117 120 118 The macro PPC_CACHE_ALIGNMENT is set to 119 120 Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the 121 The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is 122 used to align the entry point of critical routines so that as much code 123 as possible can be retrieved with the initial read into cache. This 124 is done for the interrupt handler as well as the context switch routines. 125 126 In addition, the "shortcut" data structure used by the PowerPC implementation 127 to ease access to data elements frequently accessed by RTEMS routines 128 implemented in assembly language is aligned using this value. 121 129 122 130 @ifinfo … … 125 133 @subsection Maximum Interrupts 126 134 127 The macro PPC_INTERRUPT_MAX is set to 135 The macro PPC_INTERRUPT_MAX is set to the number of exception sources 136 supported by this PowerPC model. 128 137 129 138 @ifinfo … … 132 141 @subsection Has Double Precision Floating Point 133 142 134 The macro PPC_HAS_DOUBLE is set to 143 The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model 144 has support for double precision floating point numbers. This is 145 important because the floating point registers need only be four bytes 146 wide (not eight) if double precision is not supported. 135 147 136 148 @ifinfo … … 139 151 @subsection Critical Interrupts 140 152 141 The macro PPC_HAS_RFCI is set to 142 143 @ifinfo 144 @node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags 153 The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model 154 has the Critical Interrupt capability as defined by the IBM 403 models. 155 156 @ifinfo 157 @node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags 145 158 @end ifinfo 146 159 @subsection MSR Values 147 160 148 The macro PPC_MSR_DISABLE_MASK is set to149 150 161 The macro PPC_MSR_INITIAL is set to 151 162 152 The macro PPC_MSR_0 is set to 153 154 The macro PPC_MSR_1 is set to 155 156 The macro PPC_MSR_2 is set to 157 158 The macro PPC_MSR_3 is set to 159 160 @ifinfo 161 @node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags 162 @end ifinfo 163 @subsection FPU Status Control Register Values 164 165 The macro PPC_INIT_FPSCR is set to 166 167 @ifinfo 168 @node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags 163 @ifinfo 164 @node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags 169 165 @end ifinfo 170 166 @subsection Use Multiword Load/Store Instructions 171 167 172 The macro PPC_USE_MULTIPLE is set to 168 The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and 169 store instructions should be used to perform context switch operations. 170 The relative efficiency of multiword load and store instructions versus 171 an equivalent set of single word load and store instructions varies based 172 upon the PowerPC model. 173 173 174 174 @ifinfo … … 177 177 @subsection Instruction Cache Size 178 178 179 The macro PPC_I_CACHE is set to 180 181 @ifinfo 182 @node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags179 The macro PPC_I_CACHE is set to the size in bytes of the instruction cache. 180 181 @ifinfo 182 @node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Debug Model, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags 183 183 @end ifinfo 184 184 @subsection Data Cache Size 185 185 186 The macro PPC_D_CACHE is set to 187 188 @ifinfo 189 @node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features 186 The macro PPC_D_CACHE is set to the size in bytes of the data cache. 187 188 @ifinfo 189 @node CPU Model Dependent Features Debug Model, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Feature Flags 190 @end ifinfo 191 @subsection Debug Model 192 193 The macro PPC_DEBUG_MODEL 194 195 @table @b 196 197 @item @code{PPC_DEBUG_MODEL_STANDARD} 198 indicates XXX 199 200 @item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY} 201 indicates XXX 202 203 @item @code{PPC_DEBUG_MODEL_IBM4xx} 204 indicates XXX 205 206 @end table 207 208 @ifinfo 209 @node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags 210 @end ifinfo 211 @subsection Low Power Model 212 213 The macro PPC_LOW_POWER_MODE 214 215 @table @b 216 217 @item @code{PPC_LOW_POWER_MODE_NONE} 218 indicates XXX 219 220 @item @code{PPC_LOW_POWER_MODE_STANDARD} 221 indicates XXX 222 223 @end table 224 225 226 @ifinfo 227 @node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features 190 228 @end ifinfo 191 229 @section CPU Model Implementation Notes -
doc/supplements/powerpc/cpumodel.texi
rc3fec1c r03c8223 57 57 * CPU Model Dependent Features Critical Interrupts:: 58 58 * CPU Model Dependent Features MSR Values:: 59 * CPU Model Dependent Features FPU Status Control Register Values::60 59 * CPU Model Dependent Features Use Multiword Load/Store Instructions:: 61 60 * CPU Model Dependent Features Instruction Cache Size:: 62 61 * CPU Model Dependent Features Data Cache Size:: 62 * CPU Model Dependent Features Debug Model:: 63 * CPU Model Dependent Features Low Power Model:: 63 64 @end menu 64 65 @end ifinfo … … 100 101 @subsection Floating Point Unit 101 102 102 The macro PPC_HAS_FPU is set to 1 to indicate that 103 this CPU model has a hardware floating point unit and 0 104 otherwise. 103 The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model 104 has a hardware floating point unit and 0 otherwise. 105 105 106 106 @ifinfo … … 109 109 @subsection Alignment 110 110 111 The macro PPC_ALIGNMENT is set to 111 The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment 112 requirement for data types on a byte boundary. This value is used 113 to derive the alignment restrictions for memory allocated from 114 regions and partitions. 112 115 113 116 @ifinfo … … 116 119 @subsection Cache Alignment 117 120 118 The macro PPC_CACHE_ALIGNMENT is set to 119 120 Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the 121 The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is 122 used to align the entry point of critical routines so that as much code 123 as possible can be retrieved with the initial read into cache. This 124 is done for the interrupt handler as well as the context switch routines. 125 126 In addition, the "shortcut" data structure used by the PowerPC implementation 127 to ease access to data elements frequently accessed by RTEMS routines 128 implemented in assembly language is aligned using this value. 121 129 122 130 @ifinfo … … 125 133 @subsection Maximum Interrupts 126 134 127 The macro PPC_INTERRUPT_MAX is set to 135 The macro PPC_INTERRUPT_MAX is set to the number of exception sources 136 supported by this PowerPC model. 128 137 129 138 @ifinfo … … 132 141 @subsection Has Double Precision Floating Point 133 142 134 The macro PPC_HAS_DOUBLE is set to 143 The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model 144 has support for double precision floating point numbers. This is 145 important because the floating point registers need only be four bytes 146 wide (not eight) if double precision is not supported. 135 147 136 148 @ifinfo … … 139 151 @subsection Critical Interrupts 140 152 141 The macro PPC_HAS_RFCI is set to 142 143 @ifinfo 144 @node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags 153 The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model 154 has the Critical Interrupt capability as defined by the IBM 403 models. 155 156 @ifinfo 157 @node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags 145 158 @end ifinfo 146 159 @subsection MSR Values 147 160 148 The macro PPC_MSR_DISABLE_MASK is set to149 150 161 The macro PPC_MSR_INITIAL is set to 151 162 152 The macro PPC_MSR_0 is set to 153 154 The macro PPC_MSR_1 is set to 155 156 The macro PPC_MSR_2 is set to 157 158 The macro PPC_MSR_3 is set to 159 160 @ifinfo 161 @node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags 162 @end ifinfo 163 @subsection FPU Status Control Register Values 164 165 The macro PPC_INIT_FPSCR is set to 166 167 @ifinfo 168 @node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags 163 @ifinfo 164 @node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags 169 165 @end ifinfo 170 166 @subsection Use Multiword Load/Store Instructions 171 167 172 The macro PPC_USE_MULTIPLE is set to 168 The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and 169 store instructions should be used to perform context switch operations. 170 The relative efficiency of multiword load and store instructions versus 171 an equivalent set of single word load and store instructions varies based 172 upon the PowerPC model. 173 173 174 174 @ifinfo … … 177 177 @subsection Instruction Cache Size 178 178 179 The macro PPC_I_CACHE is set to 180 181 @ifinfo 182 @node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags179 The macro PPC_I_CACHE is set to the size in bytes of the instruction cache. 180 181 @ifinfo 182 @node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Debug Model, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags 183 183 @end ifinfo 184 184 @subsection Data Cache Size 185 185 186 The macro PPC_D_CACHE is set to 187 188 @ifinfo 189 @node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features 186 The macro PPC_D_CACHE is set to the size in bytes of the data cache. 187 188 @ifinfo 189 @node CPU Model Dependent Features Debug Model, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Feature Flags 190 @end ifinfo 191 @subsection Debug Model 192 193 The macro PPC_DEBUG_MODEL 194 195 @table @b 196 197 @item @code{PPC_DEBUG_MODEL_STANDARD} 198 indicates XXX 199 200 @item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY} 201 indicates XXX 202 203 @item @code{PPC_DEBUG_MODEL_IBM4xx} 204 indicates XXX 205 206 @end table 207 208 @ifinfo 209 @node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags 210 @end ifinfo 211 @subsection Low Power Model 212 213 The macro PPC_LOW_POWER_MODE 214 215 @table @b 216 217 @item @code{PPC_LOW_POWER_MODE_NONE} 218 indicates XXX 219 220 @item @code{PPC_LOW_POWER_MODE_STANDARD} 221 indicates XXX 222 223 @end table 224 225 226 @ifinfo 227 @node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features 190 228 @end ifinfo 191 229 @section CPU Model Implementation Notes -
doc/supplements/powerpc/intr.t
rc3fec1c r03c8223 14 14 @menu 15 15 * Interrupt Processing Introduction:: 16 * Interrupt Processing Synchronous Versus Asynchronous Traps::16 * Interrupt Processing Synchronous Versus Asynchronous Exceptions:: 17 17 * Interrupt Processing Vectoring of Interrupt Handler:: 18 * Interrupt Processing Traps and Register Windows::19 18 * Interrupt Processing Interrupt Levels:: 20 19 * Interrupt Processing Disabling of Interrupts by RTEMS:: … … 24 23 25 24 @ifinfo 26 @node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing25 @node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing 27 26 @end ifinfo 28 27 @section Introduction … … 39 38 details of interrupt processing, it is important to understand 40 39 how the RTEMS interrupt manager is mapped onto the processor's 41 unique architecture. Discussed in this chapter are the SPARC's40 unique architecture. Discussed in this chapter are the PPC's 42 41 interrupt response and control mechanisms as they pertain to 43 42 RTEMS. 44 43 45 44 RTEMS and associated documentation uses the terms 46 interrupt and vector. In the SPARC architecture, these terms47 correspond to traps and trap type, respectively. The terms will45 interrupt and vector. In the PPC architecture, these terms 46 correspond to exception and exception handler, respectively. The terms will 48 47 be used interchangeably in this manual. 49 48 50 49 @ifinfo 51 @node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing50 @node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing 52 51 @end ifinfo 53 @section Synchronous Versus Asynchronous Traps52 @section Synchronous Versus Asynchronous Exceptions 54 53 55 The SPARC architecture includes two classes of traps: 56 synchronous and asynchronous. Asynchronous traps occur when an 57 external event interrupts the processor. These traps are not 58 associated with any instruction executed by the processor and 59 logically occur between instructions. The instruction currently 60 in the execute stage of the processor is allowed to complete 61 although subsequent instructions are annulled. The return 62 address reported by the processor for asynchronous traps is the 63 pair of instructions following the current instruction. 54 In the PPC architecture exceptions can be either precise or 55 imprecise and either synchronous or asynchronous. Asynchronous 56 exceptions occur when an external event interrupts the processor. 57 Synchronous exceptions are caused by the actions of an 58 instruction. During an exception SRR0 is used to calculate where 59 instruction processing should resume. All instructions prior to 60 the resume instruction will have completed execution. SRR1 is used to 61 store the machine status. 64 62 65 Synchronous traps are caused by the actions of an 66 instruction. The trap stimulus in this case either occurs 67 internally to the processor or is from an external signal that 68 was provoked by the instruction. These traps are taken 69 immediately and the instruction that caused the trap is aborted 70 before any state changes occur in the processor itself. The 71 return address reported by the processor for synchronous traps 72 is the instruction which caused the trap and the following 73 instruction. 63 There are two asynchronous nonmaskable, highest-priority exceptions 64 system reset and machine check. There are two asynchrononous maskable 65 low-priority exceptions external interrupt and decrementer. Nonmaskable 66 execptions are never delayed, therefore if two nonmaskable, asynchronous 67 exceptions occur in immediate succession, the state information saved by 68 the first exception may be overwritten when the subsequent exception occurs. 69 70 The PowerPC arcitecure defines one imprecise exception, the imprecise 71 floating point enabled exception. All other synchronous exceptions are 72 precise. The synchronization occuring during asynchronous precise 73 exceptions conforms to the requirements for context synchronization. 74 74 75 75 @ifinfo 76 @node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing76 @node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Levels, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing 77 77 @end ifinfo 78 78 @section Vectoring of Interrupt Handler 79 79 80 Upon receipt of an interrupt the SPARCautomatically80 Upon determining that an exception can be taken the PPC automatically 81 81 performs the following actions: 82 82 83 83 @itemize @bullet 84 @item disables traps (sets the ET bit of the psr to 0),84 @item an instruction address is loaded into SRR0 85 85 86 @item the S bit of the psr is copied into the Previous87 Supervisor Mode (PS) bit of the psr, 86 @item bits 33-36 and 42-47 of SRR1 are loaded with information 87 specific to the exception. 88 88 89 @item the cwp is decremented by one (modulo the number of90 register windows) to activate a trap window, 89 @item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding 90 bits from the MSR. 91 91 92 @item the PC and nPC are loaded into local register 1 and 2 93 (l0 and l1), 92 @item the MSR is set based upon the exception type. 94 93 95 @item the trap type (tt) field of the Trap Base Register (TBR) 96 is set to the appropriate value, and 94 @item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type. 97 95 98 @item if the trap is not a reset, then the PC is written with99 the contents of the TBR and the nPC is written with TBR + 4. If100 the trap is a reset, then the PC is set to zero and the nPC is101 set to 4.102 96 @end itemize 103 97 104 Trap processing on the SPARC has two features which105 are noticeably different than interrupt processing on other106 architectures. First, the value of psr register in effect107 immediately before the trap occurred is not explicitly saved.108 Instead only reversible alterations are made to it. Second, the109 Processor Interrupt Level (pil) is not set to correspond to that110 of the interrupt being processed. When a trap occurs, ALL111 subsequent traps are disabled. In order to safely invoke a112 subroutine during trap handling, traps must be enabled to allow113 for the possibility of register window overflow and underflow114 traps.115 98 116 99 If the interrupt handler was installed as an RTEMS … … 123 106 124 107 @item insures that a register window is available for 125 subsequent traps,108 subsequent exceptions, 126 109 127 110 @item if this is the outermost (i.e. non-nested) interrupt, … … 129 112 to the interrupt stack, 130 113 131 @item enables traps,114 @item enables exceptions, 132 115 133 116 @item invokes the vectors to a user interrupt service routine (ISR). 134 117 @end itemize 135 118 136 Asynchronous interrupts are ignored while traps are137 disabled. Synchronous traps which occur while trapsare119 Asynchronous interrupts are ignored while exceptions are 120 disabled. Synchronous interrupts which occur while are 138 121 disabled result in the CPU being forced into an error mode. 139 122 … … 143 126 144 127 @ifinfo 145 @node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing 146 @end ifinfo 147 @section Traps and Register Windows 148 149 One of the register windows must be reserved at all 150 times for trap processing. This is critical to the proper 151 operation of the trap mechanism in the SPARC architecture. It 152 is the responsibility of the trap handler to insure that there 153 is a register window available for a subsequent trap before 154 re-enabling traps. It is likely that any high level language 155 routines invoked by the trap handler (such as a user-provided 156 RTEMS interrupt handler) will allocate a new register window. 157 The save operation could result in a window overflow trap. This 158 trap cannot be correctly processed unless (1) traps are enabled 159 and (2) a register window is reserved for traps. Thus, the 160 RTEMS interrupt handler insures that a register window is 161 available for subsequent traps before enabling traps and 162 invoking the user's interrupt handler. 163 164 @ifinfo 165 @node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing 128 @node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing 166 129 @end ifinfo 167 130 @section Interrupt Levels 168 131 169 Sixteen levels (0-15) of interrupt priorities are170 supported by the SPARC architecture with level fifteen (15)132 TBD levels (0-TBD) of interrupt priorities are 133 supported by the PowerPC architecture with level TBD (TBD) 171 134 being the highest priority. Level zero (0) indicates that 172 135 interrupts are fully enabled. Interrupt requests for interrupts … … 174 137 level are ignored. 175 138 176 Although RTEMS supports 256 interrupt levels, the 177 SPARC only supports sixteen. RTEMS interrupt levels 0 through 178 15 directly correspond to SPARC processor interrupt levels. All 179 other RTEMS interrupt levels are undefined and their behavior is 139 TBD 140 All other RTEMS interrupt levels are undefined and their behavior is 180 141 unpredictable. 181 142 … … 187 148 During the execution of directive calls, critical 188 149 sections of code may be executed. When these sections are 189 encountered, RTEMS disables interrupts to level seven (15)150 encountered, RTEMS disables interrupts to level TBD (TBD) 190 151 before the execution of this section and restores them to the 191 152 previous level upon completion of the section. RTEMS has been 192 153 optimized to insure that interrupts are disabled for less than 193 RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ194 Mhz PowerPC 603e with zero wait states. 195 These numbers will vary based the number of wait states and 196 processor speed present on the target board.154 RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 155 RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e with zero 156 wait states. These numbers will vary based the number of wait 157 states and processor speed present on the target board. 197 158 [NOTE: The maximum period with interrupts disabled is hand calculated. This 198 159 calculation was last performed for Release … … 201 162 [NOTE: It is thought that the length of time at which 202 163 the processor interrupt level is elevated to fifteen by RTEMS is 203 not anywhere near as long as the length of time ALL traps are164 not anywhere near as long as the length of time ALL exceptions are 204 165 disabled as part of the "flush all register windows" operation.] 205 166 … … 216 177 @section Interrupt Stack 217 178 218 The SPARC architecture does not provide for a219 dedicated interrupt stack. Thus by default, traphandlers would179 The PowerPC architecture does not provide for a 180 dedicated interrupt stack. Thus by default, exception handlers would 220 181 execute on the stack of the RTEMS task which they interrupted. 221 182 This artificially inflates the stack requirements for each task … … 223 184 account for the worst case interrupt stack requirements in 224 185 addition to it's own worst case usage. RTEMS addresses this 225 problem on the SPARC by providing a dedicated interrupt stack186 problem on the PowerPC by providing a dedicated interrupt stack 226 187 managed by software. 227 188 … … 233 194 the interrupt stack before invoking the installed handler. 234 195 196 197 -
doc/supplements/powerpc/intr_NOTIMES.t
rc3fec1c r03c8223 14 14 @menu 15 15 * Interrupt Processing Introduction:: 16 * Interrupt Processing Synchronous Versus Asynchronous Traps::16 * Interrupt Processing Synchronous Versus Asynchronous Exceptions:: 17 17 * Interrupt Processing Vectoring of Interrupt Handler:: 18 * Interrupt Processing Traps and Register Windows::19 18 * Interrupt Processing Interrupt Levels:: 20 19 * Interrupt Processing Disabling of Interrupts by RTEMS:: … … 24 23 25 24 @ifinfo 26 @node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing25 @node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing 27 26 @end ifinfo 28 27 @section Introduction … … 39 38 details of interrupt processing, it is important to understand 40 39 how the RTEMS interrupt manager is mapped onto the processor's 41 unique architecture. Discussed in this chapter are the SPARC's40 unique architecture. Discussed in this chapter are the PPC's 42 41 interrupt response and control mechanisms as they pertain to 43 42 RTEMS. 44 43 45 44 RTEMS and associated documentation uses the terms 46 interrupt and vector. In the SPARC architecture, these terms47 correspond to traps and trap type, respectively. The terms will45 interrupt and vector. In the PPC architecture, these terms 46 correspond to exception and exception handler, respectively. The terms will 48 47 be used interchangeably in this manual. 49 48 50 49 @ifinfo 51 @node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing50 @node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing 52 51 @end ifinfo 53 @section Synchronous Versus Asynchronous Traps52 @section Synchronous Versus Asynchronous Exceptions 54 53 55 The SPARC architecture includes two classes of traps: 56 synchronous and asynchronous. Asynchronous traps occur when an 57 external event interrupts the processor. These traps are not 58 associated with any instruction executed by the processor and 59 logically occur between instructions. The instruction currently 60 in the execute stage of the processor is allowed to complete 61 although subsequent instructions are annulled. The return 62 address reported by the processor for asynchronous traps is the 63 pair of instructions following the current instruction. 54 In the PPC architecture exceptions can be either precise or 55 imprecise and either synchronous or asynchronous. Asynchronous 56 exceptions occur when an external event interrupts the processor. 57 Synchronous exceptions are caused by the actions of an 58 instruction. During an exception SRR0 is used to calculate where 59 instruction processing should resume. All instructions prior to 60 the resume instruction will have completed execution. SRR1 is used to 61 store the machine status. 64 62 65 Synchronous traps are caused by the actions of an 66 instruction. The trap stimulus in this case either occurs 67 internally to the processor or is from an external signal that 68 was provoked by the instruction. These traps are taken 69 immediately and the instruction that caused the trap is aborted 70 before any state changes occur in the processor itself. The 71 return address reported by the processor for synchronous traps 72 is the instruction which caused the trap and the following 73 instruction. 63 There are two asynchronous nonmaskable, highest-priority exceptions 64 system reset and machine check. There are two asynchrononous maskable 65 low-priority exceptions external interrupt and decrementer. Nonmaskable 66 execptions are never delayed, therefore if two nonmaskable, asynchronous 67 exceptions occur in immediate succession, the state information saved by 68 the first exception may be overwritten when the subsequent exception occurs. 69 70 The PowerPC arcitecure defines one imprecise exception, the imprecise 71 floating point enabled exception. All other synchronous exceptions are 72 precise. The synchronization occuring during asynchronous precise 73 exceptions conforms to the requirements for context synchronization. 74 74 75 75 @ifinfo 76 @node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing76 @node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Levels, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing 77 77 @end ifinfo 78 78 @section Vectoring of Interrupt Handler 79 79 80 Upon receipt of an interrupt the SPARCautomatically80 Upon determining that an exception can be taken the PPC automatically 81 81 performs the following actions: 82 82 83 83 @itemize @bullet 84 @item disables traps (sets the ET bit of the psr to 0),84 @item an instruction address is loaded into SRR0 85 85 86 @item the S bit of the psr is copied into the Previous87 Supervisor Mode (PS) bit of the psr, 86 @item bits 33-36 and 42-47 of SRR1 are loaded with information 87 specific to the exception. 88 88 89 @item the cwp is decremented by one (modulo the number of90 register windows) to activate a trap window, 89 @item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding 90 bits from the MSR. 91 91 92 @item the PC and nPC are loaded into local register 1 and 2 93 (l0 and l1), 92 @item the MSR is set based upon the exception type. 94 93 95 @item the trap type (tt) field of the Trap Base Register (TBR) 96 is set to the appropriate value, and 94 @item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type. 97 95 98 @item if the trap is not a reset, then the PC is written with99 the contents of the TBR and the nPC is written with TBR + 4. If100 the trap is a reset, then the PC is set to zero and the nPC is101 set to 4.102 96 @end itemize 103 97 104 Trap processing on the SPARC has two features which105 are noticeably different than interrupt processing on other106 architectures. First, the value of psr register in effect107 immediately before the trap occurred is not explicitly saved.108 Instead only reversible alterations are made to it. Second, the109 Processor Interrupt Level (pil) is not set to correspond to that110 of the interrupt being processed. When a trap occurs, ALL111 subsequent traps are disabled. In order to safely invoke a112 subroutine during trap handling, traps must be enabled to allow113 for the possibility of register window overflow and underflow114 traps.115 98 116 99 If the interrupt handler was installed as an RTEMS … … 123 106 124 107 @item insures that a register window is available for 125 subsequent traps,108 subsequent exceptions, 126 109 127 110 @item if this is the outermost (i.e. non-nested) interrupt, … … 129 112 to the interrupt stack, 130 113 131 @item enables traps,114 @item enables exceptions, 132 115 133 116 @item invokes the vectors to a user interrupt service routine (ISR). 134 117 @end itemize 135 118 136 Asynchronous interrupts are ignored while traps are137 disabled. Synchronous traps which occur while trapsare119 Asynchronous interrupts are ignored while exceptions are 120 disabled. Synchronous interrupts which occur while are 138 121 disabled result in the CPU being forced into an error mode. 139 122 … … 143 126 144 127 @ifinfo 145 @node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing 146 @end ifinfo 147 @section Traps and Register Windows 148 149 One of the register windows must be reserved at all 150 times for trap processing. This is critical to the proper 151 operation of the trap mechanism in the SPARC architecture. It 152 is the responsibility of the trap handler to insure that there 153 is a register window available for a subsequent trap before 154 re-enabling traps. It is likely that any high level language 155 routines invoked by the trap handler (such as a user-provided 156 RTEMS interrupt handler) will allocate a new register window. 157 The save operation could result in a window overflow trap. This 158 trap cannot be correctly processed unless (1) traps are enabled 159 and (2) a register window is reserved for traps. Thus, the 160 RTEMS interrupt handler insures that a register window is 161 available for subsequent traps before enabling traps and 162 invoking the user's interrupt handler. 163 164 @ifinfo 165 @node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing 128 @node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing 166 129 @end ifinfo 167 130 @section Interrupt Levels 168 131 169 Sixteen levels (0-15) of interrupt priorities are170 supported by the SPARC architecture with level fifteen (15)132 TBD levels (0-TBD) of interrupt priorities are 133 supported by the PowerPC architecture with level TBD (TBD) 171 134 being the highest priority. Level zero (0) indicates that 172 135 interrupts are fully enabled. Interrupt requests for interrupts … … 174 137 level are ignored. 175 138 176 Although RTEMS supports 256 interrupt levels, the 177 SPARC only supports sixteen. RTEMS interrupt levels 0 through 178 15 directly correspond to SPARC processor interrupt levels. All 179 other RTEMS interrupt levels are undefined and their behavior is 139 TBD 140 All other RTEMS interrupt levels are undefined and their behavior is 180 141 unpredictable. 181 142 … … 187 148 During the execution of directive calls, critical 188 149 sections of code may be executed. When these sections are 189 encountered, RTEMS disables interrupts to level seven (15)150 encountered, RTEMS disables interrupts to level TBD (TBD) 190 151 before the execution of this section and restores them to the 191 152 previous level upon completion of the section. RTEMS has been 192 153 optimized to insure that interrupts are disabled for less than 193 RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ194 Mhz PowerPC 603e with zero wait states. 195 These numbers will vary based the number of wait states and 196 processor speed present on the target board.154 RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 155 RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e with zero 156 wait states. These numbers will vary based the number of wait 157 states and processor speed present on the target board. 197 158 [NOTE: The maximum period with interrupts disabled is hand calculated. This 198 159 calculation was last performed for Release … … 201 162 [NOTE: It is thought that the length of time at which 202 163 the processor interrupt level is elevated to fifteen by RTEMS is 203 not anywhere near as long as the length of time ALL traps are164 not anywhere near as long as the length of time ALL exceptions are 204 165 disabled as part of the "flush all register windows" operation.] 205 166 … … 216 177 @section Interrupt Stack 217 178 218 The SPARC architecture does not provide for a219 dedicated interrupt stack. Thus by default, traphandlers would179 The PowerPC architecture does not provide for a 180 dedicated interrupt stack. Thus by default, exception handlers would 220 181 execute on the stack of the RTEMS task which they interrupted. 221 182 This artificially inflates the stack requirements for each task … … 223 184 account for the worst case interrupt stack requirements in 224 185 addition to it's own worst case usage. RTEMS addresses this 225 problem on the SPARC by providing a dedicated interrupt stack186 problem on the PowerPC by providing a dedicated interrupt stack 226 187 managed by software. 227 188 … … 233 194 the interrupt stack before invoking the installed handler. 234 195 196 197
Note: See TracChangeset
for help on using the changeset viewer.