DOC 2000 driver (NFTL) in kernel 2.4.7

DOC 2000 driver (NFTL) in kernel 2.4.7

[Alexandru Harsanyi]

Hi,

I'm trying to configure the 2.4.7 kernel to access a DOC, and I have the
following problems:

1) Although I have only one DOC 2000, the DOC driver detects many more
(see dmesg below)

2) The DOC driver detects 3 flash chips, I only have one

3) (and this is the show stopper) The NFTL driver is not able to find a
boot record on the DOC. This is strange because I'm actually booting
from the DOC.

The previous configuration used a 2.0.36 kernel with M-System provided
drivers and it worked fine.

Here is the relevant dmesg part from the system:

----- dmesg -----
DiskOnChip 2000 found at address 0xC8000
Flash chip found: Manufacturer ID: 98, Chip ID: 6B (Toshiba TC5832DC)
3 flash chips found. Total DiskOnChip size: 12 MiB
Possible DiskOnChip with unknown ChipID FF found at 0xca000
Possible DiskOnChip with unknown ChipID 00 found at 0xcc000
Possible DiskOnChip with unknown ChipID 00 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
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 0B found at 0xe0000
Possible DiskOnChip with unknown ChipID 00 found at 0xe2000
Possible DiskOnChip with unknown ChipID 28 found at 0xe4000
Possible DiskOnChip with unknown ChipID 00 found at 0xe6000
Possible DiskOnChip with unknown ChipID 6D found at 0xe8000
Possible DiskOnChip with unknown ChipID 07 found at 0xea000
Possible DiskOnChip with unknown ChipID 00 found at 0xec000
Possible DiskOnChip with unknown ChipID FE found at 0xee000
M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI
$Id: nftlcore.c,v 1.73 2001/06/09 01:09:43 dwmw2 Exp $
Could not find valid boot record
Could not mount NFTL device
---- end dmesg ----

Does anyone know what's the problem? 

Thanx,
Alex.

Re: DOC 2000 driver (NFTL) in kernel 2.4.7

[David Woodhouse]

On Tue, 31 Jul 2001, Alexandru Harsanyi wrote:

> 1) Although I have only one DOC 2000, the DOC driver detects many more
> (see dmesg below)

Note the word 'possible'. Turn on CONFIG_MTD_DOCPROBE_55AA

> 2) The DOC driver detects 3 flash chips, I only have one

One DiskOnChip. Three flash chips in it.

> 3) (and this is the show stopper) The NFTL driver is not able to find a
> boot record on the DOC. This is strange because I'm actually booting
> from the DOC.

That's odd. Update to the latest code from CVS, although I'm not sure it 
should make a difference, and put lots of debugging printks in 
find_boot_record() in nftlmount.c so it tells you why it rejects the 
header blocks it finds.

-- 
dwmw2

DOC 2000 driver (NFTL) in kernel 2.4.7

[Saul Thurrowgood]

> 3) (and this is the show stopper) The NFTL driver is not able to find a
> boot record on the DOC. This is strange because I'm actually booting
> from the DOC.
>
> The previous configuration used a 2.0.36 kernel with M-System provided
> drivers and it worked fine.


I had the exact same problem but I am running an Ampro P5e with DOC 2000
(2.4.1 kernel).

I knew it had a valid NFTL boot record, because it would boot to DOS,
and running the nftldump util under linux would find it. It had been
NFTL formatted with M-Systems utils.

I fixed it by formatting with nftl_format (also comes with MTD source),
providing it a 240k offset so it would not trash the BIOS at the
beginning of the chip (Ampro specific).

Works fine! So, what's the difference between the two formats?!?
Both start at the exact same place on the DOC, as seen by running
nftldump before and after.

Saul.

Re: DOC 2000 driver (NFTL) in kernel 2.4.7

[David Woodhouse]

saul@cvs.anu.edu.au said:
>  I fixed it by formatting with nftl_format (also comes with MTD
> source), providing it a 240k offset so it would not trash the BIOS at
> the beginning of the chip (Ampro specific).

That's normally 48KiB for the standard on-device firmware, I think.

> Works fine! So, what's the difference between the two formats?!? Both
> start at the exact same place on the DOC, as seen by running nftldump
> before and after. 

