Is DOC Address 0xC8000 Something Special?
ollie at sis.com.tw
Tue May 1 23:20:58 EDT 2001
Shuh C Chang wrote:
> So far I have *yet* to find the answer/solution. Like I mentioned in my
> original posting, addresses at 0xD0000 and 0xD8000 work well. I am still
> trying different options. I would welcome any suggestions from the pundits
> out there.
If the same hardware setup works for 0xDxxxx but 0xCxxxx, then it must
be VGA BIOS related stuff. And YES, the old dinosor still lives in your
> On a related note, I would suggest adding some notes to the MTD HOWTO
> document about the DOC itself. The DOC chip must be in a *good format*
> (don't know what it means yet) before you can even nftl_format or fdisk
> through /dev/mtd0 and /dev/nftla, etc. One example that I have is that
> during the experiment of installing the mtd/nftl drivers, one DOC
> (Millennium) was zapped. The DOC chip could not be recognized until it is
> "reburned" with a good "image file" using M-System's own docpmap DOS
> utility. The "good image file" was a bootable kernel in ext2 fs. We used
> it for the original M-System's binary driver. As I mention above, I don't
> know what constitutes a "good format," but the one I had worked.
The reason you can not detect a "corrupted" DoC is because you did not
disable the 0x55AA probe in the Config tool. Usually the docprobe probes
the 0x55AA signautre for DoC, but if your DoC is really screwed up you
certainly don't have them. Trust me, we F**KED the DoC as bad as you can
image in LinuxBIOS project and docprobe works PERFECTLY!!! Generally
speaking, you can drop your M-System supplied software altogether.
More information about the linux-mtd