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

Finalized TODO list for NAND and JFFS...


I have been trading quite a few emails with David Woodhouse on
implementation of a low-level MTD driver for NAND flash devices
as well as changes that will be necessary for JFFS. Below is a
TODO list with comments that I have compiled based on our
discussions and some notes from the MTD web page. I would greatly
appreciate discussion and comments before I move forward and
implement the changes. There are also some items I could use
advice on. Thank you so much.



 1) Wear-leveling and aging for block re-usage for NOR and NAND
 2) JFFS needs write gathering for NAND to keep from writing
    more than 10 times per page
 3) ECC handled in low-level MTD driver
 4) JFFS will quit treating flash device as linear and keep track
    of blocks in various conditions
 5) When reading an end of block, instead of automatically picking
    next block, utilize a function like 'get_next_usable_block'
    that will utilize metrics for block re-usage
 6) Block re-usage algorithm:
                            if jiffies % 5
                              recycle_the_oldest block;
 7) Utilize 'drivers/char/flash_mem.c' for caching 512 byte blocks
    with a buffer and write out data only when different page is found
 8) JFFS should do read after write of data with NAND flash only
 9) JFFS will mark do bad block marking
10) JFFS mount option to reserve a set percentage of blocks for bad
    block management. Default value will be percentange based on all
    flash devices' minimum bad block guarantee
11) Utilize 'drivers/mtd/pnc2000.c' for partitioning so that JFFS will
    not utilize flash blocks outside of its space in case there are
    other images on the flash device.

 1) I'm guessing a few data values will be added to the 'jffs_fm'
    structure to be dealt with by the GC.

 2) I understand what the sentence is saying, but I do not have
    a clear idea on how to do this.

 3) I will implement ECC in my low-level NAND flash driver.

 4) I am guessing that three functions in 'jffs_fm.c' are going
    to get an overhaul along with minor changes throughout this
    module. 'jffs_free_size1' , 'jffs_free_size2' and 'jffs_fmalloc'
    will be changed.

 5) I assume we are talking about flash blocks here. This item needs
    more clarification for me.

 6) Algorithm looks good to me. Changes in 'intrep.c' for GC.

 7) I believe this will be handled at the MTD level and is
    transparent for JFFS.

 8) Easy to do.

 9) When JFFS detects an error in a block, it will do its best
    to copy all the data it can into another block and then write
    '0xDEADBEEF' over the entire bad block. NOTE: Initial bad
    block testing should be done using the NAND test utility
    located in the 'utils' directory of the MTD CVS repository.
    I will be making a few modifications to this.

10) Implementing this should not be difficult. I know what we
    discussed and I will take a crack at myself. I plan on
    creating a raw inode with a value of 0xfefefefe or a special
    magic number that will contain the reserved blocks as well
    as a bad block list.

11) This should be transparent to JFFS. Easy to do.

 Steven J. Hill - Embedded SW Engineer
 Public Key: 'finger sjhill@xxxxxxx.com'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D