* Absent Configure.help @ 2001-04-27 14:23 David Woodhouse 2001-04-30 15:14 ` Is DOC Address 0xC8000 Something Special? Shuh C Chang 0 siblings, 1 reply; 9+ messages in thread From: David Woodhouse @ 2001-04-27 14:23 UTC (permalink / raw) To: mtd 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Is DOC Address 0xC8000 Something Special? 2001-04-27 14:23 Absent Configure.help David Woodhouse @ 2001-04-30 15:14 ` Shuh C Chang 2001-04-30 16:00 ` David Woodhouse ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Shuh C Chang @ 2001-04-30 15:14 UTC (permalink / raw) To: mtd 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is DOC Address 0xC8000 Something Special? 2001-04-30 15:14 ` Is DOC Address 0xC8000 Something Special? Shuh C Chang @ 2001-04-30 16:00 ` David Woodhouse 2001-05-02 0:52 ` Ollie Lho 2001-05-02 0:54 ` Ollie Lho 2001-05-02 7:52 ` Michel STEMPIN 2 siblings, 1 reply; 9+ messages in thread From: David Woodhouse @ 2001-04-30 16:00 UTC (permalink / raw) To: Shuh C. Chang; +Cc: mtd 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is DOC Address 0xC8000 Something Special? 2001-04-30 16:00 ` David Woodhouse @ 2001-05-02 0:52 ` Ollie Lho 2001-05-02 6:34 ` David Woodhouse 0 siblings, 1 reply; 9+ messages in thread From: Ollie Lho @ 2001-05-02 0:52 UTC (permalink / raw) To: David Woodhouse; +Cc: Shuh C. Chang, linux-mtd 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is DOC Address 0xC8000 Something Special? 2001-05-02 0:52 ` Ollie Lho @ 2001-05-02 6:34 ` David Woodhouse 0 siblings, 0 replies; 9+ messages in thread From: David Woodhouse @ 2001-05-02 6:34 UTC (permalink / raw) To: Ollie Lho; +Cc: Shuh C. Chang, linux-mtd 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is DOC Address 0xC8000 Something Special? 2001-04-30 15:14 ` Is DOC Address 0xC8000 Something Special? Shuh C Chang 2001-04-30 16:00 ` David Woodhouse @ 2001-05-02 0:54 ` Ollie Lho 2001-05-02 3:05 ` Shuh C Chang 2001-05-02 7:52 ` Michel STEMPIN 2 siblings, 1 reply; 9+ messages in thread From: Ollie Lho @ 2001-05-02 0:54 UTC (permalink / raw) To: Shuh C. Chang; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is DOC Address 0xC8000 Something Special? 2001-05-02 0:54 ` Ollie Lho @ 2001-05-02 3:05 ` Shuh C Chang 2001-05-02 3:20 ` Ollie Lho 0 siblings, 1 reply; 9+ messages in thread From: Shuh C Chang @ 2001-05-02 3:05 UTC (permalink / raw) To: Ollie Lho; +Cc: linux-mtd 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is DOC Address 0xC8000 Something Special? 2001-05-02 3:05 ` Shuh C Chang @ 2001-05-02 3:20 ` Ollie Lho 0 siblings, 0 replies; 9+ messages in thread From: Ollie Lho @ 2001-05-02 3:20 UTC (permalink / raw) To: schang; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Is DOC Address 0xC8000 Something Special? 2001-04-30 15:14 ` Is DOC Address 0xC8000 Something Special? Shuh C Chang 2001-04-30 16:00 ` David Woodhouse 2001-05-02 0:54 ` Ollie Lho @ 2001-05-02 7:52 ` Michel STEMPIN 2 siblings, 0 replies; 9+ messages in thread From: Michel STEMPIN @ 2001-05-02 7:52 UTC (permalink / raw) To: mtd > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2001-05-02 7:51 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2001-04-27 14:23 Absent Configure.help David Woodhouse 2001-04-30 15:14 ` Is DOC Address 0xC8000 Something Special? Shuh C Chang 2001-04-30 16:00 ` David Woodhouse 2001-05-02 0:52 ` Ollie Lho 2001-05-02 6:34 ` David Woodhouse 2001-05-02 0:54 ` Ollie Lho 2001-05-02 3:05 ` Shuh C Chang 2001-05-02 3:20 ` Ollie Lho 2001-05-02 7:52 ` Michel STEMPIN
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox