DiskOnChip 2000 TSOP bad blocks table

DiskOnChip 2000 TSOP bad blocks table

[Al Cousson]

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
INTFL: error while formatting block 390
INTFL: cannot calculate a geometry to match size of 0x3ea60.
INTFL: using C:1002 H:16 S:16 (== 0x3ea00 sects)

I fdisk'ed it, made an ext2 filesystem on it and copied my files onto
it.  So far, so good.  Then I attempted to install grub on it,
following the directions in the latest MTD source.  Running
doc_loadbios totally hosed the DiskOnChip.  The driver no longer
recognized any DiskOnChips at bootup.

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.

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?

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

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


Thanks,
Al Cousson

-----------------------------------------------------------------
Al Cousson, Systems Engineer     |  Phone: (337) 261-0660
C & C Technologies, Inc.         |  Fax:   (337) 261-0192
730 E. Kaliste Saloom Road       |  mail:  avc@cctechnol.com             
Lafayette, LA 70508              |  
-----------------------------------------------------------------

Re: DiskOnChip 2000 TSOP bad blocks table

[Ilguiz Latypov]

Hello Al,

On Thu, Nov 20, 2003 at 02:33:55PM -0600, Al Cousson wrote:
> 2.  Does doc_loadbios need to be updated to work on the DiskOnChip
>     2000 TSOP? 

I am not sure if the current patch to GRUB recognizes INFTL.  I know
that the NFTL block access layer did work.  The beginning of the NFTL
layer must not be overwritten by the GRUB firmware.  Once you burned the
firmware, you may need to re-format the rest of the chip.  The size of
the GRUB firmware rounded to the next erase sector boundary could be
given to the format utility as the start offset for the NFTL layer.

-- 
Ilguiz Latypov

Re: 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

Re: DiskOnChip 2000 TSOP bad blocks table

[David Woodhouse]

On Thu, 2003-11-20 at 14:33 -0600, Al Cousson wrote:
> But, the M-Systems utilities are again reporting "Unreadable bad
> blocks table".

Ouch.

> 1.  Is it possible that the INFTL driver is corrupting the bad blocks
>     table?

The INFTL driver completely ignores the bad block table. Running
eraseall wipes the bad block table. 

This is a bad thing. I have disabled the support for these devices
until the Bad Block Table is properly handled.

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

No, the driver needs to be updated to understand and enforce the BBT.

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

No, we broke them by erasing them.

The Bad Block Table is fairly simple. It won't be that hard to implement
proper support for it.

-- 
dwmw2