[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
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.
COMMENTS ON EACH ITEM
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 firstname.lastname@example.org'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D