gettingstarted2.html

vxworks相关论文

</font><dl class="margin">

<dd><p class="Body"><a name="88701"> </a>By default, <b class="file">sysTffs.c</b> defines <b class="symbol_UC">INCLUDE_TFFS_BOOT_IMAGE</b>. Defining this constant automatically includes <b class="routine"><i class="routine">tffsBootImagePut</i></b><b>(&nbsp;)</b> in your <b class="file">sysTffs.o</b>.</p>
<dd><p class="Body"><a name="89040"> </a>Using <b class="routine"><i class="routine">tffsBootImagePut</i></b><b>(&nbsp;)</b>, you can bypass TrueFFS (and its translation layer) and write directly into any location in flash memory. Although the translation services of TrueFFS provide many advantages for managing the data associated with a file system, those same services also complicate the use of flash memory as a boot device. The only practical solution to this problem is to exclude TrueFFS from the boot area of flash. </p>
<dd><p class="Body"><a name="88702"> </a>Using <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>, it is possible to format flash memory so that the TrueFFS-managed area starts at an offset. This creates a fallow area within flash that is totally outside the reach of TrueFFS. To write a boot image into this fallow area, use <b class="routine"><i class="routine">tffsBootImagePut</i></b><b>(&nbsp;)</b>. </p>
</dl>

</dl>

<dl class="margin">

<dd><table border="0" cellpadding="0" cellspacing="0">
<tr valign="top">
<td valign="top" width="40">
<a name="88712"><br>
</a>
<img border="0" alt="*" src="icons/warning.gif">&nbsp;&nbsp;&nbsp;
</td>
<td>
<div class="Warning"><hr><b class="symbol_UC">WARNING: </b>
Because <b class="routine"><i class="routine">tffsBootImagePut</i></b><b>(&nbsp;)</b>lets you write directly to any area of flash, it is possible to accidentally overwrite and corrupt the TrueFFS-managed area of flash. For more on this and other dangers associated with this powerful utility, see the reference entry for <b class="routine"><i class="routine">tffsBootImagePut</i></b><b>(&nbsp;)</b>. <hr></div>
</td>
</tr>
</table>
</dl>

<dl class="margin">

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="88715">Including Support for Flash Show Functionality </a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="89050"> </a>Defining <b class="symbol_UC">INCLUDE_SHOW_ROUTINES</b> automatically includes <b class="routine"><i class="routine">tffsShow</i></b><b>(&nbsp;)</b>and <b class="routine"><i class="routine">tffsShowAll</i></b><b>(&nbsp;)</b> in <b class="file">sysTffs.o</b>. The <b class="routine"><i class="routine">tffsShow</i></b><b>(&nbsp;)</b> routine prints device information for a specified socket interface. It is particularly useful when trying to determine the number of erase units required to write a boot image. The <b class="routine"><i class="routine">tffsShowAll</i></b><b>(&nbsp;)</b> routine provides the same information for all socket interfaces registered with VxWorks. If you want to exclude these routines from TrueFFS, undefine them in you BSP's <b class="file">config.h</b>. However, be aware that doing so excludes the show routines from utilities other than TrueFFS for Tornado. </p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="89754">Configuring Socket Layer Features</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="91465"> </a>Although define statements in <b class="file">sysTffs.c</b> control the inclusion of translation layer modules and MTDs and other flash-related utilities, the bulk of the file is dedicated to defining the functions that comprise the socket component driver. These functions are a standardized API that bridges the gap between the device hardware and VxWorks.<sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup>
</p>
<dd><p class="Body"><a name="91579"> </a>The socket layer code in your BSP's <b class="file">sysTffs.c</b> must provide reasonable definitions for all the functions in the standardized socket layer API. What constitutes a reasonable function definition depends largely on the flash hardware you have chosen. TrueFFS for Tornado supports three general categories of flash hardware:</p>
</dl>

<dl class="margin">

<ul class="BulletSingle" type="disc"><li><a name="94144"> </a>PC flash cards (removable flash media) </li></ul>
<ul class="BulletSingle" type="disc"><li><a name="94145"> </a>DiskOnChip 2000 devices </li></ul>
<ul class="BulletSingle" type="disc"><li><a name="94146"> </a>board-resident flash arrays</li></ul>
</dl>

<dl class="margin">

