Please give me some introduce. If I want to port the YAFFS Direct to Nucleus Plus RTOS, which documents should I read first? How about the license type and license fee and when I need to license it?

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
> 
>