Please upgrade to the latest version from CVS (nftlmount.c v1.20). It'll be 
a lot more explicit about its reasons for rejecting any media headers which 
it finds.

--
dwmw2

Re: DOC 2000 driver (NFTL) in kernel 2.4.7

[Alexandru Harsanyi]

Hi, 

I updated to the lastest CVS, and moved the driver code into the 2.4.7
kernel source.

At boot I get the following messages (debug verbosity was set to 3):

M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
DiskOnChip 2000 found at address 0xC8000
Flash chip found: Manufacturer ID: 98, Chip ID: 6B (Toshiba TC5832DC)
3 flash chips found. Total DiskOnChip size: 12 MiB
mtd: Giving out device 0 to DiskOnChip 2000
NFTL driver: nftlcore.c $Revision: 1.77 $, nftlmount.c $Revision: 1.20 $
NFTL_notify_add for DiskOnChip 2000
mtd->read = c0181a20, size = 12582912, erasesize = 8192
NFTL_setup
_DoC_WaitReady called for out-of-line wait
ANAND header found at 0xc000 in mtd0, but ECC read failed (err 1)
_DoC_WaitReady called for out-of-line wait
ANAND header found at 0xe000 in mtd0, but ECC read failed (err 1)
Could not find valid boot record
Could not mount NFTL device

----------

It seems to me that there's an ECC error when reading the DOC. With the
M-Systems provided driver, the chip works fine, so I suspect there's a
problem at the ECC computation. That would explain why, when formating
the chip with the linux-mtd tools it works (as Saul Thurrowgood
<saul@cvs.anu.edu.au> reported)

It would be interesting to test whether a chip formated with linux-mtd
tools works with the M-System provided driver. 

My DOC was formated using M-Systems tools and the partitions on it are
MS-DOS. For non-technical reasons I cannot reformat the chip.

Best Regards,
Alex.


David Woodhouse wrote:
> 
> saul@cvs.anu.edu.au said:
> >  I fixed it by formatting with nftl_format (also comes with MTD
> > source), providing it a 240k offset so it would not trash the BIOS at
> > the beginning of the chip (Ampro specific).
> 
> That's normally 48KiB for the standard on-device firmware, I think.
> 
> > Works fine! So, what's the difference between the two formats?!? Both
> > start at the exact same place on the DOC, as seen by running nftldump
> > before and after.
> 
> Please upgrade to the latest version from CVS (nftlmount.c v1.20). It'll be
> a lot more explicit about its reasons for rejecting any media headers which
> it finds.
> 
> --
> dwmw2

Re: DOC 2000 driver (NFTL) in kernel 2.4.7

[David Woodhouse]

a.harsanyi@willhart-tech.com said:
> ANAND header found at 0xc000 in mtd0, but ECC read failed (err 1)
> ANAND header found at 0xe000 in mtd0, but ECC read failed (err 1)
> Could not find valid boot record 

And with this applied...?

Index: nftlmount.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/nftlmount.c,v
retrieving revision 1.20
diff -u -r1.20 nftlmount.c
--- nftlmount.c	2001/08/07 09:22:07	1.20
+++ nftlmount.c	2001/08/08 06:41:48
@@ -103,6 +103,7 @@
 			continue;
 		}
 
+#if 0
 		/* Finally reread to check ECC */
 		if ((ret = MTD_READECC(nftl->mtd, block * nftl->EraseSize, SECTORSIZE,
 				&retlen, buf, (char *)&oob) < 0)) {
@@ -119,6 +120,7 @@
 			       buf[0], buf[1], buf[2], buf[3], buf[4], buf[5]);
 			continue;
 		}
+#endif
 			       
 		/* OK, we like it. */
 


--
dwmw2

Re: DOC 2000 driver (NFTL) in kernel 2.4.7

[Alexandru Harsanyi]

Hi,

I commented out the ECC checking part, and nftlmount.c now detects my
partition. I mounted it read-only and made some tests with copying some
files of it. It seems to be working.

However, when I mount it read-write and I write some files to the
partition, the NFTL driver hangs my system...

The messages are:
------------
_Doc_WaitReady called for out-of-line wait
Setting inplace to 0. VUC 194, block 2 was 0 lastEUN, and is in EUN 333
(!=) 673
Cannot fold Virtual Unit Chain 194 in place. Trying out-of-place
-------------

