文件列表:

Documentation (0, 2006-08-20)
Documentation\DOC Driver 1.0 Block Device (BD) Software Developer Kit (SDK) Developer Guide Rev. 0.1.pdf (347770, 2006-08-10)
Documentation\DOC Driver 1.0 Extended Functions Developer Guide Rev. 0.1.pdf (121336, 2006-08-10)
examples (0, 2006-08-20)
examples\drivers (0, 2006-08-20)
examples\drivers\vxworks (0, 2006-08-20)
examples\drivers\vxworks\custom (0, 2006-08-20)
examples\drivers\vxworks\custom\flcustom.c (5301, 2006-08-20)
examples\drivers\vxworks\custom\flcustom.h (7345, 2006-08-20)
examples\drivers\vxworks\fldrvvxw.c (126103, 2006-08-20)
examples\drivers\vxworks\fldrvvxw.h (14325, 2006-08-20)
examples\drivers\vxworks\system (0, 2006-08-20)
examples\drivers\vxworks\system\flsystem.h (15590, 2006-08-20)
examples\drivers\vxworks\system\flsysvxw.c (33218, 2006-08-20)
src (0, 2006-08-20)
src\bddefs.h (4054, 2006-08-20)
src\bdkemul.h (5511, 2006-08-20)
src\blockdev.h (83495, 2006-08-20)
src\defs.c (30607, 2006-08-20)
src\defs.h (17866, 2006-08-20)
src\docbdk.h (29554, 2006-08-20)
src\docdrv.c (12785, 2006-08-20)
src\dochstub.c (4307, 2006-08-20)
src\dochstub.h (3172, 2006-08-20)
src\dochtl.c (15454, 2006-08-20)
src\dochtl.h (3549, 2006-08-20)
src\doch_api.c (318890, 2006-08-20)
src\doch_api.h (5593, 2006-08-20)
src\doch_ata.c (104469, 2006-08-20)
src\doch_ata.h (22748, 2006-08-20)
src\doch_func.h (5730, 2006-08-20)
src\doch_sys.h (4102, 2006-08-20)
src\docsoc.c (16704, 2006-08-20)
src\docsys.c (53287, 2006-08-20)
src\docsys.h (4080, 2006-08-20)
src\dosformt.c (66363, 2006-08-20)
src\dosformt.h (16696, 2006-08-20)
src\fatfilt.c (67909, 2006-08-20)
src\fatfilt.h (6996, 2006-08-20)
... ...

