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