Yaffs appears in the eCos filesystem table. This means that you can mount a filesystem in the standard Unix-like way, then interact with it with calls to open, read, etc.
Before you can use a filesystem, it must be mounted.
A NAND device is logically organised as one or more partitions, which are usually set up by the relevant platform HAL. You need to tell the mount command which device and partition you wish to access. In the following example, we are mounting partition 0 of the onboard NAND device.
rv = mount("onboard/0", "/nand", "yaffs");
Note: The device argument to the
mountcall is a NAND-specific device name, not an entry in /dev. Refer to the documentation for your platform HAL for details of how the NAND device(s) are named, and to the NAND library documentation for details of how partitions are addressed.
You can, if you wish, make the filesystem mounting automatic at static constructor time with the MTAB_ENTRY macro. (Your platform HAL may already do this; check it carefully.)
MTAB_ENTRY(my_nand, "/nand", "yaffs", "onboard/0", "", 0);
Note: This example is for eCosPro. In eCos, the MTAB_ENTRY macro takes only four arguments.
eCosPro allows various options to be passed to a filesystem at mount time, by combining them with the filesystem argument in a particular format. Yaffs understands the following options:
reserved=<int> The number of physical NAND blocks to reserve for garbage collection and block failures (minimum 2). The default is set in CDL as
caches=<int> The number of page cache entries to use. Values of 10 to 20 are recommended. The default is set in CDL as
skip-checkpoint-readInstructs Yaffs to not attempt to reload the filesystem from a checkpoint, if one exists. In other words, this option forces a full filesystem scan whether or not one is necessary.
formatInstructs Yaffs to format the filesystem before it mounts it. This deletes its entire contents.
Yaffs operates a cacheing layer in order to save undue wear on the
NAND chip if many small writes are performed. Because of this,
if you wish to ensure that any data written to a still-open file has
been fully flushed, you must make a synchronisation request. This is
done with the
fsync function, which takes as its
argument the file descriptor of the file you wish to synchronise.
When mounting a filesystem, Yaffs has to scan the NAND chip to recreate its internal state. This can be a slow process, but is made much faster if there is a valid checkpoint.
A checkpoint is written out automatically when you unmount the filesystem. At any other time, you can manually force a checkpoint to be written with one of the following functions:
cyg_fs_fssync(mountpoint)synchronises a filesystem (automatically called on umount)
syncsynchronises all mounted filesystems.
Note: A checkpoint becomes invalid as soon as there have been any other writes to the filesystem. Finding a good place to sync is necessarily dependent on your application logic.
Although Yaffs is a Unix-compatible filesystem, the eCos port does not provide support for the full range of Unix attributes.
eCos does not check file or directory permissions; everything it creates is given fixed user and group IDs of zero and standard permissions (files rw-r--r--, directories rwxr-xr-x).
It is not currently possible to change file ownership or permissions.
It is not currently possible to create symbolic links, FIFOs (named pipes), sockets or device nodes.
Hard links to files work in the expected way. Hard links to directories are forbidden.
It is not possible to unlink the '.', '..' or 'lost+found' special directories.
Note: If you will be sharing a Yaffs filesystem between eCos and some other operating system, you are advised to carefully check the other system's definitions of mode (permission) bits and whether any translation may be required.