<dd><p class="Body"><a name="91642"> </a>Both the DiskOnChip 2000 and the board-resident flash arrays are non-removable flash media. Their socket interface needs are relatively simple. As a result, simple "do little or nothing" routines are reasonable implementations for many of the standard socket API functions. All BSPs that support TrueFFS for Tornado contain socket code that can handle the simple socket interface needs of these board-resident flash media. </p>
<dd><p class="Body"><a name="95293"> </a>However, the PC flash cards are a removable flash medium. As a result, their socket interface needs are much more demanding. The interface provided with most BSPs is robust but rather simple. It assumes the socket contains a flash card, and it does not support hot swapping. Currently, there is a big-endian and a little-endian version of this simple PCIC driver. The big-endian version is implemented in the <b class="file">sysTffs.c</b> that ships with the ads860 BSP. The little-endian version is available in the pc386 and the pc486 BSPs. </p>
<dd><p class="Body"><a name="95297"> </a>Associated with the PCIC driver are two defines, <b class="symbol_UC">INCLUDE_SOCKET_PCIC0</b> and <b class="symbol_UC">INCLUDE_SOCKET_PCIC1</b>. Edit your BSP's <b class="file">sysTffs.c</b> and define or undefine these constants according to your needs: </p>
</dl>

<dl class="margin">

<dd><div class="Item"><a name="95298"> </a><b class="symbol_UC">INCLUDE_SOCKET_PCIC0 <br>
</b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="95299"> </a>Creates a socket interface driver for slot 0. </div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="95300"> </a><b class="symbol_UC">INCLUDE_SOCKET_PCIC1</b>  <br>
</div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="95301"> </a>Creates a socket interface driver for slot 1. </div>
<br>
</dl>

</dl>

</dl>

<dl class="margin">

<dd><p class="Body"><a name="95290"> </a>For the pc386 and pc486 BSPs, you have the option of including a more sophisticated socket interface driver than the simple PCIC driver. For more information on this interface, see <a href="gettingStarted4.html#95076"><i class="title">2.4&nbsp;Socket Layer Options for the pc386 and pc486 BSPs</i></a>. </p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="91549">2.2.2  &nbsp;&nbsp;Formatting Flash </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">tffsDevFormat</i></b><b>(&nbsp;)</b>function formats flash memory for use with TrueFFS. During the formatting process, this function erases the flash medium and then writes the TrueFFS data-management structures into a header at the start of each erase unit. </p>
<dd><p class="Body"><a name="87102"> </a>As input, <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>expects a drive number (socket component number) and a pointer to a <b class="symbol_lc">FormatParams</b> structure. The drive number identifies the flash medium to be formatted and is determined by the order in which the socket components were registered. The <b class="symbol_lc">FormatParams</b> structure passes in values that specify how you want the flash to be formatted. </p>
<dd><p class="Body"><a name="90341"> </a>To facilitate calling <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>from a target shell, the second parameter accepts a 0 (the value zero) instead of a <b class="symbol_lc">FormatParams</b> pointer. This value tells <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>to use the default <b class="symbol_lc">FormatParams</b> structure defined and initialized in <b class="file">dosformt.h</b>. The values defined in this default structure are good enough for most purposes. </p>
<dd><p class="Body"><a name="87079"> </a>However, if you need to share the flash medium between TrueFFS and a boot image, the default values in <b class="file">dosformt.h</b> are inadequate. This is because you need to format the flash so that the TrueFFS segment starts at an offset. To do this, you must submit a <b class="symbol_lc">FormatParams</b> structure whose <b class="symbol_lc">bootImageLen</b> member value is at least as large as the boot image. </p>
<dd><p class="Body"><a name="90342"> </a>When <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b> formats flash, it notes the offset, then erases and formats all erase units with starting addresses higher than the offset. The erase unit containing the offset address (and all previous erase units) are left completely untouched. This preserves any data stored before the offset address. </p>
</dl>

</dl>