******************************************************************************** * * * mDOC driver for VxWorks(R). * * * * Installation Guide. * * * * Version 1.0.0.0 Alpha released on Aug 24 2006 * * Based on DOC driver version 1.0.0 Alpha * * * * Copyright msystems (c) 2006 * * * ******************************************************************************** * * * Tornado, VxWorks, VxSim, Wind River Systems, are registered trademarks or * * service marks of Wind River Systems, Inc. This is the partial list. For a * * complete list of Wind River trademarks and service marks, see the following * * URL: * * * * http://www.windriver.com/company/terms/trademark.html * * * * All the other trademarks mentioned herein are the property of their * * respective owners. * * * ******************************************************************************** * * * I M P O R T A N T * * * * This version works ONLY with mDOC H3 product family * * * ******************************************************************************** VERSION MARK ------------ Version 1.0.0.0 Alpha Aug 24, 2006 GENERAL -------- Updated manuals and documentation, can be found on msystems web site (http://www.m-systems.com). For more information, contact msystems via e-mail to info@m-systems.com, or by calling your local msystems office (see Chapter 12 below). CONTENTS -------- 1. Introduction 2. Installing mDOC driver 3. Booting VxWorks from mDOC 4. Formatting mDOC from VxWorks application 5. Excluded. 6. Considerations related to unexpected power shutdowns 7. Excluded. 8. Driver's runtime configuration options 9. Access to advanced features of mDOC 10. Built-in diagnostics 11. Known limitations 12. Contact information 1. INTRODUCTION --------------- 1.1. When used under VxWorks, mDOC is managed by a dedicated device driver. mDOC driver is normally attached to the standard VxWorks's file system (dosFs-2). VxWorks disk oriented calls (including all ANSI C file I/O facilities) work correctly with mDOC. 1.2. mDOC driver uses term "socket" to refer to either of the following: - single mDOC MD25xx part, or up to 2 such cascaded parts The term 'cascaded' refers to the parts which all share the same address in the host's address space, and form a single continuous flash media of capacity equal to the sum of capacities of individual cascaded parts. mDOC driver supports up to 4 "sockets". 1.3. The flash media that constitutes mDOC "socket", can be optionally divided into up to six independent regions (refered to as "disks"). All such regions ("disks") can be read/write accessed independently from the other "disks" of that "socket", and can have it's own hardware-level read/write access permissions. 1.4. Each "disk" could be partitioned (by using dosFs-2's 'dpartLib' library under VxWorks) into up to 11 file system partitions (primary and extended). Each such file system partition could be individually formatted with any type of FAT that dosFs-2 file system supports. 1.5. The mDOC driver is fully re-entrant, and takes care of all issues related to the multitasking VxWorks environment, thereby freeing application from any concerns of this kind. 2. INSTALLING mDOC DRIVER ------------------------------- 2.1. This version works ONLY with mDOC H3 product family. 2.2. Remove all object modules and libraries associated with the previous versions of mDOC driver,as well as with WindRiver's TFFS, from your Tornado installation. Here is the list of object modules that you will need to remove: MSYSVXW-.o abs_lyr.o bch_hm.o bdstub.o blockdev.o defs.o diskonc.o doc2exb.o docbdk.o docdrv.o dochstub.o dochtl.o doch_api.o doch_ata.o docsoc.o docsys.o docsysp.o dosformt.o fatfilt.o fatlite.o flbase.o flcustom.o fldrvvxw.o flflash.o flioctl.o flmalloc.o flmtl.o flsim.o flsocket.o flsysvxw.o fltl.o g4_lgc.o g4_mtd.o geometry.o hal_nor.o h1h1glgc.o h1h1gmtd.o h1h_lgc.o h1h_mtd.o h1_lgc.o h1_mtd.o inftl.o m512_lgc.o m512_mtd.o matchalg.o mdocplus.o nfdc2148.o nftllite.o oren_lgc.o oren_mtd.o protectp.o reedsol.o saftl.o tffsDrv.o tffsLib.o tffs_api.o ===> NOTE. Please be advised that object module names are case sensitive, i.e. "MSYSVXW-PPC860.o" and "MSYSVXW-ppc860.o" refer to two different object modules that can be both present in the same library. You will need to remove all such object modules from this library. If you are using Tornado versions 2.0x and 2.1, skip to Section 2.2.1. If you are using Tornado version 2.2 or higher or Workbench version 2.x , skip to Section 2.2.2. ===> NOTE. You can find out which Tornado version is it by look at file SETUP.LOG in Tornado installation directory. 2.2.1. If you are using Tornado version 2.2 or higher or Workbench 2.x, skip this Section, and follow instructions in Section 2.2.2 instead. 2.2.1.1. List the contents of Tornado' object library that you are linking your application with (/target/libgnuvx.a) to check if it contains any of the object modules listed in Section 2.2. To find out which Tornado's object library your application is linked with, and which archiver tool to use with this library, locate your applications' BSP directory, and check how macro 'CPU' is defined in Makefile there. The object library that your application is linked with, will be /target/libgnuvx.a. For example, in case of WindRiver' mcp750 PowerPC BSP, 'CPU' is defined as "PPC604" in /target/config/mcp750/Makefile. Respectively all applications that are based on this BSP, are linked with /target/libPPC604gnuvx.a library, and the name of the archiver tool to use with this library is "arppc". ===> NOTE. On Windows hosts, Tornado tools can be added to system's PATH by executing /host/x86-win32/bin/torVars.bat. To list contents of /target/lib/libgnuvx.a object library, use appropriate archiver tool with '-tv' command line option. For example, to list contents of /target/lib/libPPC860gnuvx.a library: arppc -tv /target/lib/libPPC860gnuvx.a If any of the above listed object modules will be present in your /target/libgnuvx.a library, use appropriate archiver with '-dv' command line option to remove this object module from the library. For example, to remove object module fltl.o from /target/lib/libPPC860gnuvx.a library: arppc -dv /target/lib/libPPC860gnuvx.a fltl.o 2.2.1.2. Delete all object modules listed in Section 2.2, from object directory /target/lib/objgnuvx. Skip to Section 2.3. 2.2.2. If you are using Tornado versions 2.0x or 2.1, skip this Section, and follow instructions in Section 2.2.1 instead. 2.2.2.1. Check if directory /target/lib///common contains WindRiver's TFFS library libtffs.a. For example, if you link your application with PowerPC 440 libraries, you should check if library /target/lib/ppc/PPC440/common/libtffs.a exists. If it does, rename this library as libtffs.a.windriver. 2.2.2.2. Check if directory /target/lib///common contains directory 'objtffs'. For example, if you link your application with PowerPC 440 libraries, you should check if directory /target/lib/ppc/PPC440/common/objtffs exists. If it does, rename this directory as "objtffs.windriver". 2.2.2.3. Check if directory /target/lib///common contains existing mDOC driver library libmsystems.a. For example, if you link your application with PowerPC 440 libraries, you should check if library /target/lib/ppc/PPC440/common/libmsystems.a exists. If it does, delete this library. 2.2.2.4. Check if directory /target/lib/objtest contains any of the object modules listed in Section 2.2, and if it does, remove them. For example, if you link you application with PowerPC 440 libraries, and use DIAB compiler, you should check directory /target/lib/objPPC440diabtest. 2.3. mDOC driver for VxWorks is distributed in source code form, and must be compiled at the customer site. In order to do this, create directory in your application's source code tree where you want to place mDOC driver's source code to, and copy all the files listed below, from their indicated locations to that directory: ===> NOTE. If any of file names listed below, appear on your UNIX host in upper case ("FLSYSTEM.H", "FLCUSTOM.H" etc.) or mixed case ("Flsystem.h", "iNFTL.C" etc.), change all these file names to lowercase ("flsystem.h", "flcustom.h" etc.). /src/defs.c /src/docdrv.c /src/doch_api.c /src/doch_ata.c /src/dochstub.c /src/dochtl.c /src/docsoc.c /src/docsys.c /src/dosformt.c /src/fatfilt.c /src/flbase.c /src/flioctl.c /src/flmalloc.c /src/geometry.c /src/hal_nor.c /src/tffs_api.c /examples/drivers/vxworks/fldrvvxw.c /examples/drivers/vxworks/system/flsysvxw.c /examples/drivers/vxworks/custom/flcustom.c Copy all the headers listed below, from their indicated locations to /target/h directory: /src/_common.h /src/_dochapi.h /src/_docsys.h /src/_fltl.h /src/bddefs.h /src/bdkemul.h /src/blockdev.h /src/defs.h /src/docbdk.h /src/doch_api.h /src/doch_ata.h /src/doch_func.h /src/doch_sys.h /src/dochstub.h /src/dochtl.h /src/docsys.h /src/dosformt.h /src/fatfilt.h /src/flbase.h /src/flbuffer.h /src/flchkdef.h /src/flcommon.h /src/flioctl.h /src/flmalloc.h /src/flstdcmp.h /src/flstruct.h /src/flsysfun.h /src/flsystyp.h /src/fltl.h /src/hal_nor.h /src/hib.h /src/part_inf.h /src/tffs_api.h /examples/drivers/vxworks/fldrvvxw.h /examples/drivers/vxworks/custom/flcustom.h /examples/drivers/vxworks/system/flsystem.h 2.4. Make sure your BSP configuration header file (/target/config//config.h) excludes the following VxWorks components: #undef INCLUDE_TFFS #undef INCLUDE_PCMCIA /* include PCMCIA driver */ 2.6. To tell mDOC driver where to look for mDOC(s), application must call routine tffsSetup(). ===> NOTE. The tffsSetup() routine must be called exactly once, BEFORE driver has been initialized by routine tffsDrv(). Here is declaration of routine tffsSetup() taken from fldrvvxw.h: extern void tffsSetup (int mDOCs, long *addressRange); where 'mDOCs' is the number of mDOC "sockets" installed in the system; 'addressRange' is an array of address pairs bounding regions to search for mDOCs. For instance, if your particular board allows installation of up to three mDOCs, and regions to search for mDOCs are as follows: [0xc00d0000 ... 0xc00d1fff] 1st mDOC [0xc00d2000 ... 0xc00d3fff] 2nd [0xc00d4000 ... 0xc00d5fff] 3rd then you should include the following code fragment into your application: #include "fldrvvxw.h" /* address ranges to search for 3 mDOCs */ long tffsAddresses[] = { 0xc00d0000, 0xc00d1fff, /* 1st mDOC */ 0xc00d2000, 0xc00d3fff, /* 2nd */ 0xc00d4000, 0xc00d5fff; /* 3rd */ }; /* tell driver to detect up to 3 mDOCs */ tffsSetup (3, tffsAddresses); In a common case when there is single mDOC installed in the system at well known address, it makes sense to prevent driver from scanning host address space for mDOC. In such cases, both upper and lower bounds of the search range could be set to the exact mDOC address. For instance, if mDOC is always installed at address 0xc00d0000, then application can tell driver to look for mDOC at this particular address only: #include "fldrvvxw.h" /* exact address to look for single mDOC */ long tffsAddresses[] = { 0xc00d0000, 0xc00d0000 }; /* tell driver to detect single mDOC */ tffsSetup (1, tffsAddresses); 2.7. Excluded. 2.8. mDOC driver features number of configuration options, which are described in detail in Chapter 8. Default settings of these options should be adequate for most applications. If you wish, for some reason, to change some of these configuration options, then do it at this stage. ===> NOTE. All driver's configuration options must be set to their desired values BEFORE calling driver's initialization routine tffsDrv(). Once routine tffsDrv() has been called, configuration options must NOT be changed. 2.9. mDOC driver must be initialized by calling routine tffsDrv(): #include "fldrvvxw.h" if( tffsDrv() != OK ) { /* error */ } ===> NOTE. This routine must be called exactly once, AFTER call to routine tffsSetup(). 2.10. In case if there is single mDOC in the system, skip this Section, and proceed with Section 2.11. In this case it is known that there is only one "socket" in the system (see Section 1.2 for definition of term "socket"). In case if there are multiple mDOCs in the system, you could find out how many "sockets" driver has actually detected during tffsDrv() call by executing the following code fragment: #include "fldrvvxw.h" int totalSockets = tffsSockets (); 2.11. To find out how many "disks" (see Chapter 1 for the definition of term "disk") exists on each mDOC "socket", execute the following code fragment: #include "fldrvvxw.h" int disksOnSocket[4] = { 1, 0, 0, 0 }; int iSocket; /* find out number of "disks" on each "socket" */ for (iSocket = 0; iSocket < totalSockets; iSocket++) { disksOnSocket[iSocket] = tffsDisksOnSocket (iSocket); } 2.12. Excluded. 2.13. Excluded. 2.14. It is assumed that you are using dosFs-2 VxWorks file system. An old dosFs file system is not supported by this driver. Make sure that you have included all dosFs-2 file system components in your application. In case of Tornado-2, these components can be seen in the 'VxWorks' view of Workspace window, under "operating system components -> IO system components -> DOSFS2 File System components". In case of Workbench 2.x, these components can be seen in the 'Components' view of the "Kernel configuration" under "operating system components -> IO system components -> dosFs File System Components(dosFs2)". 2.14.1. Application must call routine tffsDevCreate() to create VxWorks 'block device' for every "disk" of every "socket". Here is declaration of this routine taken from fldrvvxw.h : extern BLK_DEV* tffsDevCreate (int handle, int flags); ===> NOTE. mDOC parts in TSOP and BGA packages are normally shipped from the factory unformatted, which causes routine tffsDevCreate() to fail and return NULL. You will need to format these mDOC parts as described in Chapter 4, and re-attempt tffsDevCreate() call. Argument 'handle' is constructed by macro tffsMakeHandle(), based on "socket" and "disk" sequential numbers: #include "fldrvvxw.h" int handle = tffsMakeHandle (socketNo, diskNo); Any of the following optional flags can be OR-ed into argument 'flags': FL_VERIFY_WRITE2 FL_VERIFY_WRITE3 Flag FL_VERIFY_WRITE2, when OR-ed into argument 'flags', instructs mDOC driver to follow every critical 'write' operation with respective read-back-a ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：