📄 binding4.html
字号:
<dl class="margin"><dl class="margin"><dl class="margin"><dd><div class="Indent5"><a name="98735"> </a>See <a href="binding4.html#100024"><i class="title">3.4.2 Writing a Map Function for an MTD</i></a>, and <a href="binding2.html#93431"><i class="title">map</i></a>. </div><br></dl></dl></dl></dl></dl><dd><div class="Item"><a name="98695"> </a><b class="symbol_lc">read</b> </div><dl class="margin"><dl class="margin"><dl class="margin"><dl class="margin"><dl class="margin"><dd><div class="Indent5"><a name="98734"> </a>See <a href="binding4.html#100209"><i class="title">3.4.3 Writing a Read Function for an MTD</i></a>, and <a href="binding2.html#93432"><i class="title">read</i></a>. </div><br></dl></dl></dl></dl></dl></dl><dl class="margin"><dd><p class="Body"><a name="99054"> </a>After setting the members listed above, this function should return <b class="symbol_UC">flOK</b>. </p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="99423">Special Utilities for Use with NOR Flash Arrays</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="102228"> </a>For most NOR flash arrays, you can use the standard routines <b class="routine"><i class="routine">flIntelIdentify</i></b><b>( )</b><i class="i"> </i>and <b class="routine"><i class="routine">flIntelSize</i></b><b>( )</b><i class="i"> </i>to automatically detect the JEDEC id, the interleaving, and the size of the flash array. Call the <b class="routine"><i class="routine">flIntelIdentify</i></b><b>( )</b><i class="i"> </i>routine first. Its interface is:<sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup></p><dl class="margin"><dd><pre class="Code2"><b><a name="99129">FLStatus flIntelIdentify( FLFlash vol, void (*amdCmdRoutine) (FLFlash *, long int, unsigned char), long int chipOffset)</a></b></pre></dl><dd><p class="Body"><a name="99205"> </a><b class="routine"><i class="routine">flIntelIdentify</i></b><b>( )</b><i class="i"> </i>uses the chip's <b class="symbol_UC">READ_ID</b> command to detect the device and retrieve its JEDEC id and chip interleaving. Set <i class="textVariable">amdCmdRoutine</i><i class="i"> </i>to NULL for Intel flash devices. For AMD & Fujitsu flash devices, set <i class="textVariable">amdCmdRoutine</i><b class="symbol_lc"> </b>to the address of a routine that writes a command to the flash device through the special "unlock sequence" that is necessary for this kind of flash. Use <i class="textVariable">chipOffSet</i> to pass in the offset on the chip that is used for reading the chip id. A value of 0 (offset zero) is almost always appropriate. </p><dd><p class="Body"><a name="99206"> </a>If <b class="routine"><i class="routine">flIntelIdentify</i></b><b>( )</b> fails, your MTD identification routine should immediately return failure. If <b class="routine"><i class="routine">flIntelIdentify</i></b><b>( )</b> succeeds, it sets <b class="symbol_lc">vol.type</b><i class="i"> </i>and <b class="symbol_lc">vol.interleaving</b>. Your MTD identification routine should then check the JEDEC id stored in <b class="symbol_lc">vol.type</b>. If your MTD can handle this type of flash, it should set <b class="symbol_lc">vol.chipSize</b><i class="i"> </i>to its correct value, and then call <b class="routine"><i class="routine">flIntelSize</i></b><b>( )</b>, defined as:</p><dl class="margin"><dd><pre class="Code2"><b><a name="99133">FLStatus flIntelSize( FLFLash vol, void (*amdCmdRoutine) (FLFlash *, long int, unsigned char), long int chipOffset) </a></b></pre></dl><dd><p class="Body"><a name="99357"> </a>This function is able to detect the array size correctly even when an address wraparound exists at the end of the flash array, although all chips in the flash array must be of the same type. If this function succeeds, it sets <b class="symbol_lc">vol.noOfChips </b>correctly. If this routine fails, your MTD identification routine must return failure.</p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="100297">Reading the CIS through <b class="routine"><i class="routine">flMap</i></b><b>( )</b></a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="100298"> </a>Often an MTD needs to identify a PCMCIA flash card through its CIS or Attribute Memory. To access Attribute Memory, use the <b class="routine"><i class="routine">flMap</i></b><b>( )</b><i class="i"> </i>function, as described in <a href="binding4.html#100024"><i class="title">3.4.2 Writing a Map Function for an MTD</i></a>. The <i class="i">address </i>parameter is the Attribute Memory address plus<b> </b>128 M. For example:</p><dl class="margin"><dd><pre class="Code2"><b><a name="100299">void far *cis = flMap(vol, 0x8000000l);</a></b></pre></dl><dd><p class="Body"><a name="100300"> </a>Note that both the socket hardware and the card must recognize a separate Attribute Memory Space. If one of them does not, you will find yourself mapped to the equivalent address in common memory. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="100024">3.4.2 Writing a Map Function for an MTD</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="102273"> </a>On many systems, the flash array is connected to the system bus through an intelligent controller (PCMCIA, for example). From the programmer's perspective, this connection makes it appear as if there is a host address space window that is sliding along the flash array. This feature is used extensively by TrueFFS to optimize read operations on NOR flash array when TrueFFS needs to access system meta data. </p><dd><p class="Body"><a name="102276"> </a>Because system meta data is distributed evenly across the region of the flash array, TrueFFS needs to issue many calls to the MTD read routine in order to collect the data. Thus it is more efficient to map an entire region of the flash array into the host address space (using the MTD map routine) and then read directly from the memory window. </p><dd><p class="Body"><a name="100038"> </a>Initially, TrueFFS assigns <b class="symbol_lc">FLFlash.map</b> to point to a default mapping function called <b class="routine"><i class="routine">flashMap</i></b><b>( )</b>. This default function is appropriate for flash devices that can be mapped directly into host memory. Internally, this function makes only one call, a call to <b class="routine"><i class="routine">flMap</i></b><b>( )</b>:</p><dl class="margin"><dd><pre class="Code2"><b><a name="100077">void FAR0 *flMap ( FLSocket vol, CardAddress address ) </a></b></pre></dl><dd><p class="Body"><a name="100114"> </a>This function maps the flash window (described in the submitted <b class="symbol_lc">FLSocket</b> structure) to a specified card address and returns a pointer to that location, which is at some offset within the window. </p><dd><p class="Body"><a name="100191"> </a>After calling <b class="routine"><i class="routine">flMap</i></b><b>( )</b>, the specified part of the flash array is mapped to the socket window and is effectively a part of the local host memory. Thus, it is accessible through normal addressing. To address subsequent bytes on the card, increment the <i class="i">address</i> pointer--but only so far as the socket window extends in host memory. At some offset you are no longer addressing memory on the card. Because the minimum window size is 4 Kilobytes, a safe practice is to never cross a 4 KByte boundary when adding offsets to a window location. </p><dd><p class="Body"><a name="102282"> </a>Of course, if the entire flash array is visible in the host address space, the map routine need do nothing more than return a pointer to the specified address in flash memory. </p><dd><p class="Body"><a name="100172"> </a>Unfortunately, not all flash devices allow this direct mapping of flash memory into host memory. For some devices, it is necessary to map through a buffer. For example, the MTD defined in <b class="file">target/src/drv/tffs/nfdc2048.c</b> takes this approach. The identification routine of this MTD assigns <b class="symbol_lc">FLFlash.map</b> to <b class="symbol_lc">cdsnMap</b>, a pointer to <b class="routine"><i class="routine">cdsnMap</i></b><b>( )</b>, which is defined as follows:</p><dl class="margin"><dd><pre class="Code2"><b><a name="100149">static void FAR0 * cdsnMap ( FLFlash vol, CardAddress address, int length ) { cdsnRead(&vol,address,thisBuffer,length, 0); vol.socket->remapped = TRUE; return (void FAR0 *)thisBuffer; }</a></b></pre></dl><dd><p class="Body"><a name="102281"> </a>There is a common case of RFA fully visible in the host address space. In this marginal case, the only thing the map routine needs to do is to return a pointer to the specified address in flash memory. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="100209">3.4.3 Writing a Read Function for an MTD </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="100541"> </a>If the flash device can be mapped directly into flash memory, it is generally a simple matter to read from it. TrueFFS supplies a default function that does a remap and simple memory copy to retrieve the data from the specified area. If the mapping is done through a buffer, you must provide your own read routine. </p><dd><p class="Body"><a name="102277"> </a>Typically, you should write your read routine as generically as possible. That is, it should read only a character or a word or a long word at a time, and that it should be able to handle an unaligned read as well as a read that crosses chip boundaries. </p><dd><p class="Body"><a name="102278"> </a>For an example of an MTD that provides its own read routine, see the <b class="routine"><i class="routine">cdsnRead</i></b><b>( )</b> function defined in <b class="file">target/src/drv/tffs/nfdc2048.c</b>. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="100542">3.4.4 Writing Write and Erase Functions for an MTD </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="100543"> </a>Your write and erase functions should be as generic as possible. That is, the write should write only a character or a word or a long word at a time, and it should be able to handle an unaligned write as well as a write that crosses chip boundaries. Similarly, the erase function should be able to handle an erase that crosses chip boundaries. As input, the erase can expect a block number. Use the value of the <b class="symbol_lc">erasableBlockSize</b> member of the <b class="symbol_lc">FLFlash </b>structure to translate this block number to the offset within the flash array. </p><dd><p class="Body"><a name="102288"> </a>When writing these functions, you probably want to use the MTD helper functions <b class="routine"><i class="routine">flNeedVpp</i></b><b>( )</b>, <b class="routine"><i class="routine">flDontNeedVpp</i></b><b>( )</b>,<i class="i"> </i>and <b class="routine"><i class="routine">flWriteProtected</i></b><b>( )</b>. The interfaces for these routines are as follows:</p><dl class="margin"><dd><pre class="Code2"><b><a name="100655">FLStatus flNeedVpp(FLSocket vol) void flDontNeedVpp(FLSocket vol) FLBoolean flWriteProtected(FLSocket vol)</a></b></pre></dl><dd><p class="Body"><a name="100604"> </a>Use <b class="routine"><i class="routine">flNeedVpp</i></b><b>( )</b>if you need to turn on the Vpp (programming voltage) for the chip. Internally, <b class="routine"><i class="routine">flNeedVpp</i></b><b>( )</b> bumps a counter, <b class="symbol_lc">FLSocket.VppUsers</b>, and then calls the function referenced in <b class="symbol_lc">FLSocket.VppOn</b>. After calling <b class="routine"><i class="routine">flNeedVpp</i></b><b>( )</b>, check its return status to verify that it succeeded in turning on Vpp.<sup><a href="#foot"><b class="FootnoteMarker">2</b></a></sup></p><dd><p class="Body"><a name="100637"> </a>When done with the write or erase that required Vpp, call <b class="routine"><i class="routine">flDontNeedVpp</i></b><b>( )</b>to decrement the <b class="symbol_lc">FLSocket.VppUsers</b> counter. This <b class="symbol_lc">FLSocket.VppUsers </b>counter is part of a delayed-off system. While the chip is busy, TrueFFS keeps the chip continuously powered. When the chip is idle, TrueFFS turns off the voltage to conserve power. </p><dd><p class="Body"><a name="100605"> </a>Use <b class="routine"><i class="routine">flWriteProtected</i></b><b>( )</b>to test that the flash device is not write protected. MTD write and MTD erase routines must not do any flash programming before checking that writing to the card is allowed. The Boolean function <b class="routine"><i class="routine">flWriteProtected</i></b><b>( )</b> returns TRUE if the card is write-protected and FALSE otherwise.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="100450">3.4.5 Registering Your MTD with TrueFFS </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="100451"> </a>When TrueFFS tries to match an MTD to a flash device, it executes the functions referenced in <b class="symbol_lc">mtdTable[ ]</b>, which is defined in <b class="file">target/src/drv/tffs/tffsConfig.c </b>as follows: </p></dl><dl class="margin"><dd><pre class="Code"><b><a name="101838">MTDidentifyRoutine mtdTable[] = /* MTD tables */ { #ifdef INCLUDE_MTD_I28F016 i28f016Identify, #endif /* INCLUDE_MTD_I28F016 */ #ifdef INCLUDE_MTD_I28F008 i28f008Identify, #endif /* INCLUDE_MTD_I28F008 */ #ifdef INCLUDE_MTD_AMD amdMTDIdentify, #endif /* INCLUDE_MTD_AMD */ #ifdef INCLUDE_MTD_CDSN cdsnIdentify, #endif /* INCLUDE_MTD_CDSN */ #ifdef INCLUDE_MTD_DOC2 doc2Identify, #endif /* INCLUDE_MTD_DOC2 */ #ifdef INCLUDE_MTD_CFISCS cfiscsIdentify, #endif /* INCLUDE_MTD_CFISCS */ };</a></b></pre></dl><dl class="margin"><dd><p class="Body"><a name="100486"> </a>If you write a new MTD and want to make it available to TrueFFS, you must add its registration routine to this table. When doing so, you should probably surround the function name with conditional include statements. The symbolic constants that control these conditional includes are defined in the BSPs <b class="file">config.h</b>. Using these constants, your end users can conditionally include specific MTDs. When you add your MTDs identification routine to this table, you should also add a new constant to the BSP's <b class="file">config.h</b>. </p></dl></dl><a name="foot"><hr></a><p class="FootnoteNumberMarker">1: <span class="Footnote"><a name="102238"> </a>Both <b class="routine"><i class="routine">flIntelIdentify</i></b><b>( )</b> and <b class="routine"><i class="routine">flIntelSize</i></b><b>( )</b> assume 8-bit access to the flash array. If this is inappropriate for your particular flash device, you could directly set the values of the relevant members of the <b class="symbol_lc">vol</b> structure. </span><p class="FootnoteNumberMarker">2: <span class="Footnote"><a name="100672"> </a>An MTD does not need to touch Vcc. TrueFFS turns Vcc on before calling an MTD function. </span><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a></a><a href="binding.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="binding3.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="binding5.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 --->⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -