📄 c-booting2.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Booting over the Network </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="c-booting.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-booting.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-booting1.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-booting3.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="84249">13.2 About the Boot Program</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84251"> </a>It is possible to write your own boot program from scratch, provided that the program leaves a correctly formed boot line at the known memory location and then retrieves, loads, and runs the VxWorks image. While that might sound simple, in practice, it requires a considerable amount of work. This is because the boot program typically needs access to a variety of networking utilities in order to gather all the information needed for the boot line, as well as a file transfer utility to retrieve the boot image. </p><dd><p class="Body"><a name="84252"> </a>For example, in many environments, the boot program must include a DHCP client to negotiate for a lease on an IP address. In addition, in order to get the VxWorks image, the boot program typically needs access to a file transfer utility, such as FTP. Thus, such a program must include a network device driver, a DHCP client, a networking stack, an FTP client, and more. </p><dd><p class="Body"><a name="84253"> </a>To create a boot program without coding everything from scratch, you can use the appropriate BSP and Tornado to control the configuration of <b class="file">bootConfig.c</b>, the VxWorks boot program. The resulting boot program knows how to format a boot line and store it in the known memory location (as well as NVRAM, if available).<sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup> However, a boot program that uses the network to retrieve a run-time image needs its own boot parameters, such as the name of its network device. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84257">13.2.1 How the Boot Program Gets Its Boot Parameters</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84264"> </a>The default VxWorks boot program has a built-in default boot line.<sup><a href="#foot"><b class="FootnoteMarker">2</b></a></sup> However, that line might be incomplete, and certain values might not be valid. Before the boot program tries to use its default boot line, the boot program looks in NVRAM, if available. The boot program also accepts a boot line from user input. </p><dd><p class="Body"><a name="86285"> </a>From these sources, a <i class="emphasis">non</i>-networked boot program must be able to find appropriate values for <i class="emphasis">all</i> necessary boot parameters. However, if the boot program has network access, the initial boot line needs to define only those parameters required to initialize and use its networking utilities. The boot program can then use these networking utilities to retrieve the missing boot parameters and the run-time VxWorks image from a remote source.<div class="frame"><h4 class="EntityTitle"><a name="86358"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 13-1: Sources of Boot Parameters</font></a></h4><dl class="margin"><div class="Anchor"><a name="86458"> </a><img class="figure" border="0" src="images/c-booting0.gif"></div></dl></div></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="86293">13.2.2 The General Format of a Boot Line</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84376"> </a>When a VxWorks target boots, it uses the boot line to fill in a <b class="symbol_UC">BOOT_PARAMS</b> structure. The boot program and the VxWorks run-time image use this structure to track boot parameters. The <b class="symbol_UC">BOOT_PARAMS</b> structure is defined as follows:</p><dl class="margin"><dd><pre class="Code2"><b><a name="84378">typedef struct /* BOOT_PARAMS */ { char bootDev [BOOT_DEV_LEN]; /* boot device code */ char hostName [BOOT_HOST_LEN]; /* name of host */ char targetName [BOOT_HOST_LEN]; /* name of target */ char ead [BOOT_ADDR_LEN]; /* ethernet internet addr */ char bad [BOOT_ADDR_LEN]; /* backplane internet addr */ char had [BOOT_ADDR_LEN]; /* host internet addr */ char gad [BOOT_ADDR_LEN]; /* gateway internet addr */ char bootFile [BOOT_FILE_LEN]; /* name of boot file */ char startupScript [BOOT_FILE_LEN]; /* name of startup script file */ char usr [BOOT_USR_LEN]; /* user name */ char passwd [BOOT_PASSWORD_LEN]; /* password */ char other [BOOT_OTHER_LEN]; /* available for applications */ int procNum; /* processor number */ int unitNum; /* network device unit number */ int flags; /* configuration flags */ } BOOT_PARAMS;</a></b></pre></dl><dd><p class="Body"><a name="84396"> </a>This structure is shown here because its member names provide a convenient set of labels for discussing boot parameters. For example, using the member names shown above, this document can represent the general format of a boot line is as follows: </p><dl class="margin"><dd><pre class="Code2"><b><a name="84397"><i class="textVariable">bootDev</i>(<i class="textVariable">unitNum</i>, <i class="textVariable">procNum</i>) <i class="textVariable">hostName</i>:<i class="textVariable">bootFile</i> e=<i class="textVariable">ead</i> b=<i class="textVariable">bad</i> h=<i class="textVariable">had</i> g=<i class="textVariable">gad</i> u=<i class="textVariable">userName</i> pw=<i class="textVariable">passWord</i> f=<i class="textVariable">flags</i> tn=<i class="textVariable">targetName</i> s=<i class="textVariable">startupScript</i> o=<i class="textVariable">other</i></a></b></pre></dl><dd><p class="Body"><a name="84401"> </a>The labeled parameters e, b, h, and so on, are not order sensitive. You can leave them blank. For example, "pw= " specifies an empty password parameter. If the labeled parameter is optional or supplied later by DHCP or BOOTP, you can omit it from the boot line entirely.</p><dd><p class="Body"><a name="86354"> </a>As an example of a typical boot line, consider the following:</p><dl class="margin"><dd><pre class="Code2"><b><a name="84402">ln(0, 0) bear:/usr/wpwr/target/config/mz7122/vxworks e=90.0.0.2 b=91.0.0.2 h=100.0.0.4 g=90.0.0.3 u=papa pw=biggrump f=0x80 tn=goldilox s=bear:/usr/papa/startup o= </a></b></pre></dl><dd><p class="Body"><a name="84403"> </a>To get a listing of the boot parameters, type <b class="command">p</b> at the boot prompt (if a parameter currently has no setting, the <b class="symbol_lc">p</b> command does not list it). The labels used in the <b class="command">p</b> listing differ somewhat from the names of the structure members. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84404">13.2.3 Boot Parameters Needed for DHCP, BOOTP, and Network Device Initialization</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85996"> </a>Before the boot program can use a DHCP or BOOTP client to retrieve additional boot parameters from a remote server, the boot program needs appropriate values for <b class="symbol_lc">bootDev</b>, <b class="symbol_lc">unitNum</b>, <b class="symbol_lc">procNum</b>, and <b class="symbol_lc">flags</b>. See <a href="c-booting2.html#86175">Table 13-1</a>. Because the boot program does not yet have network access, the target must be able to find these parameter values in the default boot line, a user-provided boot line, or NVRAM boot line.<sup><a href="#foot"><b class="FootnoteMarker">3</b></a></sup><p class="table"><h4 class="EntityTitle"><a name="86175"><font face="Helvetica, sans-serif" size="-1" class="sans">Table 13-1: Boot Parameters Needed for DHCP, BOOTP, and Network Device Initialization </font></a></h4><table border="0" cellpadding="0" cellspacing="0"><tr><td colspan="20"><hr class="tablerule"></td></tr><tr valign="middle"><th rowspan="1" colspan="1"><div class="CellHeading"><b><a name="86181"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Parameter Name from <br><b class="symbol_UC">BOOT_PARAMS</b></font></b></div></th><td width="10"> </td><th rowspan="1" colspan="2"><div class="CellHeading"><b><a name="86183"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Parameter Name from <b class="command">p</b> Command Listing <br>(followed by description)</font></b></div></th><td width="10"> </td></tr><tr><td colspan="20"><hr class="tablerule2"></td></tr><tr valign="top"><td colspan=1 rowspan=1><div class="CellBody"><a name="86188"> </a><b class="symbol_lc">bootDev</b></div></td><td width="10"> </td><td colspan=2 rowspan=1><div class="CellBody"><a name="86190"> </a><b class="symbol_lc">boot device</b> </div><div class="CellBody"><a name="86191"> </a>Contains the name of the network device to boot from. For example, <b class="symbol_lc">ln</b> specifies the Lance driver. Which device you specify determines the physical medium over which the boot program attempts a networked boot. Currently, VxWorks supports drivers operating over three physical media: Ethernet, a serial line, and the memory backplane. For information on the configuration needs of these drivers, see <a href="c-network.html#"><i class="title">2.2 Data Link Layer Network Components</i></a>. To add support for another medium, write a MUX-based driver for the new network and include the driver in your boot program. For more information on writing a driver to the MUX interface, see <a href="c-muxif.html#"><i class="title">Using the MUX Interface</i></a>.</div></td><td width="10"> </td></tr><tr valign="top"><td colspan=1 rowspan=1><div class="CellBody"><a name="86202"> </a><b class="symbol_lc">unitNum</b></div></td><td width="10"> </td><td colspan=2 rowspan=1><div class="CellBody"><a name="86204"> </a><b class="symbol_lc">unit number</b> </div><div class="CellBody"><a name="86205"> </a>Contains the unit number for the network device. In boot prompts that reference the network device, the target appends this to the <b class="symbol_lc">bootDev</b>. For example, if you see an "ln0", the "ln" refers to the Lance driver, and the "0" is the network device unit number. If you do not specify a unit number, the boot program defaults to using 0. </div></td><td width="10"> </td></tr><tr valign="top"><td colspan=1 rowspan=1><div class="CellBody"><a name="86210"> </a><b class="symbol_lc">procNum</b></div></td><td width="10"> </td><td colspan=2 rowspan=1><div class="CellBody"><a name="86212"> </a><b class="symbol_lc">processor number</b> </div><div class="CellBody"><a name="86213"> </a>Contains the backplane processor number of the target CPU. This value is critical to the shared-memory network. The shared memory master must be CPU 0. </div></td><td width="10"> </td></tr><tr valign="top"><td colspan=1 rowspan=1><div class="CellBody"><a name="86218"> </a><b class="symbol_lc">flags</b></div></td><td width="10"> </td><td colspan=2 rowspan=1><div class="CellBody"><a name="86220"> </a><b class="symbol_lc">flags (f)</b> </div><div class="CellBody"><a name="86221"> </a>Contains a value composed of flags (<b class="symbol_UC">OR</b>ed in values) that configure the boot process. The predefined significance of each bit is as follows:</div></td><td width="10"> </td></tr><tr valign="top"><td colspan=1 rowspan=1><div class="CellBody"><a name="86225"> </a></div></td><td width="10"> </td><td colspan=1 rowspan=1><div class="CellBody"><a name="86227"> </a><b class="symbol_lc">0x01</b> </div></td><td width="10"> </td><td colspan=1 rowspan=1><div class="CellBody"><a name="86229"> </a>Disables system controller for processor 0 (not supported on all boards). </div></td><td width="10"> </td></tr><tr valign="top"><td colspan=1 rowspan=1><div class="CellBody"><a name="86231"> </a></div></td><td width="10"> </td><td colspan=1 rowspan=1><div class="CellBody"><a name="86233"> </a><b class="symbol_lc">0x02</b> </div></td><td width="10"> </td><td colspan=1 rowspan=1><div class="CellBody"><a name="86235"> </a>Loads the local symbols as well as the global symbols into the target-based symbol table. This has consequences for tools such as the target shell. If the target-based symbol contains local variables, the target shell has access to both locally and globally declared symbols. Setting this bit means you must also reconfigure VxWorks with a downloaded symbol table. The relevant configuration macro is <b class="symbol_UC">INCLUDE_NET_SYM_TBL</b>. The VxWorks startup code assumes that the file containing the symbol table is resident on the same host as the boot image. The VxWorks startup code also assumes that the name of the symbol table file is the boot file name with an appended <b class="file">.sym</b> suffix. When reading the <b class="symbol_lc">.sym</b> file, the VxWorks image has the option of loading local symbols as well as global symbols into its target-resident symbol table. </div></td><td width="10"> </td></tr><tr valign="top"><td colspan=1 rowspan=1><div class="CellBody"><a name="86240"> </a></div></td><td width="10"> </td><td colspan=1 rowspan=1>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -