Another question, has there a version of YAFFS2 Direct? When will the YAFFS2 be released?
Austin Chen
> 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
>
>
(text/plain)