<dl class="margin">

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="94963">Setting the Cluster Size </a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="94964"> </a>When formatting a flash device for use with TrueFFS, each sector on the medium is assigned to a cluster. The number of sectors assigned to each cluster is determined by <b class="symbol_lc">flMinClusterSize</b>, an <b class="symbol_lc">int</b> global variable defined in <b class="file">dosFormat.c</b>. Valid values for this global variable are non-negative integer powers of two (1, 2, 4, 8,...). The default value is 4. </p>
<dd><p class="Body"><a name="94968"> </a>For a finer granularity in describing the flash storage space, you can change the value of <b class="symbol_lc">flMinClusterSize </b>to something smaller than 4. However, because the number of FAT entries is limited, the addressable space on the flash medium is reduced if <b class="symbol_lc">flMinClusterSize</b> is reduced. For example, 16 megabytes is the largest drive addressable if <b class="symbol_lc">flMinClusterSize </b>is set to one. </p>
<dd><p class="Body"><a name="94990"> </a>Thus, choosing an <b class="symbol_lc">flMinClusterSize</b> value means making a compromise between a small address space and small inter-cluster dead spaces. For most file systems, a default <b class="symbol_lc">flMinClusterSize</b> of 4 is a reasonable compromise. </p>
</dl>

</dl>

<dl class="margin">

<dd><table border="0" cellpadding="0" cellspacing="0">
<tr valign="top">
<td valign="top" width="40">
<a name="94976"><br>
</a>
<img border="0" alt="*" src="icons/note.gif">&nbsp;&nbsp;&nbsp;
</td>
<td>
<div class="Note"><hr><b class="symbol_UC">NOTE: </b>
If you change <b class="symbol_lc">flMinClusterSize</b>, the value remains constant until you explicitly reset it or reboot. The value of <b class="symbol_lc">flMinClusterSize</b> does not revert to the default after rebooting, but not at the end of a format session. If a target system includes multiple flash drives that require different <b class="symbol_lc">flMinClusterSize </b>values, make sure you set <b class="symbol_lc">flMinClusterSize</b> correctly prior to formatting each drive. <hr></div>
</td>
</tr>
</table>
</dl>

<dl class="margin">

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="91881">About <b class="routine"><i class="routine">sysTffsFormat</i></b><b>(&nbsp;)</b></a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="91882"> </a>In some of the configuration examples that finish up this chapter, you are asked to call <b class="routine"><i class="routine">sysTffsFormat</i></b><b>(&nbsp;)</b>. Internally, <b class="routine"><i class="routine">sysTffsFormat</i></b><b>(&nbsp;)</b> calls <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>. As input to <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>, the <b class="routine"><i class="routine">sysTffsFormat</i></b><b>(&nbsp;)</b> function supplies a pointer to a <b class="symbol_lc">FormatParams</b> structure whose <b class="symbol_lc">bootImageLen</b> member specifies the offset after which to format the flash medium for use with TrueFFS. The area below this offset is excluded from TrueFFS. Typically, you would use such an area to store a boot image. For more information, see the BSP-specific reference entry for the <b class="routine"><i class="routine">sysTffsFormat</i></b><b>(&nbsp;)</b>defined in your BSP's <b class="file">sysTffs.c</b> file. </p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90292">Problems Associated with Expanding the Region Assigned to Boot Images </a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="94109"> </a>As mentioned above, when <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b> formats flash above an offset, it does not touch the flash below that offset. Normally, this is a good thing. However, problems can arise if any of the erase units below the offset had previously been formatted for use by TrueFFS. These erase units would contain TrueFFS formatting headers written by an earlier call to <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>. </p>
<dd><p class="Body"><a name="90293"> </a>When TrueFFS mounts a flash device, it scans the entire flash medium for TrueFFS formatting headers. It uses these headers to construct a map of the regions of flash memory that fall under its control. If the flash below the current offset happens to contain TrueFFS headers left over from a previous <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b> call, the TrueFFS mount can still see these headers and will fail as a result. <div class="frame">
<h4 class="EntityTitle"><a name="93606"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-1:&nbsp;&nbsp;Expanded Boot Region Requires a <b class="routine"><i class="routine">tffsRawio</i></b><b>(&nbsp;)</b> to Remove Leftover Erase Unit Header</font></a></h4>

<dl class="margin">

<div class="Anchor"><a name="93608"> </a><img class="figure" border="0" src="images/gettingStarteda4.gif">
</div>



</dl>

