From eaydjay at hotmail.com  Thu Oct  2 02:54:49 2003
From: eaydjay at hotmail.com (edward jose)
Date: Thu, 02 Oct 2003 06:54:49 +0000
Subject: high cpu usage using nftl for DOC2000
Message-ID: <Law15-F74mSknvh7wFI000062b3@hotmail.com>

hello,

i don't know if any one else experience this, i have a doc2000 with linux 
2.4.17 kernel compiled with mtd and doc modules. i use the kernel to boot 
the doc2000 everything is ok, but when i check the cpu load, it uses all the 
cpu.  this is the same when i use m-system's kernel module.

can someone explain to me why this happen?

thanks

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus



From timg at tpi.com  Thu Oct  2 15:44:14 2003
From: timg at tpi.com (Tim Gardner)
Date: Thu, 2 Oct 2003 13:44:14 -0600
Subject: Patches to nanddump.c
Message-ID: <200310021344.14931.timg@tpi.com>

I've added a couple of options to nanddump.c:

-no-oob allowa you to retrieve the contents of a NAND character partiion 
without the OOB info. 

-no-print satisfies the interactive pretty-print request. 

See attached patch file.
-- 
Tim Gardner - timg at tpi.com 406-443-5357
TriplePoint, Inc. - http://www.tpi.com
PGP: http://www.tpi.com/PGP/Tim.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd.diff.IceCube
Type: text/x-diff
Size: 2858 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031002/ba8992bb/attachment.bin 

From selwyn at hectrix.com  Thu Oct  2 22:07:06 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Fri, 03 Oct 2003 10:07:06 +0800
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
Message-ID: <3F7CD9CA.5090805@hectrix.com>

Hi Edward,

On 10/02/2003 02:54 PM, edward jose wrote:
> i don't know if any one else experience this, i have a doc2000 with linux 
> 2.4.17 kernel compiled with mtd and doc modules. i use the kernel to boot 
> the doc2000 everything is ok, but when i check the cpu load, it uses all the 

I experienced the same problem recently. I notice that whenever I try to
access the DOC, the process [nftla] starts to use up all the cpu time.
Right now I am suspecting that it is the problem with the filesystem on
the DOC. Sometimes, after running e2fsck on my ext2 partition on the
DOC, the problem just goes away. I have this problem both in 2.4.22 and
2.4.17, both patched with mtd snapshots of different dates. Therefore, I
 think it is a problem with the mtd driver.

Any ideas are appreciated.

Selwyn



From dwmw2 at infradead.org  Fri Oct  3 01:54:41 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 03 Oct 2003 06:54:41 +0100
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <3F7CD9CA.5090805@hectrix.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	 <3F7CD9CA.5090805@hectrix.com>
Message-ID: <1065160480.16088.0.camel@imladris.demon.co.uk>

On Fri, 2003-10-03 at 10:07 +0800, Selwyn Tang wrote:
> Hi Edward,
> 
> On 10/02/2003 02:54 PM, edward jose wrote:
> > i don't know if any one else experience this, i have a doc2000 with linux 
> > 2.4.17 kernel compiled with mtd and doc modules. i use the kernel to boot 
> > the doc2000 everything is ok, but when i check the cpu load, it uses all the 
> 
> I experienced the same problem recently. I notice that whenever I try to
> access the DOC, the process [nftla] starts to use up all the cpu time.
> Right now I am suspecting that it is the problem with the filesystem on
> the DOC. Sometimes, after running e2fsck on my ext2 partition on the
> DOC, the problem just goes away. I have this problem both in 2.4.22 and
> 2.4.17, both patched with mtd snapshots of different dates. Therefore, I
>  think it is a problem with the mtd driver.

Boot with 'profile=1' and use readprofile to see where it's spending all
the CPU time. Note your driver must be built-in to the kernel for this.

-- 
dwmw2




From oyvind.harboe at zylin.com  Fri Oct  3 03:48:06 2003
From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe)
Date: Fri, 03 Oct 2003 09:48:06 +0200
Subject: Can I set JFFS2_RESERVED_BLOCKS_WRITE=0?
Message-ID: <1065167286.24334.12.camel@famine>

I've got a JFFS2 fs mounted with only a single sector.

In this application, there is a phase where JFFS2 is written to,
and afterwards it is protected in hardware and never changed again.

JFFS2 scores over a ROM fs, because a ROM fs is normally created
on the developer machine during compile time, whereas the JFFS2
fs can be laid out by the application in the field.

To my surprise, JFFS2 will refuse to write more files if there
are less than 5 secotors free.

Having no fear, I set JFFS2_RESERVED_BLOCKS_WRITE = 0.

Apparently this is to avoid "endless gc looping".

http://lists.infradead.org/pipermail/linux-mtd/2003-April/007437.html

If someone could shed some light on this, I would be much obliged.


?yvind




From selwyn at hectrix.com  Fri Oct  3 04:22:15 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Fri, 03 Oct 2003 16:22:15 +0800
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <1065160480.16088.0.camel@imladris.demon.co.uk>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	<3F7CD9CA.5090805@hectrix.com> <1065160480.16088.0.camel@imladris.demon.co.uk>
Message-ID: <3F7D31B7.7020400@hectrix.com>

Hi Dave,

On 10/03/2003 01:54 PM, David Woodhouse wrote:
> Boot with 'profile=1' and use readprofile to see where it's spending all
> the CPU time. Note your driver must be built-in to the kernel for this.

The followings, among others, are reported by readprofile:

  147 handle_IRQ_event			1.5978
   17 ide_outb				1.4167
 3288 _DoC_Delay			32.8800
 6634 __rdtsc_delay			236.9286

I don't know how to interpret them :-)

Selwyn



From dwmw2 at infradead.org  Fri Oct  3 04:52:47 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 03 Oct 2003 09:52:47 +0100
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <3F7D31B7.7020400@hectrix.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	 <3F7CD9CA.5090805@hectrix.com>
	 <1065160480.16088.0.camel@imladris.demon.co.uk>
	 <3F7D31B7.7020400@hectrix.com>
Message-ID: <1065171167.22491.53.camel@hades.cambridge.redhat.com>

On Fri, 2003-10-03 at 16:22 +0800, Selwyn Tang wrote:
> The followings, among others, are reported by readprofile:
> 
>   147 handle_IRQ_event			1.5978
>    17 ide_outb				1.4167
>  3288 _DoC_Delay			32.8800
>  6634 __rdtsc_delay			236.9286
> 
> I don't know how to interpret them :-)

Run it through 'sort -n'. Ignore the third column; the first tells you
how many times, when a timer tick happened, we interrupted the function
named in the second column.

So on 147 occasions when the timer tick happened, the CPU was in
handle_IRQ_event(). During the period of this profiling run, we
(statistically speaking) spent about 1.47 seconds in that function.

We also spend 33 seconds in _DoC_Delay() and 66 seconds in
__rdtsc_delay(). It looks like the flash is very busy. Can you show me
the rest of the profile too?

Also, can you reset the profile counts (readprofile -r) and get a
reading from the time when it's doing this alone, rather than including
everything from boot onwards.

If it does it only sometimes, is there any pattern to when it starts or
stops?

-- 
dwmw2



From dsaxena at plexity.net  Fri Oct  3 13:27:43 2003
From: dsaxena at plexity.net (Deepak Saxena)
Date: Fri, 3 Oct 2003 10:27:43 -0700
Subject: [PATCH] Remove hardcoded number of CFI chips
Message-ID: <20031003172742.GA22844@plexity.net>


This is a resend of a patch originally posted by  Andrzej Mialkowski
from Intel a few months ago that removes the hardcoded MAX_CFI_CHIPS
and replaces it with a dynamic bitmap. I believe it got approved but never
checked in, but not 100% sure so I'm reposting it to see if it should
be pushed into CVS, cleaned up, or dropped.  I need this for several 
platforms with large numbers of chips, so I'd rather not see it just die.

Tnx,
~Deepak


Index: drivers/mtd/chips/cfi_probe.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/chips/cfi_probe.c,v
retrieving revision 1.72
diff -u -r1.72 cfi_probe.c
--- drivers/mtd/chips/cfi_probe.c	22 Jul 2003 13:23:38 -0000	1.72
+++ drivers/mtd/chips/cfi_probe.c	3 Oct 2003 17:13:00 -0000
@@ -26,7 +26,7 @@
 #endif
 
 static int cfi_probe_chip(struct map_info *map, __u32 base,
-			  struct flchip *chips, struct cfi_private *cfi);
+			  struct probe_info *probe, struct cfi_private *cfi);
 static int cfi_chip_setup(struct map_info *map, struct cfi_private *cfi);
 
 struct mtd_info *cfi_probe(struct map_info *map);
@@ -49,7 +49,7 @@
 }
 
 static int cfi_probe_chip(struct map_info *map, __u32 base,
-			  struct flchip *chips, struct cfi_private *cfi)
+			  struct probe_info *probe, struct cfi_private *cfi)
 {
 	int i;
 	
@@ -78,18 +78,24 @@
 	}
 
 	/* Check each previous chip to see if it's an alias */
-	for (i=0; i<cfi->numchips; i++) {
+ 	for (i=0; i < (base >> cfi->chipshift); i++) {
+ 		unsigned long start;
+ 		if(!test_bit(i, probe->chip_map)) {
+			/* Skip location; no valid chip at this address */
+ 			continue; 
+ 		}
+ 		start = i << cfi->chipshift;
 		/* This chip should be in read mode if it's one
 		   we've already touched. */
-		if (qry_present(map,chips[i].start,cfi)) {
+		if (qry_present(map, start, cfi)) {
 			/* Eep. This chip also had the QRY marker. 
 			 * Is it an alias for the new one? */
-			cfi_send_gen_cmd(0xF0, 0, chips[i].start, map, cfi, cfi->device_type, NULL);
+			cfi_send_gen_cmd(0xF0, 0, start, map, cfi, cfi->device_type, NULL);
 
 			/* If the QRY marker goes away, it's an alias */
-			if (!qry_present(map, chips[i].start, cfi)) {
+			if (!qry_present(map, start, cfi)) {
 				printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",
-				       map->name, base, chips[i].start);
+				       map->name, base, start);
 				return 0;
 			}
 			/* Yes, it's actually got QRY for data. Most 
@@ -100,7 +106,7 @@
 			
 			if (qry_present(map, base, cfi)) {
 				printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",
-				       map->name, base, chips[i].start);
+				       map->name, base, start);
 				return 0;
 			}
 		}
@@ -108,13 +114,7 @@
 	
 	/* OK, if we got to here, then none of the previous chips appear to
 	   be aliases for the current one. */
-	if (cfi->numchips == MAX_CFI_CHIPS) {
-		printk(KERN_WARNING"%s: Too many flash chips detected. Increase MAX_CFI_CHIPS from %d.\n", map->name, MAX_CFI_CHIPS);
-		/* Doesn't matter about resetting it to Read Mode - we're not going to talk to it anyway */
-		return -1;
-	}
-	chips[cfi->numchips].start = base;
-	chips[cfi->numchips].state = FL_READY;
+	set_bit((base >> cfi->chipshift), probe->chip_map); /* Update chip map */
 	cfi->numchips++;
 	
 	/* Put it back into Read Mode */
Index: drivers/mtd/chips/gen_probe.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/chips/gen_probe.c,v
retrieving revision 1.13
diff -u -r1.13 gen_probe.c
--- drivers/mtd/chips/gen_probe.c	25 Jun 2003 11:50:37 -0000	1.13
+++ drivers/mtd/chips/gen_probe.c	3 Oct 2003 17:13:01 -0000
@@ -53,14 +53,13 @@
 
 struct cfi_private *genprobe_ident_chips(struct map_info *map, struct chip_probe *cp)
 {
-	unsigned long base=0;
 	struct cfi_private cfi;
 	struct cfi_private *retcfi;
-	struct flchip chip[MAX_CFI_CHIPS];
-	int i;
+	struct probe_info probe;
+	int i, j;
+	int max_chips;
 
 	memset(&cfi, 0, sizeof(cfi));
-	memset(&chip[0], 0, sizeof(chip));
 
 	/* Call the probetype-specific code with all permutations of 
 	   interleave and device type, etc. */
@@ -81,8 +80,6 @@
 		return NULL;
 	}
 #endif
-	chip[0].start = 0;
-	chip[0].state = FL_READY;
 	cfi.chipshift = cfi.cfiq->DevSize;
 
 	switch(cfi.interleave) {
@@ -106,21 +103,26 @@
 		
 	cfi.numchips = 1;
 
+	/* Allocate memory for bitmap of valid chips. Align bitmap storage size to full byte. */
+	max_chips = map->size >> cfi.chipshift;
+	probe.chip_map = kmalloc((max_chips + 7) / 8, GFP_KERNEL);
+	if (!probe.chip_map) {
+		printk(KERN_WARNING "%s: kmalloc failed for CFI chip map\n", map->name);
+		kfree(cfi.cfiq);
+		return NULL;
+	}
+
+	set_bit(0, probe.chip_map); /* Mark first chip valid */
+
 	/*
 	 * Now probe for other chips, checking sensibly for aliases while
 	 * we're at it. The new_chip probe above should have let the first
 	 * chip in read mode.
-	 *
-	 * NOTE: Here, we're checking if there is room for another chip
-	 *       the same size within the mapping. Therefore, 
-	 *       base + chipsize <= map->size is the correct thing to do, 
-	 *       because, base + chipsize would be the  _first_ byte of the
-	 *       next chip, not the one we're currently pondering.
 	 */
 
-	for (base = (1<<cfi.chipshift); base + (1<<cfi.chipshift) <= map->size;
-	     base += (1<<cfi.chipshift))
-		cp->probe_chip(map, base, &chip[0], &cfi);
+	for (i = 1; i < max_chips; i++) {
+		cp->probe_chip(map, i << cfi.chipshift, &probe, &cfi);
+	}
 
 	/*
 	 * Now allocate the space for the structures we need to return to 
@@ -132,19 +134,26 @@
 	if (!retcfi) {
 		printk(KERN_WARNING "%s: kmalloc failed for CFI private structure\n", map->name);
 		kfree(cfi.cfiq);
+		kfree(probe.chip_map);
 		return NULL;
 	}
 
 	memcpy(retcfi, &cfi, sizeof(cfi));
-	memcpy(&retcfi->chips[0], chip, sizeof(struct flchip) * cfi.numchips);
+	memset(&retcfi->chips[0], 0, sizeof(struct flchip) * cfi.numchips);
 
-	/* Fix up the stuff that breaks when you move it */
-	for (i=0; i< retcfi->numchips; i++) {
-		init_waitqueue_head(&retcfi->chips[i].wq);
-		spin_lock_init(&retcfi->chips[i]._spinlock);
-		retcfi->chips[i].mutex = &retcfi->chips[i]._spinlock;
+	for (i = 0, j = 0; (j < cfi.numchips) && (i < max_chips); i++) {
+		if(test_bit(i, probe.chip_map)) {
+			struct flchip *pchip = &retcfi->chips[j++];
+
+			pchip->start = (i << cfi.chipshift);
+			pchip->state = FL_READY;
+			init_waitqueue_head(&pchip->wq);
+			spin_lock_init(&pchip->_spinlock);
+			pchip->mutex = &pchip->_spinlock;
+		}
 	}
 
+	kfree(probe.chip_map);
 	return retcfi;
 }
 
Index: drivers/mtd/chips/jedec_probe.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/chips/jedec_probe.c,v
retrieving revision 1.32
diff -u -r1.32 jedec_probe.c
--- drivers/mtd/chips/jedec_probe.c	1 Oct 2003 17:40:05 -0000	1.32
+++ drivers/mtd/chips/jedec_probe.c	3 Oct 2003 17:13:01 -0000
@@ -1365,7 +1365,7 @@
 static int cfi_jedec_setup(struct cfi_private *p_cfi, int index);
 
 static int jedec_probe_chip(struct map_info *map, __u32 base,
-			    struct flchip *chips, struct cfi_private *cfi);
+			    struct probe_info *probe, struct cfi_private *cfi);
 
 struct mtd_info *jedec_probe(struct map_info *map);
 
@@ -1593,7 +1593,7 @@
 
 
 static int jedec_probe_chip(struct map_info *map, __u32 base,
-			      struct flchip *chips, struct cfi_private *cfi)
+			    struct probe_info *probe, struct cfi_private *cfi)
 {
 	int i;
 	enum uaddr uaddr_idx = MTD_UADDR_NOT_SUPPORTED;
@@ -1679,21 +1679,24 @@
 		}
 	}
 	
-	/* Check each previous chip to see if it's an alias */
-	for (i=0; i<cfi->numchips; i++) {
-		/* This chip should be in read mode if it's one
-		   we've already touched. */
-		if (jedec_read_mfr(map, chips[i].start, cfi) == cfi->mfr &&
-		    jedec_read_id(map, chips[i].start, cfi) == cfi->id) {
+	/* Check each previous chip locations to see if it's an alias */
+	for (i=0; i < (base >> cfi->chipshift); i++) {
+		unsigned long start;
+		if(!test_bit(i, probe->chip_map)) {
+			continue; /* Skip location; no valid chip at this address */
+		}
+		start = i << cfi->chipshift;
+		if (jedec_read_mfr(map, start, cfi) == cfi->mfr &&
+		    jedec_read_id(map, start, cfi) == cfi->id) {
 			/* Eep. This chip also looks like it's in autoselect mode.
 			   Is it an alias for the new one? */
-			jedec_reset(chips[i].start, map, cfi);
+			jedec_reset(start, map, cfi);
 
 			/* If the device IDs go away, it's an alias */
 			if (jedec_read_mfr(map, base, cfi) != cfi->mfr ||
 			    jedec_read_id(map, base, cfi) != cfi->id) {
 				printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",
-				       map->name, base, chips[i].start);
+				       map->name, base, start);
 				return 0;
 			}
 			
@@ -1705,7 +1708,7 @@
 			if (jedec_read_mfr(map, base, cfi) == cfi->mfr &&
 			    jedec_read_id(map, base, cfi) == cfi->id) {
 				printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",
-				       map->name, base, chips[i].start);
+				       map->name, base, start);
 				return 0;
 			}
 		}
@@ -1713,13 +1716,7 @@
 		
 	/* OK, if we got to here, then none of the previous chips appear to
 	   be aliases for the current one. */
-	if (cfi->numchips == MAX_CFI_CHIPS) {
-		printk(KERN_WARNING"%s: Too many flash chips detected. Increase MAX_CFI_CHIPS from %d.\n", map->name, MAX_CFI_CHIPS);
-		/* Doesn't matter about resetting it to Read Mode - we're not going to talk to it anyway */
-		return -1;
-	}
-	chips[cfi->numchips].start = base;
-	chips[cfi->numchips].state = FL_READY;
+	set_bit((base >> cfi->chipshift), probe->chip_map); /* Update chip map */
 	cfi->numchips++;
 		
 ok_out:
Index: include/linux/mtd/cfi.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/cfi.h,v
retrieving revision 1.36
diff -u -r1.36 cfi.h
--- include/linux/mtd/cfi.h	22 Jul 2003 13:23:39 -0000	1.36
+++ include/linux/mtd/cfi.h	3 Oct 2003 17:13:01 -0000
@@ -334,8 +334,6 @@
 	struct flchip chips[0];  /* per-chip data structure for each chip */
 };
 
-#define MAX_CFI_CHIPS 8 /* Entirely arbitrary to avoid realloc() */
-
 /*
  * Returns the command address according to the given geometry.
  */
Index: include/linux/mtd/gen_probe.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/gen_probe.h,v
retrieving revision 1.1
diff -u -r1.1 gen_probe.h
--- include/linux/mtd/gen_probe.h	2 Sep 2001 18:50:13 -0000	1.1
+++ include/linux/mtd/gen_probe.h	3 Oct 2003 17:13:01 -0000
@@ -10,12 +10,16 @@
 #include <linux/mtd/flashchip.h>
 #include <linux/mtd/map.h> 
 #include <linux/mtd/cfi.h>
+#include <asm/bitops.h>
+
+struct probe_info {
+	long *chip_map;	/* bitmap of valid chips in mtd map */
+};
 
 struct chip_probe {
 	char *name;
 	int (*probe_chip)(struct map_info *map, __u32 base,
-			  struct flchip *chips, struct cfi_private *cfi);
-
+			  struct probe_info *probe, struct cfi_private *cfi);
 };
 
 struct mtd_info *mtd_do_chip_probe(struct map_info *map, struct chip_probe *cp);

-- 
Deepak Saxena - dsaxena at plexity.net

"To eliminate the concept of waste means to design things - products,
 packaging, and systems - from the very beggining on the understanding 
 that waste does not exist" - William McDonough & Michael Braungart,
                 From Cradle to Cradle: Remaking the Way We Make Things



From hking at qualcomm.com  Fri Oct  3 16:02:22 2003
From: hking at qualcomm.com (Howard King)
Date: Fri, 03 Oct 2003 13:02:22 -0700
Subject: mtd support for 64-bit bus
Message-ID: <6.0.0.22.2.20031003125817.03ae9010@e2k.qualcomm.com>

We have a customized board with 4 AMD 29L641V flash chips (4 * 8Mbyte) with 
64-bit wide bus. The mtd driver in linux 2.4.18 kernel does not work for 
this configuration.  Does anyone have similar experiences?  What is the 
solution?  Thanks.



From nico at cam.org  Fri Oct  3 16:08:36 2003
From: nico at cam.org (Nicolas Pitre)
Date: Fri, 3 Oct 2003 16:08:36 -0400 (EDT)
Subject: mtd support for 64-bit bus
In-Reply-To: <6.0.0.22.2.20031003125817.03ae9010@e2k.qualcomm.com>
Message-ID: <Pine.LNX.4.44.0310031606230.29733-100000@xanadu.home>

On Fri, 3 Oct 2003, Howard King wrote:

> We have a customized board with 4 AMD 29L641V flash chips (4 * 8Mbyte) with 
> 64-bit wide bus. The mtd driver in linux 2.4.18 kernel does not work for 
> this configuration.  Does anyone have similar experiences?  What is the 
> solution?  Thanks.

Upgrade your MTD code to a more recent snapshot.


Nicolas



From tharbuagh at lnxi.com  Fri Oct  3 23:18:10 2003
From: tharbuagh at lnxi.com (Thayne Harbaugh)
Date: Fri, 03 Oct 2003 21:18:10 -0600
Subject: mtd support for 64-bit bus
In-Reply-To: <6.0.0.22.2.20031003125817.03ae9010@e2k.qualcomm.com>
References: <6.0.0.22.2.20031003125817.03ae9010@e2k.qualcomm.com>
Message-ID: <1065213244.1508.14.camel@phantasm>

On Fri, 2003-10-03 at 14:02, Howard King wrote:
> We have a customized board with 4 AMD 29L641V flash chips (4 * 8Mbyte) with 
> 64-bit wide bus. The mtd driver in linux 2.4.18 kernel does not work for 
> this configuration.  Does anyone have similar experiences?  What is the 
> solution?  Thanks.

Just last week I committed some 64 bit fixes.  I know of a few people
that are using 64 bit buses.  I looked for the AMD 29L641V - I didn't
see it on the AMD site
(http://www.amd.com/us-en/FlashMemory/TechnicalResources/0,,37_1693_2351,00.html).
Will you send me a URL for the data sheet?

If current CVS doesn't work, let us know.



From dwmw2 at infradead.org  Sat Oct  4 13:19:39 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 04 Oct 2003 18:19:39 +0100
Subject: Patches to nanddump.c
In-Reply-To: <200310021344.14931.timg@tpi.com>
References: <200310021344.14931.timg@tpi.com>
Message-ID: <1065287933.16005.2.camel@imladris.demon.co.uk>

On Thu, 2003-10-02 at 13:44 -0600, Tim Gardner wrote:
> I've added a couple of options to nanddump.c:
> 
> -no-oob allowa you to retrieve the contents of a NAND character partiion 
> without the OOB info. 
> 
> -no-print satisfies the interactive pretty-print request. 

Looks generally sane. Can you use getopt please. Example in mkfs.jffs2.c
-- 
dwmw2




From if at sil.at  Sun Oct  5 02:25:59 2003
From: if at sil.at (Ingo Flaschberger)
Date: Sun, 5 Oct 2003 08:25:59 +0200 (CEST)
Subject: extract data fom nand_dump / how to get it back into nand_write
 format?
Message-ID: <Pine.GSO.4.56.0310050802220.3023@ikarus.sil.at>

Hi

because of some playing with a sharp zaurus c750 i need following stuff:
extract data from a backup which is made with nand_dump (which already
works)
get the data back to nand (where the only way is the "build in"
nand_write).

what i know till now (from hexdumping):
32 byte at the start of the nand_dump-file
every 16384bytes (first 16384+32) there is a 528 byte block with
"page data"

if i remove this, i have a plain file from there i could dd the
filesystem-images (and mount is already *g*).

small perlprog which do this:
---snip---
#! /usr/bin/perl

# i have a 64mbyte flash (Toshiba TH58512FT
# Manufacture ID: 0x98, Chip ID: 0x76)
# filesize of nand_dump is then:
# 528*4096 +(64*1024*1024) + 16
#                            ^^^ why 16? then the last page-data must be
#				 special? only 512 long?
$filesize=69271568/16;

# i use 16 byte big block.. make the dd faster than with 1 byte blocks
# and the script is still easy

# extract plain flash image
$skip=2;
$seek=0;
for ($i=0;$i<$filesize;$i=$skip) {
        $exec= "dd bs=16 obs=16 ibs=16 if=SYSTC750.DBK ".
		"of=SYSTC750.raw count=1024 skip=$skip seek=$seek \n";
        print $exec;
        system($exec);
        $skip= $skip+1024+33;
        $seek = $seek + 1024;
}

# extract page data
$exec= "dd bs=16 obs=16 ibs=16 if=SYSTC750.DBK of=SYSTC750.pageinfo ".
        	"count=2\n";
system($exec);

$skip=1024+2;
$seek=2;
for ($i=0;$i<$filesize;$i=$skip) {
        $exec= "dd bs=16 obs=16 ibs=16 if=SYSTC750.DBK "
		"of=SYSTC750.pageinfo count=33 skip=$skip seek=$seek \n";
        print $exec;
        system($exec);
        $skip= $skip+1024+33;
        $seek = $seek + 33;
}
---snap---


now i would like to code a programm which could reconstruct the nand_dump
format from the "plain" flash image, that i could move the data back.

and some hints how the paga-data is structured would be very nice (nothing
to see about that in the web).

some more info about partitions in mtd would be nice...
does the mtdparts affect the "page data"?

thnx & bye,
	Ingo

--
we own the fibre; 9.6.98 illiad


From mikey at bur.st  Sun Oct  5 21:52:57 2003
From: mikey at bur.st (Michael McLellan)
Date: Mon, 6 Oct 2003 11:52:57 +1000 (EST)
Subject: NFTL / FTL DoC booting
In-Reply-To: <Pine.GSO.4.56.0310050802220.3023@ikarus.sil.at>
References: <Pine.GSO.4.56.0310050802220.3023@ikarus.sil.at>
Message-ID: <Pine.LNX.4.53.0310061146570.12632@slop.cobalttech.com>

I've been trying to get this to work for ages and havn't gotten very far.
So I hope you guys can help me out.

I can install grub on my DoC but when it boots it goes to the grub shell.
The only devices which show up are (hd0) and (fd0) no (dc0). When I boot
my kernel from hd0 I get this:

$Id: ftl.c,v 1.52 2003/08/11 09:00:44 dwmw2 Exp $
NFTL driver: nftlcore.c $Revision: 1.94 $, nftlmount.c $Revision: 1.34 $
DiskOnChip 2000 found at address 0xD0000
Flash chip found: Manufacturer ID: 98, Chip ID: 75 (Toshiba:NAND 32MiB 3,3V)
3 flash chips found. Total DiskOnChip size: 96 MiB
mtd: Giving out device 0 to DiskOnChip 2000
Could not find valid boot record
NFTL: could not mount device
 ftla: ftla1

I can mount the device as /dev/ftla1 OK, but not nftla.

My questions are:
	What is nftla and ftla?
	Which one should I use?
	Can grub only see nftl devices?
	Is my chip stuffed?
	Do I need to compile nftl_format?
	What other header file do I need to include which has all the semaphore types defined correctly so it will compile?

Thanks heaps,
Mikey.


From dwmw2 at infradead.org  Mon Oct  6 02:23:48 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 06 Oct 2003 07:23:48 +0100
Subject: NFTL / FTL DoC booting
In-Reply-To: <Pine.LNX.4.53.0310061146570.12632@slop.cobalttech.com>
References: <Pine.GSO.4.56.0310050802220.3023@ikarus.sil.at>
	 <Pine.LNX.4.53.0310061146570.12632@slop.cobalttech.com>
Message-ID: <1065421428.3157.171.camel@imladris.demon.co.uk>

Grrr. This isn't a continuation of the thread 'extract data from
nand_dump...' but that's what you replied to. And in a fit of stupidity
I approved it, thinking it was a reply to an off-list message and
wouldn't break the threading.

Shame; I was going to answer you too.

Please read http://www.infradead.org/~dwmw2/email.html

-- 
dwmw2




From h.schurig at mn-logistik.de  Mon Oct  6 05:25:52 2003
From: h.schurig at mn-logistik.de (Holger Schurig)
Date: Mon, 6 Oct 2003 11:25:52 +0200
Subject: [PATCH] even less clutter in 2.6 boot log
Message-ID: <200310061125.52793.h.schurig@mn-logistik.de>

This makes the output of the boot log somewhat more pretty. It saves some 
bytes as well.


BTW: this and the previous is part of a series of patches that unifies the 
kernel log somewhat (not totally) to be in a "subsystem: message" style. 
E.g., my current kernel bootlog now looks like this:

Linux version 2.6.0-test6-bkpxa (root at mnz66.mn-logistik.de) (gcc version 
3.3) #175 Mon Oct 6 10:48:21 CEST 2003
CPU: XScale-PXA250 [69052d06] revision 6 (ARMv5TE)
CPU: D undefined 5 cache
CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Machine: Ramses
Ignoring unrecognised tag 0x00000000
Memory policy: ECC disabled, Data cache write back
Memory clock: 99.53MHz (*27)
Run Mode clock: 398.13MHz (*4)
Turbo Mode clock: 398.13MHz (*1.0, active)
On node 0 totalpages: 32768
  DMA zone: 32768 pages, LIFO batch:8
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Building zonelist for node 0
Kernel command line: root=/dev/mtdblock2 jffs2_orphaned_inodes=delet 
rootfstype=jffs2 console=ttyS0,115200
PID hash table entries: 512 (order 9: 4096 bytes)
Console: colour dummy device 80x30
Memory: 128MB = 128MB total
Memory: 128448KB available (851K code, 194K data, 52K init)
Calibrating delay loop... 397.31 BogoMIPS
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
arm: write buffer coherency ok
arm: nwfpe v0.97 (double)
devfs: v1.22 (20021013)
jffs2: v2.1 (c) 2002 Red Hat Inc
pty: 256 Unix98 ptys configured
ttyS0 at MMIO 0x40100000 IRQ 15 is a FFUART
ttyS1 at MMIO 0x40200000 IRQ 14 is a BTUART
ttyS2 at MMIO 0x40700000 IRQ 13 is a STUART
io-scheduler: noop
mtd: 0x00000000-0x00040000: "Bootloader"
mtd: 0x00040000-0x00140000: "Kernel"
mtd: 0x00140000-0x02000000: "Filesystem"
i2c_adapter i2c-0: found device 0x68
VFS: Mounted root (jffs2 filesystem).
Mounted devfs on /dev
Freeing init memory: 52K

-- 
Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at
http://www.mn-logistik.de/unsupported/linux-2.6/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trivial-jffs2printk.patch
Type: text/x-diff
Size: 343 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031006/f8d6b594/attachment.bin 

From h.schurig at mn-logistik.de  Mon Oct  6 05:21:04 2003
From: h.schurig at mn-logistik.de (Holger Schurig)
Date: Mon, 6 Oct 2003 11:21:04 +0200
Subject: [PATCH] less clutter in 2.6 boot log
Message-ID: <200310061121.04067.h.schurig@mn-logistik.de>

This removes some of the clutter in the boot log when Kernel 2.6 comes up.

-- 
Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at
http://www.mn-logistik.de/unsupported/linux-2.6/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trivial-mtdprintk.patch
Type: text/x-diff
Size: 1717 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031006/056f379c/attachment.bin 

From linux at horizon.com  Mon Oct  6 07:07:12 2003
From: linux at horizon.com (linux at horizon.com)
Date: 6 Oct 2003 11:07:12 -0000
Subject: On the usefulness of CONFIG_MTD_BLOCK_RO
Message-ID: <20031006110712.4605.qmail@science.horizon.com>

I was just fixing a performance problem caused by upgrading an old Pentium
system above 64 MB of memory.  This led me to limit the kernel's memory
usage but try to use the slram device as swap space.

RTFM, read some example HOWTOs
(http://hedera.linuxnews.pl/_news/2002/09/03/_long/1445.html)
and set up a 2.6.0-test6 kernel...

# Memory Technology Devices (MTD)
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
# CONFIG_MTD_PARTITIONS is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# Self-contained MTD device drivers
# CONFIG_MTD_PMC551 is not set
CONFIG_MTD_SLRAM=y
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_NAND is not set

Booting with "mem=65151k slram=slram,64M,96M"
(mem= is 64M minus 384K of unusable PC high memory, minus 1K of EDBA at 639K.)

gives me a nice entry in /proc/mtd:
dev:    size   erasesize  name
mtd0: 02000000 00000000 "slram"

but when I try to mkwap /dev/mtdblock0, I get complaints...

kernel: end_request: I/O error, dev mtdblock0, sector 0
kernel: Buffer I/O error on device mtdblock0, logical block 0
kernel: lost page write due to I/O error on mtdblock0

Note that this is with CONFIG_MTD_DEBUG_VERBOSE=3.

I'm not quite sure why it doesn't work, although the following code
snippets look suspiscious:

slram.c:204:	(*curmtd)->mtdinfo->erasesize = 0x0;
(in register_device())

and mtdblock_writesect() in mtdblock.c:
static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
			      unsigned long block, char *buf)
{
	struct mtdblk_dev *mtdblk = mtdblks[dev->devnum];
	if (unlikely(!mtdblk->cache_data)) {
		mtdblk->cache_data = vmalloc(mtdblk->mtd->erasesize);
		if (!mtdblk->cache_data)
			return -EINTR;
		/* -EINTR is not really correct, but it is the best match
		 * documented in man 2 write for all cases.  We could also
		 * return -EAGAIN sometimes, but why bother?
		 */
	}
	return do_cached_write(mtdblk, block<<9, 512, buf);
}

Note that vmalloc(0) will return 0, and I'm not sure what the higher layers
will do with a -EINTR return, but the error mesage eems consistent.

I think there's a bug here somewhere.  (And a second bug that the first
bug doesn't elicit a log message.)


Further searching through the code and CV archives led me to discover
mtdblock_ro.c, and enabling that instead has provided me with a working
system.  I'd like to propose the following documentation patch.

--- drivers/mtd/Kconfig	2003-10-06 09:47:34 +0000
+++ drivers/mtd/Kconfig	2003-10-06 10:00:35 +0000
@@ -156,15 +156,25 @@
 	  those, enable NFTL support (CONFIG_NFTL) instead.
 
 config MTD_BLOCK_RO
-	tristate "Readonly block device access to MTD devices"
+	tristate "Readonly/RAM block device access to MTD devices"
 	depends on MTD_BLOCK!=y && MTD
 	help
-	  This allows you to mount read-only file systems (such as cramfs)
-	  from an MTD device, without the overhead (and danger) of the caching
-	  driver.
+	  The full MTD_BLOCK driver supports writes smaller than the erase
+	  size of the device by performing a read/modify/write sequence.
+	  This is a much simpler driver that does not hide the underlying
+	  device's limitations.  Despite the name, it does have limited
+	  write support.
+
+	  This driver can be used with any MTD device read-only, to mount
+	  read-only file systems (such as cramfs) from an MTD device,
+	  without the overhead (and danger) of the caching driver.
+
+	  It can also be used to write to devices which do not have
+	  erase size limitations, particularly RAM-based devices such
+	  as slram and mtdram.
 
-	  You do not need this option for use with the DiskOnChip devices. For
-	  those, enable NFTL support (CONFIG_NFTL) instead.
+	  This driver provides the same mtdblock0 devices (major 31) as
+	  the full MTD_BLOCK driver, so the two are mututally exclusive.
 
 config FTL
 	tristate "FTL (Flash Translation Layer) support"



As an aside, the description of the MTD_BLOCK option seems potentially
out of date.  It talks about future extension to read/erase/modify/write,
which appears to have been accomplished some time ago.

But I'd like to leave that change to someone who has a better overview
of the state of the mtd system.

Thanks!


From timg at tpi.com  Mon Oct  6 09:13:13 2003
From: timg at tpi.com (Tim Gardner)
Date: Mon, 6 Oct 2003 07:13:13 -0600
Subject: Patches to nanddump.c
In-Reply-To: <1065287933.16005.2.camel@imladris.demon.co.uk>
References: <200310021344.14931.timg@tpi.com>
	<1065287933.16005.2.camel@imladris.demon.co.uk>
Message-ID: <200310060713.13344.timg@tpi.com>

Using getopt will break command line option backward compatibility, which is 
fine with me because it would clean up some parsing code. Any objections?

On Saturday 04 October 2003 11:19, David Woodhouse wrote:
>
> Looks generally sane. Can you use getopt please. Example in mkfs.jffs2.c

-- 
Tim Gardner - timg at tpi.com 406-443-5357
TriplePoint, Inc. - http://www.tpi.com
PGP: http://www.tpi.com/PGP/Tim.txt


From dwmw2 at infradead.org  Mon Oct  6 09:15:24 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 06 Oct 2003 14:15:24 +0100
Subject: Patches to nanddump.c
In-Reply-To: <200310060713.13344.timg@tpi.com>
References: <200310021344.14931.timg@tpi.com>
	 <1065287933.16005.2.camel@imladris.demon.co.uk>
	 <200310060713.13344.timg@tpi.com>
Message-ID: <1065446123.22491.191.camel@hades.cambridge.redhat.com>

On Mon, 2003-10-06 at 07:13 -0600, Tim Gardner wrote:
> Using getopt will break command line option backward compatibility, which is 
> fine with me because it would clean up some parsing code. Any objections?

Nope. It's mostly a debugging tool anyway.

-- 
dwmw2



From dwmw2 at redhat.com  Mon Oct  6 10:46:09 2003
From: dwmw2 at redhat.com (David Woodhouse)
Date: Mon, 06 Oct 2003 15:46:09 +0100
Subject: [PATCH] Memory leak in mtd/chips/cfi_cmdset_0020
In-Reply-To: <3F81800A.5000500@terra.com.br>
References: <3F81800A.5000500@terra.com.br>
Message-ID: <1065451568.22491.215.camel@hades.cambridge.redhat.com>

On Mon, 2003-10-06 at 11:45 -0300, Felipe W Damasio wrote:
> 	Hi David,
> 
> 	Patch against 2.6.0-test6.
> 
> 	- Frees a previous allocated kmalloced variable before returning NULL;
> 
> 	Found by smatch.

Applied; thanks. It'll be in the next update sent to Linus, when I get a
few spare moments for merging and testing.

Out of interest, why didn't smatch also find the same error 25 lines
further down?

-- 
dwmw2


From dwmw2 at redhat.com  Mon Oct  6 10:52:44 2003
From: dwmw2 at redhat.com (David Woodhouse)
Date: Mon, 06 Oct 2003 15:52:44 +0100
Subject: [PATCH] Memory leak in mtd/chips/cfi_cmdset_0020
In-Reply-To: <3F81820F.2000602@terra.com.br>
References: <3F81800A.5000500@terra.com.br>
	 <1065451568.22491.215.camel@hades.cambridge.redhat.com>
	 <3F81820F.2000602@terra.com.br>
Message-ID: <1065451964.22491.217.camel@hades.cambridge.redhat.com>

On Mon, 2003-10-06 at 11:54 -0300, Felipe W Damasio wrote:
> 	He did...I didn't ;)

Heh, OK. 

> 	If you want, updated patch is attached.

I'd already done it, but thanks.

-- 
dwmw2


From felipewd at terra.com.br  Mon Oct  6 10:45:30 2003
From: felipewd at terra.com.br (Felipe W Damasio)
Date: Mon, 06 Oct 2003 11:45:30 -0300
Subject: [PATCH] Memory leak in mtd/chips/cfi_cmdset_0020
Message-ID: <3F81800A.5000500@terra.com.br>

	Hi David,

	Patch against 2.6.0-test6.

	- Frees a previous allocated kmalloced variable before returning NULL;

	Found by smatch.

	Please consider applying,

Felipe
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cfi_cmdset_0020-leak.patch
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031006/77363189/attachment.pl 

From felipewd at terra.com.br  Mon Oct  6 10:54:07 2003
From: felipewd at terra.com.br (Felipe W Damasio)
Date: Mon, 06 Oct 2003 11:54:07 -0300
Subject: [PATCH] Memory leak in mtd/chips/cfi_cmdset_0020
In-Reply-To: <1065451568.22491.215.camel@hades.cambridge.redhat.com>
References: <3F81800A.5000500@terra.com.br>
	<1065451568.22491.215.camel@hades.cambridge.redhat.com>
Message-ID: <3F81820F.2000602@terra.com.br>



David Woodhouse wrote:
> Applied; thanks. It'll be in the next update sent to Linus, when I get a
> few spare moments for merging and testing.

	Great, thanks.

> Out of interest, why didn't smatch also find the same error 25 lines
> further down?

	He did...I didn't ;)

	If you want, updated patch is attached.

	Cheers,

Felipe
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cfi_cmdset_0020-leak.patch
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031006/2acd8590/attachment.pl 

From gary at mlbassoc.com  Mon Oct  6 13:10:47 2003
From: gary at mlbassoc.com (Gary Thomas)
Date: 06 Oct 2003 11:10:47 -0600
Subject: cfi probe for two different flash devices
In-Reply-To: <200310060645.BAA09508@lists.linuxppc.org>
References: <200310060645.BAA09508@lists.linuxppc.org>
Message-ID: <1065460247.1884.188.camel@hermes>

On Mon, 2003-10-06 at 00:20, J.Murali wrote:
> hi all,
> 
> i am working on a custom board(Redwood6) using IBM ppc 405. I am using
> the Montavista's kernel 2.4.17. We have one AMD flash of 4 MB and one
> Intel flash of 16 MB on our board. There are 4 mtd partitions are in AMD
> and Intel flash is used as storage space of 5 mtd partition.
> 
> AMD partitions
> -----------------
> 1. Bootparams
> 2. Bootldr
> 3. kernel
> 4. Filesystem1
> 
> Intel partition
> --------------
> 5. Filesystem2
> 
> In the CFI probe, the kernel detects only one flash either AMD or INTEL
> (Which address we specify as window address). What i have to to do for
> cfi to detect both flash devices.
> 
> Any suggestions are appreciated
> 

This question would be best asked of the MTD folks (cc'd), but I think
you'll need a customized "map" function that recognizes these two FLASH
device types and creates the appropriate MTD sub-devices appropriately.

-- 
Gary Thomas <gary at mlbassoc.com>
MLB Associates



From dwmw2 at infradead.org  Mon Oct  6 13:16:14 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 06 Oct 2003 18:16:14 +0100
Subject: cfi probe for two different flash devices
In-Reply-To: <1065460247.1884.188.camel@hermes>
References: <200310060645.BAA09508@lists.linuxppc.org>
	 <1065460247.1884.188.camel@hermes>
Message-ID: <1065460574.22491.243.camel@hades.cambridge.redhat.com>

On Mon, 2003-10-06 at 11:10 -0600, Gary Thomas wrote:
> This question would be best asked of the MTD folks (cc'd), but I think
> you'll need a customized "map" function that recognizes these two FLASH
> device types and creates the appropriate MTD sub-devices appropriately.

What Gary said.

If you poke around in drivers/mtd/maps you'll find useful examples of
such, including how to concatenate them together into one logical MTD
device and have a file system spanning them both, etc.

-- 
dwmw2



From cmayor at iders.ca  Mon Oct  6 15:33:16 2003
From: cmayor at iders.ca (Cam Mayor)
Date: Mon, 6 Oct 2003 14:33:16 -0500
Subject: mtd filesystem across different sector sizes in the same part
Message-ID: <03100614331605.30787@kilauea.iders.ca>

After doing a flash storage map for one of our devices and based on reading a 
recent question to this list, i thought of another question.

In my flash part (intel 28f320c3) there are 8 x 8kB blocks and 63 x 64 kB 
blocks.  I believe that [1] MTD can span the two block sizes effectively for 
it to be recognized as a single MTD device.  JFFS2, IIRC, uses 5 flash blocks 
for flash filesystem overhead.  Do those blocks have to be any specific size 
relative to the rest of the filesystem blocks?  Will it use the first five 
blocks, or does it move around for wear levelling?  Will JFFS2 get confused 
by different block sizes, or is that already handled in the MTD layer?  

If the 5 blocks move around, is there any way to predict how much space will 
be available in the filesystem?  (eg. one moment you have 5 overhead blocks 
in the 8kB area and have 70kB free.  the next moment you have 4 overhead 
blocks in the 8kB area, and one in the 64kB area, leaving you with 14kB free 
space)

thanks,
cam

[1] please correct me if i'm wrong


-- 
Cameron Mayor
Iders Incorporated


From dwmw2 at infradead.org  Mon Oct  6 15:36:27 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 06 Oct 2003 20:36:27 +0100
Subject: mtd filesystem across different sector sizes in the same part
In-Reply-To: <03100614331605.30787@kilauea.iders.ca>
References: <03100614331605.30787@kilauea.iders.ca>
Message-ID: <1065468987.30987.26.camel@imladris.demon.co.uk>

On Mon, 2003-10-06 at 14:33 -0500, Cam Mayor wrote:
> After doing a flash storage map for one of our devices and based on reading a 
> recent question to this list, i thought of another question.
> 
> In my flash part (intel 28f320c3) there are 8 x 8kB blocks and 63 x 64 kB 
> blocks.  I believe that [1] MTD can span the two block sizes effectively for 
> it to be recognized as a single MTD device.  JFFS2, IIRC, uses 5 flash blocks 
> for flash filesystem overhead.  Do those blocks have to be any specific size 
> relative to the rest of the filesystem blocks?  Will it use the first five 
> blocks, or does it move around for wear levelling?  Will JFFS2 get confused 
> by different block sizes, or is that already handled in the MTD layer?  

JFFS2 will use the 'major' erase size, and treat your 8 * 8KiB blocks as
a single 64KiB block.

-- 
dwmw2




From timg at tpi.com  Mon Oct  6 13:32:47 2003
From: timg at tpi.com (Tim Gardner)
Date: Mon, 6 Oct 2003 11:32:47 -0600
Subject: Patches to nanddump.c
In-Reply-To: <1065446123.22491.191.camel@hades.cambridge.redhat.com>
References: <200310021344.14931.timg@tpi.com>
	<200310060713.13344.timg@tpi.com>
	<1065446123.22491.191.camel@hades.cambridge.redhat.com>
Message-ID: <200310061132.47410.timg@tpi.com>

Since the patch is nearly as large as the file, I've just attached the file 
itself. The default options are sane in that it prints an ASCII dump of the 
specified partition to stdout. Usage output is:

[root at ppc /]$ nanddump -h
usage: nanddump
-p MTD_PARTITION  - MTD partition to dump from, e,g, /dev/mtd0
[-o DUMP_FILE]    - file to dump to, default is stdout
[-a ADDR]         - starting offset within the MTD partition, default 0
[-l LENGTH]       - Number of bytes to dump, default is size of partition
[-n]              - Omit OOB information in dump.
[-b]              - binary dump of data. Default is ASCII hex
[-v]              - verbose output.
[-h]              - Print this help message.

On Monday 06 October 2003 07:15, David Woodhouse wrote:
> On Mon, 2003-10-06 at 07:13 -0600, Tim Gardner wrote:
> > Using getopt will break command line option backward compatibility, which
> > is fine with me because it would clean up some parsing code. Any
> > objections?
>
> Nope. It's mostly a debugging tool anyway.

-- 
Tim Gardner - timg at tpi.com 406-443-5357
TriplePoint, Inc. - http://www.tpi.com
PGP: http://www.tpi.com/PGP/Tim.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nanddump.c
Type: text/x-csrc
Size: 5859 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031006/33160f1d/attachment.bin 

From cmayor at iders.ca  Mon Oct  6 16:45:45 2003
From: cmayor at iders.ca (Cam Mayor)
Date: Mon, 6 Oct 2003 15:45:45 -0500
Subject: mtd filesystem across different sector sizes in the same part
In-Reply-To: <1065468987.30987.26.camel@imladris.demon.co.uk>
References: <03100614331605.30787@kilauea.iders.ca>
	<1065468987.30987.26.camel@imladris.demon.co.uk>
Message-ID: <03100615454506.30787@kilauea.iders.ca>

On Monday 06 October 2003 14:36, David Woodhouse wrote:
> On Mon, 2003-10-06 at 14:33 -0500, Cam Mayor wrote:
> > In my flash part (intel 28f320c3) there are 8 x 8kB blocks and 63 x 64 kB
> > blocks.  I believe that [1] MTD can span the two block sizes effectively
> > for it to be recognized as a single MTD device.  JFFS2, IIRC, uses 5
> > flash blocks for flash filesystem overhead.  Do those blocks have to be
> > any specific size relative to the rest of the filesystem blocks?  Will it
> > use the first five blocks, or does it move around for wear levelling? 
> > Will JFFS2 get confused by different block sizes, or is that already
> > handled in the MTD layer?
>
> JFFS2 will use the 'major' erase size, and treat your 8 * 8KiB blocks as
> a single 64KiB block.

In my particular usage, the first two (of eight) "small" blocks are used by 
the bootloader, leaving a free area of 6 x 8kiB blocks + 6 x 64 kiB blocks.   
Just now i tried specifying this oddly shaped area on the kernel command 
line, with the result:
	mtd: partition "free" doesn't start on an erase block boundary -- force 
read-only

So, it sounds like JFFS2 won't handle this specific situation, as mtd itself 
is unwilling to deal with it.  (the partition "free" does start on an erase 
block boundary - but it is one of the smaller block boundaries, not the major 
erase size)

I don't have a multi-flash system, so i can't test this, but i wonder how 
this would work for a system concatenated across two flash chips with 
different erase block sizes where the numbers don't allow them to align 
nicely.

Here's another thing i just thought of but haven't noticed in my mtd research 
in the past (and couldn't see anything relevant in Configure.help): is there 
a way to get two non-continuous mtd partitions to host a jffs2 filesystem?  
eg. 
mtd5: 00400000 00020000 "userarea1"
mtd6: 00400000 00020000 "something_else"
mtd7: 00400000 00020000 "userarea2"
is there a way to use the disjoint mtd5+mtd7 together to host a continuous 
filesystem?

thanks for the info.

-- 
Cameron Mayor
Iders Incorporated


From dwmw2 at infradead.org  Mon Oct  6 17:08:54 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 06 Oct 2003 22:08:54 +0100
Subject: mtd filesystem across different sector sizes in the same part
In-Reply-To: <03100615454506.30787@kilauea.iders.ca>
References: <03100614331605.30787@kilauea.iders.ca>
	 <1065468987.30987.26.camel@imladris.demon.co.uk>
	 <03100615454506.30787@kilauea.iders.ca>
Message-ID: <1065474534.30987.31.camel@imladris.demon.co.uk>

On Mon, 2003-10-06 at 15:45 -0500, Cam Mayor wrote:
> In my particular usage, the first two (of eight) "small" blocks are used by 
> the bootloader, leaving a free area of 6 x 8kiB blocks + 6 x 64 kiB blocks.   
> Just now i tried specifying this oddly shaped area on the kernel command 
> line, with the result:
> 	mtd: partition "free" doesn't start on an erase block boundary -- force 
> read-only

Yep. There exists no 'major' erasesize. All real hardware devices have
one, we don't try to work around it.

> is there a way to use the disjoint mtd5+mtd7 together to host a continuous 
> filesystem?

See mtdconcat.

-- 
dwmw2




From slimaffi at yahoo.com  Mon Oct  6 17:34:35 2003
From: slimaffi at yahoo.com (Slim)
Date: Mon, 6 Oct 2003 14:34:35 -0700 (PDT)
Subject: redhat 9, doc 2000
In-Reply-To: <E1A6b7A-0004WA-Gx@pentafluge.infradead.org>
Message-ID: <20031006213435.38037.qmail@web9906.mail.yahoo.com>

> Did you copy the kernel image (like bzImage) to your doc and
configure
> the grub settings on your doc correctly?

I copied the entire /boot to the doc.
 
> I put my bzImage in /boot and in grub/menu.lst I have the following:
> 
> title DiskOnChip 2000
> 	root (dc0,0)
> 	kernel /boot/bzImage ro root=/dev/nftla1

This is the part I wasn't sure about.

> When you can boot from doc using grub, that's a good start. You may
> actually edit the boot command line when grub is booted. It supports
> auto-completion for you to easily locate your kernel image.

I've tried now to boot the hard disk based kernel to allow editing to
try
the above, but the doc-grub always loads despite changing the boot
device
in the bios setup.  Now I can't boot from the hard drive unless I
disable
all access to the doc.  Any workaround?

Thanks,
John



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From ilatypov at infradead.org  Mon Oct  6 17:51:17 2003
From: ilatypov at infradead.org (Ilguiz Latypov)
Date: Mon, 6 Oct 2003 17:51:17 -0400
Subject: redhat 9, doc 2000
In-Reply-To: <20031006213435.38037.qmail@web9906.mail.yahoo.com>
References: <E1A6b7A-0004WA-Gx@pentafluge.infradead.org>
	<20031006213435.38037.qmail@web9906.mail.yahoo.com>
Message-ID: <20031006215117.GA5320@ei.homeip.net>


On Mon, Oct 06, 2003 at 02:34:35PM -0700, Slim wrote:
> > When you can boot from doc using grub, that's a good start. You may
> > actually edit the boot command line when grub is booted. It supports
> > auto-completion for you to easily locate your kernel image.
> 
> I've tried now to boot the hard disk based kernel to allow editing to
> try the above, but the doc-grub always loads despite changing the boot
> device in the bios setup.

The GRUB's 'e' key will allow to edit the configuration file in-memory.
And the 'c' key will bring to the GRUB's shell prompt.

-- 
Ilguiz Latypov

tel.  +1 (519) 569-8746
66 Wildlark Crescent
Kitchener, Ontario N2N 3E9



From mikey at bur.st  Mon Oct  6 18:00:51 2003
From: mikey at bur.st (Michael McLellan)
Date: Tue, 7 Oct 2003 08:00:51 +1000 (EST)
Subject: redhat 9, doc 2000
In-Reply-To: <20031006213435.38037.qmail@web9906.mail.yahoo.com>
References: <20031006213435.38037.qmail@web9906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.53.0310070758050.1614@slop.cobalttech.com>

On Mon, 6 Oct 2003, Slim wrote:
>
> I've tried now to boot the hard disk based kernel to allow editing to
> try the above, but the doc-grub always loads despite changing the boot
> device in the bios setup.  Now I can't boot from the hard drive unless I
> disable all access to the doc.  Any workaround?

When you get to the grub shell you can do something like:

root (hd0)
chainloader +1
boot

This will make grub start booting from the first sector of hd0, which is
probably where your harddisk is.

This is where I'm up to, I cannot get grub to recognise the DoC, the only
devices I have avalible is (fd0) and (hd0) :(

Mikey.


From selwyn at hectrix.com  Mon Oct  6 22:55:33 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Tue, 07 Oct 2003 10:55:33 +0800
Subject: redhat 9, doc 2000
In-Reply-To: <20031006213435.38037.qmail@web9906.mail.yahoo.com>
References: <20031006213435.38037.qmail@web9906.mail.yahoo.com>
Message-ID: <3F822B25.2020600@hectrix.com>

On 10/07/2003 05:34 AM, Slim wrote:
> the above, but the doc-grub always loads despite changing the boot
> device in the bios setup.  Now I can't boot from the hard drive unless I
> disable all access to the doc.  Any workaround?

I think you have built a GRUB firmware and written it on the DOC. But
there is a catch that the firmware will register as a BIOS extension
that will take over the boot sequence from the BIOS. You should patch
GRUB with the ctrlbypass functionality. It allows you to bypass the GRUB
on DOC and boot according to your BIOS by holding CTRL while booting. I
used grub-2003-01-08.doc.patch here. Refer to p.262-266 of Karim's book.

Now, to get back to boot from your harddisk and have a chance to rewrite
the correct firmware, you may try hotplugging your DOC after the system
is booted. Although it is a bit undesirable and dangerous, I tried once
and it seemed alright. Once, I even accidentally pulled out a DOC with a
screwdriver while the system was still running, and the DOC was not
damaged at all.

Selwyn



From selwyn at hectrix.com  Wed Oct  8 05:46:21 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Wed, 08 Oct 2003 17:46:21 +0800
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <1065171167.22491.53.camel@hades.cambridge.redhat.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	<3F7CD9CA.5090805@hectrix.com>
	<1065160480.16088.0.camel@imladris.demon.co.uk>
	<3F7D31B7.7020400@hectrix.com>
	<1065171167.22491.53.camel@hades.cambridge.redhat.com>
Message-ID: <3F83DCED.8090206@hectrix.com>

On 10/03/2003 04:52 PM, David Woodhouse wrote:
> Also, can you reset the profile counts (readprofile -r) and get a
> reading from the time when it's doing this alone, rather than including
> everything from boot onwards.

Here is the output of readprofile after reset and before nftld holds my cpu:

     1 __generic_copy_to_user                     0.0139
     1 write_profile                              0.0208
   380 default_idle                               9.5000
   382 total                                      0.0003

Then I simply entered "ls /mnt/doc" (which is mounted at boot to
/dev/nftla1), and got the following result (I skipped those with one
occasion only):

     2 __delay                                    0.0333
     2 sock_poll                                  0.0500
     2 unix_poll                                  0.0135
     3 __const_udelay                             0.0833
   284 _DoC_WaitReady                             2.8400
   577 __rdtsc_delay                             20.6071
  1199 default_idle                              29.9750
  2084 total                                      0.0018

This is the output a few seconds later (also skipped some lines):

     2 add_wait_queue                             0.0500
     2 __generic_copy_to_user                     0.0278
     2 sock_poll                                  0.0500
     3 __delay                                    0.0500
     3 unix_poll                                  0.0203
     5 __const_udelay                             0.1389
   607 _DoC_WaitReady                             6.0700
  1199 default_idle                              29.9750
  1243 __rdtsc_delay                             44.3929
  3082 total                                      0.0026

So, __rdtsc_delay and _DoC_WaitReady seem to be the source of the
problem. I hope these will help you investigate. I have attached the
three outputs of readprofile for your reference.

> If it does it only sometimes, is there any pattern to when it starts or
> stops?

Once it has started, it would never stop. Sometimes, after fsck on the
doc, and remount, it becomes normal. But this time, I even tried booting
using the doc and perform some operations (like 'find .') and rebooting
back using my harddisk, and also tried booting using dos floppy and used
dinfo without the problem, but when back to Linux the problem was still
there.

I think dformating in dos is my last resort.

Selwyn

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: before
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031008/18deae11/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: after
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031008/18deae11/attachment-0001.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: after2
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031008/18deae11/attachment-0002.pl 

From dwmw2 at infradead.org  Wed Oct  8 05:58:52 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 08 Oct 2003 10:58:52 +0100
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <3F83DCED.8090206@hectrix.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	 <3F7CD9CA.5090805@hectrix.com>
	 <1065160480.16088.0.camel@imladris.demon.co.uk>
	 <3F7D31B7.7020400@hectrix.com>
	 <1065171167.22491.53.camel@hades.cambridge.redhat.com>
	 <3F83DCED.8090206@hectrix.com>
Message-ID: <1065607132.22298.88.camel@hades.cambridge.redhat.com>

It looks like it's thrashing the flash, but I can't tell why, since the
NFTL code isn't showing up on the trace. 

Can you throw printk statements into various routines in nftlcore.c so
we can it actually thinks it's doing?

You _are_ mounting your file system with -onoatime, aren't you?

-- 
dwmw2



From selwyn at hectrix.com  Wed Oct  8 06:16:06 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Wed, 08 Oct 2003 18:16:06 +0800
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <1065607132.22298.88.camel@hades.cambridge.redhat.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	<3F7CD9CA.5090805@hectrix.com>
	<1065160480.16088.0.camel@imladris.demon.co.uk>
	<3F7D31B7.7020400@hectrix.com>
	<1065171167.22491.53.camel@hades.cambridge.redhat.com>
	<3F83DCED.8090206@hectrix.com>
	<1065607132.22298.88.camel@hades.cambridge.redhat.com>
Message-ID: <3F83E3E6.3070308@hectrix.com>

On 10/08/2003 05:58 PM, David Woodhouse wrote:
> Can you throw printk statements into various routines in nftlcore.c so
> we can it actually thinks it's doing?

I will try my best to do that later.

> You _are_ mounting your file system with -onoatime, aren't you?

I compiled in the driver to the kernel and set fstab with the line:

  /dev/nftla1	/mnt/doc	auto	defaults	0 0

What do you mean by -onoatime? Should I change "defaults" to "noatime"?

Selwyn



From dwmw2 at infradead.org  Wed Oct  8 06:22:52 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 08 Oct 2003 11:22:52 +0100
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <3F83E3E6.3070308@hectrix.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	 <3F7CD9CA.5090805@hectrix.com>
	 <1065160480.16088.0.camel@imladris.demon.co.uk>
	 <3F7D31B7.7020400@hectrix.com>
	 <1065171167.22491.53.camel@hades.cambridge.redhat.com>
	 <3F83DCED.8090206@hectrix.com>
	 <1065607132.22298.88.camel@hades.cambridge.redhat.com>
	 <3F83E3E6.3070308@hectrix.com>
Message-ID: <1065608571.22298.92.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-08 at 18:16 +0800, Selwyn Tang wrote:
> I will try my best to do that later.

Thanks.

> What do you mean by -onoatime? Should I change "defaults" to "noatime"?

man 8 mount

       noatime
              Access timestamps are not updated when a file is read.
 
With atime enabled, every _read_ of a file or directory causes a write
to the flash, because the 'access timestamp' is updated.

On flash, this is a Bad Thing(tm).

-- 
dwmw2



From mdigiaco at anteon.com  Wed Oct  8 11:53:20 2003
From: mdigiaco at anteon.com (DiGiacomo, Mario)
Date: Wed, 8 Oct 2003 11:53:20 -0400
Subject: Fdisk/mount problem with DOC2000
Message-ID: <79E9503E1ABD5A479B45D36BEA17D31B093255@np-ex.anteon.com>

I'm trying to access an already-formatted 32M DOC on an AMD K6 running Linux 2.4.18 (and TrueFFS 5.1.4), and I'm having difficulty.  It _looks_ like everything is loading correctly (compiled into the kernel, not modules), but if I try to run mount or fdisk, the command hangs.
 
Any help?  I've been pounding on this for 4 days now, and people are getting antsy. :)
 
Mario Di Giacomo
Anteon, Inc.
 

From dwmw2 at infradead.org  Wed Oct  8 11:57:41 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 08 Oct 2003 16:57:41 +0100
Subject: Fdisk/mount problem with DOC2000
In-Reply-To: <79E9503E1ABD5A479B45D36BEA17D31B093255@np-ex.anteon.com>
References: <79E9503E1ABD5A479B45D36BEA17D31B093255@np-ex.anteon.com>
Message-ID: <1065628661.22298.223.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-08 at 11:53 -0400, DiGiacomo, Mario wrote:
> I'm trying to access an already-formatted 32M DOC on an AMD K6 running
> Linux 2.4.18 (and TrueFFS 5.1.4), and I'm having difficulty.  It
> _looks_ like everything is loading correctly (compiled into the
> kernel, not modules), but if I try to run mount or fdisk, the command
> hangs.

Known bug in 2.4.18. Fixed in 2.4.19 as are many other problems.

-- 
dwmw2



From selwyn at hectrix.com  Wed Oct  8 23:54:12 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Thu, 09 Oct 2003 11:54:12 +0800
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <1065608571.22298.92.camel@hades.cambridge.redhat.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	<3F7CD9CA.5090805@hectrix.com>
	<1065160480.16088.0.camel@imladris.demon.co.uk>
	<3F7D31B7.7020400@hectrix.com>
	<1065171167.22491.53.camel@hades.cambridge.redhat.com>
	<3F83DCED.8090206@hectrix.com>
	<1065607132.22298.88.camel@hades.cambridge.redhat.com>
	<3F83E3E6.3070308@hectrix.com>
	<1065608571.22298.92.camel@hades.cambridge.redhat.com>
Message-ID: <3F84DBE4.6030602@hectrix.com>

On 10/08/2003 06:22 PM, David Woodhouse wrote:
>        noatime
>               Access timestamps are not updated when a file is read.
>  
> With atime enabled, every _read_ of a file or directory causes a write
> to the flash, because the 'access timestamp' is updated.
> 
> On flash, this is a Bad Thing(tm).

I now set fstab to mount it with noatime, but it doesn't help the problem.

Besides, I added a printk to each function in nftlcore.c, printing the
name of the function when it is called, eg. "mtdcore: init_mtd". Then in
boot up, I got the followings:

/**** begin ****/
mtdcore: init_mtd
mtdcore: register_mtd_user
NFTL driver: nftlcore.c $Revision: 1.94 $, nftlmount.c $Revision: 1.34 $
DiskOnChip 2000 found at address 0xD4000
Flash chip found: Manufacturer ID: 98, Chip ID: 73 (Toshiba:NAND 16MiB 3,3V)
1 flash chips found. Total DiskOnChip size: 16 MiB
mtdcore: add_mtd_device
mtd: Giving out device 0 to DiskOnChip 2000
NFTL: add_mtd for DiskOnChip 2000
NFTL: UnitSizeFactor 0x00 detected. This violates the spec but we think
we know what it means...
 nftla: nftla1
/**** end ****/

There are only three mtdcore printk messages here: init_mtd,
register_mtd_user and add_mtd_device. Then I cat'd /proc/kmsg and ls'd
/mnt/doc. nftld immediately held all my cpu time, and /proc/kmsg didn't
give me any messages.

Where should I add printk to to get more clues?

Selwyn



From dwmw2 at infradead.org  Thu Oct  9 02:30:43 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 Oct 2003 07:30:43 +0100
Subject: high cpu usage using nftl for DOC2000
In-Reply-To: <3F84DBE4.6030602@hectrix.com>
References: <Law15-F74mSknvh7wFI000062b3@hotmail.com>
	 <3F7CD9CA.5090805@hectrix.com>
	 <1065160480.16088.0.camel@imladris.demon.co.uk>
	 <3F7D31B7.7020400@hectrix.com>
	 <1065171167.22491.53.camel@hades.cambridge.redhat.com>
	 <3F83DCED.8090206@hectrix.com>
	 <1065607132.22298.88.camel@hades.cambridge.redhat.com>
	 <3F83E3E6.3070308@hectrix.com>
	 <1065608571.22298.92.camel@hades.cambridge.redhat.com>
	 <3F84DBE4.6030602@hectrix.com>
Message-ID: <1065681043.30987.191.camel@imladris.demon.co.uk>

On Thu, 2003-10-09 at 11:54 +0800, Selwyn Tang wrote:
> Besides, I added a printk to each function in nftlcore.c, printing the
> name of the function when it is called, eg. "mtdcore: init_mtd". Then in
> boot up, I got the followings:

strcmp("nftlcore", "mtdcore");

-- 
dwmw2




From dwmw2 at redhat.com  Thu Oct  9 03:10:29 2003
From: dwmw2 at redhat.com (David Woodhouse)
Date: Thu, 09 Oct 2003 08:10:29 +0100
Subject: [ANNOUNCE] JFFS2 support for NAND flash..
Message-ID: <1065683429.30987.223.camel@imladris.demon.co.uk>

I'm happy to announce that the JFFS2 support for NAND flash has finally
reached a state in which it can be considered sane to use it in
production.

Thanks to generous sponsorship from Texas Instruments, the final
difficult parts of the NAND flash support have now been implemented.

Those were, for those who weren't paying attention, the details of
flushing the write-behind buffer appropriately upon fsync(), sync() and
other stimuli, and the code to deal with _failure_ to write the
write-behind buffer -- recovering its contents and writing them out
elsewhere on the flash to avoid data loss.

Other bugs were also found and fixed in the process of testing, and the
CVS tree also now contains changes to the garbage-collector which affect
the way it merges data nodes, which should significantly improve its
progress. These should be of benefit even on NOR flash, and may well
allow us to reduce the free-block thresholds which people keep
complaining about.

While I'm fairly confident of the behaviour and it's been stress testing
both with and without simulated errors on a DiskOnChip on my desk for
the best part of a week now, it remains relatively new code and should
therefore be treated with respect. You are advised to undertake your own
testing under your own particular usage patterns.

In addition to Texas Instruments, who kindly paid Red Hat to lock me in
a room for a few weeks with the JFFS2 code, some NAND flash and a vat of
coffee, I should also mention the efforts of Thomas Gleixner, who has
done a lot of work on JFFS2/NAND too, and also on the NAND hardware
drivers themselves. Thanks, Thomas.

-- 
dwmw2




From if at sil.at  Thu Oct  9 03:23:53 2003
From: if at sil.at (Ingo Flaschberger)
Date: Thu, 9 Oct 2003 09:23:53 +0200 (CEST)
Subject: debugging..
Message-ID: <Pine.GSO.4.56.0310090922050.17341@ikarus.sil.at>

Hey...

i have a system where i can't set the kernel command-line... searching for
"debug" about an hour did not help..(

how else could i get debugging infos (i have already modified
kernel/printk.c).

thnx & bye, Ingo

--
we own the fibre; 9.6.98 illiad


From kevinliao at iei.com.tw  Thu Oct  9 03:39:49 2003
From: kevinliao at iei.com.tw (Kevin Liao)
Date: Thu, 9 Oct 2003 15:39:49 +0800
Subject: [ANNOUNCE] JFFS2 support for NAND flash..
References: <1065683429.30987.223.camel@imladris.demon.co.uk>
Message-ID: <012c01c38e38$85298770$ab0a10ac@rdkevinliaonb>

Congratulations and thanks a lot for all your effort! Does mtd-snapshot-20031008.tar.bz2 contains all thses?

Regards,
Kevin

----- Original Message ----- 
From: "David Woodhouse" <dwmw2 at redhat.com>
To: <jffs-dev at axis.com>; <linux-mtd at lists.infradead.org>; <etux at embeddedtux.org>
Sent: Thursday, October 09, 2003 3:10 PM
Subject: [ANNOUNCE] JFFS2 support for NAND flash..


> I'm happy to announce that the JFFS2 support for NAND flash has finally
> reached a state in which it can be considered sane to use it in
> production.
> 
> Thanks to generous sponsorship from Texas Instruments, the final
> difficult parts of the NAND flash support have now been implemented.
> 
> Those were, for those who weren't paying attention, the details of
> flushing the write-behind buffer appropriately upon fsync(), sync() and
> other stimuli, and the code to deal with _failure_ to write the
> write-behind buffer -- recovering its contents and writing them out
> elsewhere on the flash to avoid data loss.
> 
> Other bugs were also found and fixed in the process of testing, and the
> CVS tree also now contains changes to the garbage-collector which affect
> the way it merges data nodes, which should significantly improve its
> progress. These should be of benefit even on NOR flash, and may well
> allow us to reduce the free-block thresholds which people keep
> complaining about.
> 
> While I'm fairly confident of the behaviour and it's been stress testing
> both with and without simulated errors on a DiskOnChip on my desk for
> the best part of a week now, it remains relatively new code and should
> therefore be treated with respect. You are advised to undertake your own
> testing under your own particular usage patterns.
> 
> In addition to Texas Instruments, who kindly paid Red Hat to lock me in
> a room for a few weeks with the JFFS2 code, some NAND flash and a vat of
> coffee, I should also mention the efforts of Thomas Gleixner, who has
> done a lot of work on JFFS2/NAND too, and also on the NAND hardware
> drivers themselves. Thanks, Thomas.
> 
> -- 
> dwmw2
> 
> 
> _______________________________________________
> etux mailing list
> etux at embeddedtux.org
> http://www.embeddedtux.org/mailman/listinfo/etux



From dwmw2 at redhat.com  Thu Oct  9 03:51:08 2003
From: dwmw2 at redhat.com (David Woodhouse)
Date: Thu, 09 Oct 2003 08:51:08 +0100
Subject: [ANNOUNCE] JFFS2 support for NAND flash..
In-Reply-To: <012c01c38e38$85298770$ab0a10ac@rdkevinliaonb>
References: <1065683429.30987.223.camel@imladris.demon.co.uk>
	 <012c01c38e38$85298770$ab0a10ac@rdkevinliaonb>
Message-ID: <1065685868.30987.262.camel@imladris.demon.co.uk>

On Thu, 2003-10-09 at 15:39 +0800, Kevin Liao wrote:
> Congratulations and thanks a lot for all your effort! Does mtd-snapshot-20031008.tar.bz2 contains all thses?

Thanks. No it doesn't, at least not entirely -- although all the NAND
wbuf handling has been there for a while, some of the tuning changes to
the GC were actually committed in the small hours of this morning. The
next snapshot will have it.

Your question was worth answering on all three lists; further followups
to only one please.

-- 
dwmw2




From gregmartin at lucent.com  Thu Oct  9 09:50:17 2003
From: gregmartin at lucent.com (Greg A. Martin)
Date: Thu, 9 Oct 2003 08:50:17 -0500
Subject: Nand Flash with 2048 Byte Page sizes
Message-ID: <000101c38e6c$469fdd40$1a53b987@na02.lucent.com>

Hi,
I haven't seen any references yet to the newer NAND devices from Samsung
that have 2048 byte
pages with 64 bytes extra data. The Part numbers are K9F1G08U0M and
K92G08U0M. These
are 1 and 2 Gbit devices with 11 bit column addresses and 16 or 17 bit page
addresses that need
two byte read commands. Any idea if support for these devices will be forth
coming soon, or do
I get to blaze a trail?

Greg



From dwmw2 at infradead.org  Thu Oct  9 10:04:48 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 Oct 2003 15:04:48 +0100
Subject: Nand Flash with 2048 Byte Page sizes
In-Reply-To: <000101c38e6c$469fdd40$1a53b987@na02.lucent.com>
References: <000101c38e6c$469fdd40$1a53b987@na02.lucent.com>
Message-ID: <1065708286.22298.1679.camel@hades.cambridge.redhat.com>

On Thu, 2003-10-09 at 08:50 -0500, Greg A. Martin wrote:
> Hi,
> I haven't seen any references yet to the newer NAND devices from
> Samsung that have 2048 byte pages with 64 bytes extra data. The Part
> numbers are K9F1G08U0M and K92G08U0M. These are 1 and 2 Gbit devices
> with 11 bit column addresses and 16 or 17 bit page addresses that need
> two byte read commands. Any idea if support for these devices will be
> forth coming soon, or do I get to blaze a trail?

You get to blaze a trail. :)

-- 
dwmw2



From eugeny.mints at auriga.ru  Thu Oct  9 11:04:27 2003
From: eugeny.mints at auriga.ru (Eugeny Mints)
Date: Thu, 9 Oct 2003 19:04:27 +0400
Subject: NAND flash
Message-ID: <5B439D84E6653F4AA2E14A5D8898A7E163D806@auriga.auriga.ru>

Hello,

Could anybody help me to solve such a problem with JFFS2 and NAND flash:
- the NAND flash Toshiba TC58256AFTI
- kernel 2.4.22 with latest MTD and JFFS2 
- handy-written miniport for the paticular flash chip

The device works OK almost in any case, but when I try to execute  while
true; do dd if=/dev/zero of=/dev/mnt/foo count=1000; done after 10-15
minutes the system hangs; I cannot login from console or via telnet, but
it is still ping'able. I tried to use YAFFS, perform dd to device itself
instead of file on the filesystem on top of flash - no hangs were
observed.

Could anybody help me, please? 
--
cheers, dmitry pervushin



From dwmw2 at infradead.org  Thu Oct  9 11:14:29 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 Oct 2003 16:14:29 +0100
Subject: NAND flash
In-Reply-To: <5B439D84E6653F4AA2E14A5D8898A7E163D806@auriga.auriga.ru>
References: <5B439D84E6653F4AA2E14A5D8898A7E163D806@auriga.auriga.ru>
Message-ID: <1065712468.22298.1835.camel@hades.cambridge.redhat.com>

On Thu, 2003-10-09 at 19:04 +0400, Eugeny Mints wrote:
> Hello,
> 
> Could anybody help me to solve such a problem with JFFS2 and NAND flash:
> - the NAND flash Toshiba TC58256AFTI
> - kernel 2.4.22 with latest MTD and JFFS2 
> - handy-written miniport for the paticular flash chip

When you say 'latest' do you really mean that? NAND flash support in
JFFS2 has changed a _lot_ in the last weeks, and even in the last few
days.

> The device works OK almost in any case, but when I try to execute  while
> true; do dd if=/dev/zero of=/dev/mnt/foo count=1000; done after 10-15
> minutes the system hangs; I cannot login from console or via telnet, but
> it is still ping'able. I tried to use YAFFS, perform dd to device itself
> instead of file on the filesystem on top of flash - no hangs were
> observed.

Use SysRq-P and/or SysRq-T to see where the kernel is stuck. IF that
doesn't work, enable CONFIG_JFFS2_FS_DEBUG=1 and 
echo > /proc/sys/kernel/printk then watch the console, and see what the
last thing it says is.

-- 
dwmw2



From Stephan.Linke at epygi.de  Thu Oct  9 11:21:52 2003
From: Stephan.Linke at epygi.de (Stephan Linke)
Date: Thu, 9 Oct 2003 17:21:52 +0200
Subject: NAND flash
In-Reply-To: <5B439D84E6653F4AA2E14A5D8898A7E163D806@auriga.auriga.ru>
Message-ID: <NGENJJFPMHGLPILEKKAMKEIBCDAA.Stephan.Linke@epygi.de>

Hi Eugeny,

maybe some problem with the flash "ready" detection?

Stephan

> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org
> [mailto:linux-mtd-bounces at lists.infradead.org]On Behalf Of Eugeny Mints
> Sent: Donnerstag, 9. Oktober 2003 17:04
> To: linux-mtd at lists.infradead.org
> Cc: Dmitry Pervushin
> Subject: NAND flash
> 
> 
> Hello,
> 
> Could anybody help me to solve such a problem with JFFS2 and NAND flash:
> - the NAND flash Toshiba TC58256AFTI
> - kernel 2.4.22 with latest MTD and JFFS2 
> - handy-written miniport for the paticular flash chip
> 
> The device works OK almost in any case, but when I try to execute  while
> true; do dd if=/dev/zero of=/dev/mnt/foo count=1000; done after 10-15
> minutes the system hangs; I cannot login from console or via telnet, but
> it is still ping'able. I tried to use YAFFS, perform dd to device itself
> instead of file on the filesystem on top of flash - no hangs were
> observed.
> 
> Could anybody help me, please? 
> --
> cheers, dmitry pervushin
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 


From slimaffi at yahoo.com  Thu Oct  9 12:33:45 2003
From: slimaffi at yahoo.com (Slim)
Date: Thu, 9 Oct 2003 09:33:45 -0700 (PDT)
Subject: redhat 9, doc 2000
In-Reply-To: <E1A6pZU-0003Bs-DJ@pentafluge.infradead.org>
Message-ID: <20031009163345.54331.qmail@web9907.mail.yahoo.com>

> The GRUB's 'e' key will allow to edit the configuration file
> in-memory.
> And the 'c' key will bring to the GRUB's shell prompt.

Didn't work for me.

> When you get to the grub shell you can do something like:
> 
> root (hd0)
> chainloader +1
> boot

Worked fine - thanks.  I'd like to incorporate the ctrl-key bypass
or better yet, have it recognize the bios setting to boot from C
instead.
 
So now I'm trying to mod the grub config on the doc, and I type:
   mount /dev/nftla /mnt/doc
and I get
   mount: /dev/nftla: unknown device
but 
   ls -l /dev/nftla
gives
   brw-r--r--   1  root     93,   0 Sep 23 10:22 /dev/nftla

I double checked the bios - it's correct.  Is the doc corrupted?
What's the reformat sequence?

Thanks,
John


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From manningc2 at actrix.gen.nz  Thu Oct  9 13:47:11 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Fri, 10 Oct 2003 06:47:11 +1300
Subject: Nand Flash with 2048 Byte Page sizes
In-Reply-To: <1065708286.22298.1679.camel@hades.cambridge.redhat.com>
References: <000101c38e6c$469fdd40$1a53b987@na02.lucent.com>
	<1065708286.22298.1679.camel@hades.cambridge.redhat.com>
Message-ID: <20031009174133.8C422474D@blood.actrix.co.nz>

On Friday 10 October 2003 03:04, David Woodhouse wrote:
> On Thu, 2003-10-09 at 08:50 -0500, Greg A. Martin wrote:
> > Hi,
> > I haven't seen any references yet to the newer NAND devices from
> > Samsung that have 2048 byte pages with 64 bytes extra data. The Part
> > numbers are K9F1G08U0M and K92G08U0M. These are 1 and 2 Gbit devices
> > with 11 bit column addresses and 16 or 17 bit page addresses that need
> > two byte read commands. Any idea if support for these devices will be
> > forth coming soon, or do I get to blaze a trail?
>
> You get to blaze a trail. :)

I'd like to suggest that when you go blaze that trail you ask guidance before 
and you go. There are many possible direction, but certain of these are more 
useful to the file systems that get to use the code.

-- Charles



From manningc2 at actrix.gen.nz  Thu Oct  9 14:01:00 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Fri, 10 Oct 2003 07:01:00 +1300
Subject: NAND flash
In-Reply-To: <NGENJJFPMHGLPILEKKAMKEIBCDAA.Stephan.Linke@epygi.de>
References: <NGENJJFPMHGLPILEKKAMKEIBCDAA.Stephan.Linke@epygi.de>
Message-ID: <20031009175522.452BB15CB9@desire.actrix.co.nz>

On Friday 10 October 2003 04:21, Stephan Linke wrote:
> Hi Eugeny,
>
> maybe some problem with the flash "ready" detection?

I do not think so since this is working fine with YAFFS which makes the same 
mtd calls as JFFS2.

Try using the newly announced JFFS2 stuff - that likely addresses some of the 
issues in previous JFFS2 releases.

-- Charles

>
> Stephan
>
> > -----Original Message-----
> > From: linux-mtd-bounces at lists.infradead.org
> > [mailto:linux-mtd-bounces at lists.infradead.org]On Behalf Of Eugeny Mints
> > Sent: Donnerstag, 9. Oktober 2003 17:04
> > To: linux-mtd at lists.infradead.org
> > Cc: Dmitry Pervushin
> > Subject: NAND flash
> >
> >
> > Hello,
> >
> > Could anybody help me to solve such a problem with JFFS2 and NAND flash:
> > - the NAND flash Toshiba TC58256AFTI
> > - kernel 2.4.22 with latest MTD and JFFS2
> > - handy-written miniport for the paticular flash chip
> >
> > The device works OK almost in any case, but when I try to execute  while
> > true; do dd if=/dev/zero of=/dev/mnt/foo count=1000; done after 10-15
> > minutes the system hangs; I cannot login from console or via telnet, but
> > it is still ping'able. I tried to use YAFFS, perform dd to device itself
> > instead of file on the filesystem on top of flash - no hangs were
> > observed.
> >
> > Could anybody help me, please?
> > --
> > cheers, dmitry pervushin
> >
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From gregmartin at lucent.com  Thu Oct  9 18:04:01 2003
From: gregmartin at lucent.com (Greg A. Martin)
Date: Thu, 9 Oct 2003 17:04:01 -0500
Subject: Nand Flash with 2048 Byte Page sizes
In-Reply-To: <20031009174133.8C422474D@blood.actrix.co.nz>
Message-ID: <000601c38eb1$3fe677d0$1a53b987@na02.lucent.com>

Thanks for suggestion (and volunteering?) to get guidance. I am in the
early stages of porting u-boot with nand support to a PowerPC 405GP
system. I am currently just trying to make sure the hardware is designed
properly.  Any suggestions are welcome. My biggest concern now (and
ignorance) is how to allocate the spare bytes for the additional ecc
required
for the larger page size. Another question I have is the current structures
(nand_chip and/or nand_flash_dev) don't seem to have enough information
about
the number of column address bytes and page address bytes that need to be
sent
to the device.


-----Original Message-----
From: Charles Manning [mailto:manningc2 at actrix.gen.nz]
Sent: Thursday, October 09, 2003 12:47 PM
To: gregmartin at lucent.com
Cc: linux-mtd at lists.infradead.org
Subject: Re: Nand Flash with 2048 Byte Page sizes


On Friday 10 October 2003 03:04, David Woodhouse wrote:
> On Thu, 2003-10-09 at 08:50 -0500, Greg A. Martin wrote:
> > Hi,
> > I haven't seen any references yet to the newer NAND devices from
> > Samsung that have 2048 byte pages with 64 bytes extra data. The Part
> > numbers are K9F1G08U0M and K92G08U0M. These are 1 and 2 Gbit devices
> > with 11 bit column addresses and 16 or 17 bit page addresses that need
> > two byte read commands. Any idea if support for these devices will be
> > forth coming soon, or do I get to blaze a trail?
>
> You get to blaze a trail. :)

I'd like to suggest that when you go blaze that trail you ask guidance
before
and you go. There are many possible direction, but certain of these are more
useful to the file systems that get to use the code.

-- Charles



From selwyn at hectrix.com  Thu Oct  9 21:40:37 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Fri, 10 Oct 2003 09:40:37 +0800
Subject: redhat 9, doc 2000
In-Reply-To: <20031009163345.54331.qmail@web9907.mail.yahoo.com>
References: <20031009163345.54331.qmail@web9907.mail.yahoo.com>
Message-ID: <3F860E15.1060008@hectrix.com>

On 10/10/2003 12:33 AM, Slim wrote:
> Worked fine - thanks.  I'd like to incorporate the ctrl-key bypass
> or better yet, have it recognize the bios setting to boot from C
> instead.

AFAIK, the ctrl-bypass is the only option to make the grub on doc return
control to the bios.

>    mount /dev/nftla /mnt/doc
> and I get
>    mount: /dev/nftla: unknown device
> but 
>    ls -l /dev/nftla
> gives
>    brw-r--r--   1  root     93,   0 Sep 23 10:22 /dev/nftla

/dev/nftla is the nftl device representing your doc, but not a
partition. You have to create a new partition on it. You may use fdisk
/dev/nftla to do create one. Suppose you only create one partition, you
will get /dev/nftla1, representing the first partition. Then, you should
use mke2fs /dev/nftla1 to create a ext-2 filesystem on it (assuming you
choose ext-2.

Selwyn



From if at sil.at  Thu Oct  9 23:13:02 2003
From: if at sil.at (Ingo Flaschberger)
Date: Fri, 10 Oct 2003 05:13:02 +0200 (CEST)
Subject: kmalloc jffs2_do_mount_fs 
Message-ID: <Pine.GSO.4.56.0310100453520.19931@ikarus.sil.at>

Hi

after 3 nights... debugging why my sharp zaurus do not boot from my
initrd.. i found:

kmalloc does not give you more than 128k (only i you "hack" it).
jffs2 with a filesystem about 40Mb need more when mounting..
to fix this.. i have luckily found a patch at the list:
http://lists.infradead.org/pipermail/linux-mtd/2002-December/006577.html

but why doe you not apply it to the source or warn because of this
"jffs2" problem???

thnx & bye, Ingo


From hek_u5 at yahoo.com  Thu Oct  9 23:32:36 2003
From: hek_u5 at yahoo.com (Kevin Kaichuan He)
Date: Thu, 9 Oct 2003 20:32:36 -0700 (PDT)
Subject: nand_scan() returns 0 even if no nand chip exists
Message-ID: <20031010033236.74060.qmail@web60301.mail.yahoo.com>

It seems to me that the nand_scan() in nand.c will return 0
even if no NAND chip is detected (CVS code on 10/09/03). This
has negative impact since my hardware specific nand driver
will assume a NAND chip is detected and go on doing 
add_mtd_partition() ...

I applied the following patch to avoid the problem, not sure
if I missed anything:

--- ./nand/nand.c       2003-10-09 19:10:05.000000000 -0700
***************
*** 1388,1394 ****
                }
        }

!       for (i=1; i < maxchips; i++) {
                this->select_chip(mtd, i);

                /* Send the command for reading device ID */
--- 1388,1396 ----
                }
        }

!       if (nand_flash_ids[i].name) {  /* Added by Kevin */
!                 /* Found NAND  */
!         for (i=1; i < maxchips; i++) {
                this->select_chip(mtd, i);

                /* Send the command for reading device ID */
***************
*** 1398,1408 ****
                if (nand_maf_id != this->read_byte(mtd) ||
                    nand_dev_id != this->read_byte(mtd))
                        break;
       }
       if (i > 1)
                printk(KERN_INFO "%d NAND chips detected\n", i);

       mtd->size = (1 << this->chipshift) /* * i when we fix the rest of the code */;

        /*
         * check ECC mode, default to software
--- 1400,1411 ----
                if (nand_maf_id != this->read_byte(mtd) ||
                    nand_dev_id != this->read_byte(mtd))
                        break;
         }
         if (i > 1)
                printk(KERN_INFO "%d NAND chips detected\n", i);

         mtd->size = (1 << this->chipshift) /* * i when we fix the rest of the code */;
+       }

        /*
         * check ECC mode, default to software


Thanks

Kevin




From hek_u5 at yahoo.com  Fri Oct 10 00:20:04 2003
From: hek_u5 at yahoo.com (Kevin Kaichuan He)
Date: Thu, 9 Oct 2003 21:20:04 -0700 (PDT)
Subject: Eraseall error on Samsung NAND Flash
Message-ID: <20031010042004.98859.qmail@web60310.mail.yahoo.com>

Hi,

I have some problems with my Samsung NAND driver. The
MTD code I used is pulled from CVS today(10/09/03) and
the kernel version is 2.4.18(mips).

This is the Samsung NAND chip detected on my board:

---
exm2402_init: allocating memory for MTD
exm2402_init: before IO-remap
exm2402_init: set this->eccmode to NAND_ECC_SOFT
NAND device: Manufacturer ID: 0xec, Chip ID: 0x75 (Samsung NAND 32MiB 3,3V)
Using static partition definition
Creating 2 MTD partitions on "NAND 32MiB 3,3V":
0x00000000-0x00c00000 : "Operational RootFS"
0x00c00000-0x01000000 : "Golden RootFS"
---

This is all MTD partitions on my board:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00010000 "Bootflash (boot)"
mtd1: 00c00000 00004000 "Operational RootFS"
mtd2: 00400000 00004000 "Golden RootFS"

----

Then when I do "eraseall -j /dev/mtd1"  (mtd1 is the 
1st partition of the Samsung NAND flash) I see the following errors
across the whole partition:


Erasing 16 Kibyte @ 0 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 4000 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 8000 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ c000 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 10000 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 14000 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 18000 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 1c000 --  0 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 20000 --  1 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 24000 --  1 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 28000 --  1 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 2c000 --  1 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 30000 --  1 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 34000 --  1 % complete.
eraseall: /dev/mtd1: MTD Erase failure: Input/output error
Erasing 16 Kibyte @ 38000 --  1 % complete

....

[continues all the way to 100% complete, each block has the
same Input/output error]

Then if I mount the partition with JFFS2 and try copying a 
file to it, it will displays the following errors.

...
Erase at 0x00bf4000 failed immediately: errno -5
Erase at 0x00bf0000 failed immediately: errno -5
Erase at 0x00bec000 failed immediately: errno -5
Erase at 0x00be8000 failed immediately: errno -5
Erase at 0x00be4000 failed immediately: errno -5
Erase at 0x00be0000 failed immediately: errno -5
Erase at 0x00bdc000 failed immediately: errno -5
Erase at 0x00bd8000 failed immediately: errno -5
Erase at 0x00bd4000 failed immediately: errno -5
....

I basically cloned the edb7312.c to make my own NAND
driver for the Samsung K9F5608U0B chip. I'm wondering
if any people have some experience with the Samsung NAND
driver to share.

Thanks a lot!

Kevin
 




From dwmw2 at infradead.org  Fri Oct 10 01:19:01 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 10 Oct 2003 06:19:01 +0100
Subject: redhat 9, doc 2000
In-Reply-To: <3F860E15.1060008@hectrix.com>
References: <20031009163345.54331.qmail@web9907.mail.yahoo.com>
	 <3F860E15.1060008@hectrix.com>
Message-ID: <1065763141.30987.315.camel@imladris.demon.co.uk>

On Fri, 2003-10-10 at 09:40 +0800, Selwyn Tang wrote:
> >    mount: /dev/nftla: unknown device
> 
> /dev/nftla is the nftl device representing your doc, but not a
> partition. You have to create a new partition on it. 

No, you don't have to. If you were going to make only one partition,
that'd just be a gratuitous waste of space -- you'd do better just to
create your file system on /dev/nftla instead.

The problem is elsewhere. Check the driver is loaded and present in
/proc/devices. Check it's actually detected the NFTL on the DiskOnChip
-- what messages did you get at boot or when you loaded the modules?

-- 
dwmw2




From dwmw2 at infradead.org  Fri Oct 10 01:46:21 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 10 Oct 2003 06:46:21 +0100
Subject: kmalloc jffs2_do_mount_fs
In-Reply-To: <Pine.GSO.4.56.0310100453520.19931@ikarus.sil.at>
References: <Pine.GSO.4.56.0310100453520.19931@ikarus.sil.at>
Message-ID: <1065764780.30987.333.camel@imladris.demon.co.uk>

On Fri, 2003-10-10 at 05:13 +0200, Ingo Flaschberger wrote:
> but why doe you not apply it to the source or warn because of this
> "jffs2" problem???

Partly because I'm unconvinced that we want to actually _use_ such a
small erasesize. It means you split far more page writes into two nodes
to avoid crossing block boundaries, and hence waste space.

I suspect the main reason Thomas objected to my original 'min 64KiB' was
because of the 5-erase-block threshold. Since I've just wound that
threshold _up_ on NAND because and it's also based in part on nr_blocks
now, we could perhaps rethink the minimum erasesize. I didn't manage to
tie him down on #mtd yesterday though.

-- 
dwmw2




From if at sil.at  Fri Oct 10 10:53:29 2003
From: if at sil.at (Ingo Flaschberger)
Date: Fri, 10 Oct 2003 16:53:29 +0200 (CEST)
Subject: kmalloc jffs2_do_mount_fs
In-Reply-To: <1065764780.30987.333.camel@imladris.demon.co.uk>
References: <Pine.GSO.4.56.0310100453520.19931@ikarus.sil.at>
 <1065764780.30987.333.camel@imladris.demon.co.uk>
Message-ID: <Pine.GSO.4.56.0310101651550.11447@ikarus.sil.at>

Hi

> On Fri, 2003-10-10 at 05:13 +0200, Ingo Flaschberger wrote:
> > but why doe you not apply it to the source or warn because of this
> > "jffs2" problem???
>
> Partly because I'm unconvinced that we want to actually _use_ such a
> small erasesize. It means you split far more page writes into two nodes
> to avoid crossing block boundaries, and hence waste space.
>
> I suspect the main reason Thomas objected to my original 'min 64KiB' was
> because of the 5-erase-block threshold. Since I've just wound that
> threshold _up_ on NAND because and it's also based in part on nr_blocks
> now, we could perhaps rethink the minimum erasesize. I didn't manage to
> tie him down on #mtd yesterday though.

i use 16k erase block size but the jffs2 partition is


From joern at wohnheim.fh-wedel.de  Fri Oct 10 13:50:41 2003
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 10 Oct 2003 19:50:41 +0200
Subject: kmalloc jffs2_do_mount_fs
In-Reply-To: <1065764780.30987.333.camel@imladris.demon.co.uk>
References: <Pine.GSO.4.56.0310100453520.19931@ikarus.sil.at>
	<1065764780.30987.333.camel@imladris.demon.co.uk>
Message-ID: <20031010175040.GA27506@wohnheim.fh-wedel.de>

On Fri, 10 October 2003 06:46:21 +0100, David Woodhouse wrote:
> 
> Partly because I'm unconvinced that we want to actually _use_ such a
> small erasesize. It means you split far more page writes into two nodes
> to avoid crossing block boundaries, and hence waste space.
> 
> I suspect the main reason Thomas objected to my original 'min 64KiB' was
> because of the 5-erase-block threshold. Since I've just wound that
> threshold _up_ on NAND because and it's also based in part on nr_blocks
> now, we could perhaps rethink the minimum erasesize. I didn't manage to
> tie him down on #mtd yesterday though.

But this is wrong (TM).  You missed at least one variable in your
equation.  Five erase blocks is quite enough for NAND, as long as you
don't have more blocks total than on a similar NOR device.  The
problems start when you have too many blocks - you need more free
blocks.

This means that you need what I tried to start with one - dynamic 1)
numbers of erase blocks and possibly dynamic block sizes as well.
Anything else may be a decent assumption for one device or another,
but not for all.

1) dynamic for compile time - it should stay static for any given
device.

J?rn

-- 
Fancy algorithms are buggier than simple ones, and they're much harder
to implement. Use simple algorithms as well as simple data structures.
-- Rob Pike


From slimaffi at yahoo.com  Fri Oct 10 16:09:28 2003
From: slimaffi at yahoo.com (Slim)
Date: Fri, 10 Oct 2003 13:09:28 -0700 (PDT)
Subject: redhat 9, doc 2000
In-Reply-To: <E1A7v07-0003hH-Sp@pentafluge.infradead.org>
Message-ID: <20031010200928.23462.qmail@web9903.mail.yahoo.com>

> The problem is elsewhere. Check the driver is loaded and present in
> /proc/devices. Check it's actually detected the NFTL on the
> DiskOnChip

Character devices:
  1 mem
  2 pty
  3 ttyp
  4 ttyS
  5 cua
  7 vcs
 10 misc
 29 fb
 36 netlink
 90 mtd
128 ptm
129 ptm
136 pts
137 pts
162 raw

Block devices:
  1 ramdisk
  2 fd
  3 ide0
  9 md
 12 unnamed
 14 unnamed
 31 mtdblock
 38 unnamed
 39 unnamed
 44 ftl
 93 nftl
 94 inftl

> -- what messages did you get at boot or when you loaded the modules?

$Id: ftl.c,v 1.52 2003/08/11 09:00:44 dwmw2 Exp $
NFTL driver: nftlcore.c $Revision: 1.94 $, nftlmount.c $Revision: 1.34
$
INFTL: inftlcore.c $Revision: 1.14 $, inftlmount.c $Revision: 1.12 $
DiskOnChip 2000 found at address 0xC8000
Flash chip found: Manufacturer ID: 98, Chip ID: 75 (Toshiba:NAND 32MiB
3,3V)
3 flash chips found. Total DiskOnChip size: 96 MiB
mtd: Giving out device 0 to DiskOnChip 2000
INFTL: could not find valid boot record?
INFTL: could not mount device
NFTL: add_mtd for DiskOnChip 2000
Could not find valid boot record
NFTL: could not mount device
ftl_cs: FTL header not found.
Ignoring DiskOnChip 2000 at 0xCA000 - already configured
Ignoring DiskOnChip 2000 at 0xCC000 - already configured
Ignoring DiskOnChip 2000 at 0xCE000 - already configured

Is the invalid boot record the problem.  This sequency only happens
after I issue the root/chainloader/boot sequence from grub.

John

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


From robin.gilks at tait.co.nz  Tue Oct 14 00:53:33 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Tue, 14 Oct 2003 17:53:33 +1300
Subject: Mount of jffs2 partition fails
Message-ID: <3F8B814D.3050408@tait.co.nz>

Greetings

I'm using mtd-snapshot-20031013, kernel 2.4.21 cross compiled from x86 
to ppc MPC8xx cpu. Mount (and other tools) are busybox-1.00pre3. The 
flash device is a M28W320CB from STMicroelectronics.

I'm hitting a problem at mount time of a jffs2 partition which is 
probably down to a configuration error but I've not been able to 
identify it (so far!!)

I've loaded a very small jffs2 image, created on the host, into flash 
and despite the errors (below) I'm able to read the contents of that 
filesystem.

First attempt...
================
/ # mount -t jffs2 /dev/mtdblock1 /mnt
/ # Erase at 0x000d0000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x000c0000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x000b0000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x000a0000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00090000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00080000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00070000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00060000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00050000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00040000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00030000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00020000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x00010000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x000f0000 failed immediately: -EROFS. Is the sector locked?
Erase at 0x000e0000 failed immediately: -EROFS. Is the sector locked?
================

Second attempt, having unlocked the flash in the bootloader (although 
I'd have thought mtd would do it!!)
================
/ # mount -t jffs2 /dev/mtdblock1 /mnt
/ # Write clean marker to block at 0x000d0000 failed: -30
Write clean marker to block at 0x000c0000 failed: -30
Write clean marker to block at 0x000b0000 failed: -30
Write clean marker to block at 0x000a0000 failed: -30
Write clean marker to block at 0x00090000 failed: -30
Write clean marker to block at 0x00080000 failed: -30
Write clean marker to block at 0x00070000 failed: -30
Write clean marker to block at 0x00060000 failed: -30
Write clean marker to block at 0x00050000 failed: -30
Write clean marker to block at 0x00040000 failed: -30
Write clean marker to block at 0x00030000 failed: -30
Write clean marker to block at 0x00020000 failed: -30
Write clean marker to block at 0x00010000 failed: -30
Write clean marker to block at 0x000f0000 failed: -30
Write clean marker to block at 0x000e0000 failed: -30
================

The relevant kernel config is as follows:
================
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=40000000
CONFIG_MTD_PHYSMAP_LEN=400000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
# CONFIG_MTD_CFI_FLAGADM is not set
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_PCMCIA is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCPROBE is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
================

The partitions reported by the proc filesystem are:
================
/ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00010000 "initrd"
mtd1: 00100000 00010000 "disk"
mtd2: 00100000 00010000 "kernel2"
mtd3: 00040000 00010000 "u-boot"
mtd4: 000c0000 00010000 "kernel"
================

and dmesg reports as follows:
no idea why its trying to load the cmdlinepart & redboot modules as they 
are not defined!!
================
physmap flash device: 400000 at 40000000
Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit mode
  Intel/Sharp Extended Query Table at 0x0035
cfi_cmdset_0001: Erase suspend on write enabled
0: offset=0x0,size=0x2000,blocks=8
1: offset=0x10000,size=0x10000,blocks=63
Using buffer write method
kmod: failed to exec /sbin/modprobe -s -k cmdlinepart, errno = 2
cmdlinepart partition parsing not available
kmod: failed to exec /sbin/modprobe -s -k RedBoot, errno = 2
RedBoot partition parsing not available
Using physmap partition definition
Creating 5 MTD partitions on "Physically mapped flash":
0x00000000-0x00100000 : "initrd"
0x00100000-0x00200000 : "disk"
0x00200000-0x00300000 : "kernel2"
0x00300000-0x00340000 : "u-boot"
0x00340000-0x00400000 : "kernel"
================

after the mount, dmesg reports
================
/ # mount -t jffs2 /dev/mtdblock1 /mnt && dmesg
erase_pending_list: 000b0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000a0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00090000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00080000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00070000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00060000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00050000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00040000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00030000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00020000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00010000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erasable_pending_wbuf_list: empty
free_list: empty
bad_list: empty
bad_used_list: empty
Pass 2 (re)starting
Pass 2: ino #1, nlink 1, ic c066f260, nodes c0670360
Pass 2: ino #2, nlink 1, ic c066f278, nodes c0670370
jffs2_dump_block_lists:
flash_size: 00100000
used_size: 00000040
dirty_size: 00000000
wasted_size: 00000000
unchecked_size: 000001f8
free_size: 000ffdc8
erasing_size: 00000000
bad_size: 00000000
sector_size: 00010000
jffs2_reserved_blocks size: 00000000
nextblock: 00000000 (used 00000040, dirty 00000000, wasted 00000000, 
unchecked 000001f8, free 0000fdc8)
gcblock: NULL
clean_list: empty
very_dirty_list: empty
dirty_list: empty
erasable_list: empty
erasing_list: empty
erase_pending_list: 000f0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000e0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000d0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000c0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000b0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000a0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00090000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00080000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00070000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00060000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00050000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00040000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00030000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00020000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00010000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erasable_pending_wbuf_list: empty
free_list: empty
bad_list: empty
bad_used_list: empty
Pass 2 complete
Pass 3: ino #1, ic c066f260, nodes c0670360
Pass 3: ino #2, ic c066f278, nodes c0670370
Pass 3 complete
jffs2_dump_block_lists:
flash_size: 00100000
used_size: 00000040
dirty_size: 00000000
wasted_size: 00000000
unchecked_size: 000001f8
free_size: 000ffdc8
erasing_size: 00000000
bad_size: 00000000
sector_size: 00010000
jffs2_reserved_blocks size: 00000000
nextblock: 00000000 (used 00000040, dirty 00000000, wasted 00000000, 
unchecked 000001f8, free 0000fdc8)
gcblock: NULL
clean_list: empty
very_dirty_list: empty
dirty_list: empty
erasable_list: empty
erasing_list: empty
erase_pending_list: 000f0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000e0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000d0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000c0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000b0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 000a0000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00090000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00080000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00070000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00060000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00050000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00040000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00030000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00020000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erase_pending_list: 00010000 (used 00000000, dirty 00000000, wasted 
00000000, unchecked 00000000, free 00010000)
erasable_pending_wbuf_list: empty
free_list: empty
bad_list: empty
bad_used_list: empty
Not rotating empty clean_list
Not rotating empty very_dirty_list
Not rotating empty dirty_list
Not rotating empty erasable_list
Rotating erase_pending_list by 1
Erase block at front of erase_pending_list is at 000d0000
Not rotating empty free_list
JFFS2 trigger levels (size 1024 KiB, block size 64 KiB, 16 blocks)
Blocks required to allow deletion:    2 (128 KiB)
Blocks required to allow writes:      3 (192 KiB)
Blocks required to quiesce GC thread: 4 (256 KiB)
Blocks required to allow GC merges:   3 (192 KiB)
Blocks required to GC bad blocks:     0 (0 KiB)
Amount of dirty space required to GC: 76021 bytes
jffs2_do_fill_super(): Getting root inode
jffs2_read_inode(): inode->i_ino == 1
jffs2_do_read_inode(): getting inocache
jffs2_get_ino_cache(): ino 1
jffs2_get_ino_cache found c0676260 for ino 1
jffs2_do_read_inode(): Got inocache at c0676260
jffs2_do_read_inode_internal(): ino #1 nlink is 1
jffs2_get_inode_nodes(): ino #1
Node at 0000000c (2) is a dirent node
Adding fd "initrd.mk", ino #2
jffs2_add_fd_to_list( c01be7d0, c068bc0c (->00000000))
Dirent "initrd.mk" (hash 0x4028c47a, ino #2
jffs2_read_inode() returning
jffs2_do_fill_super(): d_alloc_root()
JFFS2: Garbage collect thread is pid 38
thread_should_wake(): unchecked_size 504, checked_ino #0
jffs2_garbage_collect_thread(): pass
jffs2_get_ino_cache(): ino 0
jffs2_get_ino_cache found 00000000 for ino 0
jffs2_get_ino_cache(): ino 1
jffs2_get_ino_cache found c0676260 for ino 1
Skipping ino #1 already checked
jffs2_get_ino_cache(): ino 2
jffs2_get_ino_cache found c0676278 for ino 2
jffs2_garbage_collect_pass() triggering inode scan of ino#2
jffs2_do_read_inode_internal(): ino #2 nlink is 1
jffs2_get_inode_nodes(): ino #2
Node at 00000040 (0) is a data node
version 1, highest_version now 1
Marking node at 0x00000040 REF_PRISTINE
dnode @00000040: ver 1, offset 0000, dsize 03e0
jffs2_add_full_dnode_to_inode(ino #2, f c01be810, fn c0680350)
adding node 0000-03e0 @0x00000040 on flash, newfrag *c0703210
jffs2_lookup_node_frag(c01be820, 0)
Returning NULL, empty fragtree
j_a_f_d_t_f: Lookup gave no frag
Adding new frag (c0703210) at root of tree
frag 0000-03e0: 0x00000040(2) on flash (*c0703210). left (00000000), 
right (00000000), parent (00000000)
jffs2_lookup_node_frag(c01be820, 992)
Considering frag 0-992 (c0703210). left 00000000, right 00000000
Going right from frag 0-992, before the region we care about
No match. Returning frag 0,992, closest previous
Truncating fraglist to 0x000003e0 bytes
Truncating frag 0x00000000-0x000003e0
jffs2_kill_fragtree: frag at 0x0-0x3e0: node c0680350, frags 1--
thread_should_wake(): nr_free_blocks 0, nr_erasing_blocks 15, dirty_size 
0x0: no
jffs2_garbage_collect_thread sleeping...
jffs2_write_super()
thread_should_wake(): nr_free_blocks 0, nr_erasing_blocks 15, dirty_size 
0x0: no
Starting erase of pending block 0x000d0000
Freeing all node refs for eraseblock offset 0x000d0000
Erase completed successfully at 0x000d0000
Verifying erase at 0x000d0000
Writing erased marker to block at 0x000d0000
Write clean marker to block at 0x000d0000 failed: -30
Starting erase of pending block 0x000c0000
Freeing all node refs for eraseblock offset 0x000c0000
Erase completed successfully at 0x000c0000
Verifying erase at 0x000c0000
Writing erased marker to block at 0x000c0000
Write clean marker to block at 0x000c0000 failed: -30
Starting erase of pending block 0x000b0000
Freeing all node refs for eraseblock offset 0x000b0000
Erase completed successfully at 0x000b0000
Verifying erase at 0x000b0000
Writing erased marker to block at 0x000b0000
Write clean marker to block at 0x000b0000 failed: -30
....
================
the write failures repeat over time for the whole 1Mb of the partition.


-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From michael-mclellan at swsa.com.au  Tue Oct 14 01:44:27 2003
From: michael-mclellan at swsa.com.au (Michael McLellan)
Date: Tue, 14 Oct 2003 15:44:27 +1000 (EST)
Subject: DoC Grub booting problems
Message-ID: <Pine.LNX.4.53.0310141537460.12298@slop.cobalttech.com>

I've compiled grub v.0.93 with the lastest MTD patch and it pretty much
works. But it doesn't detect the DoC until I explicitly tell it its there.

Currently when it boots up it doesn't say anything about finding the DoC
and leaves me at a Grub shell prompt. If I type 'root (dc0,0)' it
comes up with the usual guff about finding the DoC and NFTL
partitions. Then I can type 'configfile /boot/grub/menu.lst' and it works
fine.

So my question is, how come it doesn't detect the DoC before searching for
the menu.lst file? So then it will boot without going to the Grub shell.

Thanks & regards, Mikey.


From dwmw2 at infradead.org  Tue Oct 14 02:04:57 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 14 Oct 2003 07:04:57 +0100
Subject: Mount of jffs2 partition fails
In-Reply-To: <3F8B814D.3050408@tait.co.nz>
References: <3F8B814D.3050408@tait.co.nz>
Message-ID: <1066111497.3172.37.camel@imladris.demon.co.uk>

On Tue, 2003-10-14 at 17:53 +0000, Robin Gilks wrote:

> / # mount -t jffs2 /dev/mtdblock1 /mnt
> Write clean marker to block at 0x000d0000 failed: -30

-30 is also -EROFS but we don't normally see it there so we don't have a
nice helpful message telling you the reason :)

I have no clue why your flash allows erases but not writes. This is a
flash hardware/driver problem, not JFFS2. Can you do more testing on the
raw /dev/mtd0 device itself using
read/write/ioctl(MEMERASE)/ioctl(MEMUNLOCK) to see what you need to do
to make it work?

-- 
dwmw2




From dwmw2 at infradead.org  Tue Oct 14 02:06:47 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 14 Oct 2003 07:06:47 +0100
Subject: DoC Grub booting problems
In-Reply-To: <Pine.LNX.4.53.0310141537460.12298@slop.cobalttech.com>
References: <Pine.LNX.4.53.0310141537460.12298@slop.cobalttech.com>
Message-ID: <1066111607.3172.40.camel@imladris.demon.co.uk>

On Tue, 2003-10-14 at 15:44 +1000, Michael McLellan wrote:
> I've compiled grub v.0.93 with the lastest MTD patch and it pretty much
> works. But it doesn't detect the DoC until I explicitly tell it its there.

I believe that's intentional; it doesn't go looking for the drive until
it's asked to access it.

> So my question is, how come it doesn't detect the DoC before searching for
> the menu.lst file? So then it will boot without going to the Grub shell.

Don't you have to tell it that the menu.lst file is on (dc0,0) (what do
you use your _other_ partitions for, btw?) to make it look there?

-- 
dwmw2




From michael-mclellan at swsa.com.au  Tue Oct 14 02:45:36 2003
From: michael-mclellan at swsa.com.au (Michael McLellan)
Date: Tue, 14 Oct 2003 16:45:36 +1000 (EST)
Subject: DoC Grub booting problems
In-Reply-To: <1066111607.3172.40.camel@imladris.demon.co.uk>
References: <Pine.LNX.4.53.0310141537460.12298@slop.cobalttech.com>
 <1066111607.3172.40.camel@imladris.demon.co.uk>
Message-ID: <Pine.LNX.4.53.0310141638470.12391@slop.cobalttech.com>

On Tue, 14 Oct 2003, David Woodhouse wrote:

> I believe that's intentional; it doesn't go looking for the drive until
> it's asked to access it.

Seems a little silly to me, grub doesn't do that when booting off a hard
disk. It would be silly if everytime you booted off a harddisk you had to
go to the grub shell and tell it where your menu.lst file is.

Besides I thought that it found the drive first using an older version of
the firmware.

> Don't you have to tell it that the menu.lst file is on (dc0,0) to make
> it look there?

Yes I do, thats the problem.

> What do you use your _other_ partitions for, btw?

The partitions are laid out like that by PeeWee linux. There is no (dc0,1)
I potentially wont partition the drive once I settle on the installation.

Cheers,
Mikey.


From dwmw2 at infradead.org  Tue Oct 14 04:32:44 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 14 Oct 2003 09:32:44 +0100
Subject: DoC Grub booting problems
In-Reply-To: <Pine.LNX.4.53.0310141638470.12391@slop.cobalttech.com>
References: <Pine.LNX.4.53.0310141537460.12298@slop.cobalttech.com>
	 <1066111607.3172.40.camel@imladris.demon.co.uk>
	 <Pine.LNX.4.53.0310141638470.12391@slop.cobalttech.com>
Message-ID: <1066120362.14783.140.camel@hades.cambridge.redhat.com>

On Tue, 2003-10-14 at 16:45 +1000, Michael McLellan wrote:
> > Don't you have to tell it that the menu.lst file is on (dc0,0) to make
> > it look there?
> 
> Yes I do, thats the problem.

Hmmm. Look at, and add more debugging to, find_config() and
try_config_partition() in stage2.c. 

Find out if they're actually being called. If not, why not -- and if so,
why aren't they finding the config file?

-- 
dwmw2



From anemo at mba.ocn.ne.jp  Tue Oct 14 10:31:56 2003
From: anemo at mba.ocn.ne.jp (Atsushi Nemoto)
Date: Tue, 14 Oct 2003 23:31:56 +0900 (JST)
Subject: [PATCH] cmdlinepart with zero offset value
Message-ID: <20031014.233156.07647021.anemo@mba.ocn.ne.jp>

I sent this patch about two month ago but no response.  I will try
again.

I found that cmdlinepart.c can not handle zero offset value correctly
(ex. "mtdparts=id:2M at 2M,2M at 0").

This is a patch to fix it.  Also I removed including asm/setup.h since
some archs do not have it.  Please review my patch and apply if no
problem.  Thank you.

--- mtd-20030811/drivers/mtd/cmdlinepart.c	Fri May 30 07:00:05 2003
+++ mtd/drivers/mtd/cmdlinepart.c	Tue Aug 12 16:35:43 2003
@@ -29,7 +29,6 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/compatmac.h>
-#include <asm/setup.h>
 #include <linux/bootmem.h>
 
 /* error message prefix */
@@ -45,6 +44,7 @@
 
 /* special size referring to all the remaining space in a partition */
 #define SIZE_REMAINING 0xffffffff
+#define OFFSET_CONTINUOUS 0xffffffff
 
 struct cmdline_mtd_partition {
 	struct cmdline_mtd_partition *next;
@@ -77,7 +77,7 @@
 {
 	struct mtd_partition *parts;
 	unsigned long size;
-	unsigned long offset = 0;
+	unsigned long offset = OFFSET_CONTINUOUS;
 	char *name;
 	int name_len;
 	unsigned char *extra_mem;
@@ -312,7 +312,7 @@
 		{
 			for(i = 0, offset = 0; i < part->num_parts; i++)
 			{
-				if (!part->parts[i].offset)
+				if (part->parts[i].offset == OFFSET_CONTINUOUS)
 				  part->parts[i].offset = offset;
 				else
 				  offset = part->parts[i].offset;
---
Atsushi Nemoto


From magnus.martensson at axis.com  Tue Oct 14 11:31:26 2003
From: magnus.martensson at axis.com (=?iso-8859-1?Q?Magnus_M=E5rtensson?=)
Date: Tue, 14 Oct 2003 17:31:26 +0200
Subject: word line disturbance
Message-ID: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>

Hi.
I had a discussion with flash manufacturer Atmel last week regarding a phenomenon that we had seen. 
The phenomenon was called "word line disturbance" and it could occur if you tried to program only ones
to a location that already contained ones. The result could be that some bit on another address got tainted. Ex
writing 0xffff to address A could result in the content on address B changing from 0xffff to 0xfffe.

Anyway I thought of a software fix to this problem. Since it is unnecessary to write
ones to a place in flash where there already are only ones and since ones is the default bit state after an erase operation you
should simply skip that write. In our case this fix has also resulted in improvement in performance since we support firmware upgrades
over ftp and the firmware image is padded with 0xffff. The patch can be seen below (diff to 2.4.22 kernel).

Regards
/Magnus 

Index: cfi_cmdset_0002.c
===================================================================
RCS file: linux/drivers/mtd/chips/cfi_cmdset_0002.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 cfi_cmdset_0002.c
--- cfi_cmdset_0002.c	17 Jun 2003 10:42:58 -0000	1.1.1.4
+++ cfi_cmdset_0002.c	14 Oct 2003 15:20:07 -0000
@@ -463,6 +463,12 @@
 	DECLARE_WAITQUEUE(wait, current);
 	int ret = 0;
 
+	/* Dont't write ones to a location that already contain ones. */	
+	if ((cfi_buswidth_is_1() && (datum == 0xff)) || 
+	    (cfi_buswidth_is_2() && (datum == 0xffff)) || 
+	    (cfi_buswidth_is_4() && (datum == 0xffffffff))) 
+		return ret;
+
  retry:
 	cfi_spin_lock(chip->mutex);
 
Index: amd_flash.c
===================================================================
RCS file: linux/drivers/mtd/chips/amd_flash.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 amd_flash.c
--- amd_flash.c	17 Jun 2003 10:42:58 -0000	1.1.1.5
+++ amd_flash.c	14 Oct 2003 15:20:07 -0000
@@ -895,6 +895,12 @@
 	int ret = 0;
 	int times_left;
 
+	/* Dont't write ones to a location that already contain ones. */
+	if (((map->buswidth == 1) && (datum == 0xff)) ||
+	    ((map->buswidth == 2) && (datum == 0xffff)) ||
+	    ((map->buswidth == 4) && (datum == 0xffffffff))) 
+		return ret;
+
 retry:
 	spin_lock_bh(chip->mutex);



From steven.scholz at imc-berlin.de  Tue Oct 14 11:46:40 2003
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 14 Oct 2003 17:46:40 +0200
Subject: word line disturbance
In-Reply-To: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
References: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
Message-ID: <3F8C1A60.5070401@imc-berlin.de>

Magnus M?rtensson wrote:

> Hi.
> I had a discussion with flash manufacturer Atmel last week regarding a phenomenon that we had seen. 
> The phenomenon was called "word line disturbance" and it could occur if you tried to program only ones
> to a location that already contained ones. The result could be that some bit on another address got tainted. Ex
> writing 0xffff to address A could result in the content on address B changing from 0xffff to 0xfffe.
> ...

Which types of flash memory are effected by this interessting "feature"?

Steven



From tharbaugh at lnxi.com  Tue Oct 14 13:31:47 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 14 Oct 2003 11:31:47 -0600
Subject: word line disturbance
In-Reply-To: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
References: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
Message-ID: <1066152707.10573.20.camel@tubarao>

On Tue, 2003-10-14 at 09:31, Magnus M?rtensson wrote:
> Hi.
> I had a discussion with flash manufacturer Atmel last week regarding
>  a phenomenon that we had seen. 
> The phenomenon was called "word line disturbance" and it could occur
>  if you tried to program only ones
> to a location that already contained ones. The result could be that
>  some bit on another address got tainted. Ex
> writing 0xffff to address A could result in the content on address B
>  changing from 0xffff to 0xfffe.

I'll add this to the list of broken flash chips.  I'm doing some major
rework of jedec_probe.c and cfi_cmdset_0002.c so that chips with
different "features" can be handled in a sane way.  What are the
identifiers of these Atmel chips and are they CFI or are they probed
with jedec_probe?

> Anyway I thought of a software fix to this problem. Since it is
>  unnecessary to write
> ones to a place in flash where there already are only ones and since
>  ones is the default bit state after an erase operation you
> should simply skip that write.

Simple enough.

>  In our case this fix has also resulted
>  in improvement in performance since we support firmware upgrades
> over ftp and the firmware image is padded with 0xffff. The patch can
>  be seen below (diff to 2.4.22 kernel).

Sounds reasonable enough to not even be a special case.  The patch makes
the assumption that there are already ones written to the address.  A
more correct method would be to read the address and compare against the
datum - if they are equal then the function should return.

I'll see about rolling this into some of the changes I'm making.  Right
now I've seen more flash chips with problems than chips that function
correctly.





From manningc2 at actrix.gen.nz  Tue Oct 14 17:39:03 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Wed, 15 Oct 2003 10:39:03 +1300
Subject: word line disturbance
In-Reply-To: <1066152707.10573.20.camel@tubarao>
References: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
	<1066152707.10573.20.camel@tubarao>
Message-ID: <20031014213315.CA9124D6D@blood.actrix.co.nz>

I'm using the flash embedded in a AT91FR4042 (single chip ARM7-based micro + 
512kB flash + 256kB RAM).  The flash is essentially an AT49xV4096A.

This device has 4 sectors: 1x16kB "boot", 2x8kB "parameter" and 1x480kB 
"application". The datasheet/appnote warns that  reprogramming the boot can 
impact other sectors. Also, reprogramming the application area  can disturb 
the parameter areas.

At first I just blew this off as just a theoretical possibility, but found 
that these disturbances do occur on a regular basis (seen on 5 out of 5 proto 
devices) - particularly upgrading the application area corrupting the 
parameter areas.

-- Charles


From michael-mclellan at swsa.com.au  Tue Oct 14 20:50:28 2003
From: michael-mclellan at swsa.com.au (Michael McLellan)
Date: Wed, 15 Oct 2003 10:50:28 +1000 (EST)
Subject: DoC Grub booting problems
In-Reply-To: <1066120362.14783.140.camel@hades.cambridge.redhat.com>
References: <Pine.LNX.4.53.0310141537460.12298@slop.cobalttech.com> 
 <1066111607.3172.40.camel@imladris.demon.co.uk> 
 <Pine.LNX.4.53.0310141638470.12391@slop.cobalttech.com>
 <1066120362.14783.140.camel@hades.cambridge.redhat.com>
Message-ID: <Pine.LNX.4.53.0310151029390.12868@slop.cobalttech.com>

OK, I've worked it out.

I forgot I had to hack the code a bit to make it compile and part of that
affected stage2 stuff. I was using grub-0.93

So I compiled against the latest CVS code and all works OK.

Thanks for your help.

Mikey.

On Tue, 14 Oct 2003, David Woodhouse wrote:

> On Tue, 2003-10-14 at 16:45 +1000, Michael McLellan wrote:
> > > Don't you have to tell it that the menu.lst file is on (dc0,0) to make
> > > it look there?
> >
> > Yes I do, thats the problem.
>
> Hmmm. Look at, and add more debugging to, find_config() and
> try_config_partition() in stage2.c.
>
> Find out if they're actually being called. If not, why not -- and if so,
> why aren't they finding the config file?
>
> --
> dwmw2
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


From alan at storlinksemi.com  Wed Oct 15 01:04:29 2003
From: alan at storlinksemi.com (Alan Shih)
Date: Tue, 14 Oct 2003 22:04:29 -0700
Subject: Exclusive lock on MTD partition?
Message-ID: <ODEIIOAOPGGCDIKEOPILOEMODNAA.alan@storlinksemi.com>

Hi all,

I was not able to find any reference in archive regarding the following:
Does the MTD partition only allow one process to write to it (in case
multiple process tries to open the same device for writing). If no such
feature exist, where would it best placed at? (in mtd open?)

Thanks in advance

Alan




From d.mueller at elsoft.ch  Wed Oct 15 03:20:14 2003
From: d.mueller at elsoft.ch (=?ISO-8859-1?Q?=22David_M=FCller_=28ELSOFT_AG=29=22?=)
Date: Wed, 15 Oct 2003 09:20:14 +0200
Subject: word line disturbance
In-Reply-To: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
References: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
Message-ID: <3F8CF52E.1050502@elsoft.ch>

Hello

Magnus M?rtensson wrote:
> Hi.
> I had a discussion with flash manufacturer Atmel last week regarding a phenomenon that we had seen. 
> The phenomenon was called "word line disturbance" and it could occur if you tried to program only ones
> to a location that already contained ones. The result could be that some bit on another address got tainted. Ex
> writing 0xffff to address A could result in the content on address B changing from 0xffff to 0xfffe.
> 

Does anybody know more about the technical background of this "it's not
a bug, it's a feature" problem? Or is it just a manager driven decision
to save some money at the wrong place?


Dave



From thomas.koeller at baslerweb.com  Wed Oct 15 06:11:29 2003
From: thomas.koeller at baslerweb.com (Thomas Koeller)
Date: Wed, 15 Oct 2003 12:11:29 +0200
Subject: [ECOS] Stress testing JFFS2
In-Reply-To: <20031008115231.7d1f012f.jani@iv.ro>
References: <1065598642.12197.6.camel@famine>
	<20031008115231.7d1f012f.jani@iv.ro>
Message-ID: <200310151211.29172.thomas.koeller@baslerweb.com>

In an attempt to understand what's really going on inside JFFS2, I
spent a day analyzing the code. Here's what I found. Please everybody
comment on this and correct any errors on my side.

- Every operation that changes the contents of the FLASH (even deleting files!)
  is performed by writing new nodes to the FLASH. Every such node is represented
  in RAM by a struct jffs2_raw_node_ref. The memory occupied by these structs
  is never freed unless the file system is unmounted or garbage collection
  takes place. Garbage collection starts when there are only five empty
  erase blocks left. Since every data node on the flash can hold at most one
  page (4KB) worth of data (uncompressed), the number of in-core instances of
  struct jffs2_raw_node_ref can grow very large. So in order to support a larger
  JFFS2 file system, an appropriate amount of RAM is absolutely required.

- The size of a single struct jffs2_raw_node_ref is 16 bytes. In ecos, these
  structs are allocated through calls to malloc(). If the underlying implementation
  is dlmalloc, as is probably the case most often, the minimum allocation size is
  24 bytes, so some memory is wasted here. A fixed-size block allocator would be
  more appropriate.

- In http://lists.infradead.org/pipermail/linux-mtd/2003-August/008372.html,
  David Woodhouse comments on this, suggesting possible improvements. I do not
  know if any work is going on to implement one of these (probably not).

When I originally decided to design my system around JFFS2 I was totally unaware
of these topics. Although everything I found is implicit in David Woodhouse's
paper 'JFFS : The Journalling Flash File System', it is not stated explicitly
anywhere, so I'm doing it here and now: Do not use large JFFS2 file systems if
RAM is a scarce resource!

tk
--------------------------------------------------

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel +49 (4102) 463-162
Fax +49 (4102) 463-239

mailto:thomas.koeller at baslerweb.com
http://www.baslerweb.com

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



From dwmw2 at infradead.org  Wed Oct 15 06:52:38 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 15 Oct 2003 11:52:38 +0100
Subject: [ECOS] Stress testing JFFS2
In-Reply-To: <200310151211.29172.thomas.koeller@baslerweb.com>
References: <1065598642.12197.6.camel@famine>
	 <20031008115231.7d1f012f.jani@iv.ro>
	 <200310151211.29172.thomas.koeller@baslerweb.com>
Message-ID: <1066215157.14783.933.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-15 at 12:11 +0200, Thomas Koeller wrote:
> In an attempt to understand what's really going on inside JFFS2, I
> spent a day analyzing the code. Here's what I found. Please everybody
> comment on this and correct any errors on my side.
> 
> - Every operation that changes the contents of the FLASH (even deleting files!)
>   is performed by writing new nodes to the FLASH. Every such node is represented
>   in RAM by a struct jffs2_raw_node_ref. The memory occupied by these structs
>   is never freed unless the file system is unmounted or garbage collection
>   takes place. Garbage collection starts when there are only five empty
>   erase blocks left. Since every data node on the flash can hold at most one
>   page (4KB) worth of data (uncompressed), the number of in-core instances of
>   struct jffs2_raw_node_ref can grow very large. So in order to support a larger
>   JFFS2 file system, an appropriate amount of RAM is absolutely required.

All correct. But you miss the observation that we also keep a
raw_node_ref around for _obsolete_ nodes, which perhaps we could avoid.
In fact, we do this because the raw_node_ref is in a singly-linked list,
and it's going to be very inefficient to remove obsoleted nodes from
that list when they become obsolete. 

Question: What is your ratio of obsolete to valid nodes, and hence what
benefit, if any, would you gain from turning the singly-linked list into
a doubly-linked list (and increasing the size of the structure by
another pointer) in order to be able to free the obsolete ones? Nobody's
ever checked, to my knowledge.

I suppose it's also possible to take the CPU-time cost of removing the
nodes even from the singly-linked list; nobody's ever done an analysis
of what this would cost either.

Look at jffs2_mark_node_obsolete and see how much time it will take to
start at jeb->first_node, walking the ->next_phys list till you find the
newly-obsoleted raw_node_ref, and free it. You also have to find the
inode number of the inode to which the node belongs (if any), by using
jffs2_raw_ref_to_inum(), and then walk _that_ list too to remove the
raw_node_ref in question.

Note that you can't actually free obsolete node refs which refer to
obsolete directory entries, because we need to keep track of them on
NAND flash. See jffs2_garbage_collect_deletion_dirent() for the gory
details.

> - The size of a single struct jffs2_raw_node_ref is 16 bytes. In ecos, these
>   structs are allocated through calls to malloc(). If the underlying implementation
>   is dlmalloc, as is probably the case most often, the minimum allocation size is
>   24 bytes, so some memory is wasted here. A fixed-size block allocator would be
>   more appropriate.

That one should be relatively easy to do. We do it in Linux already;
each object type already has its own allocation function in malloc.c

> - In http://lists.infradead.org/pipermail/linux-mtd/2003-August/008372.html,
>   David Woodhouse comments on this, suggesting possible improvements. I do not
>   know if any work is going on to implement one of these (probably not).

Omitting the 'totlen' field should be relatively simple if you're not
freeing obsolete refs. Observe that in 99% of cases, it's true that

	ref->totlen == ref_offset(ref->next_phys) - ref_offset(ref)

Make it 100% and make me believe it, and you can remove totlen from the
structure.

You do have the choice between freeing obsolete refs and the totlen
optimisation though -- obviously they don't really work together. You
could _merge_ contiguous obsolete data-node refs and free some RAM
though, while still keeping the simple way of finding totlen.

-- 
dwmw2



From thomas.koeller at baslerweb.com  Wed Oct 15 07:30:02 2003
From: thomas.koeller at baslerweb.com (Thomas Koeller)
Date: Wed, 15 Oct 2003 13:30:02 +0200
Subject: [ECOS] Stress testing JFFS2
In-Reply-To: <1066215157.14783.933.camel@hades.cambridge.redhat.com>
References: <1065598642.12197.6.camel@famine>
	<200310151211.29172.thomas.koeller@baslerweb.com>
	<1066215157.14783.933.camel@hades.cambridge.redhat.com>
Message-ID: <200310151330.02902.thomas.koeller@baslerweb.com>

Hi David,

thanks for your quick response.

> All correct. But you miss the observation that we also keep a
> raw_node_ref around for _obsolete_ nodes, which perhaps we could avoid.
> In fact, we do this because the raw_node_ref is in a singly-linked list,
> and it's going to be very inefficient to remove obsoleted nodes from
> that list when they become obsolete.

I do not think this path leads anywhere I want to go. The flash size
was chosen to meet the expected storage requirements, which means that
at some point the flash will be filled with valid data and consequently
there will be few obsoleted nodes. I expect this to be true for most
systems.

> Omitting the 'totlen' field should be relatively simple if you're not
> freeing obsolete refs. Observe that in 99% of cases, it's true that
>
> 	ref->totlen == ref_offset(ref->next_phys) - ref_offset(ref)
>
> Make it 100% and make me believe it, and you can remove totlen from the
> structure.
>

I will consider that.

tk
--------------------------------------------------

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel +49 (4102) 463-162
Fax +49 (4102) 463-239

mailto:thomas.koeller at baslerweb.com
http://www.baslerweb.com

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



From thomas.koeller at baslerweb.com  Wed Oct 15 08:58:26 2003
From: thomas.koeller at baslerweb.com (Thomas Koeller)
Date: Wed, 15 Oct 2003 14:58:26 +0200
Subject: [ECOS] Stress testing JFFS2
In-Reply-To: <20031015115257.16327.qmail@web8006.mail.in.yahoo.com>
References: <20031015115257.16327.qmail@web8006.mail.in.yahoo.com>
Message-ID: <200310151458.26409.thomas.koeller@baslerweb.com>

Dinesh Kumar wrote:
> I am newbie to JFFS2. What is the reason behind not
> freeing jffs2_raw_node_ref from RAM (even after they
> have been used)?

Their purpose is to represent physical nodes in the FLASH,
and so they must remain just as long as those.

tk
--------------------------------------------------

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel +49 (4102) 463-162
Fax +49 (4102) 463-239

mailto:thomas.koeller at baslerweb.com
http://www.baslerweb.com

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



From robin.gilks at tait.co.nz  Wed Oct 15 17:34:10 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Thu, 16 Oct 2003 10:34:10 +1300
Subject: Mount of jffs2 partition fails
In-Reply-To: <1066111497.3172.37.camel@imladris.demon.co.uk>
References: <3F8B814D.3050408@tait.co.nz>
 <1066111497.3172.37.camel@imladris.demon.co.uk>
Message-ID: <3F8DBD52.1020100@tait.co.nz>

David Woodhouse wrote:
> On Tue, 2003-10-14 at 17:53 +0000, Robin Gilks wrote:
> 
> 
>>/ # mount -t jffs2 /dev/mtdblock1 /mnt
>>Write clean marker to block at 0x000d0000 failed: -30
> 
> 
> -30 is also -EROFS but we don't normally see it there so we don't have a
> nice helpful message telling you the reason :)
> 
> I have no clue why your flash allows erases but not writes. This is a
> flash hardware/driver problem, not JFFS2. Can you do more testing on the
> raw /dev/mtd0 device itself using
> read/write/ioctl(MEMERASE)/ioctl(MEMUNLOCK) to see what you need to do
> to make it work?

I've concluded that the ST chip I'm using, although being Intel command 
set compatible, requires a different approach. That being the case I 
enabled the ST chip option and on booting I now get the following.


Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit mode
kmod: failed to exec /sbin/modprobe -s -k cfi_cmdset_0003, errno = 2
Support for command set 0003 not present
gen_probe: No supported Vendor Command Set found
kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno = 2
kmod: failed to exec /sbin/modprobe -s -k map_rom, errno = 2

The items to note here are
1. cfi_cmdset_0003 does not exist, its replaced (as far as I can see) by
cfi_cmdset_0020
2. I'm not using any modules so why is the kernel trying to load some!!
3. when I try to use the alternate Jedec probe method, I get a compile 
error in jedec_probe.c of:
jedec_probe.c:1756: error: parse error before "jedec_probe_init"
jedec_probe.c:1757: warning: return type defaults to `int'
jedec_probe.c:1762: error: parse error before "jedec_probe_exit"
jedec_probe.c:1763: warning: return type defaults to `int'
jedec_probe.c:1767: warning: type defaults to `int' in declaration of 
`module_init'
jedec_probe.c:1767: warning: parameter names (without types) in function 
declaration
jedec_probe.c:1767: warning: data definition has no type or storage class
jedec_probe.c:1768: warning: type defaults to `int' in declaration of 
`module_exit'
jedec_probe.c:1768: warning: parameter names (without types) in function 
declaration
jedec_probe.c:1768: warning: data definition has no type or storage class

I take it that the code concerned has only ever been tested as modules? 
I'll try that in the meantime but that will require major work on my 
root filesystem :-((


-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From ch at hpl.hp.com  Wed Oct 15 19:46:53 2003
From: ch at hpl.hp.com (Christopher Hoover)
Date: Wed, 15 Oct 2003 16:46:53 -0700
Subject: Regression of mtd/chips/jedec_probe.c in 2.6.0-test7
Message-ID: <000901c39376$9cb111e0$d203b60f@duckduck>


Perhaps this is already known, but it may serve as useful news to some. 

The version of mtd/chips/jedec_probe.c in 2.6.0-test7 (revision 1.29
according to $Id$) has suffered a regression.  That version fails to detect
AMD AM29LV800BB flash in 16-bit x 1 configuration.  Replacing it with
revision 1.32 from CVS or downgrading to revision 1.6 from 2.5.70-rmk1,
holding everything else constant, solves the problem.

Also, all versions of mtd/chips/jedec_probe.c need:

#include <linux/init.h>

for 2.6.0-test7.  (I cannot ssh from my current network location, otherwise
I'd make this change to CVS.)

Cheers,
-ch
ch(at)murgatroid.com
ch(at)hpl.hp.com



From ch at hpl.hp.com  Wed Oct 15 19:47:08 2003
From: ch at hpl.hp.com (Christopher Hoover)
Date: Wed, 15 Oct 2003 16:47:08 -0700
Subject: Mount of jffs2 partition fails
In-Reply-To: <3F8DBD52.1020100@tait.co.nz>
Message-ID: <000a01c39376$a5cb6460$d203b60f@duckduck>

> 3. when I try to use 
> the alternate Jedec probe method, I get a compile 
> error in jedec_probe.c of:
> jedec_probe.c:1756: error: parse error before "jedec_probe_init"
> jedec_probe.c:1757: warning: return type defaults to `int'
> [...]

Add #include <linux/init.h>.

-ch




From mad_flasher at hotmail.com  Wed Oct 15 21:54:28 2003
From: mad_flasher at hotmail.com (J B)
Date: Wed, 15 Oct 2003 20:54:28 -0500
Subject: [PATCH] cfi_cmdset_0020.c
Message-ID: <Law11-F88qfH4OWXoGR0001766a@hotmail.com>

The following patch fixes two issues with erase suspending in the chip 
driver for the STMicro Advanced Architecture chips.  The patch is against 
the latest CVS version as of 10/15.

1.  The if statement that checked FeatureSupport was incorrect.  The same 
issue was fixed a while ago in cfi_cmdset_0001.c I believe.

2.  According to the data sheet for the M58LW032A, the erase operation can 
complete in the period between issuing the suspend command and the time the 
erase controller stops.  The last part ot the patch checks the erase 
suspended bit in the status register and only sets the suspended variable if 
the bit is on.  This keeps the software state machine in sync with the 
actual state of the hardware.

I also plan on doing a patch to add support for the M58LW128A devices as 
well.  Looking at the spec sheet, they appear very similar, so it will 
probably be just a small change.

Eventually, this whole driver could probably be merged with 
cfi_cmdset_0001.c, as they are very similar.  I think that was Joern's plan 
all along, but it looks like nobody has done it yet.

Anyway, have a look and if it seems good, please apply.

Thx,
J

--- drivers/mtd/chips/cfi_cmdset_0020.c.orig	2003-10-15 20:32:20.733539872 
-0500
+++ drivers/mtd/chips/cfi_cmdset_0020.c	2003-10-15 20:23:40.657603432 -0500
@@ -262,7 +262,7 @@
	 */
	switch (chip->state) {
	case FL_ERASING:
-		if (!((struct cfi_pri_intelext *)cfi->cmdset_priv)->FeatureSupport & 2)
+		if (!(((struct cfi_pri_intelext *)cfi->cmdset_priv)->FeatureSupport & 2))
			goto sleep; /* We don't support erase suspend */

		cfi_write (map, CMD(0xb0), cmd_addr);
@@ -297,7 +297,11 @@
			spin_lock_bh(chip->mutex);
		}

-		suspended = 1;
+		/* check to see if the device really suspended.  the erase operation
+		   could have completed before the suspend could take effect */
+		if((status & (CMD(0xC0))) == (CMD(0xC0)))
+			suspended = 1;
+
		cfi_write(map, CMD(0xff), cmd_addr);
		chip->state = FL_READY;
		break;

_________________________________________________________________
Concerned that messages may bounce because your Hotmail account has exceeded 
its 2MB storage limit? Get Hotmail Extra Storage!         
http://join.msn.com/?PAGE=features/es



From dwmw2 at infradead.org  Thu Oct 16 01:31:53 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 16 Oct 2003 06:31:53 +0100
Subject: [PATCH] cfi_cmdset_0020.c
In-Reply-To: <Law11-F88qfH4OWXoGR0001766a@hotmail.com>
References: <Law11-F88qfH4OWXoGR0001766a@hotmail.com>
Message-ID: <1066282313.18189.17.camel@imladris.demon.co.uk>

On Wed, 2003-10-15 at 20:54 -0500, J B wrote:
> 2.  According to the data sheet for the M58LW032A, the erase operation can 
> complete in the period between issuing the suspend command and the time the 
> erase controller stops.  The last part ot the patch checks the erase 
> suspended bit in the status register and only sets the suspended variable if 
> the bit is on.  This keeps the software state machine in sync with the 
> actual state of the hardware.

Consider the case where you have two chips side by side on the bus. One
completes and the other doesn't; your if() statement doesn't match that
but we still needed to restart the erase.

cfi_cmdset_0001.c issues an erase resume and then a status command, to
ensure that the chip goes into status mode even if it had previously
completed the erase.

-- 
dwmw2




From dwmw2 at infradead.org  Thu Oct 16 06:25:29 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 16 Oct 2003 11:25:29 +0100
Subject: [ECOS] Stress testing JFFS2
In-Reply-To: <200310151330.02902.thomas.koeller@baslerweb.com>
References: <1065598642.12197.6.camel@famine>
	 <200310151211.29172.thomas.koeller@baslerweb.com>
	 <1066215157.14783.933.camel@hades.cambridge.redhat.com>
	 <200310151330.02902.thomas.koeller@baslerweb.com>
Message-ID: <1066299929.14783.2697.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-15 at 13:30 +0200, Thomas Koeller wrote:
> I do not think this path leads anywhere I want to go. The flash size
> was chosen to meet the expected storage requirements, which means that
> at some point the flash will be filled with valid data and consequently
> there will be few obsoleted nodes. I expect this to be true for most
> systems.

A sane observation.

> > Omitting the 'totlen' field should be relatively simple if you're not
> > freeing obsolete refs. Observe that in 99% of cases, it's true that
> >
> > 	ref->totlen == ref_offset(ref->next_phys) - ref_offset(ref)
> >
> > Make it 100% and make me believe it, and you can remove totlen from the
> > structure.
> >
> 
> I will consider that.

OK... I've made it slightly easier for you by switching all use of
'ref->totlen' to an accessor function ref_totlen(c, jeb, ref), where
'jeb' can be NULL if the caller doesn't know it -- it _can_ be
calculated in the relatively rare case that it's required, but if it's
already to hand we might as well use it.

I've written what I suspect will be the new version of that accessor
function, and included some sanity checks for it. It's in #if 0 for now
since we know it'll be broken -- look in nodelist.h. We may end up
wanting it out of line, since it's not entirely trivial.

To make it usable, we need to ensure that we have a node reference for
areas of dirty space which we've previously been ignoring -- scan.c can
no longer just skip over stuff it ignores but must allocate node
references for it, and we must allocate node references for the wasted
space at the end of eraseblocks when we've filled them _almost_ to the
end and then filed them elsewhere.

It should be relatively simple.

-- 
dwmw2



From tharbaugh at lnxi.com  Thu Oct 16 10:08:02 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 16 Oct 2003 08:08:02 -0600
Subject: Regression of mtd/chips/jedec_probe.c in 2.6.0-test7
In-Reply-To: <000901c39376$9cb111e0$d203b60f@duckduck>
References: <000901c39376$9cb111e0$d203b60f@duckduck>
Message-ID: <1066313282.10573.121.camel@tubarao>

On Wed, 2003-10-15 at 17:46, Christopher Hoover wrote:
> Perhaps this is already known, but it may serve as useful news to some. 
> 
> The version of mtd/chips/jedec_probe.c in 2.6.0-test7 (revision 1.29
> according to $Id$) has suffered a regression.  That version fails to detect
> AMD AM29LV800BB flash in 16-bit x 1 configuration.  Replacing it with
> revision 1.32 from CVS or downgrading to revision 1.6 from 2.5.70-rmk1,
> holding everything else constant, solves the problem.

Does that mean that 1.29 and 1.7 didn't work or did you just try those
versions because they were convenient for your?

> Also, all versions of mtd/chips/jedec_probe.c need:
> 
> #include <linux/init.h>

I fixed it moments before I read your email - thanks.

I'm concerned that the changes from 1.29 -> 1.33 are significant and
will meet resistance for inclusion in 2.6.0.  If you can narrow the
problem down to just a few lines that are obviously incorrect then the
patch should have a fighting chance.  There is a section that is an
obvious bug in jedec_match() that should be fixed:

@@ -1480,7 +1524,7 @@
 	DEBUG( MTD_DEBUG_LEVEL3,
 	       "MTD %s(): Check fit 0x%.8x + 0x%.8x = 0x%.8x\n",
 	       __func__, base, 1 << finfo->DevSize, base + (1 <<
finfo->DevSize) );
-	if ( base + ( 1 << finfo->DevSize ) > map->size ) {
+	if ( base + cfi->interleave * ( 1 << finfo->DevSize ) > map->size ) {
 		DEBUG( MTD_DEBUG_LEVEL3,
 		       "MTD %s(): 0x%.4x 0x%.4x %dKiB doesn't fit\n",
 		       __func__, finfo->mfr_id, finfo->dev_id,

The most likely problem, however is this chunk:

@@ -1538,10 +1582,10 @@
 	 */
 	DEBUG( MTD_DEBUG_LEVEL3, "MTD %s(): return to ID mode\n", __func__ );
 	if(cfi->addr_unlock1) {
-		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
-		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
+		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
cfi->device_type, NULL);
 	}
-	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
 	/* FIXME - should have a delay before continuing */
 
  match_done:	


Of course I can point to a few more chunks that should go into 2.6 (and
2.4 obviously), but the arguments are much weaker about why they have to
go in *now*.

If you figure out exactly what the regression is then we should lob it
at lkml.

Once again, thanks.





From manningc2 at actrix.gen.nz  Thu Oct 16 15:34:53 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Fri, 17 Oct 2003 08:34:53 +1300
Subject: word line disturbance
In-Reply-To: <3F8CF52E.1050502@elsoft.ch>
References: <3C6BEE8B5E1BAC42905A93F13004E8AB03202232@mailse01.axis.se>
	<3F8CF52E.1050502@elsoft.ch>
Message-ID: <20031016192902.9EF784FDB@blood.actrix.co.nz>

On Wednesday 15 October 2003 20:20, David M?ller (ELSOFT AG) wrote:
> Hello
>
> Magnus M?rtensson wrote:
> > Hi.
> > I had a discussion with flash manufacturer Atmel last week regarding a
> > phenomenon that we had seen. The phenomenon was called "word line
> > disturbance" and it could occur if you tried to program only ones to a
> > location that already contained ones. The result could be that some bit
> > on another address got tainted. Ex writing 0xffff to address A could
> > result in the content on address B changing from 0xffff to 0xfffe.
>
> Does anybody know more about the technical background of this "it's not
> a bug, it's a feature" problem? Or is it just a manager driven decision
> to save some money at the wrong place?
>

This is likely to be the result of a compromise to simplify the flash 
internals to save cost. Some of these compromises are acceptable for certain 
usage scenarios, but not others. Atmel do this sort of thing a lot.

Atmel design their DataFlash range of parts for data use and their other 
parts for code storage. If the problem showed up in their Dataflash parts I'd 
consider it a true bug.

-- Charles



From f.callaghan at ieee.org  Thu Oct 16 15:57:19 2003
From: f.callaghan at ieee.org (Frank R Callaghan)
Date: Thu, 16 Oct 2003 15:57:19 -0400
Subject: Help with 2.4.22 MTD driver
Message-ID: <200310161557.19824.f.callaghan@ieee.org>

Hi All,

I have been using 2.4.19 + mdt patches for sometime with no problem, now
I must switch to 2.4.22 and I have a problem with MTD 

The kernel seem to detect the chip correctly:

physmap flash device: 200000 at 9400000
 Amd/Fujitsu Extended Query Table v1.1 at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
mtd: Giving out device 0 to Physically mapped flash
Using physmap partition definition
Creating 2 MTD partitions on "Physically mapped flash":
0x00000000-0x001e0000 : "fixed_flash"
mtd: Giving out device 1 to fixed_flash
0x001e0000-0x00200000 : "BIOS-DO_NOT_TOUCH"
mtd: Giving out device 2 to BIOS-DO_NOT_TOUCH

but latter:
.......................
.......................
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001e0024: 0x7265 
id
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x001e0000 is not formatted. It will be erased
................... repeated for tree more blocks

cat /proc/mtd gives:

dev:    size   erasesize  name
mtd0: 00200000 00010000 "Physically mapped flash"
mtd1: 001e0000 00010000 "fixed_flash"
mtd2: 00020000 00010000 "BIOS-DO_NOT_TOUCH"

I'm not sure if this correct as before with 2.4.19 it looks like this

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 001e0000 00010000 "fixed_flash"
mtd1: 00020000 00010000 "BIOS-DO_NOT_TOUCH"


Now the flash file system on the partision is corrupt :(

can someone please give me a little guidance on how to find the problem ?
what other info would help ?

Thanks In Advance,

	Frank. 




From robin.gilks at tait.co.nz  Thu Oct 16 17:30:09 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Fri, 17 Oct 2003 10:30:09 +1300
Subject: Mount of jffs2 partition fails
In-Reply-To: <3F8DBD52.1020100@tait.co.nz>
References: <3F8B814D.3050408@tait.co.nz>
 <1066111497.3172.37.camel@imladris.demon.co.uk> <3F8DBD52.1020100@tait.co.nz>
Message-ID: <3F8F0DE1.9030207@tait.co.nz>

Robin Gilks wrote:
> David Woodhouse wrote:
> 
>> On Tue, 2003-10-14 at 17:53 +0000, Robin Gilks wrote:
>>
>>
>>> / # mount -t jffs2 /dev/mtdblock1 /mnt
>>> Write clean marker to block at 0x000d0000 failed: -30
>>
>>
>>
>> -30 is also -EROFS but we don't normally see it there so we don't have a
>> nice helpful message telling you the reason :)
>>
>> I have no clue why your flash allows erases but not writes. This is a
>> flash hardware/driver problem, not JFFS2. Can you do more testing on the
>> raw /dev/mtd0 device itself using
>> read/write/ioctl(MEMERASE)/ioctl(MEMUNLOCK) to see what you need to do
>> to make it work?
> 
> 
> I've concluded that the ST chip I'm using, although being Intel command 
> set compatible, requires a different approach. That being the case I 
> enabled the ST chip option and on booting I now get the following.
> 


In a message from Stuart Menefy on (CFI fixup code ref:
<20030523235020.3ca198e1.stuart.menefy at st.com>) on 24th May 2003, this 
exact problem was highlighted and is due to the ST chip not supporting 
the buffer write mode of the Intel CFI chips. I'll try applying Stuarts 
patches to 2.4.22 stock kernel and see how I get on!!

I'm still working on why the lock/unlock is operating correctly (or 
should I just unprotect the block that MTD is using in the bootstrap?)



-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From tharbaugh at lnxi.com  Thu Oct 16 11:20:08 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 16 Oct 2003 09:20:08 -0600
Subject: Mount of jffs2 partition fails
In-Reply-To: <000a01c39376$a5cb6460$d203b60f@duckduck>
References: <000a01c39376$a5cb6460$d203b60f@duckduck>
Message-ID: <1066317608.4331.3.camel@tubarao>

On Wed, 2003-10-15 at 17:47, Christopher Hoover wrote:
> > 3. when I try to use 
> > the alternate Jedec probe method, I get a compile 
> > error in jedec_probe.c of:
> > jedec_probe.c:1756: error: parse error before "jedec_probe_init"
> > jedec_probe.c:1757: warning: return type defaults to `int'
> > [...]
> 
> Add #include <linux/init.h>.

Fixed - thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031016/79c5d26b/attachment.bin 

From robin.gilks at tait.co.nz  Fri Oct 17 00:10:01 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Fri, 17 Oct 2003 17:10:01 +1300
Subject: Mount of jffs2 partition fails
In-Reply-To: <3F8F0DE1.9030207@tait.co.nz>
References: <3F8B814D.3050408@tait.co.nz>
 <1066111497.3172.37.camel@imladris.demon.co.uk> <3F8DBD52.1020100@tait.co.nz>
 <3F8F0DE1.9030207@tait.co.nz>
Message-ID: <3F8F6B99.4050906@tait.co.nz>

No more replies to myself - promise...
Patch below:-))

Robin Gilks wrote:
> 
> In a message from Stuart Menefy on (CFI fixup code ref:
> <20030523235020.3ca198e1.stuart.menefy at st.com>) on 24th May 2003, this 
> exact problem was highlighted and is due to the ST chip not supporting 
> the buffer write mode of the Intel CFI chips. I'll try applying Stuarts 
> patches to 2.4.22 stock kernel and see how I get on!!
> 
> I'm still working on why the lock/unlock is operating correctly (or 
> should I just unprotect the block that MTD is using in the bootstrap?)
> 

Looks like I was on the right lines - the fixups that Stuart introduced 
just didn't go far enough!! The m28w320cb also doesn't support buffer 
write (just like the m28w320ct doesn't) so a 2 line patch fixes it :-))

The bootloader is providing the correct unlock status of the flash over 
the partition I'm interested in so nearly all my errors have gone away. 
Just got to now work out why I get

kmod: failed to exec /sbin/modprobe -s -k cmdlinepart, errno = 2
cmdlinepart partition parsing not available
kmod: failed to exec /sbin/modprobe -s -k RedBoot, errno = 2
RedBoot partition parsing not available

at boot time when I have no modules defined in my system at all!!


-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mtd-patch
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031017/7c0ffcad/attachment.pl 

From dge at sixnetio.com  Fri Oct 17 17:39:16 2003
From: dge at sixnetio.com (Dave Ellis)
Date: Fri, 17 Oct 2003 17:39:16 -0400
Subject: kmalloc jffs2_do_mount_fs 
In-Reply-To: <Pine.GSO.4.56.0310100453520.19931@ikarus.sil.at>
Message-ID: <00512BA4F9D3D311912A009027E9B8F407E54C@nt.sixnet.com>

On Fri, 2003-10-10 at 05:13 +0200, Ingo Flaschberger wrote:
> kmalloc does not give you more than 128k (only i you "hack" it).
> jffs2 with a filesystem about 40Mb need more when mounting..
> to fix this.. i have luckily found a patch at the list:
>
http://lists.infradead.org/pipermail/linux-mtd/2002-December/006577.html

As David pointed out in his reply to my original post, the corresponding
kfree() needs to change to vfree(). I am including an updated patch
that does that. It is clean against current CVS, but I have only tested
it with my code, which is nowhere near current.

I am still using this patch since I have questions about possible
problems
with the virtual blocks. The virtual block size depends on the size of a
kernel
structure that can change and may differ for some architectures. If the
flash
is removable, it may be unusable when moved to a different system. Even
if it is not removable (mine isn't for now) a newer kernel could break
it.

It also complicates building images with mkfs.jffs2, since the block
size depends on the size of the partition. With vmalloc() I can use the
same image for any flash with the same erase size.

Also, with NAND flash, I don't see how to determine the virtual block
size when loading an image. I use U-Boot to erase the flash and load 
the image. It is not clear how the clean markers interact with virtual
blocks or what should it do when one of erase blocks in a virtual block
is bad.

Dave Ellis

diff -Naur kmalloc/build.c vmalloc/build.c
--- kmalloc/build.c	Wed Oct 15 10:03:20 2003
+++ vmalloc/build.c	Wed Oct 15 10:48:34 2003
@@ -286,7 +286,7 @@
 
 	c->free_size = c->flash_size;
 	c->nr_blocks = c->flash_size / c->sector_size;
-	c->blocks = kmalloc(sizeof(struct jffs2_eraseblock) *
c->nr_blocks, GFP_KERNEL);
+	c->blocks = vmalloc(sizeof(struct jffs2_eraseblock) *
c->nr_blocks);
 	if (!c->blocks)
 		return -ENOMEM;
 	for (i=0; i<c->nr_blocks; i++) {
@@ -325,7 +325,7 @@
 		D1(printk(KERN_DEBUG "build_fs failed\n"));
 		jffs2_free_ino_caches(c);
 		jffs2_free_raw_node_refs(c);
-		kfree(c->blocks);
+		vfree(c->blocks);
 		return -EIO;
 	}
 
diff -Naur kmalloc/fs.c vmalloc/fs.c
--- kmalloc/fs.c	Wed Oct 15 10:03:20 2003
+++ vmalloc/fs.c	Wed Oct 15 10:48:34 2003
@@ -444,8 +444,6 @@
 	 * to reduce the memorysize for c->blocks. (kmalloc allows max.
128K allocation)
 	 */
 	blocks = c->flash_size / c->mtd->erasesize;
-	while ((blocks * sizeof (struct jffs2_eraseblock)) > (128 *
1024))
-		blocks >>= 1;
 	
 	c->sector_size = c->flash_size / blocks;
 	if (c->sector_size != c->mtd->erasesize)
@@ -506,7 +504,7 @@
  out_nodes:
 	jffs2_free_ino_caches(c);
 	jffs2_free_raw_node_refs(c);
-	kfree(c->blocks);
+	vfree(c->blocks);
  out_inohash:
 	kfree(c->inocache_list);
  out_wbuf:
diff -Naur kmalloc/super-v24.c vmalloc/super-v24.c
--- kmalloc/super-v24.c	Wed Oct 15 10:03:21 2003
+++ vmalloc/super-v24.c	Wed Oct 15 10:48:34 2003
@@ -89,7 +89,7 @@
 	up(&c->alloc_sem);
 	jffs2_free_ino_caches(c);
 	jffs2_free_raw_node_refs(c);
-	kfree(c->blocks);
+	vfree(c->blocks);
 	jffs2_nand_flash_cleanup(c);
 	kfree(c->inocache_list);
 	if (c->mtd->sync)
diff -Naur kmalloc/super.c vmalloc/super.c
--- kmalloc/super.c	Wed Oct 15 10:03:21 2003
+++ vmalloc/super.c	Wed Oct 15 10:48:34 2003
@@ -264,7 +264,7 @@
 	up(&c->alloc_sem);
 	jffs2_free_ino_caches(c);
 	jffs2_free_raw_node_refs(c);
-	kfree(c->blocks);
+	vfree(c->blocks);
 	jffs2_nand_flash_cleanup(c);
 	kfree(c->inocache_list);
 	if (c->mtd->sync)
 



From mad_flasher at hotmail.com  Sat Oct 18 10:20:23 2003
From: mad_flasher at hotmail.com (J B)
Date: Sat, 18 Oct 2003 09:20:23 -0500
Subject: jffs2 fragmentation
Message-ID: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>

Ok, maybe I am just completely missing something here, but I am stumped.  I 
am running some tests (similar to the jitter tests Vipin did a long time 
ago), and I am seeing some very bad performance.   Below is a summary of 
what I am doing and what I am seeing.

I have a jffs2 filesystem that is mounted and starts out at ~87% full.  
There are various small files on there, and one big file, ~15MiB (lgood 
compression :).  Here is what I do:

rm /opt/big_file; cp /home/big_file /opt/big_file; rm /opt/big_file; cp 
/home/big_file2 /opt/big_file

/opt is the jffs2 filesystem, /home is an nfs mounted directory.  big_file 
and big_file2 are the same size, but have different content (i.e. possibly 
different compression ratios).

Normally, a rm/cp pair takes about 2 minutes on my system.  After about 10 
iterations, the copies begin to take longer, about 3-4 minutes.   After 
about 10 iterations they take upwards of 1/2 an hour.

Looking at the dirty, used, and wasted size from a df command, I see this:

<7>STATFS:
<7>flash_size: 00680000
<7>used_size: 0041afe4
<7>dirty_size: 00199d2c
<7>wasted_size: 0000012c
<7>free_size: 000cb1c4
<7>erasing_size: 00000000
<7>bad_size: 00000000
<7>sector_size: 00020000
<7>nextblock: 0x00660000
<7>gcblock: 0x000a0000

So almost 13 eraseblocks worth of dirty space (NOR flash with 128KiB 
eraseblocks).  But, there is only 1 block on the dirty_list, 6 on the 
free_list, and 44 on the clean_list.  Garbage collection is going on during 
the writes obviously, but it doesn't seem to be making any difference.  In 
fact, the dirty_size _increases_.

So here is my question:  because of the size of the file involved and the 
relative lack of free eraseblocks to start with, is it possible that the 
filesystem is so fragmented that the dirty space is spread accross many 
eraseblocks and garbage collection is incapable of actually freeing up any 
space?

That is the only conclusion I could come to.  Any thoughts would be 
appreciated.

Thx,
J

_________________________________________________________________
Want to check if your PC is virus-infected?  Get a FREE computer virus scan 
online from McAfee.    
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



From vdoukhan at cbnco.com  Sat Oct 18 14:34:13 2003
From: vdoukhan at cbnco.com (Vlad)
Date: Sat, 18 Oct 2003 14:34:13 -0400
Subject: patchin.sh and 2.4.22
Message-ID: <oprw84jbd56cx9a8@cbncitar.cbnco.com>

Hi,

For some reason 1.16 patchin.sh doesn't copy/link suspend.h into 
include/linux/ and therefore I've got a compilation error.

Cheers,
Vlad


cvs -z9 diff  "patchin.sh"
Index: patchin.sh
===================================================================
RCS file: /home/cvs/mtd/patches/patchin.sh,v
retrieving revision 1.16
diff -r1.16 patchin.sh
50c50
< FS_INC_BEL2420="jffs*.h workqueue.h z*.h rb*.h"
---
> FS_INC_BEL2420="jffs*.h workqueue.h suspend.h z*.h rb*.h"
52c52
< FS_INC_BEL25="jffs2*.h workqueue.h rb*.h"
---
> FS_INC_BEL25="jffs2*.h workqueue.h suspend.h rb*.h"


From vdoukhan at cbnco.com  Sun Oct 19 12:52:29 2003
From: vdoukhan at cbnco.com (Vlad)
Date: Sun, 19 Oct 2003 12:52:29 -0400
Subject: Two commas in cfi_cmdset_0002.c
Message-ID: <oprxauhrln6cx9a8@cbncitar.cbnco.com>


Hi,

I think you have forgotten two commas.

Cheers,
vlad

cvs -z9 diff  "cfi_cmdset_0002.c"
Index: cfi_cmdset_0002.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/chips/cfi_cmdset_0002.c,v
retrieving revision 1.89
diff -r1.89 cfi_cmdset_0002.c
371c371
< 			DEBUG(MTD_DEBUG_LEVEL1 "Using buffer write method\n" );
---
> 			DEBUG(MTD_DEBUG_LEVEL1, "Using buffer write method\n" );
374c374
< 			DEBUG(MTD_DEBUG_LEVEL1 "Using word write method\n" );
---
> 			DEBUG(MTD_DEBUG_LEVEL1, "Using word write method\n" );


From tharbaugh at lnxi.com  Fri Oct 17 16:54:58 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 17 Oct 2003 14:54:58 -0600
Subject: Concurrency erase/write on the same AMD chip with not aligned
	words
In-Reply-To: <1060078328.1717.233.camel@mhw42463>
References: <1060078328.1717.233.camel@mhw42463>
Message-ID: <1066424098.6281.15.camel@tubarao>

On Tue, 2003-08-05 at 04:12, Stefano Babic wrote:
> Hi all,
> 
> I have seen a problem when I am writing not-aligned words on AMD chips
> while on the same chip another process starts an erase procedure for
> other sectors or a different MTD device. 

Stefano,

The fix for this is in cfi_cmdset_0002.c v1.87.  I had to pick through
your patch a bit, but I think all the relevant pieces are there.  Will
you test it please?

Thanks for your help and the patch.

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031017/46f952ad/attachment.bin 

From tharbaugh at lnxi.com  Fri Oct 17 17:46:00 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 17 Oct 2003 15:46:00 -0600
Subject: [PATCH] cfi_cmdset_0002.c support for buffered mode
In-Reply-To: <2C1BAF8F8E1DD611862B0002A5D4C3FC01BC05FE@renexch3.rennes.thmulti.com>
References: 
	<2C1BAF8F8E1DD611862B0002A5D4C3FC01BC05FE@renexch3.rennes.thmulti.com>
Message-ID: <1066427159.6281.23.camel@tubarao>

On Thu, 2003-08-21 at 11:07, Fillod Stephane wrote:
> Dave,
> 
> Here is the patch for buffered mode write on Amd chips.
> I've Cc'd Thayne if anyone of you cares to commit to cvs.

I just committed your patch for buffered writes - its cfi_cmdset_0002.c
v1.89.  Please test it and let me know if it still works.

Thanks!

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031017/a6108a29/attachment.bin 

From noah at caltech.edu  Mon Oct 20 00:36:15 2003
From: noah at caltech.edu (Noah J. Misch)
Date: Sun, 19 Oct 2003 21:36:15 -0700 (PDT)
Subject: [PATCH] Remove needless and non-portable include in mtd
Message-ID: <Pine.GSO.4.58.0310171454050.13905@blinky>

Hello David,

The #include <asm/setup.h> in drivers/mtd/cmdlinepart.c does not appear to
provide any definition this file uses, and it quickly breaks builds on
architectures that lack such a header, including ia64 and sparc.

This applies to your CVS and linux-2.5 BK as of 0700 UTC 10/20/2003 and passes
an allyesconfig on (with unrelated exceptions) i386, ia64, and sparc.  I do not
have the hardware to test it further, but I think the change is straightforward.
Please let me know if you need further information.

I will probably send you at least one more MTD compatibility patch.

Thanks,
Noah

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1369  -> 1.1370
#	drivers/mtd/cmdlinepart.c	1.5     -> 1.6
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/10/16	noah at caltech.edu	1.1370
# Remove needless include of asm/setup.h in drivers/mtd/cmdlinepart.c.  This
# was breaking compilation on architectures that lack such a header.
# --------------------------------------------
#
diff -Nru a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
--- a/drivers/mtd/cmdlinepart.c	Fri Oct 17 13:40:56 2003
+++ b/drivers/mtd/cmdlinepart.c	Fri Oct 17 13:40:56 2003
@@ -28,7 +28,6 @@

 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
-#include <asm/setup.h>
 #include <linux/bootmem.h>

 /* error message prefix */



From anemo at mba.ocn.ne.jp  Mon Oct 20 10:58:42 2003
From: anemo at mba.ocn.ne.jp (Atsushi Nemoto)
Date: Mon, 20 Oct 2003 23:58:42 +0900 (JST)
Subject: [PATCH] Remove needless and non-portable include in mtd
In-Reply-To: <Pine.GSO.4.58.0310171454050.13905@blinky>
References: <Pine.GSO.4.58.0310171454050.13905@blinky>
Message-ID: <20031020.235842.126570816.anemo@mba.ocn.ne.jp>

>>>>> On Sun, 19 Oct 2003 21:36:15 -0700 (PDT), "Noah J. Misch" <noah at caltech.edu> said:

noah> The #include <asm/setup.h> in drivers/mtd/cmdlinepart.c does not
noah> appear to provide any definition this file uses, and it quickly
noah> breaks builds on architectures that lack such a header,
noah> including ia64 and sparc.

I have posted a patch including this fix to linux-mtd ML two times
(two month ago and a week ago).  My patch fixes another problem that
cmdlinepart.c can not handle zero offset value correctly
(ex. "mtdparts=id:2M at 2M,2M at 0").  Please consider applying this fix
also.  Thank you.

--- mtd-20030811/drivers/mtd/cmdlinepart.c	Fri May 30 07:00:05 2003
+++ mtd/drivers/mtd/cmdlinepart.c	Tue Aug 12 16:35:43 2003
@@ -29,7 +29,6 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/compatmac.h>
-#include <asm/setup.h>
 #include <linux/bootmem.h>
 
 /* error message prefix */
@@ -45,6 +44,7 @@
 
 /* special size referring to all the remaining space in a partition */
 #define SIZE_REMAINING 0xffffffff
+#define OFFSET_CONTINUOUS 0xffffffff
 
 struct cmdline_mtd_partition {
 	struct cmdline_mtd_partition *next;
@@ -77,7 +77,7 @@
 {
 	struct mtd_partition *parts;
 	unsigned long size;
-	unsigned long offset = 0;
+	unsigned long offset = OFFSET_CONTINUOUS;
 	char *name;
 	int name_len;
 	unsigned char *extra_mem;
@@ -312,7 +312,7 @@
 		{
 			for(i = 0, offset = 0; i < part->num_parts; i++)
 			{
-				if (!part->parts[i].offset)
+				if (part->parts[i].offset == OFFSET_CONTINUOUS)
 				  part->parts[i].offset = offset;
 				else
 				  offset = part->parts[i].offset;
---
Atsushi Nemoto


From robin.gilks at tait.co.nz  Mon Oct 20 16:49:50 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Tue, 21 Oct 2003 09:49:50 +1300
Subject: Unrequested module loading?
Message-ID: <3F944A6E.3090703@tait.co.nz>

Greetings

Any ideas why I get the following at boot time:

kmod: failed to exec /sbin/modprobe -s -k cmdlinepart, errno = 2
cmdlinepart partition parsing not available
kmod: failed to exec /sbin/modprobe -s -k RedBoot, errno = 2
RedBoot partition parsing not available

A bit odd as I have no modules defined in my system at all and the 
relevant section of the .config file says:

# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set

-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From shawn.sharp at photondynamics.com  Mon Oct 20 18:20:18 2003
From: shawn.sharp at photondynamics.com (Shawn Sharp)
Date: Mon, 20 Oct 2003 15:20:18 -0700
Subject: communication is slow
Message-ID: <F62D50EDEAC1F34AA69101426791ED2E02C2BBDB@sjo-exch-01.photondynamics.com>

All,

I have got a DOC2000 connected to a PCI slot board.  I can mount it as a
drive and see the contents of the DOC.  The problem I have is when I run
dmesg I see the MTD driver hunting for a lot of address and not finding
them.  I can connect to the drive but it is slow (About a minute or
longer to mount it).  Any Ideas 

Thanks


From tharbaugh at lnxi.com  Mon Oct 20 09:26:27 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 20 Oct 2003 07:26:27 -0600
Subject: Two commas in cfi_cmdset_0002.c
In-Reply-To: <oprxauhrln6cx9a8@cbncitar.cbnco.com>
References: <oprxauhrln6cx9a8@cbncitar.cbnco.com>
Message-ID: <1066656386.6281.36.camel@tubarao>

On Sun, 2003-10-19 at 10:52, Vlad wrote:
> Hi,
> 
> I think you have forgotten two commas.

Pesky commas!

Thanks.

<hide part="head" emotion="embarrassment"/>

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031020/06bc6632/attachment.bin 

From robin.gilks at tait.co.nz  Mon Oct 20 16:51:42 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Tue, 21 Oct 2003 09:51:42 +1300
Subject: [PATCH] Fix m28w320cb buffered write
Message-ID: <3F944ADE.70804@tait.co.nz>

Greetings

Looks like I was on the right lines - the CFI fixups that Stuart 
introduced just didn't go far enough!! The m28w320cb doesn't support 
buffered write (just like the m28w320ct doesn't) so a 2 line patch fixes 
it :-))

-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mtd-patch
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031021/c52beafe/attachment.pl 

From martin at egholm-nielsen.dk  Tue Oct 21 05:20:07 2003
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 21 Oct 2003 11:20:07 +0200
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with jffs2
Message-ID: <3F94FA47.7020805@egholm-nielsen.dk>

Hi there,

I'm attempting to mount a jffs2-filesystem on a SmartMedia card but it's 
not quite successfull (read: it doesn't work at all).
Some info:

* On startup the kernel informs me of the following:
SmartMedia card inserted.
NAND device: Manufacture ID: 0xec, Chip ID: 0x75 (Samsung KM29U256T)

* The /proc/mtd contains the following:
dev:    size   erasesize  name
mtd0: 00200000 00010000 "Physically mapped flash"
mtd1: 00840000 00000420 "Atmel AT45DB642"
mtd2: 02000000 00004000 "Samsung KM29U256T"

i.e. the flash-device I'm trying to use is "mtd2".

* Running "eraseall /dev/mtd/2" works like a charm.

* I try to create a small filesystem with the command:
  mkfs.jffs2 --eraseblock=0x4000 --pad --root=/usr/adm --output=/tmp/image

* I copied the filesystem to the device: "cp /tmp/image /dev/mtd/2"

* ...and tried to mount it: "mount -t jffs2 /dev/mtdblock/2 /mnt/mtd"
but this is where the sky falls down - I get tons of messages like the 
following:
jffs2_scan_empty(): Empty block at 0x0000001c ends at 0x00000200 (with 
0x0000000
0)! Marking dirty
<%%%% SNIP %%%%>
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased

And now I'm lost... Any ideas of how to get any further?

Regards,
  Martin Egholm Nielsen



From martin at egholm-nielsen.dk  Tue Oct 21 05:20:07 2003
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 21 Oct 2003 11:20:07 +0200
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with jffs2
Message-ID: <3F94FA47.7020805@egholm-nielsen.dk>

Hi there,

I'm attempting to mount a jffs2-filesystem on a SmartMedia card but it's 
not quite successfull (read: it doesn't work at all).
Some info:

* On startup the kernel informs me of the following:
SmartMedia card inserted.
NAND device: Manufacture ID: 0xec, Chip ID: 0x75 (Samsung KM29U256T)

* The /proc/mtd contains the following:
dev:    size   erasesize  name
mtd0: 00200000 00010000 "Physically mapped flash"
mtd1: 00840000 00000420 "Atmel AT45DB642"
mtd2: 02000000 00004000 "Samsung KM29U256T"

i.e. the flash-device I'm trying to use is "mtd2".

* Running "eraseall /dev/mtd/2" works like a charm.

* I try to create a small filesystem with the command:
  mkfs.jffs2 --eraseblock=0x4000 --pad --root=/usr/adm --output=/tmp/image

* I copied the filesystem to the device: "cp /tmp/image /dev/mtd/2"

* ...and tried to mount it: "mount -t jffs2 /dev/mtdblock/2 /mnt/mtd"
but this is where the sky falls down - I get tons of messages like the 
following:
jffs2_scan_empty(): Empty block at 0x0000001c ends at 0x00000200 (with 
0x0000000
0)! Marking dirty
<%%%% SNIP %%%%>
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased

And now I'm lost... Any ideas of how to get any further?

Regards,
  Martin Egholm Nielsen



From dwmw2 at infradead.org  Tue Oct 21 05:30:28 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 21 Oct 2003 10:30:28 +0100
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with
	jffs2
In-Reply-To: <3F94FA47.7020805@egholm-nielsen.dk>
References: <3F94FA47.7020805@egholm-nielsen.dk>
Message-ID: <1066728627.6744.1529.camel@hades.cambridge.redhat.com>

On Tue, 2003-10-21 at 11:20 +0200, Martin Egholm Nielsen wrote:
> And now I'm lost... Any ideas of how to get any further?

Can you read back the contents of the flash after writing, and compare
with the image you attempted to write?

-- 
dwmw2



From martin at egholm-nielsen.dk  Tue Oct 21 05:20:07 2003
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 21 Oct 2003 11:20:07 +0200
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with jffs2
Message-ID: <3F94FA47.7020805@egholm-nielsen.dk>

Hi there,

I'm attempting to mount a jffs2-filesystem on a SmartMedia card but it's 
not quite successfull (read: it doesn't work at all).
Some info:

* On startup the kernel informs me of the following:
SmartMedia card inserted.
NAND device: Manufacture ID: 0xec, Chip ID: 0x75 (Samsung KM29U256T)

* The /proc/mtd contains the following:
dev:    size   erasesize  name
mtd0: 00200000 00010000 "Physically mapped flash"
mtd1: 00840000 00000420 "Atmel AT45DB642"
mtd2: 02000000 00004000 "Samsung KM29U256T"

i.e. the flash-device I'm trying to use is "mtd2".

* Running "eraseall /dev/mtd/2" works like a charm.

* I try to create a small filesystem with the command:
  mkfs.jffs2 --eraseblock=0x4000 --pad --root=/usr/adm --output=/tmp/image

* I copied the filesystem to the device: "cp /tmp/image /dev/mtd/2"

* ...and tried to mount it: "mount -t jffs2 /dev/mtdblock/2 /mnt/mtd"
but this is where the sky falls down - I get tons of messages like the 
following:
jffs2_scan_empty(): Empty block at 0x0000001c ends at 0x00000200 (with 
0x0000000
0)! Marking dirty
<%%%% SNIP %%%%>
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased

And now I'm lost... Any ideas of how to get any further?

Regards,
  Martin Egholm Nielsen



From martin at egholm-nielsen.dk  Tue Oct 21 05:52:32 2003
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 21 Oct 2003 11:52:32 +0200
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with
	jffs2
In-Reply-To: <1066728627.6744.1529.camel@hades.cambridge.redhat.com>
References: <3F94FA47.7020805@egholm-nielsen.dk>
	<1066728627.6744.1529.camel@hades.cambridge.redhat.com>
Message-ID: <3F9501E0.8060904@egholm-nielsen.dk>

>>And now I'm lost... Any ideas of how to get any further?
> Can you read back the contents of the flash after writing, and compare
> with the image you attempted to write?
Heh, good point! I tried the following:

# dd if=/tmp/image of=/dev/mtd/2
32+0 records in
32+0 records out

# dd if=/dev/mtd/2 of=/tmp/copy count=32 bs=512
32+0 records in
32+0 records out

# ls -l /tmp
-rw-r--r--    1 root     root       16384 Jan  1 00:00 image
-rw-r--r--    1 root     root       16384 Jan  1 00:01 copy

# diff /tmp/image /tmp/copy
Binary files /tmp/image and /tmp/copy differ

I.e. not the same, no... You know why?

Regards,
  Martin Egholm Nielsen



From martin at egholm-nielsen.dk  Tue Oct 21 05:52:32 2003
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 21 Oct 2003 11:52:32 +0200
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with
	jffs2
In-Reply-To: <1066728627.6744.1529.camel@hades.cambridge.redhat.com>
References: <3F94FA47.7020805@egholm-nielsen.dk>
	<1066728627.6744.1529.camel@hades.cambridge.redhat.com>
Message-ID: <3F9501E0.8060904@egholm-nielsen.dk>

>>And now I'm lost... Any ideas of how to get any further?
> Can you read back the contents of the flash after writing, and compare
> with the image you attempted to write?
Heh, good point! I tried the following:

# dd if=/tmp/image of=/dev/mtd/2
32+0 records in
32+0 records out

# dd if=/dev/mtd/2 of=/tmp/copy count=32 bs=512
32+0 records in
32+0 records out

# ls -l /tmp
-rw-r--r--    1 root     root       16384 Jan  1 00:00 image
-rw-r--r--    1 root     root       16384 Jan  1 00:01 copy

# diff /tmp/image /tmp/copy
Binary files /tmp/image and /tmp/copy differ

I.e. not the same, no... You know why?

Regards,
  Martin Egholm Nielsen



From martin at egholm-nielsen.dk  Tue Oct 21 05:52:32 2003
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 21 Oct 2003 11:52:32 +0200
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with
	jffs2
In-Reply-To: <1066728627.6744.1529.camel@hades.cambridge.redhat.com>
References: <3F94FA47.7020805@egholm-nielsen.dk>
	<1066728627.6744.1529.camel@hades.cambridge.redhat.com>
Message-ID: <3F9501E0.8060904@egholm-nielsen.dk>

>>And now I'm lost... Any ideas of how to get any further?
> Can you read back the contents of the flash after writing, and compare
> with the image you attempted to write?
Heh, good point! I tried the following:

# dd if=/tmp/image of=/dev/mtd/2
32+0 records in
32+0 records out

# dd if=/dev/mtd/2 of=/tmp/copy count=32 bs=512
32+0 records in
32+0 records out

# ls -l /tmp
-rw-r--r--    1 root     root       16384 Jan  1 00:00 image
-rw-r--r--    1 root     root       16384 Jan  1 00:01 copy

# diff /tmp/image /tmp/copy
Binary files /tmp/image and /tmp/copy differ

I.e. not the same, no... You know why?

Regards,
  Martin Egholm Nielsen



From martin at egholm-nielsen.dk  Tue Oct 21 05:20:07 2003
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 21 Oct 2003 11:20:07 +0200
Subject: Mount-failure (jffs2_scan_empty()) mounting SmartMedia with jffs2
Message-ID: <3F94FA47.7020805@egholm-nielsen.dk>

Hi there,

I'm attempting to mount a jffs2-filesystem on a SmartMedia card but it's 
not quite successfull (read: it doesn't work at all).
Some info:

* On startup the kernel informs me of the following:
SmartMedia card inserted.
NAND device: Manufacture ID: 0xec, Chip ID: 0x75 (Samsung KM29U256T)

* The /proc/mtd contains the following:
dev:    size   erasesize  name
mtd0: 00200000 00010000 "Physically mapped flash"
mtd1: 00840000 00000420 "Atmel AT45DB642"
mtd2: 02000000 00004000 "Samsung KM29U256T"

i.e. the flash-device I'm trying to use is "mtd2".

* Running "eraseall /dev/mtd/2" works like a charm.

* I try to create a small filesystem with the command:
  mkfs.jffs2 --eraseblock=0x4000 --pad --root=/usr/adm --output=/tmp/image

* I copied the filesystem to the device: "cp /tmp/image /dev/mtd/2"

* ...and tried to mount it: "mount -t jffs2 /dev/mtdblock/2 /mnt/mtd"
but this is where the sky falls down - I get tons of messages like the 
following:
jffs2_scan_empty(): Empty block at 0x0000001c ends at 0x00000200 (with 
0x0000000
0)! Marking dirty
<%%%% SNIP %%%%>
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased

And now I'm lost... Any ideas of how to get any further?

Regards,
  Martin Egholm Nielsen



From hking at qualcomm.com  Tue Oct 21 20:14:24 2003
From: hking at qualcomm.com (hking)
Date: Tue, 21 Oct 2003 17:14:24 -0700
Subject: zlib compilation failed
Message-ID: <200310211714.24503.hking@qualcomm.com>

I took the most recent snap shot of mtd and tried to compile it.
It stopped at the zlib.c.  I have kernel 2.4.18.
Any clue?  Thanks.

=======================
make[2]: Entering directory `/root/CX_working_dir/mykernel/kernel/lib'
ppc_82xx-gcc -D__KERNEL__ -I/root/CX_working_dir/mykernel/kernel/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common 
-I/root/CX_working_dir/mykernel/kernel/arch/ppc -fsigned-char -msoft-float 
-pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring   
-DKBUILD_BASENAME=zlib  -DEXPORT_SYMTAB -c zlib.c
zlib.c:72: `deflate' undeclared here (not in a function)
zlib.c:72: initializer element is not constant
zlib.c:72: (near initialization for `__ksymtab_deflate.value')
zlib.c:73: `deflateInit_' undeclared here (not in a function)
zlib.c:73: initializer element is not constant
zlib.c:73: (near initialization for `__ksymtab_deflateInit_.value')
zlib.c:74: `deflateInit2_' undeclared here (not in a function)
zlib.c:74: initializer element is not constant
zlib.c:74: (near initialization for `__ksymtab_deflateInit2_.value')
zlib.c:75: `deflateEnd' undeclared here (not in a function)
zlib.c:75: initializer element is not constant
zlib.c:75: (near initialization for `__ksymtab_deflateEnd.value')
zlib.c:76: `deflateSetDictionary' undeclared here (not in a function)
zlib.c:76: initializer element is not constant
zlib.c:76: (near initialization for `__ksymtab_deflateSetDictionary.value')
zlib.c:77: `deflateCopy' undeclared here (not in a function)
zlib.c:77: initializer element is not constant
zlib.c:77: (near initialization for `__ksymtab_deflateCopy.value')
zlib.c:78: `deflateReset' undeclared here (not in a function)
zlib.c:78: initializer element is not constant
zlib.c:78: (near initialization for `__ksymtab_deflateReset.value')
zlib.c:79: `deflateParams' undeclared here (not in a function)
zlib.c:79: initializer element is not constant
zlib.c:79: (near initialization for `__ksymtab_deflateParams.value')
zlib.c:80: `deflateOutputPending' undeclared here (not in a function)
zlib.c:80: initializer element is not constant
zlib.c:80: (near initialization for `__ksymtab_deflateOutputPending.value')
zlib.c:81: `inflate' undeclared here (not in a function)
zlib.c:81: initializer element is not constant
zlib.c:81: (near initialization for `__ksymtab_inflate.value')
zlib.c:82: `inflateInit_' undeclared here (not in a function)
zlib.c:82: initializer element is not constant
zlib.c:82: (near initialization for `__ksymtab_inflateInit_.value')
zlib.c:83: `inflateInit2_' undeclared here (not in a function)
zlib.c:83: initializer element is not constant
zlib.c:83: (near initialization for `__ksymtab_inflateInit2_.value')
zlib.c:84: `inflateEnd' undeclared here (not in a function)
zlib.c:84: initializer element is not constant
zlib.c:84: (near initialization for `__ksymtab_inflateEnd.value')
zlib.c:85: `inflateSetDictionary' undeclared here (not in a function)
zlib.c:85: initializer element is not constant
zlib.c:85: (near initialization for `__ksymtab_inflateSetDictionary.value')
zlib.c:86: `inflateSync' undeclared here (not in a function)
zlib.c:86: initializer element is not constant
zlib.c:86: (near initialization for `__ksymtab_inflateSync.value')
zlib.c:87: `inflateReset' undeclared here (not in a function)
zlib.c:87: initializer element is not constant
zlib.c:87: (near initialization for `__ksymtab_inflateReset.value')
zlib.c:88: `inflateIncomp' undeclared here (not in a function)
zlib.c:88: initializer element is not constant
zlib.c:88: (near initialization for `__ksymtab_inflateIncomp.value')
zlib.c:89: `adler32' undeclared here (not in a function)
zlib.c:89: initializer element is not constant
zlib.c:89: (near initialization for `__ksymtab_adler32.value')
zlib.c:750: warning: function declaration isn't a prototype
zlib.c: In function `deflateInit_':
zlib.c:755: warning: implicit declaration of function `deflateInit2_'
zlib.c: At top level:
zlib.c:763: warning: function declaration isn't a prototype
zlib.c: In function `deflateInit2_':
zlib.c:807: structure has no member named `zalloc'
zlib.c:807: structure has no member named `opaque'
zlib.c:822: structure has no member named `zalloc'
zlib.c:822: structure has no member named `opaque'
zlib.c:823: structure has no member named `zalloc'
zlib.c:823: structure has no member named `opaque'
zlib.c:824: structure has no member named `zalloc'
zlib.c:824: structure has no member named `opaque'
zlib.c:828: structure has no member named `zalloc'
zlib.c:828: structure has no member named `opaque'
zlib.c:835: warning: implicit declaration of function `deflateEnd'
zlib.c:845: warning: implicit declaration of function `deflateReset'
zlib.c: At top level:
zlib.c:850: warning: function declaration isn't a prototype
zlib.c: In function `deflateSetDictionary':
zlib.c:865: warning: implicit declaration of function `adler32'
zlib.c: At top level:
zlib.c:893: warning: function declaration isn't a prototype
zlib.c: In function `deflateReset':
zlib.c:898: structure has no member named `zalloc'
zlib.c:898: structure has no member named `zfree'
zlib.c: At top level:
zlib.c:923: warning: function declaration isn't a prototype
zlib.c: In function `deflateParams':
zlib.c:944: warning: implicit declaration of function `deflate'
zlib.c: At top level:
zlib.c:1000: warning: function declaration isn't a prototype
zlib.c:1137: warning: function declaration isn't a prototype
zlib.c: In function `deflateEnd':
zlib.c:1152: structure has no member named `zfree'
zlib.c:1152: structure has no member named `opaque'
zlib.c:1153: structure has no member named `zfree'
zlib.c:1153: structure has no member named `opaque'
zlib.c:1154: structure has no member named `zfree'
zlib.c:1154: structure has no member named `opaque'
zlib.c:1155: structure has no member named `zfree'
zlib.c:1155: structure has no member named `opaque'
zlib.c:1157: structure has no member named `zfree'
zlib.c:1157: structure has no member named `opaque'
zlib.c: At top level:
zlib.c:1167: warning: function declaration isn't a prototype
zlib.c: In function `deflateCopy':
zlib.c:1180: structure has no member named `zalloc'
zlib.c:1180: structure has no member named `opaque'
zlib.c:1186: structure has no member named `zalloc'
zlib.c:1186: structure has no member named `opaque'
zlib.c:1187: structure has no member named `zalloc'
zlib.c:1187: structure has no member named `opaque'
zlib.c:1188: structure has no member named `zalloc'
zlib.c:1188: structure has no member named `opaque'
zlib.c:1189: structure has no member named `zalloc'
zlib.c:1189: structure has no member named `opaque'
zlib.c: At top level:
zlib.c:1219: warning: function declaration isn't a prototype
zlib.c:3116: warning: function declaration isn't a prototype
zlib.c:3132: warning: function declaration isn't a prototype
zlib.c: In function `inflateEnd':
zlib.c:3136: structure has no member named `zfree'
zlib.c:3140: structure has no member named `zfree'
zlib.c:3140: structure has no member named `opaque'
zlib.c: At top level:
zlib.c:3148: warning: function declaration isn't a prototype
zlib.c: In function `inflateInit2_':
zlib.c:3170: structure has no member named `zalloc'
zlib.c:3170: structure has no member named `opaque'
zlib.c:3192: `adler32' undeclared (first use in this function)
zlib.c:3192: (Each undeclared identifier is reported only once
zlib.c:3192: for each function it appears in.)
zlib.c: At top level:
zlib.c:3207: warning: function declaration isn't a prototype
zlib.c:3219: warning: function declaration isn't a prototype
zlib.c:3351: warning: function declaration isn't a prototype
zlib.c: In function `inflateSetDictionary':
zlib.c:3360: `adler32' used prior to declaration
zlib.c: At top level:
zlib.c:3383: warning: function declaration isn't a prototype
zlib.c:3392: warning: function declaration isn't a prototype
zlib.c: In function `inflate_blocks_reset':
zlib.c:3711: structure has no member named `zfree'
zlib.c:3711: structure has no member named `opaque'
zlib.c: In function `inflate_blocks_new':
zlib.c:3736: structure has no member named `zalloc'
zlib.c:3736: structure has no member named `opaque'
zlib.c:3738: structure has no member named `zalloc'
zlib.c:3738: structure has no member named `opaque'
zlib.c:3740: structure has no member named `zfree'
zlib.c:3740: structure has no member named `opaque'
zlib.c: In function `inflate_blocks':
zlib.c:3868: structure has no member named `zalloc'
zlib.c:3868: structure has no member named `opaque'
zlib.c:3894: structure has no member named `zfree'
zlib.c:3894: structure has no member named `opaque'
zlib.c:3933: structure has no member named `zfree'
zlib.c:3933: structure has no member named `opaque'
zlib.c:3961: structure has no member named `zfree'
zlib.c:3961: structure has no member named `opaque'
zlib.c: In function `inflate_blocks_free':
zlib.c:4032: structure has no member named `zfree'
zlib.c:4032: structure has no member named `opaque'
zlib.c:4033: structure has no member named `zfree'
zlib.c:4033: structure has no member named `opaque'
zlib.c: In function `huft_build':
zlib.c:4356: structure has no member named `zalloc'
zlib.c:4356: structure has no member named `opaque'
zlib.c: In function `inflate_trees_fixed':
zlib.c:4536: structure has no member named `zalloc'
zlib.c:4537: structure has no member named `zfree'
zlib.c:4538: structure has no member named `opaque'
zlib.c: In function `inflate_trees_free':
zlib.c:4593: structure has no member named `zfree'
zlib.c:4593: structure has no member named `opaque'
zlib.c: In function `inflate_codes_new':
zlib.c:4687: structure has no member named `zalloc'
zlib.c:4687: structure has no member named `opaque'
zlib.c: In function `inflate_codes_free':
zlib.c:4864: structure has no member named `zfree'
zlib.c:4864: structure has no member named `opaque'
zlib.c: At top level:
zlib.c:5170: warning: function declaration isn't a prototype
zlib.c:5374: warning: function declaration isn't a prototype
zlib.c:5374: `adler32' used prior to declaration
zlib.c:5374: warning: `adler32' was previously implicitly declared to return 
`int'
make[2]: *** [zlib.o] Error 1
make[2]: Leaving directory `/root/CX_working_dir/mykernel/kernel/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/root/CX_working_dir/mykernel/kernel/lib'
make: *** [_dir_lib] Error 2
-- 
Howard King L-333R
858-658-5244


From hking at qualcomm.com  Tue Oct 21 20:50:01 2003
From: hking at qualcomm.com (Howard King)
Date: Tue, 21 Oct 2003 17:50:01 -0700
Subject: mtd support for 64-bit bus
In-Reply-To: <Pine.LNX.4.44.0310031606230.29733-100000@xanadu.home>
References: <6.0.0.22.2.20031003125817.03ae9010@e2k.qualcomm.com>
 <Pine.LNX.4.44.0310031606230.29733-100000@xanadu.home>
Message-ID: <6.0.0.22.2.20031021173115.04768050@e2k.qualcomm.com>

At 01:08 PM 10/3/2003, you wrote:
>On Fri, 3 Oct 2003, Howard King wrote:
>
> > We have a customized board with 4 AMD 29L641V flash chips (4 * 8Mbyte) 
> with
> > 64-bit wide bus. The mtd driver in linux 2.4.18 kernel does not work for
> > this configuration.  Does anyone have similar experiences?  What is the
> > solution?  Thanks.
>
>Upgrade your MTD code to a more recent snapshot.
>
>
>Nicolas


I used the following commands which I found in the how-to question:

Follow the following steps:
1.Make sure that you are root.
2. cd /usr/src
3. cvs -d :pserver:anoncvs at cvs.infradead.org:/home/cvs login
(password: anoncvs)
4. cvs -d :pserver:anoncvs at cvs.infradead.org:/home/cvs co mtd
5. cd /usr/src/mtd/patches
6. sh patchin.sh -j /mykernel/kernel

== error message 1 ===
#fs/fs.o(.text+0x50eac): undefined reference to `zlib_compress'
#fs/fs.o(.text+0x50fac): undefined reference to `dynrubin_decompress'
#fs/fs.o(.text+0x50fc4): undefined reference to `zlib_decompress'

I found the zlib_.. and dynrubin_.. were added jffs2_.. prefix.  That is 
why it could not find those any more.  Since I want to use jffs2 so I 
include this flag. The -j flag is NOT in the how-to doc.  Will a newer 
kernel (2.4.20) work for this?


== error message 2 ==
#drivers/mtd/mtdlink.o(.text+0x1cc0): undefined reference to `__raw_readll'

Well, I did find that it missed raw_readll and raw_writell in 
include/linux/mtd/map.h.
Inside the map.h, it used raw_readll and raw_writell.
But I can't simply include cfi.h in map.h since cfi.h needs map.h 
definition too.
I need to add raw_readll and raw_writell definition in asm/io.h with 
raw_readl and raw_writel.
Isn't the patch supposed to work?  Did I miss something?



From sri at technovare.com  Wed Oct 22 12:08:07 2003
From: sri at technovare.com (Srikanth Sherman)
Date: Wed, 22 Oct 2003 09:08:07 -0700
Subject: Running FAT+MTD
Message-ID: <010001c398b6$aeadc740$1000a8c0@tsihq.com>

Hello,

After reading some of the old archives of the MTD list,
it looks like at least a few people have used FAT+NFTL
instead of JFFS.  The one question I have is that how do
they take care of things like wear-leveling and garbage-collection?  Aren't
they a function of JFFS or am I completely confused about MTD?  Thanks.

Sri



From manningc2 at actrix.gen.nz  Wed Oct 22 17:35:14 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Thu, 23 Oct 2003 10:35:14 +1300
Subject: Running FAT+MTD
In-Reply-To: <010001c398b6$aeadc740$1000a8c0@tsihq.com>
References: <010001c398b6$aeadc740$1000a8c0@tsihq.com>
Message-ID: <20031022212914.ABE23BD59@blood.actrix.co.nz>

On Thursday 23 October 2003 05:08, Srikanth Sherman wrote:
> Hello,
>
> After reading some of the old archives of the MTD list,
> it looks like at least a few people have used FAT+NFTL
> instead of JFFS.  The one question I have is that how do
> they take care of things like wear-leveling and garbage-collection?  Aren't
> they a function of JFFS or am I completely confused about MTD?  Thanks.
>
> Sri

First things first. ***DON'T BE TEMPTED TO DO THIS ***.

The only valid reason to use FAT is if you have removeable storage that must 
also plug into a FAT-based system.

If you use FAT:
* Your data is not safe.
* Performance goes to hell.

There are essentially two ways to implement a flash-based file system:

1) Block driver + regular file system (ext2, fat,...):
This is the approach used by SmartMedia etc. In this approach, the block 
driver tries to look like a hard disk block driver. The block driver does all 
the wear levelling etc. The file system does not know anything about flash 
and just thinks it is talking to a hard disk. To achieve this, the block 
driver needs to tell a bunch of lies and make mappings etc that are liable to 
corruption and speed issues.

2) Flash file system (eg. JFFSx, YAFFS)
These file systems know they are working with flash. They understand flash, 
know how to exploit flash and work around performance issues. Both JFFSx and 
YAFFS include some degree of journaling. They are both faster and more robust 
than equivalent FAT+block solutions.


IMHO.

-- Charles


From ch at hpl.hp.com  Wed Oct 22 18:33:24 2003
From: ch at hpl.hp.com (Christopher Hoover)
Date: Wed, 22 Oct 2003 15:33:24 -0700
Subject: Regression of mtd/chips/jedec_probe.c in 2.6.0-test7
In-Reply-To: <1066313282.10573.121.camel@tubarao>
Message-ID: <000001c398ec$81bc7020$d203b60f@duckduck>

> If you can narrow the problem down to just a few lines that 
> are obviously incorrect then the patch should have a fighting 
> chance.

Here's what I tried:

--- linux-2.6.0-test8-rmk1/drivers/mtd/chips/jedec_probe.c	2003-10-20
22:19:24.000000000 -0700
+++ linux-2.6.0-test8-rmk1-ceiva1/drivers/mtd/chips/jedec_probe.c
2003-10-22 15:24:55.000000000 -0700
@@ -1481,7 +1481,7 @@
 	DEBUG( MTD_DEBUG_LEVEL3,
 	       "MTD %s(): Check fit 0x%.8x + 0x%.8x = 0x%.8x\n",
 	       __func__, base, 1 << finfo->DevSize, base + (1 <<
finfo->DevSize) );
-	if ( base + ( 1 << finfo->DevSize ) > map->size ) {
+	if ( base + cfi->interleave * ( 1 << finfo->DevSize ) > map->size )
{
 		DEBUG( MTD_DEBUG_LEVEL3,
 		       "MTD %s(): 0x%.4x 0x%.4x %dKiB doesn't fit\n",
 		       __func__, finfo->mfr_id, finfo->dev_id,
@@ -1539,10 +1539,10 @@
 	 */
 	DEBUG( MTD_DEBUG_LEVEL3, "MTD %s(): return to ID mode\n", __func__
);
 	if(cfi->addr_unlock1) {
-		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
-		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
+		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
cfi->device_type, NULL);
 	}
-	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
 	/* FIXME - should have a delay before continuing */
 
  match_done:	

But it fails to find the chip:

Uncompressing Linux................................... done, booting the
kernel.Linux version 2.6.0-test8-rmk1-ceiva1 (ch at laptop-vmware) (gcc version
3.3.1) #33CPU: ARM720T [41807202] revision 2 (ARMv4T)
Machine: CEIVA/Polaroid Photo MAX Digital Picture Frame
Memory policy: ECC disabled, Data cache write back
On node 0 totalpages: 1024
  DMA zone: 1024 pages, LIFO batch:1
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Building zonelist for node : 0
Kernel command line: root=/dev/mtdblock3 rootfstype=cramfs console=ttyCL0
debug
Relocating machine vectors to 0xffff0000
PID hash table entries: 32 (order 5: 256 bytes)
Memory: 4MB = 4MB total
Memory: 2908KB available (921K code, 116K data, 52K init)
Calibrating delay loop... 36.76 BogoMIPS
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
Bluetooth: Core ver 2.3
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
epson1355fb: regs mapped at 0xc0800000, fb 2048 KiB mapped at 0xc0802000
epson1355fb: xres=640, yres=480, is_color=1, is_dual=1, is_tft=0
epson1355fb: bpp=16, lcd_bpp=16, crt_enabled=0, lcd_enabled=1
fb0: S1D13505 frame buffer device
Fast Floating Point Emulator V0.9 (c) Peter Teichmann.
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Serial: CLPS711x driver $Revision: 1.42 $
ttyCL0 at I/O 0x100 (irq = 12) is a CLPS711x
ttyCL1 at I/O 0x1100 (irq = 28) is a CLPS711x
Using noop io scheduler
Search for id:(01 225b) interleave(1) type(2)
Search for id:(01 225b) interleave(1) type(2)
Search for id:(70 e3a0) interleave(1) type(2)
Search for id:(01 5b) interleave(2) type(1)
Search for id:(01 5b) interleave(2) type(1)
Search for id:(70 a0) interleave(2) type(1)
Search for id:(70 f10) interleave(2) type(2)
Search for id:(70 f10) interleave(2) type(2)
Search for id:(70 f10) interleave(2) type(2)
JEDEC: Found no ceiva flash device at location zero
clps_setup_mtd: do_map_probe failed to find flash
Bluetooth: HCI UART driver ver 2.1
Bluetooth: HCI H4 protocol initialized
NET: Registered protocol family 1
Bluetooth: L2CAP ver 2.1
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.0
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
VFS: Cannot open root device "mtdblock3" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)



Is there something else you'd like me to try to narrow this down?

-ch




From ch at hpl.hp.com  Wed Oct 22 20:43:44 2003
From: ch at hpl.hp.com (Christopher Hoover)
Date: Wed, 22 Oct 2003 17:43:44 -0700
Subject: Regression of mtd/chips/jedec_probe.c in 2.6.0-test7
In-Reply-To: <1066863067.6281.197.camel@tubarao>
Message-ID: <001201c398fe$b6d567a0$d203b60f@duckduck>

> There's one more fragment where cfi->device_type should
> revert back to CFI_DEVICETYPE_X8

OK, now I'm confused.  Revert *back* to CFI_DEVICETYPE_X8?

I though we were going the other direction.

Appended is the last diff (n.b., original vs new) I tried.  It changes that
last fragment *from* CFI_DEVICETYPE_X8 *to* cfi->device_type -- it still
fails.  

The boot messages show different ids:

Search for id:(70 e3a0) interleave(1) type(2)
Search for id:(70 e3a0) interleave(1) type(2)
Search for id:(70 e3a0) interleave(1) type(2)
Search for id:(01 5b) interleave(2) type(1)
Search for id:(01 5b) interleave(2) type(1)
Search for id:(70 a0) interleave(2) type(1)
Search for id:(70 f10) interleave(2) type(2)
Search for id:(70 f10) interleave(2) type(2)
Search for id:(70 f10) interleave(2) type(2)
JEDEC: Found no ceiva flash device at location zero
clps_setup_mtd: do_map_probe failed to find flash

And before we found it fails with that last fragment left as is (i.e.
CFI_DEVICETYPE_X8).

-ch


--- linux-2.6.0-test8-rmk1/drivers/mtd/chips/jedec_probe.c	2003-10-20
22:19:24.000000000 -0700
+++ linux-2.6.0-test8-rmk1-ceiva1/drivers/mtd/chips/jedec_probe.c
2003-10-22 17:26:35.000000000 -0700
@@ -1481,7 +1481,7 @@
 	DEBUG( MTD_DEBUG_LEVEL3,
 	       "MTD %s(): Check fit 0x%.8x + 0x%.8x = 0x%.8x\n",
 	       __func__, base, 1 << finfo->DevSize, base + (1 <<
finfo->DevSize) );
-	if ( base + ( 1 << finfo->DevSize ) > map->size ) {
+	if ( base + cfi->interleave * ( 1 << finfo->DevSize ) > map->size )
{
 		DEBUG( MTD_DEBUG_LEVEL3,
 		       "MTD %s(): 0x%.4x 0x%.4x %dKiB doesn't fit\n",
 		       __func__, finfo->mfr_id, finfo->dev_id,
@@ -1539,10 +1539,10 @@
 	 */
 	DEBUG( MTD_DEBUG_LEVEL3, "MTD %s(): return to ID mode\n", __func__
);
 	if(cfi->addr_unlock1) {
-		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
-		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
+		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
cfi->device_type, NULL);
 	}
-	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
 	/* FIXME - should have a delay before continuing */
 
  match_done:	
@@ -1614,10 +1614,10 @@
 
 	/* Autoselect Mode */
 	if(cfi->addr_unlock1) {
-		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
-		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
+		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
cfi->device_type, NULL);
 	}
-	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
 	/* FIXME - should have a delay before continuing */
 
 	if (!cfi->numchips) {



From tharbaugh at lnxi.com  Wed Oct 22 14:28:26 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 22 Oct 2003 12:28:26 -0600
Subject: Huge cfi_cmdset_0002 changes
Message-ID: <1066847305.6281.170.camel@tubarao>

I just committed some major changes to cfi_cmdset_0002:

* removed *_onesize() functions - they didnt optimize that much
  and only increased code size and maintenance overhead.

* added lock/unlock functions - these likely only work on a very
  narrow set of chips, but it gives a place to start.

* made more similar to cfi_cmdset_0001 - helps cross-maintenance
  and understanding.

* do_write_oneword() checks for a NOP before writing - *huge*
  speedup and avoids some buggy chip behavior.

* revised some comments for better readability and understanding.

* likely some other subtle changes.

I'd like to request that those with buffered writes and
erase-suspend/write applications give this a try and see if I've
horribly broken anything.

Thanks for your patience and bug reports.

PS.  I think by now I have all of the submitted patches *finally* rolled
in.  If you have a patch that isn't in the latest version then let me
know!

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031022/e2365900/attachment.bin 

From tharbaugh at lnxi.com  Wed Oct 22 18:51:08 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 22 Oct 2003 16:51:08 -0600
Subject: Regression of mtd/chips/jedec_probe.c in 2.6.0-test7
In-Reply-To: <000001c398ec$81bc7020$d203b60f@duckduck>
References: <000001c398ec$81bc7020$d203b60f@duckduck>
Message-ID: <1066863067.6281.197.camel@tubarao>

On Wed, 2003-10-22 at 16:33, Christopher Hoover wrote:
> > If you can narrow the problem down to just a few lines that 
> > are obviously incorrect then the patch should have a fighting 
> > chance.
> 
> Here's what I tried:
> 
> --- linux-2.6.0-test8-rmk1/drivers/mtd/chips/jedec_probe.c	2003-10-20
> 22:19:24.000000000 -0700
> +++ linux-2.6.0-test8-rmk1-ceiva1/drivers/mtd/chips/jedec_probe.c
> 2003-10-22 15:24:55.000000000 -0700
> @@ -1481,7 +1481,7 @@
>  	DEBUG( MTD_DEBUG_LEVEL3,
>  	       "MTD %s(): Check fit 0x%.8x + 0x%.8x = 0x%.8x\n",
>  	       __func__, base, 1 << finfo->DevSize, base + (1 <<
> finfo->DevSize) );
> -	if ( base + ( 1 << finfo->DevSize ) > map->size ) {
> +	if ( base + cfi->interleave * ( 1 << finfo->DevSize ) > map->size )
> {
>  		DEBUG( MTD_DEBUG_LEVEL3,
>  		       "MTD %s(): 0x%.4x 0x%.4x %dKiB doesn't fit\n",
>  		       __func__, finfo->mfr_id, finfo->dev_id,

This is needed.

> @@ -1539,10 +1539,10 @@
>  	 */
>  	DEBUG( MTD_DEBUG_LEVEL3, "MTD %s(): return to ID mode\n", __func__
> );
>  	if(cfi->addr_unlock1) {
> -		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
> CFI_DEVICETYPE_X8, NULL);
> -		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
> CFI_DEVICETYPE_X8, NULL);
> +		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
> cfi->device_type, NULL);
> +		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
> cfi->device_type, NULL);
>  	}
> -	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
> CFI_DEVICETYPE_X8, NULL);
> +	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
> cfi->device_type, NULL);
>  	/* FIXME - should have a delay before continuing */
>  
>   match_done:	

There's one more fragment where cfi->device_type should revert back to
CFI_DEVICETYPE_X8

@@ -1674,10 +1674,10 @@
 
 	/* Autoselect Mode */
 	if(cfi->addr_unlock1) {
-		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
-		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
cfi->device_type, NULL);
+		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
+		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
 	}
-	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi,
CFI_DEVICETYPE_X8, NULL);
 	/* FIXME - should have a delay before continuing */
 
 	if (!cfi->numchips) {


Let me know if this fixes it.

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031022/c7758da9/attachment.bin 

From ahennessy at mvista.com  Wed Oct 22 17:44:56 2003
From: ahennessy at mvista.com (Alice Hennessy)
Date: Wed, 22 Oct 2003 14:44:56 -0700
Subject: TX49 NAND supported?
Message-ID: <3F96FA57.470FECC7@mvista.com>

Hi,

I have the 2 files ready that support nand on
the TX4938 and TX4925 boards.  I sent them previously but they got hung
up on the way to the mailing list
(too big?)   Anyway,  I've made some improvements.  There is also a
small change in nand.c to add
a missing case statement.

Alice
-------------- next part --------------
--- drivers/mtd/nand/nand.c	Wed Jul 23 07:23:15 2003
+++ /home/ahennessy/build/mvl-humboldt-tx4938/linux/drivers/mtd/nand/nand.c	Wed Oct 22 14:24:21 2003
@@ -1414,6 +1414,7 @@
 	switch (this->eccmode) {
 
 	case NAND_ECC_HW3_512: 
+	case NAND_ECC_HW6_512: 
 		if (mtd->oobblock == 256) {
 			printk (KERN_WARNING "512 byte HW ECC not possible on 256 Byte pagesize, fallback to SW ECC \n");
 			this->eccmode = NAND_ECC_SOFT;
-------------- next part --------------
/*
 *  drivers/mtd/tx4925ndfmc.c
 *
 *  Overview:
 *   This is a device driver for the NAND flash device found on the
 *   Toshiba RBTX4925 reference board, which is a SmartMediaCard. It supports 
 *   16MB, 32MB and 64MB cards.
 *
 * Author: MontaVista Software, Inc.  source at mvista.com
 *
 * Derived from drivers/mtd/autcpu12.c
 *       Copyright (c) 2001 Thomas Gleixner (gleixner at autronix.de)
 *
 * Copyright (C) 2001 Toshiba Corporation 
 * 
 * 2003 (c) MontaVista Software, Inc. This file is licensed under
 * the terms of the GNU General Public License version 2. This program
 * is licensed "as is" without any warranty of any kind, whether express
 * or implied.
 *
 */

#include <linux/slab.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/partitions.h>
#include <linux/delay.h>
#include <asm/io.h>
#include <asm/tx4925/tx4925_nand.h>

extern struct nand_oobinfo jffs2_oobinfo;

/*
 * MTD structure for RBTX4925 board
 */
static struct mtd_info *tx4925ndfmc_mtd = NULL;

/*
 * Module stuff
 */
#if LINUX_VERSION_CODE < 0x20212 && defined(MODULE)
#define tx4925ndfmc_init init_module
#define tx4925ndfmc_cleanup cleanup_module
#endif

/*
 * Define partitions for flash devices
 */

static struct mtd_partition partition_info16k[] = {
	{ name: "RBTX4925 flash partition 1",
	  offset:  0,
	  size:    8 * 0x00100000 },
	{ name: "RBTX4925 flash partition 2",
	  offset:  8 * 0x00100000,
	  size:    8 * 0x00100000 },
};

static struct mtd_partition partition_info32k[] = {
	{ name: "RBTX4925 flash partition 1",
	  offset:  0,
	  size:    8 * 0x00100000 },
	{ name: "RBTX4925 flash partition 2",
	  offset:  8 * 0x00100000,
	  size:   24 * 0x00100000 },
};

static struct mtd_partition partition_info64k[] = {
	{ name: "User FS",
	  offset:  0,
	  size:   16 * 0x00100000 },
	{ name: "RBTX4925 flash partition 2",
	  offset: 16 * 0x00100000,
	  size:   48 * 0x00100000},
};

static struct mtd_partition partition_info128k[] = {
	{ name: "Skip bad section",
	  offset:  0,
	  size:   16 * 0x00100000 },
	{ name: "User FS",
	  offset: 16 * 0x00100000,
	  size:   112 * 0x00100000 },
};
#define NUM_PARTITIONS16K  2
#define NUM_PARTITIONS32K  2
#define NUM_PARTITIONS64K  2
#define NUM_PARTITIONS128K 2

/* 
 *	hardware specific access to control-lines
*/
static void tx4925ndfmc_hwcontrol(struct mtd_info *mtd, int cmd)
{

	switch(cmd){

		case NAND_CTL_SETCLE: 
			tx4925_ndfmcptr->mcr |= TX4925_NDFMCR_CLE;
			break;
		case NAND_CTL_CLRCLE:
			tx4925_ndfmcptr->mcr &= ~TX4925_NDFMCR_CLE;
			break;
		case NAND_CTL_SETALE:
			tx4925_ndfmcptr->mcr |= TX4925_NDFMCR_ALE;
			break;
		case NAND_CTL_CLRALE: 
			tx4925_ndfmcptr->mcr &= ~TX4925_NDFMCR_ALE;
			break;
		case NAND_CTL_SETNCE:
			tx4925_ndfmcptr->mcr |= TX4925_NDFMCR_CE;
			break;
		case NAND_CTL_CLRNCE:
			tx4925_ndfmcptr->mcr &= ~TX4925_NDFMCR_CE;
			break;
		case NAND_CTL_SETWP:
			tx4925_ndfmcptr->mcr |= TX4925_NDFMCR_WE;
			break;
		case NAND_CTL_CLRWP:
			tx4925_ndfmcptr->mcr &= ~TX4925_NDFMCR_WE;
			break;
	}
}

/*
*	read device ready pin
*/
static int tx4925ndfmc_device_ready(struct mtd_info *mtd)
{
	int ready;
	ready = (tx4925_ndfmcptr->sr & TX4925_NDSFR_BUSY) ? 0 : 1;
	return ready;
}
void tx4925ndfmc_enable_hwecc(struct mtd_info *mtd, int mode)
{
	/* reset first */
	tx4925_ndfmcptr->mcr |= TX4925_NDFMCR_ECC_CNTL_MASK;
	tx4925_ndfmcptr->mcr &= ~TX4925_NDFMCR_ECC_CNTL_MASK;
	tx4925_ndfmcptr->mcr |= TX4925_NDFMCR_ECC_CNTL_ENAB;
}
static void tx4925ndfmc_disable_ecc(void)
{
	tx4925_ndfmcptr->mcr &= ~TX4925_NDFMCR_ECC_CNTL_MASK;
}
static void tx4925ndfmc_enable_read_ecc(void)
{
	tx4925_ndfmcptr->mcr &= ~TX4925_NDFMCR_ECC_CNTL_MASK;
	tx4925_ndfmcptr->mcr |= TX4925_NDFMCR_ECC_CNTL_READ;
}
void tx4925ndfmc_readecc(struct mtd_info *mtd, const u_char *dat, u_char *ecc_code){
	int i;
	u_char *ecc = ecc_code;
        tx4925ndfmc_enable_read_ecc();
	for (i = 0;i < 6;i++,ecc++)
		*ecc = tx4925_read_nfmc(&(tx4925_ndfmcptr->dtr));
        tx4925ndfmc_disable_ecc();
}
void tx4925ndfmc_device_setup(void)
{

	*(unsigned char *)0xbb005000 &= ~0x08;

        /* reset NDFMC */
        tx4925_ndfmcptr->rstr |= TX4925_NDFRSTR_RST;
	while (tx4925_ndfmcptr->rstr & TX4925_NDFRSTR_RST);       

	/* setup BusSeparete, Hold Time, Strobe Pulse Width */
	tx4925_ndfmcptr->mcr = TX4925_BSPRT ? TX4925_NDFMCR_BSPRT : 0;
	tx4925_ndfmcptr->spr = TX4925_HOLD << 4 | TX4925_SPW;             
}
static u_char tx4925ndfmc_nand_read_byte(struct mtd_info *mtd)
{
        struct nand_chip *this = mtd->priv;
        return tx4925_read_nfmc(this->IO_ADDR_R);
}

static void tx4925ndfmc_nand_write_byte(struct mtd_info *mtd, u_char byte)
{
        struct nand_chip *this = mtd->priv;
        tx4925_write_nfmc(byte, this->IO_ADDR_W);
}

static void tx4925ndfmc_nand_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
{
	int i;
	struct nand_chip *this = mtd->priv;

	for (i=0; i<len; i++)
		tx4925_write_nfmc(buf[i], this->IO_ADDR_W);
}

static void tx4925ndfmc_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
	int i;
	struct nand_chip *this = mtd->priv;

	for (i=0; i<len; i++)
		buf[i] = tx4925_read_nfmc(this->IO_ADDR_R);
}

static int tx4925ndfmc_nand_verify_buf(struct mtd_info *mtd, const u_char *buf, int len)
{
	int i;
	struct nand_chip *this = mtd->priv;

	for (i=0; i<len; i++)
		if (buf[i] != tx4925_read_nfmc(this->IO_ADDR_R))
			return i;

	return 0;
}

/*
 * Send command to NAND device
 */
static void tx4925ndfmc_nand_command (struct mtd_info *mtd, unsigned command, int column, int page_addr)
{
	register struct nand_chip *this = mtd->priv;

	/* Begin command latch cycle */
	this->hwcontrol(mtd, NAND_CTL_SETCLE);
	/*
	 * Write out the command to the device.
	 */
	if (command == NAND_CMD_SEQIN) {
		int readcmd;

		if (column >= mtd->oobblock) {
			/* OOB area */
			column -= mtd->oobblock;
			readcmd = NAND_CMD_READOOB;
		} else if (column < 256) {
			/* First 256 bytes --> READ0 */
			readcmd = NAND_CMD_READ0;
		} else {
			column -= 256;
			readcmd = NAND_CMD_READ1;
		}
		this->write_byte(mtd, readcmd);
	}
	this->write_byte(mtd, command);

	/* Set ALE and clear CLE to start address cycle */
	this->hwcontrol(mtd, NAND_CTL_CLRCLE);

	if (column != -1 || page_addr != -1) {
		this->hwcontrol(mtd, NAND_CTL_SETALE);

		/* Serially input address */
		if (column != -1)
			this->write_byte(mtd, column);
		if (page_addr != -1) {
			this->write_byte(mtd, (unsigned char) (page_addr & 0xff));
			this->write_byte(mtd, (unsigned char) ((page_addr >> 8) & 0xff));
			/* One more address cycle for higher density devices */
			if (mtd->size & 0x0c000000) 
				this->write_byte(mtd, (unsigned char) ((page_addr >> 16) & 0x0f));
		}
		/* Latch in address */
		this->hwcontrol(mtd, NAND_CTL_CLRALE);
	}
	
	/* 
	 * program and erase have their own busy handlers 
	 * status and sequential in needs no delay
	*/
	switch (command) {
			
	case NAND_CMD_PAGEPROG:
		/* Turn off WE */
		this->hwcontrol (mtd, NAND_CTL_CLRWP);
                return;

	case NAND_CMD_SEQIN:
		/* Turn on WE */
		this->hwcontrol (mtd, NAND_CTL_SETWP);
                return;

	case NAND_CMD_ERASE1:
	case NAND_CMD_ERASE2:
	case NAND_CMD_STATUS:
		return;

	case NAND_CMD_RESET:
		if (this->dev_ready)	
			break;
		this->hwcontrol(mtd, NAND_CTL_SETCLE);
		this->write_byte(mtd, NAND_CMD_STATUS);
		this->hwcontrol(mtd, NAND_CTL_CLRCLE);
		while ( !(this->read_byte(mtd) & 0x40));
		return;

	/* This applies to read commands */	
	default:
		/* 
		 * If we don't have access to the busy pin, we apply the given
		 * command delay
		*/
		if (!this->dev_ready) {
			udelay (this->chip_delay);
			return;
		}	
	}
	
	/* wait until command is processed */
	while (!this->dev_ready(mtd));
}

#ifdef CONFIG_MTD_CMDLINE_PARTS
extern int parse_cmdline_partitions(struct mtd_info *master, struct mtd_partitio
n **pparts, char *);
#endif

/*
 * Main initialization routine
 */
extern int nand_correct_data(struct mtd_info *mtd, u_char *dat, u_char *read_ecc, u_char *calc_ecc);
int __init tx4925ndfmc_init (void)
{
	struct nand_chip *this;
	int err = 0;

	/* Allocate memory for MTD device structure and private data */
	tx4925ndfmc_mtd = kmalloc (sizeof(struct mtd_info) + sizeof (struct nand_chip),
				GFP_KERNEL);
	if (!tx4925ndfmc_mtd) {
		printk ("Unable to allocate RBTX4925 NAND MTD device structure.\n");
		err = -ENOMEM;
		goto out;
	}

        tx4925ndfmc_device_setup();

	/* io is indirect via a register so don't need to ioremap address */

	/* Get pointer to private data */
	this = (struct nand_chip *) (&tx4925ndfmc_mtd[1]);

	/* Initialize structures */
	memset((char *) tx4925ndfmc_mtd, 0, sizeof(struct mtd_info));
	memset((char *) this, 0, sizeof(struct nand_chip));

	/* Link the private data with the MTD structure */
	tx4925ndfmc_mtd->priv = this;

	/* Set address of NAND IO lines */
	this->IO_ADDR_R = (unsigned long)&(tx4925_ndfmcptr->dtr);
	this->IO_ADDR_W = (unsigned long)&(tx4925_ndfmcptr->dtr);
	this->hwcontrol = tx4925ndfmc_hwcontrol;
#define USE_HW_ECC 
//#undef USE_HW_ECC 
#ifdef USE_HW_ECC
	this->enable_hwecc = tx4925ndfmc_enable_hwecc;
	this->calculate_ecc = tx4925ndfmc_readecc;
	this->correct_data = nand_correct_data;
	this->eccmode = NAND_ECC_HW6_512;	
#else
	this->eccmode = NAND_ECC_SOFT;	
#endif
	this->dev_ready = tx4925ndfmc_device_ready;
	/* 20 us command delay time */
	this->chip_delay = 20;		
        this->read_byte = tx4925ndfmc_nand_read_byte;
        this->write_byte = tx4925ndfmc_nand_write_byte;
	this->cmdfunc = tx4925ndfmc_nand_command;
	this->write_buf = tx4925ndfmc_nand_write_buf;
	this->read_buf = tx4925ndfmc_nand_read_buf;
	this->verify_buf = tx4925ndfmc_nand_verify_buf;

	/* Scan to find existance of the device */
	if (nand_scan (tx4925ndfmc_mtd, 1)) {
		err = -ENXIO;
		goto out_ior;
	}

	/* Allocate memory for internal data buffer */
	this->data_buf = kmalloc (sizeof(u_char) * (tx4925ndfmc_mtd->oobblock + tx4925ndfmc_mtd->oobsize), GFP_KERNEL);
	if (!this->data_buf) {
		printk ("Unable to allocate NAND data buffer for RBTX4925.\n");
		err = -ENOMEM;
		goto out_ior;
	}

	/* Register the partitions */
#ifdef CONFIG_MTD_CMDLINE_PARTS
        {
                int mtd_parts_nb = 0;
                struct mtd_partition *mtd_parts = 0;
                mtd_parts_nb = parse_cmdline_partitions(tx4925ndfmc_mtd, &mtd_parts, "tx4925ndfmc");
                if (mtd_parts_nb > 0)
                        add_mtd_partitions(tx4925ndfmc_mtd, mtd_parts, mtd_parts_nb);
                else
                        add_mtd_device(tx4925ndfmc_mtd);
        }
#else /* ifdef CONFIG_MTD_CMDLINE_PARTS */
	switch(tx4925ndfmc_mtd->size){
		case 0x01000000: add_mtd_partitions(tx4925ndfmc_mtd, partition_info16k, NUM_PARTITIONS16K); break;
		case 0x02000000: add_mtd_partitions(tx4925ndfmc_mtd, partition_info32k, NUM_PARTITIONS32K); break;
		case 0x04000000: add_mtd_partitions(tx4925ndfmc_mtd, partition_info64k, NUM_PARTITIONS64K); break; 
		case 0x08000000: add_mtd_partitions(tx4925ndfmc_mtd, partition_info128k, NUM_PARTITIONS128K); break; 
		default: {
			printk ("Unsupported SmartMedia device\n"); 
			err = -ENXIO;
			goto out_buf;
		}
	}
#endif /* ifdef CONFIG_MTD_CMDLINE_PARTS */
	goto out;

out_buf:
	kfree (this->data_buf);    
out_ior:
out:
	return err;
}

module_init(tx4925ndfmc_init);

/*
 * Clean up routine
 */
#ifdef MODULE
static void __exit tx4925ndfmc_cleanup (void)
{
	struct nand_chip *this = (struct nand_chip *) &tx4925ndfmc_mtd[1];

	/* Unregister partitions */
	del_mtd_partitions(tx4925ndfmc_mtd);
	
	/* Unregister the device */
	del_mtd_device (tx4925ndfmc_mtd);

	/* Free internal data buffers */
	kfree (this->data_buf);

	/* Free the MTD device structure */
	kfree (tx4925ndfmc_mtd);
}
module_exit(tx4925ndfmc_cleanup);
#endif

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Glue layer for SmartMediaCard on Toshiba RBTX4925");
-------------- next part --------------
/*
 * drivers/mtd/nand/tx4938ndfmc.c
 *
 *  Overview:
 *   This is a device driver for the NAND flash device connected to
 *   TX4938 internal NAND Memory Controller.
 *   TX4938 NDFMC is almost same as TX4925 NDFMC, but register size are 64 bit.
 *
 * Author: source at mvista.com
 *
 * Based on spia.c by Steven J. Hill
 *
 * Copyright (C) 2000-2001 Toshiba Corporation 
 *
 * 2003 (c) MontaVista Software, Inc. This file is licensed under the
 * terms of the GNU General Public License version 2. This program is
 * licensed "as is" without any warranty of any kind, whether express
 * or implied.
 */
#include <linux/config.h>
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/nand_ecc.h>
#include <linux/mtd/partitions.h>
#include <asm/io.h>
#include <asm/bootinfo.h>
#include <linux/delay.h>
#include <asm/tx4938/rbtx4938.h>

extern struct nand_oobinfo jffs2_oobinfo;

/*
 * MTD structure for TX4938 NDFMC
 */
static struct mtd_info *tx4938ndfmc_mtd;

/*
 * Define partitions for flash device
 */
#define flush_wb()	(void)tx4938_ndfmcptr->mcr;

#define NUM_PARTITIONS  3
#ifndef CONFIG_MTD_CMDLINE_PARTS
static struct mtd_partition partition_info[NUM_PARTITIONS] = {
	{
		name: "RBTX4938 CIS Area",
 		offset:  0,
 		size:    24 * 0x00004000,
 		mask_flags : MTD_WRITEABLE	/* This partition is not writable */
 	},
 	{
 		name: "RBTX4938 kernel image",
 		offset:  MTDPART_OFS_APPEND,
 		size:    8 * 0x00100000,	/* 8MB */
 		mask_flags : MTD_WRITEABLE	/* This partition is not writable */
 	},
 	{
 		name: "Root FS (JFFS2)",
 		offset:  MTDPART_OFS_APPEND,
 		size:    MTDPART_SIZ_FULL
 	},
};
#endif

static void tx4938ndfmc_hwcontrol(struct mtd_info *mtd, int cmd)
{
	switch (cmd) {
		case NAND_CTL_SETCLE:
			tx4938_ndfmcptr->mcr |= TX4938_NDFMCR_CLE;
			break;
		case NAND_CTL_CLRCLE:
			tx4938_ndfmcptr->mcr &= ~TX4938_NDFMCR_CLE;
			break;
		case NAND_CTL_SETALE:
			tx4938_ndfmcptr->mcr |= TX4938_NDFMCR_ALE;
			break;
		case NAND_CTL_CLRALE:
			tx4938_ndfmcptr->mcr &= ~TX4938_NDFMCR_ALE;
			break;
		/* TX4938_NDFMCR_CE bit is 0:high 1:low */
		case NAND_CTL_SETNCE:
			tx4938_ndfmcptr->mcr |= TX4938_NDFMCR_CE;
			break;
		case NAND_CTL_CLRNCE:
			tx4938_ndfmcptr->mcr &= ~TX4938_NDFMCR_CE;
			break;
		case NAND_CTL_SETWP:
			tx4938_ndfmcptr->mcr |= TX4938_NDFMCR_WE;
			break;
		case NAND_CTL_CLRWP:
			tx4938_ndfmcptr->mcr &= ~TX4938_NDFMCR_WE;
			break;
	}
}
static int tx4938ndfmc_dev_ready(struct mtd_info *mtd)
{
	flush_wb();
	return !(tx4938_ndfmcptr->sr & TX4938_NDFSR_BUSY);
}
static void tx4938ndfmc_calculate_ecc(struct mtd_info *mtd, const u_char *dat, u_char *ecc_code)
{
	u32 mcr = tx4938_ndfmcptr->mcr;
	mcr &= ~TX4938_NDFMCR_ECC_ALL;
	tx4938_ndfmcptr->mcr = mcr | TX4938_NDFMCR_ECC_OFF;
	tx4938_ndfmcptr->mcr = mcr | TX4938_NDFMCR_ECC_READ;
	ecc_code[1] = tx4938_ndfmcptr->dtr;
	ecc_code[0] = tx4938_ndfmcptr->dtr;
	ecc_code[2] = tx4938_ndfmcptr->dtr;
	tx4938_ndfmcptr->mcr = mcr | TX4938_NDFMCR_ECC_OFF;
}
static void tx4938ndfmc_enable_hwecc(struct mtd_info *mtd, int mode)
{
	u32 mcr = tx4938_ndfmcptr->mcr;
	mcr &= ~TX4938_NDFMCR_ECC_ALL;
	tx4938_ndfmcptr->mcr = mcr | TX4938_NDFMCR_ECC_RESET;
	tx4938_ndfmcptr->mcr = mcr | TX4938_NDFMCR_ECC_OFF;
	tx4938_ndfmcptr->mcr = mcr | TX4938_NDFMCR_ECC_ON;
}

static u_char tx4938ndfmc_nand_read_byte(struct mtd_info *mtd)
{
	struct nand_chip *this = mtd->priv;
	return tx4938_read_nfmc(this->IO_ADDR_R);
}

static void tx4938ndfmc_nand_write_byte(struct mtd_info *mtd, u_char byte)
{
	struct nand_chip *this = mtd->priv;
	tx4938_write_nfmc(byte, this->IO_ADDR_W);
}

static void tx4938ndfmc_nand_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
{
	int i;
	struct nand_chip *this = mtd->priv;

	for (i=0; i<len; i++)
		tx4938_write_nfmc(buf[i], this->IO_ADDR_W);
}

static void tx4938ndfmc_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
	int i;
	struct nand_chip *this = mtd->priv;

	for (i=0; i<len; i++)
		buf[i] = tx4938_read_nfmc(this->IO_ADDR_R);
}

static int tx4938ndfmc_nand_verify_buf(struct mtd_info *mtd, const u_char *buf, int len)
{
	int i;
	struct nand_chip *this = mtd->priv;

	for (i=0; i<len; i++)
		if (buf[i] != tx4938_read_nfmc(this->IO_ADDR_R))
			return i;

	return 0;
}

/*
 * Send command to NAND device
 */
static void tx4938ndfmc_nand_command (struct mtd_info *mtd, unsigned command, int column, int page_addr)
{
	register struct nand_chip *this = mtd->priv;

	/* Begin command latch cycle */
	this->hwcontrol(mtd, NAND_CTL_SETCLE);
	/*
	 * Write out the command to the device.
	 */
	if (command == NAND_CMD_SEQIN) {
		int readcmd;

		if (column >= mtd->oobblock) {
			/* OOB area */
			column -= mtd->oobblock;
			readcmd = NAND_CMD_READOOB;
		} else if (column < 256) {
			/* First 256 bytes --> READ0 */
			readcmd = NAND_CMD_READ0;
		} else {
			column -= 256;
			readcmd = NAND_CMD_READ1;
		}
		this->write_byte(mtd, readcmd);
	}
	this->write_byte(mtd, command);

	/* Set ALE and clear CLE to start address cycle */
	this->hwcontrol(mtd, NAND_CTL_CLRCLE);

	if (column != -1 || page_addr != -1) {
		this->hwcontrol(mtd, NAND_CTL_SETALE);

		/* Serially input address */
		if (column != -1)
			this->write_byte(mtd, column);
		if (page_addr != -1) {
			this->write_byte(mtd, (unsigned char) (page_addr & 0xff));
			this->write_byte(mtd, (unsigned char) ((page_addr >> 8) & 0xff));
			/* One more address cycle for higher density devices */
			if (mtd->size & 0x0c000000) 
				this->write_byte(mtd, (unsigned char) ((page_addr >> 16) & 0x0f));
		}
		/* Latch in address */
		this->hwcontrol(mtd, NAND_CTL_CLRALE);
	}
	
	/* 
	 * program and erase have their own busy handlers 
	 * status and sequential in needs no delay
	*/
	switch (command) {
			
	case NAND_CMD_PAGEPROG:
		/* Turn off WE */
		this->hwcontrol (mtd, NAND_CTL_CLRWP);
                return;

	case NAND_CMD_SEQIN:
		/* Turn on WE */
		this->hwcontrol (mtd, NAND_CTL_SETWP);
                return;

	case NAND_CMD_ERASE1:
	case NAND_CMD_ERASE2:
	case NAND_CMD_STATUS:
		return;

	case NAND_CMD_RESET:
		if (this->dev_ready)	
			break;
		this->hwcontrol(mtd, NAND_CTL_SETCLE);
		this->write_byte(mtd, NAND_CMD_STATUS);
		this->hwcontrol(mtd, NAND_CTL_CLRCLE);
		while ( !(this->read_byte(mtd) & 0x40));
		return;

	/* This applies to read commands */	
	default:
		/* 
		 * If we don't have access to the busy pin, we apply the given
		 * command delay
		*/
		if (!this->dev_ready) {
			udelay (this->chip_delay);
			return;
		}	
	}
	
	/* wait until command is processed */
	while (!this->dev_ready(mtd));
}

#ifdef CONFIG_MTD_CMDLINE_PARTS
extern int parse_cmdline_partitions(struct mtd_info *master, struct mtd_partition **pparts, char *);
#endif
/*
 * Main initialization routine
 */
int __init tx4938ndfmc_init (void)
{
	struct nand_chip *this;
	int bsprt = 0, hold = 0xf, spw = 0xf;
	int protected = 0;

	if ((*rbtx4938_piosel_ptr & 0x0c) != 0x08) {
		printk("TX4938 NDFMC: disabled by IOC PIOSEL\n");
		return -ENODEV;
	}
	bsprt = 1;
	hold = 2;
	spw = 9 - 1;	/* 8 GBUSCLK = 80ns (@ GBUSCLK 100MHz) */

	if ((tx4938_ccfgptr->pcfg &
	     (TX4938_PCFG_ATA_SEL|TX4938_PCFG_ISA_SEL|TX4938_PCFG_NDF_SEL))
	    != TX4938_PCFG_NDF_SEL) {
		printk("TX4938 NDFMC: disabled by PCFG.\n");
		return -ENODEV;
	}

	/* reset NDFMC */
	tx4938_ndfmcptr->rstr |= TX4938_NDFRSTR_RST;
	while (tx4938_ndfmcptr->rstr & TX4938_NDFRSTR_RST)
		;
	/* setup BusSeparete, Hold Time, Strobe Pulse Width */
	tx4938_ndfmcptr->mcr = bsprt ? TX4938_NDFMCR_BSPRT : 0;
	tx4938_ndfmcptr->spr = hold << 4 | spw;

	/* Allocate memory for MTD device structure and private data */
	tx4938ndfmc_mtd = kmalloc (sizeof(struct mtd_info) + sizeof (struct nand_chip),
				      GFP_KERNEL);
	if (!tx4938ndfmc_mtd) {
		printk ("Unable to allocate TX4938 NDFMC MTD device structure.\n");
		return -ENOMEM;
	}

	/* Get pointer to private data */
	this = (struct nand_chip *) (&tx4938ndfmc_mtd[1]);

	/* Initialize structures */
	memset((char *) tx4938ndfmc_mtd, 0, sizeof(struct mtd_info));
	memset((char *) this, 0, sizeof(struct nand_chip));

	/* Link the private data with the MTD structure */
	tx4938ndfmc_mtd->priv = this;

	/* Set address of NAND IO lines */
	this->IO_ADDR_R = (unsigned long)&tx4938_ndfmcptr->dtr;
	this->IO_ADDR_W = (unsigned long)&tx4938_ndfmcptr->dtr;
	this->hwcontrol = tx4938ndfmc_hwcontrol;
	this->dev_ready = tx4938ndfmc_dev_ready;
	this->calculate_ecc = tx4938ndfmc_calculate_ecc;
	this->correct_data = nand_correct_data;
	this->enable_hwecc = tx4938ndfmc_enable_hwecc;
	this->eccmode = NAND_ECC_HW3_256;
	this->chip_delay = 100;
	this->read_byte = tx4938ndfmc_nand_read_byte;
	this->write_byte = tx4938ndfmc_nand_write_byte;
	this->cmdfunc = tx4938ndfmc_nand_command;
	this->write_buf = tx4938ndfmc_nand_write_buf;
	this->read_buf = tx4938ndfmc_nand_read_buf;
	this->verify_buf = tx4938ndfmc_nand_verify_buf;

	/* Scan to find existance of the device */
	if (nand_scan (tx4938ndfmc_mtd, 1)) {
		kfree (tx4938ndfmc_mtd);
		return -ENXIO;
	}

	/* Allocate memory for internal data buffer */
	this->data_buf = kmalloc (sizeof(u_char) * (tx4938ndfmc_mtd->oobblock + tx4938ndfmc_mtd->oobsize), GFP_KERNEL);
	if (!this->data_buf) {
		printk ("Unable to allocate NAND data buffer for TX4938.\n");
		kfree (tx4938ndfmc_mtd);
		return -ENOMEM;
	}

	if (protected) {
		printk(KERN_INFO "TX4938 NDFMC: write protected.\n");
		tx4938ndfmc_mtd->flags &= ~(MTD_WRITEABLE | MTD_ERASEABLE);
	}

#ifdef CONFIG_MTD_CMDLINE_PARTS
	{
		int mtd_parts_nb = 0;
		struct mtd_partition *mtd_parts = 0;
		mtd_parts_nb = parse_cmdline_partitions(tx4938ndfmc_mtd, &mtd_parts, "tx4938ndfmc");
		if (mtd_parts_nb > 0)
			add_mtd_partitions(tx4938ndfmc_mtd, mtd_parts, mtd_parts_nb);
		else
			add_mtd_device(tx4938ndfmc_mtd);
	}
#else
	add_mtd_partitions(tx4938ndfmc_mtd, partition_info, NUM_PARTITIONS );
#endif

	return 0;
}
module_init(tx4938ndfmc_init);

/*
 * Clean up routine
 */
static void __exit tx4938ndfmc_cleanup (void)
{
	struct nand_chip *this = (struct nand_chip *) tx4938ndfmc_mtd->priv;

	/* Unregister the device */
#ifdef CONFIG_MTD_CMDLINE_PARTS
	del_mtd_partitions(tx4938ndfmc_mtd);
#endif
	del_mtd_device (tx4938ndfmc_mtd);

	/* Free the MTD device structure */
	kfree (tx4938ndfmc_mtd);

	/* Free internal data buffer */
	kfree (this->data_buf);
}
module_exit(tx4938ndfmc_cleanup);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Board-specific glue layer for NAND flash on TX4938 NDFMC");

From jsun at mvista.com  Wed Oct 22 21:15:28 2003
From: jsun at mvista.com (Jun Sun)
Date: Wed, 22 Oct 2003 18:15:28 -0700
Subject: [PATCH] remove unnecessary inclusion of <asm/setup.h>
Message-ID: <20031022181528.T19834@mvista.com>


I don't see any purpose of including this file.  Furthermore
<asm/setup.h> does not even exist on MIPS and other arches.

Jun
-------------- next part --------------
diff -Nru linux/drivers/mtd/cmdlinepart.c.orig linux/drivers/mtd/cmdlinepart.c
--- linux/drivers/mtd/cmdlinepart.c.orig	Mon Jul 21 08:14:02 2003
+++ linux/drivers/mtd/cmdlinepart.c	Wed Oct 22 15:43:03 2003
@@ -29,7 +29,6 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/compatmac.h>
-#include <asm/setup.h>
 #include <linux/bootmem.h>
 
 /* error message prefix */

From jsun at mvista.com  Wed Oct 22 21:25:58 2003
From: jsun at mvista.com (Jun Sun)
Date: Wed, 22 Oct 2003 18:25:58 -0700
Subject: [PATCH] extend physmap.c to support run-time adding partitions
Message-ID: <20031022182558.U19834@mvista.com>


While looking at drvers/mtd/maps directories, it becomes
obvious to me that many files are derived from physmap.c,
in order to add partition support or add their own
set_vpp() pointer, etc..

Such a need can be easily satisfied by extending physmap.c
a little.

In this patch, I like to introduce phsmap_add_partition()
function, which allows boards to add flash partitions
at run-time.  (Note that you can still override this
hardcoded partition by using kernel command line)

In the patch I also showed how a board can make use of this
extension.  Hopefully we can get rid of lots of files under 
the maps directory. :)

Boards which need to set set_vpp pointer can do so easily
too.

Any comments?

Jun
-------------- next part --------------
diff -Nru linux/arch/mips/mips-boards/malta/malta_setup.c.orig linux/arch/mips/mips-boards/malta/malta_setup.c
--- linux/arch/mips/mips-boards/malta/malta_setup.c.orig	Fri Aug  1 10:50:18 2003
+++ linux/arch/mips/mips-boards/malta/malta_setup.c	Wed Oct 22 17:26:24 2003
@@ -24,6 +24,7 @@
 #ifdef CONFIG_BLK_DEV_IDE
 #include <linux/ide.h>
 #endif
+#include <linux/mtd/physmap.h>
 
 #include <asm/cpu.h>
 #include <asm/bootinfo.h>
@@ -166,6 +167,12 @@
         conswitchp = &dummy_con;
 #endif
 #endif
+
+#if defined(CONFIG_MTD_PHYSMAP) && defined(CONFIG_MTD_PARTITIONS)
+	physmap_add_partition("YAMON", 0x100000, 0x0, MTD_WRITEABLE);
+	physmap_add_partition("User FS", 0x300000, 0x100000, 0);
+#endif
+
 	mips_reboot_setup();
 
 	board_time_init = mips_time_init;
diff -Nru linux/drivers/mtd/maps/physmap.c.orig linux/drivers/mtd/maps/physmap.c
--- linux/drivers/mtd/maps/physmap.c.orig	Wed Jul 23 15:17:52 2003
+++ linux/drivers/mtd/maps/physmap.c	Wed Oct 22 17:42:50 2003
@@ -2,6 +2,11 @@
  * $Id: physmap.c,v 1.28 2003/05/28 15:53:43 dwmw2 Exp $
  *
  * Normal mappings of chips in physical memory
+ *
+ * Copyright (C) 2003 MontaVista Software Inc.
+ * Author: Jun Sun, jsun at mvista.com or jsun at junsun.net
+ *
+ * 031022 - [jsun] add physmap_add_partition()
  */
 
 #include <linux/module.h>
@@ -23,7 +28,7 @@
 
 
 struct map_info physmap_map = {
-	.name = "Physically mapped flash",
+	.name = "phys_mapped_flash",
 	.size = WINDOW_SIZE,
 	.buswidth = BUSWIDTH,
 	.phys = WINDOW_ADDR,
@@ -33,35 +38,31 @@
 static struct mtd_partition *mtd_parts;
 static int                   mtd_parts_nb;
 
-static struct mtd_partition physmap_partitions[] = {
-#if 0
-/* Put your own partition definitions here */
-	{
-		.name =		"bootROM",
-		.size =		0x80000,
-		.offset =	0,
-		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
-	}, {
-		.name =		"zImage",
-		.size =		0x100000,
-		.offset =	MTDPART_OFS_APPEND,
-		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
-	}, {
-		.name =		"ramdisk.gz",
-		.size =		0x300000,
-		.offset =	MTDPART_OFS_APPEND,
-		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
-	}, {
-		.name =		"User FS",
-		.size =		MTDPART_SIZ_FULL,
-		.offset =	MTDPART_OFS_APPEND,
+#define NUM_PARTITIONS	4	/* random num which should be good enough */
+static struct mtd_partition physmap_partitions[NUM_PARTITIONS] __initdata = {};
+
+char *part_probes[] __initdata = {"cmdlinepart", "RedBoot", NULL};
+
+/*
+ * See include/linux/mtd/physmap.h file.
+ */
+static int part_index __initdata = 0;
+int __init physmap_add_partition(char *name, u32 size, u32 offset, u32 flags)
+{
+	if (part_index >= NUM_PARTITIONS) {
+		printk(KERN_ERR "physmap_add_partition() exceeds max partition table size (%d)\n", NUM_PARTITIONS);
+		return -1;
 	}
-#endif
-};
 
-#define NUM_PARTITIONS	(sizeof(physmap_partitions)/sizeof(struct mtd_partition))
-const char *part_probes[] = {"cmdlinepart", "RedBoot", NULL};
+	physmap_partitions[part_index].name = name;
+	physmap_partitions[part_index].size = size;
+	physmap_partitions[part_index].offset = offset;
+	physmap_partitions[part_index].mask_flags = flags;
+
+	part_index++;
 
+	return 0;
+}
 #endif /* CONFIG_MTD_PARTITIONS */
 
 int __init init_physmap(void)
@@ -97,11 +98,11 @@
 			return 0;
 		}
 
-		if (NUM_PARTITIONS != 0) 
+		if (part_index != 0) 
 		{
 			printk(KERN_NOTICE 
 			       "Using physmap partition definition\n");
-			add_mtd_partitions (mymtd, physmap_partitions, NUM_PARTITIONS);
+			add_mtd_partitions (mymtd, physmap_partitions, part_index);
 			return 0;
 		}
 
diff -Nru linux/include/linux/mtd/physmap.h.orig linux/include/linux/mtd/physmap.h
--- linux/include/linux/mtd/physmap.h.orig	Wed Oct 22 17:05:22 2003
+++ linux/include/linux/mtd/physmap.h	Wed Oct 22 18:20:34 2003
@@ -0,0 +1,48 @@
+/*
+ * For boards with physically mapped flash and using 
+ * drivers/mtd/maps/physmap.c mapping driver.
+ *
+ * Copyright (C) 2003 MontaVista Software Inc.
+ * Author: Jun Sun, jsun at mvista.com or jsun at junsun.net
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef __LINUX_MTD_PHYSMAP__
+
+#include <linux/config.h>
+
+#if defined(CONFIG_MTD_PHYSMAP) 
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+
+/*
+ * The map_info for physmap.  Board can override size, buswidth, phys,
+ * (*set_vpp)(), etc in their initial setup routine.
+ */
+extern struct map_info physmap_map;
+
+#if defined(CONFIG_MTD_PARTITIONS)
+
+/*
+ * Machines that wish to do flash partition may want to call this function in 
+ * their setup routine.  Examples:
+ *
+ *	physmap_add_partition("bootROM", 0x100000, 0, MTD_WRITEABLE);
+ *	physmap_add_partition("User FS", 0x300000, 0x100000, 0)
+ *
+ * Note that one can always override this hard-coded partition with 
+ * command line partition (you need to enable CONFIG_MTD_CMDLINE_PARTS).
+ */
+int physmap_add_partition(char *name, u32 size, u32 offset, u32 mask_flags);
+
+#endif /* defined(CONFIG_MTD_PARTITIONS) */
+#endif /* defined(CONFIG_MTD) */
+
+#endif /* __LINUX_MTD_PHYSMAP__ */
+

From dwmw2 at infradead.org  Thu Oct 23 04:31:50 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Oct 2003 09:31:50 +0100
Subject: TX49 NAND supported?
In-Reply-To: <3F96FA57.470FECC7@mvista.com>
References: <3F96FA57.470FECC7@mvista.com>
Message-ID: <1066897909.29915.456.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-22 at 14:44 -0700, Alice Hennessy wrote:
 There is also a small change in nand.c to add
> a missing case statement.

Applied; thanks. For the tx49 drivers, please could you correct 'MB' to
'MiB' throughout, switch to C99 struct initialisers, add $Id$ and 
MODULE_AUTHOR, and also add the appropriate magic to Makefile.common,
Config.in and Kconfig. Thanks.

You have an account and should be able to commit those directly.

-- 
dwmw2



From dwmw2 at infradead.org  Thu Oct 23 04:36:47 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Oct 2003 09:36:47 +0100
Subject: [PATCH] remove unnecessary inclusion of <asm/setup.h>
In-Reply-To: <20031022181528.T19834@mvista.com>
References: <20031022181528.T19834@mvista.com>
Message-ID: <1066898206.29915.458.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-22 at 18:15 -0700, Jun Sun wrote:
> I don't see any purpose of including this file.  Furthermore
> <asm/setup.h> does not even exist on MIPS and other arches.

Applied; thanks.

-- 
dwmw2



From armelle.potier at elios-informatique.fr  Thu Oct 23 05:52:08 2003
From: armelle.potier at elios-informatique.fr (Armelle Potier)
Date: Thu, 23 Oct 2003 10:52:08 +0100
Subject: jffs2  on Ecos: multi task access and defragmentation
Message-ID: <NFBBKFLAIMMPNKJONACNKEAECEAA.armelle.potier@elios-informatique.fr>

2 questions:
1 - How must be used jffs2 with many task calling it for read-write-erase
operations on different or same files or directory
Is it managed correctly by jffs2 and how (tasks blocked if necessary for
example) or have the task to care for multi access and then how?
2 - does jffs2 need defragmentation functionnality ? If yes how to use this
service if it's exist.

Thanks for your response.
Armelle POTIER



From jsun at mvista.com  Thu Oct 23 13:03:04 2003
From: jsun at mvista.com (Jun Sun)
Date: Thu, 23 Oct 2003 10:03:04 -0700
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031023153307.GA11669@wohnheim.fh-wedel.de>;
	from joern@wohnheim.fh-wedel.de on Thu, Oct 23, 2003 at 05:33:07PM +0200
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
Message-ID: <20031023100304.B1070@mvista.com>

On Thu, Oct 23, 2003 at 05:33:07PM +0200, J?rn Engel wrote:
> On Wed, 22 October 2003 18:25:58 -0700, Jun Sun wrote:
> > 
> > While looking at drvers/mtd/maps directories, it becomes
> > obvious to me that many files are derived from physmap.c,
> > in order to add partition support or add their own
> > set_vpp() pointer, etc..
> > 
> > Such a need can be easily satisfied by extending physmap.c
> > a little.
> > 
> > In this patch, I like to introduce phsmap_add_partition()
> > function, which allows boards to add flash partitions
> > at run-time.  (Note that you can still override this
> > hardcoded partition by using kernel command line)
> > 
> > In the patch I also showed how a board can make use of this
> > extension.  Hopefully we can get rid of lots of files under 
> > the maps directory. :)
> 
> For most people, you saved source code size and wasted binary size.
> The very same people are far more concerned about binary size. :)
>

Ahh, note that I turned a couple of functions and data into
__init kind.  That should make space-conservative people happy.
 
> I've tried to clean this up before and failed, but maybe you can do a
> better job.  Good luck!
>

What was the main objection?  I can list quite a few benefits:

1. remove _lots_ of duplicated mapping files, which also means
   a cleaner CONFIG_xxx space and a simpler Makefile.
2. the board-specific partition setup is now done in arch/<xxx>/<board>/setup.c
   which means when a board is deleted, its flash support is automatically
   removed.  (Not so with current arrangement)
3. futher _common_ improvement is possible.  For example, for most MIPS boards
   we don't need ioremap to access the flash area - CPU has a fixed uncached
   mapping to physical space.  Now we can just modify one file and benefts
   about almost 20 boards.

Jun


From joern at wohnheim.fh-wedel.de  Thu Oct 23 13:31:48 2003
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Thu, 23 Oct 2003 19:31:48 +0200
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031023100304.B1070@mvista.com>
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
	<20031023100304.B1070@mvista.com>
Message-ID: <20031023173148.GC16160@wohnheim.fh-wedel.de>

On Thu, 23 October 2003 10:03:04 -0700, Jun Sun wrote:
> On Thu, Oct 23, 2003 at 05:33:07PM +0200, J?rn Engel wrote:
> > On Wed, 22 October 2003 18:25:58 -0700, Jun Sun wrote:
> > > 
> > > While looking at drvers/mtd/maps directories, it becomes
> > > obvious to me that many files are derived from physmap.c,
> > > in order to add partition support or add their own
> > > set_vpp() pointer, etc..
> > > 
> > > Such a need can be easily satisfied by extending physmap.c
> > > a little.
> > > 
> > > In this patch, I like to introduce phsmap_add_partition()
> > > function, which allows boards to add flash partitions
> > > at run-time.  (Note that you can still override this
> > > hardcoded partition by using kernel command line)
> > > 
> > > In the patch I also showed how a board can make use of this
> > > extension.  Hopefully we can get rid of lots of files under 
> > > the maps directory. :)
> > 
> > For most people, you saved source code size and wasted binary size.
> > The very same people are far more concerned about binary size. :)
> >
> 
> Ahh, note that I turned a couple of functions and data into
> __init kind.  That should make space-conservative people happy.

__init still shows up in flash, though.

> > I've tried to clean this up before and failed, but maybe you can do a
> > better job.  Good luck!
> 
> What was the main objection?  I can list quite a few benefits:
> 
> 1. remove _lots_ of duplicated mapping files, which also means
>    a cleaner CONFIG_xxx space and a simpler Makefile.
> 2. the board-specific partition setup is now done in arch/<xxx>/<board>/setup.c
>    which means when a board is deleted, its flash support is automatically
>    removed.  (Not so with current arrangement)
> 3. futher _common_ improvement is possible.  For example, for most MIPS boards
>    we don't need ioremap to access the flash area - CPU has a fixed uncached
>    mapping to physical space.  Now we can just modify one file and benefts
>    about almost 20 boards.

o All those translate to improvements in the source code.  How about the
binary?  Compile with and without patch and post the kernel image
size.  And remember that noone will use two map files at the same time
in the real world.

o Copy and paste is simple.  So simple in fact, that everyone does it,
as you have observed.  Why make it more complicated, unless you have
clear advantages.


Yes, I like the basic idea, tried to do it myself.  But what's the use
if all your users care about binary size and that increases?

J?rn

-- 
"Translations are and will always be problematic. They inflict violence 
upon two languages." (translation from German)


From jsun at mvista.com  Thu Oct 23 13:43:20 2003
From: jsun at mvista.com (Jun Sun)
Date: Thu, 23 Oct 2003 10:43:20 -0700
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031023173148.GC16160@wohnheim.fh-wedel.de>;
	from joern@wohnheim.fh-wedel.de on Thu, Oct 23, 2003 at 07:31:48PM +0200
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
	<20031023100304.B1070@mvista.com>
	<20031023173148.GC16160@wohnheim.fh-wedel.de>
Message-ID: <20031023104320.A1345@mvista.com>

On Thu, Oct 23, 2003 at 07:31:48PM +0200, J?rn Engel wrote:
> On Thu, 23 October 2003 10:03:04 -0700, Jun Sun wrote:
> > On Thu, Oct 23, 2003 at 05:33:07PM +0200, J?rn Engel wrote:
> > > On Wed, 22 October 2003 18:25:58 -0700, Jun Sun wrote:
> > > > 
> > > > While looking at drvers/mtd/maps directories, it becomes
> > > > obvious to me that many files are derived from physmap.c,
> > > > in order to add partition support or add their own
> > > > set_vpp() pointer, etc..
> > > > 
> > > > Such a need can be easily satisfied by extending physmap.c
> > > > a little.
> > > > 
> > > > In this patch, I like to introduce phsmap_add_partition()
> > > > function, which allows boards to add flash partitions
> > > > at run-time.  (Note that you can still override this
> > > > hardcoded partition by using kernel command line)
> > > > 
> > > > In the patch I also showed how a board can make use of this
> > > > extension.  Hopefully we can get rid of lots of files under 
> > > > the maps directory. :)
> > > 
> > > For most people, you saved source code size and wasted binary size.
> > > The very same people are far more concerned about binary size. :)
> > >
> > 
> > Ahh, note that I turned a couple of functions and data into
> > __init kind.  That should make space-conservative people happy.
> 
> __init still shows up in flash, though.
> 
> > > I've tried to clean this up before and failed, but maybe you can do a
> > > better job.  Good luck!
> > 
> > What was the main objection?  I can list quite a few benefits:
> > 
> > 1. remove _lots_ of duplicated mapping files, which also means
> >    a cleaner CONFIG_xxx space and a simpler Makefile.
> > 2. the board-specific partition setup is now done in arch/<xxx>/<board>/setup.c
> >    which means when a board is deleted, its flash support is automatically
> >    removed.  (Not so with current arrangement)
> > 3. futher _common_ improvement is possible.  For example, for most MIPS boards
> >    we don't need ioremap to access the flash area - CPU has a fixed uncached
> >    mapping to physical space.  Now we can just modify one file and benefts
> >    about almost 20 boards.
> 
> o All those translate to improvements in the source code.  How about the
> binary?  Compile with and without patch and post the kernel image
> size.  And remember that noone will use two map files at the same time
> in the real world.
> 
> o Copy and paste is simple.  So simple in fact, that everyone does it,
> as you have observed.  Why make it more complicated, unless you have
> clear advantages.
> 

... as if my previous listings are not advantages. :)

> 
> Yes, I like the basic idea, tried to do it myself.  But what's the use
> if all your users care about binary size and that increases?
>

I find it hard to belive this patch would increase kernel size.
Can someone using existing propriatary mapping driver apply this 
patch, switch to use physmap.c, and let us know the size increase?

How much increase would you start to really care in a typical .5M to 2M
kernel?  1K or 10K or 100K?  I think the increase should be minimum if any.

Actually I don't see any increase at all if the proprietary file is a strict copy
of physmap.c.

Jun


From joern at wohnheim.fh-wedel.de  Thu Oct 23 14:15:41 2003
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Thu, 23 Oct 2003 20:15:41 +0200
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031023104320.A1345@mvista.com>
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
	<20031023100304.B1070@mvista.com>
	<20031023173148.GC16160@wohnheim.fh-wedel.de>
	<20031023104320.A1345@mvista.com>
Message-ID: <20031023181541.GE16160@wohnheim.fh-wedel.de>

On Thu, 23 October 2003 10:43:20 -0700, Jun Sun wrote:
> > 
> > o All those translate to improvements in the source code.  How about the
> > binary?  Compile with and without patch and post the kernel image
> > size.  And remember that noone will use two map files at the same time
> > in the real world.
> > 
> > o Copy and paste is simple.  So simple in fact, that everyone does it,
> > as you have observed.  Why make it more complicated, unless you have
> > clear advantages.
> 
> ... as if my previous listings are not advantages. :)

They are, no doubt.  But there are disadvantages as well.

> > Yes, I like the basic idea, tried to do it myself.  But what's the use
> > if all your users care about binary size and that increases?
> 
> I find it hard to belive this patch would increase kernel size.
> Can someone using existing propriatary mapping driver apply this 
> patch, switch to use physmap.c, and let us know the size increase?
> 
> How much increase would you start to really care in a typical .5M to 2M
> kernel?  1K or 10K or 100K?  I think the increase should be minimum if any.

I don't know and I don't care.  You want the patch in, you show the
numbers or convince David otherwise.

J?rn

-- 
All art is but imitation of nature.
-- Lucius Annaeus Seneca


From jsun at mvista.com  Thu Oct 23 16:04:06 2003
From: jsun at mvista.com (Jun Sun)
Date: Thu, 23 Oct 2003 13:04:06 -0700
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031023181541.GE16160@wohnheim.fh-wedel.de>;
	from joern@wohnheim.fh-wedel.de on Thu, Oct 23, 2003 at 08:15:41PM +0200
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
	<20031023100304.B1070@mvista.com>
	<20031023173148.GC16160@wohnheim.fh-wedel.de>
	<20031023104320.A1345@mvista.com>
	<20031023181541.GE16160@wohnheim.fh-wedel.de>
Message-ID: <20031023130406.D1345@mvista.com>

On Thu, Oct 23, 2003 at 08:15:41PM +0200, J?rn Engel wrote:
> On Thu, 23 October 2003 10:43:20 -0700, Jun Sun wrote:
> > > 
> > > o All those translate to improvements in the source code.  How about the
> > > binary?  Compile with and without patch and post the kernel image
> > > size.  And remember that noone will use two map files at the same time
> > > in the real world.
> > > 
> > > o Copy and paste is simple.  So simple in fact, that everyone does it,
> > > as you have observed.  Why make it more complicated, unless you have
> > > clear advantages.
> > 
> > ... as if my previous listings are not advantages. :)
> 
> They are, no doubt.  But there are disadvantages as well.
> 
> > > Yes, I like the basic idea, tried to do it myself.  But what's the use
> > > if all your users care about binary size and that increases?
> > 
> > I find it hard to belive this patch would increase kernel size.
> > Can someone using existing propriatary mapping driver apply this 
> > patch, switch to use physmap.c, and let us know the size increase?
> > 
> > How much increase would you start to really care in a typical .5M to 2M
> > kernel?  1K or 10K or 100K?  I think the increase should be minimum if any.
> 
> I don't know and I don't care.  You want the patch in, you show the
> numbers or convince David otherwise.
>

I will do some numbers, but I don't really buy your logic.  I said
"This patch is great" and you are one who said it increases the size.
It seems to me you need to prove your claim. :)

Jun


From robin.gilks at tait.co.nz  Thu Oct 23 16:14:12 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Fri, 24 Oct 2003 09:14:12 +1300
Subject: Building jffs2 utils?
Message-ID: <3F983694.1060005@tait.co.nz>

Greetings

Can someone give a clue as to the correct way to cross compile the utils 
directory? Its find just running make using my existing (Mandrake 9.1 
based) i386 system but a cross compile to powerpc-uclibc fails miserably 
on any jffs2 tools due to the zlib stuff not being found.

All contributions to my knowledge gratefully received :-))

-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From ahennessy at mvista.com  Thu Oct 23 17:33:38 2003
From: ahennessy at mvista.com (Alice Hennessy)
Date: Thu, 23 Oct 2003 14:33:38 -0700
Subject: Different nand interface
Message-ID: <3F984931.E6409ED7@mvista.com>

Hi,

I need some advice on how to support a board that has a hardware state
machine
that creates a parallel bus style interface to the NAND chip.  It is
totally
different from the standard 8 IO signal controls.   It can do write_byte
and read_byte
put requires the offset into the flash as a parameter.    nand.c is
fairly modular, allowing
several functions to be coded in the hardware file but there is no
current method of
passing an offset into, say, read_byte and write_byte unless the
nand_chip priv field
can be used (via mtd->priv).   Do you think the standard nand.c can be
used in this
case or should I create a specific one for this board?

Any advice would be appreciated.

Alice



From david at avoncliff.com  Thu Oct 23 15:40:22 2003
From: david at avoncliff.com (david stevenson)
Date: Thu, 23 Oct 2003 20:40:22 +0100
Subject: 2.2.18 status + jffs2
Message-ID: <200310232040.23006.david@avoncliff.com>

Hi
I am very new to this and am having problems understanding the current 
position.
I am trying to build a linux system for a amd cs400 based system with amd 
29f016 chips as the root fs.
I have the mtd-jffs-howto dated aug2001 and the mtd-patch-2.2.18 of 20001218, 
but following the instructions gives me compile errors with __exit. So I have 
added #define __exit to fix these and now I get "undefined reference to 
init_mtd". Looking through this list archives I find in feb2001 reference to 
changing the method of init calls. But I guess I do not have this change.
I did try applying the current CVS patch file, but it refuses to run on 
2.2.18.

Am I going in the wrong direction?
Is it possible to use jffs2 on these chips in 2.2.18?
The reason for not using a later kernel is problems booting it with the alios 
bootloader, but I guess I could revisit those.

If it is practical in 2.2.18 can you advise which patches I should be using.
Thanks
David
PS I am using mtd to write the pcmcia flash card on my host machine which is 
working very well - the code is much appreciated.


From jsun at mvista.com  Thu Oct 23 19:57:26 2003
From: jsun at mvista.com (Jun Sun)
Date: Thu, 23 Oct 2003 16:57:26 -0700
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031023130406.D1345@mvista.com>;
	from jsun@mvista.com on Thu, Oct 23, 2003 at 01:04:06PM -0700
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
	<20031023100304.B1070@mvista.com>
	<20031023173148.GC16160@wohnheim.fh-wedel.de>
	<20031023104320.A1345@mvista.com>
	<20031023181541.GE16160@wohnheim.fh-wedel.de>
	<20031023130406.D1345@mvista.com>
Message-ID: <20031023165726.J1345@mvista.com>

On Thu, Oct 23, 2003 at 01:04:06PM -0700, Jun Sun wrote:
> On Thu, Oct 23, 2003 at 08:15:41PM +0200, J?rn Engel wrote:
> > On Thu, 23 October 2003 10:43:20 -0700, Jun Sun wrote:
> > > > 
> > > > o All those translate to improvements in the source code.  How about the
> > > > binary?  Compile with and without patch and post the kernel image
> > > > size.  And remember that noone will use two map files at the same time
> > > > in the real world.
> > > > 
> > > > o Copy and paste is simple.  So simple in fact, that everyone does it,
> > > > as you have observed.  Why make it more complicated, unless you have
> > > > clear advantages.
> > > 
> > > ... as if my previous listings are not advantages. :)
> > 
> > They are, no doubt.  But there are disadvantages as well.
> > 
> > > > Yes, I like the basic idea, tried to do it myself.  But what's the use
> > > > if all your users care about binary size and that increases?
> > > 
> > > I find it hard to belive this patch would increase kernel size.
> > > Can someone using existing propriatary mapping driver apply this 
> > > patch, switch to use physmap.c, and let us know the size increase?
> > > 
> > > How much increase would you start to really care in a typical .5M to 2M
> > > kernel?  1K or 10K or 100K?  I think the increase should be minimum if any.
> > 
> > I don't know and I don't care.  You want the patch in, you show the
> > numbers or convince David otherwise.
> >
> 
> I will do some numbers, 
<snip>

OK, I converted jmr3927 flash driver to use physmap and kernel size increases
by whopping 96 bytes!  See the ELF header dump below. :)

Meanwhile, we sadly announce the loss of drivers/mtd/maps/jmr3927-flash.c
file and the death of CONFIG_MTD_JMR3927 (not in MTD tree yet).  :0


Jun

-------------------------------------------

original vmlinux with no modification:

vmlinux.orig:     file format elf32-tradlittlemips

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         001aa080  80050000  80050000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .fixup        00001250  801fa080  801fa080  001ab080  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .kstrtab      00005000  801fb2d0  801fb2d0  001ac2d0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 __ex_table    000016d8  802002d0  802002d0  001b12d0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 __dbe_table   00000000  802019a8  802019a8  001b29a8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 __ksymtab     000025a8  802019a8  802019a8  001b29a8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .data.init_task 00002000  80204000  80204000  001b5000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  7 .text.init    0001757c  80206000  80206000  001b7000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .data.init    00005070  8021d57c  8021d57c  001ce57c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .setup.init   000000e8  802225f0  802225f0  001d35f0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .initcall.init 000000ac  802226d8  802226d8  001d36d8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .data.cacheline_aligned 00001470  80223000  80223000  001d4000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
 12 .reginfo      00000018  80224470  80224470  001d5470  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE
 13 .data         0001a000  80225000  80225000  001d6000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
 14 .bss          0002ce90  8023f000  8023f000  001f0000  2**4
                  ALLOC
 15 .comment      00002cce  8026be90  8026be90  001f0000  2**0
                  CONTENTS, READONLY
 16 .pdr          00027ae0  00000000  00000000  001f2cd0  2**2
                  CONTENTS, READONLY
 17 .mdebug.abi32 00000000  00000000  00000000  0021a7b0  2**0
                  CONTENTS, READONLY
 
-------------------------------------------

new vmlinux with patching:

vmlinux:     file format elf32-tradlittlemips

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         001aa000  80050000  80050000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .fixup        00001250  801fa000  801fa000  001ab000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .kstrtab      00005000  801fb250  801fb250  001ac250  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 __ex_table    000016d8  80200250  80200250  001b1250  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 __dbe_table   00000000  80201928  80201928  001b2928  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 __ksymtab     000025a8  80201928  80201928  001b2928  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .data.init_task 00002000  80204000  80204000  001b5000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  7 .text.init    0001763c  80206000  80206000  001b7000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .data.init    000050e0  8021d63c  8021d63c  001ce63c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .setup.init   000000e8  80222720  80222720  001d3720  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .initcall.init 000000ac  80222808  80222808  001d3808  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .data.cacheline_aligned 00001470  80223000  80223000  001d4000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
 12 .reginfo      00000018  80224470  80224470  001d5470  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE
 13 .data         0001a000  80225000  80225000  001d6000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
 14 .bss          0002ce40  8023f000  8023f000  001f0000  2**4
                  ALLOC
 15 .comment      00002cce  8026be40  8026be40  001f0000  2**0
                  CONTENTS, READONLY
 16 .pdr          00027a00  00000000  00000000  001f2cd0  2**2
                  CONTENTS, READONLY
 17 .mdebug.abi32 00000000  00000000  00000000  0021a6d0  2**0
                  CONTENTS, READONLY



From joshua at joshuawise.com  Thu Oct 23 21:36:54 2003
From: joshua at joshuawise.com (Joshua Wise)
Date: Thu, 23 Oct 2003 21:36:54 -0400
Subject: Different nand interface
In-Reply-To: <3F984931.E6409ED7@mvista.com>
References: <3F984931.E6409ED7@mvista.com>
Message-ID: <200310232136.58256.joshua@joshuawise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I need some advice on how to support a board that has a hardware state
> machine
> that creates a parallel bus style interface to the NAND chip.  It is
> totally
> different from the standard 8 IO signal controls. 

I'm not certain if this is what you're looking for, but the iPAQ h1910 has 
NAND connected to the address pins. (Is this what you mean?) Take a look at 
the NAND code in handhelds.org CVS (module linux/kernel26, I think, although 
if h1910 flash is not an option there, try module linux/kernel) - it's just 
standard MTD NAND, except with some changes not to do moronic caching of 
IO_ADDR_R and IO_ADDR_W. (You can also look at the 1910 flash driver to see 
how I change IO_ADDR_R/W based on ALE and CLE.)

/j

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
Quote       | <lilo> I akilled *@* by mistake
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/mII5Pn9tWOqA4LMRAvDuAKCLJ0Oq1P9lJpvWdZFSEkR+scf0BACgkXI4
1A7evWeG40v8DYM8dsUI9nU=
=/6q9
-----END PGP SIGNATURE-----



From dwmw2 at infradead.org  Fri Oct 24 03:39:32 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 24 Oct 2003 08:39:32 +0100
Subject: Different nand interface
In-Reply-To: <200310232136.58256.joshua@joshuawise.com>
References: <3F984931.E6409ED7@mvista.com>
	 <200310232136.58256.joshua@joshuawise.com>
Message-ID: <1066981171.29915.581.camel@hades.cambridge.redhat.com>

On Thu, 2003-10-23 at 21:36 -0400, Joshua Wise wrote:
> I'm not certain if this is what you're looking for, but the iPAQ h1910 has 
> NAND connected to the address pins. (Is this what you mean?) Take a look at 
> the NAND code in handhelds.org CVS (module linux/kernel26, I think, although 
> if h1910 flash is not an option there, try module linux/kernel) - it's just 
> standard MTD NAND, except with some changes not to do moronic caching of 
> IO_ADDR_R and IO_ADDR_W. (You can also look at the 1910 flash driver to see 
> how I change IO_ADDR_R/W based on ALE and CLE.)

Urgh. I suspect I already fixed the interface between nand.c and the
board drivers so you don't need to do that... if not I'll fix it some
more.


-- 
dwmw2



From dwmw2 at infradead.org  Fri Oct 24 03:41:33 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 24 Oct 2003 08:41:33 +0100
Subject: Different nand interface
In-Reply-To: <3F984931.E6409ED7@mvista.com>
References: <3F984931.E6409ED7@mvista.com>
Message-ID: <1066981292.29915.584.camel@hades.cambridge.redhat.com>

On Thu, 2003-10-23 at 14:33 -0700, Alice Hennessy wrote:
> Hi,
> 
> I need some advice on how to support a board that has a hardware state
> machine that creates a parallel bus style interface to the NAND chip. 
> It is totally different from the standard 8 IO signal controls.   It
> can do write_byte and read_byte put requires the offset into the flash
> as a parameter.    nand.c is fairly modular, allowing several
> functions to be coded in the hardware file but there is no current
> method of passing an offset into, say, read_byte and write_byte unless
> the nand_chip priv field
> can be used (via mtd->priv).   Do you think the standard nand.c can be
> used in this case or should I create a specific one for this board?

S'difficult to say without knowing more details of the hardware in
question. What does it _do_ with the address lines in question? Are you
at least looking at the current code which has read_buf() functions?

Even the DiskOnChip isn't this bizarre :)

-- 
dwmw2



From dwmw2 at infradead.org  Fri Oct 24 03:44:32 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 24 Oct 2003 08:44:32 +0100
Subject: Building jffs2 utils?
In-Reply-To: <3F983694.1060005@tait.co.nz>
References: <3F983694.1060005@tait.co.nz>
Message-ID: <1066981471.29915.589.camel@hades.cambridge.redhat.com>

On Fri, 2003-10-24 at 09:14 +0000, Robin Gilks wrote:
> Greetings
> 
> Can someone give a clue as to the correct way to cross compile the utils 
> directory? Its find just running make using my existing (Mandrake 9.1 
> based) i386 system but a cross compile to powerpc-uclibc fails miserably 
> on any jffs2 tools due to the zlib stuff not being found.

Cross-compile zlib first?

-- 
dwmw2



From dwmw2 at infradead.org  Fri Oct 24 03:48:22 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 24 Oct 2003 08:48:22 +0100
Subject: jffs2  on Ecos: multi task access and defragmentation
In-Reply-To: <NFBBKFLAIMMPNKJONACNKEAECEAA.armelle.potier@elios-informatique.fr>
References: 
	 <NFBBKFLAIMMPNKJONACNKEAECEAA.armelle.potier@elios-informatique.fr>
Message-ID: <1066981701.29915.594.camel@hades.cambridge.redhat.com>

On Thu, 2003-10-23 at 10:52 +0100, Armelle Potier wrote:
> 2 questions:
> 1 - How must be used jffs2 with many task calling it for read-write-erase
> operations on different or same files or directory
> Is it managed correctly by jffs2 and how (tasks blocked if necessary for
> example) or have the task to care for multi access and then how?

JFFS2 does locking internally, using semaphore and spinlock primitives
under Linux.

In the eCos build, I believe those locking primitives should also work;
they're mapped to mutexes (mutices?) and NOP respectively -- but they're
largely untested because the eCos tests so far have all been
single-threaded.

> 2 - does jffs2 need defragmentation functionnality ? If yes how to use this
> service if it's exist.

JFFS2 doesn't need defragmentation. However, if you're using a
thread-capable build of eCos you could usefully implement the background
garbage collection thread for eCos. Take a look at background.c and make
a background-ecos.c which does something similar.

-- 
dwmw2



From dwmw2 at infradead.org  Fri Oct 24 03:50:08 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 24 Oct 2003 08:50:08 +0100
Subject: 2.2.18 status + jffs2
In-Reply-To: <200310232040.23006.david@avoncliff.com>
References: <200310232040.23006.david@avoncliff.com>
Message-ID: <1066981807.29915.597.camel@hades.cambridge.redhat.com>

I'd be reluctant to talk to you if it was 2.4.18 you were using.
2.2.18 is just too old.

Someone did work on backporting JFFS2 to the 2.2 kernel a couple of
years ago. If I recall correctly, last time I asked, he'd abandoned the
effort since it no longer made any sense to be using 2.2.

Update your kernel.

-- 
dwmw2



From tharbaugh at lnxi.com  Thu Oct 23 11:56:44 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 23 Oct 2003 09:56:44 -0600
Subject: Regression of mtd/chips/jedec_probe.c in 2.6.0-test7
In-Reply-To: <001201c398fe$b6d567a0$d203b60f@duckduck>
References: <001201c398fe$b6d567a0$d203b60f@duckduck>
Message-ID: <1066924604.6281.205.camel@tubarao>

On Wed, 2003-10-22 at 18:43, Christopher Hoover wrote:
> > There's one more fragment where cfi->device_type should
> > revert back to CFI_DEVICETYPE_X8
> 
> OK, now I'm confused.  Revert *back* to CFI_DEVICETYPE_X8?
> 
> I though we were going the other direction.

Okay, I didn't read the patch hunks very closely.  We really want to
move *from* cfi->device_type *to* CFI_DEVICETYPE_X8.  Do me a favor,
check out jedec_probe.c v1.36 from CVS and try that - yes, I know,
you've already mentioned that v1.32 worked, but trying 1.36 will be
helpful.

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031023/47e87b5a/attachment.bin 

From tharbaugh at lnxi.com  Thu Oct 23 12:13:45 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 23 Oct 2003 10:13:45 -0600
Subject: Regression of mtd/chips/jedec_probe.c in 2.6.0-test7
In-Reply-To: <000001c398ec$81bc7020$d203b60f@duckduck>
References: <000001c398ec$81bc7020$d203b60f@duckduck>
Message-ID: <1066925625.6281.211.camel@tubarao>

Now that I've been unhelpful, if not confusing, I figure I should look
at your emails a bit closer.

On Wed, 2003-10-22 at 16:33, Christopher Hoover wrote:

> Search for id:(01 225b) interleave(1) type(2)
> Search for id:(01 225b) interleave(1) type(2)

This is the manufacturer and device id for the AM29LV800BB.

01 = AMD
225b = AM29LV800BB in x16 mode.

If that's correct, why doesn't it find it?  Have you tried turning on
debug and setting it to 3?

> Search for id:(70 e3a0) interleave(1) type(2)
> Search for id:(01 5b) interleave(2) type(1)
> Search for id:(01 5b) interleave(2) type(1)

01 = AMD
5b = AM29LV800BB in x8 mode.

Once again, why isn't the chip found?

> Search for id:(70 a0) interleave(2) type(1)
> Search for id:(70 f10) interleave(2) type(2)
> Search for id:(70 f10) interleave(2) type(2)
> Search for id:(70 f10) interleave(2) type(2)
> JEDEC: Found no ceiva flash device at location zero
                  ^^^^^
Looks like a Polaroid camera?

> clps_setup_mtd: do_map_probe failed to find flash

We nee the debug verbosity turned up for jedec_probe.  Hopefully that
will tell us why jedec_match() (I believe) is failing.

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20031023/13738e04/attachment.bin 

From selwyn at hectrix.com  Fri Oct 24 05:16:55 2003
From: selwyn at hectrix.com (Selwyn Tang)
Date: Fri, 24 Oct 2003 17:16:55 +0800
Subject: Setting up compressed rootfs on DOC
Message-ID: <3F98EE07.20006@hectrix.com>

Hi all,

I am used to running a DOC patched grub firmware on my DOC 2000 (16MB)
with nftl, following the instructions of Karim's book. Since the space
is running out, I am interested in using a compressed root fs.

I followed mtd-jffs-HOWTO.txt (1.16) to build a compressed root fs on
DOC. That is, I copied my root fs to a ramdisk, dd'd it through gzip to
a compressed gz file, dd'd it to an offset of 1MB on /dev/mtd0 and
rdev'd the kernel image (967KB) about the offset and the device to be
used. Then I came to a problem of how to install the kernel on the DOC.

The HOWTO says I can use any boot loader, like lilo, to install the
kernel, or just place the kernel on the device and boot from it
directly. I got confused here, as I am used to using a grub firmware,
which hooks to int 19h as a bios extension. When it is booted, it
understands the DOC and can load my kernel image from my root fs on the
ext2 partition on the DOC.

But in here, how should I install my kernel image? I tried dd'ing it to
the start of my DOC, like creating a boot floppy, but it doesn't seem
like a boot device to the bios. Should I still install a grub firmware
and a small partition for storing my kernel image, and then dd my
compressed root fs after the partition? Or is there any other more
clever ways?

Selwyn



From david at avoncliff.com  Fri Oct 24 07:05:06 2003
From: david at avoncliff.com (david stevenson)
Date: Fri, 24 Oct 2003 12:05:06 +0100
Subject: 2.2.18 status + jffs2
In-Reply-To: <1066981807.29915.597.camel@hades.cambridge.redhat.com>
References: <200310232040.23006.david@avoncliff.com>
	<1066981807.29915.597.camel@hades.cambridge.redhat.com>
Message-ID: <200310241205.06646.david@avoncliff.com>

On Friday 24 October 2003 8:50 am, David Woodhouse wrote:
> I'd be reluctant to talk to you if it was 2.4.18 you were using.
> 2.2.18 is just too old.
>
> Someone did work on backporting JFFS2 to the 2.2 kernel a couple of
> years ago. If I recall correctly, last time I asked, he'd abandoned the
> effort since it no longer made any sense to be using 2.2.
>
> Update your kernel.

OK, not the reply I had hoped for but understood.

Can I propose the documentation needs updating to this status.
In ftp.infradead.org/pub/mtd/patches a readme to say the 2.2.x is no longer 
supported. And changes to the mtd-jffs-HOWTO.txt where specific instructions 
how to use 2.2.18 are given.
David



From Subashk at ami.com  Fri Oct 24 08:39:12 2003
From: Subashk at ami.com (Subash Kalbarga)
Date: Fri, 24 Oct 2003 08:39:12 -0400
Subject: amd_flash.c faster than cfi_cmdset_0002.c
Message-ID: <8CCBDD5583C50E4196F012E79439B45C046EBB01@atl-ms1.megatrends.com>


Hi all

We have an AM29LV641MH 8 meg flash on board and looking at performance,
using amd_flash.c seems to make things considerably faster when writing to
the flash.

I am using the 2.4.18 kernel.

Is there a particular reason?

It seems do_amd_onewrite seems to wait for a standard timeout period?
Chip->write_delay and then udelays of 10 seconds when reading back status?

Do later versions address this?

I am worried because amd_flash.c is obsoleted. Is it advisable to use it?

Thanks in advance

Subash Kalbarga




From tharbaugh at lnxi.com  Fri Oct 24 10:19:04 2003
From: tharbaugh at lnxi.com (Thayne Harbaugh)
Date: 24 Oct 2003 08:19:04 -0600
Subject: amd_flash.c faster than cfi_cmdset_0002.c
In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C046EBB01@atl-ms1.megatrends.com>
References: 
	 <8CCBDD5583C50E4196F012E79439B45C046EBB01@atl-ms1.megatrends.com>
Message-ID: <1067005143.6281.245.camel@tubarao>

On Fri, 2003-10-24 at 06:39, Subash Kalbarga wrote:
> Hi all
> 
> We have an AM29LV641MH 8 meg flash on board and looking at performance,
> using amd_flash.c seems to make things considerably faster when writing to
> the flash.
> 
> I am using the 2.4.18 kernel.

The first thing I recommend is moving to something newer: both kernel
and MTD drivers.  The latest version of cfi_cmdset_0002.c is r1.91.  I
have no idea what is in the 2.4.18 kernel (and I'm too lazy to go find
out).

Once you do some testing with the latest version then we will have a
basis for performance comparison.  Let me know what you find.

-- 
Thayne Harbaugh
Linux Networx



From manningc2 at actrix.gen.nz  Sat Oct 25 03:29:25 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Sat, 25 Oct 2003 20:29:25 +1300
Subject: Different nand interface
In-Reply-To: <3F984931.E6409ED7@mvista.com>
References: <3F984931.E6409ED7@mvista.com>
Message-ID: <20031025072323.378625DF3@blood.actrix.co.nz>

On Friday 24 October 2003 10:33, Alice Hennessy wrote:
> Hi,
>
> I need some advice on how to support a board that has a hardware state
> machine
> that creates a parallel bus style interface to the NAND chip.  It is
> totally
> different from the standard 8 IO signal controls.   It can do write_byte
> and read_byte
> put requires the offset into the flash as a parameter.    nand.c is
> fairly modular, allowing
> several functions to be coded in the hardware file but there is no
> current method of
> passing an offset into, say, read_byte and write_byte unless the
> nand_chip priv field
> can be used (via mtd->priv).   Do you think the standard nand.c can be
> used in this
> case or should I create a specific one for this board?
>
> Any advice would be appreciated.

I would expect the existing nand.c can be used though you might have to do 
some clever stuff to hide your flash behind it.

This is definitely the prefered way to get going in the beginning because it 
will help comparmentalise things that inevitably go wrong when bringing up 
new hardware.

Once your system is up and running you might find that you want to replace 
nand.c for efficiency reasons or whatever, but quite likely this won't be 
required (and at least you'll have a way better understanding of where you 
need to go).

G'luck

-- CHarles


From ccedeno at speedsurf.pacific.net.ph  Sun Oct 26 14:16:40 2003
From: ccedeno at speedsurf.pacific.net.ph (Charles)
Date: Mon, 27 Oct 2003 03:16:40 +0800
Subject: Genuine Profitable Opportunity!
Message-ID: <20031026191422Z19023-19313+35194@humbolt.nl.linux.org>

Hello, 
 
There's a revolutionary money making phenomenon
 that is spreading across the Internet like WILDFIRE!
 
And right now, for a very limited time, YOU have the 
opportunity to be right at the FRONT of it.
 
But time is of the essence; you need to LOCK IN 
YOUR POSITION NOW!!!
 
DON'T WAIT ANOTHER SECOND!!
 
Send email to charlesjlc at indiatimes.com with 
the subject "Register me as an Associate Member." 
with your Firstname, Lastname, Tel#, and Country. 
Registration is FREE...

If you allow this incredible, once-in-a-lifetime opportunity 
to pass you by, you'll forever regret the decision. 
 
Be an Associate Member and evaluate the program 
and surely you will discover what you have been dreaming of.
 
The time to act is now!
 
Not tomorrow... not someday... but right here, RIGHT NOW!
 
Regards,
 
Charles
charlesjlc at indiatimes.com


From Abhishek.Karoliya at fci.com  Sun Oct 26 15:00:52 2003
From: Abhishek.Karoliya at fci.com (Karoliya, Abhishek)
Date: Mon, 27 Oct 2003 01:30:52 +0530
Subject: Intel K3 Flash + MTD
Message-ID: <903E17B6FF22A24C96B4E28C2C0214D7012BB2D8@sr-bng-exc01.int.tsbu.net>

Hi All,
  
     I am using an Intel 128k3 flash chips {4 chips in total with each pair
forming a 32MB capacity} on a PMC board having powerpc 7447 + marvel 64360
combination . I running Linux from kernel.org 2.4.20 version.
         I can erase and write to flash without any problems . But once
written to flash when I reboot and  read back {using the mtd utils } it just
returns 0x80 for all location. 
   I am pretty sure that write is successful as I burn my image and ramdisk
into the flash from Linux and can reboot the board using these flash
contents. Also I have taken care that the flash is unlocked every time by
writing the unlock pattern to the flash  through the init code in the mtd
map file.
   Is the cache playing some havoc??
Please provide some pointers in the direction of resolution of this problem.

thanks a million
Abhishek

 

   


From chuckmeade at mindspring.com  Sun Oct 26 15:17:35 2003
From: chuckmeade at mindspring.com (Chuck Meade)
Date: Sun, 26 Oct 2003 15:17:35 -0500
Subject: Intel K3 Flash + MTD
In-Reply-To: <903E17B6FF22A24C96B4E28C2C0214D7012BB2D8@sr-bng-exc01.int.tsbu.net>
Message-ID: <IIEEICKJLNEPBBDJICNGGEICEBAA.chuckmeade@mindspring.com>

That sounds like the status bit that you are reading back.
Most flashes give back status after you issue them commands
(like all of your unlocks, for instance).  Usually you put them 
back into "read mode" by writing a particular byte to them
after reading the status.  Try writing an FF to the flash.
Check your flash chip's datasheet for the exact sequence that
you must use to put it back in read mode.

Chuck Meade

> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org
> [mailto:linux-mtd-bounces at lists.infradead.org]On Behalf Of Karoliya,
> Abhishek
> Sent: Sunday, October 26, 2003 3:01 PM
> To: 'linux-mtd at lists.infradead.org'
> Subject: Intel K3 Flash + MTD
> 
> 
> Hi All,
>   
>      I am using an Intel 128k3 flash chips {4 chips in total with each pair
> forming a 32MB capacity} on a PMC board having powerpc 7447 + marvel 64360
> combination . I running Linux from kernel.org 2.4.20 version.
>          I can erase and write to flash without any problems . But once
> written to flash when I reboot and  read back {using the mtd utils } it just
> returns 0x80 for all location. 
>    I am pretty sure that write is successful as I burn my image and ramdisk
> into the flash from Linux and can reboot the board using these flash
> contents. Also I have taken care that the flash is unlocked every time by
> writing the unlock pattern to the flash  through the init code in the mtd
> map file.
>    Is the cache playing some havoc??
> Please provide some pointers in the direction of resolution of this problem.
> 
> thanks a million
> Abhishek
> 
>  
> 
>    
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From xiuzhanyu at yulong.com  Mon Oct 27 01:15:45 2003
From: xiuzhanyu at yulong.com (=?gb2312?B?0N7VvdPu?=)
Date: Mon, 27 Oct 2003 14:15:45 +0800
Subject: JFFS2 on SMDK2410 with Mizi Linux...
Message-ID: <4E9160487E71D944A7422391941AF4024CF4EB@MAIL.yulong.com>

>Hello All,

>I am trying to port JFFS2 on a SMDK2410 board based on S3c2410
>processor.I am using Mizi Linux on the board but as the Mizi as only
>Cramfs support i am trying to port Jffs2 as a rw system, I have included
>the JFFS2 fs in my kernel and is it possible for me to mount the JFFS2
>on top of a bon system like mount -t jffs2 /dev/bon/3 /mnt as a read
>write partition ?.Pls advice me on this.



>Thanks and Regards
>sivam


hello sivam:

do you solute this problum ? can you tell me  the solution ?





From mariusp at ist.co.za  Mon Oct 27 07:47:44 2003
From: mariusp at ist.co.za (Marius Prinsloo)
Date: Mon, 27 Oct 2003 14:47:44 +0200
Subject: AMPRO Core Module w/ DoC onboard
Message-ID: <7630720F88260942B48ED844E600ADAE0BA3F3@ist.co.za>

Hi Nick do you sitll have P5fromat utility.
Could  I please have a copy 
Regards
Marius 


From simon at baydel.com  Mon Oct 27 10:45:28 2003
From: simon at baydel.com (simon at baydel.com)
Date: Mon, 27 Oct 2003 15:45:28 -0000
Subject: SmartMedia FAT
Message-ID: <3F9D3D98.6453.14E703@localhost>

I would like to be able to access FAT partitions on a SMC via Linux. Curently the 
hardare loads its' configuration and boots the hardware from files on a FAT partition. 
The hardware itself has no hardware flash translation layer. The SMC has been 
created on a USB device which contains a flash translation layer conforming to the 
SFFDC standard. After this a JFFS2 root is mounted. It would be nice if I could 
change the hardware and boot files from Linux but I have been unable to find any 
reliable way of accessing the FAT filesystem.

As far as I understand, from the information I have read, I would need to create  a 
block driver which contained a SSFDC compatible translation layer ? In the nand 
FAQ it mentions SmartMedia FAT. I have been unable to find how this is 
implemented. Has anyone implemented this yet ?

I would like to know if my assumptions are correct. If so I guess there are many ways 
this could be achieved. 

1. Wrirte my on block driver ?
2. Bolt on some bits to mtdblock ?
3. As I don't do this all the time write a user app to update via /dev/mtd

All comments welcome.


Many Thanks

Simon.__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon at baydel.com
__________________________



From andrzej.mialkowski at inetia.pl  Mon Oct 27 10:25:57 2003
From: andrzej.mialkowski at inetia.pl (andrzej.mialkowski at inetia.pl)
Date: Mon, 27 Oct 2003 16:25:57 +0100
Subject: [PATCH] parse_redboot_partitions not always works correctly
Message-ID: <1067268357.3f9d3905c3fc9@imail.internetia.pl>

Hi,
 I just found that redboot_parse_partitions on my system (IXDP2801) builds 
incorrect list of partitions, base addresses of some partitions are wrong. I 
located a problem in following line in redboot.c:
		buf[i].flash_base &= master->size-1;
This line tries to relocate partition base address to be 0 based, by cutting 
off some high order bits. This expression works correctly if two assumptions 
are true:
 1) master->size should be power of 2
 2) base address must be aligned to map size
Unfortunately on my board both are false: I have 10 flash chips, and base 
address is not aligned to size even after number of chips align to 16 (because 
of banking).

On different platforms I sow different use of flash base address. Some platforms
are using 0 based addresses in redboot some other physical address of flash 
chip (my case). As far as I know base address used for building partition 
entries is not stored.

The most portable method that I found is use "FIS directory" entry for guessing 
value of flash base used during building partitions. Assumption here is simple:
FIS directory is located in known place at MTD level, in last erase block of 
map. Subtracting flash base address stored in this entry with actual location 
at map driver offset level should give base address used during creating 
partition table.
Of course all partition entries must be created with the same flash base 
address.
Did anybody have better idea? Patch attached.
Thanks in advance for comments.

	Andrzej Mialkowski

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mtd-redboot-parse.patch
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20031027/1e59a008/attachment.pl 

From jsun at mvista.com  Mon Oct 27 13:17:41 2003
From: jsun at mvista.com (Jun Sun)
Date: Mon, 27 Oct 2003 10:17:41 -0800
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031022182558.U19834@mvista.com>;
	from jsun@mvista.com on Wed, Oct 22, 2003 at 06:25:58PM -0700
References: <20031022182558.U19834@mvista.com>
Message-ID: <20031027101741.C1678@mvista.com>

On Wed, Oct 22, 2003 at 06:25:58PM -0700, Jun Sun wrote:
> 
> While looking at drvers/mtd/maps directories, it becomes
> obvious to me that many files are derived from physmap.c,
> in order to add partition support or add their own
> set_vpp() pointer, etc..
> 
> Such a need can be easily satisfied by extending physmap.c
> a little.
> 
> In this patch, I like to introduce phsmap_add_partition()
> function, which allows boards to add flash partitions
> at run-time.  (Note that you can still override this
> hardcoded partition by using kernel command line)
> 
> In the patch I also showed how a board can make use of this
> extension.  Hopefully we can get rid of lots of files under 
> the maps directory. :)
> 
> Boards which need to set set_vpp pointer can do so easily
> too.
> 
> Any comments?
>

Any objections or comments?  David?

Jun
 

> diff -Nru linux/arch/mips/mips-boards/malta/malta_setup.c.orig linux/arch/mips/mips-boards/malta/malta_setup.c
> --- linux/arch/mips/mips-boards/malta/malta_setup.c.orig	Fri Aug  1 10:50:18 2003
> +++ linux/arch/mips/mips-boards/malta/malta_setup.c	Wed Oct 22 17:26:24 2003
> @@ -24,6 +24,7 @@
>  #ifdef CONFIG_BLK_DEV_IDE
>  #include <linux/ide.h>
>  #endif
> +#include <linux/mtd/physmap.h>
>  
>  #include <asm/cpu.h>
>  #include <asm/bootinfo.h>
> @@ -166,6 +167,12 @@
>          conswitchp = &dummy_con;
>  #endif
>  #endif
> +
> +#if defined(CONFIG_MTD_PHYSMAP) && defined(CONFIG_MTD_PARTITIONS)
> +	physmap_add_partition("YAMON", 0x100000, 0x0, MTD_WRITEABLE);
> +	physmap_add_partition("User FS", 0x300000, 0x100000, 0);
> +#endif
> +
>  	mips_reboot_setup();
>  
>  	board_time_init = mips_time_init;
> diff -Nru linux/drivers/mtd/maps/physmap.c.orig linux/drivers/mtd/maps/physmap.c
> --- linux/drivers/mtd/maps/physmap.c.orig	Wed Jul 23 15:17:52 2003
> +++ linux/drivers/mtd/maps/physmap.c	Wed Oct 22 17:42:50 2003
> @@ -2,6 +2,11 @@
>   * $Id: physmap.c,v 1.28 2003/05/28 15:53:43 dwmw2 Exp $
>   *
>   * Normal mappings of chips in physical memory
> + *
> + * Copyright (C) 2003 MontaVista Software Inc.
> + * Author: Jun Sun, jsun at mvista.com or jsun at junsun.net
> + *
> + * 031022 - [jsun] add physmap_add_partition()
>   */
>  
>  #include <linux/module.h>
> @@ -23,7 +28,7 @@
>  
>  
>  struct map_info physmap_map = {
> -	.name = "Physically mapped flash",
> +	.name = "phys_mapped_flash",
>  	.size = WINDOW_SIZE,
>  	.buswidth = BUSWIDTH,
>  	.phys = WINDOW_ADDR,
> @@ -33,35 +38,31 @@
>  static struct mtd_partition *mtd_parts;
>  static int                   mtd_parts_nb;
>  
> -static struct mtd_partition physmap_partitions[] = {
> -#if 0
> -/* Put your own partition definitions here */
> -	{
> -		.name =		"bootROM",
> -		.size =		0x80000,
> -		.offset =	0,
> -		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
> -	}, {
> -		.name =		"zImage",
> -		.size =		0x100000,
> -		.offset =	MTDPART_OFS_APPEND,
> -		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
> -	}, {
> -		.name =		"ramdisk.gz",
> -		.size =		0x300000,
> -		.offset =	MTDPART_OFS_APPEND,
> -		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
> -	}, {
> -		.name =		"User FS",
> -		.size =		MTDPART_SIZ_FULL,
> -		.offset =	MTDPART_OFS_APPEND,
> +#define NUM_PARTITIONS	4	/* random num which should be good enough */
> +static struct mtd_partition physmap_partitions[NUM_PARTITIONS] __initdata = {};
> +
> +char *part_probes[] __initdata = {"cmdlinepart", "RedBoot", NULL};
> +
> +/*
> + * See include/linux/mtd/physmap.h file.
> + */
> +static int part_index __initdata = 0;
> +int __init physmap_add_partition(char *name, u32 size, u32 offset, u32 flags)
> +{
> +	if (part_index >= NUM_PARTITIONS) {
> +		printk(KERN_ERR "physmap_add_partition() exceeds max partition table size (%d)\n", NUM_PARTITIONS);
> +		return -1;
>  	}
> -#endif
> -};
>  
> -#define NUM_PARTITIONS	(sizeof(physmap_partitions)/sizeof(struct mtd_partition))
> -const char *part_probes[] = {"cmdlinepart", "RedBoot", NULL};
> +	physmap_partitions[part_index].name = name;
> +	physmap_partitions[part_index].size = size;
> +	physmap_partitions[part_index].offset = offset;
> +	physmap_partitions[part_index].mask_flags = flags;
> +
> +	part_index++;
>  
> +	return 0;
> +}
>  #endif /* CONFIG_MTD_PARTITIONS */
>  
>  int __init init_physmap(void)
> @@ -97,11 +98,11 @@
>  			return 0;
>  		}
>  
> -		if (NUM_PARTITIONS != 0) 
> +		if (part_index != 0) 
>  		{
>  			printk(KERN_NOTICE 
>  			       "Using physmap partition definition\n");
> -			add_mtd_partitions (mymtd, physmap_partitions, NUM_PARTITIONS);
> +			add_mtd_partitions (mymtd, physmap_partitions, part_index);
>  			return 0;
>  		}
>  
> diff -Nru linux/include/linux/mtd/physmap.h.orig linux/include/linux/mtd/physmap.h
> --- linux/include/linux/mtd/physmap.h.orig	Wed Oct 22 17:05:22 2003
> +++ linux/include/linux/mtd/physmap.h	Wed Oct 22 18:20:34 2003
> @@ -0,0 +1,48 @@
> +/*
> + * For boards with physically mapped flash and using 
> + * drivers/mtd/maps/physmap.c mapping driver.
> + *
> + * Copyright (C) 2003 MontaVista Software Inc.
> + * Author: Jun Sun, jsun at mvista.com or jsun at junsun.net
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#ifndef __LINUX_MTD_PHYSMAP__
> +
> +#include <linux/config.h>
> +
> +#if defined(CONFIG_MTD_PHYSMAP) 
> +
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/map.h>
> +
> +/*
> + * The map_info for physmap.  Board can override size, buswidth, phys,
> + * (*set_vpp)(), etc in their initial setup routine.
> + */
> +extern struct map_info physmap_map;
> +
> +#if defined(CONFIG_MTD_PARTITIONS)
> +
> +/*
> + * Machines that wish to do flash partition may want to call this function in 
> + * their setup routine.  Examples:
> + *
> + *	physmap_add_partition("bootROM", 0x100000, 0, MTD_WRITEABLE);
> + *	physmap_add_partition("User FS", 0x300000, 0x100000, 0)
> + *
> + * Note that one can always override this hard-coded partition with 
> + * command line partition (you need to enable CONFIG_MTD_CMDLINE_PARTS).
> + */
> +int physmap_add_partition(char *name, u32 size, u32 offset, u32 mask_flags);
> +
> +#endif /* defined(CONFIG_MTD_PARTITIONS) */
> +#endif /* defined(CONFIG_MTD) */
> +
> +#endif /* __LINUX_MTD_PHYSMAP__ */
> +



From ahennessy at mvista.com  Mon Oct 27 13:25:44 2003
From: ahennessy at mvista.com (Alice Hennessy)
Date: Mon, 27 Oct 2003 10:25:44 -0800
Subject: Different nand interface
References: <3F984931.E6409ED7@mvista.com>
	<1066981292.29915.584.camel@hades.cambridge.redhat.com>
Message-ID: <3F9D6328.547A39A6@mvista.com>

David Woodhouse wrote:

> On Thu, 2003-10-23 at 14:33 -0700, Alice Hennessy wrote:
> > Hi,
> >
> > I need some advice on how to support a board that has a hardware state
> > machine that creates a parallel bus style interface to the NAND chip.
> > It is totally different from the standard 8 IO signal controls.   It
> > can do write_byte and read_byte put requires the offset into the flash
> > as a parameter.    nand.c is fairly modular, allowing several
> > functions to be coded in the hardware file but there is no current
> > method of passing an offset into, say, read_byte and write_byte unless
> > the nand_chip priv field
> > can be used (via mtd->priv).   Do you think the standard nand.c can be
> > used in this case or should I create a specific one for this board?
>
> S'difficult to say without knowing more details of the hardware in
> question. What does it _do_ with the address lines in question? Are you
> at least looking at the current code which has read_buf() functions?
>
> Even the DiskOnChip isn't this bizarre :)
>
> --
> dwmw2

Yes, I am looking at the current code which is more modular so it gives me
hope.
There are 2 nand chips on the board.  If you want to read from the 0x100th
byte
on chip 1 you need to do readb(chip1_base + 0x100);  if you want to write
the 0x10000th byte on chip 2 you need to do writeb(chip2_base +
0x10000,bytedata).
The chips are 16M X 8 bit and  are mapped in a contiguous 32 M byte memory
space
with 0-16M for chip1 and 16-32M for chip2.

Alice




From dwmw2 at infradead.org  Mon Oct 27 15:00:06 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 27 Oct 2003 20:00:06 +0000
Subject: Different nand interface
In-Reply-To: <3F9D6328.547A39A6@mvista.com>
References: <3F984931.E6409ED7@mvista.com>
	 <1066981292.29915.584.camel@hades.cambridge.redhat.com>
	 <3F9D6328.547A39A6@mvista.com>
Message-ID: <1067284806.16241.2.camel@imladris.demon.co.uk>

On Mon, 2003-10-27 at 10:25 -0800, Alice Hennessy wrote (modulo newlines):
> Yes, I am looking at the current code which is more modular so it
> gives me hope.
> There are 2 nand chips on the board.  If you want to read from the
> 0x100th byte on chip 1 you need to do readb(chip1_base + 0x100);  if
> you want to write the 0x10000th byte on chip 2 you need to do
> writeb(chip2_base + 0x10000,bytedata).
> The chips are 16M X 8 bit and  are mapped in a contiguous 32 M byte
> memory space with 0-16M for chip1 and 16-32M for chip2.

That's weird. How are the out-of-band areas accessed? How do you send
commands like READ_ID and ERASE?

-- 
dwmw2




From manningc2 at actrix.gen.nz  Mon Oct 27 15:34:16 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Tue, 28 Oct 2003 09:34:16 +1300
Subject: SmartMedia FAT
In-Reply-To: <3F9D3D98.6453.14E703@localhost>
References: <3F9D3D98.6453.14E703@localhost>
Message-ID: <20031027202807.DA4481A0A7@desire.actrix.co.nz>

On Tuesday 28 October 2003 04:45,  wrote:
> I would like to be able to access FAT partitions on a SMC via Linux.
> Curently the hardare loads its' configuration and boots the hardware from
> files on a FAT partition. The hardware itself has no hardware flash
> translation layer. The SMC has been created on a USB device which contains
> a flash translation layer conforming to the SFFDC standard. After this a
> JFFS2 root is mounted. It would be nice if I could change the hardware and
> boot files from Linux but I have been unable to find any reliable way of
> accessing the FAT filesystem.

Ok, I'll first remind you that a SmardMedia card is just NAND flash and you 
can use it with a NAND file system like YAFFS or JFFS2.

I'll also warn you that running FAT on SmartMedia is far from reliable and is 
slow (relative to YAFFS and, I expect, JFFS2).

The rest of my response assumes that you have a valid reason to use FAT + 
SMartMedia (eg. need to share files with a SmartMedia-equipped device).

Iyf you are just using SMC to load images from a PC into an embedded system, 
then you're likely going to get the best result by using YAFFS or JFFS2 and 
just using a simple copy process on the host to copy a YAFFS/JFFS2 image onto 
the SmartMedia card. ie a process like:

* Generate a YAFFS image with mkyaffsimage.
* Copy the image onto the SMC with a program derived from mkyaffs.
* Stuff into your embedded system and boot YAFFS.

>
> As far as I understand, from the information I have read, I would need to
> create  a block driver which contained a SSFDC compatible translation layer
> ? In the nand FAQ it mentions SmartMedia FAT. I have been unable to find
> how this is implemented. Has anyone implemented this yet ?

As I understand it, the SMC FAT format differs slightly from regular FAT. I 
don't know of any Linux implementations.

The Samsung www has various info on the formats. The SSFDC www has some specs 
too. The yaffs_ecc.c ECC code (in the YAFFS CVS)  does SMC compliant ECC 
calcs.


> I would like to know if my assumptions are correct. If so I guess there are
> many ways this could be achieved.
>
> 1. Wrirte my on block driver ?

Currently the md block driver is just a way to get from a name in /dev to the 
internal kernel structures so that it can be used by a flash file system. It 
does not supply full block driver functionality.

A SmartMedia block driver does bad block management, ECC and logical to 
physical block mapping. 


> 2. Bolt on some bits to mtdblock ?

I guess this could be added to mtdblock, but is probably best done as a new 
block driver that uses mtdblock under the hood. Why? Because probably nobody 
really wants all this extra stuff added to mtdblock.

> 3. As I don't do this all the time write a user app to update via /dev/mtd

I guess that's a possibility, but seems like some hard work. Likely a 
YAFFS/JFFS2 path would be simpler.



From ahennessy at mvista.com  Mon Oct 27 15:43:48 2003
From: ahennessy at mvista.com (Alice Hennessy)
Date: Mon, 27 Oct 2003 12:43:48 -0800
Subject: Different nand interface
References: <3F984931.E6409ED7@mvista.com>
	<1066981292.29915.584.camel@hades.cambridge.redhat.com>
	<1067284806.16241.2.camel@imladris.demon.co.uk>
Message-ID: <3F9D8384.ABC9FD4@mvista.com>

David Woodhouse wrote:

> On Mon, 2003-10-27 at 10:25 -0800, Alice Hennessy wrote (modulo newlines):
> > Yes, I am looking at the current code which is more modular so it
> > gives me hope.
> > There are 2 nand chips on the board.  If you want to read from the
> > 0x100th byte on chip 1 you need to do readb(chip1_base + 0x100);  if
> > you want to write the 0x10000th byte on chip 2 you need to do
> > writeb(chip2_base + 0x10000,bytedata).
> > The chips are 16M X 8 bit and  are mapped in a contiguous 32 M byte
> > memory space with 0-16M for chip1 and 16-32M for chip2.
>
> That's weird. How are the out-of-band areas accessed? How do you send
> commands like READ_ID and ERASE?
>
> --
> dwmw2

The hardware logic uses register access for special commands.   Readid,
status does
2 writes to a register, one for address (to distinquish which flash), one for
command and one more
to read.  Erase takes 2 writes to a register, address then command.   The
out-of-band access
uses a register to give a command and then the out-of-band data is read using

readb with  offset.

Alice



From dwmw2 at infradead.org  Mon Oct 27 15:55:06 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 27 Oct 2003 20:55:06 +0000
Subject: Different nand interface
In-Reply-To: <3F9D8384.ABC9FD4@mvista.com>
References: <3F984931.E6409ED7@mvista.com>
	 <1066981292.29915.584.camel@hades.cambridge.redhat.com>
	 <3F9D6328.547A39A6@mvista.com>
	 <1067284806.16241.2.camel@imladris.demon.co.uk>
	 <3F9D8384.ABC9FD4@mvista.com>
Message-ID: <1067288106.16391.5.camel@imladris.demon.co.uk>

What is wrong with your mail user agent? It's customary to wrap lines at
seventy-something characters; not to wrap them at 90 then again at 70,
giving alternate 70-char and 20-char lines... :)

On Mon, 2003-10-27 at 12:43 -0800, Alice Hennessy wrote:
> The hardware logic uses register access for special commands.  
> Readid,
> status does
> 2 writes to a register, one for address (to distinquish which flash),
> one for
> command and one more
> to read.  Erase takes 2 writes to a register, address then command.  
> The
> out-of-band access
> uses a register to give a command and then the out-of-band data is
> read using
> 
> readb with  offset.

That's just bizarre. I don't think I want to ask _why_ they did this. 

You may be able to massage this into the generic NAND code; you can
override nand_command() completely. I suspect you won't be using much of
the generic code if you do that though. You might end up just writing a
standalone driver.

-- 
dwmw2




From ahennessy at mvista.com  Mon Oct 27 16:17:08 2003
From: ahennessy at mvista.com (Alice Hennessy)
Date: Mon, 27 Oct 2003 13:17:08 -0800
Subject: Different nand interface
References: <3F984931.E6409ED7@mvista.com>
	<1066981292.29915.584.camel@hades.cambridge.redhat.com>
	<3F9D6328.547A39A6@mvista.com>
	<1067284806.16241.2.camel@imladris.demon.co.uk>
	<1067288106.16391.5.camel@imladris.demon.co.uk>
Message-ID: <3F9D8B54.FFB44876@mvista.com>

David Woodhouse wrote:

> What is wrong with your mail user agent? It's customary to wrap lines at
> seventy-something characters; not to wrap them at 90 then again at 70,
> giving alternate 70-char and 20-char lines... :)
>
> On Mon, 2003-10-27 at 12:43 -0800, Alice Hennessy wrote:
> > The hardware logic uses register access for special commands.
> > Readid,
> > status does
> > 2 writes to a register, one for address (to distinquish which flash),
> > one for
> > command and one more
> > to read.  Erase takes 2 writes to a register, address then command.
> > The
> > out-of-band access
> > uses a register to give a command and then the out-of-band data is
> > read using
> >
> > readb with  offset.
>
> That's just bizarre. I don't think I want to ask _why_ they did this.
>
> You may be able to massage this into the generic NAND code; you can
> override nand_command() completely. I suspect you won't be using much of
> the generic code if you do that though. You might end up just writing a
> standalone driver.
>
> --
> dwmw2

I'll try to fix the email thing :-)

Thanks for the quick response.  I'll weigh the massage effort with any
future maintenance effort saved.

Alice





From dwmw2 at infradead.org  Mon Oct 27 17:29:22 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 27 Oct 2003 22:29:22 +0000
Subject: Different nand interface
In-Reply-To: <3F9D8B54.FFB44876@mvista.com>
References: <3F984931.E6409ED7@mvista.com>
	 <1066981292.29915.584.camel@hades.cambridge.redhat.com>
	 <3F9D6328.547A39A6@mvista.com>
	 <1067284806.16241.2.camel@imladris.demon.co.uk>
	 <3F9D8384.ABC9FD4@mvista.com>
	 <1067288106.16391.5.camel@imladris.demon.co.uk>
	 <3F9D8B54.FFB44876@mvista.com>
Message-ID: <1067293762.17740.0.camel@imladris.demon.co.uk>

On Mon, 2003-10-27 at 13:17 -0800, Alice Hennessy wrote:
> Thanks for the quick response.  I'll weigh the massage effort with any
> future maintenance effort saved.

Bear in mind I'm happy enough to make changes to the generic NAND
interface if they're going to be useful in general.

-- 
dwmw2




From dwmw2 at infradead.org  Tue Oct 28 05:50:15 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 28 Oct 2003 10:50:15 +0000
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031027101741.C1678@mvista.com>
References: <20031022182558.U19834@mvista.com>
	 <20031027101741.C1678@mvista.com>
Message-ID: <1067338214.15551.405.camel@hades.cambridge.redhat.com>

On Mon, 2003-10-27 at 10:17 -0800, Jun Sun wrote:
> Any objections or comments?  David?

Sorry for delayed response. I'm not really sure about this. Take a look
at drivers/mtd/maps/rpxlite.c -- that's what we're able to eliminate,
and we could even stick half of _that_ into a library function. 

I'm all for cleaning up all the duplication in the map drivers, but I'm
not sure we need to do it by making users enter correct numbers for
CONFIG_MTD_PHYSMAP_*...

-- 
dwmw2



From dwmw2 at infradead.org  Tue Oct 28 06:11:43 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 28 Oct 2003 11:11:43 +0000
Subject: SmartMedia FAT
In-Reply-To: <20031027202807.DA4481A0A7@desire.actrix.co.nz>
References: <3F9D3D98.6453.14E703@localhost>
	 <20031027202807.DA4481A0A7@desire.actrix.co.nz>
Message-ID: <1067339503.15551.429.camel@hades.cambridge.redhat.com>

Some SM adapters do the translation in firmware and present themselves
to the host as a real block device. You don't have any _choice_ but to
use the SMTL on those.

You don't actually have to use _FAT_ on that though, any more than you
_have_ to use FAT on floppies or DiskOnChip just because that's how they
are shipped. You could use ext3 or something else powerfail-safe. You
still have the inefficient journalling-on-journalling effect that you
get with all such fake-block-device arrangements, but it shouldn't
actually break before you wear the flash out.

Implementing SMTL really shouldn't be that hard. The mtd_blkdevs code in
CVS handles all the horridness of the Linux block layer for you and you
only need to write readsector() and writesector() routines. There's code
in drivers/usb/storage/sddr09.c which may help, since those devices make
the host do the translation.

-- 
dwmw2



From h.schurig at mn-logistik.de  Tue Oct 28 03:22:36 2003
From: h.schurig at mn-logistik.de (Holger Schurig)
Date: Tue, 28 Oct 2003 09:22:36 +0100
Subject: [PATCH] extend physmap.c to support run-time adding partitions
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
	<20031023100304.B1070@mvista.com>
	<20031023173148.GC16160@wohnheim.fh-wedel.de>
	<20031023104320.A1345@mvista.com>
	<20031023181541.GE16160@wohnheim.fh-wedel.de>
	<20031023130406.D1345@mvista.com> <20031023165726.J1345@mvista.com>
Message-ID: <bnl90c$iae$1@sea.gmane.org>

> Meanwhile, we sadly announce the loss of drivers/mtd/maps/jmr3927-flash.c
> file and the death of CONFIG_MTD_JMR3927 (not in MTD tree yet).  :0

First: I like a unified approach. I think that, when it makes sense, board
specifica should be in board specific files at one place. This doesn't
prevent copy&past, e.g. I can copy arch/arm/mach-pxa/accelent.c and paste
stuff into arch/arm/mach-pxa/ramses.c. It's actually easier now, because
there is only one place to look for board specifics.

For example, on linux-2.6 people are trying to have an almost #ifdef-less
drivers/video/pxafb.c and have all in arm/arm/mach-pxa/*.c files.


But just one note: you don't need CONFIG_MTD_JMR3927 if JMR3927 is your
board. At least not in arm/xscale kernels (not sure about other platforms).
You already have CONFIG_ARCH_<board>, e.g. I have CONFIG_ARCH_RAMSES. And I
can re-use this config var in drivers/mtd/maps.

-- 
Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at
http://www.mn-logistik.de/unsupported/linux-2.6/



From cellec at celerity.net  Tue Oct 28 11:07:32 2003
From: cellec at celerity.net (Ellec, Chris)
Date: Tue, 28 Oct 2003 08:07:32 -0800
Subject: INFTL and MAKEDEV
Message-ID: <E025AA91F3FF3D44A8E713E82C9D359793EA19@ca2smail1.celeritynet.net>

Hello,
 
In the following from util/MAKEDEV:
 
 
function mkinftl () {
        mknod /dev/inftl$1 b 94 $2
        for a in `seq 1 15`; do
                mknod /dev/inftl$1$a b 93 `expr $2 + $a`
        done
}

shouldn't the major number be 93 for both mknod or 94 for both mknod,
instead of one of each ?

Chris.


From dwmw2 at infradead.org  Tue Oct 28 11:10:35 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 28 Oct 2003 16:10:35 +0000
Subject: INFTL and MAKEDEV
In-Reply-To: <E025AA91F3FF3D44A8E713E82C9D359793EA19@ca2smail1.celeritynet.net>
References: 
	 <E025AA91F3FF3D44A8E713E82C9D359793EA19@ca2smail1.celeritynet.net>
Message-ID: <1067357435.15551.450.camel@hades.cambridge.redhat.com>

On Tue, 2003-10-28 at 08:07 -0800, Ellec, Chris wrote:
> shouldn't the major number be 93 for both mknod or 94 for both mknod,
> instead of one of each ?

It should; now fixed in CVS. Thanks.

-- 
dwmw2



From cellec at celerity.net  Tue Oct 28 12:32:00 2003
From: cellec at celerity.net (Chris Ellec)
Date: Tue, 28 Oct 2003 09:32:00 -0800
Subject: INFTL problems
Message-ID: <3F9EA810.6010905@celerity.net>

Hello,

I have a WinSystems devel board with a DOC on it. Dinfo from MSystems 
reports a DOC 2000 at address D800 with 256 MB and an INFTL format.

I apllied the latest CVS patches to 2.4.22, but I can't seem to detect 
the chip.

I followed the doc in CVS and compiled as modules with the following 
options:

-------------------  from .config  ---------------------------
#
# Memory Technology Devices (MTD)
CONFIG_MTD=m
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m

# Self-contained MTD device drivers
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCPROBE_ADDRESS=0

#
# NAND Flash Device Drivers
CONFIG_MTD_NAND_IDS=m
------------- end of .config  ----------------------------

Then I do
# modprobe -a doc2000  inftl mtdchar mtdblock
# modprobe -a docprobe
/lib/modules/2.4.22/kernel/driver/mtd/devices/docprobe.o: init_module: 
Resource temporarily unavailable
insmod docprobe failed


in /var/log/messages I get:
INFL: inftlcore.c $Revision 1.14 inftlmount.c $Revision 1.12
No Recognized DiskOnChip found


Now what do I do ?

Chris.



From manningc2 at actrix.gen.nz  Tue Oct 28 18:33:08 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Wed, 29 Oct 2003 12:33:08 +1300
Subject: SmartMedia FAT
In-Reply-To: <1067339503.15551.429.camel@hades.cambridge.redhat.com>
References: <3F9D3D98.6453.14E703@localhost>
	<20031027202807.DA4481A0A7@desire.actrix.co.nz>
	<1067339503.15551.429.camel@hades.cambridge.redhat.com>
Message-ID: <20031028232658.9B8854414@blood.actrix.co.nz>


> Implementing SMTL really shouldn't be that hard. The mtd_blkdevs code in
> CVS handles all the horridness of the Linux block layer for you and you
> only need to write readsector() and writesector() routines. There's code
> in drivers/usb/storage/sddr09.c which may help, since those devices make
> the host do the translation.

The flip side to this is that if you can find an SDDR09  you could likely get 
YAFFS/JFFS2 working with that by bypassing the usb storage driver and 
exposing it as NAND to mtd. However, SDDR09's are pretty rare. Samsung does 
make a USB device for experimenting with NAND that could be used for the same 
purpose.

I agree with David that the SMTL is simple. I have the code for a Win2K 
version which I am not allowed to release. 

-- Charles


From dwmw2 at infradead.org  Tue Oct 28 19:48:28 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 29 Oct 2003 00:48:28 +0000
Subject: SmartMedia FAT
In-Reply-To: <20031028232658.9B8854414@blood.actrix.co.nz>
References: <3F9D3D98.6453.14E703@localhost>
	 <20031027202807.DA4481A0A7@desire.actrix.co.nz>
	 <1067339503.15551.429.camel@hades.cambridge.redhat.com>
	 <20031028232658.9B8854414@blood.actrix.co.nz>
Message-ID: <1067388508.17740.9.camel@imladris.demon.co.uk>

On Wed, 2003-10-29 at 12:33 +1300, Charles Manning wrote:
> The flip side to this is that if you can find an SDDR09  you could likely get 
> YAFFS/JFFS2 working with that by bypassing the usb storage driver and 
> exposing it as NAND to mtd. However, SDDR09's are pretty rare. Samsung does 
> make a USB device for experimenting with NAND that could be used for the same 
> purpose.

Can't you just hang one off the parallel port and bitbang it? Should be
fairly trivial to make a driver which uses the generic NAND code and
does that.... left as an exercise for the reader with a soldering iron.

-- 
dwmw2




From jsun at mvista.com  Tue Oct 28 21:33:06 2003
From: jsun at mvista.com (Jun Sun)
Date: Tue, 28 Oct 2003 18:33:06 -0800
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <bnl90c$iae$1@sea.gmane.org>;
	from h.schurig@mn-logistik.de on Tue, Oct 28, 2003 at 09:22:36AM +0100
References: <20031022182558.U19834@mvista.com>
	<20031023153307.GA11669@wohnheim.fh-wedel.de>
	<20031023100304.B1070@mvista.com>
	<20031023173148.GC16160@wohnheim.fh-wedel.de>
	<20031023104320.A1345@mvista.com>
	<20031023181541.GE16160@wohnheim.fh-wedel.de>
	<20031023130406.D1345@mvista.com> <20031023165726.J1345@mvista.com>
	<bnl90c$iae$1@sea.gmane.org>
Message-ID: <20031028183306.E30683@mvista.com>

On Tue, Oct 28, 2003 at 09:22:36AM +0100, Holger Schurig wrote:
> > Meanwhile, we sadly announce the loss of drivers/mtd/maps/jmr3927-flash.c
> > file and the death of CONFIG_MTD_JMR3927 (not in MTD tree yet).  :0
> 
> First: I like a unified approach. I think that, when it makes sense, board
> specifica should be in board specific files at one place. This doesn't
> prevent copy&past, e.g. I can copy arch/arm/mach-pxa/accelent.c and paste
> stuff into arch/arm/mach-pxa/ramses.c. It's actually easier now, because
> there is only one place to look for board specifics.
> 

Exactly!  This is another unspoken benefit of this patch (it had too many
benefits. :0).  Now a lot of board-specific mtd code is moved
into board directory instead of mtd directory.  One would appreciate it
even more when the support for a board is dropped - guess what? No
mtd code change.  Not the case today.

> For example, on linux-2.6 people are trying to have an almost #ifdef-less
> drivers/video/pxafb.c and have all in arm/arm/mach-pxa/*.c files.
> 
> 
> But just one note: you don't need CONFIG_MTD_JMR3927 if JMR3927 is your
> board. At least not in arm/xscale kernels (not sure about other platforms).
> You already have CONFIG_ARCH_<board>, e.g. I have CONFIG_ARCH_RAMSES. And I
> can re-use this config var in drivers/mtd/maps.
>

That is true.  It just happened that JMR3927 chose to create a new
config for MTD.

Jun


From jasmine at linuxgrrls.org  Wed Oct 29 04:40:11 2003
From: jasmine at linuxgrrls.org (Jasmine Strong)
Date: Wed, 29 Oct 2003 09:40:11 -0000 (GMT)
Subject: SmartMedia FAT
In-Reply-To: <1067388508.17740.9.camel@imladris.demon.co.uk>
References: <3F9D3D98.6453.14E703@localhost>
    <20031027202807.DA4481A0A7@desire.actrix.co.nz>
    <1067339503.15551.429.camel@hades.cambridge.redhat.com>
    <20031028232658.9B8854414@blood.actrix.co.nz>
    <1067388508.17740.9.camel@imladris.demon.co.uk>
Message-ID: <50335.192.91.75.30.1067420411.squirrel@mail.linuxgrrls.org>

> [NAND]
>
> Can't you just hang one off the parallel port and bitbang it? Should be
> fairly trivial to make a driver which uses the generic NAND code and
> does that.... left as an exercise for the reader with a soldering iron.

...in fact, this is very nearly what we did on the ZL103xx NAND
driver.  Rob, are you out there?

-Jasmine.


From simon at baydel.com  Wed Oct 29 05:21:52 2003
From: simon at baydel.com (simon at baydel.com)
Date: Wed, 29 Oct 2003 10:21:52 -0000
Subject: SmartMedia FAT
In-Reply-To: <3F9D3D98.6453.14E703@localhost>
Message-ID: <3F9F94C0.28402.10FED3@localhost>

Thanks too all for your help. I have started to write my own block 
driver using the FTL code as a guide. It seems fairly simple and 
should not take too long.


Thanks Again 

Simon. 

On 27 Oct 2003 at 15:45, simon at baydel.com wrote:

> I would like to be able to access FAT partitions on a SMC via Linux.
> Curently the hardare loads its' configuration and boots the hardware
> from files on a FAT partition. The hardware itself has no hardware
> flash translation layer. The SMC has been created on a USB device
> which contains a flash translation layer conforming to the SFFDC
> standard. After this a JFFS2 root is mounted. It would be nice if I
> could change the hardware and boot files from Linux but I have been
> unable to find any reliable way of accessing the FAT filesystem.
> 
> As far as I understand, from the information I have read, I would need
> to create  a block driver which contained a SSFDC compatible
> translation layer ? In the nand FAQ it mentions SmartMedia FAT. I have
> been unable to find how this is implemented. Has anyone implemented
> this yet ?
> 
> I would like to know if my assumptions are correct. If so I guess
> there are many ways this could be achieved. 
> 
> 1. Wrirte my on block driver ?
> 2. Bolt on some bits to mtdblock ?
> 3. As I don't do this all the time write a user app to update via
> /dev/mtd
> 
> All comments welcome.
> 
> 
> Many Thanks
> 
> Simon.__________________________
> 
> Simon Haynes - Baydel 
> Phone : 44 (0) 1372 378811
> Email : simon at baydel.com
> __________________________
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon at baydel.com
__________________________



From dwmw2 at infradead.org  Wed Oct 29 05:55:04 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 29 Oct 2003 10:55:04 +0000
Subject: SmartMedia FAT
In-Reply-To: <3F9F94C0.28402.10FED3@localhost>
References: <3F9F94C0.28402.10FED3@localhost>
Message-ID: <1067424903.15551.1537.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-29 at 10:21 +0000, simon at baydel.com wrote:
> Thanks too all for your help. I have started to write my own block 
> driver using the FTL code as a guide. It seems fairly simple and 
> should not take too long.

Send me a SSH key and I'll give you an account so you can put it in CVS.
Commit early and often and I'll try to heckle helpfully... :)

-- 
dwmw2



From ddillow at idleaire.com  Tue Oct 28 16:34:39 2003
From: ddillow at idleaire.com (Dave Dillow)
Date: 28 Oct 2003 16:34:39 -0500
Subject: INFTL problems
In-Reply-To: <3F9EA810.6010905@celerity.net>
References: <3F9EA810.6010905@celerity.net>
Message-ID: <1067376879.9396.1.camel@dillow.idleaire.com>

On Tue, 2003-10-28 at 12:32, Chris Ellec wrote:
> Hello,
> 
> I have a WinSystems devel board with a DOC on it. Dinfo from MSystems 
> reports a DOC 2000 at address D800 with 256 MB and an INFTL format.
> 

Try this -- it's my current hack to get my 128MB recoginzed. When I get
time, I plan to work on nand/diskonchip.c, per dwmw2's suggestion.

-- 
Dave Dillow <ddillow at idleaire.com>
-------------- next part --------------
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1191  -> 1.1192 
#	drivers/mtd/devices/doc2000.c	1.6     -> 1.7    
#	include/linux/mtd/doc2000.h	1.5     -> 1.6    
#	drivers/mtd/devices/docprobe.c	1.7     -> 1.8    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/10/13	ddillow at idleaire.com	1.1192
# Add support for DoC 2000 TSOP
# --------------------------------------------
#
diff -Nru a/drivers/mtd/devices/doc2000.c b/drivers/mtd/devices/doc2000.c
--- a/drivers/mtd/devices/doc2000.c	Tue Oct 28 16:32:43 2003
+++ b/drivers/mtd/devices/doc2000.c	Tue Oct 28 16:32:43 2003
@@ -25,6 +25,7 @@
 #include <linux/mtd/doc2000.h>
 
 #define DOC_SUPPORT_2000
+#define DOC_SUPPORT_2000TSOP
 #define DOC_SUPPORT_MILLENNIUM
 
 #ifdef DOC_SUPPORT_2000
@@ -33,6 +34,12 @@
 #define DoC_is_2000(doc) (0)
 #endif
 
+#ifdef DOC_SUPPORT_2000TSOP
+#define DoC_is_2000TSOP(doc) (doc->ChipID == DOC_ChipID_Doc2kTSOP)
+#else
+#define DoC_is_2000TSOP(doc) (0)
+#endif
+
 #ifdef DOC_SUPPORT_MILLENNIUM
 #define DoC_is_Millennium(doc) (doc->ChipID == DOC_ChipID_DocMil)
 #else
@@ -76,7 +83,7 @@
 	int i;
 	
 	for (i = 0; i < cycles; i++) {
-		if (DoC_is_Millennium(doc))
+		if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc))
 			dummy = ReadDOC(doc->virtadr, NOP);
 		else
 			dummy = ReadDOC(doc->virtadr, DOCStatus);
@@ -95,6 +102,10 @@
 
 	/* Out-of-line routine to wait for chip response */
 	while (!(ReadDOC(docptr, CDSNControl) & CDSN_CTRL_FR_B)) {
+		/* issue 2 read from NOP register after reading from CDSNControl register
+	   	see Software Requirement 11.4 item 2. */
+		DoC_Delay(doc, 2);
+
 		if (time_after(jiffies, timeo)) {
 			DEBUG(MTD_DEBUG_LEVEL2, "_DoC_WaitReady timed out.\n");
 			return -EIO;
@@ -136,18 +147,20 @@
 {
 	unsigned long docptr = doc->virtadr;
 
-	if (DoC_is_2000(doc))
+	if (DoC_is_2000(doc) || DoC_is_2000TSOP(doc))
 		xtraflags |= CDSN_CTRL_FLASH_IO;
 
 	/* Assert the CLE (Command Latch Enable) line to the flash chip */
 	WriteDOC(xtraflags | CDSN_CTRL_CLE | CDSN_CTRL_CE, docptr, CDSNControl);
 	DoC_Delay(doc, 4);	/* Software requirement 11.4.3 for Millennium */
 
-	if (DoC_is_Millennium(doc))
+	if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc))
 		WriteDOC(command, docptr, CDSNSlowIO);
 
 	/* Send the command */
 	WriteDOC_(command, docptr, doc->ioreg);
+	if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc))
+		WriteDOC(command, docptr, WritePipeTerm);
 
 	/* Lower the CLE line */
 	WriteDOC(xtraflags | CDSN_CTRL_CE, docptr, CDSNControl);
@@ -169,7 +182,7 @@
 
 	docptr = doc->virtadr;
 
-	if (DoC_is_2000(doc))
+	if (DoC_is_2000(doc) || DoC_is_2000TSOP(doc))
 		xtraflags1 |= CDSN_CTRL_FLASH_IO;
 
 	/* Assert the ALE (Address Latch Enable) line to the flash chip */
@@ -190,7 +203,7 @@
 	 */
 
 	if (numbytes == ADDR_COLUMN || numbytes == ADDR_COLUMN_PAGE) {
-		if (DoC_is_Millennium(doc))
+		if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc))
 			WriteDOC(ofs & 0xff, docptr, CDSNSlowIO);
 		WriteDOC_(ofs & 0xff, docptr, doc->ioreg);
 	}
@@ -203,12 +216,15 @@
 
 	if (numbytes == ADDR_PAGE || numbytes == ADDR_COLUMN_PAGE) {
 		for (i = 0; i < doc->pageadrlen; i++, ofs = ofs >> 8) {
-			if (DoC_is_Millennium(doc))
+			if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc))
 				WriteDOC(ofs & 0xff, docptr, CDSNSlowIO);
 			WriteDOC_(ofs & 0xff, docptr, doc->ioreg);
 		}
 	}
 
+	if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc))
+		WriteDOC(ofs & 0xff, docptr, WritePipeTerm);
+
 	DoC_Delay(doc, 2);	/* Needed for some slow flash chips. mf. */
 	
 	/* FIXME: The SlowIO's for millennium could be replaced by 
@@ -237,7 +253,7 @@
 	if (len <= 0)
 		return;
 
-	if (DoC_is_Millennium(doc)) {
+	if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc)) {
 		/* Read the data via the internal pipeline through CDSN IO register,
 		   see Pipelined Read Operations 11.3 */
 		dummy = ReadDOC(docptr, ReadPipeInit);
@@ -252,7 +268,7 @@
 	for (i = 0; i < len; i++)
 		buf[i] = ReadDOC_(docptr, doc->ioreg + (i & modulus));
 
-	if (DoC_is_Millennium(doc)) {
+	if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc)) {
 		buf[i] = ReadDOC(docptr, LastDataRead);
 	}
 }
@@ -271,7 +287,7 @@
 	for (i = 0; i < len; i++)
 		WriteDOC_(buf[i], docptr, doc->ioreg + i);
 
-	if (DoC_is_Millennium(doc)) {
+	if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc)) {
 		WriteDOC(0x00, docptr, WritePipeTerm);
 	}
 }
@@ -347,15 +363,27 @@
 
 	/* Read the manufacturer and device id codes from the device */
 
-	/* CDSN Slow IO register see Software Requirement 11.4 item 5. */
-	dummy = ReadDOC(doc->virtadr, CDSNSlowIO);
-	DoC_Delay(doc, 2);
-	mfr = ReadDOC_(doc->virtadr, doc->ioreg);
+	if (DoC_is_Millennium(doc) || DoC_is_2000TSOP(doc)) {
+		DoC_Delay(doc, 2);
+		dummy = ReadDOC(doc->virtadr, ReadPipeInit);
+		mfr = ReadDOC(doc->virtadr, LastDataRead);
+
+		DoC_Delay(doc, 2);
+		dummy = ReadDOC(doc->virtadr, ReadPipeInit);
+		id = ReadDOC(doc->virtadr, LastDataRead);
+	} else {
+		/* CDSN Slow IO register see Software Req 11.4 item 5. */
+		dummy = ReadDOC(doc->virtadr, CDSNSlowIO);
+		DoC_Delay(doc, 2);
+		mfr = ReadDOC_(doc->virtadr, doc->ioreg);
+
+		/* CDSN Slow IO register see Software Req 11.4 item 5. */
+		dummy = ReadDOC(doc->virtadr, CDSNSlowIO);
+		DoC_Delay(doc, 2);
+		id = ReadDOC_(doc->virtadr, doc->ioreg);
+	}
 
-	/* CDSN Slow IO register see Software Requirement 11.4 item 5. */
-	dummy = ReadDOC(doc->virtadr, CDSNSlowIO);
-	DoC_Delay(doc, 2);
-	id = ReadDOC_(doc->virtadr, doc->ioreg);
+	printk("IdentChip checking floor %d chip %d id 0x%02x mfr 0x%02x\n", floor, chip, id, mfr);
 
 	/* No response - return failure */
 	if (mfr == 0xff || mfr == 0)
@@ -541,6 +569,10 @@
 
 
 	switch (this->ChipID) {
+	case DOC_ChipID_Doc2kTSOP:
+		mtd->name = "DiskOnChip 2000 TSOP";
+		this->ioreg = DoC_Mil_CDSN_IO;
+		break;
 	case DOC_ChipID_Doc2k:
 		mtd->name = "DiskOnChip 2000";
 		this->ioreg = DoC_2k_CDSN_IO;
@@ -692,7 +724,7 @@
 			DoC_ReadBuf(this, eccbuf, 6);
 
 			/* Flush the pipeline */
-			if (DoC_is_Millennium(this)) {
+			if (DoC_is_Millennium(this) || DoC_is_2000TSOP(this)) {
 				dummy = ReadDOC(docptr, ECCConf);
 				dummy = ReadDOC(docptr, ECCConf);
 				i = ReadDOC(docptr, ECCConf);
@@ -773,6 +805,7 @@
 	int len256 = 0;
 	struct Nand *mychip;
 	size_t left = len;
+	int status;
 
 	docptr = this->virtadr;
 
@@ -865,7 +898,7 @@
 			WriteDOC(CDSN_CTRL_ECC_IO | CDSN_CTRL_CE, docptr,
 				 CDSNControl);
 
-			if (DoC_is_Millennium(this)) {
+			if (DoC_is_Millennium(this) || DoC_is_2000TSOP(this)) {
 				WriteDOC(0, docptr, NOP);
 				WriteDOC(0, docptr, NOP);
 				WriteDOC(0, docptr, NOP);
@@ -875,6 +908,9 @@
 				WriteDOC_(0, docptr, this->ioreg);
 			}
 
+			WriteDOC(CDSN_CTRL_ECC_IO | CDSN_CTRL_FLASH_IO | CDSN_CTRL_CE, docptr,
+				 CDSNControl);
+
 			/* Read the ECC data through the DiskOnChip ECC logic */
 			for (di = 0; di < 6; di++) {
 				eccbuf[di] = ReadDOC(docptr, ECCSyndrome0 + di);
@@ -896,10 +932,16 @@
 		DoC_Command(this, NAND_CMD_STATUS, CDSN_CTRL_WP);
 		/* There's an implicit DoC_WaitReady() in DoC_Command */
 
-		dummy = ReadDOC(docptr, CDSNSlowIO);
-		DoC_Delay(this, 2);
+		if (DoC_is_Millennium(this) || DoC_is_2000TSOP(this)) {
+			ReadDOC(docptr, ReadPipeInit);
+			status = ReadDOC(docptr, LastDataRead);
+		} else {
+			dummy = ReadDOC(docptr, CDSNSlowIO);
+			DoC_Delay(this, 2);
+			status = ReadDOC_(docptr, this->ioreg);
+		}
 
-		if (ReadDOC_(docptr, this->ioreg) & 1) {
+		if (status & 1) {
 			printk(KERN_ERR "Error programming flash\n");
 			/* Error in programming */
 			*retlen = 0;
@@ -1067,6 +1109,7 @@
 	unsigned long docptr = this->virtadr;
 	struct Nand *mychip = &this->chips[ofs >> this->chipshift];
 	volatile int dummy;
+	int status;
 
 	//      printk("doc_write_oob(%lx, %d): %2.2X %2.2X %2.2X %2.2X ... %2.2X %2.2X .. %2.2X %2.2X\n",(long)ofs, len,
 	//   buf[0], buf[1], buf[2], buf[3], buf[8], buf[9], buf[14],buf[15]);
@@ -1115,10 +1158,16 @@
 		DoC_Command(this, NAND_CMD_STATUS, 0);
 		/* DoC_WaitReady() is implicit in DoC_Command */
 
-		dummy = ReadDOC(docptr, CDSNSlowIO);
-		DoC_Delay(this, 2);
+		if (DoC_is_Millennium(this) || DoC_is_2000TSOP(this)) {
+			ReadDOC(docptr, ReadPipeInit);
+			status = ReadDOC(docptr, LastDataRead);
+		} else {
+			dummy = ReadDOC(docptr, CDSNSlowIO);
+			DoC_Delay(this, 2);
+			status = ReadDOC_(docptr, this->ioreg);
+		}
 
-		if (ReadDOC_(docptr, this->ioreg) & 1) {
+		if (status & 1) {
 			printk(KERN_ERR "Error programming oob data\n");
 			/* There was an error */
 			*retlen = 0;
@@ -1134,10 +1183,16 @@
 	DoC_Command(this, NAND_CMD_STATUS, 0);
 	/* DoC_WaitReady() is implicit in DoC_Command */
 
-	dummy = ReadDOC(docptr, CDSNSlowIO);
-	DoC_Delay(this, 2);
+	if (DoC_is_Millennium(this) || DoC_is_2000TSOP(this)) {
+		ReadDOC(docptr, ReadPipeInit);
+		status = ReadDOC(docptr, LastDataRead);
+	} else {
+		dummy = ReadDOC(docptr, CDSNSlowIO);
+		DoC_Delay(this, 2);
+		status = ReadDOC_(docptr, this->ioreg);
+	}
 
-	if (ReadDOC_(docptr, this->ioreg) & 1) {
+	if (status & 1) {
 		printk(KERN_ERR "Error programming oob data\n");
 		/* There was an error */
 		*retlen = 0;
@@ -1170,6 +1225,7 @@
 	volatile int dummy;
 	unsigned long docptr;
 	struct Nand *mychip;
+	int status;
 
  	down(&this->lock);
 
@@ -1201,10 +1257,16 @@
 
 		DoC_Command(this, NAND_CMD_STATUS, CDSN_CTRL_WP);
 
-		dummy = ReadDOC(docptr, CDSNSlowIO);
-		DoC_Delay(this, 2);
-		
-		if (ReadDOC_(docptr, this->ioreg) & 1) {
+		if (DoC_is_Millennium(this) || DoC_is_2000TSOP(this)) {
+			ReadDOC(docptr, ReadPipeInit);
+			status = ReadDOC(docptr, LastDataRead);
+		} else {
+			dummy = ReadDOC(docptr, CDSNSlowIO);
+			DoC_Delay(this, 2);
+			status = ReadDOC_(docptr, this->ioreg);
+		}
+
+		if (status & 1) {
 			printk(KERN_ERR "Error erasing at 0x%x\n", ofs);
 			/* There was an error */
 			instr->state = MTD_ERASE_FAILED;
diff -Nru a/drivers/mtd/devices/docprobe.c b/drivers/mtd/devices/docprobe.c
--- a/drivers/mtd/devices/docprobe.c	Tue Oct 28 16:32:43 2003
+++ b/drivers/mtd/devices/docprobe.c	Tue Oct 28 16:32:43 2003
@@ -97,10 +97,11 @@
 static inline int __init doccheck(unsigned long potential, unsigned long physadr)
 {
 	unsigned long window=potential;
-	unsigned char tmp, tmpb, tmpc, ChipID;
+	unsigned char tmp, tmpb, tmpc;
 #ifndef DOC_PASSIVE_PROBE
 	unsigned char tmp2;
 #endif
+	unsigned char ChipID;
 
 	/* Routine copied from the Linux DOC driver */
 
@@ -138,10 +139,16 @@
 	/* We need to read the ChipID register four times. For some
 	   newer DiskOnChip 2000 units, the first three reads will
 	   return the DiskOnChip Millennium ident. Don't ask. */
-	ReadDOC(window, ChipID);
-	ReadDOC(window, ChipID);
-	ReadDOC(window, ChipID);
 	ChipID = ReadDOC(window, ChipID);
+#if 1
+	if(ChipID == DOC_ChipID_DocMil) {
+		ReadDOC(window, ChipID);
+		ReadDOC(window, ChipID);
+		ChipID = ReadDOC(window, ChipID);
+		if(ChipID != DOC_ChipID_DocMil)
+			ChipID = DOC_ChipID_Doc2kTSOP;
+	}
+#endif
   
 	switch (ChipID) {
 	case DOC_ChipID_Doc2k:
@@ -153,6 +160,7 @@
 				return ChipID;
 		break;
 		
+	case DOC_ChipID_Doc2kTSOP:
 	case DOC_ChipID_DocMil:
 		/* Check the TOGGLE bit in the ECC register */
 		tmp  = ReadDOC(window, ECCConf) & DOC_TOGGLE_BIT;
@@ -267,6 +275,12 @@
 		sprintf(namebuf, "with ChipID %2.2X", ChipID);
 
 		switch(ChipID) {
+		case DOC_ChipID_Doc2kTSOP:
+			name="2000 TSOP";
+			im_funcname = "DoC2k_init";
+			im_modname = "doc2000";
+			break;
+			
 		case DOC_ChipID_Doc2k:
 			name="2000";
 			im_funcname = "DoC2k_init";
diff -Nru a/include/linux/mtd/doc2000.h b/include/linux/mtd/doc2000.h
--- a/include/linux/mtd/doc2000.h	Tue Oct 28 16:32:43 2003
+++ b/include/linux/mtd/doc2000.h	Tue Oct 28 16:32:43 2003
@@ -114,6 +114,7 @@
 #define DOC_MODE_MDWREN 	0x04
 
 #define DOC_ChipID_Doc2k 	0x20
+#define DOC_ChipID_Doc2kTSOP 	0x21	/* internal number for MTD */
 #define DOC_ChipID_DocMil 	0x30
 #define DOC_ChipID_DocMilPlus32	0x40
 #define DOC_ChipID_DocMilPlus16	0x41
@@ -169,7 +170,7 @@
 	unsigned long physadr;
 	unsigned long virtadr;
 	unsigned long totlen;
-	char ChipID; /* Type of DiskOnChip */
+	unsigned char ChipID; /* Type of DiskOnChip */
 	int ioreg;
 	
 	unsigned long mfr; /* Flash IDs - only one type of flash per device */

From jsun at mvista.com  Tue Oct 28 21:28:28 2003
From: jsun at mvista.com (Jun Sun)
Date: Tue, 28 Oct 2003 18:28:28 -0800
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <1067338214.15551.405.camel@hades.cambridge.redhat.com>;
	from dwmw2@infradead.org on Tue, Oct 28, 2003 at 10:50:15AM +0000
References: <20031022182558.U19834@mvista.com>
	<20031027101741.C1678@mvista.com>
	<1067338214.15551.405.camel@hades.cambridge.redhat.com>
Message-ID: <20031028182828.D30683@mvista.com>

On Tue, Oct 28, 2003 at 10:50:15AM +0000, David Woodhouse wrote:
> On Mon, 2003-10-27 at 10:17 -0800, Jun Sun wrote:
> > Any objections or comments?  David?
> 
> Sorry for delayed response. I'm not really sure about this. Take a look
> at drivers/mtd/maps/rpxlite.c -- that's what we're able to eliminate,

I think a lot of more can be eliminated, including db1x00-flash.c
which I did take a look.

What concerns me more is that I have at least four more new boards
that cry for this extension.  Without it, I would have to introduce
more junk files into linux-mtd.

We need to have this extension or something like this in place.

> and we could even stick half of _that_ into a library function. 
> 

I don't quite follow here.

> I'm all for cleaning up all the duplication in the map drivers, but I'm
> not sure we need to do it by making users enter correct numbers for
> CONFIG_MTD_PHYSMAP_*...
> 

I didn't like that aspect either.  I thought I should keep the
patch minimum so that it is easier for people to swallow. :)

Actually the new attached version is probably what I like more.
It gets rid of the config options for physmap.

Since physmap_map is external, one can easily setup the mapping
at the run time instead of configuration time.  The new patch
simply adds some syntactic sugar by introducing an inline function
to do this.  

Jun
-------------- next part --------------
diff -Nru linux/arch/mips/mips-boards/malta/malta_setup.c.orig linux/arch/mips/mips-boards/malta/malta_setup.c
--- linux/arch/mips/mips-boards/malta/malta_setup.c.orig	Fri Aug  1 10:50:18 2003
+++ linux/arch/mips/mips-boards/malta/malta_setup.c	Tue Oct 28 17:02:01 2003
@@ -24,6 +24,7 @@
 #ifdef CONFIG_BLK_DEV_IDE
 #include <linux/ide.h>
 #endif
+#include <linux/mtd/physmap.h>
 
 #include <asm/cpu.h>
 #include <asm/bootinfo.h>
@@ -166,6 +167,15 @@
         conswitchp = &dummy_con;
 #endif
 #endif
+
+#if defined(CONFIG_MTD)
+	/* we use generic physmap mapping driver */
+	physmap_set_map(0x400000, 4, 0x1e000000);
+
+	physmap_add_partition("YAMON", 0x100000, 0x0, MTD_WRITEABLE);
+	physmap_add_partition("User FS", 0x300000, 0x100000, 0);
+#endif
+
 	mips_reboot_setup();
 
 	board_time_init = mips_time_init;
diff -Nru linux/drivers/mtd/maps/physmap.c.orig linux/drivers/mtd/maps/physmap.c
--- linux/drivers/mtd/maps/physmap.c.orig	Wed Jul 23 15:17:52 2003
+++ linux/drivers/mtd/maps/physmap.c	Tue Oct 28 17:05:12 2003
@@ -2,6 +2,11 @@
  * $Id: physmap.c,v 1.28 2003/05/28 15:53:43 dwmw2 Exp $
  *
  * Normal mappings of chips in physical memory
+ *
+ * Copyright (C) 2003 MontaVista Software Inc.
+ * Author: Jun Sun, jsun at mvista.com or jsun at junsun.net
+ *
+ * 031022 - [jsun] add physmap_add_partition()
  */
 
 #include <linux/module.h>
@@ -15,53 +20,39 @@
 #include <linux/config.h>
 #include <linux/mtd/partitions.h>
 
-#define WINDOW_ADDR CONFIG_MTD_PHYSMAP_START
-#define WINDOW_SIZE CONFIG_MTD_PHYSMAP_LEN
-#define BUSWIDTH CONFIG_MTD_PHYSMAP_BUSWIDTH
-
 static struct mtd_info *mymtd;
 
-
-struct map_info physmap_map = {
-	.name = "Physically mapped flash",
-	.size = WINDOW_SIZE,
-	.buswidth = BUSWIDTH,
-	.phys = WINDOW_ADDR,
-};
+struct map_info physmap_map = {.name = "phys_mapped_flash"};
 
 #ifdef CONFIG_MTD_PARTITIONS
 static struct mtd_partition *mtd_parts;
 static int                   mtd_parts_nb;
 
-static struct mtd_partition physmap_partitions[] = {
-#if 0
-/* Put your own partition definitions here */
-	{
-		.name =		"bootROM",
-		.size =		0x80000,
-		.offset =	0,
-		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
-	}, {
-		.name =		"zImage",
-		.size =		0x100000,
-		.offset =	MTDPART_OFS_APPEND,
-		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
-	}, {
-		.name =		"ramdisk.gz",
-		.size =		0x300000,
-		.offset =	MTDPART_OFS_APPEND,
-		.mask_flags =	MTD_WRITEABLE,  /* force read-only */
-	}, {
-		.name =		"User FS",
-		.size =		MTDPART_SIZ_FULL,
-		.offset =	MTDPART_OFS_APPEND,
+#define NUM_PARTITIONS	4	/* random num which should be good enough */
+static struct mtd_partition physmap_partitions[NUM_PARTITIONS] __initdata = {};
+
+char *part_probes[] __initdata = {"cmdlinepart", "RedBoot", NULL};
+
+/*
+ * See include/linux/mtd/physmap.h file.
+ */
+static int part_index __initdata = 0;
+int __init physmap_add_partition(char *name, u32 size, u32 offset, u32 flags)
+{
+	if (part_index >= NUM_PARTITIONS) {
+		printk(KERN_ERR "physmap_add_partition() exceeds max partition table size (%d)\n", NUM_PARTITIONS);
+		return -1;
 	}
-#endif
-};
 
-#define NUM_PARTITIONS	(sizeof(physmap_partitions)/sizeof(struct mtd_partition))
-const char *part_probes[] = {"cmdlinepart", "RedBoot", NULL};
+	physmap_partitions[part_index].name = name;
+	physmap_partitions[part_index].size = size;
+	physmap_partitions[part_index].offset = offset;
+	physmap_partitions[part_index].mask_flags = flags;
+
+	part_index++;
 
+	return 0;
+}
 #endif /* CONFIG_MTD_PARTITIONS */
 
 int __init init_physmap(void)
@@ -69,8 +60,8 @@
 	static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", 0 };
 	const char **type;
 
-       	printk(KERN_NOTICE "physmap flash device: %x at %x\n", WINDOW_SIZE, WINDOW_ADDR);
-	physmap_map.virt = (unsigned long)ioremap(WINDOW_ADDR, WINDOW_SIZE);
+       	printk(KERN_NOTICE "physmap flash device: %lx at %lx\n", physmap_map.size, physmap_map.phys);
+	physmap_map.virt = (unsigned long)ioremap(physmap_map.phys, physmap_map.size);
 
 	if (!physmap_map.virt) {
 		printk("Failed to ioremap\n");
@@ -97,11 +88,11 @@
 			return 0;
 		}
 
-		if (NUM_PARTITIONS != 0) 
+		if (part_index != 0) 
 		{
 			printk(KERN_NOTICE 
 			       "Using physmap partition definition\n");
-			add_mtd_partitions (mymtd, physmap_partitions, NUM_PARTITIONS);
+			add_mtd_partitions (mymtd, physmap_partitions, part_index);
 			return 0;
 		}
 
diff -Nru linux/drivers/mtd/maps/Config.in.orig linux/drivers/mtd/maps/Config.in
--- linux/drivers/mtd/maps/Config.in.orig	Tue Oct 21 18:07:35 2003
+++ linux/drivers/mtd/maps/Config.in	Tue Oct 28 16:59:07 2003
@@ -8,12 +8,7 @@
 
 bool '  Support for non-linear mappings of flash chips' CONFIG_MTD_COMPLEX_MAPPINGS
 
-dep_tristate '  CFI Flash device in physical memory map' CONFIG_MTD_PHYSMAP $CONFIG_MTD_GEN_PROBE
-if [ "$CONFIG_MTD_PHYSMAP" = "y" -o "$CONFIG_MTD_PHYSMAP" = "m" ]; then
-   hex '    Physical start address of flash mapping' CONFIG_MTD_PHYSMAP_START 0x8000000
-   hex '    Physical length of flash mapping' CONFIG_MTD_PHYSMAP_LEN 0x4000000
-   int '    Bus width in octets' CONFIG_MTD_PHYSMAP_BUSWIDTH 2
-fi
+bool '  CFI Flash device in physical memory map' CONFIG_MTD_PHYSMAP $CONFIG_MTD_GEN_PROBE
 
 if [ "$CONFIG_SPARC" = "y" -o "$CONFIG_SPARC64" = "y" ]; then
    dep_tristate '  Sun Microsystems userflash support' CONFIG_MTD_SUN_UFLASH $CONFIG_MTD_CFI
diff -Nru linux/drivers/mtd/maps/Makefile.orig linux/drivers/mtd/maps/Makefile
diff -Nru linux/include/linux/mtd/physmap.h.orig linux/include/linux/mtd/physmap.h
--- linux/include/linux/mtd/physmap.h.orig	Wed Oct 22 17:05:22 2003
+++ linux/include/linux/mtd/physmap.h	Tue Oct 28 17:11:29 2003
@@ -0,0 +1,58 @@
+/*
+ * For boards with physically mapped flash and using 
+ * drivers/mtd/maps/physmap.c mapping driver.
+ *
+ * Copyright (C) 2003 MontaVista Software Inc.
+ * Author: Jun Sun, jsun at mvista.com or jsun at junsun.net
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef __LINUX_MTD_PHYSMAP__
+
+#include <linux/config.h>
+
+#if defined(CONFIG_MTD_PHYSMAP) 
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+
+/*
+ * The map_info for physmap.  Board can override size, buswidth, phys,
+ * (*set_vpp)(), etc in their initial setup routine.
+ */
+extern struct map_info physmap_map;
+
+/*
+ * Board needs to specify the exact mapping during their setup time.
+ */
+static inline void physmap_set_map(unsigned long size, int buswidth, unsigned long phys_addr)
+{
+	physmap_map.size = size;
+	physmap_map.buswidth = buswidth;
+	physmap_map.phys = phys_addr;
+}
+
+#if defined(CONFIG_MTD_PARTITIONS)
+
+/*
+ * Machines that wish to do flash partition may want to call this function in 
+ * their setup routine.  Examples:
+ *
+ *	physmap_add_partition("bootROM", 0x100000, 0, MTD_WRITEABLE);	// RO
+ *	physmap_add_partition("User FS", 0x300000, 0x100000, 0); 	// RW
+ *
+ * Note that one can always override this hard-coded partition with 
+ * command line partition (you need to enable CONFIG_MTD_CMDLINE_PARTS).
+ */
+int physmap_add_partition(char *name, u32 size, u32 offset, u32 mask_flags);
+
+#endif /* defined(CONFIG_MTD_PARTITIONS) */
+#endif /* defined(CONFIG_MTD) */
+
+#endif /* __LINUX_MTD_PHYSMAP__ */
+

From dwmw2 at infradead.org  Wed Oct 29 06:13:26 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 29 Oct 2003 11:13:26 +0000
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031028182828.D30683@mvista.com>
References: <20031022182558.U19834@mvista.com>
	 <20031027101741.C1678@mvista.com>
	 <1067338214.15551.405.camel@hades.cambridge.redhat.com>
	 <20031028182828.D30683@mvista.com>
Message-ID: <1067426006.15551.1546.camel@hades.cambridge.redhat.com>

On Tue, 2003-10-28 at 18:28 -0800, Jun Sun wrote:
+#if defined(CONFIG_MTD)
+       /* we use generic physmap mapping driver */
+       physmap_set_map(0x400000, 4, 0x1e000000);
+
+       physmap_add_partition("YAMON", 0x100000, 0x0, MTD_WRITEABLE);
+       physmap_add_partition("User FS", 0x300000, 0x100000, 0);
+#endif

That's nicer. Why multiple physmap_add_partition() calls rather than
just a single array passed to physmap_set_map() though?

	mtd = physmap_set_map(adr, len, width, set_vpp, partitions);

	physmap_unset_map(mtd);

-- 
dwmw2




From dwmw2 at infradead.org  Wed Oct 29 06:41:59 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 29 Oct 2003 11:41:59 +0000
Subject: INFTL problems
In-Reply-To: <1067376879.9396.1.camel@dillow.idleaire.com>
References: <3F9EA810.6010905@celerity.net>
	 <1067376879.9396.1.camel@dillow.idleaire.com>
Message-ID: <1067427718.15551.1582.camel@hades.cambridge.redhat.com>

On Tue, 2003-10-28 at 16:34 -0500, Dave Dillow wrote:
> Try this -- it's my current hack to get my 128MB recoginzed. When I get
> time, I plan to work on nand/diskonchip.c, per dwmw2's suggestion.

That looks sane enough for me to apply it, if it still actually works on
the 2000 and Millennium parts. Zachi, what's the correct name for these
parts? Is it 'DiskOnChip 2000 TSOP'?

-- 
dwmw2



From djp.mtd at onemyth.net  Wed Oct 29 13:16:23 2003
From: djp.mtd at onemyth.net (Dan Post)
Date: Wed, 29 Oct 2003 10:16:23 -0800
Subject: Intel K3 Flash + MTD
In-Reply-To: <IIEEICKJLNEPBBDJICNGGEICEBAA.chuckmeade@mindspring.com>
References: 
	<903E17B6FF22A24C96B4E28C2C0214D7012BB2D8@sr-bng-exc01.int.tsbu.net>
	<IIEEICKJLNEPBBDJICNGGEICEBAA.chuckmeade@mindspring.com>
Message-ID: <20031029181623.M2380@onemyth.net>

On Sun, 26 Oct 2003 15:17:35 -0500, Chuck Meade wrote
> That sounds like the status bit that you are reading back.
> Most flashes give back status after you issue them commands
> (like all of your unlocks, for instance).  Usually you put them 
> back into "read mode" by writing a particular byte to them
> after reading the status.  Try writing an FF to the flash.
> Check your flash chip's datasheet for the exact sequence that
> you must use to put it back in read mode.

For K3's, writing an FF should work, though I don't know why it's coming up in
status mode.  I don't think that behavior is typical.  You probably should
check the datasheet.  Or it could be your bootloader that's setting it to
status mode (maybe not changing it to Read Array after a program or erase etc).

However, you should be aware that some NOR chips, such as Intel's L18/L30's,
are multi-partitioned and each partition must be set to read array mode... the
details of its multipartitioning can be very sticky, but very cool too...

Dan


From jsun at mvista.com  Wed Oct 29 13:45:46 2003
From: jsun at mvista.com (Jun Sun)
Date: Wed, 29 Oct 2003 10:45:46 -0800
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <1067426006.15551.1546.camel@hades.cambridge.redhat.com>;
	from dwmw2@infradead.org on Wed, Oct 29, 2003 at 11:13:26AM +0000
References: <20031022182558.U19834@mvista.com>
	<20031027101741.C1678@mvista.com>
	<1067338214.15551.405.camel@hades.cambridge.redhat.com>
	<20031028182828.D30683@mvista.com>
	<1067426006.15551.1546.camel@hades.cambridge.redhat.com>
Message-ID: <20031029104546.K30683@mvista.com>

On Wed, Oct 29, 2003 at 11:13:26AM +0000, David Woodhouse wrote:
> On Tue, 2003-10-28 at 18:28 -0800, Jun Sun wrote:
> +#if defined(CONFIG_MTD)
> +       /* we use generic physmap mapping driver */
> +       physmap_set_map(0x400000, 4, 0x1e000000);
> +
> +       physmap_add_partition("YAMON", 0x100000, 0x0, MTD_WRITEABLE);
> +       physmap_add_partition("User FS", 0x300000, 0x100000, 0);
> +#endif
> 
> That's nicer. Why multiple physmap_add_partition() calls rather than
> just a single array passed to physmap_set_map() though?
> 

Hmm, currently partition only matters when CONFIG_MTD_PARTITIONS
is enabled.  I assume this mean sometimes people want to use
physmap without partitions.  True?

The board code here really takes advantage of the board-specific
knowledge, where it knows it has support for partitions.  (Maybe
I should add #ifdef CONFIG_MTD_PARTITIONS to surround adding partition
part)

> 	mtd = physmap_set_map(adr, len, width, set_vpp, partitions);
> 
> 	physmap_unset_map(mtd);
> 

phsmap currently only supports mapping for one physical flash unit.
I assume physmap_unset_map() is pretty much null op here?  

And the "physmap_set_map" really means something like "physmap_configure_map". 
So I am not sure if something "unconfigure" is necessary.

Jun


From cellec at celerity.net  Wed Oct 29 14:14:34 2003
From: cellec at celerity.net (Chris Ellec)
Date: Wed, 29 Oct 2003 11:14:34 -0800
Subject: jffs2 vs NFTL
Message-ID: <3FA0119A.9020003@celerity.net>


A couple years ago I developped a system wih DOC using [N]FTL and an 
ext2 file system which was working fine.

Now I have a new project where we'll use JFFS2 for reliability instead 
of ext2, but I am confused as to the relationship between JFFS2 and NFTL.

For example the help provided in the Configuration steps says that 
CONFIG_MTD_PARTITIONS is not needed for Diskonchip, however
http://www.linux-mtd.infradead.org/tech/nand.html
says that the same flag is needed for JFFS2

Does that mean that the JFFS2 driver does not use the NFTL driver ? What 
about the new chips that need the INFTL driver ?

Chris.



From carles.perello at ieee.org  Wed Oct 29 14:27:32 2003
From: carles.perello at ieee.org (Carles Perello)
Date: 29 Oct 2003 20:27:32 +0100
Subject: mtd from cvs compiles for a 2.4.x kernel?
Message-ID: <1067455652.662.3.camel@stream.amrsystems.com>

Hello

I updated my mtd sources from CVS today and patched a 2.4.19 kernel for
an arm target...

while trying to compile complains about undefined SA1100_CS0_PHYS in
sa1100-flash.c.

I wonder is this is a new definition on 2.5.x kernels..or I am missing
something.

Any hint?
-- 
Carles Perello <carles.perello at ieee.org>


From joern at wohnheim.fh-wedel.de  Wed Oct 29 14:32:09 2003
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Wed, 29 Oct 2003 20:32:09 +0100
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031029104546.K30683@mvista.com>
References: <20031022182558.U19834@mvista.com>
	<20031027101741.C1678@mvista.com>
	<1067338214.15551.405.camel@hades.cambridge.redhat.com>
	<20031028182828.D30683@mvista.com>
	<1067426006.15551.1546.camel@hades.cambridge.redhat.com>
	<20031029104546.K30683@mvista.com>
Message-ID: <20031029193209.GA23482@wohnheim.fh-wedel.de>

On Wed, 29 October 2003 10:45:46 -0800, Jun Sun wrote:
> 
> phsmap currently only supports mapping for one physical flash unit.

I've created a physmap variant for multiply physical mappings once.
Google for mphysmap.c and you can still find it.  No reaction
whatsoever to this day, so you can guess how many people need it. ;)

J?rn

-- 
"Error protection by error detection and correction."
-- from a university class


From chuckmeade at mindspring.com  Wed Oct 29 15:21:33 2003
From: chuckmeade at mindspring.com (Chuck Meade)
Date: Wed, 29 Oct 2003 15:21:33 -0500
Subject: Intel K3 Flash + MTD
In-Reply-To: <20031029181623.M2380@onemyth.net>
Message-ID: <IIEEICKJLNEPBBDJICNGAELGEBAA.chuckmeade@mindspring.com>

Hey Dan,

Abhishek sent me a response directly that he got it working
with the email I sent him, but then he had trouble getting
a msg back to the list that he is up and running now.

The reason it was in "status mode" was his unlock logic was
leaving it that way.

Chuck

> -----Original Message-----
> From: Dan Post [mailto:djp.mtd at onemyth.net]
> Sent: Wednesday, October 29, 2003 1:16 PM
> To: Chuck Meade; Karoliya,Abhishek
> Cc: linux-mtd at lists.infradead.org
> Subject: RE: Intel K3 Flash + MTD
> 
> 
> On Sun, 26 Oct 2003 15:17:35 -0500, Chuck Meade wrote
> > That sounds like the status bit that you are reading back.
> > Most flashes give back status after you issue them commands
> > (like all of your unlocks, for instance).  Usually you put them 
> > back into "read mode" by writing a particular byte to them
> > after reading the status.  Try writing an FF to the flash.
> > Check your flash chip's datasheet for the exact sequence that
> > you must use to put it back in read mode.
> 
> For K3's, writing an FF should work, though I don't know why it's coming up in
> status mode.  I don't think that behavior is typical.  You probably should
> check the datasheet.  Or it could be your bootloader that's setting it to
> status mode (maybe not changing it to Read Array after a program or erase etc).
> 
> However, you should be aware that some NOR chips, such as Intel's L18/L30's,
> are multi-partitioned and each partition must be set to read array mode... the
> details of its multipartitioning can be very sticky, but very cool too...
> 
> Dan


From manningc2 at actrix.gen.nz  Wed Oct 29 15:33:48 2003
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Thu, 30 Oct 2003 09:33:48 +1300
Subject: SmartMedia FAT
In-Reply-To: <1067388508.17740.9.camel@imladris.demon.co.uk>
References: <3F9D3D98.6453.14E703@localhost>
	<20031028232658.9B8854414@blood.actrix.co.nz>
	<1067388508.17740.9.camel@imladris.demon.co.uk>
Message-ID: <20031029202754.5261E1984C@desire.actrix.co.nz>

On Wednesday 29 October 2003 13:48, David Woodhouse wrote:
> On Wed, 2003-10-29 at 12:33 +1300, Charles Manning wrote:
> > The flip side to this is that if you can find an SDDR09  you could likely
> > get YAFFS/JFFS2 working with that by bypassing the usb storage driver and
> > exposing it as NAND to mtd. However, SDDR09's are pretty rare. Samsung
> > does make a USB device for experimenting with NAND that could be used for
> > the same purpose.
>
> Can't you just hang one off the parallel port and bitbang it? Should be
> fairly trivial to make a driver which uses the generic NAND code and
> does that.... left as an exercise for the reader with a soldering iron.

Last time I tried reading with a soldering iron I burnt the page. 

Samsung had a schematic for their parallel port thingy on their www. This is 
no longer there. If you want, email me.

Samsung's  USB NAND thingy is:
http://www.samsung.com/Products/Semiconductor/Flash/TechnicalInfo/NANDUSB_Introduction.pdf

-- CHarles


From cmayor at iders.ca  Wed Oct 29 17:57:27 2003
From: cmayor at iders.ca (Cam Mayor)
Date: Wed, 29 Oct 2003 16:57:27 -0600
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031029104546.K30683@mvista.com>
References: <20031022182558.U19834@mvista.com>
	<1067426006.15551.1546.camel@hades.cambridge.redhat.com>
	<20031029104546.K30683@mvista.com>
Message-ID: <03102916572705.02584@kilauea.iders.ca>

On Wednesday 29 October 2003 12:45, Jun Sun wrote:
> On Wed, Oct 29, 2003 at 11:13:26AM +0000, David Woodhouse wrote:
> >
> > That's nicer. Why multiple physmap_add_partition() calls rather than
> > just a single array passed to physmap_set_map() though?
>
> Hmm, currently partition only matters when CONFIG_MTD_PARTITIONS
> is enabled.  I assume this mean sometimes people want to use
> physmap without partitions.  True?

Yes.  We have a product that partitions physmap (from the kernel command 
line), but also uses the unpartitioned physmap base device. 

ie. physmap on /dev/mtd0
    physmap partitions on /dev/mtd1, /dev/mtd2, etc.   sometimes none.

cam

-- 
Cameron Mayor
Iders Incorporated


From jsun at mvista.com  Wed Oct 29 18:13:15 2003
From: jsun at mvista.com (Jun Sun)
Date: Wed, 29 Oct 2003 15:13:15 -0800
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <03102916572705.02584@kilauea.iders.ca>;
	from cmayor@iders.ca on Wed, Oct 29, 2003 at 04:57:27PM -0600
References: <20031022182558.U19834@mvista.com>
	<1067426006.15551.1546.camel@hades.cambridge.redhat.com>
	<20031029104546.K30683@mvista.com> <03102916572705.02584@kilauea.iders.ca>
Message-ID: <20031029151315.E6588@mvista.com>

On Wed, Oct 29, 2003 at 04:57:27PM -0600, Cam Mayor wrote:
> On Wednesday 29 October 2003 12:45, Jun Sun wrote:
> > On Wed, Oct 29, 2003 at 11:13:26AM +0000, David Woodhouse wrote:
> > >
> > > That's nicer. Why multiple physmap_add_partition() calls rather than
> > > just a single array passed to physmap_set_map() though?
> >
> > Hmm, currently partition only matters when CONFIG_MTD_PARTITIONS
> > is enabled.  I assume this mean sometimes people want to use
> > physmap without partitions.  True?
> 
> Yes.  We have a product that partitions physmap (from the kernel command 
> line), but also uses the unpartitioned physmap base device. 
> 
> ie. physmap on /dev/mtd0
>     physmap partitions on /dev/mtd1, /dev/mtd2, etc.   sometimes none.
> 

Thanks for the data point.  

My original comment is really a question to David: do we really
want "partition" to be an argument in phsmap_set_map() even when
CONFIG_MTD_PARTITIONS is _not_ configured?

If David does not like multiple add partition calls, we can
easily introduce another interface function:

 	physmap_set_partitions(partitions)

So it seems like we have three possibilities in terms
how a board tells physmap driver about the partitions:

1) lumped in physmap_set_map() (as David suggested)

2) calling adding parition multiple times (as in my original
   proposal)

3) calling adding partitions in one shot with an array.

I don't like 1) because of CONFIG_MTD_PARTITION issue.  But if
David insists, I can modify patch as such.

Jun


From jsun at mvista.com  Wed Oct 29 18:15:16 2003
From: jsun at mvista.com (Jun Sun)
Date: Wed, 29 Oct 2003 15:15:16 -0800
Subject: [PATCH] extend physmap.c to support run-time adding partitions
In-Reply-To: <20031029193209.GA23482@wohnheim.fh-wedel.de>;
	from joern@wohnheim.fh-wedel.de on Wed, Oct 29, 2003 at 08:32:09PM +0100
References: <20031022182558.U19834@mvista.com>
	<20031027101741.C1678@mvista.com>
	<1067338214.15551.405.camel@hades.cambridge.redhat.com>
	<20031028182828.D30683@mvista.com>
	<1067426006.15551.1546.camel@hades.cambridge.redhat.com>
	<20031029104546.K30683@mvista.com>
	<20031029193209.GA23482@wohnheim.fh-wedel.de>
Message-ID: <20031029151516.F6588@mvista.com>

On Wed, Oct 29, 2003 at 08:32:09PM +0100, J?rn Engel wrote:
> On Wed, 29 October 2003 10:45:46 -0800, Jun Sun wrote:
> > 
> > phsmap currently only supports mapping for one physical flash unit.
> 
> I've created a physmap variant for multiply physical mappings once.
> Google for mphysmap.c and you can still find it.  No reaction
> whatsoever to this day, so you can guess how many people need it. ;)
> 

Cool!  I think once we extend phsymap driver and get more boards
converted to using it good stuff like this will be in much more demand.

Jun


From robin.gilks at tait.co.nz  Wed Oct 29 22:05:31 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Thu, 30 Oct 2003 16:05:31 +1300
Subject: device major/minor attributes corrupt in jffs2
Message-ID: <3FA07FFB.4020403@tait.co.nz>

Greetings

Just trying to put a root filesystem into jffs2 and whilst I can mount 
the filesystem and copy my /dev directory into it and it looks OK, when 
I reboot the major/minor numbers have been added together into the minor 
and the major is always 0

Anyone any ideas?

target mpc8xx cross compiled from i386 with gcc-3.3.1
kernel 2.4.22
mtd snapshot of 22-10-03
busybox 1.00-pre3 utils
uclibc 0.9.20 library

-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From ruslics at yahoo.com  Thu Oct 30 03:04:00 2003
From: ruslics at yahoo.com (Ruslan Satlykov)
Date: Thu, 30 Oct 2003 11:04:00 +0300
Subject: read_inode() after mount
Message-ID: <200310301104.00496.ruslics@yahoo.com>


  To David Woodhouse,

  In TODO file from JFFS2 filesystem drivers' source tree, you wrote about 
twice flash readings right after mount. Could you please explain this? And 
how it interference with jffs2_scan_medium()?

  Thank you,
  Ruslan


From dwmw2 at infradead.org  Thu Oct 30 06:52:58 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 30 Oct 2003 11:52:58 +0000
Subject: jffs2 vs NFTL
In-Reply-To: <3FA0119A.9020003@celerity.net>
References: <3FA0119A.9020003@celerity.net>
Message-ID: <1067514777.3423.11.camel@hades.cambridge.redhat.com>

On Wed, 2003-10-29 at 11:14 -0800, Chris Ellec wrote:
> A couple years ago I developped a system wih DOC using [N]FTL and an 
> ext2 file system which was working fine.
> 
> Now I have a new project where we'll use JFFS2 for reliability instead 
> of ext2, but I am confused as to the relationship between JFFS2 and NFTL.

JFFS2 is a file system which works directly on flash. The MTD API below
it, the Linux VFS above it.

NFTL, INFTL etc. are a kind of pseudo-filesystem which emulates a normal
block device with overwritable 512-byte sectors. The MTD API below them,
the Linux block layer above. On these, you are expected to use a
'normal' file system such as ext2, ext3, Reiserfs, etc.

> For example the help provided in the Configuration steps says that 
> CONFIG_MTD_PARTITIONS is not needed for Diskonchip, however
> http://www.linux-mtd.infradead.org/tech/nand.html
> says that the same flag is needed for JFFS2

CONFIG_MTD_PARTITIONS just gives you a way to divide a single MTD device
into many logical MTD devices. You do not need it for the DiskOnChip
because you do not use multiple logical flash devices there. If you have
'partitions' on your DiskOnChip, then you're probably thinking of
block-device partitions, which are an entirely different thing, at a
higher level.

> Does that mean that the JFFS2 driver does not use the NFTL driver ? What 
> about the new chips that need the INFTL driver ?

JFFS2 does not use the NFTL or INFTL code. JFFS2 operates directly on
flash, not on a block device.

-- 
dwmw2



From carles.perello at ieee.org  Thu Oct 30 07:43:34 2003
From: carles.perello at ieee.org (Carles Perello)
Date: 30 Oct 2003 13:43:34 +0100
Subject: mtd from cvs compiles for a 2.4.x kernel?
In-Reply-To: <1067455652.662.3.camel@stream.amrsystems.com>
References: <1067455652.662.3.camel@stream.amrsystems.com>
Message-ID: <1067517813.670.11.camel@stream.amrsystems.com>

On Wed, 2003-10-29 at 20:27, Carles Perello wrote:
> I updated my mtd sources from CVS today and patched a 2.4.19 kernel for
> an arm target...
> 
> while trying to compile complains about undefined SA1100_CS0_PHYS in
> sa1100-flash.c.
> 

I answer my own problem: kernel 2.4.20 has a new sa1100.h which inludes
the needed definitions.

Sorry about the noise

-- 
Carles Perello <carles.perello at ieee.org>


From simon at baydel.com  Thu Oct 30 09:26:30 2003
From: simon at baydel.com (Simon Haynes)
Date: Thu, 30 Oct 2003 14:26:30 +0000
Subject: SmartMedia FAT
In-Reply-To: <1067424903.15551.1537.camel@hades.cambridge.redhat.com>
References: <3F9F94C0.28402.10FED3@localhost>
	<1067424903.15551.1537.camel@hades.cambridge.redhat.com>
Message-ID: <EDC19A8677F@baydel.com>

I have been looking at the OOB data format for SSFDC and it seems I will have 
to create and process my own OOB data as I can not see how the NAND/MTD layer 
will work with this. 

When we started this project there seemed to be a fixed NAND OOB format. Now 
the NAND OOB format is selectable. I have noticed in a couple of kernel 
distributions that the JFFS2 code does not seem to be aware of this and just 
calls pain mtd->read. I guess this would mean no ecc for JFFS2 on NAND unless 
it was done automatically by the hardware. This was the case for latest 
stable kernel, 2.4.22 downloaded from kernel.org today. 

Is this really the case ?

Cheers

Simon.


On Wednesday 29 Oct 2003 10:55 am, David Woodhouse wrote:
> On Wed, 2003-10-29 at 10:21 +0000, simon at baydel.com wrote:
> > Thanks too all for your help. I have started to write my own block
> > driver using the FTL code as a guide. It seems fairly simple and
> > should not take too long.
>
> Send me a SSH key and I'll give you an account so you can put it in CVS.
> Commit early and often and I'll try to heckle helpfully... :)


From dwmw2 at infradead.org  Thu Oct 30 10:03:34 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 30 Oct 2003 15:03:34 +0000
Subject: SmartMedia FAT
In-Reply-To: <EDC19A8677F@baydel.com>
References: <3F9F94C0.28402.10FED3@localhost>
	 <1067424903.15551.1537.camel@hades.cambridge.redhat.com>
	 <EDC19A8677F@baydel.com>
Message-ID: <1067526214.3423.147.camel@hades.cambridge.redhat.com>

On Thu, 2003-10-30 at 14:26 +0000, Simon Haynes wrote:
> I have been looking at the OOB data format for SSFDC and it seems I will have 
> to create and process my own OOB data as I can not see how the NAND/MTD layer 
> will work with this. 

Yes, that's expected. NFTL and JFFS2 do this too.

> When we started this project there seemed to be a fixed NAND OOB format. Now 
> the NAND OOB format is selectable. I have noticed in a couple of kernel 
> distributions that the JFFS2 code does not seem to be aware of this and just 
> calls pain mtd->read. I guess this would mean no ecc for JFFS2 on NAND unless 
> it was done automatically by the hardware. This was the case for latest 
> stable kernel, 2.4.22 downloaded from kernel.org today. 
> 
> Is this really the case ?

The JFFS2 in the 2.4 kernel doesn't support NAND. The code in CVS does.


-- 
dwmw2



From joern at wohnheim.fh-wedel.de  Thu Oct 30 12:45:30 2003
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Thu, 30 Oct 2003 18:45:30 +0100
Subject: jffs2 fragmentation
In-Reply-To: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>
References: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>
Message-ID: <20031030174530.GC25390@wohnheim.fh-wedel.de>

Noone cared yet, how odd.

On Sat, 18 October 2003 09:20:23 -0500, J B wrote:
> 
> Ok, maybe I am just completely missing something here, but I am stumped.  I 
> am running some tests (similar to the jitter tests Vipin did a long time 
> ago), and I am seeing some very bad performance.   Below is a summary of 
> what I am doing and what I am seeing.
> 
> I have a jffs2 filesystem that is mounted and starts out at ~87% full.  
> There are various small files on there, and one big file, ~15MiB (lgood 
> compression :).  Here is what I do:
> 
> rm /opt/big_file; cp /home/big_file /opt/big_file; rm /opt/big_file; cp 
> /home/big_file2 /opt/big_file
> 
> /opt is the jffs2 filesystem, /home is an nfs mounted directory.  big_file 
> and big_file2 are the same size, but have different content (i.e. possibly 
> different compression ratios).
> 
> Normally, a rm/cp pair takes about 2 minutes on my system.  After about 10 
> iterations, the copies begin to take longer, about 3-4 minutes.   After 
> about 10 iterations they take upwards of 1/2 an hour.

The first slowdown is expected, the second is not.

When flash is full, jffs2 has to wait for garbage collection before
writing.  Flash erase costs roughly as long as flash write, so double
time is expected.  Try to add a sleep after each rm and this should go
away.

1/2 hour is a surprise.  Does this still appear, when adding a sleep?

> Looking at the dirty, used, and wasted size from a df command, I see this:
> 
> <7>STATFS:
> <7>flash_size:	00680000
> <7>used_size:		0041afe4
> <7>dirty_size:	00199d2c
> <7>wasted_size:	0000012c
> <7>free_size:		000cb1c4
> <7>erasing_size:	00000000
> <7>bad_size:		00000000
> <7>sector_size:	00020000
> <7>nextblock:	      0x00660000
> <7>gcblock:	      0x000a0000
> 
> So almost 13 eraseblocks worth of dirty space (NOR flash with 128KiB 
> eraseblocks).  But, there is only 1 block on the dirty_list, 6 on the 
> free_list, and 44 on the clean_list.  Garbage collection is going on during 
> the writes obviously, but it doesn't seem to be making any difference.  In 
> fact, the dirty_size _increases_.
> 
> So here is my question:  because of the size of the file involved and the 
> relative lack of free eraseblocks to start with, is it possible that the 
> filesystem is so fragmented that the dirty space is spread accross many 
> eraseblocks and garbage collection is incapable of actually freeing up any 
> space?

Fragmentation is hard to achieve for log structured file systems. ;)

Honestly, I have no idea.  Your test is not the usual workload for
jffs2, so you may have uncovered some hidden problem. (and one that
most people don't care about)

> That is the only conclusion I could come to.  Any thoughts would be 
> appreciated.

J?rn

-- 
Homo Sapiens is a goal, not a description.
-- unknown


From dwmw2 at infradead.org  Thu Oct 30 13:53:08 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 30 Oct 2003 18:53:08 +0000
Subject: jffs2 fragmentation
In-Reply-To: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>
References: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>
Message-ID: <1067539988.3423.208.camel@hades.cambridge.redhat.com>

On Sat, 2003-10-18 at 09:20 -0500, J B wrote:
> Normally, a rm/cp pair takes about 2 minutes on my system.  After about 10 
> iterations, the copies begin to take longer, about 3-4 minutes.   After 
> about 10 iterations they take upwards of 1/2 an hour.

I suspect you've triggered the worst case of a performance bug which
I've known about for a while.

We should write new data out to one empty block, while writing out
garbage-collected data out to another. We don't do that at the moment;
we interleave old and new data and then you erase your new file, leaving
us with a very suboptimal mix of valid and obsolete nodes in each
eraseblock we've been writing to.

I'm still a bit surprised it takes half an hour though. 

-- 
dwmw2



From david at avoncliff.com  Thu Oct 30 16:03:42 2003
From: david at avoncliff.com (david stevenson)
Date: Thu, 30 Oct 2003 21:03:42 +0000
Subject: zlib versions
Message-ID: <200310302103.42918.david@avoncliff.com>

Could someone please educate me on zlib?

I can compile kernel 2.4.21 with MTD updated from tarball 20031021 with jff2 
with no errors.
But when I try and compile the utils from the same tar ball, using the same 
kernel headers I get error file not found zlib.h.

I can compile the utils against the kernel headers on my host 2.4.20 without 
error. But I guess then the binaries will not run on the target machine?

The difference appears to be linux/zlib v1.1.3 or /zlib v1.1.4 but I am not 
sure what I should use to get utils that run.
Thanks
David



From robin.gilks at tait.co.nz  Thu Oct 30 16:43:50 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Fri, 31 Oct 2003 10:43:50 +1300
Subject: Has anyone managed to compile jffs2reader lately?
Message-ID: <3FA18616.6090201@tait.co.nz>

I note that its commented out in the makefile and despite various hacks 
and trials I'm unable to compile it since it seems to suffer rather a 
lot of typedef problems (inherited from zlib I think).

I'll not include the whole list (too big) but this is an example of the 
errors I'm seeing.

jffs2reader.c: In function `putblock':
jffs2reader.c:139: incompatible types in initialization
jffs2reader.c:141: invalid operands to binary >
jffs2reader.c:141: invalid operands to binary +
jffs2reader.c:146: invalid operands to binary <
jffs2reader.c:147: invalid operands to binary -
jffs2reader.c:151: invalid operands to binary +

This lack of an analysis tool means I'm unable to debug the device file 
problems I reports yesterday.

-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From robin.gilks at tait.co.nz  Thu Oct 30 16:49:13 2003
From: robin.gilks at tait.co.nz (Robin Gilks)
Date: Fri, 31 Oct 2003 10:49:13 +1300
Subject: device major/minor attributes corrupt in jffs2
In-Reply-To: <3FA07FFB.4020403@tait.co.nz>
References: <3FA07FFB.4020403@tait.co.nz>
Message-ID: <3FA18759.2070901@tait.co.nz>

Robin Gilks wrote:
> Greetings
> 
> Just trying to put a root filesystem into jffs2 and whilst I can mount 
> the filesystem and copy my /dev directory into it and it looks OK, when 
> I reboot the major/minor numbers have been added together into the minor 
> and the major is always 0
> 
> Anyone any ideas?
> 
> target mpc8xx cross compiled from i386 with gcc-3.3.1
> kernel 2.4.22
> mtd snapshot of 22-10-03
> busybox 1.00-pre3 utils
> uclibc 0.9.20 library
> 

More info - just unmount and remount and the device file attributes are 
  buggered - I assume that the cache is OK but the data written to flash 
is not :-((

Also, it looks like the major/minor numbers not added - can't work out 
exactly what is going on !!

/home # ./MAKEDEV
/home # ls -l /mnt/dev/mtd*
crw-r--r--    1 root     root      90,   0 Jan  1 17:26 /mnt/dev/mtd0
crw-r--r--    1 root     root      90,   2 Jan  1 17:26 /mnt/dev/mtd1
crw-r--r--    1 root     root      90,   4 Jan  1 17:26 /mnt/dev/mtd2
crw-r--r--    1 root     root      90,   6 Jan  1 17:26 /mnt/dev/mtd3
crw-r--r--    1 root     root      90,   8 Jan  1 17:26 /mnt/dev/mtd4
crw-r--r--    1 root     root      90,  10 Jan  1 17:26 /mnt/dev/mtd5
crw-r--r--    1 root     root      90,  12 Jan  1 17:26 /mnt/dev/mtd6
crw-r--r--    1 root     root      90,  14 Jan  1 17:26 /mnt/dev/mtd7
/home # umount /mnt
/home # mount /mnt
/home # ls -l /mnt/dev/mtd*
crw-r--r--    1 root     root       0,  90 Jan  1 17:26 /mnt/dev/mtd0
crw-r--r--    1 root     root       0,  90 Jan  1 17:26 /mnt/dev/mtd1
crw-r--r--    1 root     root       0,  94 Jan  1 17:26 /mnt/dev/mtd2
crw-r--r--    1 root     root       0,  94 Jan  1 17:26 /mnt/dev/mtd3
crw-r--r--    1 root     root       0,  90 Jan  1 17:26 /mnt/dev/mtd4
crw-r--r--    1 root     root       0,  90 Jan  1 17:26 /mnt/dev/mtd5
crw-r--r--    1 root     root       0,  94 Jan  1 17:26 /mnt/dev/mtd6
crw-r--r--    1 root     root       0,  94 Jan  1 17:26 /mnt/dev/mtd7


-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks at tait.co.nz
New Zealand



From dwmw2 at infradead.org  Thu Oct 30 17:20:05 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 30 Oct 2003 22:20:05 +0000
Subject: Has anyone managed to compile jffs2reader lately?
In-Reply-To: <3FA18616.6090201@tait.co.nz>
References: <3FA18616.6090201@tait.co.nz>
Message-ID: <1067552405.21312.41.camel@imladris.demon.co.uk>

On Fri, 2003-10-31 at 10:43 +1300, Robin Gilks wrote:
> I note that its commented out in the makefile and despite various hacks 
> and trials I'm unable to compile it since it seems to suffer rather a 
> lot of typedef problems (inherited from zlib I think).

Omit '-I../include' from its CFLAGS; let it include _old_ JFFS2 kernel
headers from your 2.4 kernel.

-- 
dwmw2




From miernik at ctnet.pl  Fri Oct 31 04:49:20 2003
From: miernik at ctnet.pl (Miernik)
Date: Fri, 31 Oct 2003 10:49:20 +0100
Subject: "this device cannot be used for FTL" with a SMART PCMCIA linear
	flash
Message-ID: <slrnbq4c10.qor.miernik@tarnica.ctnet.pl>

I'm trying to get a "SMART Modular Technologies 4MB FAST FLASH CARD 
SM9FA2043IP280" PCMCIA linear flash Intel Series 2+ card working.

The explanation of SM9FA2043IP280:

SM      Smart Modular
9       Product Category:       Memory Card
F       Technology:             Flash
A       Attribute:              With Attribute (2kB)
2       Nop. of banks:          2 Bank
04      Card Density:           4 MB
3       Component Data Width:   x16
I       Device Manufacturer:    Intel
P       Pinout:                 68 Pin PC Card (Type I)
2       Interface:              x16 only
80      Card Speed:             80ns


FLA16MPX16ICB REV.A

To know what I'm working with, I have opened the card, and found these 
4 chips:

2 * chip:
---------
Intel

E28F016SA
70   5.0V
120  3.3V
U84433T1C
1993

Flash
---------

---------
ATMEL
AT28C16
15TC
9837
---------

---------
IDT 74FCT
108CTQ
KP84ST
---------

I have accidentally erased attribute memory of this card, so it is 
detected only as anonymous memory. I fix it like this:

card "Anonymous Memory"
  anonymous
  cis "cis/smartm-4mb-flash.dat"
  bind "memory_cs", "ftl_cs"


I am using 2.4.22-3 kernel from Debian, self-compiled, not compiling 
pcmcia-modules from the kernel, but separately. 
I compiled pcmcia-modules_3.2.2-1.4.

These are self-made packages of my kernel and pcmcia-modules:
http://www.miernik.ctnet.pl/debian/pool/kernel-image-2.4.22_tarnica.1.0_i386.deb
http://www.miernik.ctnet.pl/debian/pool/pcmcia-modules-2.4.22_3.2.2-1.4+tarnica.1.0_i386.deb

This is my problem:

tarnica:~# ftl_format -i /dev/mem0c0c
this device cannot be used for FTL!
format failed.
tarnica:~#

tarnica:~# ftl_check /dev/mem0c0c
Memory region info:
  Card offset = 0x0, region size = 4 mb, access speed = 200 ns
  Erase block size = 1 bytes, partition multiple = 1 bytes

No valid erase unit headers!
tarnica:~#

If I try a dd to it I get "input/output error" or no error messages, 
but when I try to dd it back ftom the card, I get a file with all bits 
set to 1. Depending on if I try to use /dev/mem0c, /dev/mem0c0b or 
/dev/mem0c0c.

I forgot to note exactly what when happens with dd, and I can't check 
it not, as I have my WLAN card in that PCMCIA slot to access the 
Internet, I can check it later if needed.

Logs, pcmcia configuration, and other detailed info of my problems can 
be found in: http://www.miernik.ctnet.pl/mtd/3-repeat-clear/

-- 
    Miernik         ________________________ jabber:miernik at jabber.gda.pl
__ ICQ: 4004001 ___/__ tel: +48608233394 __/      mailto:miernik at ctnet.pl
Protect Europe from a law-disaster. Petition for a Software Patent Free Europe
http://www.noepatents.org/index_html?LANG=en 



From joern at wohnheim.fh-wedel.de  Fri Oct 31 06:24:21 2003
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 31 Oct 2003 12:24:21 +0100
Subject: jffs2 fragmentation
In-Reply-To: <1067539988.3423.208.camel@hades.cambridge.redhat.com>
References: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>
	<1067539988.3423.208.camel@hades.cambridge.redhat.com>
Message-ID: <20031031112421.GC5604@wohnheim.fh-wedel.de>

On Thu, 30 October 2003 18:53:08 +0000, David Woodhouse wrote:
> On Sat, 2003-10-18 at 09:20 -0500, J B wrote:
> > Normally, a rm/cp pair takes about 2 minutes on my system.  After about 10 
> > iterations, the copies begin to take longer, about 3-4 minutes.   After 
> > about 10 iterations they take upwards of 1/2 an hour.
> 
> I suspect you've triggered the worst case of a performance bug which
> I've known about for a while.
> 
> We should write new data out to one empty block, while writing out
> garbage-collected data out to another. We don't do that at the moment;
> we interleave old and new data and then you erase your new file, leaving
> us with a very suboptimal mix of valid and obsolete nodes in each
> eraseblock we've been writing to.
> 
> I'm still a bit surprised it takes half an hour though. 

If your explanation is correct, a shift from 4 to 28 minutes would
correspond to 6 clean nodes reused for every 1 dirty node deleted and
new node written.

Doesn't make a lot of sense with a filesystem that should be >80% free
or dirty, does it?

J?rn

-- 
Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982


From dwmw2 at infradead.org  Fri Oct 31 06:53:20 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 31 Oct 2003 11:53:20 +0000
Subject: jffs2 fragmentation
In-Reply-To: <20031031112421.GC5604@wohnheim.fh-wedel.de>
References: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>
	 <1067539988.3423.208.camel@hades.cambridge.redhat.com>
	 <20031031112421.GC5604@wohnheim.fh-wedel.de>
Message-ID: <1067601200.24809.13.camel@imladris.demon.co.uk>

On Fri, 2003-10-31 at 12:24 +0100, J?rn Engel wrote:
> If your explanation is correct, a shift from 4 to 28 minutes would
> correspond to 6 clean nodes reused for every 1 dirty node deleted and
> new node written.
> 
> Doesn't make a lot of sense with a filesystem that should be >80% free
> or dirty, does it?

Hmmm. The figure of 87% was _with_ the large file, wasn't it? How full
is it when the large file is deleted? 

When it's 80% full it does make sense. It's 80% full. 20% "free or
dirty". Your 20% free space is mixed in with the clean data; you have to
move 6 nodes out of the way for every node's worth of space you recover.

Consider the case where every eraseblock has 80% clean data and 20% of
each contains part of the large file you've just deleted, and is hence
now dirty. Then you write the same large file again. Garbage collection
happens -- each time we GC a full eraseblock we recover and rewrite 80%
of an eraseblock of clean data, and we manage to write 20% of an
eraseblock of the new file. The 80/20 ratio hence remains stable.

-- 
dwmw2




From david at avoncliff.com  Fri Oct 31 07:25:19 2003
From: david at avoncliff.com (david stevenson)
Date: Fri, 31 Oct 2003 12:25:19 +0000
Subject: "this device cannot be used for FTL" with a SMART PCMCIA linear
	flash
In-Reply-To: <slrnbq4c10.qor.miernik@tarnica.ctnet.pl>
References: <slrnbq4c10.qor.miernik@tarnica.ctnet.pl>
Message-ID: <200310311225.19498.david@avoncliff.com>

On Friday 31 October 2003 9:49 am, Miernik wrote:
> I'm trying to get a "SMART Modular Technologies 4MB FAST FLASH CARD
> SM9FA2043IP280" PCMCIA linear flash Intel Series 2+ card working.

I am new round here so can not help directly with your problem, but do you 
know about wrflash utility that comes as part of the alios bootloader from
www.telos.info/ftp/linux/alios/alios-source-2.2.tar.gz
I use it to erase and write to /dev/mem0c0c.
David



From joern at wohnheim.fh-wedel.de  Fri Oct 31 07:50:56 2003
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 31 Oct 2003 13:50:56 +0100
Subject: jffs2 fragmentation
In-Reply-To: <1067601200.24809.13.camel@imladris.demon.co.uk>
References: <Law11-F26lgYBr4BvRn0000b9c5@hotmail.com>
	<1067539988.3423.208.camel@hades.cambridge.redhat.com>
	<20031031112421.GC5604@wohnheim.fh-wedel.de>
	<1067601200.24809.13.camel@imladris.demon.co.uk>
Message-ID: <20031031125056.GA8119@wohnheim.fh-wedel.de>

On Fri, 31 October 2003 11:53:20 +0000, David Woodhouse wrote:
> On Fri, 2003-10-31 at 12:24 +0100, J?rn Engel wrote:
> > If your explanation is correct, a shift from 4 to 28 minutes would
> > correspond to 6 clean nodes reused for every 1 dirty node deleted and
> > new node written.
> > 
> > Doesn't make a lot of sense with a filesystem that should be >80% free
> > or dirty, does it?
> 
> Hmmm. The figure of 87% was _with_ the large file, wasn't it? How full
> is it when the large file is deleted? 
> 
> When it's 80% full it does make sense. It's 80% full. 20% "free or
> dirty". Your 20% free space is mixed in with the clean data; you have to
> move 6 nodes out of the way for every node's worth of space you recover.
> 
> Consider the case where every eraseblock has 80% clean data and 20% of
> each contains part of the large file you've just deleted, and is hence
> now dirty. Then you write the same large file again. Garbage collection
> happens -- each time we GC a full eraseblock we recover and rewrite 80%
> of an eraseblock of clean data, and we manage to write 20% of an
> eraseblock of the new file. The 80/20 ratio hence remains stable.

Sorry, I should have reread the original message.  The fs under
pressure is permanently 87% full, not 87% empty.  Makes perfect sense
now.

J?rn

-- 
When in doubt, punt.  When somebody actually complains, go back and fix it...
The 90% solution is a good thing.
-- Rob Landley


From dwmw2 at infradead.org  Fri Oct 31 11:12:18 2003
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 31 Oct 2003 16:12:18 +0000
Subject: zlib versions
In-Reply-To: <200310302103.42918.david@avoncliff.com>
References: <200310302103.42918.david@avoncliff.com>
Message-ID: <1067616737.3423.283.camel@hades.cambridge.redhat.com>

On Thu, 2003-10-30 at 21:03 +0000, david stevenson wrote:
> Could someone please educate me on zlib?
> 
> I can compile kernel 2.4.21 with MTD updated from tarball 20031021 with jff2 
> with no errors.
> But when I try and compile the utils from the same tar ball, using the same 
> kernel headers I get error file not found zlib.h.

Do you have the zlib-devel package installed? Are you compiling natively
or cross-compiling?

-- 
dwmw2



From david at avoncliff.com  Fri Oct 31 13:49:09 2003
From: david at avoncliff.com (david stevenson)
Date: Fri, 31 Oct 2003 18:49:09 +0000
Subject: zlib versions
In-Reply-To: <1067616737.3423.283.camel@hades.cambridge.redhat.com>
References: <200310302103.42918.david@avoncliff.com>
	<1067616737.3423.283.camel@hades.cambridge.redhat.com>
Message-ID: <200310311849.09315.david@avoncliff.com>

On Friday 31 October 2003 4:12 pm, David Woodhouse wrote:
> On Thu, 2003-10-30 at 21:03 +0000, david stevenson wrote:
> > Could someone please educate me on zlib?
> >
> > I can compile kernel 2.4.21 with MTD updated from tarball 20031021 with
> > jff2 with no errors.
> > But when I try and compile the utils from the same tar ball, using the
> > same kernel headers I get error file not found zlib.h.
>
> Do you have the zlib-devel package installed? Are you compiling natively
> or cross-compiling?

I am cross compiling - well actually it is from pentium to i386.

I do not know about zlib-devel, which probably means I don't have it.
But the kernel code includes include/linux/zlib.h which is included by 
/fs/jffs2/compr_zlib.c and this compiles OK. So I assumed I had all that was 
needed.

However in the util tree compr_zlib.c is looking for include/zlib.h, and I 
belive a different version.

If I need to get zlib-devel can you give a reference to where I get it from as 
I have seen confusing alternatives.

Thanks
David



