文件列表:

fldrvvxw.h (7308, 2000-11-27)
flioctl.h (7673, 2000-08-04)
MSYSVXW.o (55624, 2000-11-28)

=================================================================== Copyright M-Systems (c) 2000 DiskOnChip (R) Software December 4, 2000 Installation Guide for DiskOnChip(R) Product Family on VxWorks(R)/x86 Operating System. VERSION MARK ------------ Version 4.2.1 December 4, 2000 Version 4.2 September 15, 2000 Version 4.1 May 25, 2000 Version 1.21 July 26, 1999 =================================================================== General -------- The following directory contains VxWorks programming files for M-Systems' DiskOnChip 2000, DiskOnChip DIMM2000 and DiskOnChip Millennium products, all capacities. In the remainder of this Readme, the term "DiskOnChip" is used to describe the above mentioned DiskOnChip Family Products. For detailed information on how to use DiskOnChip utilities for DOS, please refer to the DiskOnChip Utilities User Manual. For the most updated manuals and documentation, please see M-Systems' web site (http://www.m-sys.com) or send your requests to e-mail: info@m-sys.com. NEW FEATURES IN VERSION 4.2.1 ----------------------------- Version 4.2.1 is the latest version of the TrueFFS driver for VxWorks. It is backward compatible with all DiskOnChip products and supports M-Systems' latest products and capacities. Version 4.2.1 contains the following new features: - support for dosFs's long filenames - Support for dos2Fs when used in dosFs compatibility mode Version 4.2.1 also provides access to new features of the DiskOnChip, like software write-protection, background garbage collection and the ability to access the Binary partition on the DiskOnchip. These features are available via standard VxWorks IOCTL calls to the TrueFFS driver. GANG PROGRAMMER SUPPORT ----------------------- Customers that use the new DiskOnChip products should upgrade their GANG Programmer with GANG software version 4.2. Contents -------- 1. Introduction 2. Installing the TrueFFS driver 3. Booting VxWorks/x86 from the DiskOnChip 4. Driver's run-time configuration options 5. Formatting the DiskOnChip from VxWorks application 6. Considerations related to unexpected power shutdowns 7. Alternative "garbage collection" scenario 8. New DiskOnChip features available via IOCTL calls 9. Known problems Appendix A. Formatting the bootable DiskOnChip. 1. Introduction --------------- The DiskOnChip 2000, DiskOnChip Millennium and DiskOnChip DIMM 2000 are members of the new generation of high performance single-chip flash disks by M-Systems. When used under VxWorks, the DiskOnChip is managed by a dedicated device driver attached to the standard VxWorks's 'dosFs' filesystem and serves as both a data storage and a boot device. Most of VxWorks disk oriented calls (including all ANSI C file I/O facilities) work correctly with the DiskOnChip. The TrueFFS driver is capable of supporting up to 4 DiskOnChip devices in parallel, possibly of different types and capacities. The TrueFFS driver is fully re-entrant and takes care of all issues releated to a multitasking environment, thereby freeing the application from any concerns of this kind. 2. Installing the TrueFFS driver -------------------------------- 2.1. The distribution of the TrueFFS driver for VxWorks/x86 consists of the following files: - MSYSVXW.o x86 binaries of the TrueFFS driver for VxWorks - fldrvvxw.h TrueFFS driver's "include" file. This file must be #included by the application in order to be able to access the driver's API - flioctl.h Extended functionality "include" file. This file must be #included by the application in order to be able to access the Extended functionality API - Readme This readme 2.2. Check if the BSP library (Tornado/target/libgnuvx.a) contains the following object modules: tffsDrv.o tffsLib.o dosformt.o fatlite.o fltl.o nftllite.o flflash.o nfdc2148.o reedsol.o flsocket.o flbase.o For instance, if you are using 'pc486' BSP, you could list the contents of the BSP library (libI80486gnuvx.a in this case) as follows: ar386 -tv libI80486gnuvx.a If the BSP library contains any of these modules, delete them from the library. For instance, to delete module fltl.o from the libI80486gnuvx.a, you could execute: ar386 -dv libI80486gnuvx.a fltl.o 2.3. Delete the following object modules: tffsDrv.o tffsLib.o dosformt.o fatlite.o fltl.o nftllite.o flflash.o nfdc2148.o reedsol.o flsocket.o flbase.o from the BSP object directory (Tornado/target/objgnuvx). 2.4. The object module MSYSVXW.o contains the x86 binaries of the TrueFFS driver for VxWorks. This object module should be added to the application's linking process either statically or dynamically. One possible way to accomplish this is to copy MSYSVXW.o to the Tornado/target/lib directory and add MSYSVXW.o to the existing VxWorks/I80486 object library: ar386 -cru libI80486gnuvx.a MSYSVXW.o 2.5. Make sure that the file fldrvvxw.h is on the compiler's INCLUDE path and is #included by your application. 2.6. The TrueFFS driver's initialization routine scans the host address space for the DiskOnChip(s). By default, the driver will look for a single DiskOnChip in the x86-specific address range of [0xc8000..0xe0000]. In most of the cases the DiskOnChip's address is well known, and it makes sense to eliminate the memory scan by telling the driver explicitly where to look for the DiskOnChip. This can be accomplished by calling the tffsSetup() routine from your application. ===> NOTE. The tffsSetup() routine must be called exactly once, BEFORE the driver has been initialized by the routine tffsDrv(). Normally, it is called from usrRoot. Here is a prototype of the tffsSetup() routine taken from fldrvvxw.h: extern void tffsSetup (int diskonchips, long *addressRange); where 'diskonchips' is the number of DiskOnChip devices installed in the system; 'addressRange' is an array of address pairs bounding the regions to search for DiskOnChips. For instance, if your particular board allows an installation of up to three DiskOnChips, and the regions to search for the DiskOnChips are as follows: [0xd0000 ... 0xd1fff] 1st DiskOnChip [0xd2000 ... 0xd3fff] 2nd [0xd4000 ... 0xd5fff] 3rd then you should include the following code fragment into your application: #include "fldrvvxw.h" /* address ranges to search for the DiskOnChip */ long tffsAddresses[] = { 0xd0000, 0xd1fff, /* 1st DiskOnChip */ 0xd2000, 0xd3fff, /* 2nd */ 0xd4000, 0xd5fff }; /* 3rd */ /* configure the driver to detect up to three DiskOnChips */ tffsSetup(3, tffsAddresses); When there is a single DiskOnChip installed in the system at a well known address, it is desirable to prevent the driver from scanning the host address space for the DiskOnChip. In such cases both upper and lower bounds of the search range could be set to the exact DiskOnChip address. For instance, if the DiskOnChip is always installed at address 0xd0000, then the application can instruct the driver to look for the DiskOnChip at this particular address only by executing the following code fragment: #include "fldrvvxw.h" /* single address to look for a DiskOnChip */ long tffsAddresses[] = { 0xd0000, 0xd0000 }; /* configure the driver to detect single DiskOnChip */ tffsSetup(1, tffsAddresses); 2.7. The TrueFFS driver features a number of configuration options, described in detail in Chapter 4 below. The default settings of these options should be adequate for most of applications. If you wish, for some reason, to change some of the driver's configuration options, then do it at this stage. For instance, if you want to enable the TrueFFS driver built-in diagnostics (see Section 4.4 below), you should include the following code fragment: #include "fldrvvxw.h" /* enable built-in diagnostics and allocate 4KB for */ /* logging diagnostics messages. */ fl_useDebug = 4; ===> NOTE. All the driver's configuration options must be set to the desired values BEFORE calling the driver's initialization routine tffsDrv(). Once the tffsDrv() routine has been called, the configuration options must NOT be changed. 2.8. The TrueFFS driver must be initialized by calling the tffsDrv() routine. ===> NOTE. This routine must be called exactly once, AFTER call to the tffsSetup() routine. Normally, it is called from usrRoot. 2.9. The application must call the routine tffsDevCreate() to create a 'device' for every physical DiskOnChip installed in the system. Here is a prototype of this routine taken from fldrvvxw.h : extern BLK_DEV* tffsDevCreate (int tffsDriveNo, int flags); where 'tffsDriveNo' is the DiskOnChip sequential number (zero-based). The argument 'flags' should be set to be zero, unless long filename option is enabled in dosFs (see Sections 2.13 - 2.27). The tffsDevCreate() routine returns a pointer of (BLK_DEV *) type which must be saved by the application for later use. For example, if there is only one DiskOnChip on the system, the application should include the following code fragment : #include "fldrvvxw.h" BLK_DEV *tffs_blk_dev = tffsDevCreate (0, 0); Here is another example for the system featuring three DiskOnChips: #include "fldrvvxw.h" BLK_DEV *tffs_blk_dev[3] = { NULL, NULL, NULL }; tffs_blk_dev[0] = tffsDevCreate (0, 0); /* 1st DiskOnChip */ tffs_blk_dev[1] = tffsDevCreate (1, 0); /* 2nd */ tffs_blk_dev[2] = tffsDevCreate (2, 0); /* 3rd */ ===> NOTE. The DiskOnChip devices in TSOP package (which measures approx. 20 x 10 mm) are usually shipped from the factory unformatted. If you happen to have such TSOP DiskOnChip, and tffsDevCreate() call has failed (i.e. returned NULL), the most likely cause of the failure is the fact that this TSOP DiskOnChip has never been formatted. Please call tffsDevCreate() to format DiskOnChip as desribed in Section 5, and then re-attempt tffsDevCreate() call. 2.10 Once the 'device' has been created for every DiskOnChip, they must be given a name and associated with the file system (dosFs). This is accomplished by calling the dosFsDevInit() routine (see VxWorks Reference manual). This routine accepts as a parameter the pointer of type (BLK_DEV *) which has been returned by the preceeding call to tffsDevCreate() (see Section 2.9 above). The dosfsDevInit() routine returns a pointer of type (DOS_VOL_DESC *) which must be saved by the application for later use. For example, if there is only one DiskOnChip in the system, the following code section will name it '/tffs0/' and associate it with dosFs filesystem: #include "fldrvvxw.h" DOS_VOL_DESC *tffs_dosFs_vol = dosFsDevInit ("/tffs0/", tffs_blk_dev, NULL); Here is another example for a system featuring three DiskOnChips: #include "fldrvvxw.h" DOS_VOL_DESC *tffs_dosFs_vol[3] = { NULL, NULL, NULL }; tffs_dosFs_vol[0] = dosFsDevInit ("/tffs0/", tffs_blk_dev[0], NULL); tffs_dosFs_vol[1] = dosFsDevInit ("/tffs1/", tffs_blk_dev[1], NULL); tffs_dosFs_vol[2] = dosFsDevInit ("/tffs2/", tffs_blk_dev[2], NULL); 2.11 M-Systems guarantees that low-level format on the DiskOnChip (the one maintained by the TrueFFS driver) won't get corrupted by unexpected power shutdowns. Unfortunately, the default configuration of VxWorks's dosFs filesystem is aimed at providing high I/O performance by caching user data in RAM rather than immediately writing it onto the disk. If unexpected power shutdowns are likely to happen to your system, the data cached by the filesystem in RAM could be lost and the media could be left in an inconsistent state. To minimize the risk, avoid caching of data in RAM by calling the dosFsVolOptionsSet() routine (see VxWorks Reference manual), as shown by the code fragment below: #include "fldrvvxw.h" dosFsVolOptionsSet(tffs_dosFs_vol, tffs_dosFs_vol->dosvd_options | DOS_OPT_CHANGENOWARN); where 'tffs_dosFs_vol' is a pointer returned by the call to the routine dosFsDevInit() (see Section 2.10 above). More detailed discussion of the issues related to the unexpected power shutdown could be found in Chapter 6 below. ===> NOTE. The disabling of the filesystem cache reduces the I/O performance of the DiskOnChip. 2.12. Make sure your BSP configuration .H file (Tornado/target/config/pc486/config.h in case of pc486 BSP) excludes the following VxWorks components: #undef INCLUDE_TFFS /* include TrueFFS driver */ #undef INCLUDE_PCMCIA /* include PCMCIA driver */ 2.13 By default, dosFs runs with long filenames support disabled (option DOS_OPT_LONGNAMES is not set), for MS-DOS compatibility reasons. If you will not be enabling support for long filenames in dosFs, you should skip Sections 2.14 - 2.27. If you do want to enable this option and use long filenames, you will need to proceed with Section 2.14. ===> NOTE. The dosFs's long filenames support is not compatible with MS-DOS, and dosFs volumes with long filenames cannot be accessed on MS-DOS machines. Please use dosFs long filenames option ONLY when you really need them. ===> NOTE. While the DiskOnChip driver does support dosFs's long filenames, it runs with some internal optimizations turned off in this mode. This may have a negative impact on the driver's 'write' performance (the 'read' performance is not affected). 2.14. Since the dosFs volume with long filenames support is not compatible with MS-DOS, it can't be read by VxWorks bootsector. In another words, it is not possible to boot VxWorks from such a volume. This means that, in order to boot VxWorks from the DiskOnChip AND still be able to use dosFs long filenames, two partitions need to be created on DiskOnChip: - the primary, DOS-compatible partition which will be used to store the bootimage BOOTROM.SYS - the second partition which will be used to store application files in the dosFs's long filename format The following sections contain instructions for creating and initializing these two partitions. 2.15. Boot DOS on the target, and start MS-DOS FDISK.EXE utility: FDISK If DiskOnChip is the only "hard disk" in the system, you should see FDISK's main menu with the enries like "Delete Partition" and "Create DOS partition or logical DOS Drive". If FDISK asks you to select the hard disk, you will have to power down the system, detach all the hard disks, turn the power up and re-invoke FDISK at the DOS prompt. 2.16. Delete the existing FAT12/16 partition by selecting "Delete Partition" (option 3), then "Delete Primary DOS Partition" (option 1). 2.17. Create boot partition by selecting "Create DOS partition or logical DOS Drive" (option 1), then "Create Primary DOS Partition" (option 1). When asked "Use maximum available size for that partition [Y/N]", answer 'N', and then specify the minimum size which is sufficient for storing VxWorks bootimage(s). 2.18. Create extended partition by selecting "Create DOS partition or logical DOS Drive" (option 1), then "Create Extended DOS Partition" (option 2). By default FDISK proposes to allocate all the remaining disk space to the extended partition; you should accept this default. Finally, FDISK offers to create logical drive that spans the entire extended partition; you should accept this too. 2.19. Mark the primary partition as active one by selecting "Set active partition" (option 2), and then entering '1' as the number of partition you wish to make active. 2.20. Exit FDISK and reboot the system with DOS. 2.21. Create the FAT12/16 filesystem on the primary partition by executing : FORMAT C: 2.22. Write VxWorks boot sector onto the primary partition by executing: VXSYS C: 2.23. At that point you will need to create dosFs filesystem with long filenames support on the extended partition on the DiskOnChip. The Sections below show how to do this. You will need to use boot scenario 'A' (boot over network) for this purpose. 2.24. Locate the place in you application which contains the tffsDevCreate() call (see Section 2.9), and change the 2nd arguement passed to this call to be (FL_DOSFS_LONGNAMES | 2). ===> NOTE. Please note that if the boot scenario 'C' is used (see Section 3.1), the routine tffsDevCreate() is called from two places - from the application code, and from the BOOTROM.SYS bootloader code (Tornado/target/config/all/bootConfig.c, see Section 3.11). Only the application code should pass ((FL_DOSFS_LONGNAMES | 2) to tffsDevCreate() as 2nd arguement, because application is looking for access to the extended partition (where application stores it's files). The bootloader code in bootConfig.c always passes zero as 2nd arguement to tffsDevCreate(), because bootloader code is looking for access to the primary partition (where VxWorks application is stored). 2.25. Locate the place in your application which contains dosFsDevInit() call (see Section 2.10), and temporary change this code section to look like this: #include "fldrvvxw.h" #if FALSE DOS_VOL_DESC *tffs_dosFs_vol = dosFsDevInit ("/tffs0/", tffs_blk_dev, NULL); #else /* Temporary code to initialize extended ... ...

近期下载者：

相关文件：

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

收藏者：