1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2008. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @chapter Initialization Code |
---|
10 | |
---|
11 | @section Introduction |
---|
12 | |
---|
13 | The initialization code is the first piece of code executed when there's a |
---|
14 | reset/reboot. Its purpose is to initialize the board for the application. |
---|
15 | This chapter contains a narrative description of the initialization |
---|
16 | process followed by a description of each of the files and routines |
---|
17 | commonly found in the BSP related to initialization. The remainder of |
---|
18 | this chapter covers special issues which require attention such |
---|
19 | as interrupt vector table and chip select initialization. |
---|
20 | |
---|
21 | Most of the examples in this chapter will be based on the SPARC/ERC32 and |
---|
22 | m68k/gen68340 BSP initialization code. Like most BSPs, the initialization |
---|
23 | for these BSP is divided into two subdirectories under the BSP source |
---|
24 | directory. The BSP source code for these BSPs is in the following |
---|
25 | directories: |
---|
26 | |
---|
27 | @example |
---|
28 | c/src/lib/libbsp/m68k/gen68340 |
---|
29 | c/src/lib/libbsp/sparc/erc32 |
---|
30 | @end example |
---|
31 | |
---|
32 | Both BSPs contain startup code written in assembly language and C. |
---|
33 | The gen68340 BSP has its early initialization start code in the |
---|
34 | @code{start340} subdirectory and its C startup code in the @code{startup} |
---|
35 | directory. In the @code{start340} directory are two source files. |
---|
36 | The file @code{startfor340only.s} is the simpler of these files as it only |
---|
37 | has initialization code for a MC68340 board. The file @code{start340.s} |
---|
38 | contains initialization for a 68349 based board as well. |
---|
39 | |
---|
40 | Similarly, the ERC32 BSP has startup code written in assembly language |
---|
41 | and C. However, this BSP shares this code with other SPARC BSPs. |
---|
42 | Thus the @code{Makefile.am} explicitly references the following files |
---|
43 | for this functionality. |
---|
44 | |
---|
45 | @example |
---|
46 | ../../sparc/shared/start.S |
---|
47 | ../../sparc/shared/bspclean.c |
---|
48 | @end example |
---|
49 | |
---|
50 | @b{NOTE:} In most BSPs, the directory named @code{start340} in the |
---|
51 | gen68340 BSP would be simply named @code{start} or start followed by a |
---|
52 | BSP designation. |
---|
53 | |
---|
54 | @section Required Global Variables |
---|
55 | |
---|
56 | Although not strictly part of initialization, there are a few global |
---|
57 | variables assumed to exist by reusable device drivers. These global |
---|
58 | variables should only defined by the BSP when using one of these device |
---|
59 | drivers. |
---|
60 | |
---|
61 | The BSP author probably should be aware of the @code{Configuration} |
---|
62 | Table structure generated by @code{<rtems/confdefs.h>} during debug but |
---|
63 | should not explicitly reference it in the source code. There are helper |
---|
64 | routines provided by RTEMS to access individual fields. |
---|
65 | |
---|
66 | In older RTEMS versions, the BSP included a number of required global |
---|
67 | variables. We have made every attempt to eliminate these in the interest |
---|
68 | of simplicity. |
---|
69 | |
---|
70 | @section Board Initialization |
---|
71 | |
---|
72 | This section describes the steps an application goes through from the |
---|
73 | time the first BSP code is executed until the first application task |
---|
74 | executes. The following figure illustrates the program flow during |
---|
75 | this sequence: |
---|
76 | |
---|
77 | @ifset use-ascii |
---|
78 | IMAGE NOT AVAILABLE IN ASCII VERSION |
---|
79 | @end ifset |
---|
80 | |
---|
81 | @ifset use-tex |
---|
82 | @image{BSPInitFlowchart-49,6in,,Initialization Sequence,.png} |
---|
83 | @c @image{FILENAME[, WIDTH[, HEIGHT[, ALTTEXT[, EXTENSION]]]]} |
---|
84 | @end ifset |
---|
85 | |
---|
86 | @ifset use-html |
---|
87 | @html |
---|
88 | <center> |
---|
89 | <IMG SRC="BSPInitFlowchart-49.png" WIDTH=800 ALT="Initialization Sequence"> |
---|
90 | </center> |
---|
91 | @end html |
---|
92 | @end ifset |
---|
93 | |
---|
94 | The above figure illustrates the flow from assembly language start code |
---|
95 | to the shared @code{bootcard.c} framework then through the C Library, |
---|
96 | RTEMS, device driver initialization phases, and the context switch |
---|
97 | to the first application task. After this, the application executes |
---|
98 | until it calls @code{exit}, @code{rtems_shutdown_executive}, or some |
---|
99 | other normal termination initiating routine and control is returned |
---|
100 | to @code{bootcard.c} which allows the BSP to perform some clanup in C |
---|
101 | (@code{bsp_cleanup}) and then @code{boot_card} returns to the assembly |
---|
102 | language which initially invoked it. |
---|
103 | |
---|
104 | The routines invoked during this will be discussed and their location |
---|
105 | in the RTEMS source tree pointed out as we discuss each. |
---|
106 | |
---|
107 | @subsection Start Code - Assembly Language Initialization |
---|
108 | |
---|
109 | The assembly language code in the directory @code{start} is the first part |
---|
110 | of the application to execute. It is responsible for initializing the |
---|
111 | processor and board enough to execute the rest of the BSP. This includes: |
---|
112 | |
---|
113 | @itemize @bullet |
---|
114 | @item initializing the stack |
---|
115 | @item zeroing out the uninitialized data section @code{.bss} |
---|
116 | @item disabling external interrupts |
---|
117 | @item copy the initialized data from ROM to RAM |
---|
118 | @end itemize |
---|
119 | |
---|
120 | The general rule of thumb is that the start code in assembly should |
---|
121 | do the minimum necessary to allow C code to execute to complete the |
---|
122 | initialization sequence. |
---|
123 | |
---|
124 | The initial assembly language start code completes its execution by |
---|
125 | invoking the shared routine @code{boot_card()}. |
---|
126 | |
---|
127 | The label (symbolic name) associated with the starting address of the |
---|
128 | program is typically called @code{start}. The start object file is the |
---|
129 | first object file linked into the program image so it is ensured that |
---|
130 | the start code is at offset 0 in the @code{.text} section. It is the |
---|
131 | responsibility of the linker script in conjunction with the compiler |
---|
132 | specifications file to put the start code in the correct location in |
---|
133 | the application image. |
---|
134 | |
---|
135 | @subsection boot_card() - Boot the Card |
---|
136 | |
---|
137 | The @code{boot_card()} is the first C code invoked. This file is the |
---|
138 | core component in the RTEMS BSP Initialization Framework and provides |
---|
139 | the proper sequencing of initialization steps for the BSP, RTEMS and |
---|
140 | device drivers. All BSPs use the same shared version of @code{boot_card()} |
---|
141 | which is located in the following file: |
---|
142 | |
---|
143 | @example |
---|
144 | c/src/lib/libbsp/shared/bootcard.c |
---|
145 | @end example |
---|
146 | |
---|
147 | The @code{boot_card()} routine performs the following functions: |
---|
148 | |
---|
149 | @itemize @bullet |
---|
150 | |
---|
151 | @item It disables processor interrupts. |
---|
152 | |
---|
153 | @item It sets the global program name and command line argument variables |
---|
154 | for later use by the application. |
---|
155 | |
---|
156 | @item If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined, it |
---|
157 | will invoke the BSP specific @code{bsp_get_work_area} function to obtain |
---|
158 | information on the amount and location of BSP RAM that is available to |
---|
159 | be allocated to the C Program Heap and RTEMS Workspace. If the amount |
---|
160 | of memory available for the RTEMS Workspace is less than that required |
---|
161 | by the application (e.g. @code{rtems_configuration_get_work_space_size()}, |
---|
162 | then a message is printed using @code{printk}, @code{bsp_cleanup} is |
---|
163 | invoked, and -1 is return to the assembly language start code. BSPs which |
---|
164 | use this memory allocation functionality in @code{bootcard.c} |
---|
165 | must invoke the RTEMS specific autoconf macro |
---|
166 | @code{RTEMS_BSP_BOOTCARD_HANDLES_RAM_ALLOCATION} in the BSP's |
---|
167 | @code{configure.ac} file. |
---|
168 | |
---|
169 | @item It invokes the BSP specific routine @code{bsp_start()} which is |
---|
170 | written in C and thus able to perform more advanced initialization. |
---|
171 | Often MMU and bus initialization occurs here. |
---|
172 | |
---|
173 | @item It invokes the RTEMS directive |
---|
174 | @code{rtems_initialize_data_structures()} to initialize the RTEMS |
---|
175 | executive to a state where objects can be created but tasking is not |
---|
176 | enabled. |
---|
177 | |
---|
178 | @item If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined, |
---|
179 | it will calculate the memory available for the C Program Heap and invoke |
---|
180 | the initialization routine for the C Library with this information. |
---|
181 | |
---|
182 | @item It invokes the BSP specific routine @code{bsp_pretasking_hook}. On |
---|
183 | most BSPs which utilize the framework, this routine does nothing. |
---|
184 | |
---|
185 | @item If @code{RTEMS_DEBUG} is enabled, then the RTEMS debug mask level |
---|
186 | is inialized appropriately. |
---|
187 | |
---|
188 | @item It invokes the RTEMS directive |
---|
189 | @code{rtems_initialize_before_drivers()} to initialize the MPCI Server |
---|
190 | thread in a multiprocessor configuration and execute API specific |
---|
191 | extensions. |
---|
192 | |
---|
193 | @item It invokes the BSP specific routine @code{bsp_predriver_hook}. For |
---|
194 | most BSPs, the implementation of this routine does nothing. However, |
---|
195 | on some BSPs, required subsystems which utilize the C Library |
---|
196 | (e.g. @code{malloc} in particular) may be initialized at this point. |
---|
197 | |
---|
198 | @item It invokes the RTEMS directive |
---|
199 | @code{rtems_initialize_device_drivers()} to initialize the statically |
---|
200 | configured set of device drivers in the order they were specified in |
---|
201 | the Configuration Table. |
---|
202 | |
---|
203 | @item It invokes the BSP specific routine @code{bsp_postdriver_hook}. For |
---|
204 | most BSPs, the implementation of this routine does nothing. However, some |
---|
205 | BSPs use this hook and perform some initialization which must be done at |
---|
206 | this point in the initialization sequence. This is the last opportunity |
---|
207 | for the BSP to insert BSP specific code into the initialization sequence. |
---|
208 | |
---|
209 | @item It invokes the RTEMS directive |
---|
210 | @code{rtems_initialize_start_multitasking()} which starts multitasking and context switches to the first task. @code{boot_card()} will not return until the application is shutdown. As part of this sequence the following actions occur: |
---|
211 | |
---|
212 | @itemize @bullet |
---|
213 | |
---|
214 | @item RTEMS will context switch to the first application task. As a |
---|
215 | side-effect of this context switch, processor interrupts will be enabled. |
---|
216 | This is often the source of a fatal error during BSP development because |
---|
217 | the BSP did not clear and/or disable all interrupt sources and a spurious |
---|
218 | interrupt will occur . |
---|
219 | |
---|
220 | @item When in the context of the first task but before its body has been |
---|
221 | entered, any C++ Global Constructors will be invoked. |
---|
222 | |
---|
223 | @end itemize |
---|
224 | |
---|
225 | @item Finally after the application shutsdown RTEMS and control is |
---|
226 | return to @code{boot_card()} from RTEMS, it invokes the BSP specific |
---|
227 | routine @code{bsp_cleanup()} to perform any necessary board specific |
---|
228 | shutdown actions. |
---|
229 | |
---|
230 | @end itemize |
---|
231 | |
---|
232 | That's it. We just went through the entire sequence. |
---|
233 | |
---|
234 | @subsection bsp_start() - BSP Specific Initialization |
---|
235 | |
---|
236 | This is the first BSP specific C routine to execute during system |
---|
237 | initialization. This routine often performs required fundamental |
---|
238 | hardware initialization such as setting bus controller registers |
---|
239 | that do not have a direct impact on whether or not C code can execute. |
---|
240 | The source code for this routine is usually found in the following |
---|
241 | file: |
---|
242 | |
---|
243 | @example |
---|
244 | c/src/lib/libbsp/CPU/BSP/startup/bspstart.c |
---|
245 | @end example |
---|
246 | |
---|
247 | This routine is also responsible for overriding the default settings |
---|
248 | in the CPU Configuration Table and setting port specific entries |
---|
249 | in this table. This may include increasing the maximum number |
---|
250 | of some types of RTEMS system objects to reflect the needs of |
---|
251 | the BSP and the base set of device drivers. This routine will |
---|
252 | typically also install routines for one or more of the following |
---|
253 | initialization hooks: |
---|
254 | |
---|
255 | @itemize @bullet |
---|
256 | @item BSP Pretasking Hook |
---|
257 | @item BSP Predriver Hook |
---|
258 | @item BSP Postdriver Hook |
---|
259 | @end itemize |
---|
260 | |
---|
261 | One of the most important functions performed by this routine |
---|
262 | is determining where the RTEMS Workspace is to be |
---|
263 | located in memory. All RTEMS objects and task stacks will be |
---|
264 | allocated from this Workspace. The RTEMS Workspace is distinct |
---|
265 | from the application heap used for @code{malloc()}. Many BSPs |
---|
266 | place the RTEMS Workspace area at the end of RAM although this is |
---|
267 | certainly not a requirement. |
---|
268 | |
---|
269 | After completing execution, this routine returns to the |
---|
270 | @code{boot_card()} routine. |
---|
271 | |
---|
272 | @subsection main() - C Main |
---|
273 | |
---|
274 | This routine is the C main entry point. This is a special routine |
---|
275 | and the GNU Compiler Suite treats it as such. The GNU C Compiler |
---|
276 | recognizes @code{main()} and automatically inserts a call to the |
---|
277 | compiler run-time support routine @code{__main()} as the first |
---|
278 | code executed in @code{main()}. |
---|
279 | |
---|
280 | The routine @code{__main()} initializes the compiler's basic run-time |
---|
281 | support library and, most importantly, invokes the C++ global |
---|
282 | constructors. |
---|
283 | |
---|
284 | The precise placement of when @code{main()} is invoked in the |
---|
285 | RTEMS initialization sequence ensures that C Library and non-blocking |
---|
286 | calls can be made in global C++ constructors. |
---|
287 | |
---|
288 | The shared implementation of this routine is located in the following file: |
---|
289 | |
---|
290 | @example |
---|
291 | c/src/lib/libbsp/shared/main.c |
---|
292 | @end example |
---|
293 | |
---|
294 | In addition to the implicit invocation of @code{__main}, this |
---|
295 | routine performs some explicit initialization. This routine |
---|
296 | sets the variable @code{rtems_progname} and initiates |
---|
297 | multitasking via a call to the RTEMS directive |
---|
298 | @code{rtems_initialize_executive_late}. It is important to note |
---|
299 | that the executive does not return to this routine until the |
---|
300 | RTEMS directive @code{rtems_shutdown_executive} is invoked. |
---|
301 | |
---|
302 | The RTEMS initialization procedure is described in the @b{Initialization |
---|
303 | Manager} chapter of the @b{RTEMS Application C User's Guide}. |
---|
304 | Please refer to that manual for more information. |
---|
305 | |
---|
306 | @subsection RTEMS Pretasking Callback |
---|
307 | |
---|
308 | The @code{pretasking_hook} entry in the RTEMS CPU Configuration |
---|
309 | Table may be the address of a user provided routine that is |
---|
310 | invoked once RTEMS API initialization is complete but before interrupts |
---|
311 | and tasking are enabled. No tasks -- not even the IDLE task -- have |
---|
312 | been created when this hook is invoked. The pretasking hook is optional. |
---|
313 | |
---|
314 | Although optional, most of the RTEMS BSPs provide a pretasking hook |
---|
315 | callback. This routine is usually called @code{bsp_pretasking_hook} |
---|
316 | and is found in the file: |
---|
317 | |
---|
318 | @example |
---|
319 | c/src/lib/libbsp/CPU/BSP/startup/bspstart.c |
---|
320 | @end example |
---|
321 | |
---|
322 | The @code{bsp_pretasking_hook()} routine is the appropriate place to |
---|
323 | initialize any support components which depend on the RTEMS APIs. |
---|
324 | Most BSPs set the debug level for the system and initialize the |
---|
325 | RTEMS C Library support in their |
---|
326 | implementation of @code{bsp_pretasking_hook()}. This initialization |
---|
327 | includes the application heap used by the @code{malloc} family |
---|
328 | of routines as well as the reentrancy support for the C Library. |
---|
329 | |
---|
330 | The routine @code{bsp_libc_init} routine invoked from the |
---|
331 | @code{bsp_pretasking_hook()} routine is passed the starting |
---|
332 | address, length, and growth amount passed to @code{sbrk}. |
---|
333 | This "sbrk amount" is only used if the heap runs out of |
---|
334 | memory. In this case, the RTEMS malloc implementation will |
---|
335 | invoked @code{sbrk} to obtain more memory. See |
---|
336 | @ref{Miscellaneous Support Files sbrk() Implementation} for more details. |
---|
337 | |
---|
338 | @subsection RTEMS Predriver Callback |
---|
339 | |
---|
340 | The @code{predriver_hook} entry in the RTEMS CPU Configuration |
---|
341 | Table may be the address of a user provided routine that is |
---|
342 | is invoked immediately before the the device drivers and MPCI |
---|
343 | are initialized. RTEMS |
---|
344 | initialization is complete but interrupts and tasking are disabled. |
---|
345 | This field may be NULL to indicate that the hook is not utilized. |
---|
346 | |
---|
347 | Most BSPs do not use this callback. |
---|
348 | |
---|
349 | @subsection Device Driver Initialization |
---|
350 | |
---|
351 | At this point in the initialization sequence, the initialization |
---|
352 | routines for all of the device drivers specified in the Device |
---|
353 | Driver Table are invoked. The initialization routines are invoked |
---|
354 | in the order they appear in the Device Driver Table. |
---|
355 | |
---|
356 | The Driver Address Table is part of the RTEMS Configuration Table. It |
---|
357 | defines device drivers entry points (initialization, open, close, read, |
---|
358 | write, and control). For more information about this table, please |
---|
359 | refer to the @b{Configuring a System} chapter in the |
---|
360 | @b{RTEMS Application C User's Guide}. |
---|
361 | |
---|
362 | The RTEMS initialization procedure calls the initialization function for |
---|
363 | every driver defined in the RTEMS Configuration Table (this allows |
---|
364 | one to include only the drivers needed by the application). |
---|
365 | |
---|
366 | All these primitives have a major and a minor number as arguments: |
---|
367 | |
---|
368 | @itemize @bullet |
---|
369 | |
---|
370 | @item the major number refers to the driver type, |
---|
371 | |
---|
372 | @item the minor number is used to control two peripherals with the same |
---|
373 | driver (for instance, we define only one major number for the serial |
---|
374 | driver, but two minor numbers for channel A and B if there are two |
---|
375 | channels in the UART). |
---|
376 | |
---|
377 | @end itemize |
---|
378 | |
---|
379 | @subsection RTEMS Postdriver Callback |
---|
380 | |
---|
381 | The @code{postdriver_hook} entry in the RTEMS CPU Configuration |
---|
382 | Table may be the address of a user provided routine that is |
---|
383 | invoked immediately after the the device drivers and MPCI are initialized. |
---|
384 | Interrupts and tasking are disabled. The postdriver hook is optional. |
---|
385 | |
---|
386 | Although optional, most of the RTEMS BSPs provide a postdriver hook |
---|
387 | callback. This routine is usually called @code{bsp_postdriver_hook} |
---|
388 | and is found in the file: |
---|
389 | |
---|
390 | @example |
---|
391 | c/src/lib/libbsp/CPU/BSP/startup/bsppost.c |
---|
392 | @end example |
---|
393 | |
---|
394 | The @code{bsp_postdriver_hook()} routine is the appropriate place to |
---|
395 | perform initialization that must be performed before the first task |
---|
396 | executes but requires that a device driver be initialized. The |
---|
397 | shared implementation of the postdriver hook opens the default |
---|
398 | standard in, out, and error files and associates them with |
---|
399 | @code{/dev/console}. |
---|
400 | |
---|
401 | @section The Interrupt Vector Table |
---|
402 | |
---|
403 | The Interrupt Vector Table is called different things on different |
---|
404 | processor families but the basic functionality is the same. Each |
---|
405 | entry in the Table corresponds to the handler routine for a particular |
---|
406 | interrupt source. When an interrupt from that source occurs, the |
---|
407 | specified handler routine is invoked. Some context information is |
---|
408 | saved by the processor automatically when this happens. RTEMS saves |
---|
409 | enough context information so that an interrupt service routine |
---|
410 | can be implemented in a high level language. |
---|
411 | |
---|
412 | On some processors, the Interrupt Vector Table is at a fixed address. If |
---|
413 | this address is in RAM, then usually the BSP only has to initialize |
---|
414 | it to contain pointers to default handlers. If the table is in ROM, |
---|
415 | then the application developer will have to take special steps to |
---|
416 | fill in the table. |
---|
417 | |
---|
418 | If the base address of the Interrupt Vector Table can be dynamically |
---|
419 | changed to an arbitrary address, then the RTEMS port to that processor |
---|
420 | family will usually allocate its own table and install it. For example, |
---|
421 | on some members of the Motorola MC68xxx family, the Vector Base Register |
---|
422 | (@code{vbr}) contains this base address. |
---|
423 | |
---|
424 | @subsection Interrupt Vector Table on the gen68340 BSP |
---|
425 | |
---|
426 | The gen68340 BSP provides a default Interrupt Vector Table in the |
---|
427 | file @code{$BSP_ROOT/start340/start340.s}. After the @code{entry} |
---|
428 | label is the definition of space reserved for the table of |
---|
429 | interrupts vectors. This space is assigned the symbolic name |
---|
430 | of @code{__uhoh} in the @code{gen68340} BSP. |
---|
431 | |
---|
432 | At @code{__uhoh} label is the default interrupt handler routine. This |
---|
433 | routine is only called when an unexpected interrupts is raised. One can |
---|
434 | add their own routine there (in that case there's a call to a routine - |
---|
435 | $BSP_ROOT/startup/dumpanic.c - that prints which address caused the |
---|
436 | interrupt and the contents of the registers, stack, etc.), but this should |
---|
437 | not return. |
---|
438 | |
---|
439 | @section Chip Select Initialization |
---|
440 | |
---|
441 | When the microprocessor accesses a memory area, address decoding is |
---|
442 | handled by an address decoder, so that the microprocessor knows which |
---|
443 | memory chip(s) to access. The following figure illustrates this: |
---|
444 | |
---|
445 | @example |
---|
446 | @group |
---|
447 | +-------------------+ |
---|
448 | ------------| | |
---|
449 | ------------| |------------ |
---|
450 | ------------| Address |------------ |
---|
451 | ------------| Decoder |------------ |
---|
452 | ------------| |------------ |
---|
453 | ------------| | |
---|
454 | +-------------------+ |
---|
455 | CPU Bus Chip Select |
---|
456 | @end group |
---|
457 | @end example |
---|
458 | |
---|
459 | |
---|
460 | The Chip Select registers must be programmed such that they match |
---|
461 | the @code{linkcmds} settings. In the gen68340 BSP, ROM and RAM |
---|
462 | addresses can be found in both the @code{linkcmds} and initialization |
---|
463 | code, but this is not a great way to do this. It is better to |
---|
464 | define addresses in the linker script. |
---|
465 | |
---|
466 | @section Integrated Processor Registers Initialization |
---|
467 | |
---|
468 | The CPUs used in many embedded systems are highly complex devices |
---|
469 | with multiple peripherals on the CPU itself. For these devices, |
---|
470 | there are always some specific integrated processor registers |
---|
471 | that must be initialized. Refer to the processors' manuals for |
---|
472 | details on these registers and be VERY careful programming them. |
---|
473 | |
---|
474 | @section Data Section Recopy |
---|
475 | |
---|
476 | The next initialization part can be found in |
---|
477 | @code{$BSP340_ROOT/start340/init68340.c}. First the Interrupt |
---|
478 | Vector Table is copied into RAM, then the data section recopy is initiated |
---|
479 | (_CopyDataClearBSSAndStart in @code{$BSP340_ROOT/start340/startfor340only.s}). |
---|
480 | |
---|
481 | This code performs the following actions: |
---|
482 | |
---|
483 | @itemize @bullet |
---|
484 | |
---|
485 | @item copies the .data section from ROM to its location reserved in RAM |
---|
486 | (see @ref{Linker Script Initialized Data} for more details about this copy), |
---|
487 | |
---|
488 | @item clear @code{.bss} section (all the non-initialized |
---|
489 | data will take value 0). |
---|
490 | |
---|
491 | @end itemize |
---|
492 | |
---|
493 | @section RTEMS-Specific Initialization |
---|
494 | |
---|
495 | @section The RTEMS configuration table |
---|
496 | |
---|
497 | The RTEMS configuration table contains the maximum number of objects RTEMS |
---|
498 | can handle during the application (e.g. maximum number of tasks, |
---|
499 | semaphores, etc.). It's used to allocate the size for the RTEMS inner data |
---|
500 | structures. |
---|
501 | |
---|
502 | The RTEMS configuration table is application dependent, which means that |
---|
503 | one has to provide one per application. It is usually defined |
---|
504 | by defining macros and including the header file @code{<rtems/confdefs.h>}. |
---|
505 | In simple applications such as the tests provided with RTEMS, it is |
---|
506 | commonly found in the main module of the application. For more complex |
---|
507 | applications, it may be in a file by itself. |
---|
508 | |
---|
509 | The header file @code{<rtems/confdefs.h>} defines a constant table named |
---|
510 | @code{Configuration}. With RTEMS 4.8 and older, it was |
---|
511 | accepted practice for the BSP to copy this table into a modifiable |
---|
512 | copy named @code{BSP_Configuration}. This copy of the table was modified |
---|
513 | to define the base address of the RTEMS Executive Workspace as well as |
---|
514 | to reflect any BSP and device driver requirements not automatically |
---|
515 | handled by the application. In 4.9 and newer, we have eliminated |
---|
516 | the BSP copies of the configuration tables and are making efforts |
---|
517 | to make the configuration information generated by @code{<rtems/confdefs.h>} |
---|
518 | constant and read only. |
---|
519 | |
---|
520 | For more information on the RTEMS Configuration Table, refer to the |
---|
521 | @b{RTEMS Application C User's Guide}. |
---|
522 | |
---|