something drastic (relocating the BNAND media header)

Lindstrom James-A19027 A19027 at
Thu Jun 30 10:31:24 EDT 2005

Hi gang,

I've written twice this month asking for help getting my MD2202-D384 DoC
working.  I've got the kernel (2.4.18 (with cerf patches) plus snapshot
2005-03-04 plus my hacks to get it to build) to recognize my controller,
but the issue was that it wasn't finding a BNAND media header.  I tweaked
my page size from 0x4000 down to 0x2000 and sure enough the code found a
BNAND media header at 0x2000 (not a boundary it was checking, clearly,
using the larger page size).  Strangely, though, using that page size, and
given the size of my DOC (384MB), there were >= 32768 pages and, thus, the
mtd code complained that the nMultiplierBits was too small or something 
like that.  I removed that check just to see if the mtd code could even see
the partitions or anything.  It did see two partitions (which was correct)
but things were clearly screwed up.

( The back story is this: the previous engineer using these chips had used
the MSYS drivers and formatted two EXT2 partitions onto it. )

So here's where the fun comes in.  Diskonchip.c doeesn't see the BNAND 
media header at pagesize=0x4000, but at pagesize=0x2000 it sees it and says
that nMultiplierBits isn't sane.  Does anyone think I'd have any luck if I hacked in some code that reads my media header, writes it to 0x4000 and then
use pagesize=0x4000 as though everything were normal?  What I'd hope is that
if I do that, and set the nPartitions to 0, then I'd be able to fdisk the 
/dev/mtdX (X=4 in my case, as I've got 0-3 for flash).  

How badly will this probably screw things up?  Should I have a fire
extinguisher near by?  Is this likely to hose the DOC?


More information about the linux-mtd mailing list