Skip to contentSkip to conversation

Absent Configure.help

DISCUSSION David Woodhouse 4 participants 9 messages Apr 27, 2001 – May 2, 2001 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

I just added some help text. I've not bothered with some of the mapping drivers - please could the owners of those fix it up accordingly.

If you have suggested improvements to the text I've thrown together, please feel free to send patches. But at least there's something there now.

Still missing (afaict) are:

CONFIG_MTD_CFI_FLAGADM
CONFIG_MTD_ARM
CONFIG_MTD_IQ80310
CONFIG_MTD_CSTM_MIPS_IXX
CONFIG_MTD_CSTM_MIPS_IXX_BUSWIDTH
CONFIG_MTD_CSTM_MIPS_IXX_LEN
CONFIG_MTD_CSTM_MIPS_IXX_START
CONFIG_MTD_DBOX2
CONFIG_MTD_SBC_GXX

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

#1 lore raw

Is DOC Address 0xC8000 Something Special?

Dear MTD fans:

I would like to ask the developers in this list if any of you have ever experienced a DiskOnChip (DOC) problem not being recognized at address 0xC8000 ONLY by docprobe.

By accident, we found that, for some reason, docprobe.c fails to detect the DOC address set at 0xC8000. Is it a special address that needs special treatment? I checked the source code of docprobe.c but couldn't find anything suspecious. I then begin to suspect that if this is because of the eval board (directly from M-System) that we are using. Did any of you experience the same problem with other (non-M-System) boards? Can you shed some light on this?

The same problem (not recognizing DOC) occurs for both fixed address probe (C8000 in config) as well as autoprobe (0000 in config). Strangely, docprobe works well (again, both fixed and auto probe) at two other DOC
addresses: 0xD0000 and 0xD8000.

We are using M-System's eval boards: "91-PB-010-00 REV C" (newer board) and "91-PB-001-00 REV B" (older board), which can only be physically set at three addresses: C8000, D0000 and D8000. The Linux kernel that we use is 2.4.2.

Based on our tests, the same docprobe code produces a slightly different results using these two different eval boards from M-System. The older board basically produces the same results as the new board except that it's
missing the formatting part in the output. It looks like that when the
newer board is used, docprobe can detect that the DOC is not properly formatted yet and then does format the "chain" and "block". When the older board is used, docprobe can not detect the format, and therefore requires a manual nftl format later (based on the well known "Could not find valid boot record" and "Could not mount NFTL device" messages).

Here are the dmesg snips for these tests based on the newer board.

======== Auto Probe for DOC Address C8000 ================ M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc. Using configured probe address 0xc8000
Possible DiskOnChip with unknown ChipID EA found at 0xc8000 M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI $Id: nftl.c,v 1.57 2000/12/01 17:51:54 dwmw2 Exp $

======== Fixed Probe for DOC Address C8000 ================ M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc. Using configured probe address 0xc8000
Possible DiskOnChip with unknown ChipID EA found at 0xc8000

======== Auto Probe for DOC Address D0000 ================ M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc. Possible DiskOnChip with unknown ChipID EA found at 0xc8000 Possible DiskOnChip with unknown ChipID 00 found at 0xca000 Possible DiskOnChip with unknown ChipID FF found at 0xcc000 Possible DiskOnChip with unknown ChipID FF found at 0xce000 DiskOnChip Millennium found at address 0xD0000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) 1 flash chips found. Total DiskOnChip size: 8 Mbytes
Possible DiskOnChip with unknown ChipID FF found at 0xd2000 Possible DiskOnChip with unknown ChipID FF found at 0xd4000 Possible DiskOnChip with unknown ChipID FF found at 0xd6000 Possible DiskOnChip with unknown ChipID FF found at 0xd8000 Possible DiskOnChip with unknown ChipID FF found at 0xda000 Possible DiskOnChip with unknown ChipID FF found at 0xdc000 Possible DiskOnChip with unknown ChipID FF found at 0xde000 Possible DiskOnChip with unknown ChipID FF found at 0xe0000 Possible DiskOnChip with unknown ChipID FF found at 0xe2000 Possible DiskOnChip with unknown ChipID FF found at 0xe4000 Possible DiskOnChip with unknown ChipID FF found at 0xe6000 Possible DiskOnChip with unknown ChipID FF found at 0xe8000 Possible DiskOnChip with unknown ChipID FF found at 0xea000 Possible DiskOnChip with unknown ChipID FF found at 0xec000 Possible DiskOnChip with unknown ChipID FF found at 0xee000 M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI $Id: nftl.c,v 1.57 2000/12/01 17:51:54 dwmw2 Exp $
Block 1015: free but referenced in chain 16
Formatting chain at block 16
Formatting block 16
Formatting block 1015
Block 1016: free but referenced in chain 17
Formatting chain at block 17
Formatting block 17
Formatting block 1016
Block 1019: free but referenced in chain 20
Formatting chain at block 20
Formatting block 20
Formatting block 1019
Block 1020: free but referenced in chain 21
Formatting chain at block 21
Formatting block 21
Formatting block 1020
Block 1021: free but referenced in chain 22
Formatting chain at block 22
Formatting block 22
Formatting block 1021
Block 35: referencing block 24 already in another chain Formatting chain at block 35
Formatting block 35
Block 36: referencing block 25 already in another chain Formatting chain at block 36
Formatting block 36
Block 37: referencing block 26 already in another chain Formatting chain at block 37
Formatting block 37
Block 41: referencing block 32 already in another chain Formatting chain at block 41
Formatting block 41
Block 46: referencing block 42 already in another chain Formatting chain at block 46
Formatting block 46
nftla: nftla1

