NAND flash and JFFS(2)
A message that is not in the archive (sent off-list or not yet received): 02020523405103.11497@thomas
Quoted 5 lines · Thomas Gleixner
There are different types of adaptors available:
- Very smart with controller (Useless they force this DOS/FAT style fs)
- Less smart with ECC hardware (OK, but we should have a close look on it, regarding ECC stuff, especially write to the ecc area and consecutive writes to a page). I have schematics and CPLD code. I try to figure it out.
We should be able to use their ECC hardware. As with the DiskOnChip, this effectively limits us to one write per page, even if the NAND chip can do more than that.
Quoted 2 lines
- simple without anything, like on the Cirrus evaluation boards is exactly the same as a soldered NAND chip. (No restrictions)
We already have software ECC code which we can use on these.
Quoted 2 lines
Maybe we can use the SmartMedia scheme for ECC placement in general for all NAND chips.
Except DiskOnChip, which has its own layout.
Quoted 6 lines
Quoted 3 lines
This would be feasible. I thought I'd heard of NAND flash devices which only allowed one write per page though - and I've already written the code to move the cleanmarker.
I have a look on the data sheets again. I know only about 2 writes/page limit. But maybe we need this, when we have a less smart adaptor with ECC hardware.
Yes, the ECC makes supporting multiple writes quite hard. We could invent new node types and do ECC per-node, but I think it would be better to do block-based ECC and use the hardware capabilities, as we have to do write batching into blocks anyway.
Quoted 2 lines
I had already a look on your changes.
Is there a possibility to get a mail, when CVS updates are done ?
http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs
Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
I've done some of the write batching too - we have code to set up a
Cool.
tricky hack, but now oops is gone.
OK. Could you show me the changes you had to make?
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
That's a bit of headache i don't know exactly how to handle. The only tricky thing is a write error when we flush the buffer and have data of the previous write in the buffer.
The comments say what you need to do in that case - still a PITA to actually write though.
I know, but I'm not deep enough inside the jffs2 stuff to do this. If you provide a basic implementation, i could do the same as to the wbuf stuff.
OK, I'll have a go at it. I was leaving it till last, because it's not particularly likely to happen in real life. Once the rest works, I'll be all happy and motivated to do the evil bits of the error handling :)
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
Quoted 1 line
and I haven't implemented
fsync().I implemented it basicly and it works.
How did you implement this?
I look, if the inode of the file, which has to be synced, is partially or full in the writebuffer. Then i pad and flush the buffer and adjust the
c->nextsize->free_sizeanddirty_size. Is simple but works.
OK. It would be nice if we could trigger GC to fill the wbuf, rather than padding - and only pad it if we really can't use up the space with GC writes.
Signature · 1 line
dwmw2
Quoted 4 lines · David Woodhouse
We should be able to use their ECC hardware. As with the DiskOnChip, this effectively limits us to one write per page, even if the NAND chip can do more than that.
The ECC hardware does not limit us to one write. The ECC hardware just calculates the ECC if requested and you must read it back out of the CPLD. Then you program it into the spare area. On read you must also enable the ECC hardware, read the page, read the ECC .... You can do also read/write without ECC.There are no restrictions which part of the spare area to use. You can also do everything in software. Anyway we need a different driver for this adaptors, because they implement the access to the select lines in their CPLD.
Quoted 3 lines
Quoted 2 lines
Maybe we can use the SmartMedia scheme for ECC placement in general for all NAND chips.
Except DiskOnChip, which has its own layout.
OK
Quoted 7 lines
Quoted 3 lines
I have a look on the data sheets again. I know only about 2 writes/page limit. But maybe we need this, when we have a less smart adaptor with ECC hardware.
Yes, the ECC makes supporting multiple writes quite hard. We could invent new node types and do ECC per-node, but I think it would be better to do block-based ECC and use the hardware capabilities, as we have to do write batching into blocks anyway.
See above
Quoted 1 line
OK. Could you show me the changes you had to make?
Should i put them into CVS to jffs-nand-branch or send them by mail ?
Quoted 3 lines
OK, I'll have a go at it. I was leaving it till last, because it's not particularly likely to happen in real life. Once the rest works, I'll be all happy and motivated to do the evil bits of the error handling :)
sounds good to me
Quoted 3 lines
OK. It would be nice if we could trigger GC to fill the wbuf, rather than padding - and only pad it if we really can't use up the space with GC writes.
Sure, but we must have something, that makes sure that data is written immidiatly to the flash, if we have sensitive data loggers or configuration data, where a loss is not acceptable.
Another thought about cleanmarker nodes. If we keep them in the page, we can easy burn a jffs2-image into a raw flash. This makes life easier for bootloaders....
Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: [email protected], http://www.autronix.de
Quoted 5 lines · Thomas Gleixner
The ECC hardware does not limit us to one write. The ECC hardware just calculates the ECC if requested and you must read it back out of the CPLD. Then you program it into the spare area. On read you must also enable the ECC hardware, read the page, read the ECC .... You can do also read/write without ECC.There are no restrictions which part of the spare area to use.
True - but in order to implement ECC we have to either write partial blocks _without_ ECC, until we fill the block and write the ECC data with the 512nd byte, or batch the writes into pages.
Quoted 1 line
Should i put them into CVS to jffs-nand-branch or send them by mail ?
Mail's probably best at this stage - thanks.
Quoted 6 lines
Quoted 3 lines
OK. It would be nice if we could trigger GC to fill the wbuf, rather than padding - and only pad it if we really can't use up the space with GC writes.
Sure, but we must have something, that makes sure that data is written immidiatly to the flash, if we have sensitive data loggers or configuration data, where a loss is not acceptable.
We can do that. Triggering a GC pass to try to fill the wbuf won't take long - it can be done in the context of a fsync() call, and if we can't find anything else to write out, _then_ we pad it and still return (almost) immediately.
We probably need to rethink our (ab)use of the s_dirt member of the superblock, and actually make write_super() do the sync too.
Quoted 3 lines
Another thought about cleanmarker nodes. If we keep them in the page, we can easy burn a jffs2-image into a raw flash. This makes life easier for bootloaders....
Bootloaders need to know about JFFS2 anyway - currently they erase blocks without putting a cleanmarker in, then Linux will re-erase all those blocks again on first mount.
Signature · 1 line
dwmw2
Quoted 4 lines · David Woodhouse
On Wed, 6 Feb 2002, Thomas Gleixner wrote:
True - but in order to implement ECC we have to either write partial blocks _without_ ECC, until we fill the block and write the ECC data with the 512nd byte, or batch the writes into pages.
I mean we should keep the batch write. Thats correct. But we can leave the cleanmarker where it is now and write it without ECC and put the rest of the page with ECC. On small NAND devices we have only 8byte spare area per block. We need 3 byte for ECC and at least 1 byte for flags. Then the cleanmarker area is reduced to 4 bytes. Is that enough ?
Quoted 2 lines
Quoted 1 line
Should i put them into CVS to jffs-nand-branch or send them by mail ?
Mail's probably best at this stage - thanks.
I will send it in the afternoon
Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: [email protected], http://www.autronix.de
Quoted 5 lines · Thomas Gleixner
I mean we should keep the batch write. Thats correct. But we can leave the cleanmarker where it is now and write it without ECC and put the rest of the page with ECC. On small NAND devices we have only 8byte spare area per block. We need 3 byte for ECC and at least 1 byte for flags. Then the cleanmarker area is reduced to 4 bytes. Is that enough ?
Yeah, that's fine. We can do either - I'm not sure it matters too much.
Signature · 1 line
dwmw2
Quoted 8 lines · David Woodhouse
Quoted 5 lines · Thomas Gleixner
I mean we should keep the batch write. Thats correct. But we can leave the cleanmarker where it is now and write it without ECC and put the rest of the page with ECC. On small NAND devices we have only 8byte spare area per block. We need 3 byte for ECC and at least 1 byte for flags. Then the cleanmarker area is reduced to 4 bytes. Is that enough ?
Yeah, that's fine. We can do either - I'm not sure it matters too much.
I'm going to merge your current CVS code with my wbuf changes. But we should decide what to do with the cleanmarker stuff and the usage of the spare area.
On devices with 512 byte pagesize we have a spare area of 16 byte. On smaller devices with 256 byte pagesize we have only 8 byte.
We have already some layouts for the spare area:
DOC
Byte 0-5 ECC
Byte 6-7 block used status (0x55,0x55)
Byte 8-15 not assigned
SmartMediaCard 256 Byte pagesize
Byte 0-5 not assigned
Byte 6 bad block status
Byte 7 not assigned
SmartMediaCard 512 Byte pagesize
Byte 0-5 not assigned
Byte 6 bad block status
Byte 7 not assigned
Byte 8-15 not assigned
Raw Nand Chips 256 Byte pagesize
Byte 0-7 not assigned
Raw Nand Chips 512 Byte pagesize
Byte 0-15 not assigned
The bad block status on the SmartMediaCards is programmed to a value different to 0xff by the manufacturer. We should use this too. Bad blocks on raw NAND chips are marked by values different to 0xff in the first two pages of a block.
I don't know, if there's a similar technique on DOC.
I think the SmartMedia bad block indication is much more convenient than the raw NAND solution. May be we can implement a utility to move the bad block info into the spare area on raw NAND chips, so the bad block indication would be the same. This could also be done at production time or be part of a bootloader, because it has to done only once.
The nand driver should exclude these blocks from erase/write to keep this information intact. But then we should read the bad block information at mount time too. This can easily be done with the read_cleanmarker_oob function. If we detect a bad block during operation, we could mark it the same way, so the block is excluded for ever.
Layout with cleanmarker in spare area:
DOC
Byte 0-5 ECC
Byte 6-7 block used status (0x55,0x55) or bad block (value != 0x55 && != 0xff)
Byte 8-15 cleanmarker
SmartMedia and raw NAND 512 Byte pagesize
Byte 0-5 ECC
Byte 6 bad block status
Byte 7 page data valid flag
Byte 8-15 cleanmarker
SmartMedia and raw NAND 256 Byte pagesize
Byte 0-2 ECC for even page
Byte 3-5 cleanmarker
Byte 6 bad block status
Byte 7 page data valid flag
Some information about the current state. I ran a 24h test with copying, moving, deleting files with random power down. The filesystem is clean and we have no data loss except some broken files on powerdown. But nothing in the world can help, if we write a new file and loose power before we finished it.
Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: [email protected], http://www.autronix.de
Quoted 11 lines · Thomas Gleixner
On Thursday, 7. February 2002 08:04, David Woodhouse wrote:
I'm going to merge your current CVS code with my wbuf changes. But we should decide what to do with the cleanmarker stuff and the usage of the spare area.
On devices with 512 byte pagesize we have a spare area of 16 byte. On smaller devices with 256 byte pagesize we have only 8 byte.
We have already some layouts for the spare area:
DOC
Byte 0-5 ECC
Byte 6-7 block used status (0x55,0x55)
Byte 8-15 not assigned
Yes it is, at least for the first three pages in each eraseblock. It holds the 'Unit Control Information' structures.
Quoted 4 lines
SmartMediaCard 256 Byte pagesize
Byte 0-5 not assigned
Byte 6 bad block status
Byte 7 not assigned
Where's the ECC when we're using the SmartMedia format on them?
Quoted 5 lines
The bad block status on the SmartMediaCards is programmed to a value different to
0xffby the manufacturer. We should use this too. Bad blocks on raw NAND chips are marked by values different to0xffin the first two pages of a block.
I don't know, if there's a similar technique on DOC.
Same as raw NAND I believe. The DiskOnChip driver lists the NAND chips which are used - all the data sheets are available.
Quoted 2 lines
I think the SmartMedia bad block indication is much more convenient than the raw NAND solution.
Either way, you mustn't ever erase a block which is marked bad, right?
Quoted 9 lines
May be we can implement a utility to move the bad block
info into the spare area on raw NAND chips, so the bad block indication would be the same. This could also be done at production time or be part of a bootloader, because it has to done only once.
The nand driver should exclude these blocks from erase/write to keep this information intact. But then we should read the bad block information at mount time too. This can easily be done with theread_cleanmarker_oobfunction. If we detect a bad block during operation, we could mark it the same way, so the block is excluded for ever.
Seems sane.
Quoted 12 lines
Layout with cleanmarker in spare area:
DOC
Byte 0-5 ECC
Byte 6-7 block used status (0x55,0x55) or bad block (value !=0x55&& !=0xff)
Byte 8-15 cleanmarkerSmartMedia and raw NAND 512 Byte pagesize
Byte 0-5 ECC
Byte 6 bad block status
Byte 7 page data valid flag
Byte 8-15 cleanmarker
Quoted 5 lines
SmartMedia and raw NAND 256 Byte pagesize
Byte 0-2 ECC for even page
Byte 3-5 cleanmarker
Byte 6 bad block status
Byte 7 page data valid flag
Those also look sane.
Quoted 4 lines
Some information about the current state. I ran a 24h test with copying, moving, deleting files with random power down. The filesystem is clean and we have no data loss except some broken files on powerdown. But nothing in the world can help, if we write a new file and loose power before we finished it.
Cool. Does this leave some files on the fs and make lots of GC happen, and check the contents of all files on restart? Vipin's tests did this quite well, IIRC.
Now I suppose we need to look at using write_super and sb->s_dirt the way that God intended, for flushing pending writes in the wbuf rather than just triggering erases.
Signature · 1 line
dwmw2
A message that is not in the archive (sent off-list or not yet received): 0202121847440K.00764@thomas
Quoted 4 lines · Thomas Gleixner
Actual state of JFFS2 on NAND
I will run some more tests tonight.
Excellent test result.
Test is as follows:
SmartMediaCard: 16MB two partitions a 8MB
1st partition is root
2nd partition is data
data contains 20 files, which are not touched.
3 tasks running in loops
task 1:
copy 40 files from root to data, remove the files on root diff against original files on nfs
copy 40 files from data to root, remove the files on data diff against original files on nfs
task 2:
open file A on data for write every 1 sec. append 1000 bytes and close the file
loop until filesize is >1MB
open file B on data for write every 1 sec. append 1000 bytes and close the file
loop until filesize is >1MB
task3:
wait until A is >1MB
copy file A to nfs
check file integrity of A
remove file A on data
wait until B is >1MB
copy file B to nfs
check file integrity of B
remove file B on data
A independent control removes power after ~ 1-2 hours without warning. After reboot:
The untouched 20 files on data are diffed against the original files on nfs The 40 files, which are shuffeld between root and data are diffed against original files on nfs.
task1 starts
task2 takes the file, which was filled at last and starts
task3 starts
The test ran for 8 hours without any problem.
Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: [email protected], http://www.autronix.de