Re: [Yaffs] Re: Use YAFFS in RTOS

Startseite
Anhänge:
Nachricht
+ (text/plain)
Nachricht löschen
Nachricht beantworten
Autor: Charles Manning
Datum:  
To: Austin Chen
CC: yaffs
Betreff: Re: [Yaffs] Re: Use YAFFS in RTOS
I'll add a few comments to what Wookey has written.

On Wednesday 24 August 2005 00:56, Wookey wrote:
> +++ Austin Chen [05-08-23 19:52 +0800]:
> > Dear All,
> >
> >     I am new to here. I have a design use the NAND Flash File System
> > designed by myself. It has bad block management but lack of wear
> > leveling. It also use a non-standard FAT to store files. Now I want to
> > improve my design and incorporate a full-featured Flash File System.

> >
> > Is the YAFFS or YAFFS2 suitable for embedded design with RTOS?
>
> Yes. The YAFFS Direct variant is designed with this purpose in mind. You
> just need to provide a few functions (read/write/inet/erase NAND, get time,
> get/drop mutex).
>
> It has been used with pSOS and Vxworks and at least one in house system.
>
> > My design use Nucleus Plus RTOS and Nucleus File system.
>
> A port for this OS has not yet been done (SFAIK). You will need to do some
> work to merge it in. If Nucleos is not GPL-compatible then you will need to
> get a licence from Aleph One to use the code in a non-GPL context.


The actual OS porting is almost trivial. You just need to write a few simple
functions to provide a locking semaphore etc.
>
> > The Nucleus File is used to access a USB Disk. Since there already has a
> > File System, I hope the YAFFS can be used as a pure FTL (Flash
> > Translation Layer) to make the NAND Flash as disk like block device. Is
> > it possible to split FTL and File System from YAFFS?
>
> I don't think this is possible. YAFFS is a whole filesystem, and presents a
> posix-style interface to the OS (open, read, write, rename etc). This
> should be reasonable easy to integrate into nucleous. Trying to just use it
> as an FTL/block device is really the wrong tool for the job. Charles may
> wish to comment further here?


Many flash implementations (eg. DiskOnChip + FAT/ext2/... or SmartMedia + FAT)
use a regular file system and wrap up the NAND to look like a block device.
Most block devices (eg. your hard drive) are thin software layers over a true
block device. When you do this with flash, you're telling a pack of "lies"
and quite a bit of effort is required to keep the charade going. This
approach has various limitations, particularly with regard to reliability and
write performance.

YAFFS does not use a block device, but is "flash friendly". It expects to be
working with NAND and exploits the NAND-ness in the way the file system
works. So, there are no seperate FTL + file system layerings that can be
separated out.

You could, however, use YAFFSs under the hood for a "block driver" ie. write
an FTL on top of YAFFS, then run FAT on top of that. However, it is not clear
trhat this would really get you anything very useful (apart from the academic
exercise).

It seems though that your main goal is to try reduce memory footprint by only
having one FS. I'd suggest doing a trial build of YAFFS Direct to see what
the footprint implications would be.

Please feel free to discuss this further on or off list.

-- CHarles