DiskOnChip 2000 TSOP bad blocks table

[David Dillow]

On Thu, 2003-11-20 at 15:33, Al Cousson wrote:
> I received this x86 compatible SBC computer with a DiskOnChip 2000
> TSOP for eval the other day.
> 
> I got the latest snapshot of the MTD source, compiled it with the
> latest 2.4.22 kernel and it recognized the chip.  It does produce a
> few curious messages at bootup though:
> 
> INTFL: corrupt block 390 in chain 390, chain length 0, erase mark 0x0?
> INTFL: formatting chain at block 390
> INTFL: formatting block 390
> Error erasing at 0x618000

I've seen the "Error erasing" messages on some of my DoC's as well, so
maybe something is goofy in my patches for the TSOP support. At first
glance, I don't see it, but it's going to be next month before I can
devote much time to it.

What's odd is sometimes it works, and sometimes it doesn't, for the same
block. I wonder if we're tripping into something timing sensitive, and
(not) catching an interrupt at the right time.

> INTFL: cannot calculate a geometry to match size of 0x3ea60.
> INTFL: using C:1002 H:16 S:16 (== 0x3ea00 sects)

This is fairly normal, don't worry about it -- it means you've lost 96
sectors off the end of the device. Consider them (extra) spare erase
units.


> The M-Systems dformat utility failed with "Error - Unreadable bad
> blocks table."  The M-Systems tech support told me to RMA it with my
> vendor.  I got a replacement DiskOnChip 2000 TSOP in.

You've definitely hosed the bad blocks table. I've done this myself a
few times....

While not the best solution (making a backup of the original BBT when
you get the chip), if you erase the entire DoC (or at least everything
but the IPL), dformat will rebuild the BBT for you, though it may miss a
few. Use the mtdchar driver and the erase utilities in the MTD
distribution to do this. Make sure you have the correct .EXB file to
replace the IPL!

> During bootup, I get the same INTFL messages.  Actually, the above
> messages are from the second chip.  The numbers may have been slightly
> different for the first one.  I haven't attempted the doc_loadbios on
> it, fearing the corrupted bad blocks table thing.  I never mounted or
> even fdisk'ed this second chip.
> 
> But, the M-Systems utilities are again reporting "Unreadable bad
> blocks table".
> 
> So, finally to my questions:
> 
> 1.  Is it possible that the INFTL driver is corrupting the bad blocks
>     table?

I'm seeing INFTL corruption on my DoC, but it may be a combination of
the patches I'm using. I've already caught one bug I introduced... When
I get them cleaned up, I'll be sending them to this list.

> 2.  Does doc_loadbios need to be updated to work on the DiskOnChip
>     2000 TSOP? 

Sorry, I've not played with this.

> 3.  Or, did I just get 2 bad DiskOnChips?

The bad erase mark is interesting, but it is possible the doc2000
patches for the TSOP are to blame. I doubt the DoCs you have are bad.

Dave