[ae68ff0] | 1 | @c |
---|
[1e524995] | 2 | @c COPYRIGHT (c) 1988-1998. |
---|
[ae68ff0] | 3 | @c On-Line Applications Research Corporation (OAR). |
---|
| 4 | @c All rights reserved. |
---|
| 5 | @c |
---|
[139b2e4a] | 6 | @c $Id$ |
---|
| 7 | @c |
---|
[ae68ff0] | 8 | |
---|
| 9 | @ifinfo |
---|
| 10 | @node Board Support Packages, Board Support Packages Introduction, RATE_MONOTONIC_GET_STATUS - Obtain status information on period, Top |
---|
| 11 | @end ifinfo |
---|
| 12 | @chapter Board Support Packages |
---|
| 13 | @ifinfo |
---|
| 14 | @menu |
---|
| 15 | * Board Support Packages Introduction:: |
---|
| 16 | * Board Support Packages Reset and Initialization:: |
---|
| 17 | * Board Support Packages Device Drivers:: |
---|
| 18 | * Board Support Packages User Extensions:: |
---|
| 19 | * Board Support Packages Multiprocessor Communications Interface (MPCI):: |
---|
| 20 | @end menu |
---|
| 21 | @end ifinfo |
---|
| 22 | |
---|
| 23 | @ifinfo |
---|
| 24 | @node Board Support Packages Introduction, Board Support Packages Reset and Initialization, Board Support Packages, Board Support Packages |
---|
| 25 | @end ifinfo |
---|
| 26 | @section Introduction |
---|
| 27 | |
---|
| 28 | A board support package (BSP) is a collection of |
---|
| 29 | user-provided facilities which interface RTEMS and an |
---|
| 30 | application with a specific hardware platform. These facilities |
---|
| 31 | may include hardware initialization, device drivers, user |
---|
| 32 | extensions, and a Multiprocessor Communications Interface |
---|
| 33 | (MPCI). However, a minimal BSP need only support processor |
---|
| 34 | reset and initialization and, if needed, a clock tick. |
---|
| 35 | |
---|
| 36 | @ifinfo |
---|
| 37 | @node Board Support Packages Reset and Initialization, Interrupt Stack Requirements, Board Support Packages Introduction, Board Support Packages |
---|
| 38 | @end ifinfo |
---|
| 39 | @section Reset and Initialization |
---|
| 40 | @ifinfo |
---|
| 41 | @menu |
---|
| 42 | * Interrupt Stack Requirements:: |
---|
| 43 | * Processors with a Separate Interrupt Stack:: |
---|
| 44 | * Processors without a Separate Interrupt Stack:: |
---|
| 45 | @end menu |
---|
| 46 | @end ifinfo |
---|
| 47 | |
---|
| 48 | An RTEMS based application is initiated or |
---|
| 49 | re-initiated when the processor is reset. This initialization |
---|
| 50 | code is responsible for preparing the target platform for the |
---|
| 51 | RTEMS application. Although the exact actions performed by the |
---|
| 52 | initialization code are highly processor and target dependent, |
---|
| 53 | the logical functionality of these actions are similar across a |
---|
| 54 | variety of processors and target platforms. |
---|
| 55 | |
---|
| 56 | Normally, the application's initialization is |
---|
| 57 | performed at two separate times: before the call to |
---|
| 58 | initialize_executive (reset application initialization) and |
---|
| 59 | after initialize_executive in the user's initialization tasks |
---|
| 60 | (local and global application initialization). The order of the |
---|
| 61 | startup procedure is as follows: |
---|
| 62 | |
---|
| 63 | @enumerate |
---|
| 64 | @item Reset application initialization. |
---|
| 65 | @item Call to initialize_executive |
---|
| 66 | @item Local and global application initialization. |
---|
| 67 | @end enumerate |
---|
| 68 | |
---|
| 69 | The reset application initialization code is executed |
---|
| 70 | first when the processor is reset. All of the hardware must be |
---|
| 71 | initialized to a quiescent state by this software before |
---|
| 72 | initializing RTEMS. When in quiescent state, devices do not |
---|
| 73 | generate any interrupts or require any servicing by the |
---|
| 74 | application. Some of the hardware components may be initialized |
---|
| 75 | in this code as well as any application initialization that does |
---|
| 76 | not involve calls to RTEMS directives. |
---|
| 77 | |
---|
| 78 | The processor's Interrupt Vector Table which will be |
---|
| 79 | used by the application may need to be set to the required value |
---|
| 80 | by the reset application initialization code. Because |
---|
| 81 | interrupts are enabled automatically by RTEMS as part of the |
---|
| 82 | initialize_executive directive, the Interrupt Vector Table MUST |
---|
| 83 | be set before this directive is invoked to insure correct |
---|
| 84 | interrupt vectoring. The processor's Interrupt Vector Table |
---|
| 85 | must be accessible by RTEMS as it will be modified by the |
---|
| 86 | interrupt_catch directive. On some CPUs, RTEMS installs it's |
---|
| 87 | own Interrupt Vector Table as part of initialization and thus |
---|
| 88 | these requirements are met automatically. The reset code which |
---|
| 89 | is executed before the call to initialize_executive has the |
---|
| 90 | following requirements: |
---|
| 91 | |
---|
| 92 | @itemize @bullet |
---|
| 93 | @item Must not make any RTEMS directive calls. |
---|
| 94 | |
---|
| 95 | @item If the processor supports multiple privilege levels, |
---|
| 96 | must leave the processor in the most privileged, or supervisory, |
---|
| 97 | state. |
---|
| 98 | |
---|
[a94c5a5d] | 99 | @item Must allocate a stack of at least @code{MINIMUM_STACK_SIZE} |
---|
[ae68ff0] | 100 | bytes and initialize the stack pointer for the |
---|
| 101 | initialize_executive directive. |
---|
| 102 | |
---|
| 103 | @item Must initialize the processor's Interrupt Vector Table. |
---|
| 104 | |
---|
| 105 | @item Must disable all maskable interrupts. |
---|
| 106 | |
---|
| 107 | @item If the processor supports a separate interrupt stack, |
---|
| 108 | must allocate the interrupt stack and initialize the interrupt |
---|
| 109 | stack pointer. |
---|
| 110 | @end itemize |
---|
| 111 | |
---|
| 112 | The initialize_executive directive does not return to |
---|
| 113 | the initialization code, but causes the highest priority |
---|
| 114 | initialization task to begin execution. Initialization tasks |
---|
| 115 | are used to perform both local and global application |
---|
| 116 | initialization which is dependent on RTEMS facilities. The user |
---|
| 117 | initialization task facility is typically used to create the |
---|
| 118 | application's set of tasks. |
---|
| 119 | |
---|
| 120 | @ifinfo |
---|
| 121 | @node Interrupt Stack Requirements, Processors with a Separate Interrupt Stack, Board Support Packages Reset and Initialization, Board Support Packages Reset and Initialization |
---|
| 122 | @end ifinfo |
---|
| 123 | @subsection Interrupt Stack Requirements |
---|
| 124 | |
---|
| 125 | The worst-case stack usage by interrupt service |
---|
| 126 | routines must be taken into account when designing an |
---|
| 127 | application. If the processor supports interrupt nesting, the |
---|
| 128 | stack usage must include the deepest nest level. The worst-case |
---|
| 129 | stack usage must account for the following requirements: |
---|
| 130 | |
---|
| 131 | @itemize @bullet |
---|
| 132 | @item Processor's interrupt stack frame |
---|
| 133 | |
---|
| 134 | @item Processor's subroutine call stack frame |
---|
| 135 | |
---|
| 136 | @item RTEMS system calls |
---|
| 137 | |
---|
| 138 | @item Registers saved on stack |
---|
| 139 | |
---|
| 140 | @item Application subroutine calls |
---|
| 141 | @end itemize |
---|
| 142 | |
---|
| 143 | The size of the interrupt stack must be greater than |
---|
[a94c5a5d] | 144 | or equal to the constant @code{MINIMUM_STACK_SIZE}. |
---|
[ae68ff0] | 145 | |
---|
| 146 | @ifinfo |
---|
| 147 | @node Processors with a Separate Interrupt Stack, Processors without a Separate Interrupt Stack, Interrupt Stack Requirements, Board Support Packages Reset and Initialization |
---|
| 148 | @end ifinfo |
---|
| 149 | @subsection Processors with a Separate Interrupt Stack |
---|
| 150 | |
---|
| 151 | Some processors support a separate stack for |
---|
| 152 | interrupts. When an interrupt is vectored and the interrupt is |
---|
| 153 | not nested, the processor will automatically switch from the |
---|
| 154 | current stack to the interrupt stack. The size of this stack is |
---|
| 155 | based solely on the worst-case stack usage by interrupt service |
---|
| 156 | routines. |
---|
| 157 | |
---|
| 158 | The dedicated interrupt stack for the entire |
---|
| 159 | application is supplied and initialized by the reset and |
---|
| 160 | initialization code of the user's board support package. Since |
---|
| 161 | all ISRs use this stack, the stack size must take into account |
---|
| 162 | the worst case stack usage by any combination of nested ISRs. |
---|
| 163 | |
---|
| 164 | @ifinfo |
---|
| 165 | @node Processors without a Separate Interrupt Stack, Board Support Packages Device Drivers, Processors with a Separate Interrupt Stack, Board Support Packages Reset and Initialization |
---|
| 166 | @end ifinfo |
---|
| 167 | @subsection Processors without a Separate Interrupt Stack |
---|
| 168 | |
---|
| 169 | Some processors do not support a separate stack for |
---|
| 170 | interrupts. In this case, without special assistance every |
---|
| 171 | task's stack must include enough space to handle the task's |
---|
| 172 | worst-case stack usage as well as the worst-case interrupt stack |
---|
| 173 | usage. This is necessary because the worst-case interrupt |
---|
| 174 | nesting could occur while any task is executing. |
---|
| 175 | |
---|
| 176 | On many processors without dedicated hardware managed |
---|
| 177 | interrupt stacks, RTEMS manages a dedicated interrupt stack in |
---|
| 178 | software. If this capability is supported on a CPU, then it is |
---|
| 179 | logically equivalent to the processor supporting a separate |
---|
| 180 | interrupt stack in hardware. |
---|
| 181 | |
---|
| 182 | @ifinfo |
---|
| 183 | @node Board Support Packages Device Drivers, Clock Tick Device Driver, Processors without a Separate Interrupt Stack, Board Support Packages |
---|
| 184 | @end ifinfo |
---|
| 185 | @section Device Drivers |
---|
| 186 | @ifinfo |
---|
| 187 | @menu |
---|
| 188 | * Clock Tick Device Driver:: |
---|
| 189 | @end menu |
---|
| 190 | @end ifinfo |
---|
| 191 | |
---|
| 192 | Device drivers consist of control software for |
---|
| 193 | special peripheral devices and provide a logical interface for |
---|
| 194 | the application developer. The RTEMS I/O manager provides |
---|
| 195 | directives which allow applications to access these device |
---|
| 196 | drivers in a consistent fashion. A Board Support Package may |
---|
| 197 | include device drivers to access the hardware on the target |
---|
| 198 | platform. These devices typically include serial and parallel |
---|
| 199 | ports, counter/timer peripherals, real-time clocks, disk |
---|
| 200 | interfaces, and network controllers. |
---|
| 201 | |
---|
| 202 | For more information on device drivers, refer to the |
---|
| 203 | I/O Manager chapter. |
---|
| 204 | |
---|
| 205 | @ifinfo |
---|
| 206 | @node Clock Tick Device Driver, Board Support Packages User Extensions, Board Support Packages Device Drivers, Board Support Packages Device Drivers |
---|
| 207 | @end ifinfo |
---|
| 208 | @subsection Clock Tick Device Driver |
---|
| 209 | |
---|
| 210 | Most RTEMS applications will include a clock tick |
---|
| 211 | device driver which invokes the clock_tick directive at regular |
---|
| 212 | intervals. The clock tick is necessary if the application is to |
---|
| 213 | utilize timeslicing, the clock manager, the timer manager, the |
---|
| 214 | rate monotonic manager, or the timeout option on blocking |
---|
| 215 | directives. |
---|
| 216 | |
---|
| 217 | The clock tick is usually provided as an interrupt |
---|
| 218 | from a counter/timer or a real-time clock device. When a |
---|
| 219 | counter/timer is used to provide the clock tick, the device is |
---|
| 220 | typically programmed to operate in continuous mode. This mode |
---|
| 221 | selection causes the device to automatically reload the initial |
---|
| 222 | count and continue the countdown without programmer |
---|
| 223 | intervention. This reduces the overhead required to manipulate |
---|
| 224 | the counter/timer in the clock tick ISR and increases the |
---|
| 225 | accuracy of tick occurrences. The initial count can be based on |
---|
| 226 | the microseconds_per_tick field in the RTEMS Configuration |
---|
| 227 | Table. An alternate approach is to set the initial count for a |
---|
| 228 | fixed time period (such as one millisecond) and have the ISR |
---|
| 229 | invoke clock_tick on the microseconds_per_tick boundaries. |
---|
| 230 | Obviously, this can induce some error if the configured |
---|
| 231 | microseconds_per_tick is not evenly divisible by the chosen |
---|
| 232 | clock interrupt quantum. |
---|
| 233 | |
---|
| 234 | It is important to note that the interval between |
---|
| 235 | clock ticks directly impacts the granularity of RTEMS timing |
---|
| 236 | operations. In addition, the frequency of clock ticks is an |
---|
| 237 | important factor in the overall level of system overhead. A |
---|
| 238 | high clock tick frequency results in less processor time being |
---|
| 239 | available for task execution due to the increased number of |
---|
| 240 | clock tick ISRs. |
---|
| 241 | |
---|
| 242 | @ifinfo |
---|
| 243 | @node Board Support Packages User Extensions, Board Support Packages Multiprocessor Communications Interface (MPCI), Clock Tick Device Driver, Board Support Packages |
---|
| 244 | @end ifinfo |
---|
| 245 | @section User Extensions |
---|
| 246 | |
---|
| 247 | RTEMS allows the application developer to augment |
---|
| 248 | selected features by invoking user-supplied extension routines |
---|
| 249 | when the following system events occur: |
---|
| 250 | |
---|
| 251 | @itemize @bullet |
---|
| 252 | @item Task creation |
---|
| 253 | @item Task initiation |
---|
| 254 | @item Task reinitiation |
---|
| 255 | @item Task deletion |
---|
| 256 | @item Task context switch |
---|
| 257 | @item Post task context switch |
---|
| 258 | @item Task begin |
---|
| 259 | @item Task exits |
---|
| 260 | @item Fatal error detection |
---|
| 261 | @end itemize |
---|
| 262 | |
---|
| 263 | User extensions can be used to implement a wide variety of |
---|
| 264 | functions including execution profiling, non-standard |
---|
| 265 | coprocessor support, debug support, and error detection and |
---|
| 266 | recovery. For example, the context of a non-standard numeric |
---|
| 267 | coprocessor may be maintained via the user extensions. In this |
---|
| 268 | example, the task creation and deletion extensions are |
---|
| 269 | responsible for allocating and deallocating the context area, |
---|
| 270 | the task initiation and reinitiation extensions would be |
---|
| 271 | responsible for priming the context area, and the task context |
---|
| 272 | switch extension would save and restore the context of the |
---|
| 273 | device. |
---|
| 274 | |
---|
| 275 | For more information on user extensions, refer to the |
---|
| 276 | User Extensions chapter. |
---|
| 277 | |
---|
| 278 | @ifinfo |
---|
| 279 | @node Board Support Packages Multiprocessor Communications Interface (MPCI), Tightly-Coupled Systems, Board Support Packages User Extensions, Board Support Packages |
---|
| 280 | @end ifinfo |
---|
| 281 | @section Multiprocessor Communications Interface (MPCI) |
---|
| 282 | @ifinfo |
---|
| 283 | @menu |
---|
| 284 | * Tightly-Coupled Systems:: |
---|
| 285 | * Loosely-Coupled Systems:: |
---|
| 286 | * Systems with Mixed Coupling:: |
---|
| 287 | * Heterogeneous Systems:: |
---|
| 288 | @end menu |
---|
| 289 | @end ifinfo |
---|
| 290 | |
---|
| 291 | RTEMS requires that an MPCI layer be provided when a |
---|
| 292 | multiple node application is developed. This MPCI layer must |
---|
| 293 | provide an efficient and reliable communications mechanism |
---|
| 294 | between the multiple nodes. Tasks on different nodes |
---|
| 295 | communicate and synchronize with one another via the MPCI. Each |
---|
| 296 | MPCI layer must be tailored to support the architecture of the |
---|
| 297 | target platform. |
---|
| 298 | |
---|
| 299 | For more information on the MPCI, refer to the |
---|
| 300 | Multiprocessing Manager chapter. |
---|
| 301 | |
---|
| 302 | @ifinfo |
---|
| 303 | @node Tightly-Coupled Systems, Loosely-Coupled Systems, Board Support Packages Multiprocessor Communications Interface (MPCI), Board Support Packages Multiprocessor Communications Interface (MPCI) |
---|
| 304 | @end ifinfo |
---|
| 305 | @subsection Tightly-Coupled Systems |
---|
| 306 | |
---|
| 307 | A tightly-coupled system is a multiprocessor |
---|
| 308 | configuration in which the processors communicate solely via |
---|
| 309 | shared global memory. The MPCI can simply place the RTEMS |
---|
| 310 | packets in the shared memory space. The two primary |
---|
| 311 | considerations when designing an MPCI for a tightly-coupled |
---|
| 312 | system are data consistency and informing another node of a |
---|
| 313 | packet. |
---|
| 314 | |
---|
| 315 | The data consistency problem may be solved using |
---|
| 316 | atomic "test and set" operations to provide a "lock" in the |
---|
| 317 | shared memory. It is important to minimize the length of time |
---|
| 318 | any particular processor locks a shared data structure. |
---|
| 319 | |
---|
| 320 | The problem of informing another node of a packet can |
---|
| 321 | be addressed using one of two techniques. The first technique |
---|
| 322 | is to use an interprocessor interrupt capability to cause an |
---|
| 323 | interrupt on the receiving node. This technique requires that |
---|
| 324 | special support hardware be provided by either the processor |
---|
| 325 | itself or the target platform. The second technique is to have |
---|
| 326 | a node poll for arrival of packets. The drawback to this |
---|
| 327 | technique is the overhead associated with polling. |
---|
| 328 | |
---|
| 329 | @ifinfo |
---|
| 330 | @node Loosely-Coupled Systems, Systems with Mixed Coupling, Tightly-Coupled Systems, Board Support Packages Multiprocessor Communications Interface (MPCI) |
---|
| 331 | @end ifinfo |
---|
| 332 | @subsection Loosely-Coupled Systems |
---|
| 333 | |
---|
| 334 | A loosely-coupled system is a multiprocessor |
---|
| 335 | configuration in which the processors communicate via some type |
---|
| 336 | of communications link which is not shared global memory. The |
---|
| 337 | MPCI sends the RTEMS packets across the communications link to |
---|
| 338 | the destination node. The characteristics of the communications |
---|
| 339 | link vary widely and have a significant impact on the MPCI |
---|
| 340 | layer. For example, the bandwidth of the communications link |
---|
| 341 | has an obvious impact on the maximum MPCI throughput. |
---|
| 342 | |
---|
| 343 | The characteristics of a shared network, such as |
---|
| 344 | Ethernet, lend themselves to supporting an MPCI layer. These |
---|
| 345 | networks provide both the point-to-point and broadcast |
---|
| 346 | capabilities which are expected by RTEMS. |
---|
| 347 | |
---|
| 348 | @ifinfo |
---|
| 349 | @node Systems with Mixed Coupling, Heterogeneous Systems, Loosely-Coupled Systems, Board Support Packages Multiprocessor Communications Interface (MPCI) |
---|
| 350 | @end ifinfo |
---|
| 351 | @subsection Systems with Mixed Coupling |
---|
| 352 | |
---|
| 353 | A mixed-coupling system is a multiprocessor |
---|
| 354 | configuration in which the processors communicate via both |
---|
| 355 | shared memory and communications links. A unique characteristic |
---|
| 356 | of mixed-coupling systems is that a node may not have access to |
---|
| 357 | all communication methods. There may be multiple shared memory |
---|
| 358 | areas and communication links. Therefore, one of the primary |
---|
| 359 | functions of the MPCI layer is to efficiently route RTEMS |
---|
| 360 | packets between nodes. This routing may be based on numerous |
---|
| 361 | algorithms. In addition, the router may provide alternate |
---|
| 362 | communications paths in the event of an overload or a partial |
---|
| 363 | failure. |
---|
| 364 | |
---|
| 365 | @ifinfo |
---|
| 366 | @node Heterogeneous Systems, User Extensions Manager, Systems with Mixed Coupling, Board Support Packages Multiprocessor Communications Interface (MPCI) |
---|
| 367 | @end ifinfo |
---|
| 368 | @subsection Heterogeneous Systems |
---|
| 369 | |
---|
| 370 | Designing an MPCI layer for a heterogeneous system |
---|
| 371 | requires special considerations by the developer. RTEMS is |
---|
| 372 | designed to eliminate many of the problems associated with |
---|
| 373 | sharing data in a heterogeneous environment. The MPCI layer |
---|
| 374 | need only address the representation of thirty-two (32) bit |
---|
| 375 | unsigned quantities. |
---|
| 376 | |
---|
| 377 | For more information on supporting a heterogeneous |
---|
| 378 | system, refer the Supporting Heterogeneous Environments in the |
---|
| 379 | Multiprocessing Manager chapter. |
---|