something drastic (relocating the BNAND media header)
dan_brown at ieee.org
Thu Jun 30 11:29:33 EDT 2005
Lindstrom James-A19027 wrote:
> 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).
That is really odd. I happen to have a couple of MD2202-D384 parts
here, formatted with MSYS tools version 5.1.4, and my BNAND data is at
0x4000. Since the erasesize is 16k, there should be media headers at
0x4000 and 0x5000 according to the specs (unless you've removed your IPL
region in which case they should be at 0x0000 and 0x1000).
Can you use M-systems' 'dinfo' program from DOS and see what it reports
about your erase size, media header location, etc? Let me know if you
need help doing this.
Also, could you please send the output of running 'mtd_debug info <device>'?
> 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.
Nothing strange about it. If your physical erase size really were
0x2000, the MSYS tools would have set BlockMultiplierBits=1 (instead of
0) to create a logical unit size of 0x4000, because the NFTL format
requires <= 32768 logical units. By forcing the physical erase size to
0x2000 you break that invariant.
David and Thomas, do you have any ideas about what might be going on
here? It looks to me like a problem sending the proper address to the
> ( The back story is this: the previous engineer using these chips had used
> the MSYS drivers and formatted two EXT2 partitions onto it. )
Hmm. I wonder if the MSYS drivers were screwed up somehow.
> 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).
First of all you can't use fdisk. You can use either the DOS-based MSYS
tools or 'docfdisk' to alter the BNAND partition table. You CAN fdisk
the virtual block device created by the NFTL driver -- could that be
what you mean? If so, you're planning to run a standard filesystem
(like ext2) over NFTL over diskonchip. I don't know if this is really
working at the moment. Does anyone out there sucessfully do this?
I only have experience using jffs2 directly over the mtd device. I
highly recomment this route even if NFTL is currently working :)
To answer your actual question... if your media header really is at
0x2000 (I have some doubt about that, but 'dinfo' should clear up the
issue), your best be might be to use 'dformat' from DOS to reformat your
device, rather than hacking up your own tool.
> How badly will this probably screw things up? Should I have a fire
> extinguisher near by? Is this likely to hose the DOC?
You'll lose your data, certainly, but you won't hose the device. You
can always use dformat to fix whatever problems you cause (unless you
manage to hose the bad block table at the very end of the device, which
would be bad).
More information about the linux-mtd