Advanced users may alternatively use the ecosadmin.tcl tool from the command line. You will be prompted to accept the license at the appropriate time during the procedure.

tclsh $ECOS_REPOSITORY/ecosadmin.tcl add yaffs-v1_2_3.epk

To link Yaffs into your application, add CYGPKG_FS_YAFFS to your eCos configuration in the normal way, either using the eCos Configuration Tool (Packages dialog on the Build menu), or the ecosconfig command-line tool.

You will also need to add CYGPKG_IO_NAND and CYGPKG_IO_FILEIO to your configuration if they are not already present. Your platform HAL should supply packages for all NAND device(s) present.

If you started with a smaller template than default, you may also need to add some of the following:

Yaffs provides a number of package options, including tuning parameters.

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 mount call 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.

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:

	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.

	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.

Consider a Yaffs filesystem hosted by a NAND partition with 65536 pages, each of size 2k, using the default setting of ten short-op caches. On this filesystem we shall store 10000 files each of size 10240 bytes, hence each requires a single group of Tnodes.

This example is a close match to the actual consumption measured by eCosCentric during testing. (The measured consumption as reported by mallinfo was 1,681,112 bytes, which includes the heap's own overheads.)