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

Re: JFFS2 on NAND flash



On Friday,  1. February 2002 19:10, David Woodhouse wrote:
> cvs up -r jffs2-nand-branch

I got it. The wbuf stuff is running now. But i have some questions. 

1. in jffs2_flush_wbuf, you have a adjustment of c->nextblock->freesize.
I don't find a reason to use it. If we write to a different block, we can not 
touch nextblock. If we pad a page, because the next node does not fit into 
this page, the information is already updated. This happens, when c->wbuf_len 
is 0x1fd  and the next write occurs on the beginning of a new page.

2. Powerdown with data in writebuffer.
If we have data in the writebuffer, e.g. a new file, we will loose this file. 
The only way to get around this is a early powerfail warning, which shuts 
down the system. 
But what about data, whe have for lets say 20 Minutes in the writebuffer ? 
This happens, if the application has stopped to produce new data. Is there a 
possibilty to build a timeout for flashing out the remaining bytes in the 
writebuffer ?

3. CLEANMARKER. In your "Ramblings on NAND flash support" you say we have to 
move the cleanmarker into the spare area of the flash-chip. This means we 
have to shorten the nodesize and fake the cleanmarker node in the nand driver 
on readback. What happens, when we flush the write buffer. The buffer starts 
at page offset 0xc, when we write at the beginning of a block. We have to 
change jffs2 node management and more things. I don't know if that's a good 
idea, because we build more incompabilties than neccecary.
We can write the cleanmarker node as it is now, because we have only one more 
write to the page and thats ok.

I suggest to use the spare-area as follows:

Pagesize 512 Bytes + 16 Byte spare area
512-514 	Short ECC for Cleanmarker write
515		Spare
516		Short Data Status Flag
517		Block Status Flag 
518-523		ECC for page write
524		Data Status Flag
525-527		Spare

Pagesize 256 Bytes + 8 Byte spare area
512-514 	ECC for page write
515		Data Status Flag
516		Short Data Status Flag
517		Block Status Flag 

We keep the Block Status Flag at it's original place. So we can retrieve bad 
blocks marked by the manufacturer (Thats only true for SmartMediaCards).
When we write a short node (cleanmarker), we use a short ECC (on 512 Byte 
page devices only) and program the Short Data Status Flag to 0. On 256 Byte 
page devices we write the cleanmarker without ECC (and hope ....).
When we flush the writebuffer, we have to ensure to use also the already 
written data for ECC calculation. We have to do this, if the Short Data 
Status Flag is zero.
We write the ECC to the ECC field and set the Data Status Flag to 0.

On read, we can determine by reading the data status fields, if no, short or 
long ECC is used. 

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