NAND flash and JFFS(2)

DISCUSSION Thomas Gleixner 1 participant 3 messages Feb 11, 2002 Memory technology devices (MTD)

lore

Share & tools

lore

Thomas Gleixner

author

2002-02-11 15:18 UTC #0 lore raw

Quoted 1 line · David Woodhouse

Where's the ECC when we're using the SmartMedia format on them?

The layout for SmartMedia DOS for 256 byte pagesize:

Even page:
Byte 0-3 reserved area
Byte 4 data status flag
Byte 5 block status flag (bad block marker)
Byte 6-7 block adress 1

Odd page:
Byte 0-2 ECC Area-2 (odd page)
Byte 3-4 Block Address 2
Byte 5-7 ECC Area-1 (even page)

The layout for SmartMedia DOS for 512 byte pagesize:
Byte 0-3 Reserved Area
Byte 4 Data Status Flag
Byte 5 block status flag (bad block marker)
Byte 6-7 Block Address-1
Byte 8-10 ECC Area-2 (byte 256-511)
Byte 11-12 Block Address 2
Byte 13-15 ECC Area-1 (byte 0-255)

They build a virtual blocksize of 512 byte on the small devices. I thought about doing the same, but IMHO it's not a good idea.

Quoted 1 line

Either way, you mustn't ever erase a block which is marked bad, right?

The datasheet says it's not allowed to do this, due to the fact, that you loose bad block information and maybe you can't write the bad block info again. So you would run always into this bad block after restart.

Sorry, as you see above, i had some trouble to count. The bad block status on SmartMedia is not at Byte 6 it's at Byte 5. We want to keep it there, so we have to split the ECC data on 512 byte devices.
SmartMedia and raw NAND 512 byte pagesize
Byte 0-3 ECC part 1
Byte 4 page data valid flag
Byte 5 bad block status
Byte 6-7 ECC part 2
Byte 8-15 cleanmarker

SmartMedia and raw NAND 256 Byte pagesize
Byte 0-2 ECC
Byte 3-4 cleanmarker
Byte 5 bad block status
Byte 6 page data valid flag
Byte 7 spare

Please let me know, if we can fix this layout. Then i would implement and test it.

Quoted 3 lines

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.

I have some files untouched on the fs. I check them with diff after reboot. There was no failure.

Quoted 3 lines

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.

What do you mean exactly and what about the cleanup, when we fail during flush_wbuf ?

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

Thomas Gleixner

author

2002-02-11 15:35 UTC #1 lore raw

Quoted 25 lines · Thomas Gleixner

Quoted 1 line · David Woodhouse
Where's the ECC when we're using the SmartMedia format on them?
The layout for SmartMedia DOS for 256 byte pagesize:
Even page:
Byte 0-3 reserved area
Byte 4 data status flag
Byte 5 block status flag (bad block marker)
Byte 6-7 block adress 1
Odd page:
Byte 0-2 ECC Area-2 (odd page)
Byte 3-4 Block Address 2
Byte 5-7 ECC Area-1 (even page)
The layout for SmartMedia DOS for 512 byte pagesize:
Byte 0-3 Reserved Area
Byte 4 Data Status Flag
Byte 5 block status flag (bad block marker)
Byte 6-7 Block Address-1
Byte 8-10 ECC Area-2 (byte 256-511)
Byte 11-12 Block Address 2
Byte 13-15 ECC Area-1 (byte 0-255)

Quoted 3 lines

They build a virtual blocksize of 512 byte on the small devices. I thought about doing the same, but IMHO it's not a good idea.

I reflected this question again and we should do this very careful before implemetation. If we choose the same layout, somebody would be able to implement the SmartMedia DOS fs on top of SmartMedia and raw NAND flash. I personally have not interest in this fs, it's ok for MP3 players and digicams but not for industrial use.

Thomas Gleixner

author

2002-02-11 19:14 UTC #2 lore raw

Quoted 5 lines · Thomas Gleixner

I reflected this question again and we should do this very careful before implemetation. If we choose the same layout, somebody would be able to implement the SmartMedia DOS fs on top of SmartMedia and raw NAND flash. I personally have not interest in this fs, it's ok for MP3 players and digicams but not for industrial use.

I had a look at the nand driver, where we have to do some changes anyway to support a different ECC address. To get the flexibility to use either a JFFS2 specific ECC scheme or a different scheme like the SmartMedia DOS-FAT i will add a array to the nand structure, which holds the positions of the ECC bytes inside the spare area and a flag, which can be used to support the virtual pagesize of 512 Byte for small NAND devices (if anybody is going to implement this).
The filesystem driver can set the ECC byte positions, so they match it's requirements. We could add config options to select a default ECC scheme, so we have access to the chip as char device too. I'm not sure if we need this really.
So we have the flexibility to do what we want and we don't prevent anybody from implementing a different system.

I will try it with the following scheme tonight:

SmartMedia and raw NAND 512 byte pagesize
Byte 0-3        ECC part 1
Byte 4           page data valid flag
Byte 5           bad block status
Byte 6-7        ECC part 2
Byte 8-15      cleanmarker

SmartMedia and raw NAND 256 Byte pagesize
Byte 0-2        ECC
Byte 3           spare
Byte 4           page data valid flag
Byte 5           bad block status
Byte 6-7        cleanmarker

I have both card types so i can verify that it works.