Overview

1.4 Sharing Flash Memory Between TrueFFS and a Boot Image

By default, the TrueFFS formatting utilities format the entire flash medium for use under TrueFFS. Although the translation services of TrueFFS provide many advantages for managing the data associated with a file system, those same services also complicate the use of flash memory as a boot device. The only practical solution to this problem is to exclude TrueFFS from the boot area of flash.

Fortunately, the formatting utility shipped with TrueFFS for Tornado lets you start the formatting operation at an offset. This creates a fallow area within flash that is totally outside the reach of TrueFFS. TrueFFS for Tornado also includes utilities that you can use to manage this fallow area. This functionality includes the ability to write a boot image into the fallow area as well as erase it.

However, when using these utilities, you must exercise caution. These utilities bypass all the protections built into TrueFFS. Thus, not only is it possible to over program the flash medium, it is also possible to write outside the fallow area. Handled carelessly, such a write could irretrievably corrupt the TrueFFS-managed data.

Running the VxWorks Image out of Flash Memory

The discussion above assumes that you want 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 often possible to map a flash device directly into the target's memory, it is also possible run the VxWorks image out of flash memory. Still, 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.

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). A writable flash-resident file system requires garbage collection, which, in turn, requires an erase cycle.

Unfortunately, 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.

Thus, if you want to implement both a writable file system and a vxWorks.res_rom in flash, you must implement them on separate sockets. Because this conflict arises only during a write to the flash device, the vxWorks.res_rom image can share the flash device with a file system if the file system is read only.