</div>
</p>
<dd><p class="Body"><a name="84540"> </a>To overcome this problem, you can use <b class="routine"><i class="routine">tffsRawio</i></b><b>(&nbsp;)</b>to do a physical erase of the problem erase units. However, this is a very powerful and dangerous utility. If misused, it can permanently damage flash memory. During the development phase of your embedded system, you can probably trust yourself to use it carefully. However, if you need to make the functionality of this utility available in the deployed version of your product, you should surround that functionality with protections appropriate to your application and its users. </p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="90478">2.2.3  &nbsp;&nbsp;Creating TrueFFS Block Devices</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="90645"> </a>Before you can create a logical TrueFFS block device, you need to have already run <b class="routine"><i class="routine">tffsDrv</i></b><b>(&nbsp;)</b>. If you configured VxWorks correctly, this is handled for you automatically at boot time. Running <b class="routine"><i class="routine">tffsDrv</i></b><b>(&nbsp;)</b>initializes TrueFFS for Tornado, which includes setting up the mutual exclusion semaphore, global variables, and data structures needed to manage TrueFFS. This initialization also includes the registration of socket component drivers for all the flash devices on the target. </p>
<dd><p class="Body"><a name="93335"> </a>Registering a socket component driver with TrueFFS starts with getting an <b class="file">FLSocket</b> structure from a preallocated 5-element TrueFFS-internal array of <b class="file">FLSocket</b> structures. The next step is to update that <b class="file">FLSocket</b> structure to contain data and pointers to functions that handle the basic hardware interface to the flash device. </p>
<dd><p class="Body"><a name="93384"> </a>When TrueFFS needs to interact with the socket hardware for a particular flash device, it uses the drive number (0 through 4) as an index into its array of <b class="symbol_lc">FLSocket</b> structures. TrueFFS then uses the functions referenced in that structure to handle its hardware interface needs. Although these socket interface functions do not quite provide a block device interface, they do provide an interface that is good enough for utilities such as <b class="routine"><i class="routine">tffsDevFormat</i></b><b>(&nbsp;)</b>, a function you can use to format the flash medium for use with TrueFFS. This ability at this stage is important as it is not possible to create a TrueFFS block device for a flash medium that has not been previously formatted for use with TrueFFS. </p>
<dd><p class="Body"><a name="91310"> </a>After registering a socket component driver for a flash device, it is possible to create a TrueFFS block device on top of the socket component driver. To do this, call <b class="routine"><i class="routine">tffsDevCreate</i></b><b>(&nbsp;)</b>. As input, you must specify a number (0 through 4, inclusive) that identifies the socket component driver on top of which to construct the TrueFFS block device. The <b class="routine"><i class="routine">tffsDevCreate</i></b><b>(&nbsp;)</b>call uses this number as an index into the array of <b class="symbol_lc">FLSocket</b> structures. This number is visible later to dosFs as the driver number. </p>
<dd><p class="Body"><a name="90661"> </a>After creating the TrueFFS block device, you must mount dosFs onto the device. To do this, you must call <b class="routine"><i class="routine">dosFsDevInit</i></b><b>(&nbsp;)</b>. After mounting dosFs, you can read and write from flash memory just as you would from a standard disk drive. In the examples at the end of this chapter, there are no calls to <b class="routine"><i class="routine">tffsDevCreate</i></b><b>(&nbsp;)</b> or <b class="routine"><i class="routine">dosFsDevInit</i></b><b>(&nbsp;)</b>. Instead, there is a call to <b class="routine"><i class="routine">usrTffsConfig</i></b><b>(&nbsp;)</b>. Internally, this function handles the call to <b class="routine"><i class="routine">tffsDevCreate</i></b><b>(&nbsp;)</b>, <b class="routine"><i class="routine">dosFsDevInit</i></b><b>(&nbsp;)</b>, and the other functions necessary to create a TrueFFS block device and mount dosFs on that device.<sup><a href="#foot"><b class="FootnoteMarker">2</b></a></sup>
</p>
</dl>

</dl>


<a name="foot"><hr></a>

<p class="FootnoteNumberMarker">1:&nbsp;
<span class="Footnote"><a name="91585"> </a>For more information the standardized socket layer API, see <a href="binding.html#84152"><i class="title">3.&nbsp;Writing Socket Component Drivers and MTDs</i></a>. </span>
<p class="FootnoteNumberMarker">2:&nbsp;
<span class="Footnote"><a name="91987"> </a>To see the source code for <b class="routine"><i class="routine">usrTffsConfig</i></b><b>(&nbsp;)</b>, look in <b class="file">target/src/config/usrTffs.c</b>. </span>

<p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a></a><a href="gettingStarted.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="gettingStarted1.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="gettingStarted3.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p>

</body>

</html>
<!---
by WRS Documentation (), Wind River Systems, Inc.
    conversion tool:  Quadralay WebWorks Publisher 4.0.11
    template:         CSS Template, Jan 1998 - Jefro --->