?? c-config3.html
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Configuration and Build </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-config.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-config2.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-config4.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="84472">8.3 VxWorks Initialization Timeline</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84473"> </a>This section covers the initialization sequence for VxWorks in a typical development configuration. The steps are described in sequence of execution. This is not the only way VxWorks can be bootstrapped on a particular processor. There are often more efficient or robust techniques unique to a particular processor or hardware; consult your hardware's documentation.</p><dd><p class="Body"><a name="84474"> </a>For final production, the sequence can be revisited to include diagnostics or to remove some of the generic operations that are required for booting a development environment, but that are unnecessary for production. This description can provide only an approximate guide to the processor initialization sequence and does not document every exception to this time-line.</p><dd><p class="Body"><a name="84475"> </a>The early steps of the initialization sequence are slightly different for ROM-based versions of VxWorks; for information, see <a href="c-config6.html#86219"><i class="title">8.6.3 Initialization Sequence for ROM-Based VxWorks</i></a>.</p><dd><p class="Body"><a name="84482"> </a>For a summary of the initialization time-line, see <a href="c-config3.html#84763">Table 8-1</a>. The following sections describe the initialization in detail by routine name. For clarity, the sequence is divided into a number of main steps or function calls. The key routines are listed in the headings and are described in chronological order.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84485">The VxWorks Entry Point: <b class="routine"><i class="routine">sysInit</i></b><b>( )</b> </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84486"> </a>The first step in starting a VxWorks system is to load a system image into main memory. This usually occurs as a download from the development host, under the control of the VxWorks boot ROM. Next, the boot ROM transfers control to the VxWorks startup entry point, <b class="routine"><i class="routine">sysInit</i></b><b>( )</b>. This entry point is configured by <b class="symbol_UC">RAM_LOW_ADRS</b> in the makefile and in <b class="file">config.h</b>. The VxWorks memory layout is different for each architecture; for details, see the appendix that describes your architecture.</p><dd><p class="Body"><a name="84488"> </a>The entry point, <b class="routine"><i class="routine">sysInit</i></b><b>( )</b>, is in the system-dependent assembly language module, <b class="library">sysALib.s</b>. It locks out all interrupts, invalidates caches if applicable, and initializes processor registers (including the C stack pointer) to default values. It also disables tracing, clears all pending interrupts, and invokes <b class="routine"><i class="routine">usrInit</i></b><b>( )</b>, a C subroutine in the <b class="library">usrConfig.c</b> module. For some targets, <b class="routine"><i class="routine">sysInit</i></b><b>( )</b> also performs some minimal system-dependent hardware initialization, enough to execute the remaining initialization in <b class="routine"><i class="routine">usrInit</i></b><b>( )</b>. The initial stack pointer, which is used only by <b class="routine"><i class="routine">usrInit</i></b><b>( )</b>, is set to occupy an area below the system image but above the vector table (if any).</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84492">The Initial Routine: <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84494"> </a>The <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> routine (in <b class="library">usrConfig.c</b>) saves information about the boot type, handles all the initialization that must be performed before the kernel is actually started, and then starts the kernel execution. It is the first C code to run in VxWorks. It is invoked in supervisor mode with all hardware interrupts locked out.</p><dd><p class="Body"><a name="84496"> </a>Many VxWorks facilities cannot be invoked from this routine. Because there is no task context as yet (no TCB and no task stack), facilities that require a task context cannot be invoked. This includes any facility that can cause the caller to be preempted, such as semaphores, or any facility that uses such facilities, such as <b class="routine"><i class="routine">printf</i></b><b>( )</b>. Instead, the <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> routine does only what is necessary to create an initial task, <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b>. This task then completes the startup.</p><dd><p class="Body"><a name="84497"> </a>The initialization in <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> includes the following:</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84499">Cache Initialization</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84500"> </a>The code at the beginning of <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> initializes the caches, sets the mode of the caches and puts the caches in a safe state. At the end of <b class="routine"><i class="routine">usrInit</i></b><b>( )</b>, the instruction and data caches are enabled by default.</p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84502">Zeroing Out the System <i class="acronym_lc">bss</i> Segment</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84503"> </a>The C and C++ languages specify that all uninitialized variables must have initial values of 0. These uninitialized variables are put together in a segment called <i class="acronym_lc">bss</i>. This segment is not actually loaded during the bootstrap, because it is known to be zeroed out. Because <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> is the first C code to execute, it clears the section of memory containing <i class="acronym_lc">bss</i> as its very first action. While the VxWorks boot ROMs clear all memory, VxWorks does not assume that the boot ROMs are used.</p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84505">Initializing Interrupt Vectors</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84506"> </a>The exception vectors must be set up before enabling interrupts and starting the kernel. First, <b class="routine"><i class="routine">intVecBaseSet</i></b><b>( )</b> is called to establish the vector table base address.</p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="87061"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a>There are exceptions to this in some architectures; see the appendix that describes your architecture for details.</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout><dl class="margin"><dd><p class="Body"><a name="84518"> </a>After <b class="routine"><i class="routine">intVecBaseSet</i></b><b>( )</b> is called, the routine <b class="routine"><i class="routine">excVecInit</i></b><b>( )</b> initializes all exception vectors to default handlers that safely trap and report exceptions caused by program errors or unexpected hardware interrupts.</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84520">Initializing System Hardware to a Quiescent State</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84521"> </a>System hardware is initialized by calling the system-dependent routine <b class="routine"><i class="routine">sysHwInit</i></b><b>( )</b>. This mainly consists of resetting and disabling hardware devices that can cause interrupts after interrupts are enabled (when the kernel is started). This is important because the VxWorks ISRs (for I/O devices, system clocks, and so on), are not connected to their interrupt vectors until the system initialization is completed in the <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> task. However, do not attempt to connect an interrupt handler to an interrupt during the <b class="routine"><i class="routine">sysHwInit</i></b><b>( )</b> call, because the memory pool is not yet initialized.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84524">Initializing the Kernel</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84525"> </a>The <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> routine ends with calls to two kernel initialization routines:</p></dl><dl class="margin"><dd><div class="Item"><a name="84526"> </a><b class="routine"><i class="routine">usrKernelInit</i></b><b>( )</b> (defined in <b class="file">usrKernel.c</b>)</div><dl class="margin"><dl class="margin"><dd><div class="Indent2"><a name="84527"> </a>calls the appropriate initialization routines for each of the specified optional kernel facilities (see <a href="c-config3.html#84763">Table 8-1</a> for a list).</div><br></dl></dl><dd><div class="Item"><a name="84532"> </a><b class="routine"><i class="routine">kernelInit</i></b><b>( )</b> (part of <b class="file">kernelLib.c</b>)</div><dl class="margin"><dl class="margin"><dd><div class="Indent2"><a name="84533"> </a>initiates the multitasking environment and never returns. It takes the following parameters: </div><br></dl></dl><dl class="margin"><p class="listspace"><ul class="Dash2" type="circle"><li><a name="84534"> </a>The application to be spawned as the "root" task, typically <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b>.</li></ul></p><p class="listspace"><ul class="Dash2" type="circle"><li><a name="84535"> </a>The stack size.</li></ul></p><p class="listspace"><ul class="Dash2" type="circle"><li><a name="84536"> </a>The start of usable memory; that is, the memory after the main text, data, and <i class="acronym_lc">bss</i> of the VxWorks image. All memory after this area is added to the system memory pool, which is managed by <b class="library">memPartLib</b>. Allocation for dynamic module loading, task control blocks, stacks, and so on, all come out of this region. See <a href="c-config3.html#84549"><i class="title">Initializing the Memory Pool</i></a>.</li></ul></p><p class="listspace"><ul class="Dash2" type="circle"><li><a name="84540"> </a>The top of memory as indicated by <b class="routine"><i class="routine">sysMemTop</i></b><b>( )</b>. If a contiguous block of memory is to be preserved from normal memory allocation, pass <b class="routine"><i class="routine">sysMemTop</i></b><b>( )</b> less the reserved memory.</li></ul></p><p class="listspace"><ul class="Dash2" type="circle"><li><a name="84541"> </a>The interrupt stack size. The interrupt stack corresponds to the largest amount of stack space any interrupt-level routine uses, plus a safe margin for the nesting of interrupts.</li></ul></p><p class="listspace"><ul class="Dash2" type="circle"><li><a name="84542"> </a>The interrupt lock-out level. For architectures that have a <i class="emphasis">level</i> concept, it is the maximum level. For architectures that do not have a level concept, it is the mask to disable interrupts. See the appendix that describes your architecture for details.</li></ul></p></dl></dl><dl class="margin"><dd><p class="Body"><a name="84544"> </a><b class="routine"><i class="routine">kernelInit</i></b><b>( )</b> calls <b class="routine"><i class="routine">intLockLevelSet</i></b><b>( )</b>, disables round-robin mode, and creates an interrupt stack if supported by the architecture. It then creates a root stack and TCB from the top of the memory pool, spawns the root task, <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b>, and terminates the <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> thread of execution. At this time, interrupts are enabled; it is critical that all interrupt sources are disabled and pending interrupts cleared.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84549">Initializing the Memory Pool</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84552"> </a>VxWorks includes a memory allocation facility, in the module <b class="library">memPartLib</b>, that manages a pool of available memory. The <b class="routine"><i class="routine">malloc</i></b><b>( )</b> routine allows callers to obtain variable-size blocks of memory from the pool. Internally, VxWorks uses <b class="routine"><i class="routine">malloc</i></b><b>( )</b> for dynamic allocation of memory. In particular, many VxWorks facilities allocate data structures during initialization. Therefore, the memory pool must be initialized before any other VxWorks facilities are initialized.</p><dd><p class="Body"><a name="84554"> </a>Note that the Tornado target server manages a portion of target memory to support downloading of object modules and other development functions. VxWorks makes heavy use of <b class="routine"><i class="routine">malloc</i></b><b>( )</b>, including allocation of space for loaded modules, allocation of stacks for spawned tasks, and allocation of data structures on initialization. You are also encouraged to use <b class="routine"><i class="routine">malloc</i></b><b>( )</b> to allocate any memory your application requires. Therefore, it is recommended that you assign to the VxWorks memory pool all unused memory, unless you must reserve some fixed absolute memory area for a particular application use.</p><dd><p class="Body"><a name="84555"> </a>The memory pool is initialized by <b class="routine"><i class="routine">kernelInit</i></b><b>( )</b>. The parameters to <b class="routine"><i class="routine">kernelInit</i></b><b>( )</b> specify the start and end address of the initial memory pool. In the default <b class="routine"><i class="routine">usrInit</i></b><b>( )</b> distributed with VxWorks, the pool is set to start immediately following the end of the booted system, and to contain all the rest of available memory.</p><dd><p class="Body"><a name="84558"> </a>The extent of available memory is determined by <b class="routine"><i class="routine">sysMemTop</i></b><b>( )</b>, which is a system-dependent routine that determines the size of available memory. If your system has other noncontiguous memory areas, you can make them available in the general memory pool by later calling <b class="routine"><i class="routine">memAddToPool</i></b><b>( )</b> in the <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> task.<b></b></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84564">The Initial Task: <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84565"> </a>When the multitasking kernel starts executing, all VxWorks multitasking facilities are available. Control is transferred to the <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> task and the initialization of the system can be completed. For example, <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> performs the following:</p></dl><dl class="margin"><ul class="DashSingle" type="circle"><li><a name="84567"> </a>initialization of the system clock </li></ul><ul class="DashSingle" type="circle"><li><a name="84568"> </a>initialization of the I/O system and drivers </li></ul><ul class="DashSingle" type="circle"><li><a name="84569"> </a>creation of the console devices</li></ul><ul class="DashSingle" type="circle"><li><a name="84570"> </a>setting of standard in and standard out</li></ul><ul class="DashSingle" type="circle"><li><a name="84571"> </a>installation of exception handling and logging</li></ul><ul class="DashSingle" type="circle"><li><a name="84572"> </a>initialization of the pipe driver</li></ul><ul class="DashSingle" type="circle"><li><a name="84573"> </a>initialization of standard I/O</li></ul><ul class="DashSingle" type="circle"><li><a name="84574"> </a>creation of file system devices and installation of disk drivers</li></ul><ul class="DashSingle" type="circle"><li><a name="84575"> </a>initialization of floating-point support</li></ul><ul class="DashSingle" type="circle"><li><a name="84576"> </a>initialization of performance monitoring facilities</li></ul><ul class="DashSingle" type="circle"><li><a name="84577"> </a>initialization of the network </li></ul><ul class="DashSingle" type="circle"><li><a name="84578"> </a>initialization of optional facilities </li></ul><ul class="DashSingle" type="circle"><li><a name="84579"> </a>initialization of WindView (see the <i class="title">WindView User's Guide</i>)</li></ul><ul class="DashSingle" type="circle"><li><a name="84580"> </a>initialization of target agent</li></ul><ul class="DashSingle" type="circle"><li><a name="84581"> </a>execution of a user-supplied startup script</li></ul></dl><dl class="margin"><dd><p class="Body"><a name="84582"> </a>To review the complete initialization sequence within <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b>, see <i class="textVariable">installDir</i><b class="file">/target/config/all/ usrConfig.c</b>.</p><dd><p class="Body"><a name="84583"> </a>Modify these initializations to suit your configuration. The meaning of each step and the significance of the various parameters are explained in the following sections.</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84584">Initialization of the System Clock</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84586"> </a>The first action in the <b class="routine"><i class="routine">usrRoot</i></b><b>( )</b> task is to initialize the VxWorks clock. The system clock interrupt vector is connected to the routine <b class="routine"><i class="routine">usrClock</i></b><b>( )</b> (described in <a href="c-config3.html#84742"><i class="title">The System Clock Routine: usrClock( )</i></a>) by calling <b class="routine"><i class="routine">sysClkConnect</i></b><b>( )</b>. Then, the system clock rate (usually 60Hz) is set by<b class="routine"><i class="routine"> sysClkRateSet</i></b><b>( )</b>. Most boards allow clock rates as low as 30Hz (some even as low as 1Hz), and as high as several thousand Hz. High clock rates (>1000Hz) are not desirable, because they can cause system <i class="term">thrashing</i>.<i class="term"><sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup></i> </p><dd><p class="Body"><a name="84596"> </a>The timer drivers supplied by WRS include a call to <b class="routine"><i class="routine">sysHwInit2</i></b><b>( )</b> as part of the <b class="routine"><i class="routine">sysClkConnect</i></b><b>( )</b>routine. Wind River BSPs use <b class="routine"><i class="routine">sysHwInit2</i></b><b>( )</b> to perform further board initialization that is not completed in<b class="routine"><i class="routine"> sysHwInit</i></b><b>( )</b>. For example, an<b class="routine"><i class="routine"> intConnect</i></b><b>( )</b><b class="routine"><i class="routine"> </i></b>of ISRs can take place here, because memory can be allocated now that the system is multitasking.</p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84597">Initialization of the I/O System</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84599"> </a>If <b class="symbol_UC">INCLUDE_IO_SYSTEM</b> is defined in <b class="file">configAll.h</b>, the VxWorks I/O system is initialized by calling the routine <b class="routine"><i class="routine">iosInit</i></b><b>( )</b>. The arguments specify the maximum number of drivers that can be subsequently installed, the maximum number of files that can be open in the system simultaneously, and the desired name of the "null" device that is included in the VxWorks I/O system. This null device is a "bit-bucket" on output and always returns end-of-file for input.</p>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -