Embedded Flash File Systems
What is so unique about TargetFFS?
The key benefit of TargetFFS is the ability to recover from unexpected power losses and resets. Additional benefits include advanced file system features we have added over time in response to customer requests. These include file links, file access protection, quota/reservations, and much more. TargetFFS has been exposed to many extreme use cases (automated power fail testing, large files, large number of files, unusual flash devices, etc.)
How do you know the power loss recovery works?
Not only was the system designed with this in mind, TargetFFS has undergone and passed extensive automated power fail torture testing, both internal and external to Blunk. Blunk's own automated powerfail test meticulously checks for failures at every change in flash state.
What type of file system does the TargetFFS driver use? Is there a description of the file system available?
TargetFFS is not a driver, but a complete file system, all the way to the Standard C/POSIX API. We are able to provide recovery from unexpected power loss precisely because TargetFFS is designed from the ground up to implement a file system on flash memory devices. This is an elusive feature in flash translation layer solutions designed to run underneath a standard hard disk file system.
Are there any specifications on the throughput (sustained read/write
rates) for your driver?
That is a question best answered by benchmarking on your target board, because there are dependencies on so many things, especially on how your application uses the file system. In general, the fuller you keep the file system, the slower it will be. To support continued writes, TargetFFS must periodically erase a flash block after copying all data in use off the block.
The more full a flash volume is, the more often these copy/erase cycles must be performed. Our benchmark graph shows some measurements we took of TargetFFS relative write speed versus percent of free space in the volume. The speed decrease is a little less than linear.
How long does it take to mount a flash file system volume?
TargetFFS has been optimized for fast mounts.
Mount times are dependent on the contents of the file system, processor speed, and other hardware performance characteristics.
Contact Blunk for more details.
We're looking for a flash file system to implement some file system dependencies that we have in our product. We're currently releasing a browser that assumes some sort of ANSI or near ANSI file system. Our simulator uses the file system of the desktop.
The TargetFFS API includes the ANSI C library file-related calls and the file-related calls in POSIX. One will have to mangle the names, most likely, to prevent linker collision with the runtime library of the RTOS one is using.
We're using a Cirrus Logic board right now without an OS. Does your file system require an OS?
TargetFFS doesn't require an OS. It uses two semaphores to protect its critical sections when there is multitasking, but in an environment like yours the semaphore routines (semPost(), semPend(), semCreate()) can just be empty functions, no-ops.
Have you ported to other OSs?
We have our own RTOS, TargetOS. We don't proactively port to other OSs. We keep the code strict ANSI and provide a porting guide that makes it simple to bring up TargetFFS with any RTOS.
The porting guide is an appendix in the manual, and the issues come down
- 1. Implementing the TargetOS semPost(), semPend(), semCreate() calls with the RTOS you are using. These are just simple counting semaphores, so virtually any RTOS has equivalent support.
- 2. Doing whatever name mangling is required. If you are using an RTOS that has its own Standard C library and you are using the stdio.h routines from it, then you will have to "mangle" the names of the TargetFFS routines to prevent linker collision. This is done by changing the "#if 0" below in "posix.h" to "#if 1".
** Include "psxfs.h" to name-mangle the TargetOS POSIX API
** if your environment already defines the POSIX structures
** and routines.
This will rename our POSIX API, appending an "FFS" to the end
of each name (i.e. readFFS(), writeFFS(), etc.) and you can use
those names without conflict.
What flash memory vendors have TargetFFS been integrated with? Does TargetFFS support Intel flash?
TargetFFS works with any block-erasable, byte-writeable NOR or NAND flash, both single and multilevel bit cell devices. The driver layer is small and simple. The set of provided sample drivers includes drivers for Intel, Spansion, Samsung, and Toshiba parts. TargetFFS has a thin device driver layer, which consists of the following functions:
- write 1 byte
- write 512 bytes
- read 512 bytes
- erase block
What is the footprint when merging the full package?
TargetFFS is built as a library, so only the routines that are used are pulled in. The footprint pulled in by one of our sample applications was 60KB. Something around 64KB is typical for RAM use for buffers and the like.
Can we merge part of the package - for small boot images?
Since it is a library, only those parts needed are pulled in, but don't expect it to vary too much. The TargetFFS footprint is not affected by the size of any file it contains in a volume.
Does your file system support boot images - meaning that the boot images have to be programmed in specific address (exp. 0xFFF00000 in PPC microprocessors) and continuous code?
TargetFFS supports boot images by allowing the flash chip to be shared. You don't have to turn the whole chip over to TargetFFS. In the driver, you specify the base address that TargetFFS accesses and the number of 512-byte sectors above the base address which it can use, like so:
/* Register flash volume with TargetFFS. */
vol.name = "flash";
vol.block_size = BLOCK_SIZE;
vol.num_sectors = (BLOCK_SIZE * NUM_BLOCKS) / SECTOR_SIZE;
vol.mem_base = STRATA_BASE;
vol.write_byte = write_byte;
vol.write_sector = write_sector;
vol.read_sector = read_sector;
vol.erase_block = erase_block;
perror("FlashAddVol failed: ");
There is some more discussion of this in the manual, in Chapter 2.
Does your file system support non-contiguous flash addresses?
Yes, the file system of TargetFFS only accesses the flash through the driver layer. So, it is easy to support non-contiguous flash addresses by doing the appropriate translation in the driver.
Does TargetFFS support a single bank NOR Flash device? That means XIP (execute-in-place) on the same flash as the file system area.
Yes. We have customers using TargetFFS on single bank devices that they are also executing their application code from. What they do is copy the driver (very small) to RAM and then execute from there while programming or erasing the flash.
A critical point with this approach is that the initial ISR handlers have to be copied to RAM also and they must suspend any erase or program operations in progress before executing higher level code.
Many cell phones have been shipped using this approach.