Bad Block Table

Bad Block Table

[Dvir Oren]

[-- Attachment #0: forwarded message --]
[-- Type: message/rfc822, Size: 664 bytes --]

From: Dvir Oren <dvir@>
To: Orono@m-sys.com
Cc: mtd@infraded.org
Subject: bad block table
Date: Sun, 26 Mar 2000 12:19:36 +0200 (IST)
Message-ID: <14557.58424.842711.701852@4x1.lucid>

One question I forgot to ask is where is the bad block table?
If I need to do a docpmap /e, where do I take the bad block
table from?

---------
Dvir Oren <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Bad Block Table

[Dvir Oren]

I have several questions about the bad block table:

1.  Where is it located?  Oron from M-Systems said that before erase the
flash it is important to save it.  So where is it located, and how can I
save it? (Will dd work?)

2.  Also mentioned was that during the lifetime of the flash, if a new
bad block is found, it is marked as a bad block.  This will be effective
only before doing a boot.  Question is, who is responsible for finding
those bad blocks - the M-Systems kernel driver?

3.  And if the driver is responsible for this, does the MTD driver do
the same?

Also, on a related issue, I found that after using nftl_format,
M-Systems' dfromat does not recognize the flash correctly, and errors
something about "out of spare units".  I usually fixed this by erasing
the flash (docpmap /e).  Any other way to do it?  dformat /unformat
doesn't seem to do it.

-- 
Dvir Oren               <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Bad Block Table

[David Woodhouse]

dviro@lucidvon.com said:
>  1.  Where is it located?  Oron from M-Systems said that before erase
> the flash it is important to save it.  So where is it located, and how
> can I save it? (Will dd work?) 

Stored in the same erase block as the NFTL Media Header(s). 
Look for BadUnitTable in util/nftl_format.c


dviro@lucidvon.com said:
>  2.  Also mentioned was that during the lifetime of the flash, if a
> new bad block is found, it is marked as a bad block.  This will be
> effective only before doing a boot.  Question is, who is responsible
> for finding those bad blocks - the M-Systems kernel driver?

This is effective only until you next reboot - i.e. it's not written to the 
BadUnitTable, only stored in memory. Presumably, the M-Systems driver notices 
a failure when it tries to erase or write a block, and marks it bad.


dviro@lucidvon.com said:
>  3.  And if the driver is responsible for this, does the MTD driver do
> the same? 

Not yet.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Bad Block Table

[Dvir Oren]

David Woodhouse wrote:

> Stored in the same erase block as the NFTL Media 
> Header(s).  Look for BadUnitTable in util/nftl_format.c

I now have some more questions:

If I understand correctly, 512 zones (== bytes?) are 1 block.  And then
you try to erase each block, and see if
it was written correctly, and if not, you save it in the
table.

However - it seems to me like the position you write the
table depends on where the nftl_format got started.  That is, if I write
nftl_format /dev/mtd0 49152, it'll write it at a different place than if
I wrote nftl_format /dev/mtd0.
Isn't the table supposed to be at the same place all the time?  I just
called M-Systems, and they claim it's at the same position all the
time.  They have a command to save it: dformat /win:xxxx /log:<file>,
which appears like it will be at the same position each time.

And also - Oron from M-Systems said something about saving the table,
and never writing to it.  That's not quite what you do.  You check for
the bad blocks, and then re-write the table.  Am I correct?

I didn't understand why there is MediaUnit1 and MediaUnit2.

Thanks for the help!

--
Dvir Oren               <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Bad Block Table

[Dvir Oren]

David Woodhouse wrote:
> dviro@lucidvon.com said:
>  3.  And if the driver is responsible for this, does the 
> MTD driver do the same?
> 
> Not yet.

But does MTD even care about the BadBlockTable?  That is, does nftl.c
check that the block that is about to be written to is not in the bad
block table?

If not, then I guess there is no point in restoring the bad block table
when using the MTD drivers, since they don't care about it anywy.  On
the other hand, nftl_format reconstructs the bad block table anyway.

Could this explain why I'm getting file system trashes?

-- 
Dvir Oren               <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Bad Block Table

[David Woodhouse]

dviro@lucidvon.com said:
>  But does MTD even care about the BadBlockTable?  That is, does nftl.c
> check that the block that is about to be written to is not in the bad
> block table?

Not yet. That'll come when it handle async erases properly - and keeps a queue 
of preerased blocks which are available for writing, rather than going 
trawling for a new one each time it needs one.


dviro@lucidvon.com said:
>  Could this explain why I'm getting file system trashes?

If you've got bad blocks of flash, yes. It's more likely that I'm just 
violating some of the timing requirements for the DiskOnChip, though. 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Bad Block Table

[Dvir Oren]

BTW:  I tried using dformat /win:XXXX /log:<file>, to save the Bad Block Table, but
got a 0 sized file.  Either this means that there are no bad blocks, or that this
feature doesn't work.

-- 
Dvir Oren               <dviro@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org