======== Fixed Probe for DOC Address D0000 ================ M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc. Using configured probe address 0xd0000
DiskOnChip Millennium found at address 0xD0000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) 1 flash chips found. Total DiskOnChip size: 8 Mbytes
M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI $Id: nftl.c,v 1.57 2000/12/01 17:51:54 dwmw2 Exp $
Block 1021: free but referenced in chain 22
Formatting chain at block 22
Formatting block 22
Formatting block 1021
nftla: nftla1

======== Auto Probe for DOC Address D8000 ================ M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc. Possible DiskOnChip with unknown ChipID EA found at 0xc8000 Possible DiskOnChip with unknown ChipID 00 found at 0xca000 Possible DiskOnChip with unknown ChipID FF found at 0xcc000 Possible DiskOnChip with unknown ChipID FF found at 0xce000 Possible DiskOnChip with unknown ChipID FF found at 0xd0000 Possible DiskOnChip with unknown ChipID FF found at 0xd2000 Possible DiskOnChip with unknown ChipID FF found at 0xd4000 Possible DiskOnChip with unknown ChipID FF found at 0xd6000 DiskOnChip Millennium found at address 0xD8000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) 1 flash chips found. Total DiskOnChip size: 8 Mbytes
Possible DiskOnChip with unknown ChipID FF found at 0xda000 Possible DiskOnChip with unknown ChipID FF found at 0xdc000 Possible DiskOnChip with unknown ChipID FF found at 0xde000 Possible DiskOnChip with unknown ChipID FF found at 0xe0000 Possible DiskOnChip with unknown ChipID FF found at 0xe2000 Possible DiskOnChip with unknown ChipID FF found at 0xe4000 Possible DiskOnChip with unknown ChipID FF found at 0xe6000 Possible DiskOnChip with unknown ChipID FF found at 0xe8000 Possible DiskOnChip with unknown ChipID FF found at 0xea000 Possible DiskOnChip with unknown ChipID FF found at 0xec000 Possible DiskOnChip with unknown ChipID FF found at 0xee000 M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI $Id: nftl.c,v 1.57 2000/12/01 17:51:54 dwmw2 Exp $
Block 1016: free but referenced in chain 17
Formatting chain at block 17
Formatting block 17
Formatting block 1016
Block 1021: free but referenced in chain 22
Formatting chain at block 22
Formatting block 22
Formatting block 1021
Block 36: referencing block 25 already in another chain Formatting chain at block 36
Formatting block 36
nftla: nftla1

===============================================

As an example, here is an output based on the old board:

======== Auto Probe for DOC Address D0000 (Old board) ============== M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc. Possible DiskOnChip with unknown ChipID EA found at 0xc8000 Possible DiskOnChip with unknown ChipID 00 found at 0xca000 Possible DiskOnChip with unknown ChipID FF found at 0xcc000 Possible DiskOnChip with unknown ChipID FF found at 0xce000 DiskOnChip Millennium found at address 0xD0000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) 1 flash chips found. Total DiskOnChip size: 8 Mbytes
Possible DiskOnChip with unknown ChipID FF found at 0xd2000 Possible DiskOnChip with unknown ChipID FF found at 0xd4000 Possible DiskOnChip with unknown ChipID FF found at 0xd6000 Possible DiskOnChip with unknown ChipID FF found at 0xd8000 Possible DiskOnChip with unknown ChipID FF found at 0xda000 Possible DiskOnChip with unknown ChipID FF found at 0xdc000 Possible DiskOnChip with unknown ChipID FF found at 0xde000 Possible DiskOnChip with unknown ChipID FF found at 0xe0000 Possible DiskOnChip with unknown ChipID FF found at 0xe2000 Possible DiskOnChip with unknown ChipID FF found at 0xe4000 Possible DiskOnChip with unknown ChipID FF found at 0xe6000 Possible DiskOnChip with unknown ChipID FF found at 0xe8000 Possible DiskOnChip with unknown ChipID FF found at 0xea000 Possible DiskOnChip with unknown ChipID FF found at 0xec000 Possible DiskOnChip with unknown ChipID FF found at 0xee000 M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI $Id: nftl.c,v 1.57 2000/12/01 17:51:54 dwmw2 Exp $
Could not find valid boot record
Could not mount NFTL device

