[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Thursday, 14. February 2002 18:27, David Woodhouse wrote:
> gleixner@xxxxxxx.de said:
> I'm sorry I haven't been particularly responsive for the last few days.
> It's not that I'm not interested, more that the last few days included 24
> hours in a tin can coming back from linux.conf.au and I don't think I'm
> awake enough yet to attempt it :)
Ok no problem, i was a little bit irritated, that a lot of other issues were 
answered and did not know, why the discussion was broken. So this was only a 
well meant wakeup call.

I Include my latest statement on this, to have this new thread up to date.

Actual state of JFFS2 on NAND

I implemented a new structure into nand_chip structure, which describes the 
usage of the oob area. You can read and modify this structure from the 
filesystem driver via two functions, which i have implemented into the mtd 
structure. (get_oobcfg, set_oobcfg).
The mtd_oob_config structure is:
/* configuration for out of band data (NAND,DOC...) */
struct mtd_oob_config {
         int     oob_size;       /* size of out of band area */
         int     ecc_pos[6];     /* position of ECC bytes inside oob */
         int     badblock_pos;   /* position of bad block flag inside oob -1 
= inactive */
         int     eccvalid_pos;   /* position of ECC valid flag inside oob -1 
= inactive */
         int     fsdata_pos;     /* position to store filesystem specific 
information */
         int     fsdata_len;     /* length available for filesystem specific 
data */
With this structure we can decide at mount time, which scheme we use. Either 
the fs driver modifies it to match it's requirements or the fs driver uses 
the information given by the device driver. At the moment i use the 
information given by the device driver.

I have now fixed the most NAND related FIXME's inside JFFS2, except the 
problem with wbuf_flush fail. The cleanmarker in the oob area and the bad 
block marking is working pretty good. I modified the scan routine to collect 
bad block information. I have a old SmartMediaCard, which has bad blocks on 
it. The information is collected correct. Then I erased one of the bad blocks 
and destroyed the bad block flag. When gc erased this block again it was 
detected as bad (not totaly erased) and marked bad again. 

I ran some stress tests on the filesystem and encountered no serious problem, 
except when i used a wornout old SMCard from a digicam i ran into the 
flush_wbuf bug.

Thomas Gleixner, autronix automation GmbH
auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: gleixner@xxxxxxx.de">http://www.autronix.de  

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com