VxWorks Reference Manual : Libraries
tffsConfig - TrueFFS configuration file for VxWorks
tffsShowAll( ) - show device information on all socket interfaces
tffsShow( ) - show device information on a specific socket interface
tffsBootImagePut( ) - write to the boot-image region of the flash device
This source file, with the help of sysTffs.c, configures TrueFFS for VxWorks. The functions defined here are generic to all BSPs. To include these functions in the BSP-specific module, the BSP's sysTffs.c file includes this file. Within the sysTffs.c file, define statements determine which functions from the tffsConfig.c file are ultimately included in TrueFFS.
The only externally callable routines defined in this file are tffsShow( ), tffsShowAll( ), and tffsBootImagePut( ). You can exclude the show utilities if you edit config.h and undefine INCLUDE_SHOW_ROUTINES. You can exclude tffsBootImagePut( ) if you edit sysTffs.c and undefine INCLUDE_TFFS_BOOT_IMAGE. (If you find these utilities are missing and you want them included, edit config.h and define INCLUDE_SHOW_ROUTINES and INCLUDE_TFFS_BOOT_IMAGE.)
If you wish to include only the TrueFFS specific show routines you could define INCLUDE_TFFS_SHOW instead of INCLUDE_SHOW_ROUTINES in config.h.
However, for the most part, these externally callable routines are only a small part of the TrueFFS configuration needs handled by this file. The routines internal to this file make calls into the MTDs and translation layer modules of TrueFFS. At link time, resolving the symbols associated with these calls pulls MTD and translation layer modules into VxWorks.
However, each of these calls to the MTDs and the translation layer modules is only conditionally included. The constants that control the includes are defined in sysTffs.c. To exclude an MTD or translation layer module, you edit sysTffs.c, undefine the appropriate constant, and rebuild sysTffs.o. These constants are described in the reference entry for sysTffs.
stdcomp.h
tffsShowAll( ) - show device information on all socket interfaces
void tffsShowAll (void)
This routine prints device information on all socket interfaces.
N/A
tffsShow( ) - show device information on a specific socket interface
void tffsShow ( int driveNo /* TFFS drive number */ )
This routine prints device information on the specified socket interface. This information is particularly useful when trying to determine the number of Erase Units required to contain a boot image. The field called unitSize reports the size of an Erase Unit.
If the process of getting physical information fails, an error code is printed. The error codes can be found in flbase.h.
N/A
tffsBootImagePut( ) - write to the boot-image region of the flash device
STATUS tffsBootImagePut ( int driveNo, /* TFFS drive number */ int offset, /* offset in the flash chip/card */ char * filename /* binary format of the bootimage */ )
This routine writes an input stream to the boot-image region (if any) of a flash memory device. Typically, the input stream contains a boot image, such as the VxWorks boot image, but you are free to use this function to write any data needed. The size of the boot-image region is set by the tffsDevFormat( ) call (or the sysTffsFormat( ) call, a BSP-specific helper function that calls tffsDevFormat( ) internally) that formats the flash device for use with TrueFFS.
If tffsBootImagePut( ) is used to put a VxWorks boot image in flash, you should not use the s-record version of the boot image typically produced by make. Instead, you should take the pre s-record version (usually called bootrom instead of bootrom.hex), and filter out its loader header information using an xxxToBin utility. For example:
elfToBin < bootrom > bootrom.binUse the resulting bootrom.bin as input to tffsBootImagePut( ).The discussion above assumes that you want only to use the flash device to store a VxWorks image that is retrieved from the flash device and then run out of RAM. However, because it is possible to map many flash devices directly into the target's memory, it is also possible run the VxWorks image from flash memory, although there are some restrictions:
- The flash device must be non-NAND.
- Only the text segment of the VxWorks image (vxWorks.res_rom) may run out of flash memory. The data segment of the image must reside in standard RAM.
- No part of the flash device may be erased while the VxWorks image is running from flash memory.
Because TrueFFS garbage collection triggers an erase, this last restriction means that you cannot run a VxWorks boot image out of a flash device that must also support a writable file system (although a read-only file system is OK).
This last restriction arises from the way in which flash devices are constructed. The current physical construction of flash memory devices does not allow access to the device while an erase is in progress anywhere on the flash device. As a result, if TrueFFS tries to erase a portion of the flash device, the entire device becomes inaccessible to all other users. If that other user happens to be the VxWorks image looking for its next instruction, the VxWorks image crashes.
OK or ERROR