===============================================

As you can see, the old board requires a manual nftl format, but not the new board.

Any clues?

Shuh Chang
[email protected]

To unsubscribe, send "unsubscribe mtd" to [email protected]

#2 lore raw

Re: Is DOC Address 0xC8000 Something Special?

Quoted 3 lines · [email protected] said:

I would like to ask the developers in this list if any of you have
ever experienced a DiskOnChip (DOC) problem not being recognized at address 0xC8000 ONLY by docprobe.

There's probably something on your system board mapped at 0xC8000 which conflicts with the DiskOnChip at that address.

I'm confused by the observed difference between the behaviour of the two eval boards, though. Can you try the timing changes suggested by David Griffith a few days ago?

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

#3 lore raw

Re: Is DOC Address 0xC8000 Something Special?

Quoted 6 lines · David Woodhouse

I'm confused by the observed difference between the behaviour of the two eval boards, though. Can you try the timing changes suggested by David Griffith a few days ago?

What was it ??

Ollie

#5 lore raw

Re: Is DOC Address 0xC8000 Something Special?

In reply to Shuh C Chang
Quoted 7 lines · Shuh C Chang

Dear MTD fans:

I would like to ask the developers in this list if any of you have ever experienced a DiskOnChip (DOC) problem not being recognized at address 0xC8000 ONLY by docprobe.

The C segment is usually used by VGA BIOS and is mapped (shadow) to your DRAM, not on any ISA device.

Ollie

#6 lore raw

Re: Is DOC Address 0xC8000 Something Special?

Hey, Ollie:

I knew that there got to be some genius out there who can give this 0xC8000 address some special meaning. Now you mention it, it just brings back the good old memory when the first CGA color monitor came out in the early 80s. That's where the video RAM starts for the color video adaptor. No wonder it looks so awefully familiar to me, but I just never bother to look back. Just like the old Chinese saying, "You can no longer smell the fragrance once you are in a room full of orchid long enough."

Nonetheless, I thought this was an ancient problem of a dinosaur in the old DOS dynasty. Is this still a problem as real as in the old days?

So far, I have tried with Griffith/Woodhouse's suggestions such as:
- cycles*4 in doc2001.c & doc2000.c
- fixed probe & auto probe
- Commenting out DOC_SINGLE_DRIVER in docprobe.c
- Changing MTD_READECC to MTD_READ in nftlmount.c
- etc.

but to no avail.

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.

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 DOC chip was so corrupted that even the dformat wouldn't work and dinfo wouldn't recognized the DOC. Only forcing a "reburning" of an image with docpmap would restore the DOC to its working condition.

It's a pity. I would love to use the dd command in the Linux world for "burning" the image. However, before you *fix* the format on DOC, you cannot access to it from Linux, let along using the dd command. Having to use the DOS docpmap utility for a rescue makes me feel a little bit uneasy and nauseous...

I guess once I sorted out all the problems that I have at hand, maybe I can prepare that part of the document if anyone is interested.

Shuh

----- Original Message -----
From: "Ollie Lho" <[email protected]>
To: "Shuh C. Chang" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, May 01, 2001 7:54 PM
Subject: Re: Is DOC Address 0xC8000 Something Special?

Quoted 14 lines
Quoted 7 lines · Shuh C Chang

Dear MTD fans:

I would like to ask the developers in this list if any of you have ever experienced a DiskOnChip (DOC) problem not being recognized at address 0xC8000 ONLY by docprobe.

The C segment is usually used by VGA BIOS and is mapped (shadow) to your DRAM, not on any ISA device.

Ollie

#7 lore raw

Re: Is DOC Address 0xC8000 Something Special?

Quoted 6 lines · Shuh C Chang

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 PC.

Quoted 11 lines

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.

Ollie

#8 lore raw

RE: Is DOC Address 0xC8000 Something Special?

In reply to Shuh C Chang
Quoted 4 lines

The same problem (not recognizing DOC) occurs for both fixed address probe (C8000 in config) as well as autoprobe (0000 in config). Strangely, docprobe works well (again, both fixed and auto probe) at two other DOC
addresses: 0xD0000 and 0xD8000.

Just as a sanity check, make sure you don't have your video BIOS shadowed at this address in you BIOS setup.

--
Michel Stempin
MIS
COM One SA, 11 parc de Marticot, 33610 CESTAS, FRANCE
Tel: +33(0)5 57 97 72 72
Fax: +33(0)5 56 78 84 78
Email: [email protected]