Charles, On Friday 22 November 2002 22:04, Charles Manning wrote: > One thing I have realised (and this might be a Good Thing for mtd too) is > that some options are best not compiled in, but run-time selected. With > YAFFS2, I intend to allow both YAFFS1 and YAFFS2 in a single system with > YAFFS1 or YAFFS2 being runtime selected (as well as other attributes such > as internal caching, chunk size etc which are now compile time selected). > The reason for this is that a smaller partition (eg boot partition) might > be more suited to YAFFS1 and a larger partition to YAFFS2. > > In mtd, for example, is it perfectly reasonable to think that an mtd in a > single system might need to run JFFS, YAFFS and some other fs > (??FAT/SmartMedia??) all with different feature requirements (eg. ECC, > placement of ECC data). Would it not be better to control these on a > per-parftition basis? In the current code the ECC-placement and ECC-calculation selection is runtime selectable. You can also supply oob-data from your filesystem driver and readback the oob-data together with the data from the main area. This implies, that you can use different filesystems on the partitions of a chip. static int nand_write_ecc (struct mtd_info *mtd, loff_t to, size_t len, size_t * retlen, const u_char * buf, u_char * eccbuf, int oobsel) If you supply an eccbuf, the driver writes those data into the oobarea. The buffer length should be equal to oobsize * number of blocks to write. If you do not supply a buffer there (NULL), then no fs-specific data is written into the spare area and the nand driver builds a buffer, which is filled with 0xff. The oobsel argument selects the filesystem dependent placement of ECC data. If you select NAND_NONE_OOB, no ECC calculation is done and no ECC data is placed in the spare area. This applies to the current YAFFS code. If you select one of the defined placements (NAND_JFFS2_OOB, NAND_YAFFS_OOB) the ECC calculation you selected for this chip is done and the ECC data is placed on the appropriate byte positions either in the sparearea buffer, which was supplied by the fs driver, or in the buffer, which was filled with 0xff by the nand driver. The oobsel argument is either NAND_OOB_NONE; if you supply ECC in your spare buffer alreday, or NAND_OOB_YAFFS, if you want to utilize the nand-driver ECC functionality as selected for your chip. The nand_read_ecc function is analogous. IMHO it makes no sense to select different ECC-modes for different partitions on the same chip, except the NONE variant where the fs-driver supplies all oob data including ECC. __________________________________________________________________ The current yaffs-mtd interface can be run on top of the current mtd-cvs _WITHOUT_ any modifications of nand.c, as it defaults to NAND_NONE_OOB for mtd->write and mtd->read. So it skips all ECC related calculations. I run it together with a jffs2 partition on the same chip. The jffs2 partition uses software ECC and selects NAND_JFFS2_OOB for read_ecc and write_ecc. I copied and moved files around the two partitions without any problem. Due to the fact, that nand.c uses the fs-buffer for page aligned read / write and some other critizied speed problems are resolved, there should be no or only a minimal speed penalty compared to a yaffs optimized driver. I made following changes to yaffs_mtdif.c and improved the performance, due to the fact, that data and oob area are read and written in one go, without (de)selecting the chip again. RCS file: /home/aleph1/cvs/yaffs/yaffs_mtdif.c,v retrieving revision 1.2 diff -u -r1.2 yaffs_mtdif.c --- yaffs_mtdif.c 27 Aug 2002 03:31:38 -0000 1.2 +++ yaffs_mtdif.c 23 Nov 2002 07:54:21 -0000 @@ -32,11 +32,12 @@ __u8 *spareAsBytes = (__u8 *)spare; - if(data) + if(data && !spare) mtd->write(mtd,addr,YAFFS_BYTES_PER_CHUNK,&dummy,data); - if(spare) + if(!data && spare) mtd->write_oob(mtd,addr,YAFFS_BYTES_PER_SPARE,&dummy,spareAsBytes); - + if(data && spare) + mtd->write_ecc(mtd,addr,YAFFS_BYTES_PER_CHUNK,&dummy,data,spareAsBytes,NAND_OOB_NONE); return YAFFS_OK; } @@ -50,10 +51,12 @@ __u8 *spareAsBytes = (__u8 *)spare; - if(data) + if(data && !spare) mtd->read(mtd,addr,YAFFS_BYTES_PER_CHUNK,&dummy,data); - if(spare) + if(!data && spare) mtd->read_oob(mtd,addr,YAFFS_BYTES_PER_SPARE,&dummy,spareAsBytes); + if(data && spare) + mtd->read_ecc(mtd,addr,YAFFS_BYTES_PER_CHUNK,&dummy,data,spareAsBytes,NAND_OOB_NONE); return YAFFS_OK; } I think it would be easy to modify YAFFS code to use the ECC functionality of nand.c, which includes software ECC and various hardware ECC modes. The hardware ECC functions have to be provided by the hardware dependend driver. To use this, you only have to supply your sparearea buffer as now and select NAND_YAFFS_OOB. The ECC positions in the oobarea should be defined correctly for Yaffs already. Further improvement could be done by using the multiblock read/write, which is possible with read/write_ecc. One further suggestion: I tried to mount yaffs on an already JFFS2 formatted partition. Yaffs mounts, but tells the that the fs is 100% full. JFFS2 checks the partition, if it's empty, JFFS2 formatted or formatted for a different filesystem. In the later case it refuses to mount. This would be a reasonable feature for YAFFS too. -- Thomas ____________________________________________________ linutronix - competence in embedded & realtime linux http://www.linutronix.de mail: tglx@linutronix.de --------------------------------------------------------------------------------------- This mailing list is hosted by Toby Churchill open software (www.toby-churchill.org). If mailing list membership is no longer wanted you can remove yourself from the list by sending an email to yaffs-request@toby-churchill.org with the text "unsubscribe" (without the quotes) as the subject.