1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-1996. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
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 | |
---|
99 | @item Must allocate a stack of at least @code{MINIMUM_STACK_SIZE} |
---|
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 |
---|
144 | or equal to the constant @code{MINIMUM_STACK_SIZE}. |
---|
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. |
---|