The DOC data doesn't seem to be corrupted (as I can boot from it again)
but nothing gets written to it.

Best Regards,
Alex.

David Woodhouse wrote:
> 
> a.harsanyi@willhart-tech.com said:
> > ANAND header found at 0xc000 in mtd0, but ECC read failed (err 1)
> > ANAND header found at 0xe000 in mtd0, but ECC read failed (err 1)
> > Could not find valid boot record
> 
> And with this applied...?
> 
> Index: nftlmount.c
> ===================================================================
> RCS file: /home/cvs/mtd/drivers/mtd/nftlmount.c,v
> retrieving revision 1.20
> diff -u -r1.20 nftlmount.c
> --- nftlmount.c 2001/08/07 09:22:07     1.20
> +++ nftlmount.c 2001/08/08 06:41:48
> @@ -103,6 +103,7 @@
>                         continue;
>                 }
> 
> +#if 0
>                 /* Finally reread to check ECC */
>                 if ((ret = MTD_READECC(nftl->mtd, block * nftl->EraseSize, SECTORSIZE,
>                                 &retlen, buf, (char *)&oob) < 0)) {
> @@ -119,6 +120,7 @@
>                                buf[0], buf[1], buf[2], buf[3], buf[4], buf[5]);
>                         continue;
>                 }
> +#endif
> 
>                 /* OK, we like it. */
> 
> 
> --
> dwmw2
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: DOC 2000 driver (NFTL) in kernel 2.4.7

[David Woodhouse]

a.harsanyi@willhart-tech.com said:
>  However, when I mount it read-write and I write some files to the
> partition, the NFTL driver hangs my system...

> The messages are:
> ------------
> _Doc_WaitReady called for out-of-line wait
> Setting inplace to 0. VUC 194, block 2 was 0 lastEUN, and is in EUN 333 (!=) 673


/me dusts off the NFTL spec and tries to interpret that...

One of the blocks is marked BLOCK_DELETED in the Erase Unit which it's 
trying to fold the chain into. That ought to be fine - it can just leave it 
marked as deleted. I think that sanity check can be changed as follows:

Index: nftlcore.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/nftlcore.c,v
retrieving revision 1.77
diff -u -r1.77 nftlcore.c
--- nftlcore.c	2001/08/07 09:47:41	1.77
+++ nftlcore.c	2001/08/08 08:46:17
@@ -330,8 +330,17 @@
 					       "in Virtual Unit Chain %d for block %d\n",
 					       thisVUC, block);
 				break;
-			case SECTOR_IGNORE:
 			case SECTOR_DELETED:
+				if (!BlockFreeFound[block])
+					BlockMap[block] = BLOCK_NIL;
+				else
+					printk(KERN_WARNING 
+					       "SECTOR_DELETED found after SECTOR_FREE "
+					       "in Virtual Unit Chain %d for block %d\n",
+					       thisVUC, block);
+				break;
+
+			case SECTOR_IGNORE:
 				break;
 			default:
 				printk("Unknown status for block %d in EUN %d: %x\n",
@@ -350,12 +359,15 @@
 
 	if (inplace) {
 		/* We're being asked to be a fold-in-place. Check
-		   that all blocks are either present or SECTOR_FREE
-		   in the target block. If not, we're going to have
-		   to fold out-of-place anyway.
+		   that all blocks which actually have data associated
+		   with them (i.e. BlockMap[block] != BLOCK_NIL) are 
+		   either already present or SECTOR_FREE in the target
+		   block. If not, we're going to have to fold out-of-place
+		   anyway.
 		*/
 		for (block = 0; block < nftl->EraseSize / 512 ; block++) {
 			if (BlockLastState[block] != SECTOR_FREE &&
+			    BlockMap[block] != BLOCK_NIL &&
 			    BlockMap[block] != targetEUN) {
 				DEBUG(MTD_DEBUG_LEVEL1, "Setting inplace to 0. VUC %d, "
 				      "block %d was %x lastEUN, "


> Cannot fold Virtual Unit Chain 194 in place. Trying out-of-place

Regardless of the above bug, dying here is not acceptable though. 
Change the 'int silly = -1;' in NFTL_findfreeblock() to
	int silly = nftl->nb_blocks;

Dunno why it wasn't like that before.


--
dwmw2