Absent Configure.help

Absent Configure.help

[David Woodhouse]

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 majordomo@infradead.org

Is DOC Address 0xC8000 Something Special?

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

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
schang@3inet.com







To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Is DOC Address 0xC8000 Something Special?

[David Woodhouse]

schang@3inet.com 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 majordomo@infradead.org

Re: Is DOC Address 0xC8000 Something Special?

[Ollie Lho]

David Woodhouse wrote:
> 
> 
> 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

Re: Is DOC Address 0xC8000 Something Special?

[Ollie Lho]

Shuh C Chang wrote:
> 
> 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

Re: Is DOC Address 0xC8000 Something Special?

[Shuh C Chang]

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" <ollie@sis.com.tw>
To: "Shuh C. Chang" <schang@3inet.com>
Cc: <mtd@infradead.org>
Sent: Tuesday, May 01, 2001 7:54 PM
Subject: Re: Is DOC Address 0xC8000 Something Special?


> Shuh C Chang wrote:
> >
> > 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
>

Re: Is DOC Address 0xC8000 Something Special?

[Ollie Lho]

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

> 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

Re: Is DOC Address 0xC8000 Something Special?

[David Woodhouse]

ollie@sis.com.tw said:
>  What was it ?? 

Quadrupling the number of delay cycles in DoC_Delay().

http://lists.infradead.org/pipermail/linux-mtd/2001-April/000488.html

--
dwmw2

RE: Is DOC Address 0xC8000 Something Special?

[Michel STEMPIN]

> 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: mstempin@com1.fr