DOC1.0_VxWorks_1000_Alpha
所属分类:VxWorks
开发工具:Unix_Linux
文件大小:676KB
下载次数:15
上传日期:2008-07-09 16:27:01
上 传 者:
fourstones
说明: mDOC电子盘在VxWorks环境下的驱动程序
(err)
文件列表:
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 ... ...
近期下载者:
相关文件:
收藏者: