From andrew at sanpeople.com  Tue Feb  1 03:44:15 2005
From: andrew at sanpeople.com (Andrew Victor)
Date: 01 Feb 2005 10:44:15 +0200
Subject: JFFS2-on-DataFlash : 1 - Core changes
Message-ID: <1107247455.22636.36.camel@fuzzie.sanpeople.com>

hi,

Based on the previous comments, the patch has been split up.

The changes included in this patch are:

DataFlash page-sizes are not a power of two (they're multiples of 528
bytes).  There are a few places in JFFS2 code where sector_size is used
as a bitmask.  A new macro (SECTOR_ADDR) was defined to calculate these
sector addresses. For non-DataFlash devices, the original (faster)
bitmask operation is still used.

In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. 
Since this could be larger than the sector size of the DataFlash, this
is now basically set to MIN(sector_size, 1024).

Addition of a jffs2_is_writebuffered() macro.

Regards,
  Andrew Victor


diff -urN -x CVS mtd.orig/fs/jffs2/erase.c mtd.core/fs/jffs2/erase.c
--- mtd.orig/fs/jffs2/erase.c	Wed Jan 26 16:07:57 2005
+++ mtd.core/fs/jffs2/erase.c	Tue Feb  1 10:06:13 2005
@@ -233,7 +233,7 @@
 			continue;
 		} 
 
-		if (((*prev)->flash_offset & ~(c->sector_size -1)) == jeb->offset) {
+		if (SECTOR_ADDR((*prev)->flash_offset) == jeb->offset) {
 			/* It's in the block we're erasing */
 			struct jffs2_raw_node_ref *this;
 
diff -urN -x CVS mtd.orig/fs/jffs2/gc.c mtd.core/fs/jffs2/gc.c
--- mtd.orig/fs/jffs2/gc.c	Wed Jan 26 16:07:57 2005
+++ mtd.core/fs/jffs2/gc.c	Tue Feb  1 10:06:13 2005
@@ -816,8 +816,7 @@
 
 			/* Doesn't matter if there's one in the same erase block. We're going to 
 			   delete it too at the same time. */
-			if ((raw->flash_offset & ~(c->sector_size-1)) ==
-			    (fd->raw->flash_offset & ~(c->sector_size-1)))
+			if (SECTOR_ADDR(raw->flash_offset) == SECTOR_ADDR(fd->raw->flash_offset))
 				continue;
 
 			D1(printk(KERN_DEBUG "Check potential deletion dirent at %08x\n", ref_offset(raw)));
diff -urN -x CVS mtd.orig/fs/jffs2/os-linux.h mtd.core/fs/jffs2/os-linux.h
--- mtd.orig/fs/jffs2/os-linux.h	Wed Jan 26 16:07:58 2005
+++ mtd.core/fs/jffs2/os-linux.h	Tue Feb  1 10:06:13 2005
@@ -97,7 +97,10 @@
 #endif
 }
 
+#define SECTOR_ADDR(x) ( ((unsigned long)(x) & ~(c->sector_size-1)) )
+
 #define jffs2_is_readonly(c) (OFNI_BS_2SFFJ(c)->s_flags & MS_RDONLY)
+#define jffs2_is_writebuffered(c) (c->wbuf != NULL)
 
 #if (!defined CONFIG_JFFS2_FS_NAND && !defined CONFIG_JFFS2_FS_NOR_ECC)
 #define jffs2_can_mark_obsolete(c) (1)
diff -urN -x CVS mtd.orig/fs/jffs2/scan.c mtd.core/fs/jffs2/scan.c
--- mtd.orig/fs/jffs2/scan.c	Wed Jan 26 16:07:58 2005
+++ mtd.core/fs/jffs2/scan.c	Tue Feb  1 10:07:55 2005
@@ -19,7 +19,7 @@
 #include <linux/compiler.h>
 #include "nodelist.h"
 
-#define EMPTY_SCAN_SIZE 1024
+#define DEFAULT_EMPTY_SCAN_SIZE 1024
 
 #define DIRTY_SPACE(x) do { typeof(x) _x = (x); \
 		c->free_size -= _x; c->dirty_size += _x; \
@@ -75,6 +75,14 @@
 	return min;
 
 }
+
+static inline uint32_t EMPTY_SCAN_SIZE(uint32_t sector_size) {
+	if (sector_size < DEFAULT_EMPTY_SCAN_SIZE)
+		return sector_size;
+	else
+		return DEFAULT_EMPTY_SCAN_SIZE;
+}
+
 int jffs2_scan_medium(struct jffs2_sb_info *c)
 {
 	int i, ret;
@@ -316,7 +324,7 @@
 	if (!buf_size) {
 		buf_len = c->sector_size;
 	} else {
-		buf_len = EMPTY_SCAN_SIZE;
+		buf_len = EMPTY_SCAN_SIZE(c->sector_size);
 		err = jffs2_fill_scan_buf(c, buf, buf_ofs, buf_len);
 		if (err)
 			return err;
@@ -326,10 +334,10 @@
 	ofs = 0;
 
 	/* Scan only 4KiB of 0xFF before declaring it's empty */
-	while(ofs < EMPTY_SCAN_SIZE && *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF)
+	while(ofs < EMPTY_SCAN_SIZE(c->sector_size) && *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF)
 		ofs += 4;
 
-	if (ofs == EMPTY_SCAN_SIZE) {
+	if (ofs == EMPTY_SCAN_SIZE(c->sector_size)) {
 #ifdef CONFIG_JFFS2_FS_NAND
 		if (jffs2_cleanmarker_oob(c)) {
 			/* scan oob, take care of cleanmarker */
@@ -423,7 +431,7 @@
 			   bail now */
 			if (buf_ofs == jeb->offset && jeb->used_size == PAD(c->cleanmarker_size) && 
 			    c->cleanmarker_size && !jeb->dirty_size && !jeb->first_node->next_in_ino) {
-				D1(printk(KERN_DEBUG "%d bytes at start of block seems clean... assuming all clean\n", EMPTY_SCAN_SIZE));
+				D1(printk(KERN_DEBUG "%d bytes at start of block seems clean... assuming all clean\n", EMPTY_SCAN_SIZE(c->sector_size)));
 				return BLK_STATE_CLEANMARKER;
 			}
 
diff -urN -x CVS mtd.orig/fs/jffs2/wbuf.c mtd.core/fs/jffs2/wbuf.c
--- mtd.orig/fs/jffs2/wbuf.c	Wed Jan 26 16:07:58 2005
+++ mtd.core/fs/jffs2/wbuf.c	Tue Feb  1 10:06:13 2005
@@ -415,9 +415,9 @@
 	int ret;
 	size_t retlen;
 
-	/* Nothing to do if not NAND flash. In particular, we shouldn't
+	/* Nothing to do if not write-buffering the flash. In particular, we shouldn't
 	   del_timer() the timer we never initialised. */
-	if (jffs2_can_mark_obsolete(c))
+	if (!jffs2_is_writebuffered(c))
 		return 0;
 
 	if (!down_trylock(&c->alloc_sem)) {
@@ -426,7 +426,7 @@
 		BUG();
 	}
 
-	if(!c->wbuf || !c->wbuf_len)
+	if (!c->wbuf_len)	/* already checked c->wbuf above */
 		return 0;
 
 	/* claim remaining space on the page
@@ -614,7 +614,7 @@
 	uint32_t outvec_to = to;
 
 	/* If not NAND flash, don't bother */
-	if (!c->wbuf)
+	if (!jffs2_is_writebuffered(c))
 		return jffs2_flash_direct_writev(c, invecs, count, to, retlen);
 	
 	down_write(&c->wbuf_sem);
@@ -643,7 +643,7 @@
 	   erase block. Anything else, and you die.
 	   New block starts at xxx000c (0-b = block header)
 	*/
-	if ( (to & ~(c->sector_size-1)) != (c->wbuf_ofs & ~(c->sector_size-1)) ) {
+	if (SECTOR_ADDR(to) != SECTOR_ADDR(c->wbuf_ofs)) {
 		/* It's a write to a new block */
 		if (c->wbuf_len) {
 			D1(printk(KERN_DEBUG "jffs2_flash_writev() to 0x%lx causes flush of wbuf at 0x%08x\n", (unsigned long)to, c->wbuf_ofs));
@@ -841,7 +841,7 @@
 {
 	struct kvec vecs[1];
 
-	if (jffs2_can_mark_obsolete(c))
+	if (!jffs2_is_writebuffered(c))
 		return c->mtd->write(c->mtd, ofs, len, retlen, buf);
 
 	vecs[0].iov_base = (unsigned char *) buf;
@@ -857,39 +857,39 @@
 	loff_t	orbf = 0, owbf = 0, lwbf = 0;
 	int	ret;
 
+	if (!jffs2_is_writebuffered(c))
+		return c->mtd->read(c->mtd, ofs, len, retlen, buf);
+
 	/* Read flash */
-	if (!jffs2_can_mark_obsolete(c)) {
-		down_read(&c->wbuf_sem);
+	down_read(&c->wbuf_sem);
 
-		if (jffs2_cleanmarker_oob(c))
-			ret = c->mtd->read_ecc(c->mtd, ofs, len, retlen, buf, NULL, c->oobinfo);
-		else
-			ret = c->mtd->read(c->mtd, ofs, len, retlen, buf);
+	if (jffs2_cleanmarker_oob(c))
+		ret = c->mtd->read_ecc(c->mtd, ofs, len, retlen, buf, NULL, c->oobinfo);
+	else
+		ret = c->mtd->read(c->mtd, ofs, len, retlen, buf);
 
-		if ( (ret == -EBADMSG) && (*retlen == len) ) {
-			printk(KERN_WARNING "mtd->read(0x%zx bytes from 0x%llx) returned ECC error\n",
-			       len, ofs);
-			/* 
-			 * We have the raw data without ECC correction in the buffer, maybe 
-			 * we are lucky and all data or parts are correct. We check the node.
-			 * If data are corrupted node check will sort it out.
-			 * We keep this block, it will fail on write or erase and the we
-			 * mark it bad. Or should we do that now? But we should give him a chance.
-			 * Maybe we had a system crash or power loss before the ecc write or  
-			 * a erase was completed.
-			 * So we return success. :)
-			 */
-		 	ret = 0;
-		 }	
-	} else
-		return c->mtd->read(c->mtd, ofs, len, retlen, buf);
+	if ( (ret == -EBADMSG) && (*retlen == len) ) {
+		printk(KERN_WARNING "mtd->read(0x%zx bytes from 0x%llx) returned ECC error\n",
+		       len, ofs);
+		/* 
+		 * We have the raw data without ECC correction in the buffer, maybe 
+		 * we are lucky and all data or parts are correct. We check the node.
+		 * If data are corrupted node check will sort it out.
+		 * We keep this block, it will fail on write or erase and the we
+		 * mark it bad. Or should we do that now? But we should give him a chance.
+		 * Maybe we had a system crash or power loss before the ecc write or  
+		 * a erase was completed.
+		 * So we return success. :)
+		 */
+	 	ret = 0;
+	}	
 
 	/* if no writebuffer available or write buffer empty, return */
 	if (!c->wbuf_pagesize || !c->wbuf_len)
 		goto exit;
 
 	/* if we read in a different block, return */
-	if ( (ofs & ~(c->sector_size-1)) != (c->wbuf_ofs & ~(c->sector_size-1)) ) 
+	if (SECTOR_ADDR(ofs) != SECTOR_ADDR(c->wbuf_ofs))
 		goto exit;
 
 	if (ofs >= c->wbuf_ofs) {






From andrew at sanpeople.com  Tue Feb  1 04:00:03 2005
From: andrew at sanpeople.com (Andrew Victor)
Date: 01 Feb 2005 11:00:03 +0200
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
Message-ID: <1107248402.22631.53.camel@fuzzie.sanpeople.com>

hi,

The changes included in this patch are:

For Dataflash, can_mark_obsolete = false and the NAND write buffering
code (wbuf.c) is used.

Since the DataFlash chip will automatically erase pages when writing,
the cleanmarkers are not needed - so cleanmarker_oob = false and
cleanmarker_size = 0

Configuration (Config.in and Kconfig) and Makefiles updated.

DataFlash page-sizes are not a power of two (they're multiples of 528
bytes).  The SECTOR_ADDR macro (added in the previous core patch) is
replaced with a (slower) div/mod version if CONFIG_JFFS2_FS_DATAFLASH is
selected.

Padding nodes are only skipped for DataFlash devices - no longer breaks
the NOR ECC flash support.


Regards,
  Andrew Victor



diff -urN -x CVS mtd.core/fs/Config.in mtd.new/fs/Config.in
--- mtd.core/fs/Config.in	Tue May 25 13:31:47 2004
+++ mtd.new/fs/Config.in	Tue Feb  1 10:17:22 2005
@@ -7,6 +7,7 @@
 if [ "$CONFIG_JFFS2_FS" = "y" -o "$CONFIG_JFFS2_FS" = "m" ] ; then
    int 'JFFS2 debugging verbosity (0 = quiet, 2 = noisy)' CONFIG_JFFS2_FS_DEBUG 0
    bool 'JFFS2 support for NAND chips' CONFIG_JFFS2_FS_NAND
+   bool 'JFFS2 support for DataFlash' CONFIG_JFFS2_FS_DATAFLASH
    bool 'JFFS2 ZLIB compression support (recommended)' CONFIG_JFFS2_ZLIB
    bool 'JFFS2 RTIME compression support (recommended)' CONFIG_JFFS2_RTIME
    bool 'JFFS2 RUBIN compression support' CONFIG_JFFS2_RUBIN
diff -urN -x CVS mtd.core/fs/Kconfig mtd.new/fs/Kconfig
--- mtd.core/fs/Kconfig	Wed Jan 26 16:07:56 2005
+++ mtd.new/fs/Kconfig	Tue Feb  1 10:17:22 2005
@@ -77,6 +77,13 @@
 		 ECC for JFFS2.  This type of flash chip is not common, however it is
 		 available from STMicro.
 
+config JFFS2_FS_DATAFLASH
+	bool "JFFS2 support for DataFlash (EXPERIMENTAL)"
+	depends on JFFS2_FS && EXPERIMENTAL
+	default n
+	help
+	  This enables the experimental support for JFFS2 on DataFlash devices.
+
 config JFFS2_COMPRESSION_OPTIONS
 	bool "Advanced compression options for JFFS2"
 	default n
diff -urN -x CVS mtd.core/fs/jffs2/Makefile.24 mtd.new/fs/jffs2/Makefile.24
--- mtd.core/fs/jffs2/Makefile.24	Mon Aug  9 20:46:05 2004
+++ mtd.new/fs/jffs2/Makefile.24	Tue Feb  1 10:17:22 2005
@@ -30,6 +30,7 @@
 LINUX_OBJS += super-v24.o crc32.o rbtree.o
 
 NAND_OBJS-$(CONFIG_JFFS2_FS_NAND) += wbuf.o
+NAND_OBJS-$(CONFIG_JFFS2_FS_DATAFLASH) += wbuf.o
 
 COMPR_OBJS-$(CONFIG_JFFS2_RUBIN)  += compr_rubin.o
 COMPR_OBJS-$(CONFIG_JFFS2_RTIME)  += compr_rtime.o
diff -urN -x CVS mtd.core/fs/jffs2/Makefile.common mtd.new/fs/jffs2/Makefile.common
--- mtd.core/fs/jffs2/Makefile.common	Wed Nov  3 14:57:38 2004
+++ mtd.new/fs/jffs2/Makefile.common	Tue Feb  1 10:17:22 2005
@@ -13,6 +13,7 @@
 
 jffs2-$(CONFIG_JFFS2_FS_NAND)	+= wbuf.o
 jffs2-$(CONFIG_JFFS2_FS_NOR_ECC) += wbuf.o
+jffs2-$(CONFIG_JFFS2_FS_DATAFLASH) += wbuf.o
 jffs2-$(CONFIG_JFFS2_RUBIN)	+= compr_rubin.o
 jffs2-$(CONFIG_JFFS2_RTIME)	+= compr_rtime.o
 jffs2-$(CONFIG_JFFS2_ZLIB)	+= compr_zlib.o
diff -urN -x CVS mtd.core/fs/jffs2/erase.c mtd.new/fs/jffs2/erase.c
--- mtd.core/fs/jffs2/erase.c	Tue Feb  1 10:06:13 2005
+++ mtd.new/fs/jffs2/erase.c	Tue Feb  1 10:17:22 2005
@@ -310,7 +310,7 @@
 	int ret;
 	uint32_t bad_offset;
 
-	if (!jffs2_cleanmarker_oob(c)) {
+	if ((!jffs2_cleanmarker_oob(c)) && (c->cleanmarker_size > 0)) {
 		marker_ref = jffs2_alloc_raw_node_ref();
 		if (!marker_ref) {
 			printk(KERN_WARNING "Failed to allocate raw node ref for clean marker\n");
@@ -351,7 +351,7 @@
 					bad_offset += i;
 					printk(KERN_WARNING "Newly-erased block contained word 0x%lx at offset 0x%08x\n", datum, bad_offset);
 				bad: 
-					if (!jffs2_cleanmarker_oob(c))
+					if ((!jffs2_cleanmarker_oob(c)) && (c->cleanmarker_size > 0))
 						jffs2_free_raw_node_ref(marker_ref);
 					kfree(ebuf);
 				bad2:
@@ -384,6 +384,13 @@
 		jeb->first_node = jeb->last_node = NULL;
 
 		jeb->free_size = c->sector_size;
+		jeb->used_size = 0;
+		jeb->dirty_size = 0;
+		jeb->wasted_size = 0;
+	} else if (c->cleanmarker_size == 0) {
+		jeb->first_node = jeb->last_node = NULL;
+
+		jeb->free_size = c->sector_size;
 		jeb->used_size = 0;
 		jeb->dirty_size = 0;
 		jeb->wasted_size = 0;
diff -urN -x CVS mtd.core/fs/jffs2/fs.c mtd.new/fs/jffs2/fs.c
--- mtd.core/fs/jffs2/fs.c	Wed Jan 26 16:07:57 2005
+++ mtd.new/fs/jffs2/fs.c	Tue Feb  1 10:17:22 2005
@@ -455,6 +455,12 @@
 		return -EINVAL;
 	}
 #endif
+#ifndef CONFIG_JFFS2_FS_DATAFLASH
+	if (c->mtd->type == MTD_DATAFLASH) {
+		printk(KERN_ERR "jffs2: Cannot operate on DataFlash unless jffs2 DataFlash support is compiled in.\n");
+		return -EINVAL;
+	}
+#endif
 
 	c->flash_size = c->mtd->size;
 
@@ -660,6 +666,14 @@
 		if (ret)
 			return ret;
 	}
+	
+	/* and Dataflash */
+	if (jffs2_dataflash(c)) {
+		ret = jffs2_dataflash_setup(c);
+		if (ret)
+			return ret;
+	}
+	
 	return ret;
 }
 
@@ -673,4 +687,9 @@
 	if (jffs2_nor_ecc(c)) {
 		jffs2_nor_ecc_flash_cleanup(c);
 	}
+	
+	/* and DataFlash */
+	if (jffs2_dataflash(c)) {
+		jffs2_dataflash_cleanup(c);
+	}
 }
diff -urN -x CVS mtd.core/fs/jffs2/os-linux.h mtd.new/fs/jffs2/os-linux.h
--- mtd.core/fs/jffs2/os-linux.h	Tue Feb  1 10:06:13 2005
+++ mtd.new/fs/jffs2/os-linux.h	Tue Feb  1 10:18:19 2005
@@ -97,12 +97,16 @@
 #endif
 }
 
+#ifdef CONFIG_JFFS2_FS_DATAFLASH
+#define SECTOR_ADDR(x) ( ((unsigned long)(x) / (unsigned long)(c->sector_size)) * c->sector_size )
+#else
 #define SECTOR_ADDR(x) ( ((unsigned long)(x) & ~(c->sector_size-1)) )
+#endif
 
 #define jffs2_is_readonly(c) (OFNI_BS_2SFFJ(c)->s_flags & MS_RDONLY)
 #define jffs2_is_writebuffered(c) (c->wbuf != NULL)
 
-#if (!defined CONFIG_JFFS2_FS_NAND && !defined CONFIG_JFFS2_FS_NOR_ECC)
+#if (!defined CONFIG_JFFS2_FS_NAND && !defined CONFIG_JFFS2_FS_NOR_ECC && !defined CONFIG_JFFS2_FS_DATAFLASH)
 #define jffs2_can_mark_obsolete(c) (1)
 #define jffs2_cleanmarker_oob(c) (0)
 #define jffs2_write_nand_cleanmarker(c,jeb) (-EIO)
@@ -119,6 +123,7 @@
 #define jffs2_wbuf_timeout NULL
 #define jffs2_wbuf_process NULL
 #define jffs2_nor_ecc(c) (0)
+#define jffs2_dataflash(c) (0)
 #define jffs2_nor_ecc_flash_setup(c) (0)
 #define jffs2_nor_ecc_flash_cleanup(c) do {} while (0)
 
@@ -154,6 +159,15 @@
 #define jffs2_nor_ecc_flash_setup(c) (0)
 #define jffs2_nor_ecc_flash_cleanup(c) do {} while (0)
 #endif /* NOR ECC */
+#ifdef CONFIG_JFFS2_FS_DATAFLASH
+#define jffs2_dataflash(c) (c->mtd->type == MTD_DATAFLASH)
+int jffs2_dataflash_setup(struct jffs2_sb_info *c);
+void jffs2_dataflash_cleanup(struct jffs2_sb_info *c);
+#else
+#define jffs2_dataflash(c) (0)
+#define jffs2_dataflash_setup(c) (0)
+#define jffs2_dataflash_cleanup(c) do {} while (0)
+#endf /* DATAFLASH */
 #endif /* NAND */
 
 /* erase.c */
diff -urN -x CVS mtd.core/fs/jffs2/scan.c mtd.new/fs/jffs2/scan.c
--- mtd.core/fs/jffs2/scan.c	Tue Feb  1 10:07:55 2005
+++ mtd.new/fs/jffs2/scan.c	Tue Feb  1 10:18:53 2005
@@ -68,7 +68,7 @@
 static inline int min_free(struct jffs2_sb_info *c)
 {
 	uint32_t min = 2 * sizeof(struct jffs2_raw_inode);
-#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC
+#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
 	if (!jffs2_can_mark_obsolete(c) && min < c->wbuf_pagesize)
 		return c->wbuf_pagesize;
 #endif
@@ -228,7 +228,7 @@
 		c->dirty_size -= c->nextblock->dirty_size;
 		c->nextblock->dirty_size = 0;
 	}
-#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC
+#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
 	if (!jffs2_can_mark_obsolete(c) && c->nextblock && (c->nextblock->free_size & (c->wbuf_pagesize-1))) {
 		/* If we're going to start writing into a block which already 
 		   contains data, and the end of the data isn't page-aligned,
@@ -351,7 +351,10 @@
 		}
 #endif
 		D1(printk(KERN_DEBUG "Block at 0x%08x is empty (erased)\n", jeb->offset));
-		return BLK_STATE_ALLFF;	/* OK to erase if all blocks are like this */
+		if (c->cleanmarker_size == 0)
+			return BLK_STATE_CLEANMARKER;	/* don't bother with re-erase */
+		else
+			return BLK_STATE_ALLFF;	/* OK to erase if all blocks are like this */
 	}
 	if (ofs) {
 		D1(printk(KERN_DEBUG "Free space at %08x ends at %08x\n", jeb->offset,
diff -urN -x CVS mtd.core/fs/jffs2/wbuf.c mtd.new/fs/jffs2/wbuf.c
--- mtd.core/fs/jffs2/wbuf.c	Tue Feb  1 10:06:13 2005
+++ mtd.new/fs/jffs2/wbuf.c	Tue Feb  1 10:17:22 2005
@@ -435,7 +435,7 @@
 	   if we have a switch to next page, we will not have
 	   enough remaining space for this. 
 	*/
-	if (pad) {
+	if (pad && !jffs2_dataflash(c)) {
 		c->wbuf_len = PAD(c->wbuf_len);
 
 		/* Pad with JFFS2_DIRTY_BITMASK initially.  this helps out ECC'd NOR
@@ -486,7 +486,7 @@
 	spin_lock(&c->erase_completion_lock);
 
 	/* Adjust free size of the block if we padded. */
-	if (pad) {
+	if (pad && !jffs2_dataflash(c)) {
 		struct jffs2_eraseblock *jeb;
 
 		jeb = &c->blocks[c->wbuf_ofs / c->sector_size];
@@ -598,8 +598,14 @@
 	return ret;
 }
 
+#ifdef CONFIG_JFFS2_FS_DATAFLASH
+#define PAGE_DIV(x) ( ((unsigned long)(x) / (unsigned long)(c->wbuf_pagesize)) * (unsigned long)(c->wbuf_pagesize) )
+#define PAGE_MOD(x) ( (unsigned long)(x) % (unsigned long)(c->wbuf_pagesize) )
+#else
 #define PAGE_DIV(x) ( (x) & (~(c->wbuf_pagesize - 1)) )
 #define PAGE_MOD(x) ( (x) & (c->wbuf_pagesize - 1) )
+#endif
+
 int jffs2_flash_writev(struct jffs2_sb_info *c, const struct kvec *invecs, unsigned long count, loff_t to, size_t *retlen, uint32_t ino)
 {
 	struct kvec outvecs[3];
@@ -1183,6 +1189,29 @@
 	kfree(c->wbuf);
 }
 
+#ifdef CONFIG_JFFS2_FS_DATAFLASH
+int jffs2_dataflash_setup(struct jffs2_sb_info *c) {
+	c->cleanmarker_size = 0;		/* No cleanmarkers needed */
+	
+	/* Initialize write buffer */
+	init_rwsem(&c->wbuf_sem);
+	c->wbuf_pagesize = c->sector_size;
+	c->wbuf_ofs = 0xFFFFFFFF;
+
+	c->wbuf = kmalloc(c->wbuf_pagesize, GFP_KERNEL);
+	if (!c->wbuf)
+		return -ENOMEM;
+
+	printk(KERN_INFO "JFFS2 write-buffering enabled (%i)\n", c->wbuf_pagesize);
+
+	return 0;
+}
+
+void jffs2_dataflash_cleanup(struct jffs2_sb_info *c) {
+	kfree(c->wbuf);
+}
+#endif
+
 #ifdef CONFIG_JFFS2_FS_NOR_ECC
 int jffs2_nor_ecc_flash_setup(struct jffs2_sb_info *c) {
 	/* Cleanmarker is actually larger on the flashes */
diff -urN -x CVS mtd.core/include/linux/jffs2_fs_sb.h mtd.new/include/linux/jffs2_fs_sb.h
--- mtd.core/include/linux/jffs2_fs_sb.h	Wed Jan 26 16:09:40 2005
+++ mtd.new/include/linux/jffs2_fs_sb.h	Tue Feb  1 10:17:22 2005
@@ -94,7 +94,7 @@
 	   to an obsoleted node. I don't like this. Alternatives welcomed. */
 	struct semaphore erase_free_sem;
 
-#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC
+#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
 	/* Write-behind buffer for NAND flash */
 	unsigned char *wbuf;
 	uint32_t wbuf_ofs;
diff -urN -x CVS mtd.core/include/mtd/mtd-abi.h mtd.new/include/mtd/mtd-abi.h
--- mtd.core/include/mtd/mtd-abi.h	Wed Jan 26 16:09:41 2005
+++ mtd.new/include/mtd/mtd-abi.h	Tue Feb  1 10:17:22 2005
@@ -29,6 +29,7 @@
 #define MTD_NORFLASH		3
 #define MTD_NANDFLASH		4
 #define MTD_PEROM		5
+#define MTD_DATAFLASH		6
 #define MTD_OTHER		14
 #define MTD_UNKNOWN		15
 






From joern at wohnheim.fh-wedel.de  Tue Feb  1 08:03:15 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 1 Feb 2005 14:03:15 +0100
Subject: running out of space dd'ing JFFS2 image to /dev/mtdblock/0
In-Reply-To: <1107217171.783.332.camel@baythorne.infradead.org>
References: <Pine.LNX.4.61.0501311010180.3552@localhost.localdomain>
	<1107184897.7567.20.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.61.0501311038140.3730@localhost.localdomain>
	<Pine.LNX.4.58.0501311553590.17207@phoenix.infradead.org>
	<Pine.LNX.4.61.0501311109050.13936@localhost.localdomain>
	<20050131163919.GH6694@wohnheim.fh-wedel.de>
	<1107217171.783.332.camel@baythorne.infradead.org>
Message-ID: <20050201130315.GA11055@wohnheim.fh-wedel.de>

On Tue, 1 February 2005 00:19:31 +0000, David Woodhouse wrote:
> On Mon, 2005-01-31 at 17:39 +0100, J?rn Engel wrote:
> > This allows different people with different taste to specify numbers
> > in various simple formats.  If you think you can improve on this,
> > please send me a patch.
> 
> It is wrong to interpret 'k' 'M' and 'G' as anything other than 10^3,
> 10^6 or 10^9 respectively. If you have to do it to support a legacy
> interface like slram, that's vaguely acceptable. No more, though.

Misunderstanding.  Nowhere do I accept 'k' without 'i' and nowhere do
I use 10^[369].  Everything is good. :)

J?rn

-- 
Victory in war is not repetitious.
-- Sun Tzu



From rudi at unsec.nl  Tue Feb  1 10:32:23 2005
From: rudi at unsec.nl (Rudi Engelbertink)
Date: Tue, 1 Feb 2005 16:32:23 +0100
Subject: jffs2_get_inode_nodes() very very slow
Message-ID: <20050201150810.M93647@unsec.nl>

Hello,

On a 64 MiB NAND Flash I created a jffs2 file system. After several tests
especially power fail tests resulting in a lot off CRC and Data CRC errors.
This appears not to be a problem except it takes a very long time to check
the file system.
The initial check (scanning for erased blocks) is done in aproximatly 10
seconds, but after that the jffs2_get_inode_nodes check is running. 
This process takes up to 8 minutes.
During this time the file-system is inaccessible which in oure case a
watchdog decides to reboot the system, making it even worse.
It appears that the check is done with a stepsize of 16 bytes. On an 64MiB
NAND flash it does this check +/- 4 million times.

Is there a way to reduce the time to check the file-system and/or how 
can I recover from these errors.

Kind Regards,
Rudi.
-- 
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
   Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8



From lists at ku-gbr.de  Tue Feb  1 10:39:46 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 1 Feb 2005 16:39:46 +0100
Subject: I need still help with XIP, kernel boots now :)
Message-ID: <20050201153945.GA26068@synertronixx3>

Hi people!

Now I need definately have XIP to get running :/

I use 2.6.11-rc2-mm2 and put the "xipu" patches into it, which make the
"make xipuImage" available and the XIP Kernel boots now. heureka.

Due to the fakt I have no hardware partiotionable Flash devices I need
to utlize the mtd software support to cexist with an XIP Kernel
(CONFIG_MTD_XIP=y). I changed the xip.h to

#if defined(CONFIG_ARCH_SA1100) || defined(CONFIG_ARCH_PXA) || defined(CONFIG_ARCH_IMX)

#include <asm/hardware.h>
#ifdef CONFIG_ARCH_PXA
#include <asm/arch/pxa-regs.h>
#endif

#ifdef CONFIG_ARCH_IMX
#include <asm/arch/imx-regs.h>
#endif /* CONFIG_ARCH_IMX */

#endif /* CONFIG_ARCH_ */

#if defined(CONFIG_ARCH_PXA)

#define xip_irqpending()        (ICIP & ICMR)

/* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
#define xip_currtime()          (OSCR)
#define xip_elapsed_since(x)    (signed)((OSCR - (x)) / 4)

#elif defined (CONFIG_ARCH_IMX)

#define xip_irqpending()        (( IMX_INTENABLEH  & IMX_NIPNDH ) || ( IMX_INTENABLEL & IMX_NIPNDL ))

/* we hopefully too :p */
#define xip_currtime()          (IMX_TCN(1))
#define xip_elapsed_since(x)    (signed)((IMX_TCN(1) - (x)) / 4)

#elif

So, when I read datasheet correct, pxa's ICIP corresponds to i.MX's NIPNDx 
and pxa's ICMR to i.MX's INTENABLEx.

When I boot the xipuImage with / mounted ro it boots most often to the
loginprompt, I can login and do stuff. But when / is mounted rw the
system brakes. this happens after 

Probing scb9328_flash at physical address 0x10000000 (16-bit buswidth)
scb9328_flash: Found 1 x16 devices at 0x0 in 16-bit bank              
Intel/Sharp Extended Query Table at 0x0031             
cfi_cmdset_0001: write suspend disabled    
Using buffer write method              
cfi_cmdset_0001: Erase suspend on write enabled
5 cmdlinepart partitions found on MTD device scb9328_flash
Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
0x00040000-0x00140000 : "kernel"    
0x00140000-0x00540000 : "root"  
0x00540000-0x00940000 : "fs"
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)       
TCP: Hash tables configured (established 1024 bind 1024)

Its also possible to mount / ro and mount rw a fourth partition after
logging in, kernel freezes then.

So I have an error in my setup. Is xip.h the only place, which should be
adapted from pxa/sa1100 to i.MX?

When compiling the cmopiler warns:

  CC      drivers/mtd/chips/cfi_probe.o
/tmp/ccnLmXio.s: Assembler messages:
/tmp/ccnLmXio.s:3: Warning: ignoring changed section attributes for .data
  CC      drivers/mtd/chips/cfi_util.o
/tmp/ccjtGCIO.s: Assembler messages:
/tmp/ccjtGCIO.s:13: Warning: ignoring changed section attributes for .data
  CC      drivers/mtd/chips/cfi_cmdset_0001.o

Is this fatal and needs to be adjusted in platform stuff or arch stuff?

Regards, Konsti


-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From dedekind at infradead.org  Tue Feb  1 11:03:31 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 1 Feb 2005 16:03:31 +0000 (GMT)
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <20050201150810.M93647@unsec.nl>
References: <20050201150810.M93647@unsec.nl>
Message-ID: <Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>

On Tue, 1 Feb 2005, Rudi Engelbertink wrote:

> Hello,
> 
> On a 64 MiB NAND Flash I created a jffs2 file system. After several tests
> especially power fail tests resulting in a lot off CRC and Data CRC errors.
How do you do your power-fail tests?

> This appears not to be a problem except it takes a very long time to check
> the file system.
> The initial check (scanning for erased blocks) is done in aproximatly 10
> seconds, but after that the jffs2_get_inode_nodes check is running. 
> This process takes up to 8 minutes.
Do you mean this happens every time or in case of "powerfails"?

> During this time the file-system is inaccessible which in oure case a
> watchdog decides to reboot the system, making it even worse.
> It appears that the check is done with a stepsize of 16 bytes. On an 64MiB
> NAND flash it does this check +/- 4 million times.
That's strange. JFFS2 should share processor's cycles.

> 
> Is there a way to reduce the time to check the file-system and/or how 
> can I recover from these errors.
> 
> Kind Regards,
> Rudi.
> -- 
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety.
>    Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
> GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From tglx at linutronix.de  Tue Feb  1 11:10:31 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 01 Feb 2005 17:10:31 +0100
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <20050201150810.M93647@unsec.nl>
References: <20050201150810.M93647@unsec.nl>
Message-ID: <1107274232.21196.433.camel@tglx.tec.linutronix.de>

On Tue, 2005-02-01 at 16:32 +0100, Rudi Engelbertink wrote:
> Hello,
> 
> On a 64 MiB NAND Flash I created a jffs2 file system. After several tests
> especially power fail tests resulting in a lot off CRC and Data CRC errors.
> This appears not to be a problem except it takes a very long time to check
> the file system.
> The initial check (scanning for erased blocks) is done in aproximatly 10
> seconds, but after that the jffs2_get_inode_nodes check is running. 
> This process takes up to 8 minutes.
> During this time the file-system is inaccessible which in oure case a
> watchdog decides to reboot the system, making it even worse.
> It appears that the check is done with a stepsize of 16 bytes. On an 64MiB
> NAND flash it does this check +/- 4 million times.

Hmm, which kernel version ? 

Can you switch on JFFS2 debugging (debuglevel 1), log the output on a
serial line and send me the log, please ? 

tglx





From nico at cam.org  Tue Feb  1 11:38:23 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 1 Feb 2005 11:38:23 -0500 (EST)
Subject: I need still help with XIP, kernel boots now :)
In-Reply-To: <20050201153945.GA26068@synertronixx3>
References: <20050201153945.GA26068@synertronixx3>
Message-ID: <Pine.LNX.4.61.0502011137020.31479@localhost.localdomain>

On Tue, 1 Feb 2005, Konstantin Kletschke wrote:

> Hi people!
> 
> Now I need definately have XIP to get running :/
> 
> I use 2.6.11-rc2-mm2 and put the "xipu" patches into it, which make the
> "make xipuImage" available and the XIP Kernel boots now. heureka.
> 
> Due to the fakt I have no hardware partiotionable Flash devices I need
> to utlize the mtd software support to cexist with an XIP Kernel
> (CONFIG_MTD_XIP=y).

Try that option with a non XIP kernel at first, then test writing to 
flash etc.  See if that works first.


Nicolas



From tglx at linutronix.de  Tue Feb  1 11:49:21 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 01 Feb 2005 17:49:21 +0100
Subject: JFFS3 memory consumption
In-Reply-To: <Pine.LNX.4.58.0501311804550.17207@phoenix.infradead.org>
References: <Pine.LNX.4.58.0501260841380.3222@phoenix.infradead.org>
	<1106865326.783.146.camel@baythorne.infradead.org>
	<1106871577.21196.155.camel@tglx.tec.linutronix.de>
	<1106872400.6480.201.camel@localhost.localdomain>
	<1106873065.21196.168.camel@tglx.tec.linutronix.de>
	<Pine.LNX.4.58.0501280817330.11160@phoenix.infradead.org>
	<1106903029.21196.216.camel@tglx.tec.linutronix.de>
	<Pine.LNX.4.58.0501280914580.11160@phoenix.infradead.org>
	<Pine.LNX.4.58.0501281855370.11160@phoenix.infradead.org>
	<1107111514.18794.37.camel@sauron.oktetlabs.ru>
	<6934efce05013108463a4d42e4@mail.gmail.com>
	<Pine.LNX.4.58.0501311804550.17207@phoenix.infradead.org>
Message-ID: <1107276561.21196.457.camel@tglx.tec.linutronix.de>

On Mon, 2005-01-31 at 18:05 +0000, Artem B. Bityuckiy wrote:
> Will try to express what I think.
> 
> If the inode's nodes are scattered over many blocks, this will quite slow;
> 
> But we may do the following optimizations:
> 
> A. Have special GC strategy to put (or try to put) nodes belonging to the 
> same inode to the same blocks. Thus we may keep the number of blocks where 
> the inode's nodes are scattered relatively small.

This might turn out to be a GC nightmare. Every update to a file might
result in shuffling tons of nodes around or at least trying to do so.

Keep it simple.

> 2. ICP... The alternative is using ICP. ICP contains the ICP entries in 
> its body. These entries describe all the nodes of our inode. Thus, for 
> each inode, we may keep in-core only the inode's ICP offset. And when we 
> need to build the inode in the iget() call, we need just to read the 
> corresponding ICP, and that's all.
> 
> The problem here is that ICP contains the physical offsets of nodes. But 
> the GC works and moves nodes brom one block to another, changing their 
> offsets. And we need to often update ICPs - even for static RO files.

Not only GC makes this necessary, every write to a file too. 

> Thoughts?

I'm not sure which of the mechanisms will provide us more horror. My
guess is ICP. The summary method is definitely less performant, but I
think therefor less complicated to handle. So we trade performance for
simplicity, which makes more sense for me than the other way round.

tglx





From lists at ku-gbr.de  Tue Feb  1 12:21:00 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 1 Feb 2005 18:21:00 +0100
Subject: I need still help with XIP, kernel boots now :)
In-Reply-To: <Pine.LNX.4.61.0502011137020.31479@localhost.localdomain>
References: <20050201153945.GA26068@synertronixx3>
	<Pine.LNX.4.61.0502011137020.31479@localhost.localdomain>
Message-ID: <20050201172059.GB26068@synertronixx3>

Am 2005-02-01 11:38 -0500 schrieb Nicolas Pitre:
> On Tue, 1 Feb 2005, Konstantin Kletschke wrote:
> 
> > Hi people!
> > 
> > Now I need definately have XIP to get running :/
> > 
> > I use 2.6.11-rc2-mm2 and put the "xipu" patches into it, which make the
> > "make xipuImage" available and the XIP Kernel boots now. heureka.
> > 
> > Due to the fakt I have no hardware partiotionable Flash devices I need
> > to utlize the mtd software support to cexist with an XIP Kernel
> > (CONFIG_MTD_XIP=y).
> 
> Try that option with a non XIP kernel at first, then test writing to 
> flash etc.  See if that works first.

*ourks* This guves a nice Oops.

Internal error: Oops: 0 [#1] 
CPU: 0            
pc : [<c001fdd8>]    lr : [<e5933000>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
sp : c01af98c  ip : c01afa00  fp : c01af99c          
r10: c01f69f8  r9 : 00000023  r8 : e0000011
r7 : c0160038  r6 : c01afa00  r5 : e5933000  r4 : 00000003
r3 : 00000000  r2 : e0000011  r1 : 00100000  r0 : e0000011
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  Segment kernel
Control: C000717F  Table: 08004000  DAC: 00000017          
Stack: (0xc01af98c to 0xc01b0000)                 
f980:                            00000000 c01af9d8 c01af9a0 c0020400 c001fd94 
f9a0: c01af9ac c01af9a4 c01af9a4 c0171384 00000023 c01afa34 c01573f0 e0000011 
f9c0: c01afa00 60000093 c01f69f8 c01af9fc c01af9dc c001f120 c0020288 ffffffff 
f9e0: c01afa34 00000002 c01633c8 00275680 c01afb24 c01afa00 c001827c c001f0f4 
fa00: 00000001 00000002 00000080 e0000011 00000002 00000001 00000002 c01633c8 
fa20: 00275680 c01f69c0 c01f69f8 c01afb24 00000000 c01afa48 c015ffd0 c016003c 
fa40: 60000093 ffffffff c01d01c9 00000009 c00db9d0 00000006 00000021 00000080 
fa60: c01c1b00 00000200 c01f69f8 c000a7d0 c00b1ff0 0000001f 0000007f 00000007 
fa80: 00000000 c01afad0 c01679d8 c01679cc c01afab0 c01afaa0 c000a3e4 c0051e84 
faa0: 00000000 c01aff64 c01afab4 c000abd0 c000a3d4 c01366d4 c01b3804 c01afac0 
fac0: 00000005 c01afb00 00000001 00000080 00000080 00000000 c01a9d60 c0029f90 
fae0: 00000000 00000000 00000000 c01a9d60 c0029f90 00000000 00000000 00000002 
fb00: 00000001 c01633c8 00000002 0000000c c01f69f8 00275680 c01afc50 c01afb28 
fb20: c0161bf8 c015ff88 c01afb34 00003d39 c004d244 00000080 00000006 00000000 
fb40: 00000000 00000080 c01f69c0 c01afcf4 002756a0 00000001 00000000 000000d0 
fb60: c01a9d60 c01afb84 c01a9d60 c01afbac c00db9d0 c0029df4 c0028c44 00000080 
fb80: c01f69c0 000000d0 000000d0 00000000 0000003b 00003d39 00000005 00000005 
fba0: c01afbc4 c01afbb0 c01afba8 c01afba8 c0171384 00000000 00000080 00000080 
fbc0: 00000080 00000080 00000080 000000e8 000000e8 c01633c8 c01f69f8 c01f69c0 
fbe0: 002756a0 00000030 00000080 00000030 00000070 00000070 00000080 c01afc44 
fc00: c01afc0c c00dc4c4 c002a034 c01a9d60 c0029f90 00000000 00000000 002756a0 
fc20: c01f69f8 00000000 0000000c c01f69f8 00000000 002756a0 00000000 c01f69c0 
fc40: 0000000c c01afc90 c01afc54 c00dceb0 c0160f5c 0000000c c01f69c0 00000040 
fc60: c01633c8 c0253000 00000000 000356a0 00000000 0000000c c01afce0 c01afce8 
fc80: c01afce8 c01afcc8 c01afc94 c00d7d48 c00dcd78 c01afce0 c01afce8 c01afcd4 
fca0: c01afcac 000356a0 00000000 c01afce0 c0264030 c0269a00 c0276694 c01afd1c 
fcc0: c01afccc c009c044 c00d7c9c c01afce0 c01afce8 c00dc780 00400000 c0269a00 
fce0: 00000000 c01ac002 c0021985 000000f5 3d39d2e2 c027561c c027561c c01afd44 
fd00: c0269a00 c01afd48 c0269ac4 c0269aac c01afd40 c01afd20 c00a2a5c c009bad4 
fd20: c01afd48 c027561c c0269a00 00000000 c01afd48 c01afd6c c01afd44 c00a27e8 
fd40: c00a2a3c 00000000 00000025 c0269a94 c0269a9c c0269aa4 c0269ab4 c0269abc 
fd60: c01afdb4 c01afd70 c00a2df4 c00a2618 c0269af8 c0269a00 c0269adc c0269ad4 
fd80: c0269acc c0269aec c00b1ff0 c025a800 c0269a00 00000000 c0269800 c025a800 
fda0: 00000000 00000000 c01afdd8 c01afdb8 c00a4b90 c00a2ba8 c0269800 c0269a00 
fdc0: 00008000 00000000 c025a800 c01afdfc c01afddc c00a51e4 c00a4a64 ffffffea 
fde0: 00000003 c0270000 00008000 c015beb8 c01afe6c c01afe00 c00a5430 c00a515c 
fe00: c025a800 c007a15c c025b5dc c01a7600 c01afecc c01afecc c01afe64 00000001 
fe20: 00000001 00000000 0000000a c01a72a0 c0261680 c0270000 00008000 00000000 
fe40: c01afe6c c01afe50 c01a72a0 fffffff4 c015beb8 c0270000 00008000 00000000 
fe60: c01afe94 c01afe70 c0068ed4 c00a52ac ffffffff c0270000 00000000 00008000 
fe80: c01afecc 00000000 c01afebc c01afe98 c007e600 c0068e88 00008000 00000000 
fea0: c026f000 00000000 c0270000 c01afecc c01aff34 c01afec0 c007eca0 c007e58c 
fec0: c0270000 00000000 c026e000 c01b2554 c01a7600 c01afee0 00000000 c0138cb8 
fee0: 00000001 00000001 00000000 00000000 00000000 c01aff10 c01aff04 c004dff8 
ff00: 00001000 c01aff34 c01aff14 00000000 00000000 c0138cb8 c026f000 00008000 
ff20: 00000000 00000000 c01aff68 c01aff38 c007f0c0 c007eb60 00000000 00000000 
ff40: c0270000 c026e000 c01ca000 c01ca000 00008000 c0138cb8 c01732b0 c01aff80 
ff60: c01aff6c c0008f68 c007f02c 00000000 c01ca000 c01affc4 c01aff84 c000904c 
ff80: c0008f48 c003d8c4 01f00003 c0138cb8 00000000 00000000 00000000 00000000 
ffa0: c01affc4 c0016a18 c00169c8 00000000 00000000 00000000 c01affe0 c01affc8 
ffc0: c0009210 c0009004 00000000 c0138b70 00000000 c01afff4 c01affe4 c00180c4 
ffe0: c0009194 00000000 00000000 c01afff8 c002f820 c0018084 e1530001 9a000007 
Backtrace:                                                                   
Function entered at [<c001fd84>] from [<c0020400>]
 r4 = 00000000                                    
Function entered at [<c0020278>] from [<c001f120>]
Function entered at [<c001f0e4>] from [<c001827c>]
 r8 = 00275680  r7 = C01633C8  r6 = 00000002  r5 = C01AFA34
 r4 = FFFFFFFF                                             
Function entered at [<c015ff78>] from [<c0161bf8>]
Function entered at [<c0160f4c>] from [<c00dceb0>]
Function entered at [<c00dcd68>] from [<c00d7d48>]
Function entered at [<c00d7c8c>] from [<c009c044>]
Function entered at [<c009bac4>] from [<c00a2a5c>]
Function entered at [<c00a2a2c>] from [<c00a27e8>]
 r8 = C01AFD48  r7 = 00000000  r6 = C0269A00  r5 = C027561C
 r4 = C01AFD48                                             
Function entered at [<c00a2608>] from [<c00a2df4>]
 r8 = C0269ABC  r7 = C0269AB4  r6 = C0269AA4  r5 = C0269A9C
 r4 = C0269A94                                             
Function entered at [<c00a2b98>] from [<c00a4b90>]
Function entered at [<c00a4a54>] from [<c00a51e4>]
 r8 = C025A800  r7 = 00000000  r6 = 00008000  r5 = C0269A00
 r4 = C0269800                                             
Function entered at [<c00a514c>] from [<c00a5430>]
 r8 = C015BEB8  r7 = 00008000  r6 = C0270000  r5 = 00000003
 r4 = FFFFFFEA                                             
Function entered at [<c00a529c>] from [<c0068ed4>]
Function entered at [<c0068e78>] from [<c007e600>]
Function entered at [<c007e57c>] from [<c007eca0>]
Function entered at [<c007eb50>] from [<c007f0c0>]
Function entered at [<c007f01c>] from [<c0008f68>]
 r8 = C01732B0  r7 = C0138CB8  r6 = 00008000  r5 = C01CA000
 r4 = C01CA000                                             
Function entered at [<c0008f38>] from [<c000904c>]
 r4 = C01CA000                                    
Function entered at [<c0008ff4>] from [<c0009210>]
 r8 = 00000000  r7 = 00000000  r6 = 00000000  r5 = C00169C8
 r4 = C0016A18                                             
Function entered at [<c0009184>] from [<c00180c4>]
 r5 = 00000000  r4 = C0138B70                     
Function entered at [<c0018074>] from [<c002f820>]
 r4 = 00000000                                    
Code: e21e1601 0a000008 e1a02000 e3a03000 (e4d21001)


>>EIP; c001fdd8 <do_alignment_ldrstr+54/108>   <=====

>>r7; c0160038 <xip_udelay+c0/950>

Trace; c001fd84 <do_alignment_ldrstr+0/108>
Trace; c0020400 <do_alignment+188/2c8>
Trace; c0020278 <do_alignment+0/2c8>
Trace; c001f120 <do_DataAbort+3c/a0>
Trace; c001f0e4 <do_DataAbort+0/a0>
Trace; c001827c <__dabt_svc+3c/60>

>>r7; c01633c8 <scb9328_map+0/30>

Trace; c015ff78 <xip_udelay+0/950>
Trace; c0161bf8 <do_write_buffer+cac/10f8>
Trace; c0160f4c <do_write_buffer+0/10f8>
Trace; c00dceb0 <cfi_intelext_write_buffers+148/1a4>
Trace; c00dcd68 <cfi_intelext_write_buffers+0/1a4>
Trace; c00d7d48 <part_write+bc/f8>
Trace; c00d7c8c <part_write+0/f8>
Trace; c009c044 <jffs2_mark_node_obsolete+580/76c>
Trace; c009bac4 <jffs2_mark_node_obsolete+0/76c>
Trace; c00a2a5c <jffs2_build_remove_unlinked_inode+30/ec>
Trace; c00a2a2c <jffs2_build_remove_unlinked_inode+0/ec>
Trace; c00a27e8 <jffs2_build_filesystem+1e0/424>
Trace; c00a2608 <jffs2_build_filesystem+0/424>
Trace; c00a2df4 <jffs2_do_mount_fs+25c/2bc>
Trace; c00a2b98 <jffs2_do_mount_fs+0/2bc>
Trace; c00a4b90 <jffs2_do_fill_super+13c/25c>
Trace; c00a4a54 <jffs2_do_fill_super+0/25c>
Trace; c00a51e4 <jffs2_get_sb_mtd+98/f8>
Trace; c00a514c <jffs2_get_sb_mtd+0/f8>
Trace; c00a5430 <jffs2_get_sb+194/1d0>

>>r8; c015beb8 <jffs2_fs_type+0/20>

Trace; c00a529c <jffs2_get_sb+0/1d0>
Trace; c0068ed4 <do_kern_mount+5c/f4>
Trace; c0068e78 <do_kern_mount+0/f4>
Trace; c007e600 <do_new_mount+84/b8>
Trace; c007e57c <do_new_mount+0/b8>
Trace; c007eca0 <do_mount+150/16c>
Trace; c007eb50 <do_mount+0/16c>
Trace; c007f0c0 <sys_mount+a4/e8>
Trace; c007f01c <sys_mount+0/e8>
Trace; c0008f68 <do_mount_root+30/bc>

>>r8; c01732b0 <names_cachep+0/4>
>>r7; c0138cb8 <__func__.1+33c/ed04>

Trace; c0008f38 <do_mount_root+0/bc>
Trace; c000904c <mount_block_root+58/124>
Trace; c0008ff4 <mount_block_root+0/124>
Trace; c0009210 <prepare_namespace+8c/d0>

>>r5; c00169c8 <root_device_name+0/4>
>>r4; c0016a18 <root_delay+0/4>

Trace; c0009184 <prepare_namespace+0/d0>
Trace; c00180c4 <init+50/10c>

>>r4; c0138b70 <__func__.1+1f4/ed04>

Trace; c0018074 <init+0/10c>
Trace; c002f820 <do_exit+0/328>

Code;  c001fdc8 <do_alignment_ldrstr+44/108>
00000000 <_EIP>:
Code;  c001fdc8 <do_alignment_ldrstr+44/108>
   0:   01 16                     add    %edx,(%esi)
Code;  c001fdca <do_alignment_ldrstr+46/108>
   2:   1e                        push   %ds
Code;  c001fdcb <do_alignment_ldrstr+47/108>
   3:   e2 08                     loop   d <_EIP+0xd>
Code;  c001fdcd <do_alignment_ldrstr+49/108>
   5:   00 00                     add    %al,(%eax)
Code;  c001fdcf <do_alignment_ldrstr+4b/108>
   7:   0a 00                     or     (%eax),%al
Code;  c001fdd1 <do_alignment_ldrstr+4d/108>
   9:   20 a0 e1 00 30 a0         and    %ah,0xa03000e1(%eax)
Code;  c001fdd7 <do_alignment_ldrstr+53/108>   <=====
   f:   e3 01                     jecxz  12 <_EIP+0x12>   <=====
Code;  c001fdd9 <do_alignment_ldrstr+55/108>
  11:   10 d2                     adc    %dl,%dl
Code;  c001fddb <do_alignment_ldrstr+57/108>
  13:   e4 00                     in     $0x0,%al


If xip_udelay is to blame I suspect my xip.h is broken, 
otherwise I have no clue.

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From nico at cam.org  Tue Feb  1 12:30:19 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 1 Feb 2005 12:30:19 -0500 (EST)
Subject: I need still help with XIP, kernel boots now :)
In-Reply-To: <20050201172059.GB26068@synertronixx3>
References: <20050201153945.GA26068@synertronixx3>
	<Pine.LNX.4.61.0502011137020.31479@localhost.localdomain>
	<20050201172059.GB26068@synertronixx3>
Message-ID: <Pine.LNX.4.61.0502011229310.31479@localhost.localdomain>

On Tue, 1 Feb 2005, Konstantin Kletschke wrote:

> Am 2005-02-01 11:38 -0500 schrieb Nicolas Pitre:
> > On Tue, 1 Feb 2005, Konstantin Kletschke wrote:
> > 
> > > Hi people!
> > > 
> > > Now I need definately have XIP to get running :/
> > > 
> > > I use 2.6.11-rc2-mm2 and put the "xipu" patches into it, which make the
> > > "make xipuImage" available and the XIP Kernel boots now. heureka.
> > > 
> > > Due to the fakt I have no hardware partiotionable Flash devices I need
> > > to utlize the mtd software support to cexist with an XIP Kernel
> > > (CONFIG_MTD_XIP=y).
> > 
> > Try that option with a non XIP kernel at first, then test writing to 
> > flash etc.  See if that works first.
> 
> *ourks* This guves a nice Oops.
> 
> Internal error: Oops: 0 [#1] 
> CPU: 0            
> pc : [<c001fdd8>]    lr : [<e5933000>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
[...]

What kernel version is this?


Nicolas



From lists at ku-gbr.de  Tue Feb  1 12:44:20 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 1 Feb 2005 18:44:20 +0100
Subject: I need still help with XIP, kernel boots now :)
In-Reply-To: <Pine.LNX.4.61.0502011229310.31479@localhost.localdomain>
References: <20050201153945.GA26068@synertronixx3>
	<Pine.LNX.4.61.0502011137020.31479@localhost.localdomain>
	<20050201172059.GB26068@synertronixx3>
	<Pine.LNX.4.61.0502011229310.31479@localhost.localdomain>
Message-ID: <20050201174419.GA32581@synertronixx3>

Regarding my mail before:

I changed IMX_TCN(1) to IMX_TCN(0) because this is the system timer,
damn! Oops is away then and booting an non xip uImage with
CONFIG_XIP_MTD=y works very well! I could copy a file onto the extra
partition mounted rw. 

Running this xipuImage (/ mounted ro) allowed me to mount 
an extra jffs2 partition and ls on it, but writing on it freezes the
system.

Am 2005-02-01 12:30 -0500 schrieb Nicolas Pitre:

> What kernel version is this?

2.6.11-rc2-mm2 with my board specific i.MX addons.

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From jaredeh at gmail.com  Tue Feb  1 13:14:23 2005
From: jaredeh at gmail.com (Jared Hulbert)
Date: Tue, 1 Feb 2005 10:14:23 -0800
Subject: I need still help with XIP, kernel boots now :)
In-Reply-To: <20050201174419.GA32581@synertronixx3>
References: <20050201153945.GA26068@synertronixx3>
	<Pine.LNX.4.61.0502011137020.31479@localhost.localdomain>
	<20050201172059.GB26068@synertronixx3>
	<Pine.LNX.4.61.0502011229310.31479@localhost.localdomain>
	<20050201174419.GA32581@synertronixx3>
Message-ID: <6934efce0502011014a75e21b@mail.gmail.com>

> I changed IMX_TCN(1) to IMX_TCN(0) because this is the system timer,
> damn! Oops is away then and booting an non xip uImage with
> CONFIG_XIP_MTD=y works very well! I could copy a file onto the extra
> partition mounted rw.
> 
> Running this xipuImage (/ mounted ro) allowed me to mount
> an extra jffs2 partition and ls on it, but writing on it freezes the
> system.

JTAG/BDM debug time?  I've had good luck with the Abatron BDI2000. ;)

If you look at cfi_cmdset_0001 you'll find some function use __xipram.
 This is intended to place them in RAM so when the flash goes into
status mode you can run these functions.  Make sure they are actually
in RAM.  Check your System.map.



From jdub at us.ibm.com  Tue Feb  1 17:40:36 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Tue, 01 Feb 2005 16:40:36 -0600
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
In-Reply-To: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
References: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
Message-ID: <1107297636.8235.3.camel@windu.rchland.ibm.com>

On Tue, 2005-02-01 at 11:00 +0200, Andrew Victor wrote:
> 
> Configuration (Config.in and Kconfig) and Makefiles updated.

Cool.

> 
> Padding nodes are only skipped for DataFlash devices - no longer breaks
> the NOR ECC flash support.

Looks better.  Thanks!

josh




From lists at ku-gbr.de  Wed Feb  2 03:54:41 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Wed, 2 Feb 2005 09:54:41 +0100
Subject: I need still help with XIP, kernel boots now :)
Message-ID: <20050202085441.GB3063@synertronixx3>

Hi!

Ok, seems to be it is debug time :)

I have a BDI2000 here, but I never used it to debug a running kernel, I
should learn that now :/

I am trying to look ATM if the __xipram using functions went into .data
but I doubt that, since the compiler issues a warning at just this
point, so I asked in my initial mail if thats not only a warning for me
:)

In System.map there are 

bf112a8c t xip_disable
c0014e14 d xip_enable
c0014f78 d xip_udelay

I did an arm-linux-objdump -ad and searched for the addresses, but only
I find the xip_disable address:

bf112a8c <xip_disable>:
bf112a8c:	e1a0c00d 	mov	ip, sp

not the address of xip_enable and xip_udelay...

How can that be?

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From rudi at unsec.nl  Wed Feb  2 04:05:15 2005
From: rudi at unsec.nl (Rudi Engelbertink)
Date: Wed, 2 Feb 2005 10:05:15 +0100
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>
References: <20050201150810.M93647@unsec.nl>
	<Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>
Message-ID: <20050202085600.M52308@unsec.nl>

On Tue, 1 Feb 2005 16:03:31 +0000 (GMT), Artem B. Bityuckiy wrote
> On Tue, 1 Feb 2005, Rudi Engelbertink wrote:
> 
> > Hello,
> > 
> > On a 64 MiB NAND Flash I created a jffs2 file system. After several tests
> > especially power fail tests resulting in a lot off CRC and Data CRC errors.
> How do you do your power-fail tests?
The powerfail tests are done by:
A. a clock. Just turn off and on the power every 15 minutes and start the
an application which logs 2 40-60 byte events every second.
B. an internal (hardware) watchdog which reboots the system when the
'application' appears to be dead for 10 minutes.

> 
> > This appears not to be a problem except it takes a very long time to check
> > the file system.
> > The initial check (scanning for erased blocks) is done in aproximatly 10
> > seconds, but after that the jffs2_get_inode_nodes check is running. 
> > This process takes up to 8 minutes.
> Do you mean this happens every time or in case of "powerfails"?
Yes it happens every time the system reboots or when the (nand) filesystem
is mounted.
> 
> > During this time the file-system is inaccessible which in oure case a
> > watchdog decides to reboot the system, making it even worse.
> > It appears that the check is done with a stepsize of 16 bytes. On an 64MiB
> > NAND flash it does this check +/- 4 million times.
> That's strange. JFFS2 should share processor's cycles.
Yes, the root is accessable but the directory where the logging is stored,
is unavailable for several minutes.
> 
> > 
> > Is there a way to reduce the time to check the file-system and/or how 
> > can I recover from these errors.
> > 
> > Kind Regards,
> > Rudi.
> > -- 
> > They that can give up essential liberty to obtain a little temporary
> > safety deserve neither liberty nor safety.
> >    Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
> > GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
> 
> --
> Best Regards,
> Artem B. Bityuckiy,
> St.-Petersburg, Russia.


RGDS Rudi.

-- 
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
   Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8




From tglx at linutronix.de  Wed Feb  2 05:26:51 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 02 Feb 2005 11:26:51 +0100
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <20050202085600.M52308@unsec.nl>
References: <20050201150810.M93647@unsec.nl>
	<Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>
	<20050202085600.M52308@unsec.nl>
Message-ID: <1107340012.21196.507.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-02 at 10:05 +0100, Rudi Engelbertink wrote:
> The powerfail tests are done by:
> A. a clock. Just turn off and on the power every 15 minutes and start the
> an application which logs 2 40-60 byte events every second.
> ...
> Yes, the root is accessable but the directory where the logging is stored,
> is unavailable for several minutes.

You hit the worst case for JFFS2.

Your event logging creates tons of small nodes for your logfiles.
Actually are about 96000 very small nodes on the chip, so the mount time
is not surprising. This also will use a quite big amount of memory.

We have no real cure for this at the moment. We have this scenario in
our design list for JFFS3. I remember that somebody else came up with
this issue sometime ago. IIRC changing the log method did help a bit.

while true
do
	log_event
	let cnt=cnt+1
	if [ $cnt -ge $LIMIT ]
	then
		closelog
		cat log.small >>log.big
		rm log.small
	fi
done

This converts the small nodes to bigger nodes when the data are appended
to log.big. I guess garbage collection should kick in quite fast and
clean up the small nodes. It might not totally go away, but it should be
much better than now. This will also give you more capacity on your
partition as the small nodes consist mostly of node overhead. 

You may also try YAFFS for the logging partition. It should deal with
this situation a bit better.

tglx





From dwmw2 at infradead.org  Wed Feb  2 05:35:52 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 02 Feb 2005 10:35:52 +0000
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <1107340012.21196.507.camel@tglx.tec.linutronix.de>
References: <20050201150810.M93647@unsec.nl>
	<Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>
	<20050202085600.M52308@unsec.nl>
	<1107340012.21196.507.camel@tglx.tec.linutronix.de>
Message-ID: <1107340552.12063.8.camel@baythorne.infradead.org>

On Wed, 2005-02-02 at 11:26 +0100, Thomas Gleixner wrote:
> This converts the small nodes to bigger nodes when the data are
> appended to log.big. I guess garbage collection should kick in quite
> fast and clean up the small nodes. It might not totally go away, but
> it should be much better than now. This will also give you more
> capacity on your partition as the small nodes consist mostly of node
> overhead. 

We could possibly do this for ourselves quite easily. When writing to a
page which already has more than N fragments, obsolete them all and
write the whole page out again.

Or maybe, when writing the _last_ byte in a page which already has N
fragments, rewrite the whole page?

-- 
dwmw2





From jonas.holmberg at axis.com  Wed Feb  2 06:07:16 2005
From: jonas.holmberg at axis.com (Jonas Holmberg)
Date: Wed, 2 Feb 2005 12:07:16 +0100
Subject: Device ID collision in amd_flash.c
Message-ID: <20050202110715.GH27015@axis.com>

The (obsolete) AMD NOR-flash driver has an "probe-table-entry" for 
AM29BDS643D that happens to match AM29DL640G as well, even though they  
have different block/sector-layouts.

I think the problem is that AMD is assigning device-IDs of more than 
16-bits.  Anyhow, both AM29BDS643D and AM29DL640G supports CFI, so I 
would like to remove support for them in amd_flash.c (patch below) to 
avoid problems.

OK to commit?

/Jonas

PS. Would this patch ever find it's way into Linux 2.4 or just Linux 
2.6?



RCS file: /home/cvs/mtd/drivers/mtd/chips/amd_flash.c,v
retrieving revision 1.26
diff -u -r1.26 amd_flash.c
--- amd_flash.c 20 Nov 2004 12:49:04 -0000      1.26
+++ amd_flash.c 2 Feb 2005 11:03:07 -0000
@@ -67,7 +67,6 @@
 #define AM29LV160DT    0x22C4
 #define AM29LV160DB    0x2249
 #define AM29BDS323D     0x22D1
-#define AM29BDS643D    0x227E
 
 /* Atmel */
 #define AT49xV16x      0x00C0
@@ -618,17 +617,6 @@
                        { .offset = 0x3f0000, .erasesize = 0x02000, .numblocks =  8 },
                }
        }, {
-               .mfr_id = MANUFACTURER_AMD,
-               .dev_id = AM29BDS643D,
-               .name = "AMD AM29BDS643D",
-               .size = 0x00800000,
-               .numeraseregions = 3,
-               .regions = {
-                       { .offset = 0x000000, .erasesize = 0x10000, .numblocks = 96 },
-                       { .offset = 0x600000, .erasesize = 0x10000, .numblocks = 31 },
-                       { .offset = 0x7f0000, .erasesize = 0x02000, .numblocks =  8 },
-               }
-       }, {
                .mfr_id = MANUFACTURER_ATMEL,
                .dev_id = AT49xV16x,
                .name = "Atmel AT49xV16x",




From dedekind at infradead.org  Wed Feb  2 06:23:38 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 2 Feb 2005 11:23:38 +0000 (GMT)
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <1107340552.12063.8.camel@baythorne.infradead.org>
References: <20050201150810.M93647@unsec.nl>
	<Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>
	<20050202085600.M52308@unsec.nl>
	<1107340012.21196.507.camel@tglx.tec.linutronix.de>
	<1107340552.12063.8.camel@baythorne.infradead.org>
Message-ID: <Pine.LNX.4.58.0502021122260.29798@phoenix.infradead.org>

On Wed, 2 Feb 2005, David Woodhouse wrote:

> On Wed, 2005-02-02 at 11:26 +0100, Thomas Gleixner wrote:
> > This converts the small nodes to bigger nodes when the data are
> > appended to log.big. I guess garbage collection should kick in quite
> > fast and clean up the small nodes. It might not totally go away, but
> > it should be much better than now. This will also give you more
> > capacity on your partition as the small nodes consist mostly of node
> > overhead. 
> 
> We could possibly do this for ourselves quite easily. When writing to a
> page which already has more than N fragments, obsolete them all and
> write the whole page out again.
IMO, perfectly good idea! I think the reasonable thrashhold is about 3-6 
fragments.

> 
> Or maybe, when writing the _last_ byte in a page which already has N
> fragments, rewrite the whole page?
> 
> -- 
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From joern at wohnheim.fh-wedel.de  Wed Feb  2 07:21:20 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Wed, 2 Feb 2005 13:21:20 +0100
Subject: JFFS2-on-DataFlash : 1 - Core changes
In-Reply-To: <1107247455.22636.36.camel@fuzzie.sanpeople.com>
References: <1107247455.22636.36.camel@fuzzie.sanpeople.com>
Message-ID: <20050202122120.GA23156@wohnheim.fh-wedel.de>

On Tue, 1 February 2005 10:44:15 +0200, Andrew Victor wrote:
> 
> Based on the previous comments, the patch has been split up.
> 
> The changes included in this patch are:
> 
> DataFlash page-sizes are not a power of two (they're multiples of 528
> bytes).  There are a few places in JFFS2 code where sector_size is used
> as a bitmask.  A new macro (SECTOR_ADDR) was defined to calculate these
> sector addresses. For non-DataFlash devices, the original (faster)
> bitmask operation is still used.

Nice.  Being independent of specific sector sizes (power of 2,
whatever) makes jffs2 more flexible.  People can decide to spend a few
bytes for for error correction, etc.

> In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. 
> Since this could be larger than the sector size of the DataFlash, this
> is now basically set to MIN(sector_size, 1024).

Ok.

> Addition of a jffs2_is_writebuffered() macro.

Hmm.  See below.

Overall I like the patch, module comments below.

> diff -urN -x CVS mtd.orig/fs/jffs2/erase.c mtd.core/fs/jffs2/erase.c
> --- mtd.orig/fs/jffs2/erase.c	Wed Jan 26 16:07:57 2005
> +++ mtd.core/fs/jffs2/erase.c	Tue Feb  1 10:06:13 2005
> @@ -233,7 +233,7 @@
>  			continue;
>  		} 
>  
> -		if (((*prev)->flash_offset & ~(c->sector_size -1)) == jeb->offset) {
> +		if (SECTOR_ADDR((*prev)->flash_offset) == jeb->offset) {
>  			/* It's in the block we're erasing */
>  			struct jffs2_raw_node_ref *this;
>  
> diff -urN -x CVS mtd.orig/fs/jffs2/gc.c mtd.core/fs/jffs2/gc.c
> --- mtd.orig/fs/jffs2/gc.c	Wed Jan 26 16:07:57 2005
> +++ mtd.core/fs/jffs2/gc.c	Tue Feb  1 10:06:13 2005
> @@ -816,8 +816,7 @@
>  
>  			/* Doesn't matter if there's one in the same erase block. We're going to 
>  			   delete it too at the same time. */
> -			if ((raw->flash_offset & ~(c->sector_size-1)) ==
> -			    (fd->raw->flash_offset & ~(c->sector_size-1)))
> +			if (SECTOR_ADDR(raw->flash_offset) == SECTOR_ADDR(fd->raw->flash_offset))
>  				continue;
>  
>  			D1(printk(KERN_DEBUG "Check potential deletion dirent at %08x\n", ref_offset(raw)));
> diff -urN -x CVS mtd.orig/fs/jffs2/os-linux.h mtd.core/fs/jffs2/os-linux.h
> --- mtd.orig/fs/jffs2/os-linux.h	Wed Jan 26 16:07:58 2005
> +++ mtd.core/fs/jffs2/os-linux.h	Tue Feb  1 10:06:13 2005
> @@ -97,7 +97,10 @@
>  #endif
>  }
>  
> +#define SECTOR_ADDR(x) ( ((unsigned long)(x) & ~(c->sector_size-1)) )
> +
>  #define jffs2_is_readonly(c) (OFNI_BS_2SFFJ(c)->s_flags & MS_RDONLY)
> +#define jffs2_is_writebuffered(c) (c->wbuf != NULL)

if (jffs2_is_writebuffered(c))
if (c->wbuf)

With your definition, the code is getting longer.  Not sure if I like
that part.

>  
>  #if (!defined CONFIG_JFFS2_FS_NAND && !defined CONFIG_JFFS2_FS_NOR_ECC)
>  #define jffs2_can_mark_obsolete(c) (1)
> diff -urN -x CVS mtd.orig/fs/jffs2/scan.c mtd.core/fs/jffs2/scan.c
> --- mtd.orig/fs/jffs2/scan.c	Wed Jan 26 16:07:58 2005
> +++ mtd.core/fs/jffs2/scan.c	Tue Feb  1 10:07:55 2005
> @@ -19,7 +19,7 @@
>  #include <linux/compiler.h>
>  #include "nodelist.h"
>  
> -#define EMPTY_SCAN_SIZE 1024
> +#define DEFAULT_EMPTY_SCAN_SIZE 1024
>  
>  #define DIRTY_SPACE(x) do { typeof(x) _x = (x); \
>  		c->free_size -= _x; c->dirty_size += _x; \
> @@ -75,6 +75,14 @@
>  	return min;
>  
>  }
> +
> +static inline uint32_t EMPTY_SCAN_SIZE(uint32_t sector_size) {
> +	if (sector_size < DEFAULT_EMPTY_SCAN_SIZE)
> +		return sector_size;
> +	else
> +		return DEFAULT_EMPTY_SCAN_SIZE;
> +}
> +

Better use min() or at least min_t().  Also, if you pass c instead of
c->sector_size, the calling code is a bit simpler.

>  int jffs2_scan_medium(struct jffs2_sb_info *c)
>  {
>  	int i, ret;
> @@ -316,7 +324,7 @@
>  	if (!buf_size) {
>  		buf_len = c->sector_size;
>  	} else {
> -		buf_len = EMPTY_SCAN_SIZE;
> +		buf_len = EMPTY_SCAN_SIZE(c->sector_size);
>  		err = jffs2_fill_scan_buf(c, buf, buf_ofs, buf_len);
>  		if (err)
>  			return err;
> @@ -326,10 +334,10 @@
>  	ofs = 0;
>  
>  	/* Scan only 4KiB of 0xFF before declaring it's empty */
> -	while(ofs < EMPTY_SCAN_SIZE && *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF)
> +	while(ofs < EMPTY_SCAN_SIZE(c->sector_size) && *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF)
>  		ofs += 4;
>  
> -	if (ofs == EMPTY_SCAN_SIZE) {
> +	if (ofs == EMPTY_SCAN_SIZE(c->sector_size)) {
>  #ifdef CONFIG_JFFS2_FS_NAND
>  		if (jffs2_cleanmarker_oob(c)) {
>  			/* scan oob, take care of cleanmarker */
> @@ -423,7 +431,7 @@
>  			   bail now */
>  			if (buf_ofs == jeb->offset && jeb->used_size == PAD(c->cleanmarker_size) && 
>  			    c->cleanmarker_size && !jeb->dirty_size && !jeb->first_node->next_in_ino) {
> -				D1(printk(KERN_DEBUG "%d bytes at start of block seems clean... assuming all clean\n", EMPTY_SCAN_SIZE));
> +				D1(printk(KERN_DEBUG "%d bytes at start of block seems clean... assuming all clean\n", EMPTY_SCAN_SIZE(c->sector_size)));
>  				return BLK_STATE_CLEANMARKER;
>  			}
>  
> diff -urN -x CVS mtd.orig/fs/jffs2/wbuf.c mtd.core/fs/jffs2/wbuf.c
> --- mtd.orig/fs/jffs2/wbuf.c	Wed Jan 26 16:07:58 2005
> +++ mtd.core/fs/jffs2/wbuf.c	Tue Feb  1 10:06:13 2005
> @@ -415,9 +415,9 @@
>  	int ret;
>  	size_t retlen;
>  
> -	/* Nothing to do if not NAND flash. In particular, we shouldn't
> +	/* Nothing to do if not write-buffering the flash. In particular, we shouldn't
>  	   del_timer() the timer we never initialised. */
> -	if (jffs2_can_mark_obsolete(c))
> +	if (!jffs2_is_writebuffered(c))
>  		return 0;
>  
>  	if (!down_trylock(&c->alloc_sem)) {
> @@ -426,7 +426,7 @@
>  		BUG();
>  	}
>  
> -	if(!c->wbuf || !c->wbuf_len)
> +	if (!c->wbuf_len)	/* already checked c->wbuf above */
>  		return 0;
>  
>  	/* claim remaining space on the page
> @@ -614,7 +614,7 @@
>  	uint32_t outvec_to = to;
>  
>  	/* If not NAND flash, don't bother */
> -	if (!c->wbuf)
> +	if (!jffs2_is_writebuffered(c))
>  		return jffs2_flash_direct_writev(c, invecs, count, to, retlen);
>  	
>  	down_write(&c->wbuf_sem);
> @@ -643,7 +643,7 @@
>  	   erase block. Anything else, and you die.
>  	   New block starts at xxx000c (0-b = block header)
>  	*/
> -	if ( (to & ~(c->sector_size-1)) != (c->wbuf_ofs & ~(c->sector_size-1)) ) {
> +	if (SECTOR_ADDR(to) != SECTOR_ADDR(c->wbuf_ofs)) {
>  		/* It's a write to a new block */
>  		if (c->wbuf_len) {
>  			D1(printk(KERN_DEBUG "jffs2_flash_writev() to 0x%lx causes flush of wbuf at 0x%08x\n", (unsigned long)to, c->wbuf_ofs));
> @@ -841,7 +841,7 @@
>  {
>  	struct kvec vecs[1];
>  
> -	if (jffs2_can_mark_obsolete(c))
> +	if (!jffs2_is_writebuffered(c))
>  		return c->mtd->write(c->mtd, ofs, len, retlen, buf);
>  
>  	vecs[0].iov_base = (unsigned char *) buf;
> @@ -857,39 +857,39 @@
>  	loff_t	orbf = 0, owbf = 0, lwbf = 0;
>  	int	ret;
>  
> +	if (!jffs2_is_writebuffered(c))
> +		return c->mtd->read(c->mtd, ofs, len, retlen, buf);
> +
>  	/* Read flash */
> -	if (!jffs2_can_mark_obsolete(c)) {
> -		down_read(&c->wbuf_sem);
> +	down_read(&c->wbuf_sem);
>  
> -		if (jffs2_cleanmarker_oob(c))
> -			ret = c->mtd->read_ecc(c->mtd, ofs, len, retlen, buf, NULL, c->oobinfo);
> -		else
> -			ret = c->mtd->read(c->mtd, ofs, len, retlen, buf);
> +	if (jffs2_cleanmarker_oob(c))
> +		ret = c->mtd->read_ecc(c->mtd, ofs, len, retlen, buf, NULL, c->oobinfo);
> +	else
> +		ret = c->mtd->read(c->mtd, ofs, len, retlen, buf);
>  
> -		if ( (ret == -EBADMSG) && (*retlen == len) ) {
> -			printk(KERN_WARNING "mtd->read(0x%zx bytes from 0x%llx) returned ECC error\n",
> -			       len, ofs);
> -			/* 
> -			 * We have the raw data without ECC correction in the buffer, maybe 
> -			 * we are lucky and all data or parts are correct. We check the node.
> -			 * If data are corrupted node check will sort it out.
> -			 * We keep this block, it will fail on write or erase and the we
> -			 * mark it bad. Or should we do that now? But we should give him a chance.
> -			 * Maybe we had a system crash or power loss before the ecc write or  
> -			 * a erase was completed.
> -			 * So we return success. :)
> -			 */
> -		 	ret = 0;
> -		 }	
> -	} else
> -		return c->mtd->read(c->mtd, ofs, len, retlen, buf);
> +	if ( (ret == -EBADMSG) && (*retlen == len) ) {
> +		printk(KERN_WARNING "mtd->read(0x%zx bytes from 0x%llx) returned ECC error\n",
> +		       len, ofs);
> +		/* 
> +		 * We have the raw data without ECC correction in the buffer, maybe 
> +		 * we are lucky and all data or parts are correct. We check the node.
> +		 * If data are corrupted node check will sort it out.
> +		 * We keep this block, it will fail on write or erase and the we
> +		 * mark it bad. Or should we do that now? But we should give him a chance.
> +		 * Maybe we had a system crash or power loss before the ecc write or  
> +		 * a erase was completed.
> +		 * So we return success. :)
> +		 */
> +	 	ret = 0;
> +	}	
>  
>  	/* if no writebuffer available or write buffer empty, return */
>  	if (!c->wbuf_pagesize || !c->wbuf_len)
>  		goto exit;
>  
>  	/* if we read in a different block, return */
> -	if ( (ofs & ~(c->sector_size-1)) != (c->wbuf_ofs & ~(c->sector_size-1)) ) 
> +	if (SECTOR_ADDR(ofs) != SECTOR_ADDR(c->wbuf_ofs))
>  		goto exit;
>  
>  	if (ofs >= c->wbuf_ofs) {
> 
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

J?rn

-- 
Happiness isn't having what you want, it's wanting what you have.
-- unknown



From rudi at unsec.nl  Wed Feb  2 07:26:00 2005
From: rudi at unsec.nl (Rudi Engelbertink)
Date: Wed, 2 Feb 2005 13:26:00 +0100
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <1107340012.21196.507.camel@tglx.tec.linutronix.de>
References: <20050201150810.M93647@unsec.nl>
	<Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>
	<20050202085600.M52308@unsec.nl>
	<1107340012.21196.507.camel@tglx.tec.linutronix.de>
Message-ID: <20050202112025.M50509@unsec.nl>

On Wed, 02 Feb 2005 11:26:51 +0100, Thomas Gleixner wrote
> On Wed, 2005-02-02 at 10:05 +0100, Rudi Engelbertink wrote:
> > The powerfail tests are done by:
> > A. a clock. Just turn off and on the power every 15 minutes and start the
> > an application which logs 2 40-60 byte events every second.
> > ...
> > Yes, the root is accessable but the directory where the logging is stored,
> > is unavailable for several minutes.
> 
> You hit the worst case for JFFS2.
> 
> Your event logging creates tons of small nodes for your logfiles.
> Actually are about 96000 very small nodes on the chip, so the mount time
> is not surprising. This also will use a quite big amount of memory.
> 
> We have no real cure for this at the moment. We have this scenario in
> our design list for JFFS3. I remember that somebody else came up with
> this issue sometime ago. IIRC changing the log method did help a bit.
> 
> while true
> do
> 	log_event
> 	let cnt=cnt+1
> 	if [ $cnt -ge $LIMIT ]
> 	then
> 		closelog
> 		cat log.small >>log.big
> 		rm log.small
> 	fi
> done
> 
> This converts the small nodes to bigger nodes when the data are appended
> to log.big. I guess garbage collection should kick in quite fast and
> clean up the small nodes. It might not totally go away, but it 
> should be much better than now. This will also give you more 
> capacity on your partition as the small nodes consist mostly of node 
> overhead.

Digging through the logfile I noticed that several inodes had a lot of
versions. Especialy the inode #737 which had 60000+ versions.
This is a bit strange because this is a 16 byte pointer file which will
be opened once and never closed. This should not result in 60000+ versions.
A copy move action (cp -p file file.cp && mv file.cp file) indeed makes a big
performance improvement. 
Will a regular close open of this file make some improvement regarding the
stored version information of this inode. During normal operations this file,
and some other files, never gets closed. So there will be never a 'commit'.
So after a powerfail, all the inode version information must be checked.

> 
> You may also try YAFFS for the logging partition. It should deal with
> this situation a bit better.
> 
> tglx

RGDS Rudi.
-- 
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
   Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8




From joern at wohnheim.fh-wedel.de  Wed Feb  2 07:40:43 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Wed, 2 Feb 2005 13:40:43 +0100
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
In-Reply-To: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
References: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
Message-ID: <20050202124043.GB23156@wohnheim.fh-wedel.de>

On Tue, 1 February 2005 11:00:03 +0200, Andrew Victor wrote:
>
> @@ -660,6 +666,14 @@
>  		if (ret)
>  			return ret;
>  	}
> +	
> +	/* and Dataflash */
> +	if (jffs2_dataflash(c)) {
> +		ret = jffs2_dataflash_setup(c);
> +		if (ret)
> +			return ret;
> +	}

This can be a bit simpler:

	ret = jffs2_dataflash_setup()
	if (ret)
		return ret;

Just move the outer condition into the called function, like this:

	if (!jffs2_data_flash(c)
		return 0; /* nothing to do */

>  	return ret;
>  }
>  
> @@ -673,4 +687,9 @@
>  	if (jffs2_nor_ecc(c)) {
>  		jffs2_nor_ecc_flash_cleanup(c);
>  	}
> +	
> +	/* and DataFlash */
> +	if (jffs2_dataflash(c)) {
> +		jffs2_dataflash_cleanup(c);
> +	}

Same here.

> diff -urN -x CVS mtd.core/fs/jffs2/os-linux.h mtd.new/fs/jffs2/os-linux.h
> --- mtd.core/fs/jffs2/os-linux.h	Tue Feb  1 10:06:13 2005
> +++ mtd.new/fs/jffs2/os-linux.h	Tue Feb  1 10:18:19 2005
> @@ -97,12 +97,16 @@
>  #endif
>  }
>  
> +#ifdef CONFIG_JFFS2_FS_DATAFLASH
> +#define SECTOR_ADDR(x) ( ((unsigned long)(x) / (unsigned long)(c->sector_size)) * c->sector_size )

Not sure, but this might be slightly faster:

static inline unsigned long SECTOR_ADDR(struct jffs2_superblock_info c, uint32_t _x) {
	unsigned long x = _x;
	return x - (x % c->sector_size);
}

Plus it has the types explicit.  They may be wrong in my version, but
at least they are explicitly wrong.

> +#else
>  #define SECTOR_ADDR(x) ( ((unsigned long)(x) & ~(c->sector_size-1)) )
> +#endif
>  
>  #define jffs2_is_readonly(c) (OFNI_BS_2SFFJ(c)->s_flags & MS_RDONLY)
>  #define jffs2_is_writebuffered(c) (c->wbuf != NULL)
>  
> -#if (!defined CONFIG_JFFS2_FS_NAND && !defined CONFIG_JFFS2_FS_NOR_ECC)
> +#if (!defined CONFIG_JFFS2_FS_NAND && !defined CONFIG_JFFS2_FS_NOR_ECC && !defined CONFIG_JFFS2_FS_DATAFLASH)
>  #define jffs2_can_mark_obsolete(c) (1)
>  #define jffs2_cleanmarker_oob(c) (0)
>  #define jffs2_write_nand_cleanmarker(c,jeb) (-EIO)
> @@ -119,6 +123,7 @@
>  #define jffs2_wbuf_timeout NULL
>  #define jffs2_wbuf_process NULL
>  #define jffs2_nor_ecc(c) (0)
> +#define jffs2_dataflash(c) (0)
>  #define jffs2_nor_ecc_flash_setup(c) (0)
>  #define jffs2_nor_ecc_flash_cleanup(c) do {} while (0)
>  
> @@ -154,6 +159,15 @@
>  #define jffs2_nor_ecc_flash_setup(c) (0)
>  #define jffs2_nor_ecc_flash_cleanup(c) do {} while (0)
>  #endif /* NOR ECC */
> +#ifdef CONFIG_JFFS2_FS_DATAFLASH
> +#define jffs2_dataflash(c) (c->mtd->type == MTD_DATAFLASH)
> +int jffs2_dataflash_setup(struct jffs2_sb_info *c);
> +void jffs2_dataflash_cleanup(struct jffs2_sb_info *c);
> +#else
> +#define jffs2_dataflash(c) (0)
> +#define jffs2_dataflash_setup(c) (0)
> +#define jffs2_dataflash_cleanup(c) do {} while (0)
> +#endf /* DATAFLASH */
>  #endif /* NAND */
>  
>  /* erase.c */
> diff -urN -x CVS mtd.core/fs/jffs2/scan.c mtd.new/fs/jffs2/scan.c
> --- mtd.core/fs/jffs2/scan.c	Tue Feb  1 10:07:55 2005
> +++ mtd.new/fs/jffs2/scan.c	Tue Feb  1 10:18:53 2005
> @@ -68,7 +68,7 @@
>  static inline int min_free(struct jffs2_sb_info *c)
>  {
>  	uint32_t min = 2 * sizeof(struct jffs2_raw_inode);
> -#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC
> +#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
>  	if (!jffs2_can_mark_obsolete(c) && min < c->wbuf_pagesize)
>  		return c->wbuf_pagesize;
>  #endif
> @@ -228,7 +228,7 @@
>  		c->dirty_size -= c->nextblock->dirty_size;
>  		c->nextblock->dirty_size = 0;
>  	}
> -#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC
> +#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
>  	if (!jffs2_can_mark_obsolete(c) && c->nextblock && (c->nextblock->free_size & (c->wbuf_pagesize-1))) {
>  		/* If we're going to start writing into a block which already 
>  		   contains data, and the end of the data isn't page-aligned,
> @@ -351,7 +351,10 @@
>  		}
>  #endif
>  		D1(printk(KERN_DEBUG "Block at 0x%08x is empty (erased)\n", jeb->offset));
> -		return BLK_STATE_ALLFF;	/* OK to erase if all blocks are like this */
> +		if (c->cleanmarker_size == 0)
> +			return BLK_STATE_CLEANMARKER;	/* don't bother with re-erase */

Why this?

> +		else
> +			return BLK_STATE_ALLFF;	/* OK to erase if all blocks are like this */
>  	}
>  	if (ofs) {
>  		D1(printk(KERN_DEBUG "Free space at %08x ends at %08x\n", jeb->offset,
> diff -urN -x CVS mtd.core/fs/jffs2/wbuf.c mtd.new/fs/jffs2/wbuf.c
> --- mtd.core/fs/jffs2/wbuf.c	Tue Feb  1 10:06:13 2005
> +++ mtd.new/fs/jffs2/wbuf.c	Tue Feb  1 10:17:22 2005
> @@ -435,7 +435,7 @@
>  	   if we have a switch to next page, we will not have
>  	   enough remaining space for this. 
>  	*/
> -	if (pad) {
> +	if (pad && !jffs2_dataflash(c)) {
>  		c->wbuf_len = PAD(c->wbuf_len);
>  
>  		/* Pad with JFFS2_DIRTY_BITMASK initially.  this helps out ECC'd NOR
> @@ -486,7 +486,7 @@
>  	spin_lock(&c->erase_completion_lock);
>  
>  	/* Adjust free size of the block if we padded. */
> -	if (pad) {
> +	if (pad && !jffs2_dataflash(c)) {
>  		struct jffs2_eraseblock *jeb;
>  
>  		jeb = &c->blocks[c->wbuf_ofs / c->sector_size];
> @@ -598,8 +598,14 @@
>  	return ret;
>  }
>  
> +#ifdef CONFIG_JFFS2_FS_DATAFLASH
> +#define PAGE_DIV(x) ( ((unsigned long)(x) / (unsigned long)(c->wbuf_pagesize)) * (unsigned long)(c->wbuf_pagesize) )
> +#define PAGE_MOD(x) ( (unsigned long)(x) % (unsigned long)(c->wbuf_pagesize) )

See above.

> +#else
>  #define PAGE_DIV(x) ( (x) & (~(c->wbuf_pagesize - 1)) )
>  #define PAGE_MOD(x) ( (x) & (c->wbuf_pagesize - 1) )
> +#endif
> +
>  int jffs2_flash_writev(struct jffs2_sb_info *c, const struct kvec *invecs, unsigned long count, loff_t to, size_t *retlen, uint32_t ino)
>  {
>  	struct kvec outvecs[3];
> @@ -1183,6 +1189,29 @@
>  	kfree(c->wbuf);
>  }
>  
> +#ifdef CONFIG_JFFS2_FS_DATAFLASH
> +int jffs2_dataflash_setup(struct jffs2_sb_info *c) {

Insert the check from above.

> +	c->cleanmarker_size = 0;		/* No cleanmarkers needed */
> +	
> +	/* Initialize write buffer */
> +	init_rwsem(&c->wbuf_sem);
> +	c->wbuf_pagesize = c->sector_size;
> +	c->wbuf_ofs = 0xFFFFFFFF;
> +
> +	c->wbuf = kmalloc(c->wbuf_pagesize, GFP_KERNEL);
> +	if (!c->wbuf)
> +		return -ENOMEM;
> +
> +	printk(KERN_INFO "JFFS2 write-buffering enabled (%i)\n", c->wbuf_pagesize);
> +
> +	return 0;
> +}
> +
> +void jffs2_dataflash_cleanup(struct jffs2_sb_info *c) {

dito

> +	kfree(c->wbuf);
> +}
> +#endif
> +
>  #ifdef CONFIG_JFFS2_FS_NOR_ECC
>  int jffs2_nor_ecc_flash_setup(struct jffs2_sb_info *c) {
>  	/* Cleanmarker is actually larger on the flashes */
> diff -urN -x CVS mtd.core/include/linux/jffs2_fs_sb.h mtd.new/include/linux/jffs2_fs_sb.h
> --- mtd.core/include/linux/jffs2_fs_sb.h	Wed Jan 26 16:09:40 2005
> +++ mtd.new/include/linux/jffs2_fs_sb.h	Tue Feb  1 10:17:22 2005
> @@ -94,7 +94,7 @@
>  	   to an obsoleted node. I don't like this. Alternatives welcomed. */
>  	struct semaphore erase_free_sem;
>  
> -#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC
> +#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
>  	/* Write-behind buffer for NAND flash */
>  	unsigned char *wbuf;
>  	uint32_t wbuf_ofs;
> diff -urN -x CVS mtd.core/include/mtd/mtd-abi.h mtd.new/include/mtd/mtd-abi.h
> --- mtd.core/include/mtd/mtd-abi.h	Wed Jan 26 16:09:41 2005
> +++ mtd.new/include/mtd/mtd-abi.h	Tue Feb  1 10:17:22 2005
> @@ -29,6 +29,7 @@
>  #define MTD_NORFLASH		3
>  #define MTD_NANDFLASH		4
>  #define MTD_PEROM		5
> +#define MTD_DATAFLASH		6
>  #define MTD_OTHER		14
>  #define MTD_UNKNOWN		15
>  
> 
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

J?rn

-- 
...one more straw can't possibly matter...
-- Kirby Bakken



From tglx at linutronix.de  Wed Feb  2 07:41:05 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 02 Feb 2005 13:41:05 +0100
Subject: jffs2_get_inode_nodes() very very slow
In-Reply-To: <20050202112025.M50509@unsec.nl>
References: <20050201150810.M93647@unsec.nl>
	<Pine.LNX.4.58.0502011601470.23856@phoenix.infradead.org>
	<20050202085600.M52308@unsec.nl>
	<1107340012.21196.507.camel@tglx.tec.linutronix.de>
	<20050202112025.M50509@unsec.nl>
Message-ID: <1107348065.21196.544.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-02 at 13:26 +0100, Rudi Engelbertink wrote:
> > This converts the small nodes to bigger nodes when the data are appended
> > to log.big. I guess garbage collection should kick in quite fast and
> > clean up the small nodes. It might not totally go away, but it 
> > should be much better than now. This will also give you more 
> > capacity on your partition as the small nodes consist mostly of node 
> > overhead.
> 
> Digging through the logfile I noticed that several inodes had a lot of
> versions. Especialy the inode #737 which had 60000+ versions.
> This is a bit strange because this is a 16 byte pointer file which will
> be opened once and never closed. This should not result in 60000+ versions.

It's because JFFS2 does synchronous writes. That means, every write()
you do, is written to the FLASH immidiately. So every small log write
goes into FLASH and builds a node.

The version count is just incremented and the old nodes are declared
obsolete. I'm not sure, why the blocks are not garbage collected.

> A copy move action (cp -p file file.cp && mv file.cp file) indeed makes a big
> performance improvement. 
> Will a regular close open of this file make some improvement regarding the
> stored version information of this inode. During normal operations this file,
> and some other files, never gets closed. So there will be never a 'commit'.

close / open actually does not help. Without changes to JFFS2 code only
the copy to a different file will help you.

tglx






From dwmw2 at infradead.org  Wed Feb  2 08:43:48 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 02 Feb 2005 13:43:48 +0000
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
In-Reply-To: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
References: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
Message-ID: <1107351828.18239.26.camel@baythorne.infradead.org>

On Tue, 2005-02-01 at 11:00 +0200, Andrew Victor wrote:
> +   bool 'JFFS2 support for DataFlash' CONFIG_JFFS2_FS_DATAFLASH

Heckling on IRC has convinced me that it's time we reduced the mess of
config options. We don't want separate options for all of the random
flash types. 

We could _perhaps_ still have an option to omit wbuf.c entirely and
support only NOR flash, but having an option for each of the other types
is overkill and it's getting ugly. Can we merge the NAND and ECC_NOR and
DATAFLASH options into one? And can we make it use the wbuf on blkmtd
while we're at it?

-- 
dwmw2





From MattCreech at eaton.com  Wed Feb  2 10:00:56 2005
From: MattCreech at eaton.com (Creech, Matthew)
Date: Wed, 2 Feb 2005 10:00:56 -0500
Subject: JFFS2 on dataflash problem
Message-ID: <F0A064EBC8C91C449244D108367426DC01E4AFEF@ra1ncsmb01.nasa.ad.etn.com>

Hi,

Please forgive the cross-posting, but I'm not sure where exactly to go
with this problem.

I have an embedded device based on Atmel's AT91RM9200DK board, which is
using serial dataflash (AT45DB642).  I've allocated a JFFS2 partition to
store non-volatile data.  In testing I stumbled across a particular
problem that only occurs after heavy hammering on our device, but is
fairly consistent in how and when it occurs.  The pattern has been
narrowed down so that a script doing something like this:

while [ 1 ]; do
   cp /mnt/jffs2/$RANDOM_FILE /mnt/jffs2/$BLAH
   # File size has been tested between 8K and 64K
done

makes the problem occur within 24 to 36 hours.  So something about
copying one file over another one breaks things.  The "problem" here is
that every I/O operation having to do with the JFFS2 partition blocks
indefinitely.  For example, after running the test for 2 days, you can
log into the device and try to "ls" the contents of /mnt/jffs2, and your
shell will hang.  You can then login on another terminal, but you'll get
another hang if you try to have any interaction with the JFFS2
partition.  So everything else seems to function normally, but JFFS2
just dies.  Also note that rebooting the device sometimes fixes things
right up (JFFS2 mounts fine and works properly as if nothing happened at
all), but sometimes the filesystem image is corrupt and refuses to
mount.

The system's specs are as follows:
AT91RM9200
AT45DB642 8MB serial dataflash device on SPI channel
2.4.25 kernel with VRS2 patchset, plus...
Andrew Victor's AT91 patchset (http://maxim.org.za/AT91RM9200/), plus...
Various snapshots of MTD taken over the past several months (no change)
Snapgear-3.2.0 userland (doubt this makes a difference)

As noted above, I've tried this with various MTD snapshots (using the
default MTD in 2.4.25 makes JFFS2 die almost immediately when doing
anything).  I've also recently compiled 2.6.10 with the AT91 patchset
(http://maxim.org.za/AT91RM9200/2.6/), but the *exact* same thing
happens.

The only kernel output I get is a few repetitions of this message, just
before the problem begins:

Node totlen on flash (0xffffffff) != totlen from node ref ([some
close-to-zero number])

My testing using raw dataflash access seems to rule out dataflash
issues, and _suggest_ that MTD isn't directly to blame, since no errors
occur when copying images to /dev/mtd/X then reading them back.  But I
can't rule anything out for sure.  It seems more likely that this is
some strange interaction between dataflash, MTD, and JFFS2, possibly
related to this device's 1056-byte blocksize; IIRC this was a problem in
the past that required some patching, since most code assumes a
power-of-two blocksize.

These are all just guesses, though, which is why I'm posting this
message.  I'm wondering whether there are any other ideas I can try to
narrow this problem down; since testing it requires 1-2 days, it's
fruitless to just make random guesses and see if they "fix" things.  Any
suggestions you have are greatly appreciated!

Thanks for the help

-- 
Matthew L. Creech 



From dedekind at infradead.org  Wed Feb  2 10:44:50 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 2 Feb 2005 15:44:50 +0000 (GMT)
Subject: JFFS3 memory consumption
In-Reply-To: <1107276561.21196.457.camel@tglx.tec.linutronix.de>
References: <Pine.LNX.4.58.0501260841380.3222@phoenix.infradead.org> 
	<1106865326.783.146.camel@baythorne.infradead.org> 
	<1106871577.21196.155.camel@tglx.tec.linutronix.de> 
	<1106872400.6480.201.camel@localhost.localdomain> 
	<1106873065.21196.168.camel@tglx.tec.linutronix.de> 
	<Pine.LNX.4.58.0501280817330.11160@phoenix.infradead.org> 
	<1106903029.21196.216.camel@tglx.tec.linutronix.de> 
	<Pine.LNX.4.58.0501280914580.11160@phoenix.infradead.org> 
	<Pine.LNX.4.58.0501281855370.11160@phoenix.infradead.org> 
	<1107111514.18794.37.camel@sauron.oktetlabs.ru>
	<6934efce05013108463a4d42e4@mail.gmail.com>
	<Pine.LNX.4.58.0501311804550.17207@phoenix.infradead.org>
	<1107276561.21196.457.camel@tglx.tec.linutronix.de>
Message-ID: <Pine.LNX.4.58.0502021544380.29798@phoenix.infradead.org>

On Tue, 1 Feb 2005, Thomas Gleixner wrote:
> This might turn out to be a GC nightmare. Every update to a file might
> result in shuffling tons of nodes around or at least trying to do so.
>
> Keep it simple.
Agree, this might be too complicate approach.

> Not only GC makes this necessary, every write to a file too.
Agreed.

> I'm not sure which of the mechanisms will provide us more horror. My
> guess is ICP. The summary method is definitely less performant, but I
> think therefor less complicated to handle. So we trade performance for
> simplicity, which makes more sense for me than the other way round.
>

I'll try to describe ICP approach and the horror I may foresee.

Some terms and definitions:
~~~~~~~~~~~~~~~~~~~~~~~~~~
ICP describes nodes and contains *ICP entries*. Each ICP entry corresponds 
to one node.

ICP entry is *valid*, if the node it refers to is valid and is at the 
correct position (i.e., GC didn't move it).

ICP entry is *invalid* if it is not valid.

ICP node is *obsolete* if:
1. the number of its valid ICP entries is less then certain watermark 
(MIN_ICP_ENTRIES);
2. The percentage of its valid ICP entries is less then the certain 
watermark (MIN_ICP_ENTRIES_PERC).

Next, the ICP entries have versions. The next ICP entry has the version of 
the previous one + 1.

Consider use-cases for better understanding. Suppose we have 3 ICP nodes 
for the inode #4. Their versions are 1,2 and 3. Suppose inode #4 has 3000 
nodes (versions 1-3000) if it is the regular file inode or 3000 direntries 
if it is the directory inode.

Case 1.
	ICP node v1 describes nodes v1-1000.
	ICP node v2 describes nodes v1001-2500.
	ICP node v3 describes nodes v2501-3000.
All ICP nodes are valid, everybody are happy.
To build the inode #4 we need to read all three ICPs.

Case 2.
	ICP node v1 describes nodes v1-3000.
	ICP node v2 describes nodes v10-3000.
	ICP node v3 describes nodes 1-2000.
The ICP node v1 is obsolete since there is newer ICP node (v2) which 
describe almost of the nodes of the inode #4. ICP node v2 is valid, but 
contains only 1000 valid ICP entries since entries v0-2000 are overriden 
by the next ICP node. ICP node v3 is valid, it partially overrides ICP 
node v3.
To build inode #4, we need to read ICP node v2 and ICP node v3.

The analogy to the ordinary inode nodes is obvious.

-------------------------------------------------------------

So, how am I offer to operate?
Basically, I offer to keep in-core references to inode's ICPs. Suppose we 
have flash with data and each inode has valid ICP(s). To be not very 
vague, I'll just describe the behavior I expect in different cases.

1.
If the nodes are moved by the GC, some ICP entries become invalid. For 
those nodes, which have been moved, we keep in-core node_ref. Thus, we 
will have two things in-core:
a). ICP reference(s).
b). node_refs for all the invalid ICP entries.

Here we may again, introduce some watermark - the maximum number of 
node_ref which we may have in-core. If we exceed this watermark, we write 
new ICP node to flash. In new ICP node makes the previous one obsolete, we 
include the ICP entries for all nodes to our new ICP. Otherwise, only 
those which were actually changed.

2.
When the file is changed (not appended), the situation is the same as in  
the first example.

3. If the file is appended, old ICPs are not changed. So we just write new 
ICPs which describe newer nodes only.

Several notes:
1. I did not consider the unclean reboot situation. I think this problem 
is handleable, but may make the mount process very complicated.
2. small inodes, which contain few nodes, may not have ICP. I think it is 
reasonable to use the MIN_ICP_ENTRIES watermark here (described above).

Comments?

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From nico at cam.org  Wed Feb  2 11:28:17 2005
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 2 Feb 2005 11:28:17 -0500 (EST)
Subject: HowTo cache additional address space
In-Reply-To: <20050202160838.GB28574@synertronixx3>
References: <20050202134730.GA16215@synertronixx3>
	<Pine.LNX.4.61.0502021029000.26049@localhost.localdomain>
	<20050202160838.GB28574@synertronixx3>
Message-ID: <Pine.LNX.4.61.0502021122100.26049@localhost.localdomain>

On Wed, 2 Feb 2005, Konstantin Kletschke wrote:

> Am 2005-02-02 10:30 -0500 schrieb Nicolas Pitre:
> 
> > For MTD you need to add support for that in your map driver.  See the 
> > Lubbock map driver for example.
> 
> Is maps/xxx.c the only file which has to be adapted? Ok, I found lubbok
> myself and the ioremap.cached stuff in there...
> 
> I am curious if only the (succesful)
> 
> scb9328_map.cached = (unsigned long)__ioremap(scb9328_map.phys,
> SCB9328_FLASH_SIZE, 0, 0);
> or 
> scb9328_map.cached = ioremap_cached(scb9328_map.phys,
> SCB9328_FLASH_SIZE)
> 
> does the trick...

The __ioremap(..., 0, 0) is uncached.  You need to use the later.

But no, that's not enough.  You also need to provide an inval_cache 
method.


Nicolas



From estelle.hammache at st.com  Wed Feb  2 11:21:43 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Wed, 02 Feb 2005 17:21:43 +0100
Subject: JFFS2 & NAND failure
References: <419B8715.4036BDBB@st.com>
	<1100795260.8191.7333.camel@hades.cambridge.redhat.com>
	<419CE1E8.F20DD890@st.com>
	<1100870238.8191.7368.camel@hades.cambridge.redhat.com>
	<419E1DE0.FDD5DEC0@st.com>
	<1100978366.7949.38.camel@localhost.localdomain>
	<1100988787.7949.46.camel@localhost.localdomain>
	<1102604262.6694.17.camel@hades.cambridge.redhat.com>
	<41B88622.4BCD78EC@st.com> <41C02F29.92D2B5A@st.com>
Message-ID: <4200FE17.30B38D9C@st.com>

Estelle HAMMACHE wrote:
> 
> Hi everyone,
> 
> it seems there is a problem with jffs2_wbuf_recover and
> the wbuf_sem...
> 
> jffs2_flash_writev
> ** down_write(&c->wbuf_sem);  !!!
> ** __jffs2_flush_wbuf
> **** jffs2_wbuf_recover
> ******  jffs2_block_refile
> ********  nextblock = NULL;
> ******  jffs2_reserve_space_gc
> ********  jffs2_do_reserve_space
> **********  jffs2_erase_pending_blocks
> ************  jffs2_mark_erased_block
> **************  jffs2_flash_read
> ****************  down_read(&c->wbuf_sem); !!!
> 

After some thinking I wrote a smallish patch to correct 
this part of the problem (edited below to show the full
function). If there are no objections I will commit it
this week-end. The wbuf semaphore is locked only after
the first checks, I don't believe this can cause trouble
because the wbuf is not freed once it is allocated
and the later checks are enough to prevent copying
a wrong wbuf contents.

The other case I mentionned (no erasing block so
jffs2_do_reserve_space tries to flush the wbuf)
seems impossible - we would not have allowed writing
in this case.

bye
Estelle


 int jffs2_flash_read(struct jffs2_sb_info *c, loff_t ofs, size_t len, size_t *retlen, u_char *buf)
 {
 	loff_t	orbf = 0, owbf = 0, lwbf = 0;
 	int	ret;
 
 	/* Read flash */
 	if (!jffs2_can_mark_obsolete(c)) {
-		down_read(&c->wbuf_sem);
 
 		if (jffs2_cleanmarker_oob(c))
 			ret = c->mtd->read_ecc(c->mtd, ofs, len, retlen, buf, NULL, c->oobinfo);
 		else
 			ret = c->mtd->read(c->mtd, ofs, len, retlen, buf);
 
 		if ( (ret == -EBADMSG) && (*retlen == len) ) {
 			printk(KERN_WARNING "mtd->read(0x%zx bytes from 0x%llx) returned ECC error\n",
 			       len, ofs);
 			/* 
 			 * We have the raw data without ECC correction in the buffer, maybe 
 			 * we are lucky and all data or parts are correct. We check the node.
 			 * If data are corrupted node check will sort it out.
 			 * We keep this block, it will fail on write or erase and the we
 			 * mark it bad. Or should we do that now? But we should give him a chance.
 			 * Maybe we had a system crash or power loss before the ecc write or  
 			 * a erase was completed.
 			 * So we return success. :)
 			 */
 		 	ret = 0;
 		 }	
 	} else
 		return c->mtd->read(c->mtd, ofs, len, retlen, buf);
 
 	/* if no writebuffer available or write buffer empty, return */
 	if (!c->wbuf_pagesize || !c->wbuf_len)
-		goto exit;
+		return ret;
 
 	/* if we read in a different block, return */
 	if ( (ofs & ~(c->sector_size-1)) != (c->wbuf_ofs & ~(c->sector_size-1)) ) 
-		goto exit;
+		return ret;
+
+	/* Lock only if we have reason to believe wbuf contains relevant data,
+	   so that checking an erased block during wbuf recovery space allocation
+	   does not deadlock. */
+	down_read(&c->wbuf_sem);
 
 	if (ofs >= c->wbuf_ofs) {
 		owbf = (ofs - c->wbuf_ofs);	/* offset in write buffer */
 		if (owbf > c->wbuf_len)		/* is read beyond write buffer ? */
 			goto exit;
 		lwbf = c->wbuf_len - owbf;	/* number of bytes to copy */
 		if (lwbf > len)	
 			lwbf = len;
 	} else {	
 		orbf = (c->wbuf_ofs - ofs);	/* offset in read buffer */
 		if (orbf > len)			/* is write beyond write buffer ? */
 			goto exit;
 		lwbf = len - orbf; 		/* number of bytes to copy */
 		if (lwbf > c->wbuf_len)	
 			lwbf = c->wbuf_len;
 	}	
 	if (lwbf > 0)
 		memcpy(buf+orbf,c->wbuf+owbf,lwbf);
 
 exit:
 	up_read(&c->wbuf_sem);
 	return ret;
 }



From jaredeh at gmail.com  Wed Feb  2 13:34:41 2005
From: jaredeh at gmail.com (Jared Hulbert)
Date: Wed, 2 Feb 2005 10:34:41 -0800
Subject: JFFS3 memory consumption
In-Reply-To: <Pine.LNX.4.58.0502021544380.29798@phoenix.infradead.org>
References: <Pine.LNX.4.58.0501260841380.3222@phoenix.infradead.org>
	<Pine.LNX.4.58.0501280817330.11160@phoenix.infradead.org>
	<1106903029.21196.216.camel@tglx.tec.linutronix.de>
	<Pine.LNX.4.58.0501280914580.11160@phoenix.infradead.org>
	<Pine.LNX.4.58.0501281855370.11160@phoenix.infradead.org>
	<1107111514.18794.37.camel@sauron.oktetlabs.ru>
	<6934efce05013108463a4d42e4@mail.gmail.com>
	<Pine.LNX.4.58.0501311804550.17207@phoenix.infradead.org>
	<1107276561.21196.457.camel@tglx.tec.linutronix.de>
	<Pine.LNX.4.58.0502021544380.29798@phoenix.infradead.org>
Message-ID: <6934efce05020210343e3841ec@mail.gmail.com>

What do you mean by in-core?



From tglx at linutronix.de  Wed Feb  2 14:02:08 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 02 Feb 2005 20:02:08 +0100
Subject: CONFIG_MTD_PHYSMAP_START= physical address of NOR FLASH
In-Reply-To: <20050202.102451.25662.2542@webmail18.lax.untd.com>
References: <20050202.102451.25662.2542@webmail18.lax.untd.com>
Message-ID: <1107370929.21196.580.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-02 at 18:24 +0000, Alex wrote:
> CONFIG_MTD_PHYSMAP_START=0x04000801 (this is higher than RAM !)

1. It never starts on an odd address
2. It's inside the reserved physical address space of RAM

> So (based on the data given to me)
> should I use 0x00000801 as a physical
> start address of my NOR FLASH chip ?
> (i got this info from h/w people in Italy)

See below.

> The initial boot provides the following:
> Memory map:
> /* Chip Select FLASH Normal */
> #define BR0_VAL 0x04000801  /* Offset=0x04000000 PS=16 GPCM Valid=1 */
> #define OR0_VAL     0xFFC00160  /* OK */

The value you are using is the value, which is programmed into the BR0
register of the CPU. 
BRx = Bank Register for chipselect x
ORx = Option Register for chipselect x
The values in those registers define the startaddress, buswitdh, size,
timings for the chipselects. So using those values is definitely not a
good idea. Of course you can decode the values in the registers to get
your real address values. 

I have no datasheet handy, but you should definitely read it :)

tglx





From tglx at linutronix.de  Wed Feb  2 14:02:55 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 02 Feb 2005 20:02:55 +0100
Subject: JFFS3 memory consumption
In-Reply-To: <6934efce05020210343e3841ec@mail.gmail.com>
References: <Pine.LNX.4.58.0501260841380.3222@phoenix.infradead.org>
	<Pine.LNX.4.58.0501280817330.11160@phoenix.infradead.org>
	<1106903029.21196.216.camel@tglx.tec.linutronix.de>
	<Pine.LNX.4.58.0501280914580.11160@phoenix.infradead.org>
	<Pine.LNX.4.58.0501281855370.11160@phoenix.infradead.org>
	<1107111514.18794.37.camel@sauron.oktetlabs.ru>
	<6934efce05013108463a4d42e4@mail.gmail.com>
	<Pine.LNX.4.58.0501311804550.17207@phoenix.infradead.org>
	<1107276561.21196.457.camel@tglx.tec.linutronix.de>
	<Pine.LNX.4.58.0502021544380.29798@phoenix.infradead.org>
	<6934efce05020210343e3841ec@mail.gmail.com>
Message-ID: <1107370975.21196.582.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-02 at 10:34 -0800, Jared Hulbert wrote:
> What do you mean by in-core?

RAM

tglx





From pevnev at juno.com  Wed Feb  2 14:05:20 2005
From: pevnev at juno.com (Alex)
Date: Wed, 2 Feb 2005 19:05:20 GMT
Subject: issue with CONFIG_MTD_PHYSMAP_START
Message-ID: <20050202.110536.19684.3594@webmail03.lax.untd.com>


Hi,

I am totally confused now ...

I have: 

load_kernel after serial_init
loaded at:     00180000 0039C184
relocated to:  00400000 0061C184
board data at: 0061A124 0061A164
relocated to:  004050BC 004050FC
zimage at:     004059ED 004EC1DF
initrd at:     004ED000 006199A1
avail ram:     0061D000 02000000
(So I have 32 Mb RAM)

I tried (in .config) for 2.6.10-rc3
CONFIG_MTD_PHYSMAP_START=0x04000801 (this is higher than RAM address !)

and got:
phys addr 04000000 is RAM !!!!

Anyone could tell me, please, why ?

Thanks,
Alex


___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!




From viro at parcelfarce.linux.theplanet.co.uk  Wed Feb  2 14:16:33 2005
From: viro at parcelfarce.linux.theplanet.co.uk (Al Viro)
Date: Wed, 2 Feb 2005 19:16:33 +0000
Subject: [PATCH] (8/27) block2mtd 64bit bug
Message-ID: <20050202191632.GE8859@parcelfarce.linux.theplanet.co.uk>

	Passing pointer to size_t to function that expects u32 * and actually
stores a value there...
Signed-off-by: Al Viro <viro at parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC11-rc2-bk10-sent/drivers/mtd/devices/block2mtd.c RC11-rc2-bk10-mtd/drivers/mtd/devices/block2mtd.c
--- RC11-rc2-bk10-sent/drivers/mtd/devices/block2mtd.c	Fri Jan 21 22:46:40 2005
+++ RC11-rc2-bk10-mtd/drivers/mtd/devices/block2mtd.c	Wed Feb  2 08:27:37 2005
@@ -422,7 +422,7 @@
 	char buf[80+12], *str=buf; /* 80 for device, 12 for erase size */
 	char *token[2];
 	char *name;
-	size_t erase_size = PAGE_SIZE;
+	u32 erase_size = PAGE_SIZE;
 	int i, ret;
 
 	if (strnlen(val, sizeof(buf)) >= sizeof(buf))



From viro at parcelfarce.linux.theplanet.co.uk  Wed Feb  2 14:39:09 2005
From: viro at parcelfarce.linux.theplanet.co.uk (Al Viro)
Date: Wed, 2 Feb 2005 19:39:09 +0000
Subject: [PATCH] (21/27) misc mtd sparse fixes
Message-ID: <20050202193909.GR8859@parcelfarce.linux.theplanet.co.uk>

	* jedec - switched to C99 initializers
	* sun_uflash - removed bogus cast to void * in argument of iounmap() +
NULL noise removal.
Signed-off-by: Al Viro <viro at parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC11-rc2-bk10-sent/drivers/mtd/chips/jedec_probe.c RC11-rc2-bk10-mtd-misc/drivers/mtd/chips/jedec_probe.c
--- RC11-rc2-bk10-sent/drivers/mtd/chips/jedec_probe.c	Fri Jan 21 22:46:40 2005
+++ RC11-rc2-bk10-mtd-misc/drivers/mtd/chips/jedec_probe.c	Wed Feb  2 10:34:57 2005
@@ -1302,7 +1302,7 @@
  		.DevSize	= SIZE_256KiB,
  		.CmdSet		= P_ID_SST_PAGE,
  		.NumEraseRegions= 1,
- 		regions: {ERASEINFO(0x01000,64),
+ 		.regions = {ERASEINFO(0x01000,64),
  		}
          }, {
  		.mfr_id		= MANUFACTURER_SST,
@@ -1314,7 +1314,7 @@
  		.DevSize	= SIZE_256KiB,
  		.CmdSet		= P_ID_SST_PAGE,
  		.NumEraseRegions= 1,
- 		regions: {ERASEINFO(0x01000,64),
+ 		.regions = {ERASEINFO(0x01000,64),
  		}
 	}, {
 		.mfr_id		= MANUFACTURER_SST,
diff -urN RC11-rc2-bk10-sent/drivers/mtd/maps/sun_uflash.c RC11-rc2-bk10-mtd-misc/drivers/mtd/maps/sun_uflash.c
--- RC11-rc2-bk10-sent/drivers/mtd/maps/sun_uflash.c	Fri Dec 24 20:11:47 2004
+++ RC11-rc2-bk10-mtd-misc/drivers/mtd/maps/sun_uflash.c	Wed Feb  2 10:34:57 2005
@@ -109,7 +109,7 @@
 	/* MTD registration */
 	pdev->mtd = do_map_probe("cfi_probe", &pdev->map);
 	if(0 == pdev->mtd) {
-		iounmap((void *)pdev->map.virt);
+		iounmap(pdev->map.virt);
 		kfree(pdev->name);
 		kfree(pdev);
 		return(-ENXIO);
@@ -163,8 +163,8 @@
 			map_destroy(udev->mtd);
 		}
 		if(0 != udev->map.virt) {
-			iounmap((void*)udev->map.virt);
-			udev->map.virt = 0;
+			iounmap(udev->map.virt);
+			udev->map.virt = NULL;
 		}
 		if(0 != udev->name) {
 			kfree(udev->name);



From pevnev at juno.com  Wed Feb  2 14:49:54 2005
From: pevnev at juno.com (Alex)
Date: Wed, 2 Feb 2005 19:49:54 GMT
Subject: CONFIG_MTD_PHYSMAP_START
Message-ID: <20050202.115006.19684.4589@webmail03.lax.untd.com>


Also (in addition to my previous post, where I am questioning the correctness of the output, stating that address belongs to RAM while it clearly does not !), Thomas wrote:

>> The initial boot provides the following:
>> Memory map:
>> /* Chip Select FLASH Normal */
>> #define BR0_VAL 0x04000801 /* Offset=0x04000000 PS=16 GPCM Valid=1 */
>> #define OR0_VAL     0xFFC00160  /* OK */

>The value you are using is the value, which is programmed into the BR0
>register of the CPU. 
>BRx = Bank Register for chipselect x
>ORx = Option Register for chipselect x
>The values in those registers define the start address, buswitdh, size,
>timings for the chipselects. So using those values is definitely not a
>good idea. Of course you can decode the values in the registers to get
>your real address values. 

- it looks that I am in the "chicken" and the "egg" problem ...
According to Thomas (see above), I can not rely on the flash phys start address, given to me "verbotum" - so I can not set the value in .config 
for CONFIG_MTD_PHYSMAP_START ... 
Thomas - in what software you advise me to "decode the values in the registers to get real address values" ? 

Thanks,
Best Regards,
Alex


___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!




From ulf at atmel.com  Wed Feb  2 16:32:27 2005
From: ulf at atmel.com (Ulf Samuelsson)
Date: Wed, 2 Feb 2005 22:32:27 +0100
Subject: JFFS2 on dataflash problem
References: <F0A064EBC8C91C449244D108367426DC01E4AFEF@ra1ncsmb01.nasa.ad.etn.com>
Message-ID: <01c401c50970$3ed65c30$4c7370d5@Glamdring>

> I have an embedded device based on Atmel's AT91RM9200DK board, which is
> using serial dataflash (AT45DB642).  I've allocated a JFFS2 partition to
> store non-volatile data.  In testing I stumbled across a particular
> problem that only occurs after heavy hammering on our device, but is
> fairly consistent in how and when it occurs.  The pattern has been
> narrowed down so that a script doing something like this:

> while [ 1 ]; do
>   cp /mnt/jffs2/$RANDOM_FILE /mnt/jffs2/$BLAH
>   # File size has been tested between 8K and 64K
> done

If I wrote this script I would call it:

wear_out_dataflash_quickly.sh

There are some limitations to the number of erase cycles in the dataflash.
(IN any flash to be correct)
You can expect to reprogram it 50,000-100.000 times before the first errors
occur.
The second thing is that you need to do a block erase after the sum
of erases inside an 8 page block exceeds 10,000.

I am not at all sure that the MTD drivers/JFFS2 handle this (did not look at
the code).
I assume that JFFS may be able to detect a bad write and map
the block out from time to time, so this could explain why you can do the
recover.

If you really want to test the dataflash, write a CRC in the extra bytes
available.
(The page is 1024 + 32 bytes) and read back, checking CRC.

Best Regards,
Ulf Samuelsson
ulf at a-t-m-e-l.com





From pevnev at juno.com  Wed Feb  2 16:49:38 2005
From: pevnev at juno.com (Alex)
Date: Wed, 2 Feb 2005 21:49:38 GMT
Subject: CONFIG_MTD_PHYSMAP_START
Message-ID: <20050202.135036.2985.7488@webmail13.lax.untd.com>


As a reference I am supplying relevant
 content of my .config file 
- could someone please pinpoint to me
 what options need to be changed 
or invoked to correct my current problem
(driver interprets 0x04000000 as RAM address for 32Mb DRAM,
with highest address being 0x02000000).

Thanks,
***************************
...
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
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_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
# 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

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x04000801
CONFIG_MTD_PHYSMAP_LEN=0x400000
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_RPXLITE is not set
# CONFIG_MTD_CFI_FLAGADM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
                                                              

___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!




From tglx at linutronix.de  Wed Feb  2 17:09:30 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 02 Feb 2005 23:09:30 +0100
Subject: CONFIG_MTD_PHYSMAP_START
In-Reply-To: <20050202.115006.19684.4589@webmail03.lax.untd.com>
References: <20050202.115006.19684.4589@webmail03.lax.untd.com>
Message-ID: <1107382170.21196.611.camel@tglx.tec.linutronix.de>

Yor mail client still sends lines > 80 chars 

On Wed, 2005-02-02 at 19:49 +0000, Alex wrote:
> Also (in addition to my previous post, where 
> I am questioning the correctness of the output, 
> stating that address belongs to RAM while it clearly does not !), 

Would you consider to read TFA ?
>> 2. It's inside the reserved physical address space of RAM

> - it looks that I am in the "chicken" and the "egg" problem ...
> According to Thomas (see above), I can not rely on the 
> flash phys start address, given to me "verbotum" - 

Given "verbotum" - I guess you meant verbatim. Some one told you to use
0x000801, which is definitely wrong. Can you please provide the verbatim
information which was given to you ?

You could also point to some valuable information about the board
(vendor, user manual ....)

> so I can not set the value in .config 
> for CONFIG_MTD_PHYSMAP_START ... 
> Thomas - in what software you advise me to "decode the 
> values in the registers to get real address values" ? 

Again: RTFA
>> I have no datasheet handy, but you should definitely read it :)

The registers are described there. Do you expect that I download the
datasheet and decode this for your conveniance ? I can do so, please
contact me offlist and talk to your manager about a support contract.

tglx





From tglx at linutronix.de  Wed Feb  2 17:14:32 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 02 Feb 2005 23:14:32 +0100
Subject: CONFIG_MTD_PHYSMAP_START
In-Reply-To: <20050202.135036.2985.7488@webmail13.lax.untd.com>
References: <20050202.135036.2985.7488@webmail13.lax.untd.com>
Message-ID: <1107382472.21196.616.camel@tglx.tec.linutronix.de>

Keep your postings in the Mail thread by hitting the reply button.

On Wed, 2005-02-02 at 21:49 +0000, Alex wrote:
> As a reference I am supplying relevant

You meant irrelevant.

> CONFIG_MTD_PHYSMAP_START=0x04000801

As explained already, this address is definitely wrong.

Provide relevant information. We are not good in witchcraft and wizardy.

tglx





From tglx at linutronix.de  Wed Feb  2 17:22:11 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 02 Feb 2005 23:22:11 +0100
Subject: JFFS2 on dataflash problem
In-Reply-To: <F0A064EBC8C91C449244D108367426DC01E4AFEF@ra1ncsmb01.nasa.ad.etn.com>
References: <F0A064EBC8C91C449244D108367426DC01E4AFEF@ra1ncsmb01.nasa.ad.etn.com>
Message-ID: <1107382931.21196.620.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-02 at 10:00 -0500, Creech, Matthew wrote:
> Hi,
> 
> makes the problem occur within 24 to 36 hours.  So something about
> copying one file over another one breaks things.  The "problem" here is
> that every I/O operation having to do with the JFFS2 partition blocks
> indefinitely.  For example, after running the test for 2 days, you can
> log into the device and try to "ls" the contents of /mnt/jffs2, and your
> shell will hang.  You can then login on another terminal, but you'll get
> another hang if you try to have any interaction with the JFFS2
> partition.  So everything else seems to function normally, but JFFS2
> just dies.  Also note that rebooting the device sometimes fixes things
> right up (JFFS2 mounts fine and works properly as if nothing happened at
> all), but sometimes the filesystem image is corrupt and refuses to
> mount.

Can you turn on JFFS2 debugging (level 1) in this case and log the debug
output over a serial console ?

tglx





From dwmw2 at infradead.org  Wed Feb  2 17:20:23 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 02 Feb 2005 22:20:23 +0000
Subject: CONFIG_MTD_PHYSMAP_START
In-Reply-To: <1107382472.21196.616.camel@tglx.tec.linutronix.de>
References: <20050202.135036.2985.7488@webmail13.lax.untd.com>
	<1107382472.21196.616.camel@tglx.tec.linutronix.de>
Message-ID: <1107382823.12383.12.camel@localhost.localdomain>

On Wed, 2005-02-02 at 23:14 +0100, Thomas Gleixner wrote:
> Keep your postings in the Mail thread by hitting the reply button.

His reply button is broken; his mailer doesn't conform to RFC2822.

Alex, please use a non-broken mailer if you want to use this forum.
Omitting 'Re:' from the subject to get round the automatic filtering
isn't acceptable either. All traffic from you will be trapped for
moderation until I'm sure you are behaving correctly.

The address 0x04000801 is definitely not correct for the physical
address of the start of flash. Consult your board documentation or
schematics and find the correct value.

-- 
dwmw2




From ashwinc at aftek.com  Wed Feb  2 14:44:18 2005
From: ashwinc at aftek.com (Ashwin Chaugule)
Date: Thu, 03 Feb 2005 01:14:18 +0530
Subject: ST flashes
Message-ID: <42012D92.90007@aftek.com>

Hi,
         Im using 2.4.19-rmk7-pxa1 ... i know its really old and all 
that ... but i have no options right now...
but anyway..
Here's my problem.
I have two pxa 255 boards , one with ST flash and one with AMD.
I configured them to use the lubbock flash driver , and made one 
partition for jffs2.
sorry i dont have the board with me, i shall post the dumps soon..

On both the boards,
it boots up properly , performs all file operations smooth ...mount , 
read write etc..
on the AMD , this performance is consistent even after powering the 
board down.
But on the ST , the moment you power down the board ! , the next time , 
it only mounts , but doesnt
let me perform any fops. I keep getting I/O errors..for only write 
operations... read works , coz i could ls in the partition.
It also doesnt let me format the partition.

So I upgraded , the mtd subsys , along with jffs2 , but still the same 
behaviour...
Also , after upgrading mtd , i found that , the lubbock driver uses 
ioremap_cached and DMA , which is not available
in 2.4.19 , so i disabled all of it , but then the cfi probe fails , and 
only rom_mapping works...
due to which im guessing , mtdblock0 gets write protected and mounts 
jffs2 as read-only.

So I used the physmap driver , created one partition just like the 
lubbock driver .. , but then again , it mounts it as ro !!
here again , only ROM mapping works , it doesnt detect the flash type 
anymore. I have enabled Intel/Sharp , ST and AMD flash driver options in 
the CFI submenu.

Before upgrading the mtd , these options used to work.

Can anyone , give me a lead here ?
Thanks,

-- 
-------------------------
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys Ltd.
[Embedded Division] 




From andrew at sanpeople.com  Thu Feb  3 04:03:16 2005
From: andrew at sanpeople.com (Andrew Victor)
Date: 03 Feb 2005 11:03:16 +0200
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
In-Reply-To: <20050202124043.GB23156@wohnheim.fh-wedel.de>
References: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
	<20050202124043.GB23156@wohnheim.fh-wedel.de>
Message-ID: <1107421396.32163.53.camel@fuzzie.sanpeople.com>

hi J?rn,

> > +	/* and Dataflash */
> > +	if (jffs2_dataflash(c)) {
> > +		ret = jffs2_dataflash_setup(c);
> > +		if (ret)
> > +			return ret;
> > +	}
> 
> This can be a bit simpler:
> 	ret = jffs2_dataflash_setup()
> 	if (ret)
> 		return ret;

I just copied the way it was done for the the NOR ECC flash.


> > -	return BLK_STATE_ALLFF;	/* OK to erase if all blocks are like this */
> > +	if (c->cleanmarker_size == 0)
> > +		return BLK_STATE_CLEANMARKER;	/* don't bother with re-erase */

If a cleanmarker is not detected (within the first EMPTY_SCAN_SIZE bytes
of a block), the block is added to the 'erase_pending_list' to be
re-erased (and have a new cleanmarker written).

Since we don't need cleanmarkers on DataFlash, we return
BLK_STATE_CLEANMARKER from jffs2_scan_eraseblock() so that the block
rather gets added directly to the 'free_list'.


Regards,
  Andrew Victor





From jay4mail at yahoo.com  Thu Feb  3 04:35:43 2005
From: jay4mail at yahoo.com (Pathompong Puengrostham)
Date: Thu, 03 Feb 2005 16:35:43 +0700
Subject: jffs2_scan_eraseblock scan only 1 KiB not 4 KiB of 0xFF
Message-ID: <4201F06F.4030207@yahoo.com>

Hi,

In scan.c, jffs2_scan_eraseblock() scan only 1 KiB of 0xFF not 4 KiB as 
said in the comment. I think the comment is not correct. Do I get it right?


Thanks,
Pathompong Puengrostham

--- scan.c	27 Jan 2005 04:35:22 -0000	1.3
+++ scan.c	3 Feb 2005 09:29:24 -0000
@@ -325,7 +325,7 @@
  	/* We temporarily use 'ofs' as a pointer into the buffer/jeb */
  	ofs = 0;

-	/* Scan only 4KiB of 0xFF before declaring it's empty */
+	/* Scan only 1KiB of 0xFF before declaring it's empty */
  	while(ofs < EMPTY_SCAN_SIZE && *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF)
  		ofs += 4;



From jonas.holmberg at axis.com  Thu Feb  3 04:58:42 2005
From: jonas.holmberg at axis.com (Jonas Holmberg)
Date: Thu, 3 Feb 2005 10:58:42 +0100
Subject: Device ID collision in amd_flash.c
In-Reply-To: <20050202110715.GH27015@axis.com>
References: <20050202110715.GH27015@axis.com>
Message-ID: <20050203095842.GA20345@axis.com>

On Wed, Feb 02, 2005 at 12:07:16PM +0100, Jonas Holmberg wrote:
> The (obsolete) AMD NOR-flash driver has an "probe-table-entry" for 
> AM29BDS643D that happens to match AM29DL640G as well, even though they  
> have different block/sector-layouts.
> 
> I think the problem is that AMD is assigning device-IDs of more than 
> 16-bits.  Anyhow, both AM29BDS643D and AM29DL640G supports CFI, so I 
> would like to remove support for them in amd_flash.c (patch below) to 
> avoid problems.
> 
> OK to commit?

Silly me, who cares about obsolete drivers...
Let me rephrase that question: Any objections before I commit on 
friday (tomorrow)?

I still would like to know how bugfixes finds their way into Linux 
2.4. As I understand, the main trunk in CVS is for 2.6 and I can't 
find any 2.4-branch...

Best regards
/Jonas

> 
> /Jonas
> 
> PS. Would this patch ever find it's way into Linux 2.4 or just Linux 
> 2.6?
> 
> 
> 
> RCS file: /home/cvs/mtd/drivers/mtd/chips/amd_flash.c,v
> retrieving revision 1.26
> diff -u -r1.26 amd_flash.c
> --- amd_flash.c 20 Nov 2004 12:49:04 -0000      1.26
> +++ amd_flash.c 2 Feb 2005 11:03:07 -0000
> @@ -67,7 +67,6 @@
>  #define AM29LV160DT    0x22C4
>  #define AM29LV160DB    0x2249
>  #define AM29BDS323D     0x22D1
> -#define AM29BDS643D    0x227E
>  
>  /* Atmel */
>  #define AT49xV16x      0x00C0
> @@ -618,17 +617,6 @@
>                         { .offset = 0x3f0000, .erasesize = 0x02000, .numblocks =  8 },
>                 }
>         }, {
> -               .mfr_id = MANUFACTURER_AMD,
> -               .dev_id = AM29BDS643D,
> -               .name = "AMD AM29BDS643D",
> -               .size = 0x00800000,
> -               .numeraseregions = 3,
> -               .regions = {
> -                       { .offset = 0x000000, .erasesize = 0x10000, .numblocks = 96 },
> -                       { .offset = 0x600000, .erasesize = 0x10000, .numblocks = 31 },
> -                       { .offset = 0x7f0000, .erasesize = 0x02000, .numblocks =  8 },
> -               }
> -       }, {
>                 .mfr_id = MANUFACTURER_ATMEL,
>                 .dev_id = AT49xV16x,
>                 .name = "Atmel AT49xV16x",
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



From dwmw2 at infradead.org  Thu Feb  3 05:23:52 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 03 Feb 2005 10:23:52 +0000
Subject: Device ID collision in amd_flash.c
In-Reply-To: <20050203095842.GA20345@axis.com>
References: <20050202110715.GH27015@axis.com> <20050203095842.GA20345@axis.com>
Message-ID: <1107426233.12383.46.camel@localhost.localdomain>

On Thu, 2005-02-03 at 10:58 +0100, Jonas Holmberg wrote:
> Silly me, who cares about obsolete drivers...
> Let me rephrase that question: Any objections before I commit on 
> friday (tomorrow)?

Sorry, go ahead.

> I still would like to know how bugfixes finds their way into Linux 
> 2.4. As I understand, the main trunk in CVS is for 2.6 and I can't 
> find any 2.4-branch...

In general, they don't get in to 2.4. Nobody cares about 2.4 any more.
If it _works_ for you, all well and good. But if it hasn't already been
working for you for a year, then why are you trying to make it work now?
Use 2.6.

Feel free to send this change to Marcelo if you really care.

-- 
dwmw2




From dedekind at infradead.org  Thu Feb  3 05:54:26 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 3 Feb 2005 10:54:26 +0000 (GMT)
Subject: JFFS3 memory consumption
In-Reply-To: <6934efce05020210343e3841ec@mail.gmail.com>
References: <Pine.LNX.4.58.0501260841380.3222@phoenix.infradead.org> 
	<Pine.LNX.4.58.0501280817330.11160@phoenix.infradead.org> 
	<1106903029.21196.216.camel@tglx.tec.linutronix.de> 
	<Pine.LNX.4.58.0501280914580.11160@phoenix.infradead.org> 
	<Pine.LNX.4.58.0501281855370.11160@phoenix.infradead.org> 
	<1107111514.18794.37.camel@sauron.oktetlabs.ru>
	<6934efce05013108463a4d42e4@mail.gmail.com>
	<Pine.LNX.4.58.0501311804550.17207@phoenix.infradead.org> 
	<1107276561.21196.457.camel@tglx.tec.linutronix.de> 
	<Pine.LNX.4.58.0502021544380.29798@phoenix.infradead.org>
	<6934efce05020210343e3841ec@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0502031054200.29798@phoenix.infradead.org>

Jared Hulbert wrote:
> What do you mean by in-core?

This is the term used in JFFS2. All objects which JFFS2 allocates in RAM 
are divided on two groups: in-core objects and other.

In-core are those objects which must be allocated in order to mount to 
JFFS2 and work with it. So, the in-core memory is the memory which JFFS2 
consumes when it is mounted irrespective of whether one work with it or 
not.

For example, to mount 1GiB JFFS2 partition full of data one need, say, 5 
MiB RAM. Once you have mounted JFFS2, these 5 MiB will be consumed forever 
(until you unmount it). To open files and lookup directories JFFS2 needs 
more RAM. But this RAM is freed when, roughly speaking, you close your 
files.

So, the major JFFS2 drawback is that its in-core RAM consumption depends 
linearly on the amount of data you store *on flash*. And I'm trying to 
find the way to relax this.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From jonas.holmberg at axis.com  Thu Feb  3 05:55:05 2005
From: jonas.holmberg at axis.com (Jonas Holmberg)
Date: Thu, 3 Feb 2005 11:55:05 +0100
Subject: Device ID collision in amd_flash.c
In-Reply-To: <1107426233.12383.46.camel@localhost.localdomain>
References: <20050202110715.GH27015@axis.com> <20050203095842.GA20345@axis.com>
	<1107426233.12383.46.camel@localhost.localdomain>
Message-ID: <20050203105505.GB20345@axis.com>

On Thu, Feb 03, 2005 at 10:23:52AM +0000, David Woodhouse wrote:
> On Thu, 2005-02-03 at 10:58 +0100, Jonas Holmberg wrote:
> > Silly me, who cares about obsolete drivers...
> > Let me rephrase that question: Any objections before I commit on 
> > friday (tomorrow)?
> 
> Sorry, go ahead.

Thanks.

> 
> > I still would like to know how bugfixes finds their way into Linux 
> > 2.4. As I understand, the main trunk in CVS is for 2.6 and I can't 
> > find any 2.4-branch...
> 
> In general, they don't get in to 2.4. Nobody cares about 2.4 any more.
> If it _works_ for you, all well and good. But if it hasn't already been
> working for you for a year, then why are you trying to make it work now?

I just noticed the bug. It only reveals itself when you try to erase 
the first sector on that particular chip, and we never had to do that, 
until now.

> Use 2.6.

Will do, but need bugfix for old stuff too.

It would be quite nice with a 2.4-branch that we can commit bugfixes 
to that could be sent to Marcelo regularly.  But if I'm the first to 
ask, we probably don't need it.

> 
> Feel free to send this change to Marcelo if you really care.

OK.

/Jonas



From dwmw2 at infradead.org  Thu Feb  3 06:24:37 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 03 Feb 2005 11:24:37 +0000
Subject: Device ID collision in amd_flash.c
In-Reply-To: <20050203105505.GB20345@axis.com>
References: <20050202110715.GH27015@axis.com> <20050203095842.GA20345@axis.com>
	<1107426233.12383.46.camel@localhost.localdomain>
	<20050203105505.GB20345@axis.com>
Message-ID: <1107429877.19262.258.camel@hades.cambridge.redhat.com>

On Thu, 2005-02-03 at 11:55 +0100, Jonas Holmberg wrote:
> It would be quite nice with a 2.4-branch that we can commit bugfixes 
> to that could be sent to Marcelo regularly.  But if I'm the first to 
> ask, we probably don't need it.

We have one for JFFS2. For the MTD code we probably don't need it.

-- 
dwmw2




From andrew at sanpeople.com  Thu Feb  3 09:08:25 2005
From: andrew at sanpeople.com (Andrew Victor)
Date: 03 Feb 2005 16:08:25 +0200
Subject: JFFS2_FS_WRITEBUFFER config option
Message-ID: <1107439704.32168.66.camel@fuzzie.sanpeople.com>

hi,

As per discussions on IRC, this patch replaces the current
CONFIG_JFFS2_FS_NAND, CONFIG_JFFS2_FS_NOR_ECC and
CONFIG_JFFS2_FS_DATAFLASH with a single configuration option - 
CONFIG_JFFS2_FS_WRITEBUFFER.

This patch applies on top of the two previously posted DataFlash
patches.

The only functional change of this patch is that the slower div/mod
calculations for SECTOR_ADDR(), PAGE_DIV() and PAGE_MOD() are now always
used.


Regards,
  Andrew Victor


diff -urN -x CVS mtd/fs/Config.in mtd.new/fs/Config.in
--- mtd/fs/Config.in	Thu Jan 27 19:23:32 2005
+++ mtd.new/fs/Config.in	Thu Feb  3 14:56:12 2005
@@ -6,8 +6,7 @@
 dep_tristate 'Journalling Flash File System v2 (JFFS2) support' CONFIG_JFFS2_FS $CONFIG_MTD
 if [ "$CONFIG_JFFS2_FS" = "y" -o "$CONFIG_JFFS2_FS" = "m" ] ; then
    int 'JFFS2 debugging verbosity (0 = quiet, 2 = noisy)' CONFIG_JFFS2_FS_DEBUG 0
-   bool 'JFFS2 support for NAND chips' CONFIG_JFFS2_FS_NAND
-   bool 'JFFS2 support for DataFlash' CONFIG_JFFS2_FS_DATAFLASH
+   bool 'JFFS2 write-buffering support' CONFIG_JFFS2_FS_WRITEBUFFER
    bool 'JFFS2 ZLIB compression support (recommended)' CONFIG_JFFS2_ZLIB
    bool 'JFFS2 RTIME compression support (recommended)' CONFIG_JFFS2_RTIME
    bool 'JFFS2 RUBIN compression support' CONFIG_JFFS2_RUBIN
diff -urN -x CVS mtd/fs/Kconfig mtd.new/fs/Kconfig
--- mtd/fs/Kconfig	Tue Feb  1 09:35:12 2005
+++ mtd.new/fs/Kconfig	Thu Feb  3 15:07:51 2005
@@ -51,38 +51,18 @@
 	  If reporting bugs, please try to have available a full dump of the
 	  messages at debug level 1 while the misbehaviour was occurring.
 
-config JFFS2_FS_NAND
-	bool "JFFS2 support for NAND flash (EXPERIMENTAL)"
-	depends on JFFS2_FS && EXPERIMENTAL
-	default n
+config JFFS2_FS_WRITEBUFFER
+	bool "JFFS2 write-buffering support"
+	depends on JFFS2_FS
+	default y
 	help
-	  This enables the experimental support for NAND flash in JFFS2. NAND
-	  is a newer type of flash chip design than the traditional NOR flash,
-	  with higher density but a handful of characteristics which make it
-	  more interesting for the file system to use. Support for NAND flash
-	  is not yet complete and may corrupt data. For further information,
-	  including a link to the mailing list where details of the remaining
-	  work to be completed for NAND flash support can be found, see the 
-	  JFFS2 web site at <http://sources.redhat.com/jffs2>.
+	  This enables the write-buffering support in JFFS2.
 
-	  Say 'N' unless you have NAND flash and you are willing to test and
-	  develop JFFS2 support for it.
-
-config JFFS2_FS_NOR_ECC
-	bool "JFFS2 support for ECC'd NOR flash (EXPERIMENTAL)"
-	   depends on JFFS2_FS && EXPERIMENTAL
-	   default n
-	   help
-	     This enables the experimental support for NOR flash with transparent
-		 ECC for JFFS2.  This type of flash chip is not common, however it is
-		 available from STMicro.
-
-config JFFS2_FS_DATAFLASH
-	bool "JFFS2 support for DataFlash (EXPERIMENTAL)"
-	depends on JFFS2_FS && EXPERIMENTAL
-	default n
-	help
-	  This enables the experimental support for JFFS2 on DataFlash devices.
+	  This functionality is required to support JFFS2 on the following
+	  types of flash devices:
+	    - NAND flash
+	    - NOR flash with transparent ECC
+	    - DataFlash
 
 config JFFS2_COMPRESSION_OPTIONS
 	bool "Advanced compression options for JFFS2"
diff -urN -x CVS mtd/fs/jffs2/Makefile.24 mtd.new/fs/jffs2/Makefile.24
--- mtd/fs/jffs2/Makefile.24	Thu Jan 27 19:24:55 2005
+++ mtd.new/fs/jffs2/Makefile.24	Thu Feb  3 15:02:21 2005
@@ -29,14 +29,13 @@
 
 LINUX_OBJS += super-v24.o crc32.o rbtree.o
 
-NAND_OBJS-$(CONFIG_JFFS2_FS_NAND) += wbuf.o
-NAND_OBJS-$(CONFIG_JFFS2_FS_DATAFLASH) += wbuf.o
+WBUF_OBJS-$(CONFIG_JFFS2_FS_WRITEBUFFER) += wbuf.o
 
 COMPR_OBJS-$(CONFIG_JFFS2_RUBIN)  += compr_rubin.o
 COMPR_OBJS-$(CONFIG_JFFS2_RTIME)  += compr_rtime.o
 COMPR_OBJS-$(CONFIG_JFFS2_ZLIB)   += compr_zlib.o
 
-obj-y := $(COMPR_OBJS-y) $(JFFS2_OBJS) $(LINUX_OBJS) $(NAND_OBJS-y)
+obj-y := $(COMPR_OBJS-y) $(JFFS2_OBJS) $(LINUX_OBJS) $(WBUF_OBJS-y)
 O_TARGET := jffs2.o
 
 include $(TOPDIR)/Rules.make
diff -urN -x CVS mtd/fs/jffs2/Makefile.common mtd.new/fs/jffs2/Makefile.common
--- mtd/fs/jffs2/Makefile.common	Mon Jan 31 14:33:12 2005
+++ mtd.new/fs/jffs2/Makefile.common	Thu Feb  3 15:09:22 2005
@@ -11,9 +11,7 @@
 jffs2-y	+= symlink.o build.o erase.o background.o fs.o writev.o
 jffs2-y	+= super.o
 
-jffs2-$(CONFIG_JFFS2_FS_NAND)	+= wbuf.o
-jffs2-$(CONFIG_JFFS2_FS_NOR_ECC) += wbuf.o
-jffs2-$(CONFIG_JFFS2_FS_DATAFLASH) += wbuf.o
+jffs2-$(CONFIG_JFFS2_FS_WRITEBUFFER)	+= wbuf.o
 jffs2-$(CONFIG_JFFS2_RUBIN)	+= compr_rubin.o
 jffs2-$(CONFIG_JFFS2_RTIME)	+= compr_rtime.o
 jffs2-$(CONFIG_JFFS2_ZLIB)	+= compr_zlib.o
diff -urN -x CVS mtd/fs/jffs2/defconfig mtd.new/fs/jffs2/defconfig
--- mtd/fs/jffs2/defconfig	Tue May 27 11:35:22 2003
+++ mtd.new/fs/jffs2/defconfig	Thu Feb  3 15:03:21 2005
@@ -2,7 +2,7 @@
 
 CONFIG_JFFS2_FS=m
 ifdef NONAND
-CONFIG_JFFS2_FS_NAND=n
+CONFIG_JFFS2_FS_WRITEBUFFER=n
 else
-CONFIG_JFFS2_FS_NAND=y
+CONFIG_JFFS2_FS_WRITEBUFFER=y
 endif
diff -urN -x CVS mtd/fs/jffs2/ecos/cdl/jffs2.cdl mtd.new/fs/jffs2/ecos/cdl/jffs2.cdl
--- mtd/fs/jffs2/ecos/cdl/jffs2.cdl	Wed Jan 26 16:08:00 2005
+++ mtd.new/fs/jffs2/ecos/cdl/jffs2.cdl	Thu Feb  3 15:08:30 2005
@@ -132,7 +132,7 @@
     cdl_option CYGOPT_FS_JFFS2_NAND {
 	display         "Support for NAND flash"
 	flavor          bool
-	define          CONFIG_JFFS2_FS_NAND
+	define          CONFIG_JFFS2_FS_WRITEBUFFER
 	compile         wbuf.c
         requires        0
         description     "
diff -urN -x CVS mtd/fs/jffs2/ecos/src/os-ecos.h mtd.new/fs/jffs2/ecos/src/os-ecos.h
--- mtd/fs/jffs2/ecos/src/os-ecos.h	Wed Jan 26 16:08:01 2005
+++ mtd.new/fs/jffs2/ecos/src/os-ecos.h	Thu Feb  3 15:08:55 2005
@@ -196,7 +196,7 @@
 static inline void jffs2_erase_pending_trigger(struct jffs2_sb_info *c)
 { }
 
-#ifndef CONFIG_JFFS2_FS_NAND
+#ifndef CONFIG_JFFS2_FS_WRITEBUFFER
 #define jffs2_can_mark_obsolete(c) (1)
 #define jffs2_cleanmarker_oob(c) (0)
 #define jffs2_write_nand_cleanmarker(c,jeb) (-EIO)
diff -urN -x CVS mtd/fs/jffs2/fs.c mtd.new/fs/jffs2/fs.c
--- mtd/fs/jffs2/fs.c	Fri Jan 28 12:16:15 2005
+++ mtd.new/fs/jffs2/fs.c	Thu Feb  3 15:03:53 2005
@@ -449,13 +449,11 @@
 
 	c = JFFS2_SB_INFO(sb);
 
-#ifndef CONFIG_JFFS2_FS_NAND
+#ifndef CONFIG_JFFS2_FS_WRITEBUFFER
 	if (c->mtd->type == MTD_NANDFLASH) {
 		printk(KERN_ERR "jffs2: Cannot operate on NAND flash unless jffs2 NAND support is compiled in.\n");
 		return -EINVAL;
 	}
-#endif
-#ifndef CONFIG_JFFS2_FS_DATAFLASH
 	if (c->mtd->type == MTD_DATAFLASH) {
 		printk(KERN_ERR "jffs2: Cannot operate on DataFlash unless jffs2 DataFlash support is compiled in.\n");
 		return -EINVAL;
diff -urN -x CVS mtd/fs/jffs2/nodelist.h mtd.new/fs/jffs2/nodelist.h
--- mtd/fs/jffs2/nodelist.h	Wed Jan 26 16:07:57 2005
+++ mtd.new/fs/jffs2/nodelist.h	Thu Feb  3 15:07:38 2005
@@ -463,7 +463,7 @@
 void jffs2_erase_block(struct jffs2_sb_info *c, struct jffs2_eraseblock *jeb);
 void jffs2_erase_pending_blocks(struct jffs2_sb_info *c, int count);
 
-#ifdef CONFIG_JFFS2_FS_NAND
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 /* wbuf.c */
 int jffs2_flush_wbuf_gc(struct jffs2_sb_info *c, uint32_t ino);
 int jffs2_flush_wbuf_pad(struct jffs2_sb_info *c);
diff -urN -x CVS mtd/fs/jffs2/os-linux.h mtd.new/fs/jffs2/os-linux.h
--- mtd/fs/jffs2/os-linux.h	Wed Feb  2 18:48:25 2005
+++ mtd.new/fs/jffs2/os-linux.h	Thu Feb  3 15:23:28 2005
@@ -97,16 +97,12 @@
 #endif
 }
 
-#ifdef CONFIG_JFFS2_FS_DATAFLASH
-#define SECTOR_ADDR(x) ( ((unsigned long)(x) / (unsigned long)(c->sector_size)) * c->sector_size )
-#else
-#define SECTOR_ADDR(x) ( ((unsigned long)(x) & ~(c->sector_size-1)) )
-#endif
 
 #define jffs2_is_readonly(c) (OFNI_BS_2SFFJ(c)->s_flags & MS_RDONLY)
 #define jffs2_is_writebuffered(c) (c->wbuf != NULL)
 
-#if (!defined CONFIG_JFFS2_FS_NAND && !defined CONFIG_JFFS2_FS_NOR_ECC && !defined CONFIG_JFFS2_FS_DATAFLASH)
+#ifndef CONFIG_JFFS2_FS_WRITEBUFFER
+#define SECTOR_ADDR(x) ( ((unsigned long)(x) & ~(c->sector_size-1)) )
 #define jffs2_can_mark_obsolete(c) (1)
 #define jffs2_cleanmarker_oob(c) (0)
 #define jffs2_write_nand_cleanmarker(c,jeb) (-EIO)
@@ -129,6 +125,7 @@
 
 #else /* NAND and/or ECC'd NOR support present */
 
+#define SECTOR_ADDR(x) ( ((unsigned long)(x) / (unsigned long)(c->sector_size)) * c->sector_size )
 #define jffs2_can_mark_obsolete(c) ((c->mtd->type == MTD_NORFLASH && !(c->mtd->flags & MTD_ECC)) || c->mtd->type == MTD_RAM)
 #define jffs2_cleanmarker_oob(c) (c->mtd->type == MTD_NANDFLASH)
 
@@ -150,25 +147,16 @@
 int jffs2_flush_wbuf_pad(struct jffs2_sb_info *c);
 int jffs2_nand_flash_setup(struct jffs2_sb_info *c);
 void jffs2_nand_flash_cleanup(struct jffs2_sb_info *c);
-#ifdef CONFIG_JFFS2_FS_NOR_ECC
+
 #define jffs2_nor_ecc(c) (c->mtd->type == MTD_NORFLASH && (c->mtd->flags & MTD_ECC))
 int jffs2_nor_ecc_flash_setup(struct jffs2_sb_info *c);
 void jffs2_nor_ecc_flash_cleanup(struct jffs2_sb_info *c);
-#else
-#define jffs2_nor_ecc(c) (0)
-#define jffs2_nor_ecc_flash_setup(c) (0)
-#define jffs2_nor_ecc_flash_cleanup(c) do {} while (0)
-#endif /* NOR ECC */
-#ifdef CONFIG_JFFS2_FS_DATAFLASH
+
 #define jffs2_dataflash(c) (c->mtd->type == MTD_DATAFLASH)
 int jffs2_dataflash_setup(struct jffs2_sb_info *c);
 void jffs2_dataflash_cleanup(struct jffs2_sb_info *c);
-#else
-#define jffs2_dataflash(c) (0)
-#define jffs2_dataflash_setup(c) (0)
-#define jffs2_dataflash_cleanup(c) do {} while (0)
-#endif /* DATAFLASH */
-#endif /* NAND */
+
+#endif /* WRITEBUFFER */
 
 /* erase.c */
 static inline void jffs2_erase_pending_trigger(struct jffs2_sb_info *c)
diff -urN -x CVS mtd/fs/jffs2/scan.c mtd.new/fs/jffs2/scan.c
--- mtd/fs/jffs2/scan.c	Fri Jan 28 11:36:06 2005
+++ mtd.new/fs/jffs2/scan.c	Thu Feb  3 15:14:48 2005
@@ -68,7 +68,7 @@
 static inline int min_free(struct jffs2_sb_info *c)
 {
 	uint32_t min = 2 * sizeof(struct jffs2_raw_inode);
-#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 	if (!jffs2_can_mark_obsolete(c) && min < c->wbuf_pagesize)
 		return c->wbuf_pagesize;
 #endif
@@ -228,7 +228,7 @@
 		c->dirty_size -= c->nextblock->dirty_size;
 		c->nextblock->dirty_size = 0;
 	}
-#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 	if (!jffs2_can_mark_obsolete(c) && c->nextblock && (c->nextblock->free_size & (c->wbuf_pagesize-1))) {
 		/* If we're going to start writing into a block which already 
 		   contains data, and the end of the data isn't page-aligned,
@@ -294,7 +294,7 @@
 	uint32_t hdr_crc, buf_ofs, buf_len;
 	int err;
 	int noise = 0;
-#ifdef CONFIG_JFFS2_FS_NAND
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 	int cleanmarkerfound = 0;
 #endif
 
@@ -303,7 +303,7 @@
 
 	D1(printk(KERN_DEBUG "jffs2_scan_eraseblock(): Scanning block at 0x%x\n", ofs));
 
-#ifdef CONFIG_JFFS2_FS_NAND
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 	if (jffs2_cleanmarker_oob(c)) {
 		int ret = jffs2_check_nand_cleanmarker(c, jeb);
 		D2(printk(KERN_NOTICE "jffs_check_nand_cleanmarker returned %d\n",ret));
@@ -338,7 +338,7 @@
 		ofs += 4;
 
 	if (ofs == EMPTY_SCAN_SIZE(c->sector_size)) {
-#ifdef CONFIG_JFFS2_FS_NAND
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 		if (jffs2_cleanmarker_oob(c)) {
 			/* scan oob, take care of cleanmarker */
 			int ret = jffs2_check_oob_empty(c, jeb, cleanmarkerfound);
diff -urN -x CVS mtd/fs/jffs2/super-v24.c mtd.new/fs/jffs2/super-v24.c
--- mtd/fs/jffs2/super-v24.c	Wed Jan 26 16:07:58 2005
+++ mtd.new/fs/jffs2/super-v24.c	Thu Feb  3 15:06:27 2005
@@ -110,7 +110,7 @@
 	int ret;
 
 	printk(KERN_INFO "JFFS2 version 2.2."
-#ifdef CONFIG_JFFS2_FS_NAND
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 	       " (NAND)"
 #endif
 	       " (C) 2001-2003 Red Hat, Inc.\n");
diff -urN -x CVS mtd/fs/jffs2/super.c mtd.new/fs/jffs2/super.c
--- mtd/fs/jffs2/super.c	Wed Jan 26 16:07:58 2005
+++ mtd.new/fs/jffs2/super.c	Thu Feb  3 15:05:58 2005
@@ -309,7 +309,7 @@
 	int ret;
 
 	printk(KERN_INFO "JFFS2 version 2.2."
-#ifdef CONFIG_JFFS2_FS_NAND
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 	       " (NAND)"
 #endif
 	       " (C) 2001-2003 Red Hat, Inc.\n");
diff -urN -x CVS mtd/fs/jffs2/wbuf.c mtd.new/fs/jffs2/wbuf.c
--- mtd/fs/jffs2/wbuf.c	Tue Feb  1 09:38:41 2005
+++ mtd.new/fs/jffs2/wbuf.c	Thu Feb  3 15:22:17 2005
@@ -598,7 +598,7 @@
 	return ret;
 }
 
-#ifdef CONFIG_JFFS2_FS_DATAFLASH
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 #define PAGE_DIV(x) ( ((unsigned long)(x) / (unsigned long)(c->wbuf_pagesize)) * (unsigned long)(c->wbuf_pagesize) )
 #define PAGE_MOD(x) ( (unsigned long)(x) % (unsigned long)(c->wbuf_pagesize) )
 #else
@@ -1189,7 +1189,6 @@
 	kfree(c->wbuf);
 }
 
-#ifdef CONFIG_JFFS2_FS_DATAFLASH
 int jffs2_dataflash_setup(struct jffs2_sb_info *c) {
 	c->cleanmarker_size = 0;		/* No cleanmarkers needed */
 	
@@ -1210,9 +1209,7 @@
 void jffs2_dataflash_cleanup(struct jffs2_sb_info *c) {
 	kfree(c->wbuf);
 }
-#endif
 
-#ifdef CONFIG_JFFS2_FS_NOR_ECC
 int jffs2_nor_ecc_flash_setup(struct jffs2_sb_info *c) {
 	/* Cleanmarker is actually larger on the flashes */
 	c->cleanmarker_size = 16;
@@ -1232,4 +1229,3 @@
 void jffs2_nor_ecc_flash_cleanup(struct jffs2_sb_info *c) {
 	kfree(c->wbuf);
 }
-#endif
diff -urN -x CVS mtd/include/linux/config.h mtd.new/include/linux/config.h
--- mtd/include/linux/config.h	Sat Jul 10 23:14:18 2004
+++ mtd.new/include/linux/config.h	Thu Feb  3 15:25:31 2005
@@ -35,7 +35,7 @@
 #endif /* MTD_OUT_OF_TREE */
 
 #ifndef NONAND
-#define CONFIG_JFFS2_FS_NAND 1
+#define CONFIG_JFFS2_FS_WRITEBUFFER 1
 #endif
 
 #endif /* __MTD_CONFIG_H__ */
diff -urN -x CVS mtd/include/linux/jffs2_fs_sb.h mtd.new/include/linux/jffs2_fs_sb.h
--- mtd/include/linux/jffs2_fs_sb.h	Fri Jan 28 11:31:51 2005
+++ mtd.new/include/linux/jffs2_fs_sb.h	Thu Feb  3 15:24:34 2005
@@ -94,7 +94,7 @@
 	   to an obsoleted node. I don't like this. Alternatives welcomed. */
 	struct semaphore erase_free_sem;
 
-#if defined CONFIG_JFFS2_FS_NAND || defined CONFIG_JFFS2_FS_NOR_ECC || defined CONFIG_JFFS2_FS_DATAFLASH
+#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 	/* Write-behind buffer for NAND flash */
 	unsigned char *wbuf;
 	uint32_t wbuf_ofs;
diff -urN -x CVS mtd/patches/Configure.help mtd.new/patches/Configure.help
--- mtd/patches/Configure.help	Tue Aug 19 11:24:36 2003
+++ mtd.new/patches/Configure.help	Thu Feb  3 15:27:22 2005
@@ -829,8 +829,13 @@
   If reporting bugs, please try to have available a full dump of the
   messages at debug level 1 while the misbehaviour was occurring.
 
-CONFIG_JFFS2_FS_NAND
-  Enables JFFS2 support for NAND FLASH.
+CONFIG_JFFS2_FS_WRITEBUFFER
+  This enables the write-buffering support in JFFS2.
+  This functionality is required to support JFFS2 on the following
+  types of flash devices:
+    - NAND flash
+    - NOR flash with transparent ECC
+    - DataFlash
 
 Flash chip mapping on the Flaga Digital Module
 CONFIG_MTD_CFI_FLAGADM






From jdub at us.ibm.com  Thu Feb  3 09:13:41 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Thu, 03 Feb 2005 08:13:41 -0600
Subject: Device ID collision in amd_flash.c
In-Reply-To: <1107429877.19262.258.camel@hades.cambridge.redhat.com>
References: <20050202110715.GH27015@axis.com> <20050203095842.GA20345@axis.com>
	<1107426233.12383.46.camel@localhost.localdomain>
	<20050203105505.GB20345@axis.com>
	<1107429877.19262.258.camel@hades.cambridge.redhat.com>
Message-ID: <1107440021.7780.0.camel@windu.rchland.ibm.com>

On Thu, 2005-02-03 at 11:24 +0000, David Woodhouse wrote:
> On Thu, 2005-02-03 at 11:55 +0100, Jonas Holmberg wrote:
> > It would be quite nice with a 2.4-branch that we can commit bugfixes 
> > to that could be sent to Marcelo regularly.  But if I'm the first to 
> > ask, we probably don't need it.
> 
> We have one for JFFS2. For the MTD code we probably don't need it.

Unless you finally get around to removing all the inter_module_* stuff
and use symbol_{get,put}... ;)

josh




From rudi at unsec.nl  Fri Feb  4 06:43:58 2005
From: rudi at unsec.nl (Rudi Engelbertink)
Date: Fri, 4 Feb 2005 12:43:58 +0100
Subject: unable to get NAND oobinfo
Message-ID: <20050204112622.M33820@unsec.nl>

Hi,

trying to get my nand driver (for compulab 586core board) on kernel 2.4.27
working, i ran into the following problem:
The driver is recognised and appears to work. That means I can read the mtdchar
device but whin I'm trying to format the device, I recieve the message
'flash_eraseall: /dev/mtd3: unable to get NAND oobinfo'
An strace replies with:
open("/dev/mtd3", O_RDWR)               = 3
ioctl(3, 0x80204d01, 0xbffffdf0)        = 0
ioctl(3, 0x80c84d0a, 0xbffffd20)        = -1 ENOTTY (Inappropriate ioctl for
device)
At that moment it does an ioctl(fd, MEMGETOOBSEL, &oobinfo) but it looks
like the device is not registered properly.

NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MB 3,3V)

On the mailing list I found an email with the same question about this but no
answer.
Could you give me a hint about what is going wrong or a posible solution.

RGDS Rudi.
-- 
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
   Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8




From dedekind at infradead.org  Fri Feb  4 06:58:33 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 4 Feb 2005 11:58:33 +0000 (GMT)
Subject: unable to get NAND oobinfo
In-Reply-To: <20050204112622.M33820@unsec.nl>
References: <20050204112622.M33820@unsec.nl>
Message-ID: <Pine.LNX.4.58.0502041157560.29798@phoenix.infradead.org>

What does cat /proc/mtd say ?

On Fri, 4 Feb 2005, Rudi Engelbertink wrote:
> Hi,
> 
> trying to get my nand driver (for compulab 586core board) on kernel 2.4.27
> working, i ran into the following problem:
> The driver is recognised and appears to work. That means I can read the mtdchar
> device but whin I'm trying to format the device, I recieve the message
> 'flash_eraseall: /dev/mtd3: unable to get NAND oobinfo'
> An strace replies with:
> open("/dev/mtd3", O_RDWR)               = 3
> ioctl(3, 0x80204d01, 0xbffffdf0)        = 0
> ioctl(3, 0x80c84d0a, 0xbffffd20)        = -1 ENOTTY (Inappropriate ioctl for
> device)
> At that moment it does an ioctl(fd, MEMGETOOBSEL, &oobinfo) but it looks
> like the device is not registered properly.
> 
> NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MB 3,3V)
> 
> On the mailing list I found an email with the same question about this but no
> answer.
> Could you give me a hint about what is going wrong or a posible solution.
> 
> RGDS Rudi.
> -- 
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety.
>    Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
> GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From rudi at unsec.nl  Fri Feb  4 07:00:35 2005
From: rudi at unsec.nl (Rudi Engelbertink)
Date: Fri, 4 Feb 2005 13:00:35 +0100
Subject: unable to get NAND oobinfo
In-Reply-To: <Pine.LNX.4.58.0502041157560.29798@phoenix.infradead.org>
References: <20050204112622.M33820@unsec.nl>
	<Pine.LNX.4.58.0502041157560.29798@phoenix.infradead.org>
Message-ID: <20050204120004.M34991@unsec.nl>

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000e0000 00010000 "cl586nor Dos Low"
mtd1: 00100000 00010000 "cl586nor Dos High"
mtd2: 00020000 00010000 "cl586nor BIOS"
mtd3: 04000000 00004000 "cl586core NAND FS 0"

On Fri, 4 Feb 2005 11:58:33 +0000 (GMT), Artem B. Bityuckiy wrote
> What does cat /proc/mtd say ?
> 
> On Fri, 4 Feb 2005, Rudi Engelbertink wrote:
> > Hi,
> > 
> > trying to get my nand driver (for compulab 586core board) on kernel 2.4.27
> > working, i ran into the following problem:
> > The driver is recognised and appears to work. That means I can read the
mtdchar
> > device but whin I'm trying to format the device, I recieve the message
> > 'flash_eraseall: /dev/mtd3: unable to get NAND oobinfo'
> > An strace replies with:
> > open("/dev/mtd3", O_RDWR)               = 3
> > ioctl(3, 0x80204d01, 0xbffffdf0)        = 0
> > ioctl(3, 0x80c84d0a, 0xbffffd20)        = -1 ENOTTY (Inappropriate ioctl for
> > device)
> > At that moment it does an ioctl(fd, MEMGETOOBSEL, &oobinfo) but it looks
> > like the device is not registered properly.
> > 
> > NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MB 3,3V)
> > 
> > On the mailing list I found an email with the same question about this but no
> > answer.
> > Could you give me a hint about what is going wrong or a posible solution.
> > 
> > RGDS Rudi.
> > -- 
> > They that can give up essential liberty to obtain a little temporary
> > safety deserve neither liberty nor safety.
> >    Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
> > GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8
> > 
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
> 
> --
> Best Regards,
> Artem B. Bityuckiy,
> St.-Petersburg, Russia.


--
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
   Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB  A962 0A75 7F9B 07A1 83E8




From jsteve17 at yahoo.com  Fri Feb  4 11:18:31 2005
From: jsteve17 at yahoo.com (Jeff Stevens)
Date: Fri, 4 Feb 2005 08:18:31 -0800 (PST)
Subject: MTD JFFS2 Problems
Message-ID: <20050204161831.32323.qmail@web41406.mail.yahoo.com>

I am trying to create a jffs2 filesystem, and it seems
to be very flakey.  I have tried creating a jffs2
filesystem using mkfs.jffs2 and then copy it directly
to /dev/mtd0, but when I try to mount it I get a bunch
of errors, and when it finally mounts, the filesystem
acts weird.  So now I am trying a different approach,
where I mount an erased mtdblock0 as jffs2 and then
untar a filesystem on the mounted device.  However,
when I do this it seems to crap out at various points
in the filesystem (I have tried it many times).  Here
is a screen dump:

[root at gtvme ~]# mount -t jffs2 /dev/mtdblock0
/mnt/root
[root at gtvme ~]# cd /mnt/root/
[root at gtvme root]# ls
./  ../
[root at gtvme root]# tar xf /gtvmefs.tar
Write of 1170 bytes at 0x01fa000c failed. returned
-30, retlen 374
Write of 1170 bytes at 0x01fa04a0 failed. returned
-30, retlen 288
Write of 1170 bytes at 0x01fa0934 failed. returned
-30, retlen 740
Write of 2765 bytes at 0x01fa125c failed. returned
-30, retlen 326
Write of 2765 bytes at 0x01fa1d2c failed. returned
-30, retlen 1032
Write of 2765 bytes at 0x01fa27fc failed. returned
-30, retlen 862
Write of 2765 bytes at 0x01fa32cc failed. returned
-30, retlen 116
tar: Write Error: Read-only file system
tar: Invalid tar magic
[root at gtvme root]# Write clean marker to block at
0x00a20000 failed: -30
Write clean marker to block at 0x00820000 failed: -30


I'm not sure what I'm doing wrong.  I seem to be able
to copy things to flash just fine using dd, and
flashcp.  Please help!

Thanks,
   Jeff Stevens


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250



From rgadams at cox.net  Fri Feb  4 13:12:18 2005
From: rgadams at cox.net (Rick Adams)
Date: Fri, 4 Feb 2005 10:12:18 -0800
Subject: MTD JFFS2 Problems 
In-Reply-To: <E1Cx6oS-0004DA-Fy@canuck.infradead.org>
References: <E1Cx6oS-0004DA-Fy@canuck.infradead.org>
Message-ID: <200502041012.18287.rgadams@cox.net>

On Friday 04 February 2005 09:00 am, linux-mtd-request at lists.infradead.org 
wrote:
> Date: Fri, 4 Feb 2005 08:18:31 -0800 (PST)
From: Jeff Stevens <jsteve17 at yahoo.com>
>Subject: MTD JFFS2 Problems
>To: linux-mtd at lists.infradead.org
>Message-ID: <20050204161831.32323.qmail at web41406.mail.yahoo.com>
>
>
>[root at gtvme root]# Write clean marker to block at
>0x00a20000 failed: -30
>Write clean marker to block at 0x00820000 failed: -30
>
I had a client that was experiencing the CLEANMARKER errors at boot (mount of 
the jffs2 root  filesystem). The problem was related to using the host 
version of mkfs.jffs2 tool when they should have been using the target 
version. They were also experiencing several other "weird" operations. This 
issue is only applicable in a cross development environment. Unfortunately 
Jeff, you did not give us enough information for me to tell what's going on. 
Hope this helps.
-- 
Rick Adams
rick at theptrgroup.com






From bhe at jadechip.com  Fri Feb  4 21:20:14 2005
From: bhe at jadechip.com (stiger)
Date: Sat, 05 Feb 2005 02:20:14 -0000
Subject: flash unlock on VPB
Message-ID: <001501c3eb8f$1e9cf780$33050a0a@jadechip.net>

hello,

i'm using VPB + kernel 2.6.9
but i found the flash cannot write, it should be unlocked first.

if not use root filesystem in flash, I can use flash_unlock to unlock the
flash.
but if burn root filesystem into flash, i have to change the kernel code.

i add these code at driver/mtd/mtdpart.c->add_mtd_partitions()

        if((slave->mtd.flags & MTD_WRITEABLE) && slave->mtd.unlock ){
            slave->mtd.unlock(&(slave->mtd), 0, slave->mtd.size );
        }

now, it works.
but i think it's a stupid way to do this.
is there any other way to do this ?

From nico at cam.org  Fri Feb  4 21:39:10 2005
From: nico at cam.org (Nicolas Pitre)
Date: Fri, 4 Feb 2005 21:39:10 -0500 (EST)
Subject: flash unlock on VPB
In-Reply-To: <001501c3eb8f$1e9cf780$33050a0a@jadechip.net>
References: <001501c3eb8f$1e9cf780$33050a0a@jadechip.net>
Message-ID: <Pine.LNX.4.61.0502042136340.25997@localhost.localdomain>

On Thu, 5 Feb 2004, stiger wrote:

> hello,
> 
> i'm using VPB + kernel 2.6.9
> but i found the flash cannot write, it should be unlocked first.
> 
> if not use root filesystem in flash, I can use flash_unlock to unlock the
> flash.
> but if burn root filesystem into flash, i have to change the kernel code.
> 
> i add these code at driver/mtd/mtdpart.c->add_mtd_partitions()
> 
>         if((slave->mtd.flags & MTD_WRITEABLE) && slave->mtd.unlock ){
>             slave->mtd.unlock(&(slave->mtd), 0, slave->mtd.size );
>         }
> 
> now, it works.
> but i think it's a stupid way to do this.
> is there any other way to do this ?

The unlock is usually called from the map driver in that case.


Nicolas



From bhe at jadechip.com  Fri Feb  4 22:14:26 2005
From: bhe at jadechip.com (stiger)
Date: Sat, 05 Feb 2005 03:14:26 -0000
Subject: flash unlock on VPB
References: <001501c3eb8f$1e9cf780$33050a0a@jadechip.net>
	<Pine.LNX.4.61.0502042136340.25997@localhost.localdomain>
Message-ID: <004901c3eb96$aff0ee10$33050a0a@jadechip.net>

thx.

Is there any code to real call unlock?

i see many map drivers only set
.mask_flags   =  MTD_WRITEABLE
and then call add_mtd_partitions()
but i didn't see any real unlock in map drivers.

so, how can they do when they want to use writeable root filesystem in flash ?


----- Original Message ----- 
From: "Nicolas Pitre" <nico at cam.org>
To: "stiger" <bhe at jadechip.com>
Cc: <linux-mtd at lists.infradead.org>
Sent: Saturday, February 05, 2005 10:39 AM
Subject: Re: flash unlock on VPB


> On Thu, 5 Feb 2004, stiger wrote:
> 
> > hello,
> > 
> > i'm using VPB + kernel 2.6.9
> > but i found the flash cannot write, it should be unlocked first.
> > 
> > if not use root filesystem in flash, I can use flash_unlock to unlock the
> > flash.
> > but if burn root filesystem into flash, i have to change the kernel code.
> > 
> > i add these code at driver/mtd/mtdpart.c->add_mtd_partitions()
> > 
> >         if((slave->mtd.flags & MTD_WRITEABLE) && slave->mtd.unlock ){
> >             slave->mtd.unlock(&(slave->mtd), 0, slave->mtd.size );
> >         }
> > 
> > now, it works.
> > but i think it's a stupid way to do this.
> > is there any other way to do this ?
> 
> The unlock is usually called from the map driver in that case.
> 
> 
> Nicolas

From martin at egholm-nielsen.dk  Thu Feb  3 04:31:42 2005
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Thu, 03 Feb 2005 10:31:42 +0100
Subject: Writing frequently to NAND - wearing, caching?
Message-ID: <ctsr0r$94m$1@sea.gmane.org>

Hi there,

I have an application which may need to write states frequently to my 
nand-fs in order to have these states in case of powerdown.
But I'm a bit concerned about wearing the nand if I write to frequently.

So, if I only need to write, say, 100 bytes every second, how often will 
this actually be flushed to the nand?
Is there a maximum commit/flush frequency built in the driver? Or can 
this be configured?
I know this is a very diffuse question, but hopefully you get my drift.

BR,
  Martin Egholm




From manningc2 at actrix.gen.nz  Sun Feb  6 17:14:06 2005
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Mon, 7 Feb 2005 11:14:06 +1300
Subject: Writing frequently to NAND - wearing, caching?
In-Reply-To: <ctsr0r$94m$1@sea.gmane.org>
References: <ctsr0r$94m$1@sea.gmane.org>
Message-ID: <20050206220713.D99FE15504@desire.actrix.co.nz>

On Thursday 03 February 2005 22:31, Martin Egholm Nielsen wrote:
> Hi there,
>
> I have an application which may need to write states frequently to my
> nand-fs in order to have these states in case of powerdown.
> But I'm a bit concerned about wearing the nand if I write to frequently.
>
> So, if I only need to write, say, 100 bytes every second, how often will
> this actually be flushed to the nand?
> Is there a maximum commit/flush frequency built in the driver? Or can
> this be configured?
> I know this is a very diffuse question, but hopefully you get my drift.
>
> BR,
>   Martin Egholm

It depends on what fs you're using.

With YAFFS, and I believe JFFS2 too, there is no reason to worry about flash 
"wearing out".  I have done accelerated lifetime tests on NAND using YAFFS 
and in one test wrote 130GB to NAND without any data loss, bad blocks 
happening etc.

The NAND writes whenever the file system tells it to, so again your question 
is FS dependent, but all file systems that are NAND-friendly should handle 
the load you mention with no problems.

-- Charles






From rgadams at cox.net  Sun Feb  6 23:32:05 2005
From: rgadams at cox.net (Rick Adams)
Date: Sun, 6 Feb 2005 20:32:05 -0800
Subject: ST flashes 
In-Reply-To: <E1CwefL-0002c2-JD@canuck.infradead.org>
References: <E1CwefL-0002c2-JD@canuck.infradead.org>
Message-ID: <200502062032.05112.rgadams@cox.net>

On Thursday 03 February 2005 02:56 am, linux-mtd-request at lists.infradead.org 
wrote:

>Im using 2.4.19-rmk7-pxa1 ... i know its really old and all 
>that ... but i have no options right now...
>but anyway..
<Here's my problem.
>I have two pxa 255 boards , one with ST flash and one with AMD.
>I configured them to use the lubbock flash driver , and made one 
>partition for jffs2.

>But on the ST , the moment you power down the board ! , the next time , 
>it only mounts , but doesnt
>let me perform any fops. I keep getting I/O errors..for only write 
>operations... read works , coz i could ls in the partition.
>It also doesnt let me format the partition.


Hi Ashwin

What's the part number of the Intel flash, is it a J or K version? The part 
number will look like 28FnnnJ3 where nnn is the size or 28FnnnKvv where nnn 
is size an vv is voltage. These are the part numbers for the TSOP package, 
for the BGA package the first part will be different but will have the J or K 
designation. The J or K designation is the only thing that matters for this 
discussion the rest of the number isn't important. Intel is obsoleting the J 
part and replacing it with the K part. The version of the kernel and the 
Lubbock board were built with J parts (before the K was around). The K is 
"almost" identical to the J. One important difference is the the K part has 
all it's sectors locked at power up and the J has all it's sectors unlocked. 
If you have a driver written for the J and a board with a K part then this 
could lead to the exact problem you talked about.

If this is your situation there are two possible fixes. One is to get a driver 
that understands how to talk to a K, or modify the boot or initialization 
code to unlock all the sector of the K at power up, and then it will function 
exactly like a J. The other main feature the K has is the ability to burst 
read. This will improve some flash operations if the processor supports DMA 
from flash and you modify the boot or initialization code to enable this 
mode. I know the ARM9 core supports it, I don't know offhand if the xScale 
does. Anyhow the point is that the J driver lack of burst mode support only 
has a performance implication and no functional one. The easiest thing is to 
just unlock all flash sectors of the K at power up and use the J driver.

If this isn't your situation (you don't have K parts) then never mind.
-- 
Rick Adams
rick at theptrgroup.com




From martin at egholm-nielsen.dk  Mon Feb  7 03:33:48 2005
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Mon, 07 Feb 2005 09:33:48 +0100
Subject: Writing frequently to NAND - wearing, caching?
In-Reply-To: <20050206220713.D99FE15504@desire.actrix.co.nz>
References: <ctsr0r$94m$1@sea.gmane.org>
	<20050206220713.D99FE15504@desire.actrix.co.nz>
Message-ID: <cu7934$irr$1@sea.gmane.org>

Hi,

>>I have an application which may need to write states frequently to my
>>nand-fs in order to have these states in case of powerdown.
>>But I'm a bit concerned about wearing the nand if I write to frequently.

>>So, if I only need to write, say, 100 bytes every second, how often will
>>this actually be flushed to the nand?
>>Is there a maximum commit/flush frequency built in the driver? Or can
>>this be configured?

> It depends on what fs you're using.
> With YAFFS, and I believe JFFS2 too, there is no reason to worry about flash 
> "wearing out".  I have done accelerated lifetime tests on NAND using YAFFS 
> and in one test wrote 130GB to NAND without any data loss, bad blocks 
> happening etc.
Now, that's a lot :-)
I'm using JFFS2 - so hopefully you're right...

> The NAND writes whenever the file system tells it to, so again your question 
> is FS dependent, but all file systems that are NAND-friendly should handle 
> the load you mention with no problems.
And that is JFFS2 - but since it's a journaling fs it must commit the 
journal, as well, every now and then...

// Martin




From estelle.hammache at st.com  Mon Feb  7 07:02:57 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Mon, 07 Feb 2005 13:02:57 +0100
Subject: Writing frequently to NAND - wearing, caching?
References: <ctsr0r$94m$1@sea.gmane.org>
	<20050206220713.D99FE15504@desire.actrix.co.nz>
	<cu7934$irr$1@sea.gmane.org>
Message-ID: <420758F1.8CAC90A2@st.com>

Hi Martin,

regarding JFFS2/NAND, the filesystem does not cache
write operations, however there is a NAND page cache.
This means that if you write 100 bytes at a time,
you will not use a full NAND page each time, but you will
probably create two JFFS2 data nodes in the same
NAND flash page. (NB a node may overlap a page boundary,
the page buffer is flushed to the device when
it is full).
Now if you do fsync between each write operation,
the page buffer will be flushed immediately. So in
this case you do use a full page (256 bytes or 2KB)
for each write.
The main drawback of JFFS2 in both cases is that
you end up with many small nodes on the flash
and this slows down initialization and access to this
file (see thread "jffs2_get_inode_nodes() very very slow"
in the February archive at 
http://lists.infradead.org/mailman/listinfo/linux-mtd/).
If you were to write 1 byte at a time this problem would
be even more acute. 
There is no "journal" per se in JFFS2, the whole 
filesystem is log-based.

The case with fsync will wear up the flash somewhat faster
but in any case JFFS2 contains integrated wear levelling
which will distribute the wear on all the blocks in the
partition, so no single block should be worn so much
that it fails (ideally. In real life some NAND blocks
may fail at any time even with perfect wear levelling.
However JFFS2 is able to cope with this case, and the
failed write operation will be retried on another block).

Have you read the JFFS/JFFS2 paper at
http://sources.redhat.com/jffs2/jffs2.pdf ?
(it is slightly out of date but the basic principles
of journaling, wear leveling, data nodes etc have not 
changed).

bye
Estelle


Martin Egholm Nielsen wrote:
> 
> Hi,
> 
> >>I have an application which may need to write states frequently to my
> >>nand-fs in order to have these states in case of powerdown.
> >>But I'm a bit concerned about wearing the nand if I write to frequently.
> 
> >>So, if I only need to write, say, 100 bytes every second, how often will
> >>this actually be flushed to the nand?
> >>Is there a maximum commit/flush frequency built in the driver? Or can
> >>this be configured?
> 
> > It depends on what fs you're using.
> > With YAFFS, and I believe JFFS2 too, there is no reason to worry about flash
> > "wearing out".  I have done accelerated lifetime tests on NAND using YAFFS
> > and in one test wrote 130GB to NAND without any data loss, bad blocks
> > happening etc.
> Now, that's a lot :-)
> I'm using JFFS2 - so hopefully you're right...
> 
> > The NAND writes whenever the file system tells it to, so again your question
> > is FS dependent, but all file systems that are NAND-friendly should handle
> > the load you mention with no problems.
> And that is JFFS2 - but since it's a journaling fs it must commit the
> journal, as well, every now and then...
> 
> // Martin
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



From joern at wohnheim.fh-wedel.de  Mon Feb  7 07:55:01 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 7 Feb 2005 13:55:01 +0100
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
In-Reply-To: <1107421396.32163.53.camel@fuzzie.sanpeople.com>
References: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
	<20050202124043.GB23156@wohnheim.fh-wedel.de>
	<1107421396.32163.53.camel@fuzzie.sanpeople.com>
Message-ID: <20050207125500.GA25504@wohnheim.fh-wedel.de>

On Thu, 3 February 2005 11:03:16 +0200, Andrew Victor wrote:
> 
> > > +	/* and Dataflash */
> > > +	if (jffs2_dataflash(c)) {
> > > +		ret = jffs2_dataflash_setup(c);
> > > +		if (ret)
> > > +			return ret;
> > > +	}
> > 
> > This can be a bit simpler:
> > 	ret = jffs2_dataflash_setup()
> > 	if (ret)
> > 		return ret;
> 
> I just copied the way it was done for the the NOR ECC flash.

That's a good explantion, but not a good excuse. ;)

> > > -	return BLK_STATE_ALLFF;	/* OK to erase if all blocks are like this */
> > > +	if (c->cleanmarker_size == 0)
> > > +		return BLK_STATE_CLEANMARKER;	/* don't bother with re-erase */
> 
> If a cleanmarker is not detected (within the first EMPTY_SCAN_SIZE bytes
> of a block), the block is added to the 'erase_pending_list' to be
> re-erased (and have a new cleanmarker written).
> 
> Since we don't need cleanmarkers on DataFlash, we return
> BLK_STATE_CLEANMARKER from jffs2_scan_eraseblock() so that the block
> rather gets added directly to the 'free_list'.

Why don't you need cleanmarkers?

With all other flash types, cleanmarkers catch the case where your
power fails during flash erase.  If that happens, you cannot trust the
eraseblock.  It could be fully erased, it could also just _look_ as if
it was and fail later on.  Bad.

Now you claim that this is not the case for DataFlash.  So I'd like
some explanation before I trust your code.

J?rn

-- 
I've never met a human being who would want to read 17,000 pages of
documentation, and if there was, I'd kill him to get him out of the
gene pool.
-- Joseph Costello



From andrew at sanpeople.com  Mon Feb  7 08:27:23 2005
From: andrew at sanpeople.com (Andrew Victor)
Date: 07 Feb 2005 15:27:23 +0200
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
In-Reply-To: <20050207125500.GA25504@wohnheim.fh-wedel.de>
References: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
	<20050202124043.GB23156@wohnheim.fh-wedel.de>
	<1107421396.32163.53.camel@fuzzie.sanpeople.com>
	<20050207125500.GA25504@wohnheim.fh-wedel.de>
Message-ID: <1107782843.28634.114.camel@fuzzie.sanpeople.com>

hi J?rn,
 
> > Since we don't need cleanmarkers on DataFlash, we return
> > BLK_STATE_CLEANMARKER from jffs2_scan_eraseblock() so that the block
> > rather gets added directly to the 'free_list'.
> 
> Why don't you need cleanmarkers?
> 
> With all other flash types, cleanmarkers catch the case where your
> power fails during flash erase.  If that happens, you cannot trust the
> eraseblock.  It could be fully erased, it could also just _look_ as if
> it was and fail later on.  Bad.
> 
> Now you claim that this is not the case for DataFlash.  So I'd like
> some explanation before I trust your code.

We don't need cleanmarkers since the DataFlash device will automatically
performs a page-erase before writing to the page.


Regards,
  Andrew Victor





From joern at wohnheim.fh-wedel.de  Mon Feb  7 09:04:53 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 7 Feb 2005 15:04:53 +0100
Subject: JFFS2-on-DataFlash : 2 - DataFlash support
In-Reply-To: <1107782843.28634.114.camel@fuzzie.sanpeople.com>
References: <1107248402.22631.53.camel@fuzzie.sanpeople.com>
	<20050202124043.GB23156@wohnheim.fh-wedel.de>
	<1107421396.32163.53.camel@fuzzie.sanpeople.com>
	<20050207125500.GA25504@wohnheim.fh-wedel.de>
	<1107782843.28634.114.camel@fuzzie.sanpeople.com>
Message-ID: <20050207140453.GB25504@wohnheim.fh-wedel.de>

On Mon, 7 February 2005 15:27:23 +0200, Andrew Victor wrote:
> 
> We don't need cleanmarkers since the DataFlash device will automatically
> performs a page-erase before writing to the page.

Ah, thanks.

Maybe a similar comment in the code would help other people who are
just as stupid as me.

J?rn

-- 
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt



From Sergei.Sharonov at Halliburton.com  Mon Feb  7 09:47:24 2005
From: Sergei.Sharonov at Halliburton.com (Sergei Sharonov)
Date: Mon, 7 Feb 2005 08:47:24 -0600
Subject: Low write throughput with arm/jffs2/nand
Message-ID: <487B538D08487B4D8FEC138A13D4F6AC21D8A5@HOUEXCH077.corp.halliburton.com>

Hi,

Around Jan 18 nand_wait() function in nand_base.c was changed to 
use msleep(1) instead of yield(). While it is sort of OK on x86
with its default HZ=1000 (linux 2.6) it slows down the throughput
on arm where the default is HZ=100. What I believe is happening:
- on the first pass flash is not ready
- msleep(1) is invoked, but it actually sleeps 10 or 20 ms

What will be the right way of fixing that? Replacing msleep(1) with
yield() does it but philosophically is probably not the right thing 
to do, changing HZ is much worse..

Sergei

P.S. What is the best read/write speed you people are getting with 
jffs2/nand?



From mcole at ati.com  Mon Feb  7 13:51:22 2005
From: mcole at ati.com (Matthew Cole)
Date: Mon, 7 Feb 2005 13:51:22 -0500 
Subject: Follow-up to wearing / caching question
Message-ID: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>

The question posed by Martin Neilsen leads me to write in search of an
answer that I've been pondering for a few days.  I've been tasked with
approximating the lifespan of the flash (JFFS2) filesystem embedded in our
products.  Is there a best method for calculating the space required for a
fixed-size file over a given lifespan?  If we want our flash filesystem to
be available for an approximate lifespan of 20 years, given the
wear-leveling duty-cycle of JFFS2, and an average block endurance of 100k
write/erase cycles, would I need 150% of the file's size? 200%? 1000%?  The
worst-case answer should be acceptable, but obviously, the most-realistic
case is what we're aiming for.  The actual read/write duty cycle of the
application is quite variable, so that adds some complexity to the problem,
but a good guess for now would be that it writes the entire file out to
flash once a minute.  But as that is an independent variable, maybe someone
could help me solve for that over a span of duty cycles?

I'd very much appreciate any input that anyone could offer me on this
problem.

Matthew Cole
Software Engineer
DTV Systems
ATI Research, Inc.
62 Forest St.
Marlborough, MA 01752
?
mcole at ati.com
O: 508-486-1179
F: 508-303-3920
C: 508-241-7923




From joern at wohnheim.fh-wedel.de  Mon Feb  7 14:52:09 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 7 Feb 2005 20:52:09 +0100
Subject: Follow-up to wearing / caching question
In-Reply-To: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>
References: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>
Message-ID: <20050207195209.GC25504@wohnheim.fh-wedel.de>

On Mon, 7 February 2005 13:51:22 -0500, Matthew Cole wrote:
> 
> The question posed by Martin Neilsen leads me to write in search of an
> answer that I've been pondering for a few days.  I've been tasked with
> approximating the lifespan of the flash (JFFS2) filesystem embedded in our
> products.  Is there a best method for calculating the space required for a
> fixed-size file over a given lifespan?  If we want our flash filesystem to
> be available for an approximate lifespan of 20 years, given the
> wear-leveling duty-cycle of JFFS2, and an average block endurance of 100k
> write/erase cycles, would I need 150% of the file's size? 200%? 1000%?  The
> worst-case answer should be acceptable, but obviously, the most-realistic
> case is what we're aiming for.  The actual read/write duty cycle of the
> application is quite variable, so that adds some complexity to the problem,
> but a good guess for now would be that it writes the entire file out to
> flash once a minute.  But as that is an independent variable, maybe someone
> could help me solve for that over a span of duty cycles?

Assuming non-compressable data and zero jffs2 overhead simplifies the
calculation.

In your scenario, you write the file every minute, over 20 years,
which is about 60x24x365x20 or 10M times.  You can only write any
individual address 100k times, so the flash would have to be 100x
bigger than your imaginary file.

Another way to look at it is an imaginary 1MiB flash.  You can write
it 100k times, for a total of 100GiB written to it.  With 600M seconds
in your expected 20 years, that gives you ~160 Bytes/s average write
speed.  Not very much.

Is that the calculation you were looking for?

J?rn

-- 
Homo Sapiens is a goal, not a description.
-- unknown



From manningc2 at actrix.gen.nz  Mon Feb  7 19:12:26 2005
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Tue, 8 Feb 2005 13:12:26 +1300
Subject: Writing frequently to NAND - wearing, caching?
In-Reply-To: <cu7934$irr$1@sea.gmane.org>
References: <ctsr0r$94m$1@sea.gmane.org>
	<20050206220713.D99FE15504@desire.actrix.co.nz>
	<cu7934$irr$1@sea.gmane.org>
Message-ID: <20050208000532.543131604C@desire.actrix.co.nz>

On Monday 07 February 2005 21:33, Martin Egholm Nielsen wrote:
> Hi,
>
> >>I have an application which may need to write states frequently to my
> >>nand-fs in order to have these states in case of powerdown.
> >>But I'm a bit concerned about wearing the nand if I write to frequently.
> >>
> >>So, if I only need to write, say, 100 bytes every second, how often will
> >>this actually be flushed to the nand?
> >>Is there a maximum commit/flush frequency built in the driver? Or can
> >>this be configured?
> >
> > It depends on what fs you're using.
> > With YAFFS, and I believe JFFS2 too, there is no reason to worry about
> > flash "wearing out".  I have done accelerated lifetime tests on NAND
> > using YAFFS and in one test wrote 130GB to NAND without any data loss,
> > bad blocks happening etc.
>
> Now, that's a lot :-)
> I'm using JFFS2 - so hopefully you're right...

What I always do is to do some lifetime estimates for stuff that can wear 
out. For most handheld mobile stuff this means flash, batteries, backlights.

For instance, YAFFS was used in a  hand-held data logger/PDA-thing 
application. 
*Typical high usage for a full day: 5MB of writes. Double it 10MB
*Typical high usage per year: 100 days/year. Use 150 days.
*Typical product lifetime: 5 years. Use 10 years.

Double again for all garbage collection etc.

That works out to 30GB of writing. 

On a 128Mbyte NAND, that works out at an average of 240 writes for each part 
of flash. Even if we go multiply by a very large "skew factor" of 100  
(because we're not using explicite wear levelling) we still have only reached 
24,000 - only 24% of the 100,000 cycle lifetime of the flash.

I did the 130GB test because I wanted a big enough number (~50 typical  
lifetimes) to make the nay-sayers shut up forever.

>
> > The NAND writes whenever the file system tells it to, so again your
> > question is FS dependent, but all file systems that are NAND-friendly
> > should handle the load you mention with no problems.
>
> And that is JFFS2 - but since it's a journaling fs it must commit the
> journal, as well, every now and then...

YAFFS and JFFS2 are both what I would consider to be very flash friendly. 
Even FAT on a SmartMedia is not too bad.  FAT+SM corruyptions are generally 
the fault of general FAT crappiness.

SmartMedia cycles through the blocks in the free pool. On a device with, say, 
1024 blocks, only 1000, say, of these will be used. The other are either bad 
blocks or in the free pool. When SmartMedia writes a block it uses a block 
from the free pool, then releases the old block to the free pool. This 
implements a degree of "implcite" wear levelling (ie. this use of a free pool 
tends to cause wear levelling as a side effect).

Where you'd get problem would be using a file system like FAT without a 
logical to physical remapping layer. This would result in the 
blocks holding the FAT getting hammered hard. 

Wear levelling, with a reasonable file system or logical mapping layer, is 
just a non-issue for most products.

-- Charles





From manningc2 at actrix.gen.nz  Mon Feb  7 19:22:23 2005
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Tue, 8 Feb 2005 13:22:23 +1300
Subject: Follow-up to wearing / caching question
In-Reply-To: <20050207195209.GC25504@wohnheim.fh-wedel.de>
References: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>
	<20050207195209.GC25504@wohnheim.fh-wedel.de>
Message-ID: <20050208001528.C613F409A@blood.actrix.co.nz>

On Tuesday 08 February 2005 08:52, J?rn Engel wrote:
> On Mon, 7 February 2005 13:51:22 -0500, Matthew Cole wrote:
> > The question posed by Martin Neilsen leads me to write in search of an
> > answer that I've been pondering for a few days.  I've been tasked with
> > approximating the lifespan of the flash (JFFS2) filesystem embedded in
> > our products.  Is there a best method for calculating the space required
> > for a fixed-size file over a given lifespan?  If we want our flash
> > filesystem to be available for an approximate lifespan of 20 years, given
> > the
> > wear-leveling duty-cycle of JFFS2, and an average block endurance of 100k
> > write/erase cycles, would I need 150% of the file's size? 200%? 1000%? 
> > The worst-case answer should be acceptable, but obviously, the
> > most-realistic case is what we're aiming for.  The actual read/write duty
> > cycle of the application is quite variable, so that adds some complexity
> > to the problem, but a good guess for now would be that it writes the
> > entire file out to flash once a minute.  But as that is an independent
> > variable, maybe someone could help me solve for that over a span of duty
> > cycles?

20 year product life? Really? What stuff are you still using that was first 
plugged in in 1985?

> Assuming non-compressable data and zero jffs2 overhead simplifies the
> calculation.
>
> In your scenario, you write the file every minute, over 20 years,
> which is about 60x24x365x20 or 10M times.  You can only write any
> individual address 100k times, so the flash would have to be 100x
> bigger than your imaginary file.
>
> Another way to look at it is an imaginary 1MiB flash.  You can write
> it 100k times, for a total of 100GiB written to it.  With 600M seconds
> in your expected 20 years, that gives you ~160 Bytes/s average write
> speed.  Not very much.
>
> Is that the calculation you were looking for?

There are two factors which skew this:

1) Garbage collection. Depending on the way the files are rewritten and freed 
up, different amounts of garbage collection rewrites will be performed. Worst 
case GC can drive up the number of writes.

2) "Squatter files". Some files live a long time and some are transient. 
Those that live a long time will tend to take up "squatters rights" on an 
area of flash which means that the rest gets written more often.


>
> J?rn



From jinz6055 at yahoo.com  Mon Feb  7 21:09:09 2005
From: jinz6055 at yahoo.com (Jin Zhang)
Date: Mon, 7 Feb 2005 18:09:09 -0800 (PST)
Subject: experience with using jffs 
Message-ID: <20050208020909.35730.qmail@web30704.mail.mud.yahoo.com>

hi, friends,

i am evaluating using the jffs on top of a compact
flash running linux system. i'd like to hear your
experiences with using the jffs, like stability,
functional compliance with FS semantics, performance,
etc.

also, several questions:

can grub boot from jffs?
does jffs work on compact flash right now, i seem to
got conflicting answers while searching the web.

thanks a lot,

Jin


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250



From martin at egholm-nielsen.dk  Mon Feb  7 16:36:45 2005
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Mon, 07 Feb 2005 22:36:45 +0100
Subject: Follow-up to wearing / caching question
In-Reply-To: <20050207195209.GC25504@wohnheim.fh-wedel.de>
References: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>
	<20050207195209.GC25504@wohnheim.fh-wedel.de>
Message-ID: <cu8n22$acu$1@sea.gmane.org>

Hi there,

>> I've been tasked with approximating the lifespan of the flash
>> (JFFS2) filesystem embedded in our products. Is there a best method
>> for calculating the space required for a fixed-size file over a
>> given lifespan? If we want our flash filesystem to be available for
>> an approximate lifespan of 20 years, given the wear-leveling
>> duty-cycle of JFFS2, and an average block endurance of 100k 
>> write/erase cycles, would I need 150% of the file's size? 200%?
>> 1000%?
=== 8< 8< 8< ===
> Another way to look at it is an imaginary 1MiB flash.  You can write
> it 100k times, for a total of 100GiB written to it.  With 600M seconds
> in your expected 20 years, that gives you ~160 Bytes/s average write
> speed.  Not very much.
Then what about the pagesize and corresponding writebuffer - this may 
have an effect, as well, when talking that slow write rates, right?!

> Is that the calculation you were looking for?
I liked it alot - thanks! ;-)

// Martin




From dedekind at infradead.org  Tue Feb  8 05:31:19 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 8 Feb 2005 10:31:19 +0000 (GMT)
Subject: Low write throughput with arm/jffs2/nand
In-Reply-To: <487B538D08487B4D8FEC138A13D4F6AC21D8A5@HOUEXCH077.corp.halliburton.com>
References: <487B538D08487B4D8FEC138A13D4F6AC21D8A5@HOUEXCH077.corp.halliburton.com>
Message-ID: <Pine.LNX.4.58.0502081028020.13460@phoenix.infradead.org>

On Mon, 7 Feb 2005, Sergei Sharonov wrote:
> Hi,
> 
> Around Jan 18 nand_wait() function in nand_base.c was changed to 
> use msleep(1) instead of yield(). While it is sort of OK on x86
> with its default HZ=1000 (linux 2.6) it slows down the throughput
> on arm where the default is HZ=100. What I believe is happening:
> - on the first pass flash is not ready
> - msleep(1) is invoked, but it actually sleeps 10 or 20 ms
> 
> What will be the right way of fixing that? Replacing msleep(1) with
> yield() does it but philosophically is probably not the right thing 
> to do, changing HZ is much worse..
> 
> Sergei
> 
> P.S. What is the best read/write speed you people are getting with 
> jffs2/nand?
This is highly depended on whether you use compression and the compression 
mode.

> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From dedekind at infradead.org  Tue Feb  8 07:02:04 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 8 Feb 2005 12:02:04 +0000 (GMT)
Subject: [PATCH] nand_default_block_markbad fix
Message-ID: <Pine.LNX.4.58.0502081156310.20565@phoenix.infradead.org>

Hello, here is small bugfix.

Bug description: kernel oops if there is no BBT table and the 
nand_default_block_markbad() function is called.

The patch should be applied to the drivers/mtd/nand/nand_base.c file.

Ok to commit?

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
--- nand_base.c	2005-02-08 14:54:03.330897219 +0300
+++ nand_base_fixed.c	2005-02-08 14:52:44.330376104 +0300
@@ -461,7 +461,8 @@
 	
 	/* Get block number */
 	block = ((int) ofs) >> this->bbt_erase_shift;
-	this->bbt[block >> 2] |= 0x01 << ((block & 0x03) << 1);
+	if (this->bbt)
+		this->bbt[block >> 2] |= 0x01 << ((block & 0x03) << 1);
 
 	/* Do we have a flash based bad block table ? */
 	if (this->options & NAND_USE_FLASH_BBT)

From joern at wohnheim.fh-wedel.de  Tue Feb  8 08:23:54 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 8 Feb 2005 14:23:54 +0100
Subject: Follow-up to wearing / caching question
In-Reply-To: <20050208001528.C613F409A@blood.actrix.co.nz>
References: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>
	<20050207195209.GC25504@wohnheim.fh-wedel.de>
	<20050208001528.C613F409A@blood.actrix.co.nz>
Message-ID: <20050208132354.GA21515@wohnheim.fh-wedel.de>

On Tue, 8 February 2005 13:22:23 +1300, Charles Manning wrote:
> 
> 20 year product life? Really? What stuff are you still using that was first 
> plugged in in 1985?

Most likely some old mainframes.  But even for them it'd be a long
life.

> There are two factors which skew this:
> 
> 1) Garbage collection. Depending on the way the files are rewritten and freed 
> up, different amounts of garbage collection rewrites will be performed. Worst 
> case GC can drive up the number of writes.
> 
> 2) "Squatter files". Some files live a long time and some are transient. 
> Those that live a long time will tend to take up "squatters rights" on an 
> area of flash which means that the rest gets written more often.

I guess dwmw2's approach to split up writes between two erase blocks
would solve both issues.  GC'd data can be expected to be rather
long-living, so it goes to a different block than newly written data.

J?rn

-- 
People will accept your ideas much more readily if you tell them
that Benjamin Franklin said it first.
-- unknown



From MattCreech at eaton.com  Tue Feb  8 09:05:40 2005
From: MattCreech at eaton.com (Creech, Matthew)
Date: Tue, 8 Feb 2005 09:05:40 -0500
Subject: JFFS2 on dataflash problem [fixed]
Message-ID: <F0A064EBC8C91C449244D108367426DC01EF2AAD@ra1ncsmb01.nasa.ad.etn.com>

Creech, Matthew wrote:
> I have an embedded device based on Atmel's AT91RM9200DK board, which
is
> using serial dataflash (AT45DB642).  I've allocated a JFFS2 partition
to
> store non-volatile data.  In testing I stumbled across a particular
> problem that only occurs after heavy hammering on our device, but is
> fairly consistent in how and when it occurs.  The pattern has been
> narrowed down so that a script doing something like this:     
> 
> while [ 1 ]; do
>    cp /mnt/jffs2/$RANDOM_FILE /mnt/jffs2/$BLAH
>    # File size has been tested between 8K and 64K
> done
> 
> makes the problem occur within 24 to 36 hours.  So something about
> copying one file over another one breaks things.  The "problem" here
is
> that every I/O operation having to do with the JFFS2 partition blocks
> indefinitely.  For example, after running the test for 2 days, you can
> log into the device and try to "ls" the contents of /mnt/jffs2, and
your
> shell will hang.  You can then login on another terminal, but you'll
get
> another hang if you try to have any interaction with the JFFS2
partition.
> So everything else seems to function normally, but JFFS2 just dies.
Also
> note that rebooting the device sometimes fixes things right up (JFFS2
> mounts fine and works properly as if nothing happened at all), but
> sometimes the filesystem image is corrupt and refuses to mount.

> 
[snip]

For anyone interested, Andrew Victor pointed me to these two patches:

http://lists.infradead.org/pipermail/linux-mtd/2005-February/011766.html
http://lists.infradead.org/pipermail/linux-mtd/2005-February/011767.html

which I applied to a kernel with a recent MTD snapshot patched in.  The
test which had consistently crashed my device within 24-36 hours has now
been running for 5 days.  During this time the device has operated
perfectly, with no JFFS2 errors at all.  So it seems that the problem
has been fixed.

Just an FYI, in case someone is considering merging these patches into
CVS.  Thanks

-- 
Matthew L. Creech 



From joern at wohnheim.fh-wedel.de  Tue Feb  8 10:09:53 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 8 Feb 2005 16:09:53 +0100
Subject: Follow-up to wearing / caching question
In-Reply-To: <cu8n22$acu$1@sea.gmane.org>
References: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>
	<20050207195209.GC25504@wohnheim.fh-wedel.de>
	<cu8n22$acu$1@sea.gmane.org>
Message-ID: <20050208150953.GA23906@wohnheim.fh-wedel.de>

On Mon, 7 February 2005 22:36:45 +0100, Martin Egholm Nielsen wrote:
>
> >Another way to look at it is an imaginary 1MiB flash.  You can write
> >it 100k times, for a total of 100GiB written to it.  With 600M seconds
> >in your expected 20 years, that gives you ~160 Bytes/s average write
> >speed.  Not very much.
> Then what about the pagesize and corresponding writebuffer - this may 
> have an effect, as well, when talking that slow write rates, right?!

For NOR, you don't need a write buffer.  For NAND you do, but then
again, 1MiB is rather small for NAND.  With 128MiB, you'd already have
a write rate of 20k/s, so the write buffer overhead is just a small
fraction of 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 tglx at linutronix.de  Tue Feb  8 11:51:47 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 08 Feb 2005 17:51:47 +0100
Subject: unable to get NAND oobinfo
In-Reply-To: <20050204112622.M33820@unsec.nl>
References: <20050204112622.M33820@unsec.nl>
Message-ID: <1107881508.17747.2.camel@tglx.tec.linutronix.de>

On Fri, 2005-02-04 at 12:43 +0100, Rudi Engelbertink wrote:
> Hi,
> 
> trying to get my nand driver (for compulab 586core board) on kernel 2.4.27
> working, i ran into the following problem:
> The driver is recognised and appears to work. That means I can read the mtdchar
> device but whin I'm trying to format the device, I recieve the message
> 'flash_eraseall: /dev/mtd3: unable to get NAND oobinfo'
> An strace replies with:
> open("/dev/mtd3", O_RDWR)               = 3
> ioctl(3, 0x80204d01, 0xbffffdf0)        = 0
> ioctl(3, 0x80c84d0a, 0xbffffd20)        = -1 ENOTTY (Inappropriate ioctl for
> device)

I guess you are using vanilla 2.4.27 without mtd patches. So the ioctl
is not implemented. The NAND stuff in MTD/JFFS2 on vanilla 2.4.xx is not
really fully functional. 

tglx





From Eoghan.Doyle at trintech.com  Tue Feb  8 11:50:20 2005
From: Eoghan.Doyle at trintech.com (Eoghan Doyle)
Date: Tue, 8 Feb 2005 16:50:20 -0000 
Subject: ST Flashes and buffer write
Message-ID: <BBB9FA5E1514D511A88D00B0D0AA8EA60AD22073@ntdub1e.trintech.com>

Hi,

I have a problem with an ST flash and buffer write. It looks similar to what
as discussed in several threads as far back as Aug 2002, but I cannot find
the solution.

I am using a M28W640 flash. This claims to be an Intel/Sharp Standard flash
supporting buffered write.
But the buffered write it supports is not the same as coded in
cfi_cmdset_0001.c.
It uses a double/quad word write instead of a buffer write.

The Intel buffer write is:
1.	Write buffer write command (0xe8)
2.	Write the number of words to follow.
3.	Write each word.
4.	Write the confirm command (0xd0).
5.	Check status.

The ST version is: (see the datasheet at
http://www.datasheetarchive.com/datasheet/pdf/46/469684.html)

1.	Write double/quad word command (0x30/0x56)
2.	Write 2/4 words.
3.	Check status.

In the ST case you must check that the addresses are consecutive and that
only bottom bits change.

If you use one of these chips with the MTD you will get EROFS returned from
do_write_buffer.

Currently I am defining FORCE_WORD_WRITE as a work around.
I have attached some debug output below.

The questions I have are:
1.	Is there already code to handle this difference, which I have
missed?
2.	How can you tell the difference between the 2 write buffer methods
without resorting to tying it to a specific vender/chip?
3.	Will this make much of a difference to write speeds?

Thanks for your help,
Eoghan

============================================================
Debug output:
Number of erase regions: 2
Primary Vendor Command Set: 0003 (Intel/Sharp Standard)
Primary Algorithm Table at 0035
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
Vpp Minimum: b.4 V
Vpp Maximum: c.6 V
Typical byte/word write timeout: 16 ?s
Maximum byte/word write timeout: 512 ?s
Typical full buffer write timeout: 16 ?s
Maximum full buffer write timeout: 512 ?s
Typical block erase timeout: 1024 ?s
Maximum block erase timeout: 8192 ?s
Chip erase not supported
Device size: 0x800000 bytes (8 MiB)
Flash Device Interface description: 0x0001
  - x16-only asynchronous interface
Max. bytes in buffer write: 0x8
Number of Erase Block Regions: 2
  Erase Region #0: BlockSize 0x2000 bytes, 8 blocks
  Erase Region #1: BlockSize 0x10000 bytes, 127 blocks
  Feature/Command Support: 0066
     - Chip Erase:         unsupported
     - Suspend Erase:      supported
     - Suspend Program:    supported
     - Legacy Lock/Unlock: unsupported
     - Queued Erase:       unsupported
     - Instant block lock: supported
     - Protection Bits:    supported
     - Page-mode read:     unsupported
     - Synchronous read:   unsupported
  Supported functions after Suspend: 01
     - Program after Erase Suspend: supported
  Block Status Register Mask: 0003
     - Lock Bit Active:      yes
     - Valid Bit Active:     yes
  Vcc Logic Supply Optimum Program/Erase Voltage: 0.0 V
  Vpp Programming Supply Optimum Program/Erase Voltage: 0.0 V
Using buffer write method



From dwmw2 at infradead.org  Tue Feb  8 12:54:19 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 08 Feb 2005 17:54:19 +0000
Subject: mtd/include/mtd mtd-abi.h,1.8,1.9
In-Reply-To: <E1CyZQx-0005qR-9M@phoenix.infradead.org>
References: <E1CyZQx-0005qR-9M@phoenix.infradead.org>
Message-ID: <1107885259.19262.495.camel@hades.cambridge.redhat.com>

On Tue, 2005-02-08 at 17:45 +0000, Nicolas Pitre wrote:
> +#define OTPSELECT		_IOR('M', 13, int)
> +#define OTPGETREGIONCOUNT	_IOW('M', 14, int)

No ints in ioctls please. Choose something with a fixed size.

-- 
dwmw2




From nico at cam.org  Tue Feb  8 12:57:13 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 8 Feb 2005 12:57:13 -0500 (EST)
Subject: mtd/include/mtd mtd-abi.h,1.8,1.9
In-Reply-To: <1107885259.19262.495.camel@hades.cambridge.redhat.com>
References: <E1CyZQx-0005qR-9M@phoenix.infradead.org>
	<1107885259.19262.495.camel@hades.cambridge.redhat.com>
Message-ID: <Pine.LNX.4.61.0502081255500.20042@localhost.localdomain>

On Tue, 8 Feb 2005, David Woodhouse wrote:

> On Tue, 2005-02-08 at 17:45 +0000, Nicolas Pitre wrote:
> > +#define OTPSELECT		_IOR('M', 13, int)
> > +#define OTPGETREGIONCOUNT	_IOW('M', 14, int)
> 
> No ints in ioctls please. Choose something with a fixed size.

Aren't ints fixed size?  I carefully avoided using a long for that 
reason.


Nicolas



From dwmw2 at infradead.org  Tue Feb  8 13:02:51 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 08 Feb 2005 18:02:51 +0000
Subject: mtd/include/mtd mtd-abi.h,1.8,1.9
In-Reply-To: <Pine.LNX.4.61.0502081255500.20042@localhost.localdomain>
References: <E1CyZQx-0005qR-9M@phoenix.infradead.org>
	<1107885259.19262.495.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.61.0502081255500.20042@localhost.localdomain>
Message-ID: <1107885772.19262.496.camel@hades.cambridge.redhat.com>

On Tue, 2005-02-08 at 12:57 -0500, Nicolas Pitre wrote:
> 
> > No ints in ioctls please. Choose something with a fixed size.
> 
> Aren't ints fixed size?  I carefully avoided using a long for that 
> reason.

Yeah, I'm full of crap. Sorry.

-- 
dwmw2




From c.lucas at ifrance.com  Tue Feb  8 10:10:45 2005
From: c.lucas at ifrance.com (Christophe Lucas)
Date: Tue, 8 Feb 2005 16:10:45 +0100
Subject: drivers/mtd/maps/*: convert to pci_register_driver
Message-ID: <20050208151045.GQ31996@rhum.iomeda.fr>

Hi,

Description:
convert from pci_module_init to pci_register_driver
(from:http://kerneljanitors.org/TODO).

Signed-off-by: Christophe Lucas <c.lucas at ifrance.com>
-- 
Christophe
-------------- next part --------------
diff -urpN -X /work/users/dontdiff linux-2.6.11-rc3-vanilla/drivers/mtd/maps/amd76xrom.c linux-2.6.11-rc3/drivers/mtd/maps/amd76xrom.c
--- linux-2.6.11-rc3-vanilla/drivers/mtd/maps/amd76xrom.c	2005-02-03 17:03:48.000000000 +0100
+++ linux-2.6.11-rc3/drivers/mtd/maps/amd76xrom.c	2005-02-07 09:39:28.000000000 +0100
@@ -314,7 +314,7 @@ static int __init init_amd76xrom(void)
 	}
 	return -ENXIO;
 #if 0
-	return pci_module_init(&amd76xrom_driver);
+	return pci_register_driver(&amd76xrom_driver);
 #endif
 }
 
diff -urpN -X /work/users/dontdiff linux-2.6.11-rc3-vanilla/drivers/mtd/maps/ich2rom.c linux-2.6.11-rc3/drivers/mtd/maps/ich2rom.c
--- linux-2.6.11-rc3-vanilla/drivers/mtd/maps/ich2rom.c	2004-12-24 22:35:49.000000000 +0100
+++ linux-2.6.11-rc3/drivers/mtd/maps/ich2rom.c	2005-02-07 09:39:28.000000000 +0100
@@ -299,7 +299,7 @@ int __init init_ich2rom(void)
 	}
 	return -ENXIO;
 #if 0
-	return pci_module_init(&ich2rom_driver);
+	return pci_register_driver(&ich2rom_driver);
 #endif
 }
 
diff -urpN -X /work/users/dontdiff linux-2.6.11-rc3-vanilla/drivers/mtd/maps/ichxrom.c linux-2.6.11-rc3/drivers/mtd/maps/ichxrom.c
--- linux-2.6.11-rc3-vanilla/drivers/mtd/maps/ichxrom.c	2005-02-03 17:03:48.000000000 +0100
+++ linux-2.6.11-rc3/drivers/mtd/maps/ichxrom.c	2005-02-07 09:39:28.000000000 +0100
@@ -366,7 +366,7 @@ static int __init init_ichxrom(void)
 	}
 	return -ENXIO;
 #if 0
-	return pci_module_init(&ichxrom_driver);
+	return pci_register_driver(&ichxrom_driver);
 #endif
 }
 
diff -urpN -X /work/users/dontdiff linux-2.6.11-rc3-vanilla/drivers/mtd/maps/pci.c linux-2.6.11-rc3/drivers/mtd/maps/pci.c
--- linux-2.6.11-rc3-vanilla/drivers/mtd/maps/pci.c	2005-02-03 17:03:48.000000000 +0100
+++ linux-2.6.11-rc3/drivers/mtd/maps/pci.c	2005-02-07 09:39:28.000000000 +0100
@@ -370,7 +370,7 @@ static struct pci_driver mtd_pci_driver 
 
 static int __init mtd_pci_maps_init(void)
 {
-	return pci_module_init(&mtd_pci_driver);
+	return pci_register_driver(&mtd_pci_driver);
 }
 
 static void __exit mtd_pci_maps_exit(void)
diff -urpN -X /work/users/dontdiff linux-2.6.11-rc3-vanilla/drivers/mtd/maps/scb2_flash.c linux-2.6.11-rc3/drivers/mtd/maps/scb2_flash.c
--- linux-2.6.11-rc3-vanilla/drivers/mtd/maps/scb2_flash.c	2005-02-03 17:03:48.000000000 +0100
+++ linux-2.6.11-rc3/drivers/mtd/maps/scb2_flash.c	2005-02-07 09:39:28.000000000 +0100
@@ -238,7 +238,7 @@ static struct pci_driver scb2_flash_driv
 static int __init
 scb2_flash_init(void)
 {
-	return pci_module_init(&scb2_flash_driver);
+	return pci_register_driver(&scb2_flash_driver);
 }
 
 static void __exit

From dedekind at infradead.org  Tue Feb  8 14:23:26 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 8 Feb 2005 19:23:26 +0000 (GMT)
Subject: 2 Questions - with regards to  Linux 2.6
In-Reply-To: <20050208173925.96725.qmail@web90108.mail.scd.yahoo.com>
References: <20050208173925.96725.qmail@web90108.mail.scd.yahoo.com>
Message-ID: <Pine.LNX.4.58.0502081902060.20565@phoenix.infradead.org>

On Tue, 8 Feb 2005, anonymous wrote:
> 
> Hi Artem,
> 
> My mailer client  prevents me from posting to the list - could I ask you for a favor to answer few of my questions (I am new on Linux and its flash support) ? - I would highly appreciate your kindness to the person, who was born in the same beatiful city (St. Petersburg) you are living ...
I wonder what disaster doesn't allow you to post to the mailing list :-)
Well, I'll try to answer some questions. Hope others will 
supplement/correct me.

> 
> 1) NOR related question(s) 
> 
>  How commandline partition parsing is getting enabled (in .config ? ) on Linux 2.6 ?
I've never used NOR flashes. Just hints where to dig:

Documentation/kernel-parameters.txt - grep for mtdpart
drivers/mtd/cmdlinepart.c - here the cmdline is usually parsed
drivers/mtd/maps - the NOR registration/detecting etc stuff

>  How could I provide info for creating 3 partitions on single NOR flash on the commandline (is it possible in principle ?) 
> 
> What is the specific command line syntax to achieve the following effect:
> 
> Creating 3 MTD partitions on "phys_mapped_flash":
> 0x00000000-0x00080000 : "name 1"
> 0x00080000-0x00180000 : "name 2"
> 0x00180000-0x00380000 : "name 3"
drivers/mtd/cmdlinepart.c - see the header comment there, for example.

> 
>  2) NAND related question 
> 
>   Is there a generic driver on Linux 2.6 to support single partition on NAND flash ?

Well, the most generic driver is the default operations in nand_base.c.
Usually people write different drivers. Dig nand_base.c for most 
NAND-related stuff.

> 
>   What enabling of (each of)  the following Linux 2.6 .config options does ?
> 
> #
> # NAND Flash Device Drivers
> #
> CONFIG_MTD_NAND
Enable generic NAND support.

> CONFIG_MTD_NAND_VERIFY_WRITE 
Gets MTD layer to operate in write-check mode. this means that after each 
page write MTD will read this page agein and compare whether it was 
written correctly.
Usually useful on the development/debuggind stage, not in production.

> CONFIG_MTD_NAND_IDS=y
I assume this links the arrays of known NAND flash chips. Each NAND flash 
chip type has unique ID bytes, so MTD layer may auto-detect its 
geometry/etc automatically. I would suggest to use this. Dig the 
nand_ids.c.

> CONFIG_MTD_NAND_DISKONCHIP
Enable the DiskOnChip stuff. Don't use this if you have no.

> 
> Again - If you could kindly spend some of your pressures time and answer my questions and perhaps (optionally - on your discretion) post your answers on the list so other newbies could also benefit from your answers - I would appreciate it very much !
Not big help, but anyway...

> 
> Thanks,
> 
> Best Regards,
> 
> Alex (Sasha)

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From steve at digidescorp.com  Thu Feb 10 17:44:12 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Thu, 10 Feb 2005 16:44:12 -0600
Subject: Bug in jffs2/scan.c re: incorrect assumption of "all clean" block
Message-ID: <002f01c50fc2$0d968ed0$6ffea8c0@banana>

Hello MTD folk,

I'm not hooked into the MTD list so please cc: me on any replies. Also
please note that this is my first experience with this code, so excuse
me if I've gone off base.

I believe there is a bug in fs/jffs2/scan.c that causes it to
incorrectly assume a block with a cleanmarker is "all clean". This
causes an "Eep. Block 0xXXXXXXXX taken from free_list had free_size of
0xXXXXXXXX!!" to go off when jffs2_do_reserve_space() is called later.

There are 4 conditions that have to be met in a particular block for the
bug to surface:

* The block has a cleanmarker
* The end of the block has to be free space (0xFF)
* The block has JFFS2_NODETYPE_INODEs
* The block does NOT have any JFFS2_NODETYPE_DIRENTs

The test that governs the "all clean" assumption is as follows (cf.
scan.c 1.118 line 435)

	if (buf_ofs == jeb->offset && jeb->used_size ==
PAD(c->cleanmarker_size) && 
	    c->cleanmarker_size && !jeb->dirty_size &&
!jeb->first_node->next_in_ino) {

The bug is that there is no test that checks whether any
JFFS2_NODETYPE_INODEs have been seen. Since only JFFS2_NODETYPE_DIRENTs
are counted as used, and JFFS2_NODETYPE_INODEs are counted as unchecked,
I think that the correction should look like this:

	if (buf_ofs == jeb->offset && ((jeb->used_size +
jeb->unchecked_size) == PAD(c->cleanmarker_size)) && 
	    c->cleanmarker_size && !jeb->dirty_size &&
!jeb->first_node->next_in_ino) {


This seems consistent with what is done at line 631:

	if ((jeb->used_size + jeb->unchecked_size) ==
PAD(c->cleanmarker_size) && !jeb->dirty_size 
		&& (!jeb->first_node || !jeb->first_node->next_in_ino) )

...although the two are still not checking quite the same set of
conditions.

Comments? I can provide a JFFS2 image that triggers the problem if
someone is interested in stepping through it.

Steve Magnani
Digital Design Corporation
www.digidescorp.com






From arasv at magellan-technology.com  Wed Feb  9 01:16:35 2005
From: arasv at magellan-technology.com (Aras Vaichas)
Date: Wed, 09 Feb 2005 17:16:35 +1100
Subject: Writing frequently to NAND - wearing, caching?
In-Reply-To: <20050208000532.543131604C@desire.actrix.co.nz>
References: <ctsr0r$94m$1@sea.gmane.org>	<20050206220713.D99FE15504@desire.actrix.co.nz>	<cu7934$irr$1@sea.gmane.org>
	<20050208000532.543131604C@desire.actrix.co.nz>
Message-ID: <4209AAC3.2090806@magellan-technology.com>

Charles Manning wrote:
> On Monday 07 February 2005 21:33, Martin Egholm Nielsen wrote:
> 
>>Hi,
>>
>>
>>>>I have an application which may need to write states frequently to my
>>>>nand-fs in order to have these states in case of powerdown.
>>>>But I'm a bit concerned about wearing the nand if I write to frequently.
 > <snip>
> (because we're not using explicite wear levelling) we still have only reached 
> 24,000 - only 24% of the 100,000 cycle lifetime of the flash.
> 

... and then there is the fact that the 100,000 write cycle limit is generally 
a conservative estimate based on testing of the device at an operating 
temperature of around 125 celcius! Most likely the device will be able to 
withstand over to 1,000,000 write cycles before failure. If your FS uses write 
verification to make sure the data is secure then you shouldn't have any 
problems even if you do reach this limit on some areas of the Flash.

 From the "Toshiba NAND Flash Applications Design Guide"

"NOR Flash is typically limited to around 100,000 cycles. Since the electron 
flow-path due to the hot electron injection for programming is different from 
the one due to tunneling from the floating gate to the source for erasing, 
degradation is enhanced. However, in NAND Flash, both the programming and 
erasing is achieved by uniform Fowler- Nordheim tunneling between the floating 
gate and the substrate. This uniform programming and uniform erasing technology 
guarantees a wide cell threshold window even after 1,000,000 cycles."

and

"There is one question that often comes up  Is ECC really necessary?  After 
all, the likeliest cause of a bit error is during the programming process. For 
example, if you program a block, then verify it has no errors, how reliable is 
the data? In these ROM-like applications where the write/erase cycles is very 
low, the actual failure rate for a block is about 3 ppm after 10 years (i.e. 3 
blocks out of every million blocks will have a bit error after 10 years) in 
which a block failure is defined as a single bit error. This result was derived 
from testing 29708 pieces of 512Mb NAND (0.16um) by writing a checkerboard 
pattern into blocks and storing at 125C. Since there will be a non-zero data 
retention failure rate, you should limit the amount of code to 1 block to 
achieve a low ppm probability of failure."


regards,

Aras



From f.grasso at custom.it  Wed Feb  9 10:16:03 2005
From: f.grasso at custom.it (Fabrizio Grasso)
Date: Wed, 09 Feb 2005 16:16:03 +0100
Subject: Creating RAM partition??
Message-ID: <5.0.2.1.2.20050209161004.00b425b8@192.168.2.9>

Hi all,
I'm using ARM9 S3C2410A from Samsung and Linux 2.4.18 from Mizi.

I'd like to know if it's possible ( and how :) ) to create a RAM filesystem 
which I can mount in R/W mode... at a specified RAM area.
I think I must create something under /dev path which represent the 
specified memory area and then mount it at runtime with something like:
"mount -t ramfs /dev/... /mnt/ramfs".

But... how to create the /dev/... object??

At this moment I have /dev/rd/0 which I can mount with:
"mount -t ramfs /dev/rd/0 /mnt/ramfs"
I can read/write to /mnt/ramfs but I don't know at which memory address it 
write!

PS: Probably I'm wrong in all my reasoning... if it so... please 
redirection me to the correct way!!

Thanks!




From wanttoknowwhyandwhatfor at yahoo.com  Tue Feb  8 23:16:15 2005
From: wanttoknowwhyandwhatfor at yahoo.com (anonymous)
Date: Tue, 8 Feb 2005 20:16:15 -0800 (PST)
Subject: further question on commandline partitions
Message-ID: <20050209041615.31286.qmail@web90107.mail.scd.yahoo.com>

Hi,

I currently have:
...
<5>physmap flash device:400000 at 4000000.
<4>__ioremap(): phys addr 04000000 is RAM lr c01d93f0.
<4>__ioremap(): virt_to_phys(high_memory) addr
02000000.
<4>__ioremap(): passed first cond.
<4>__ioremap(): passed second cond.
<4>__ioremap(): passed label.
<5>init_physmap after simple_map_init.
<5>init_physmap type=cfi_probe.
<6>phys_mapped_flash: Found 1 x16 devys_mapped_flash:
Found 1 x16 devices at 0x0 in 16-bit bank.
<4> Amd/Fujitsu Extended Query Tableat 0x0040.
<5>number of CFI chips: 1.
<5>cfi_cmdset_0002: Disabling erase-suspend-program
due to code brokenness..
<5>init_physmap after for loop.
<5>RedBoot partition parsing not
available.
<5>init_physmap after parse_mtd_partitions.
<6>mtd: Giving out device 0 to phys_mapped_flash.
<5>init_physmap after add_mtd_device.
...
Now I am trying to use commandline for creating
partitions. I was referred to the header comment in
the drivers/mtd/cmdlinepart.c:
/* The format for the command line is as follows:
*
* mtdparts=<mtddef>[;<mtddef]
* <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
* <partdef> := <size>[@offset][<name>][ro]
* <mtd-id>  := unique name used in mapping
driver/device (mtd->name)
* <size>    := standard linux memsize OR "-" to denote
all remaining space
* <name>    := '(' NAME ')'
*
* Examples:
*
* 1 NOR Flash, with 1 single writable partition:
* edb7312-nor:-
*
* 1 NOR Flash with 2 partitions, 1 NAND with one
*
edb7312-nor:256k(ARMboot)ro,-(root);edb7312-nand:-(home)
*/

It is still unclear for me from the comment and
example above - how I come up with the:

 "<mtd-id>  := unique name used in mapping
driver/device (mtd->name)"

 such as  "edb7312-nor" and "edb7312-nand" ...

is it the unique name, which I should make up on my
own
or else ?

Also speaking of the sizes for partitions: -
I suppose that for the NOR flash, the size info from
the commandline will be processed together with the
info on the total size of the NOR flash, provided in 
.config's 
CONFIG_MTD_PHYSMAP_LEN 
- am I correct in my above conjecture ?

However, this leaves unexplained how the total size of
the NAND flash is derived, say for the given above
example:
edb7312-nand:-(home)
In above notation - it merely refers to "all remaining
space" (which in particular example I think means:
entire space of the NAND flash - correct ?). So 
how the total size of the NAND flash is derived ?
(I do not see any .config entry for this info with
regards to NAND flash).

Thanks




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From mssadijal at zipmail.com.br  Sun Feb 13 17:54:11 2005
From: mssadijal at zipmail.com.br (mssadijal at zipmail.com.br)
Date: Sun, 13 Feb 2005 23:54:11 +0100
Subject: A CRY FOR HELP
Message-ID: <420EFAF5000015FA@www.zipmail.com.br>

A CRY FOR HELP
For security reasons please reply to :
marahsadija at netscape.net

Dear friend ,
this mail will definitely be coming to you as a
surprise, but i must 
crave your indulgence to introduce myself to you.
 I am Miss Marah sadija, former mistress to the son
(Qusay) of the 
Iraqi former leader, Saddam Hussein.
I am an Ethiopian, by birth and i am presently in a
refugee camp in 
Zimbabwe, where the living conditions are
unbearable.
 I do not wish to take your time with a lenghty
mail, but i have to 
put this proposal to you so that you can assist me.
      While i was still in contact with Qusay,he
made a deposit in my 
name to a security firm in Spain, which has an
affiliate branch in 
Amsterdam.
This deposit was made in my name and the secret code
and necessary 
documents are presently in the possession of an
attorney, presently in 
London.
 This deposit was made in the form of a consigment
and the content is 
a considerable amount of money in United state
dollars which i cannot 
disclose to you for security purposes, until you
have confirmed your 
willingness to assist me.
I would be pleased and grateful to you if you could
assist me in 
collecting this consignment on my behalf from the
security firm in 
Spain, 
upon which i will be offering you a percentage for
your efforts.
The attorney in London, will arrange an authority to
release and pay 
in your name which you will tender to the security
firm coupled with 
all necessary documents that will back up your
claims in collecting 
this 
consignment on my behalf.
I have to stop here now as your response will
determine our
subsequent corresspondence. Please feel free to
dis-regard this 
proposal if it is not in line with your principles. 
For security reasons please reply to:
marahsadija at netscape.net
Allah bless you,
Marah Sadija



------------------------------------------
Use o melhor sistema de busca da Internet
Radar UOL - http://www.radaruol.com.br






From mschulz at rose.man.poznan.pl  Mon Feb 14 02:45:30 2005
From: mschulz at rose.man.poznan.pl (Michal Schulz)
Date: Mon, 14 Feb 2005 08:45:30 +0100 (CET)
Subject: Creating RAM partition??
In-Reply-To: <5.0.2.1.2.20050209161004.00b425b8@192.168.2.9>
References: <5.0.2.1.2.20050209161004.00b425b8@192.168.2.9>
Message-ID: <Pine.GSO.4.61.0502140844360.21825@rose.man.poznan.pl>

On Wed, 9 Feb 2005, Fabrizio Grasso wrote:

> I'd like to know if it's possible ( and how :) ) to create a RAM filesystem 
> which I can mount in R/W mode... at a specified RAM area.
[...]

You might want to have a look at this one:

http://hedera.linuxnews.pl/_news/2002/09/03/_long/1445.html

-- 
Michal Schulz




From martin at egholm-nielsen.dk  Mon Feb 14 03:37:45 2005
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Mon, 14 Feb 2005 09:37:45 +0100
Subject: Writing frequently to NAND - wearing, caching?
In-Reply-To: <4209AAC3.2090806@magellan-technology.com>
References: <ctsr0r$94m$1@sea.gmane.org>	<20050206220713.D99FE15504@desire.actrix.co.nz>	<cu7934$irr$1@sea.gmane.org>	<20050208000532.543131604C@desire.actrix.co.nz>
	<4209AAC3.2090806@magellan-technology.com>
Message-ID: <cupnsf$skj$1@sea.gmane.org>

Hi Aras,

>>>>> I have an application which may need to write states frequently to my
>>>>> nand-fs in order to have these states in case of powerdown.
>>>>> But I'm a bit concerned about wearing the nand if I write to 
>>>>> frequently.
>  > <snip>
>> (because we're not using explicite wear levelling) we still have only 
>> reached 24,000 - only 24% of the 100,000 cycle lifetime of the flash.
Thanks for the "comments" below - they are nice to have...

> ... and then there is the fact that the 100,000 write cycle limit is 
> generally a conservative estimate based on testing of the device at an 
> operating temperature of around 125 celcius! Most likely the device will 
> be able to withstand over to 1,000,000 write cycles before failure. If 
> your FS uses write verification to make sure the data is secure then you 
> shouldn't have any problems even if you do reach this limit on some 
> areas of the Flash.
> 
>  From the "Toshiba NAND Flash Applications Design Guide"
> 
> "NOR Flash is typically limited to around 100,000 cycles. Since the 
> electron flow-path due to the hot electron injection for programming is 
> different from the one due to tunneling from the floating gate to the 
> source for erasing, degradation is enhanced. However, in NAND Flash, 
> both the programming and erasing is achieved by uniform Fowler- Nordheim 
> tunneling between the floating gate and the substrate. This uniform 
> programming and uniform erasing technology guarantees a wide cell 
> threshold window even after 1,000,000 cycles."
> 
> and
> 
> "There is one question that often comes up  Is ECC really necessary?  
> After all, the likeliest cause of a bit error is during the programming 
> process. For example, if you program a block, then verify it has no 
> errors, how reliable is the data? In these ROM-like applications where 
> the write/erase cycles is very low, the actual failure rate for a block 
> is about 3 ppm after 10 years (i.e. 3 blocks out of every million blocks 
> will have a bit error after 10 years) in which a block failure is 
> defined as a single bit error. This result was derived from testing 
> 29708 pieces of 512Mb NAND (0.16um) by writing a checkerboard pattern 
> into blocks and storing at 125C. Since there will be a non-zero data 
> retention failure rate, you should limit the amount of code to 1 block 
> to achieve a low ppm probability of failure."




From kyungmin.park at samsung.com  Mon Feb 14 03:40:59 2005
From: kyungmin.park at samsung.com (kyungmin park)
Date: Mon, 14 Feb 2005 17:40:59 +0900
Subject: [RFC] adding support for OneNAND flash memory
Message-ID: <0IBW007DE84BOU@mmp1.samsung.com>

Dear,

I'm working on a MTD driver-level support for OneNAND flash memory.
OneNAND is a new type of fusion flash memory which has a small control logic inside.
It is connected to the CPU via NOR flash interface, but acts like NAND device.

At first, I've tried using the existing nand framework and extending it. However, due to the difference in the interfacing scheme, the existing nand framework needs to be modified heavily. 
This is due to the fact that every NAND command is directly written to the OneNAND controller register accessed via address bus, while the data is read through specific buffer accessed via address bus and read via data bus.

E.g., write operation
In NAND nature, basic operations are based on address/command latch enable.

1. send start address (ALE)
2. send write command (CLE)
3. write data
4. send write command (CLE)
5. send status command (CLE)
6. check status

But OneNAND operations are different from NAND flash.
The OneNAND uses register based access

1. select DataRAM* (REG)
2. write data into DataRAM
3. write block and page to Start Address Register (REG)
4. write Start Buffer Register (REG)
5. write 0 to interrupt register (REG)
6. write program command to command register (REG)
7. wait for write completed
8. read controller status register (REG)
9. check status
Note: (1) must happen before data input

So it's hard to apply OneNAND access method to current nand directory

Moreover,

To identify the OneNAND scheme is changed. There's no read id command.
Just it reads from device id register (read-only).
Also the device ids can be conflicted between NAND and OneNAND.

For this reason, I'd like to suggest adding another directory (ex. drivers/mtd/onenand) to mtd source tree for supporting OneNAND flash memory instead of modifying/extending existing nand framework.

Comments are always welcome.

Regards,

ps. for detailed info about OneNAND, please visit the following link http://www.samsung.com/Products/Semiconductor/Flash/OneNAND_TM/512Mbit/KFG1216Q2M/KFG1216Q2M.htm

--
 
Kyungmin Park
Embedded Linux Group, System Lab.
Samsung Electronics Co., Ltd.
E-mail: kyungmin.park at samsung.com
Office: +82-31-200-3109




From prasadamkumar at yahoo.com  Mon Feb 14 03:44:03 2005
From: prasadamkumar at yahoo.com (prasadam kumar)
Date: Mon, 14 Feb 2005 00:44:03 -0800 (PST)
Subject: how to write flash
Message-ID: <20050214084404.36072.qmail@web11604.mail.yahoo.com>


hai

I am working on intel IQ80321 flash, it is configured
as a char driver in my target side(/dev/mtd[0..7]) and
mapped as a rom flash (map_rom.c). If i want to write
Image to the flash with my existing setup. Is it
possible or not. plz help out from this

bye
ppk


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail



From dedekind at infradead.org  Mon Feb 14 03:58:33 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 14 Feb 2005 11:58:33 +0300
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <0IBW007DE84BOU@mmp1.samsung.com>
References: <0IBW007DE84BOU@mmp1.samsung.com>
Message-ID: <1108371513.26412.7.camel@sauron.oktetlabs.ru>

Hi,

I wonder is the bad block handling the same in case of OneNAND?


On Mon, 2005-02-14 at 17:40 +0900, kyungmin park wrote:
> Dear,
> 
> I'm working on a MTD driver-level support for OneNAND flash memory.
> OneNAND is a new type of fusion flash memory which has a small control logic inside.
> It is connected to the CPU via NOR flash interface, but acts like NAND device.
> 
> At first, I've tried using the existing nand framework and extending it. However, due to the difference in the interfacing scheme, the existing nand framework needs to be modified heavily. 
> This is due to the fact that every NAND command is directly written to the OneNAND controller register accessed via address bus, while the data is read through specific buffer accessed via address bus and read via data bus.
> 
> E.g., write operation
> In NAND nature, basic operations are based on address/command latch enable.
> 
> 1. send start address (ALE)
> 2. send write command (CLE)
> 3. write data
> 4. send write command (CLE)
> 5. send status command (CLE)
> 6. check status
> 
> But OneNAND operations are different from NAND flash.
> The OneNAND uses register based access
> 
> 1. select DataRAM* (REG)
> 2. write data into DataRAM
> 3. write block and page to Start Address Register (REG)
> 4. write Start Buffer Register (REG)
> 5. write 0 to interrupt register (REG)
> 6. write program command to command register (REG)
> 7. wait for write completed
> 8. read controller status register (REG)
> 9. check status
> Note: (1) must happen before data input
> 
> So it's hard to apply OneNAND access method to current nand directory
> 
> Moreover,
> 
> To identify the OneNAND scheme is changed. There's no read id command.
> Just it reads from device id register (read-only).
> Also the device ids can be conflicted between NAND and OneNAND.
> 
> or this reason, I'd like to suggest adding another directory (ex. drivers/mtd/onenand) to mtd source tree for supporting OneNAND flash memory instead of modifying/extending existing nand framework.
May be it makes sense to put it to drivers/mtd/nand/onenand if some
parts of the existing code (like BBT, etc) may be reused? Possibly,
you'll need to split the existing code on what is NAND-specific and what
is OK for both OneNAND and NAND.

And one more offer: the AG-AND support has been added directly to the
nand, but seems it would be nice to separate it and put to
drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
doesn't fit nicely to NAND stuff.

> 
> Comments are always welcome.
> 
> Regards,
> 
> ps. for detailed info about OneNAND, please visit the following link http://www.samsung.com/Products/Semiconductor/Flash/OneNAND_TM/512Mbit/KFG1216Q2M/KFG1216Q2M.htm
> 
> --
>  
> Kyungmin Park
> Embedded Linux Group, System Lab.
> Samsung Electronics Co., Ltd.
> E-mail: kyungmin.park at samsung.com
> Office: +82-31-200-3109
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From tglx at linutronix.de  Mon Feb 14 04:00:52 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 14 Feb 2005 10:00:52 +0100
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <0IBW007DE84BOU@mmp1.samsung.com>
References: <0IBW007DE84BOU@mmp1.samsung.com>
Message-ID: <1108371652.16612.247.camel@tglx.tec.linutronix.de>

Hi,

On Mon, 2005-02-14 at 17:40 +0900, kyungmin park wrote:
> For this reason, I'd like to suggest adding another directory 
> (ex. drivers/mtd/onenand) to mtd source tree for supporting OneNAND 
> flash memory instead of modifying/extending existing nand framework.

This makes sense. I had a look into OneNAND datasheets some time ago and
I can only agree that it does not fit into the NAND driver. 

tglx






From kyungmin.park at samsung.com  Mon Feb 14 05:05:13 2005
From: kyungmin.park at samsung.com (kyungmin park)
Date: Mon, 14 Feb 2005 19:05:13 +0900
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <1108371513.26412.7.camel@sauron.oktetlabs.ru>
Message-ID: <0IBW007DGC0POU@mmp1.samsung.com>

Hi,

I wonder is the bad block handling the same in case of OneNAND?

=> Yes, It's the same as NAND. With regard to bad block handling, IMHO, I
think it would be better to use Bad Block Management (replace based scheme)
instead of Bad Block Table (skip based scheme). However, it's another issue
(from this OneNAND thread).

On Mon, 2005-02-14 at 17:40 +0900, kyungmin park wrote:
> Dear,
> 
> I'm working on a MTD driver-level support for OneNAND flash memory.
> OneNAND is a new type of fusion flash memory which has a small control
logic inside.
> It is connected to the CPU via NOR flash interface, but acts like NAND
device.
> 
> At first, I've tried using the existing nand framework and extending it.
However, due to the difference in the interfacing scheme, the existing nand
framework needs to be modified heavily. 
> This is due to the fact that every NAND command is directly written to
the OneNAND controller register accessed via address bus, while the data is
read through specific buffer accessed via address bus and read via data bus.
> 
> E.g., write operation
> In NAND nature, basic operations are based on address/command latch
enable.
> 
> 1. send start address (ALE)
> 2. send write command (CLE)
> 3. write data
> 4. send write command (CLE)
> 5. send status command (CLE)
> 6. check status
> 
> But OneNAND operations are different from NAND flash.
> The OneNAND uses register based access
> 
> 1. select DataRAM* (REG)
> 2. write data into DataRAM
> 3. write block and page to Start Address Register (REG)
> 4. write Start Buffer Register (REG)
> 5. write 0 to interrupt register (REG)
> 6. write program command to command register (REG)
> 7. wait for write completed
> 8. read controller status register (REG)
> 9. check status
> Note: (1) must happen before data input
> 
> So it's hard to apply OneNAND access method to current nand directory
> 
> Moreover,
> 
> To identify the OneNAND scheme is changed. There's no read id command.
> Just it reads from device id register (read-only).
> Also the device ids can be conflicted between NAND and OneNAND.
> 
> or this reason, I'd like to suggest adding another directory (ex.
drivers/mtd/onenand) to mtd source tree for supporting OneNAND flash memory
instead of modifying/extending existing nand framework.

May be it makes sense to put it to drivers/mtd/nand/onenand if some
parts of the existing code (like BBT, etc) may be reused? Possibly,
you'll need to split the existing code on what is NAND-specific and what
is OK for both OneNAND and NAND.

=> As I said before, it's difficult to modify/extend current nand directory
to support OneNAND. That's why I suggested to add onenand directory.

And one more offer: the AG-AND support has been added directly to the
nand, but seems it would be nice to separate it and put to
drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
doesn't fit nicely to NAND stuff.

=> I agree, but it's another issue.

> 
> Comments are always welcome.
> 
> Regards,
> 
> ps. for detailed info about OneNAND, please visit the following link
http://www.samsung.com/Products/Semiconductor/Flash/OneNAND_TM/512Mbit/KFG12
16Q2M/KFG1216Q2M.htm
> 
> --
>  
> Kyungmin Park
> Embedded Linux Group, System Lab.
> Samsung Electronics Co., Ltd.
> E-mail: kyungmin.park at samsung.com
> Office: +82-31-200-3109
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/






From tglx at linutronix.de  Mon Feb 14 05:11:40 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 14 Feb 2005 11:11:40 +0100
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <1108371513.26412.7.camel@sauron.oktetlabs.ru>
References: <0IBW007DE84BOU@mmp1.samsung.com>
	<1108371513.26412.7.camel@sauron.oktetlabs.ru>
Message-ID: <1108375900.16612.280.camel@tglx.tec.linutronix.de>

On Mon, 2005-02-14 at 11:58 +0300, Artem B. Bityuckiy wrote:
> And one more offer: the AG-AND support has been added directly to the
> nand, but seems it would be nice to separate it and put to
> drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
> doesn't fit nicely to NAND stuff.

I don't see a real good reason to remove AG-AND from the NAND code. It
fits quite well and ripping it out would just duplicate 95% of the NAND
driver code. The tweaks to integrate AG-AND are really simple

tglx





From tglx at linutronix.de  Mon Feb 14 05:23:50 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 14 Feb 2005 11:23:50 +0100
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <0IBW007DGC0POU@mmp1.samsung.com>
References: <0IBW007DGC0POU@mmp1.samsung.com>
Message-ID: <1108376630.16612.294.camel@tglx.tec.linutronix.de>

Hi,

can you please fix your mail client to prepend the original text with ">
" ? It's hard to distiguish the original text and your answers.

On Mon, 2005-02-14 at 19:05 +0900, kyungmin park wrote:
> I wonder is the bad block handling the same in case of OneNAND?
> 
> => Yes, It's the same as NAND. With regard to bad block handling, IMHO, I
> think it would be better to use Bad Block Management (replace based scheme)
> instead of Bad Block Table (skip based scheme). However, it's another issue
> (from this OneNAND thread).

We use skip based scheme to allow filesystems to use the lowest level
and do their own management. It's no problem to add a replace based
scheme on top as the FLASH translation layers already do.

> May be it makes sense to put it to drivers/mtd/nand/onenand if some
> parts of the existing code (like BBT, etc) may be reused? Possibly,
> you'll need to split the existing code on what is NAND-specific and what
> is OK for both OneNAND and NAND.
> 
> => As I said before, it's difficult to modify/extend current nand directory
> to support OneNAND. That's why I suggested to add onenand directory.

It's not hard to extend. Just add onenand.c to it, if thats all what is
needed. The question is whether the bad block table code can be shared
or not. I agree that nand_base.c can not be tweaked for OneNAND.

> And one more offer: the AG-AND support has been added directly to the
> nand, but seems it would be nice to separate it and put to
> drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
> doesn't fit nicely to NAND stuff.
> 
> => I agree, but it's another issue.

I don't see a point to touch AG-AND support. AG-AND is NAND with some
extra features. As I said already it shares >90% of the NAND code.

It is more interesting whether OneNAND and superAND could share a fair
amount of code.

tglx





From kyungmin.park at samsung.com  Mon Feb 14 06:18:47 2005
From: kyungmin.park at samsung.com (kyungmin park)
Date: Mon, 14 Feb 2005 20:18:47 +0900
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <1108376630.16612.294.camel@tglx.tec.linutronix.de>
Message-ID: <0IBW0090KFFB9Z@mmp2.samsung.com>

[snip]
> May be it makes sense to put it to drivers/mtd/nand/onenand if some
> parts of the existing code (like BBT, etc) may be reused? Possibly,
> you'll need to split the existing code on what is NAND-specific and what
> is OK for both OneNAND and NAND.
> 
> => As I said before, it's difficult to modify/extend current nand
directory
> to support OneNAND. That's why I suggested to add onenand directory.

> It's not hard to extend. Just add onenand.c to it, if thats all what is
> needed. The question is whether the bad block table code can be shared
> or not. I agree that nand_base.c can not be tweaked for OneNAND.

Although OneNAND uses NAND core internally, the interface is very different
from NAND. The viewpoint of the hardware it seems to be connected with NOR.
Also OneNAND supports synchronous burst read as NOR does
I wonder the different interface of flash putting together is accptable?

Currently, I don't apply bad block table code to onenand. But I think
there's no problem to use current bbt code.





From tglx at linutronix.de  Mon Feb 14 06:23:47 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 14 Feb 2005 12:23:47 +0100
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <0IBW0090KFFB9Z@mmp2.samsung.com>
References: <0IBW0090KFFB9Z@mmp2.samsung.com>
Message-ID: <1108380228.16612.300.camel@tglx.tec.linutronix.de>

On Mon, 2005-02-14 at 20:18 +0900, kyungmin park wrote:
> [snip]
> > May be it makes sense to put it to drivers/mtd/nand/onenand if some
> > parts of the existing code (like BBT, etc) may be reused? Possibly,
> > you'll need to split the existing code on what is NAND-specific and what
> > is OK for both OneNAND and NAND.
> > 
> > => As I said before, it's difficult to modify/extend current nand
> directory
> > to support OneNAND. That's why I suggested to add onenand directory.
> 
> > It's not hard to extend. Just add onenand.c to it, if thats all what is
> > needed. The question is whether the bad block table code can be shared
> > or not. I agree that nand_base.c can not be tweaked for OneNAND.
> 
> Although OneNAND uses NAND core internally, the interface is very different
> from NAND. The viewpoint of the hardware it seems to be connected with NOR.
> Also OneNAND supports synchronous burst read as NOR does
> I wonder the different interface of flash putting together is accptable?
> 
> Currently, I don't apply bad block table code to onenand. But I think
> there's no problem to use current bbt code.

Ok, so I guess it makes sense to put it into drivers/mtd/onenand. If you
want to use the bbt code from nand it's no problem, just a tweak in
KConfig.

tglx





From tglx at linutronix.de  Mon Feb 14 06:29:58 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 14 Feb 2005 12:29:58 +0100
Subject: [RFC] adding support for OneNAND flash memory
In-Reply-To: <1108380228.16612.300.camel@tglx.tec.linutronix.de>
References: <0IBW0090KFFB9Z@mmp2.samsung.com>
	<1108380228.16612.300.camel@tglx.tec.linutronix.de>
Message-ID: <1108380598.16612.303.camel@tglx.tec.linutronix.de>

On Mon, 2005-02-14 at 12:23 +0100, Thomas Gleixner wrote:
> > 
> > Currently, I don't apply bad block table code to onenand. But I think
> > there's no problem to use current bbt code.
> 
> Ok, so I guess it makes sense to put it into drivers/mtd/onenand. If you
> want to use the bbt code from nand it's no problem, just a tweak in
> KConfig.

If you are going to implement a block replacement scheme, please put it
into a seperate file, so it can be used by others too. 

thanks

tglx






From niraj.maheshwari at gmail.com  Mon Feb 14 07:46:13 2005
From: niraj.maheshwari at gmail.com (Niraj Maheshwari)
Date: Mon, 14 Feb 2005 18:16:13 +0530
Subject: Compilation of MTD Utils
Message-ID: <f6d0cd0605021404467195684f@mail.gmail.com>

Hi,

I am trying to compile the MTD utils ( Specifically mkfs.jffs2  ) for
ARM-Linux platform. I am getting lot of errors while compiling this.
Does anyone already have mkfs.jffs2 executable for ARM-Linux platform
then pl. send it to me.

Or if you can help me how to do this compilation then it will be of
great help. I am getting following error. It's not able to find
deflate() etc functions.

arm-linux-gcc  -o mkfs.jffs2 crc32.o compr_rtime.o mkfs.jffs2.o
deftree.o deflate.o compr_zlib.o compr.o compr_lzari.o compr_lzo.o
-L./libz.so.1.1.4
compr_zlib.o(.text+0x34): In function `jffs2_zlib_compress':
/root/temp/mtd/util/compr_zlib.c:68: undefined reference to `deflateInit_'
compr_zlib.o(.text+0x98):/root/temp/mtd/util/compr_zlib.c:80:
undefined reference to `deflate'
compr_zlib.o(.text+0xe4):/root/temp/mtd/util/compr_zlib.c:88:
undefined reference to `deflate'
compr_zlib.o(.text+0xf4):/root/temp/mtd/util/compr_zlib.c:93:
undefined reference to `deflateEnd'
compr_zlib.o(.text+0x128):/root/temp/mtd/util/compr_zlib.c:82:
undefined reference to `deflateEnd'
compr_zlib.o(.text+0x158): In function `jffs2_zlib_decompress':
/root/temp/mtd/util/compr_zlib.c:113: undefined reference to `inflateInit_'
compr_zlib.o(.text+0x188):/root/temp/mtd/util/compr_zlib.c:124:
undefined reference to `inflate'
compr_zlib.o(.text+0x198):/root/temp/mtd/util/compr_zlib.c:127:
undefined reference to `inflateEnd'
collect2: ld returned 1 exit status
make: *** [mkfs.jffs2] Error 1

Thanks
Niraj



From dedekind at infradead.org  Mon Feb 14 08:24:24 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 14 Feb 2005 16:24:24 +0300
Subject: Bug in jffs2/scan.c re: incorrect assumption of "all clean"
	block
In-Reply-To: <002f01c50fc2$0d968ed0$6ffea8c0@banana>
References: <002f01c50fc2$0d968ed0$6ffea8c0@banana>
Message-ID: <1108387464.26412.9.camel@sauron.oktetlabs.ru>

Could you please send your JFFS2 dbg L1 output?

Is your flash NOR or NAND?

On Thu, 2005-02-10 at 16:44 -0600, Steven J. Magnani wrote:
> Hello MTD folk,
> 
> I'm not hooked into the MTD list so please cc: me on any replies. Also
> please note that this is my first experience with this code, so excuse
> me if I've gone off base.
> 
> I believe there is a bug in fs/jffs2/scan.c that causes it to
> incorrectly assume a block with a cleanmarker is "all clean". This
> causes an "Eep. Block 0xXXXXXXXX taken from free_list had free_size of
> 0xXXXXXXXX!!" to go off when jffs2_do_reserve_space() is called later.
> 
> There are 4 conditions that have to be met in a particular block for the
> bug to surface:
> 
> * The block has a cleanmarker
> * The end of the block has to be free space (0xFF)
> * The block has JFFS2_NODETYPE_INODEs
> * The block does NOT have any JFFS2_NODETYPE_DIRENTs
> 
> The test that governs the "all clean" assumption is as follows (cf.
> scan.c 1.118 line 435)
> 
> 	if (buf_ofs == jeb->offset && jeb->used_size ==
> PAD(c->cleanmarker_size) && 
> 	    c->cleanmarker_size && !jeb->dirty_size &&
> !jeb->first_node->next_in_ino) {
> 
> The bug is that there is no test that checks whether any
> JFFS2_NODETYPE_INODEs have been seen. Since only JFFS2_NODETYPE_DIRENTs
> are counted as used, and JFFS2_NODETYPE_INODEs are counted as unchecked,
> I think that the correction should look like this:
> 
> 	if (buf_ofs == jeb->offset && ((jeb->used_size +
> jeb->unchecked_size) == PAD(c->cleanmarker_size)) && 
> 	    c->cleanmarker_size && !jeb->dirty_size &&
> !jeb->first_node->next_in_ino) {
> 
> 
> This seems consistent with what is done at line 631:
> 
> 	if ((jeb->used_size + jeb->unchecked_size) ==
> PAD(c->cleanmarker_size) && !jeb->dirty_size 
> 		&& (!jeb->first_node || !jeb->first_node->next_in_ino) )
> 
> ...although the two are still not checking quite the same set of
> conditions.
> 
> Comments? I can provide a JFFS2 image that triggers the problem if
> someone is interested in stepping through it.
> 
> Steve Magnani
> Digital Design Corporation
> www.digidescorp.com
> 
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From dedekind at infradead.org  Mon Feb 14 08:37:39 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 14 Feb 2005 16:37:39 +0300
Subject: Compilation of MTD Utils
In-Reply-To: <f6d0cd0605021404467195684f@mail.gmail.com>
References: <f6d0cd0605021404467195684f@mail.gmail.com>
Message-ID: <1108388259.26412.11.camel@sauron.oktetlabs.ru>

On Mon, 2005-02-14 at 18:16 +0530, Niraj Maheshwari wrote:
> Hi,
> 
> I am trying to compile the MTD utils ( Specifically mkfs.jffs2  ) for
> ARM-Linux platform. I am getting lot of errors while compiling this.
> Does anyone already have mkfs.jffs2 executable for ARM-Linux platform
> then pl. send it to me.
> 
> Or if you can help me how to do this compilation then it will be of
> great help. I am getting following error. It's not able to find
> deflate() etc functions.
> 
Looks like you need to link zlib library...

> arm-linux-gcc  -o mkfs.jffs2 crc32.o compr_rtime.o mkfs.jffs2.o
> deftree.o deflate.o compr_zlib.o compr.o compr_lzari.o compr_lzo.o
> -L./libz.so.1.1.4
> compr_zlib.o(.text+0x34): In function `jffs2_zlib_compress':
> /root/temp/mtd/util/compr_zlib.c:68: undefined reference to `deflateInit_'
> compr_zlib.o(.text+0x98):/root/temp/mtd/util/compr_zlib.c:80:
> undefined reference to `deflate'
> compr_zlib.o(.text+0xe4):/root/temp/mtd/util/compr_zlib.c:88:
> undefined reference to `deflate'
> compr_zlib.o(.text+0xf4):/root/temp/mtd/util/compr_zlib.c:93:
> undefined reference to `deflateEnd'
> compr_zlib.o(.text+0x128):/root/temp/mtd/util/compr_zlib.c:82:
> undefined reference to `deflateEnd'
> compr_zlib.o(.text+0x158): In function `jffs2_zlib_decompress':
> /root/temp/mtd/util/compr_zlib.c:113: undefined reference to `inflateInit_'
> compr_zlib.o(.text+0x188):/root/temp/mtd/util/compr_zlib.c:124:
> undefined reference to `inflate'
> compr_zlib.o(.text+0x198):/root/temp/mtd/util/compr_zlib.c:127:
> undefined reference to `inflateEnd'
> collect2: ld returned 1 exit status
> make: *** [mkfs.jffs2] Error 1
> 
> Thanks
> Niraj
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From sharmilai at rapideffect.com  Mon Feb 14 09:03:28 2005
From: sharmilai at rapideffect.com (sharmila inamdar)
Date: Mon, 14 Feb 2005 19:33:28 +0530
Subject: M-systems linux driver 5.1.4 and INFTL
Message-ID: <002101c5129d$fc311e10$046464c7@sharmila>

We have recently received  128MB DOCs  (MD2202-D128). With the 5.1.4
utilities it is clear that it is DOC2000 TSOP and is using INFTL.

>From the list I understand that the MTD driver will support these DOCs on
kernel 2.6.x . But for certain time constraints, I have to use these DOCS on
Linux ( Redhat 6.2,kernel v 2.2.14).   I want to format these DOCs and put
file system on them.


We have been using M-sys old DOCS ,which are NTFL based, on this setup with
5.1.4 driver. But the same can not be utilized now.

For formatting I followed the documented procedure. i.e.

step-1 > formatted the DOC with DOS utilities and put the firmware
doc514.exb with /empty and /nodsos flag

step-2 -> in Linux, gave command fdisk /dev/msys/fla

and it says device can not be read .




What's wrong ?Does the M-sys driver (5.1.4) on Linux support these DOCs
?does it support INFTL ?
How do I go about this ?  I am not getting any sort of hint on this from
M-sys site or other sources.

..sharmila







From lists at ku-gbr.de  Mon Feb 14 09:36:02 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Mon, 14 Feb 2005 15:36:02 +0100
Subject: Oops in 2.6.10-rc2
Message-ID: <20050214143601.GB27046@synertronixx3>

Hi people!

I have an Oops in 2.6.10-rc2. Sadly I can't update to 2.6.10 so I want
to ask what in particular I should fix in 2.6.10-rc2 if this bug is
fixed already.

I can reproduce it:
flash bootloader, kernel, rootfs and adjust bootargs kernel cmdline to
match the layout. Then I boot kernel, system comes up without a hitch.
then scp rootfs.tar (some userspace binary additions) into /tmp which is
tmpfs. Then go to / and do tar xf /tmp/rootfs.tar:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 807 [#1]
CPU: 0                   
pc : [<c00926c8>]    lr : [<c01de994>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
sp : c031de18  ip : 00000000  fp : c031de68
r10: c026ff54  r9 : c031de34  r8 : c0261600
r7 : c026c830  r6 : c031de2c  r5 : 00000000  r4 : 000300d4
r3 : 00000000  r2 : 00000030  r1 : c026ff34  r0 : c026ff44
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C000317F  Table: 08C10000  DAC: 00000015
Stack: (0xc031de18 to 0xc031e000)
de00:                                                       c031de2c c031de34
de20: c0c4e4f4 c0c4d224 00000003 0000000c c0ebc002 c0021985 00000044 98f7fb1d
de40: 00000000 c0c4d298 c0eb74f4 c0c4d24c c0015ea4 c0c4d224 c031defc c031decc
de60: c031de6c c009a6c4 c0092134 00000000 0034ebb8 00000000 00000000 00000044
de80: 00000000 00000000 c0261600 c0c4e4f4 00011448 0034ebb8 00000000 f9126449
dea0: c0068160 c031defc 00000046 c0c4d24c 000041ed c0c7319c c031c000 0000fc80
dec0: c031def8 c031ded0 c0075428 c0099fe0 0000005a 3296684c c0c4d2b4 ffffffff
dee0: 00000000 c031df48 c00177e4 c031df44 c031defc c0059f04 c007531c 00000046
df00: c031df28 000001f5 00000064 c01b1000 c031df48 0000005a 3296684c 0000005a
df20: 3296684c 0000005a 3296684c 000001f5 000001f5 00000064 c031dfa4 c031df48
df40: c0059fd4 c0059e50 c0c7319c c0193360 00000007 c01b1004 00000000 00000000
df60: 00000001 00000000 c031df74 c005aec8 c005ab9c 00000400 00000000 00000000
df80: 00000200 4006db10 ffffffff 4006daa8 4006da68 00000010 00000000 c031dfa8
dfa0: c0017660 c0059fa0 ffffffff c001de44 4006daf8 000001f5 00000064 00000065
dfc0: ffffffff 4006daa8 4006da68 4006da68 4006daa8 00000000 0000fc80 00000000
dfe0: 0000ffff befffb84 0000f9f0 4005dfcc 80000010 4006daf8 00087805 00087806
Backtrace:
Function entered at [<c0092124>] from [<c009a6c4>]
Function entered at [<c0099fd0>] from [<c0075428>]
Function entered at [<c007530c>] from [<c0059f04>]
 r8 = C00177E4  r7 = C031DF48  r6 = 00000000  r5 = FFFFFFFF
 r4 = C0C4D2B4
Function entered at [<c0059e40>] from [<c0059fd4>]
 r5 = 00000064  r4 = 000001F5
Function entered at [<c0059f90>] from [<c0017660>]
 r7 = 00000010  r6 = 4006DA68  r5 = 4006DAA8  r4 = FFFFFFFF
Code: 0587a02c e5903000 e3530000 13a03000 (15833000)


>>EIP; c00926c8 <jffs2_mark_node_obsolete+5a4/664>   <=====
                         
Trace; c0092124 <jffs2_mark_node_obsolete+0/664>
Trace; c009a6c4 <jffs2_do_setattr+6f4/780>
Trace; c0099fd0 <jffs2_do_setattr+0/780>
Trace; c0075428 <notify_change+11c/184>
Trace; c007530c <notify_change+0/184>
Trace; c0059f04 <chown_common+c4/f8>
                         
>>r8; c00177e4 <sys_call_table+0/0>
                         
Trace; c0059e40 <chown_common+0/f8>
Trace; c0059fd4 <sys_lchown+44/58>
Trace; c0059f90 <sys_lchown+0/58>
Trace; c0017660 <ret_fast_syscall+0/2c>
                         
Code;  c00926b8 <jffs2_mark_node_obsolete+594/664>
00000000 <_EIP>:         
Code;  c00926b8 <jffs2_mark_node_obsolete+594/664>
   0:   2c a0                     sub    $0xa0,%al
Code;  c00926ba <jffs2_mark_node_obsolete+596/664>
   2:   87 05 00 30 90 e5         xchg   %eax,0xe5903000
Code;  c00926c0 <jffs2_mark_node_obsolete+59c/664>
   8:   00 00                     add    %al,(%eax)
Code;  c00926c2 <jffs2_mark_node_obsolete+59e/664>
   a:   53                        push   %ebx
Code;  c00926c3 <jffs2_mark_node_obsolete+59f/664>
   b:   e3 00                     jecxz  d <_EIP+0xd>
Code;  c00926c5 <jffs2_mark_node_obsolete+5a1/664>   <=====
   d:   30 a0 13 00 30 83         xor    %ah,0x83300013(%eax)   <=====
Code;  c00926cb <jffs2_mark_node_obsolete+5a7/664>
  13:   15 00 00 00 00            adc    $0x0,%eax


My question is if this bug is fixed, which changes from 10-rc2 to 10
are concerned by the fix? I can't update because porting my usb stuff
will take ages and I don't wan't to destabilize things which are stable
now (well, all except this one).

REgards, Konstantin Kletschke

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From wjbeksi at setabox.com  Wed Feb  9 03:27:49 2005
From: wjbeksi at setabox.com (William J Beksi)
Date: Wed, 09 Feb 2005 16:27:49 +0800
Subject: [PATCH] accessing NAND flash through an IDE interface
Message-ID: <4209C985.3020902@setabox.com>

Hi Thomas,
I am not sure if you received the patch I sent you last month for 
accessing nand flash through an IDE interface so I am sending it again.

I think some people may find it useful.

Thank you.

-- 
William J Beksi                          <wjbeksi at users.sourceforge.net>
GPG Key Fingerprint = ED4B 32C3 69E6 C2B7 705C  263F CB2F 3253 E7E1 DB3B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ide.c
Type: text/x-c
Size: 3946 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050209/f8acdfdf/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd-ide-patch.diff
Type: text/x-patch
Size: 3632 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050209/f8acdfdf/attachment-0001.bin 

From f.janot at ateme.fr  Mon Feb 14 12:08:41 2005
From: f.janot at ateme.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Janot?=)
Date: Mon, 14 Feb 2005 18:08:41 +0100
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
Message-ID: <4210DB19.9000808@ateme.fr>

Hi,

I have a board with samsung K9F5608UOC nand flash and mpc5200 ppc processor.
I run a 2.4.25 kernel (yes I know it's very old) on this board with mtd 
from 20041007 snapshot.

I burn a jffs2 image on the nand with "nandwrite -j" (from nfs). All is 
ok and the filesystem is good but
when I reboot the board or when I remove the power "violently", I get 
somes messages like this :
/Empty flash at 0x009826d8 ends at 0x00982800
jffs2_get_inode_nodes(): Data CRC failed on node at 0x00cc0f90: Read 
0x6e17981a,  calculated 0x4614a389
/And I get one more message each time I reboot the board. But the 
filesystem doesn't seem corrupted.

If I umount / before rebooting, I don't have one more error message at 
the next reboot.

Here is my kernel command line (passed from uboot). Do I forget some 
mount options ?
/Kernel command line: root=/dev/mtdblock3 rw 
ip=172.16.48.19:172.16.16.240:172.16 .254.254:255.255.0.0::eth0:off panic=1
/
Do you have any idea about where the problem could come from ?

Frederic.

PS: sorry for my poor english.





From estelle.hammache at st.com  Mon Feb 14 12:24:43 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Mon, 14 Feb 2005 18:24:43 +0100
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
References: <4210DB19.9000808@ateme.fr>
Message-ID: <4210DEDB.DD35E2DE@st.com>

Fr?d?ric Janot wrote:
> 
> Hi,
> 
> I have a board with samsung K9F5608UOC nand flash and mpc5200 ppc processor.

JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when
it is full, or when you do fsync, sync or umount.

> when I reboot the board or when I remove the power "violently"

Some data may remain in the page buffer and is never written
to the Flash.

> jffs2_get_inode_nodes(): Data CRC failed on node at 0x00cc0f90: Read
> 0x6e17981a,  calculated 0x4614a389

Well obviously a node was partly written to flash and the end of the
node remained in the cache and was never written. This means you
lost some data.

> /And I get one more message each time I reboot the board. But the
> filesystem doesn't seem corrupted.

It is a warning only. The remainder of the file system will probably
still work. Only the last operation(s) before reboot are lost.

> If I umount / before rebooting, I don't have one more error message at
> the next reboot.

This is correct procedure if you don't want to lose any data.

> Do you have any idea about where the problem could come from ?

There is no problem. This is standard JFFS2 processing. Nodes with
wrong CRCs (partly written for instance) are ignored and not taken 
in account when building the FS tree and files.

Estelle



From joern at wohnheim.fh-wedel.de  Mon Feb 14 12:52:51 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 14 Feb 2005 18:52:51 +0100
Subject: [PATCH 8/18] drivers/mtd/ remove pci_find_{device, subsys}
In-Reply-To: <200502141122.11786.amitg@calsoftinc.com>
Message-ID: <20050214175251.GA28755@wohnheim.fh-wedel.de>

Looks fairly simple, but I've never dealt with pci_find_device(), so
my voice doesn't count.

dwmw2, is this ok?

On Mon, 14 February 2005 11:22:06 +0530, Amit Gud wrote:
> 
> Remove deprecated pci_find_device and pci_find_subsys
> 
> 
> AG
> --
> May the source be with you
> 
> 
> Signed-off-by: Amit Gud <gud at eth.net>
> 
> 
> diff -uprN orig/drivers/mtd/devices/pmc551.c linux-2.6.11-rc3/drivers/mtd/devices/pmc551.c
> --- orig/drivers/mtd/devices/pmc551.c	2005-02-11 15:19:47.000000000 +0530
> +++ linux-2.6.11-rc3/drivers/mtd/devices/pmc551.c	2005-02-14 02:34:15.000000000 +0530
> @@ -680,7 +680,7 @@ static int __init init_pmc551(void)
>           */
>          for( count = 0; count < MAX_MTD_DEVICES; count++ ) {
>  
> -                if ((PCI_Device = pci_find_device(PCI_VENDOR_ID_V3_SEMI,
> +                if ((PCI_Device = pci_get_device(PCI_VENDOR_ID_V3_SEMI,
>                                                    PCI_DEVICE_ID_V3_SEMI_V370PDC,
>  						  PCI_Device ) ) == NULL) {
>                          break;
> diff -uprN orig/drivers/mtd/maps/amd76xrom.c linux-2.6.11-rc3/drivers/mtd/maps/amd76xrom.c
> --- orig/drivers/mtd/maps/amd76xrom.c	2005-02-11 15:19:47.000000000 +0530
> +++ linux-2.6.11-rc3/drivers/mtd/maps/amd76xrom.c	2005-02-14 02:34:21.000000000 +0530
> @@ -304,7 +304,7 @@ static int __init init_amd76xrom(void)
>  	struct pci_device_id *id;
>  	pdev = NULL;
>  	for(id = amd76xrom_pci_tbl; id->vendor; id++) {
> -		pdev = pci_find_device(id->vendor, id->device, NULL);
> +		pdev = pci_get_device(id->vendor, id->device, NULL);
>  		if (pdev) {
>  			break;
>  		}
> diff -uprN orig/drivers/mtd/maps/ich2rom.c linux-2.6.11-rc3/drivers/mtd/maps/ich2rom.c
> --- orig/drivers/mtd/maps/ich2rom.c	2004-10-19 03:25:35.000000000 +0530
> +++ linux-2.6.11-rc3/drivers/mtd/maps/ich2rom.c	2005-02-14 02:34:26.000000000 +0530
> @@ -288,7 +288,7 @@ int __init init_ich2rom(void)
>  	struct pci_device_id *id;
>  	pdev = NULL;
>  	for(id = ich2rom_pci_tbl; id->vendor; id++) {
> -		pdev = pci_find_device(id->vendor, id->device, NULL);
> +		pdev = pci_get_device(id->vendor, id->device, NULL);
>  		if (pdev) {
>  			break;
>  		}
> diff -uprN orig/drivers/mtd/maps/ichxrom.c linux-2.6.11-rc3/drivers/mtd/maps/ichxrom.c
> --- orig/drivers/mtd/maps/ichxrom.c	2005-02-11 15:19:47.000000000 +0530
> +++ linux-2.6.11-rc3/drivers/mtd/maps/ichxrom.c	2005-02-14 02:34:31.000000000 +0530
> @@ -356,7 +356,7 @@ static int __init init_ichxrom(void)
>  
>  	pdev = NULL;
>  	for (id = ichxrom_pci_tbl; id->vendor; id++) {
> -		pdev = pci_find_device(id->vendor, id->device, NULL);
> +		pdev = pci_get_device(id->vendor, id->device, NULL);
>  		if (pdev) {
>  			break;
>  		}
> diff -uprN orig/drivers/mtd/maps/l440gx.c linux-2.6.11-rc3/drivers/mtd/maps/l440gx.c
> --- orig/drivers/mtd/maps/l440gx.c	2005-02-11 15:19:47.000000000 +0530
> +++ linux-2.6.11-rc3/drivers/mtd/maps/l440gx.c	2005-02-14 02:34:44.000000000 +0530
> @@ -62,10 +62,10 @@ static int __init init_l440gx(void)
>  	struct resource *pm_iobase;
>  	__u16 word;
>  
> -	dev = pci_find_device(PCI_VENDOR_ID_INTEL, 
> +	dev = pci_get_device(PCI_VENDOR_ID_INTEL, 
>  		PCI_DEVICE_ID_INTEL_82371AB_0, NULL);
>  
> -	pm_dev = pci_find_device(PCI_VENDOR_ID_INTEL, 
> +	pm_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 
>  		PCI_DEVICE_ID_INTEL_82371AB_3, NULL);
>  
>  	if (!dev || !pm_dev) {
> diff -uprN orig/drivers/mtd/maps/scx200_docflash.c linux-2.6.11-rc3/drivers/mtd/maps/scx200_docflash.c
> --- orig/drivers/mtd/maps/scx200_docflash.c	2005-02-11 15:19:47.000000000 +0530
> +++ linux-2.6.11-rc3/drivers/mtd/maps/scx200_docflash.c	2005-02-14 02:34:50.000000000 +0530
> @@ -88,7 +88,7 @@ static int __init init_scx200_docflash(v
>  
>  	printk(KERN_DEBUG NAME ": NatSemi SCx200 DOCCS Flash Driver\n");
>  
> -	if ((bridge = pci_find_device(PCI_VENDOR_ID_NS, 
> +	if ((bridge = pci_get_device(PCI_VENDOR_ID_NS, 
>  				      PCI_DEVICE_ID_NS_SCx200_BRIDGE,
>  				      NULL)) == NULL)
>  		return -ENODEV;

J?rn

-- 
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall 



From f.janot at ateme.fr  Mon Feb 14 12:58:27 2005
From: f.janot at ateme.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Janot?=)
Date: Mon, 14 Feb 2005 18:58:27 +0100
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <4210DEDB.DD35E2DE@st.com>
References: <4210DB19.9000808@ateme.fr> <4210DEDB.DD35E2DE@st.com>
Message-ID: <4210E6C3.9030208@ateme.fr>

Estelle,

Thanks for this very fast answer !!!

Estelle HAMMACHE wrote:

>JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when
>it is full, or when you do fsync, sync or umount.
>  
>
Does that mean that I have to call fsync each time after fclose a file ?
Even if I do not edit some files, I get this kind of error. Does that 
mean something (jffs2 itself or other) write some data to the flash all 
the time ?

>Some data may remain in the page buffer and is never written
>to the Flash.
>  
>
So I really loose some data :(

>>If I umount / before rebooting, I don't have one more error message at
>>the next reboot.
>>    
>>
>
>This is correct procedure if you don't want to lose any data.
>  
>
It is an embedded board without power supervisor. I cannot detect when 
the customer power down the board :(

Frederic




From tglx at linutronix.de  Mon Feb 14 13:04:09 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 14 Feb 2005 19:04:09 +0100
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <4210E6C3.9030208@ateme.fr>
References: <4210DB19.9000808@ateme.fr> <4210DEDB.DD35E2DE@st.com>
	<4210E6C3.9030208@ateme.fr>
Message-ID: <1108404250.16612.327.camel@tglx.tec.linutronix.de>

On Mon, 2005-02-14 at 18:58 +0100, Fr?d?ric Janot wrote:
> >JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when
> >it is full, or when you do fsync, sync or umount.
> >
> Does that mean that I have to call fsync each time after fclose a file ?
> Even if I do not edit some files, I get this kind of error. Does that 
> mean something (jffs2 itself or other) write some data to the flash all 
> the time ?

No, jffs2 does not write data just for fun. There is some application,
script, daemon writing/modifying file(s).

tglx





From jdub at us.ibm.com  Mon Feb 14 13:08:01 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Mon, 14 Feb 2005 12:08:01 -0600
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <4210E6C3.9030208@ateme.fr>
References: <4210DB19.9000808@ateme.fr> <4210DEDB.DD35E2DE@st.com>
	<4210E6C3.9030208@ateme.fr>
Message-ID: <1108404481.7790.2.camel@windu.rchland.ibm.com>

On Mon, 2005-02-14 at 18:58 +0100, Fr?d?ric Janot wrote:
> >
> Does that mean that I have to call fsync each time after fclose a file ?
> Even if I do not edit some files, I get this kind of error. Does that 
> mean something (jffs2 itself or other) write some data to the flash all 
> the time ?

Sorta.  See below.

> 
> >Some data may remain in the page buffer and is never written
> >to the Flash.
> >  
> >
> So I really loose some data :(

Maybe not.  It could be a GC node that was cut short.  In that case, you
shouldn't loose any data since the original node should still be in
place.

> It is an embedded board without power supervisor. I cannot detect when 
> the customer power down the board :(

If you are worried about data loss, then fsync/sync is probably what you
should do.

josh




From greg at kroah.com  Mon Feb 14 13:40:08 2005
From: greg at kroah.com (Greg KH)
Date: Mon, 14 Feb 2005 10:40:08 -0800
Subject: [KJ] Re: [PATCH 8/18] drivers/mtd/ remove pci_find_{device,
	subsys}
In-Reply-To: <20050214175251.GA28755@wohnheim.fh-wedel.de>
References: <200502141122.11786.amitg@calsoftinc.com>
	<20050214175251.GA28755@wohnheim.fh-wedel.de>
Message-ID: <20050214184007.GF7815@kroah.com>

On Mon, Feb 14, 2005 at 06:52:51PM +0100, J?rn Engel wrote:
> Looks fairly simple, but I've never dealt with pci_find_device(), so
> my voice doesn't count.
> 
> dwmw2, is this ok?

No it isn't, please do not apply.  See my KJ response for why it is not
correct.

thanks,

greg k-h



From ebiederman at lnxi.com  Mon Feb 14 13:41:22 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: 14 Feb 2005 11:41:22 -0700
Subject: [PATCH 8/18] drivers/mtd/ remove pci_find_{device, subsys}
In-Reply-To: <20050214175251.GA28755@wohnheim.fh-wedel.de>
References: <20050214175251.GA28755@wohnheim.fh-wedel.de>
Message-ID: <m3fyzzx9v1.fsf@maxwell.lnxi.com>

J?rn Engel <joern at wohnheim.fh-wedel.de> writes:

> Looks fairly simple, but I've never dealt with pci_find_device(), so
> my voice doesn't count.

When switching from pci_find_device to pci_get_device
the corresponding call to pci_dev_put() needs to be added.

In addition we need an entry in compat.h

Beyond that ich2rom.c should just be deleted.  It was renamed
ichxrom.c a while ago.

Eric



From dwmw2 at infradead.org  Mon Feb 14 19:03:06 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 15 Feb 2005 00:03:06 +0000
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <1108404250.16612.327.camel@tglx.tec.linutronix.de>
References: <4210DB19.9000808@ateme.fr> <4210DEDB.DD35E2DE@st.com>
	<4210E6C3.9030208@ateme.fr>
	<1108404250.16612.327.camel@tglx.tec.linutronix.de>
Message-ID: <1108425786.22597.6.camel@baythorne.infradead.org>

On Mon, 2005-02-14 at 19:04 +0100, Thomas Gleixner wrote:
> On Mon, 2005-02-14 at 18:58 +0100, Fr?d?ric Janot wrote:
> > >JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when
> > >it is full, or when you do fsync, sync or umount.
> > >
> > Does that mean that I have to call fsync each time after fclose a file ?

Yes. It's precisely the same as with other file systems. If you write to
a file, close it and then lose power immediately, your data may be lost.
It's not guaranteed to be on the medium until you sync.

> > Even if I do not edit some files, I get this kind of error. Does that 
> > mean something (jffs2 itself or other) write some data to the flash all 
> > the time ?
> 
> No, jffs2 does not write data just for fun. There is some application,
> script, daemon writing/modifying file(s).

Or garbage collection, but in that case no data are lost. It was just
copying from one part of the flash to another, and the old copy will
still be intact.

-- 
dwmw2





From sean.sweng at gmail.com  Mon Feb 14 21:47:56 2005
From: sean.sweng at gmail.com (Sean Kelley)
Date: Mon, 14 Feb 2005 20:47:56 -0600
Subject: Linux MTD and NFTL - Question
Message-ID: <43507b7c0502141847134e1e68@mail.gmail.com>

I've been looking into an NFTL implementation for a device that uses a
NAND part and needs to be mounted on a Window's PC Desktop.  Thus I
need a Block Device interface so as to present a surface on which a
FAT filesystem can be placed.  However, in the course of my research
it came to my attention that a company called M-Systems has a hefty
amount of IP with regards to FTL and NFTL for pseudo-block devices. 
How does the Linux MTD-NFTL skirt the patents that M-Systems has in
place?  If I want to sell my product commercially what sort of risk? 
It is not terribly clear.  I've looked at YAFFS and JFFS2, but those
won't work if I wish to support USB mass storage for the Windows
desktop.

Any comments on NFTL and M-Systems patents much appreciated.

Thanks,

Sean



From dwmw2 at infradead.org  Tue Feb 15 02:48:05 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 15 Feb 2005 07:48:05 +0000
Subject: Linux MTD and NFTL - Question
In-Reply-To: <43507b7c0502141847134e1e68@mail.gmail.com>
References: <43507b7c0502141847134e1e68@mail.gmail.com>
Message-ID: <1108453685.22597.30.camel@baythorne.infradead.org>

On Mon, 2005-02-14 at 20:47 -0600, Sean Kelley wrote:
> However, in the course of my research it came to my attention that a
> company called M-Systems has a hefty amount of IP with regards to FTL
> and NFTL for pseudo-block devices. How does the Linux MTD-NFTL skirt
> the patents that M-Systems has in place?  If I want to sell my product
> commercially what sort of risk? It is not terribly clear. 

In general, we only really use FTL/NFTL/INFTL for backwards
compatibility on devices which already had it when we started. The block
device emulation thing just doesn't make much sense now that we're not
running on DOS where we have to provide an INT 13h disk BIOS handler.

So even outside the Free World it's never really been much of an issue,
because that means we tend to operate within the licence which was
granted for use on PCMCIA devices (for FTL) or for use on M-Systems
hardware (NFTL).

I'm happy enough shipping the code like that, following the precedent
set by David Hinds with FTL in pcmcia-cs. AFAICT the GPL doesn't
actually specify that you have to be able to _use_ the code without
restrictions -- only to copy, modify and redistribute it. I could write
GPL'd code for running a nuclear power plant, for example -- but I
suspect the authorities will be less than amused if you try to _use_ it.

If you're in a part of the world where the patents apply, and you think
that they're sufficiently non-obvious or the patent office is
sufficiently corrupt that you'd stand a good chance of losing in court
when you try to challenge them, then you probably shouldn't be using the
techniques outside the terms of the licence granted by M-Systems. You
should consult a patent lawyer though.

> > I've looked at YAFFS and JFFS2, but those won't work if I wish to
> > support USB mass storage for the Windows desktop.

Does it have to be USB mass storage? What about the file system profile
which is used with cameras? That should work when backed by JFFS2.

-- 
dwmw2





From dedekind at infradead.org  Tue Feb 15 03:04:48 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 15 Feb 2005 11:04:48 +0300
Subject: Bug in jffs2/scan.c re: incorrect assumption of "all clean"block
In-Reply-To: <004a01c512c2$60b92930$6ffea8c0@banana>
References: <004a01c512c2$60b92930$6ffea8c0@banana>
Message-ID: <1108454688.26412.18.camel@sauron.oktetlabs.ru>

Well, I've looked trough your debug output and the code and think the
following patch should fix the bug.

On Mon, 2005-02-14 at 12:24 -0600, Steven J. Magnani wrote:
> Artem -
> 
> I'm assuming when you say "JFFS2 dbg L1 output" you mean the kernel log
> contents when CONFIG_JFFS2_FS_DEBUG=1. That seems to be WAY too much
> output for the kernel to handle.
> 
> I built a kernel with just scan.c at L1 debugging, the output is
> attached. This is completely reproducible the first time I mount this
> image created by mkfs.jffs2.
> 
> The part is NOR flash (Intel 28F320C3).
> 
> Steve
> 
> -----Original Message-----
> From: Artem B. Bityuckiy [mailto:dedekind at infradead.org] 
> Sent: Monday, February 14, 2005 7:24 AM
> To: Steven J. Magnani
> Cc: linux-mtd at lists.infradead.org
> Subject: Re: Bug in jffs2/scan.c re: incorrect assumption of "all
> clean"block
> 
> 
> Could you please send your JFFS2 dbg L1 output?
> 
> Is your flash NOR or NAND?
> 
> On Thu, 2005-02-10 at 16:44 -0600, Steven J. Magnani wrote:
> > Hello MTD folk,
> > 
> > I'm not hooked into the MTD list so please cc: me on any replies. Also
> 
> > please note that this is my first experience with this code, so excuse
> 
> > me if I've gone off base.
> > 
> > I believe there is a bug in fs/jffs2/scan.c that causes it to 
> > incorrectly assume a block with a cleanmarker is "all clean". This 
> > causes an "Eep. Block 0xXXXXXXXX taken from free_list had free_size of
> 
> > 0xXXXXXXXX!!" to go off when jffs2_do_reserve_space() is called later.
> > 
> > There are 4 conditions that have to be met in a particular block for 
> > the bug to surface:
> > 
> > * The block has a cleanmarker
> > * The end of the block has to be free space (0xFF)
> > * The block has JFFS2_NODETYPE_INODEs
> > * The block does NOT have any JFFS2_NODETYPE_DIRENTs
> > 
> > The test that governs the "all clean" assumption is as follows (cf. 
> > scan.c 1.118 line 435)
> > 
> > 	if (buf_ofs == jeb->offset && jeb->used_size ==
> > PAD(c->cleanmarker_size) && 
> > 	    c->cleanmarker_size && !jeb->dirty_size &&
> > !jeb->first_node->next_in_ino) {
> > 
> > The bug is that there is no test that checks whether any 
> > JFFS2_NODETYPE_INODEs have been seen. Since only 
> > JFFS2_NODETYPE_DIRENTs are counted as used, and JFFS2_NODETYPE_INODEs 
> > are counted as unchecked, I think that the correction should look like
> 
> > this:
> > 
> > 	if (buf_ofs == jeb->offset && ((jeb->used_size +
> > jeb->unchecked_size) == PAD(c->cleanmarker_size)) &&
> > 	    c->cleanmarker_size && !jeb->dirty_size &&
> > !jeb->first_node->next_in_ino) {
> > 
> > 
> > This seems consistent with what is done at line 631:
> > 
> > 	if ((jeb->used_size + jeb->unchecked_size) ==
> > PAD(c->cleanmarker_size) && !jeb->dirty_size 
> > 		&& (!jeb->first_node || !jeb->first_node->next_in_ino) )
> > 
> > ...although the two are still not checking quite the same set of 
> > conditions.
> > 
> > Comments? I can provide a JFFS2 image that triggers the problem if 
> > someone is interested in stepping through it.
> > 
> > Steve Magnani
> > Digital Design Corporation
> > www.digidescorp.com
> > 
> > 
> > 
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list 
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scan.c.diff
Type: text/x-patch
Size: 651 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050215/6ff052ab/attachment.bin 

From dedekind at infradead.org  Tue Feb 15 05:33:31 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 15 Feb 2005 13:33:31 +0300
Subject: Oops in 2.6.10-rc2
In-Reply-To: <20050214143601.GB27046@synertronixx3>
References: <20050214143601.GB27046@synertronixx3>
Message-ID: <1108463611.26412.27.camel@sauron.oktetlabs.ru>

On Mon, 2005-02-14 at 15:36 +0100, Konstantin Kletschke wrote:
> Hi people!
> 
> I have an Oops in 2.6.10-rc2. Sadly I can't update to 2.6.10 so I want
> to ask what in particular I should fix in 2.6.10-rc2 if this bug is
> fixed already.
> 
> I can reproduce it:
> flash bootloader, kernel, rootfs and adjust bootargs kernel cmdline to
> match the layout. Then I boot kernel, system comes up without a hitch.
> then scp rootfs.tar (some userspace binary additions) into /tmp which is
> tmpfs. Then go to / and do tar xf /tmp/rootfs.tar:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> Internal error: Oops: 807 [#1]
> CPU: 0                   
> pc : [<c00926c8>]    lr : [<c01de994>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> sp : c031de18  ip : 00000000  fp : c031de68
> r10: c026ff54  r9 : c031de34  r8 : c0261600
> r7 : c026c830  r6 : c031de2c  r5 : 00000000  r4 : 000300d4
> r3 : 00000000  r2 : 00000030  r1 : c026ff34  r0 : c026ff44
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: C000317F  Table: 08C10000  DAC: 00000015
> Stack: (0xc031de18 to 0xc031e000)
> de00:                                                       c031de2c c031de34
> de20: c0c4e4f4 c0c4d224 00000003 0000000c c0ebc002 c0021985 00000044 98f7fb1d
> de40: 00000000 c0c4d298 c0eb74f4 c0c4d24c c0015ea4 c0c4d224 c031defc c031decc
> de60: c031de6c c009a6c4 c0092134 00000000 0034ebb8 00000000 00000000 00000044
> de80: 00000000 00000000 c0261600 c0c4e4f4 00011448 0034ebb8 00000000 f9126449
> dea0: c0068160 c031defc 00000046 c0c4d24c 000041ed c0c7319c c031c000 0000fc80
> dec0: c031def8 c031ded0 c0075428 c0099fe0 0000005a 3296684c c0c4d2b4 ffffffff
> dee0: 00000000 c031df48 c00177e4 c031df44 c031defc c0059f04 c007531c 00000046
> df00: c031df28 000001f5 00000064 c01b1000 c031df48 0000005a 3296684c 0000005a
> df20: 3296684c 0000005a 3296684c 000001f5 000001f5 00000064 c031dfa4 c031df48
> df40: c0059fd4 c0059e50 c0c7319c c0193360 00000007 c01b1004 00000000 00000000
> df60: 00000001 00000000 c031df74 c005aec8 c005ab9c 00000400 00000000 00000000
> df80: 00000200 4006db10 ffffffff 4006daa8 4006da68 00000010 00000000 c031dfa8
> dfa0: c0017660 c0059fa0 ffffffff c001de44 4006daf8 000001f5 00000064 00000065
> dfc0: ffffffff 4006daa8 4006da68 4006da68 4006daa8 00000000 0000fc80 00000000
> dfe0: 0000ffff befffb84 0000f9f0 4005dfcc 80000010 4006daf8 00087805 00087806
> Backtrace:
> Function entered at [<c0092124>] from [<c009a6c4>]
> Function entered at [<c0099fd0>] from [<c0075428>]
> Function entered at [<c007530c>] from [<c0059f04>]
>  r8 = C00177E4  r7 = C031DF48  r6 = 00000000  r5 = FFFFFFFF
>  r4 = C0C4D2B4
> Function entered at [<c0059e40>] from [<c0059fd4>]
>  r5 = 00000064  r4 = 000001F5
> Function entered at [<c0059f90>] from [<c0017660>]
>  r7 = 00000010  r6 = 4006DA68  r5 = 4006DAA8  r4 = FFFFFFFF
> Code: 0587a02c e5903000 e3530000 13a03000 (15833000)
> 
> 
> >>EIP; c00926c8 <jffs2_mark_node_obsolete+5a4/664>   <=====
>                          
> Trace; c0092124 <jffs2_mark_node_obsolete+0/664>
> Trace; c009a6c4 <jffs2_do_setattr+6f4/780>
> Trace; c0099fd0 <jffs2_do_setattr+0/780>
> Trace; c0075428 <notify_change+11c/184>
> Trace; c007530c <notify_change+0/184>
> Trace; c0059f04 <chown_common+c4/f8>
>                          
> >>r8; c00177e4 <sys_call_table+0/0>
>                          
> Trace; c0059e40 <chown_common+0/f8>
> Trace; c0059fd4 <sys_lchown+44/58>
> Trace; c0059f90 <sys_lchown+0/58>
> Trace; c0017660 <ret_fast_syscall+0/2c>
>                          
> Code;  c00926b8 <jffs2_mark_node_obsolete+594/664>
> 00000000 <_EIP>:         
> Code;  c00926b8 <jffs2_mark_node_obsolete+594/664>
>    0:   2c a0                     sub    $0xa0,%al
> Code;  c00926ba <jffs2_mark_node_obsolete+596/664>
>    2:   87 05 00 30 90 e5         xchg   %eax,0xe5903000
> Code;  c00926c0 <jffs2_mark_node_obsolete+59c/664>
>    8:   00 00                     add    %al,(%eax)
> Code;  c00926c2 <jffs2_mark_node_obsolete+59e/664>
>    a:   53                        push   %ebx
> Code;  c00926c3 <jffs2_mark_node_obsolete+59f/664>
>    b:   e3 00                     jecxz  d <_EIP+0xd>
> Code;  c00926c5 <jffs2_mark_node_obsolete+5a1/664>   <=====
>    d:   30 a0 13 00 30 83         xor    %ah,0x83300013(%eax)   <=====
> Code;  c00926cb <jffs2_mark_node_obsolete+5a7/664>
>   13:   15 00 00 00 00            adc    $0x0,%eax
> 
> 
> My question is if this bug is fixed, which changes from 10-rc2 to 10
> are concerned by the fix? I can't update because porting my usb stuff
> will take ages and I don't wan't to destabilize things which are stable
> now (well, all except this one).

IIRC, there were some NOR-related bug fixes. I would just see the
revision of your nodemngmnt.c file and compare with the latest revision.
I believe the distance is one or two commits. You may port them or just
use the latest nodemngmnt.c - with high probability it will work well.

> 
> REgards, Konstantin Kletschke
> 




From steven.scholz at imc-berlin.de  Tue Feb 15 06:40:44 2005
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 15 Feb 2005 12:40:44 +0100
Subject: JFFS2_FS_WRITEBUFFER config option
In-Reply-To: <1107439704.32168.66.camel@fuzzie.sanpeople.com>
References: <1107439704.32168.66.camel@fuzzie.sanpeople.com>
Message-ID: <4211DFBC.2080901@imc-berlin.de>

Hi,

> As per discussions on IRC, this patch replaces the current
> CONFIG_JFFS2_FS_NAND, CONFIG_JFFS2_FS_NOR_ECC and
> CONFIG_JFFS2_FS_DATAFLASH with a single configuration option - 
> CONFIG_JFFS2_FS_WRITEBUFFER.

IIUC than I dont need to enable this option for plain old NOR flash. Right?

-- 
Steven



From dedekind at infradead.org  Tue Feb 15 06:51:07 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 15 Feb 2005 14:51:07 +0300
Subject: JFFS2_FS_WRITEBUFFER config option
In-Reply-To: <4211DFBC.2080901@imc-berlin.de>
References: <1107439704.32168.66.camel@fuzzie.sanpeople.com>
	<4211DFBC.2080901@imc-berlin.de>
Message-ID: <1108468267.26412.28.camel@sauron.oktetlabs.ru>

On Tue, 2005-02-15 at 12:40 +0100, Steven Scholz wrote:
> Hi,
> 
> > As per discussions on IRC, this patch replaces the current
> > CONFIG_JFFS2_FS_NAND, CONFIG_JFFS2_FS_NOR_ECC and
> > CONFIG_JFFS2_FS_DATAFLASH with a single configuration option - 
> > CONFIG_JFFS2_FS_WRITEBUFFER.
> 
> IIUC than I dont need to enable this option for plain old NOR flash. Right?

Hi, Right




From sean.sweng at gmail.com  Tue Feb 15 09:07:49 2005
From: sean.sweng at gmail.com (Sean Kelley)
Date: Tue, 15 Feb 2005 08:07:49 -0600
Subject: Linux MTD and NFTL - Question
In-Reply-To: <1108453685.22597.30.camel@baythorne.infradead.org>
References: <43507b7c0502141847134e1e68@mail.gmail.com>
	<1108453685.22597.30.camel@baythorne.infradead.org>
Message-ID: <43507b7c05021506077ab223aa@mail.gmail.com>

David,

Thank you for your reply.  I would like to ship a product without a
CD.  USB mass storage allows you that option.  I am not familiar with
the file system profile.  Is this something similar to a PC side
driver which can understand JFFS2?

Thanks,

Sean

On Tue, 15 Feb 2005 07:48:05 +0000, David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> Does it have to be USB mass storage? What about the file system profile
> which is used with cameras? That should work when backed by JFFS2.
> 
> --
> dwmw2
> 
>



From dwmw2 at infradead.org  Tue Feb 15 09:39:38 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 15 Feb 2005 14:39:38 +0000
Subject: Linux MTD and NFTL - Question
In-Reply-To: <43507b7c05021506077ab223aa@mail.gmail.com>
References: <43507b7c0502141847134e1e68@mail.gmail.com>
	<1108453685.22597.30.camel@baythorne.infradead.org>
	<43507b7c05021506077ab223aa@mail.gmail.com>
Message-ID: <1108478378.19262.603.camel@hades.cambridge.redhat.com>

On Tue, 2005-02-15 at 08:07 -0600, Sean Kelley wrote:
> Thank you for your reply.  I would like to ship a product without a
> CD.  USB mass storage allows you that option.  I am not familiar with
> the file system profile.  Is this something similar to a PC side
> driver which can understand JFFS2?

It's a PC side driver which can understand a file system. I haven't
investigated it much -- all I know is what David Brownell said when I
last said "wouldn't it be nice if...' last March:

(Message-ID: <40644FCA.8000206 at pacbell.net> on linux-kernel)

On Fri, 2004-03-26 at 07:44 -0800, David Brownell wrote:
> David Woodhouse wrote:
> > 
> > Out of interest -- have they (or has anyone else) invented a 'file
> > system' USB device yet? For exporting some file systems, pretending to
> > be a block device really isn't very useful.
> 
> There's a file system protocol used by many digital still cameras,
> which isn't actually camera-specific.  Not MSFT-specific either.
> 
> Originally called "Picture Transfer Protocol" (PTP) it's actually
> more of a remote hierarchical filesystem protocol ... with an event
> channel (handy for "new picture" or "inserted new flash memory")
> and some built-in search capabilities ("what JPGs do you have").
> The strangest capability was a file type tag, which isn't actually
> that bizarre.
> 
> As with RNDIS, and USB Mass Storage, I understand that support for
> PTP is part of MS-Windows since about Win2K.  So a PTP gadget
> driver would probably be a useful contribution to Linux.

A quick google shows an old host-side implementation for Linux at 
http://www.michaelminn.com/?linux/mmptp/README.html but no slave
implmentation yet. 

-- 
dwmw2




From simon at baydel.com  Tue Feb 15 09:33:20 2005
From: simon at baydel.com (Simon Haynes)
Date: Tue, 15 Feb 2005 14:33:20 +0000
Subject: Linux MTD and NFTL - Question
In-Reply-To: <43507b7c0502141847134e1e68@mail.gmail.com>
References: <43507b7c0502141847134e1e68@mail.gmail.com>
Message-ID: <B14B7F022B43@baydel.com>

Sean,

Do you know if the USB device contains any embedded block translation layer ?

I had a similar problem with Smart Media. All of the PC card readers I have 
come across have a embedded block translation layer and my ebmedded hardware
did not. I had to write a software version of this translation layer so that 
I could interchange the media. I included this stuff in the mtd tree so you 
can get it there, if this is what you need ?

This is very basic code and it has limitiations which made writing the stuff 
quicker. These are ok for me but may not be for you.

Cheers

Simon

On Tuesday 15 Feb 2005 2:47 am, Sean Kelley wrote:
> I've been looking into an NFTL implementation for a device that uses a
> NAND part and needs to be mounted on a Window's PC Desktop.  Thus I
> need a Block Device interface so as to present a surface on which a
> FAT filesystem can be placed.  However, in the course of my research
> it came to my attention that a company called M-Systems has a hefty
> amount of IP with regards to FTL and NFTL for pseudo-block devices.
> How does the Linux MTD-NFTL skirt the patents that M-Systems has in
> place?  If I want to sell my product commercially what sort of risk?
> It is not terribly clear.  I've looked at YAFFS and JFFS2, but those
> won't work if I wish to support USB mass storage for the Windows
> desktop.
>
> Any comments on NFTL and M-Systems patents much appreciated.
>
> Thanks,
>
> Sean
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



From lists at ku-gbr.de  Tue Feb 15 10:02:32 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 15 Feb 2005 16:02:32 +0100
Subject: Oops in 2.6.10-rc2
In-Reply-To: <1108463611.26412.27.camel@sauron.oktetlabs.ru>
References: <20050214143601.GB27046@synertronixx3>
	<1108463611.26412.27.camel@sauron.oktetlabs.ru>
Message-ID: <20050215150231.GA831@synertronixx3>

Am 2005-02-15 13:33 +0300 schrieb Artem B. Bityuckiy:

> IIRC, there were some NOR-related bug fixes. I would just see the
> revision of your nodemngmnt.c file and compare with the latest revision.
> I believe the distance is one or two commits. You may port them or just
> use the latest nodemngmnt.c - with high probability it will work well.

Ok, I will try that and fetch a new nodemgmnt.c tomorrow.
Now I am at my XIP construction set :(

Thanks for your help, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From steve at digidescorp.com  Tue Feb 15 10:24:04 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Tue, 15 Feb 2005 09:24:04 -0600
Subject: Bug in jffs2/scan.c re: incorrect assumption of "allclean"block
In-Reply-To: <1108454688.26412.18.camel@sauron.oktetlabs.ru>
Message-ID: <005101c51372$659fd420$6ffea8c0@banana>


> Well, I've looked trough your debug output and the code and think the
following patch should fix the bug.

That also seems to work. I assume that the test for "jeb->used_size ==
PAD(c->cleanmarker_size)" assures that jeb->first_node is non-NULL, so
dereferencing it won't ever cause an oops.

Should the code at line 631 be changed to look more like your patched
code? (Why the difference?)

Steve






From lists at ku-gbr.de  Tue Feb 15 10:48:19 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 15 Feb 2005 16:48:19 +0100
Subject: XIP aware file system
Message-ID: <20050215154819.GB831@synertronixx3>

Hi people!

Since I got a reasonable burst modus of flash device running XIP is not
taking more but less time now, so third attempt to get this running...
I have to port the stuff in xip.h.

PXA:

I have a question why (ICIP & ICMR) is done. Because ICIP _is_ already
the hardware "and"ed between  ICMR and ICPR so it seems bogus at this
place to "and" pending and mask by software again.
Is this done because of "ICCR[DIM]=0 & Idle mode='1'" "or"ed to ICMR?
If yes, on our i.MX it should be sufficient to do 
( IMX_NIPNDH || IMX_NIPNDL ) which are the IRQ pending registers already
"and"ed between IRQ source and INT enable.

The OSCR Register is read to get some timing stuff, at what frequency is
the timer ++ed? I am sure it is 32.768kHz or 32.8kHz. Is that correct?
In this case I should also do
(signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) /4).
because "our" timer runs at 32kHz. I am pretty sure though...

Further I found in funktion __xipram xip_udelay() a call to printk()
right at the beginning, "pending entry". This will never work,
becaus printk is located in flash,is that
correct (just trying to really understand)?
When I look at dissassembled vmlinux I find several calls to functions in
flash in xip_udelay:

c0013974:       ebc3fa2e        bl      bf112234 <cond_resched>
c0013994:       ebc34c31        bl      bf0e6a60 <memset>
c00139dc:       ebc18b27        bl      bf076680 <add_wait_queue>
c00139e0:       ebc3f696        bl      bf111440 <schedule>
c00139ec:       ebc18b45        bl      bf076708 <remove_wait_queue>

and so on.
Is this correct?

Hm, our Kernel freezes right after

Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
0x00040000-0x00140000 : "kernel"    
0x00140000-0x00540000 : "root"  
0x00540000-0x00940000 : "fs"

at the moment.

Kind regards, Konsti




-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From dedekind at infradead.org  Tue Feb 15 10:57:52 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 15 Feb 2005 18:57:52 +0300
Subject: Bug in jffs2/scan.c re: incorrect assumption of "allclean"block
In-Reply-To: <005101c51372$659fd420$6ffea8c0@banana>
References: <005101c51372$659fd420$6ffea8c0@banana>
Message-ID: <1108483073.26412.31.camel@sauron.oktetlabs.ru>

On Tue, 2005-02-15 at 09:24 -0600, Steven J. Magnani wrote:
> > Well, I've looked trough your debug output and the code and think the
> following patch should fix the bug.
> 
> That also seems to work. I assume that the test for "jeb->used_size ==
> PAD(c->cleanmarker_size)" assures that jeb->first_node is non-NULL, so
> dereferencing it won't ever cause an oops.
Yes

> 
> Should the code at line 631 be changed to look more like your patched
> code? (Why the difference?)
I believe the same should be done there too.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From lists at ku-gbr.de  Tue Feb 15 11:12:08 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 15 Feb 2005 17:12:08 +0100
Subject: XIP aware file system
In-Reply-To: <20050215154819.GB831@synertronixx3>
References: <20050215154819.GB831@synertronixx3>
Message-ID: <20050215161208.GC831@synertronixx3>

eumn, in general, is it OK to try the XIP stuff with
linux-2.6.11-rc2-mm1?
The patches applied clean, I thought XIP is in mm tree and I realized
much later the XIP is already in 2.6.11-rc2...

Regards, Konsti


-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From nico at cam.org  Tue Feb 15 11:38:02 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 15 Feb 2005 11:38:02 -0500 (EST)
Subject: XIP aware file system
In-Reply-To: <20050215154819.GB831@synertronixx3>
References: <20050215154819.GB831@synertronixx3>
Message-ID: <Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>

On Tue, 15 Feb 2005, Konstantin Kletschke wrote:

> Hi people!
> 
> Since I got a reasonable burst modus of flash device running XIP is not
> taking more but less time now, so third attempt to get this running...
> I have to port the stuff in xip.h.
> 
> PXA:
> 
> I have a question why (ICIP & ICMR) is done. Because ICIP _is_ already
> the hardware "and"ed between  ICMR and ICPR so it seems bogus at this
> place to "and" pending and mask by software again.

   The  Interrupt Controller Pending register (ICPR) (see Section 25.5.1)
   has  a  bit  for  each of the peripherals (primary interrupt sources).
   Each  active  interrupt  sets  the  corresponding  bit.  The Interrupt
   Controller  IRQ  Pending  register (ICIP) (see Section 25.5.2) and the
   Interrupt  Controller FIQ Pending register (ICFP) (see Section 25.5.3)
   identify  the  active,  unmasked  pending  interrupt  sources that are
   causing  IRQ-  and  FIQ-level interrupts, respectively. Interrupts are
   set   at  their  source  and  masked  or  unmasked  in  the  interrupt
   controller. The programmable Interrupt Controller Mask register (ICMR)
   (see  Section 25.5.4) chooses which interrupt source is masked. Masked
   interrupt sources do not cause an IRQ or FIQ interrupt to the core and
   only update the ICPR. The Interrupt Control Level register (ICLR) (see
   Section 25.5.5) chooses whether an interrupt causes an IRQ or an FIQ.

> Is this done because of "ICCR[DIM]=0 & Idle mode='1'" "or"ed to ICMR?

I'm not sure if it is strictly necessary to use ICMR.  According to the 
manual quoted above masked interrupts only update ICPR and not ICIP.  If 
so the & with ICMR is redundent.

> If yes, on our i.MX it should be sufficient to do 
> ( IMX_NIPNDH || IMX_NIPNDL ) which are the IRQ pending registers already
> "and"ed between IRQ source and INT enable.

Right.

> The OSCR Register is read to get some timing stuff, at what frequency is
> the timer ++ed? I am sure it is 32.768kHz or 32.8kHz. Is that correct?

No. It's either 3686400 Hz or 3250000 Hz.  Therefore xip_elapsed_since() 
should do:

	ticks = OSCR(now) - OSCR(before)
	usecs = ticks / 3606400 (ticks/sec) * 1000000 (usecs/sec)

or	usecs = (OSCR - x) / 3.686400

Rounding it to avoid floats and making sure it provides a result smaller
than the actual delay in microsecs (per the comment in xip.h) we get:

#define xip_elapsed_since(x)    (signed)((OSCR - (x)) / 4)

The (signed) is to make sure the compiler does a signed compare with it 
later on regardless of the OSCR signedness.

> In this case I should also do
> (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) /4).
> because "our" timer runs at 32kHz. I am pretty sure though...

If your time base runs at 32kHz you need:

#define xip_elapsed_since(x) (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 31)

where 31 = 1000000 (usecs/sec) / 32000 (ticks/sec).

> Further I found in funktion __xipram xip_udelay() a call to printk()
> right at the beginning, "pending entry".

Where do you see that?

> This will never work,
> becaus printk is located in flash,is that
> correct (just trying to really understand)?
> When I look at dissassembled vmlinux I find several calls to functions in
> flash in xip_udelay:
> 
> c0013974:       ebc3fa2e        bl      bf112234 <cond_resched>
> c0013994:       ebc34c31        bl      bf0e6a60 <memset>
> c00139dc:       ebc18b27        bl      bf076680 <add_wait_queue>
> c00139e0:       ebc3f696        bl      bf111440 <schedule>
> c00139ec:       ebc18b45        bl      bf076708 <remove_wait_queue>
> 
> and so on.
> Is this correct?

Please study carefully xip_udelay() and try to understand _when_ it is 
OK to call other functions and when it is not.  This function is really 
where all the magic is happening.

> Hm, our Kernel freezes right after
> 
> Creating 5 MTD partitions on "scb9328_flash":             
> 0x00000000-0x00020000 : "U-boot"             
> 0x00020000-0x00040000 : "U-boot_env"
> 0x00040000-0x00140000 : "kernel"    
> 0x00140000-0x00540000 : "root"  
> 0x00540000-0x00940000 : "fs"
> 
> at the moment.

Look at your xip_elasped_since() implementation.


Nicolas



From lists at ku-gbr.de  Tue Feb 15 11:50:48 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 15 Feb 2005 17:50:48 +0100
Subject: XIP aware file system
In-Reply-To: <Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
References: <20050215154819.GB831@synertronixx3>
	<Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
Message-ID: <20050215165048.GE831@synertronixx3>

You got it!

Finally I considered the OSCR running at 3.6MHz and did

#define xip_elapsed_since(x)    (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 28)

i.e. 112/4. And it runs and does xip and I can write to flash.
Im not believing what I see...

Am 2005-02-15 11:38 -0500 schrieb Nicolas Pitre:

> I'm not sure if it is strictly necessary to use ICMR.  According to the 
> manual quoted above masked interrupts only update ICPR and not ICIP.  If 
> so the & with ICMR is redundent.

I think it is redundant but I don't know exactly the meaning of
ICMR|ICCR.

> If your time base runs at 32kHz you need:
> 
> #define xip_elapsed_since(x) (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 31)

Right. As said, I assumed OSCR runs 3.6MHz and came to * 28, but I
should do 112/3.6.
Thanks for your nice explanation.

> Where do you see that?

ARGH! It was mine! 

> Please study carefully xip_udelay() and try to understand _when_ it is 

Im trying hard :)

> Look at your xip_elasped_since() implementation.

All right, I did while you calculated the values for me :)

Thanks for your help, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From nico at cam.org  Tue Feb 15 12:12:06 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 15 Feb 2005 12:12:06 -0500 (EST)
Subject: XIP aware file system
In-Reply-To: <20050215165048.GE831@synertronixx3>
References: <20050215154819.GB831@synertronixx3>
	<Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
	<20050215165048.GE831@synertronixx3>
Message-ID: <Pine.LNX.4.61.0502151210270.27338@localhost.localdomain>

On Tue, 15 Feb 2005, Konstantin Kletschke wrote:

> You got it!
> 
> Finally I considered the OSCR running at 3.6MHz and did
> 
> #define xip_elapsed_since(x)    (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 28)
> 
> i.e. 112/4. And it runs and does xip and I can write to flash.

Where does that 112/4 come from?


Nicolas



From dwmw2 at infradead.org  Tue Feb 15 12:36:29 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 15 Feb 2005 17:36:29 +0000
Subject: XIP aware file system
In-Reply-To: <Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
References: <20050215154819.GB831@synertronixx3>
	<Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
Message-ID: <1108488989.19262.623.camel@hades.cambridge.redhat.com>

On Tue, 2005-02-15 at 11:38 -0500, Nicolas Pitre wrote:
> Please study carefully xip_udelay() and try to understand _when_ it is 
> OK to call other functions and when it is not.  This function is really 
> where all the magic is happening.

Out of interest, how do we guarantee that there won't be speculative
prefetching of icache? If you're relying on hardware-specific knowledge
that it doesn't happen, please document that so that it doesn't bite
people implementing the XIP primitives on other platforms.

-- 
dwmw2




From nico at cam.org  Tue Feb 15 13:04:05 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 15 Feb 2005 13:04:05 -0500 (EST)
Subject: XIP aware file system
In-Reply-To: <1108488989.19262.623.camel@hades.cambridge.redhat.com>
References: <20050215154819.GB831@synertronixx3>
	<Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
	<1108488989.19262.623.camel@hades.cambridge.redhat.com>
Message-ID: <Pine.LNX.4.61.0502151239250.27338@localhost.localdomain>

On Tue, 15 Feb 2005, David Woodhouse wrote:

> On Tue, 2005-02-15 at 11:38 -0500, Nicolas Pitre wrote:
> > Please study carefully xip_udelay() and try to understand _when_ it is 
> > OK to call other functions and when it is not.  This function is really 
> > where all the magic is happening.
> 
> Out of interest, how do we guarantee that there won't be speculative
> prefetching of icache? If you're relying on hardware-specific knowledge
> that it doesn't happen, please document that so that it doesn't bite
> people implementing the XIP primitives on other platforms.

See xip_enable().  You'll find:

	(void) map_read(map, adr);
	asm volatile (".rep 8; nop; .endr"); /* fill instruction prefetch */

Hopefully that should be suficient to avoid this problem.


Nicolas



From lists at ku-gbr.de  Tue Feb 15 13:08:09 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 15 Feb 2005 19:08:09 +0100
Subject: XIP aware file system
In-Reply-To: <Pine.LNX.4.61.0502151210270.27338@localhost.localdomain>
References: <20050215154819.GB831@synertronixx3>
	<Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
	<20050215165048.GE831@synertronixx3>
	<Pine.LNX.4.61.0502151210270.27338@localhost.localdomain>
Message-ID: <20050215180809.GA15503@synertronixx3>

Am 2005-02-15 12:12 -0500 schrieb Nicolas Pitre:

> Where does that 112/4 come from?

OSCR: 3.6MHz
i.MX Timer: 32kHz

3.6/0.032~112

OSCR/4 == i.MX Timer*(112/4)

There I got my 28 from :)

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From nico at cam.org  Tue Feb 15 13:25:23 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 15 Feb 2005 13:25:23 -0500 (EST)
Subject: XIP aware file system
In-Reply-To: <20050215180809.GA15503@synertronixx3>
References: <20050215154819.GB831@synertronixx3>
	<Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
	<20050215165048.GE831@synertronixx3>
	<Pine.LNX.4.61.0502151210270.27338@localhost.localdomain>
	<20050215180809.GA15503@synertronixx3>
Message-ID: <Pine.LNX.4.61.0502151322230.27338@localhost.localdomain>

On Tue, 15 Feb 2005, Konstantin Kletschke wrote:

> Am 2005-02-15 12:12 -0500 schrieb Nicolas Pitre:
> 
> > Where does that 112/4 come from?
> 
> OSCR: 3.6MHz
> i.MX Timer: 32kHz
> 
> 3.6/0.032~112
> 
> OSCR/4 == i.MX Timer*(112/4)
> 
> There I got my 28 from :)

Please re-read my previous email discussing implementation of 
xip_elapsed_since() again, and re-read it until it's obvious to you why 
I'm so insisting.

The SA11x0/PXA2xx implementation is an _example_ not a _reference_.


Nicolas



From lists at ku-gbr.de  Tue Feb 15 13:51:14 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Tue, 15 Feb 2005 19:51:14 +0100
Subject: XIP aware file system
In-Reply-To: <20050215165048.GE831@synertronixx3>
References: <20050215154819.GB831@synertronixx3>
	<Pine.LNX.4.61.0502151055150.27338@localhost.localdomain>
	<20050215165048.GE831@synertronixx3>
Message-ID: <20050215185113.GB15503@synertronixx3>

Hm, something is unstable yet.
Either my burstmode is too hard or something else...

The burst mode I tuned this day, it worked for a couple of hours, but my
xip kernels all brak now:

Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
0x00040000-0x00240000 : "kernel"    
0x00240000-0x00640000 : "root"  
0x00640000-0x01000000 : "fs"  
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000b2128: Read
0x405647ad, calculated 0x7e3eb440
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000b236c: Read
0xb9570647, calculated 0x35f96289
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000b35a8: Read
0x9acd7a6e, calculated 0x87339b9f
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000e8630: Read
0x03371d6d, calculated 0x4dcf6e71
jffs2_scan_dirent_node(): Name CRC failed on node at 0x0010adac: Read
0xe2abe810, calculated 0xe0794e1f

And freeze then. Is my xipuImage frying the fs on its first boot?
Yes, obviously but why not an hour ago? hm...

Adressess are constant with every version and the rootfs is reflashed
every time. 
I am puzzled...

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From martin at egholm-nielsen.dk  Tue Feb 15 14:22:44 2005
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Tue, 15 Feb 2005 20:22:44 +0100
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <1108425786.22597.6.camel@baythorne.infradead.org>
References: <4210DB19.9000808@ateme.fr>
	<4210DEDB.DD35E2DE@st.com>	<4210E6C3.9030208@ateme.fr>	<1108404250.16612.327.camel@tglx.tec.linutronix.de>
	<1108425786.22597.6.camel@baythorne.infradead.org>
Message-ID: <cuti4g$g6h$1@sea.gmane.org>

Hi,

>>>>JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when
>>>>it is full, or when you do fsync, sync or umount.
>>>Does that mean that I have to call fsync each time after fclose a file ?
> Yes. It's precisely the same as with other file systems. If you write to
> a file, close it and then lose power immediately, your data may be lost.
> It's not guaranteed to be on the medium until you sync.
Well, as someone told me the other day on the IRC-channel, the 
writebuffer is flushed automatically if the buffer has not been accessed 
for X (2?) seconds (controlled by the VFS, right?)...

Correct me if I'm wrong...

// Martin




From jdub at us.ibm.com  Tue Feb 15 14:46:17 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Tue, 15 Feb 2005 13:46:17 -0600
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <cuti4g$g6h$1@sea.gmane.org>
References: <4210DB19.9000808@ateme.fr> <4210DEDB.DD35E2DE@st.com>
	<4210E6C3.9030208@ateme.fr>
	<1108404250.16612.327.camel@tglx.tec.linutronix.de>
	<1108425786.22597.6.camel@baythorne.infradead.org>
	<cuti4g$g6h$1@sea.gmane.org>
Message-ID: <1108496777.7801.9.camel@windu.rchland.ibm.com>

On Tue, 2005-02-15 at 20:22 +0100, Martin Egholm Nielsen wrote:
> Well, as someone told me the other day on the IRC-channel, the 
> writebuffer is flushed automatically if the buffer has not been accessed 
> for X (2?) seconds (controlled by the VFS, right?)...
> 
> Correct me if I'm wrong...

Not quite.  The write buffer is flushed every 5 seconds, unless you tune
it using the /proc entry.  It's controlled by kupdated, which syncs the
supers, which flushes the write buffer in JFFS2.

If the write buffer contains GC data, that isn't flushed at all.

josh




From jdub at us.ibm.com  Tue Feb 15 15:03:33 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Tue, 15 Feb 2005 14:03:33 -0600
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <1108496777.7801.9.camel@windu.rchland.ibm.com>
References: <4210DB19.9000808@ateme.fr> <4210DEDB.DD35E2DE@st.com>
	<4210E6C3.9030208@ateme.fr>
	<1108404250.16612.327.camel@tglx.tec.linutronix.de>
	<1108425786.22597.6.camel@baythorne.infradead.org>
	<cuti4g$g6h$1@sea.gmane.org>
	<1108496777.7801.9.camel@windu.rchland.ibm.com>
Message-ID: <1108497813.7801.12.camel@windu.rchland.ibm.com>

On Tue, 2005-02-15 at 13:46 -0600, Josh Boyer wrote:
> On Tue, 2005-02-15 at 20:22 +0100, Martin Egholm Nielsen wrote:
> > Well, as someone told me the other day on the IRC-channel, the 
> > writebuffer is flushed automatically if the buffer has not been accessed 
> > for X (2?) seconds (controlled by the VFS, right?)...
> > 
> > Correct me if I'm wrong...
> 
> Not quite.  The write buffer is flushed every 5 seconds, unless you tune
> it using the /proc entry.  It's controlled by kupdated, which syncs the
> supers, which flushes the write buffer in JFFS2.
> 
> If the write buffer contains GC data, that isn't flushed at all.

Just to clarify that, if the buffer contains _only_ GC data it isn't
flushed.  If it contains GC + inode data, all of that data is.

josh




From sean.sweng at gmail.com  Tue Feb 15 21:21:17 2005
From: sean.sweng at gmail.com (Sean Kelley)
Date: Tue, 15 Feb 2005 20:21:17 -0600
Subject: Linux MTD and NFTL - Question
In-Reply-To: <1108478378.19262.603.camel@hades.cambridge.redhat.com>
References: <43507b7c0502141847134e1e68@mail.gmail.com>
	<1108453685.22597.30.camel@baythorne.infradead.org>
	<43507b7c05021506077ab223aa@mail.gmail.com>
	<1108478378.19262.603.camel@hades.cambridge.redhat.com>
Message-ID: <43507b7c0502151821309e9e51@mail.gmail.com>

One other idea is to do a loopback-type of mechanism by placing an
image file that contains a FAT volume as a file in JFFS2, basically
using JFFS2 to replace the FTL.  The downside is that if the FAT is
meant to be RW, it will still have corruption  problems.  I would need
a scandisk utility on my embedded device to repair the FAT image!  It
is imazing the kind of hoops we jump through just so that Joe User can
plug the device into his windows machine.

Thanks for the links!

Sean   


On Tue, 15 Feb 2005 14:39:38 +0000, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2005-02-15 at 08:07 -0600, Sean Kelley wrote:
> > Thank you for your reply.  I would like to ship a product without a
> > CD.  USB mass storage allows you that option.  I am not familiar with
> > the file system profile.  Is this something similar to a PC side
> > driver which can understand JFFS2?
> 
> It's a PC side driver which can understand a file system. I haven't
> investigated it much -- all I know is what David Brownell said when I
> last said "wouldn't it be nice if...' last March:
> 
> (Message-ID: <40644FCA.8000206 at pacbell.net> on linux-kernel)
> 
> On Fri, 2004-03-26 at 07:44 -0800, David Brownell wrote:
> > David Woodhouse wrote:
> > >
> > > Out of interest -- have they (or has anyone else) invented a 'file
> > > system' USB device yet? For exporting some file systems, pretending to
> > > be a block device really isn't very useful.
> >
> > There's a file system protocol used by many digital still cameras,
> > which isn't actually camera-specific.  Not MSFT-specific either.
> >
> > Originally called "Picture Transfer Protocol" (PTP) it's actually
> > more of a remote hierarchical filesystem protocol ... with an event
> > channel (handy for "new picture" or "inserted new flash memory")
> > and some built-in search capabilities ("what JPGs do you have").
> > The strangest capability was a file type tag, which isn't actually
> > that bizarre.
> >
> > As with RNDIS, and USB Mass Storage, I understand that support for
> > PTP is part of MS-Windows since about Win2K.  So a PTP gadget
> > driver would probably be a useful contribution to Linux.
> 
> A quick google shows an old host-side implementation for Linux at
> http://www.michaelminn.com/?linux/mmptp/README.html but no slave
> implmentation yet.
> 
> --
> dwmw2
> 
>



From sean.sweng at gmail.com  Tue Feb 15 23:11:01 2005
From: sean.sweng at gmail.com (Sean Kelley)
Date: Tue, 15 Feb 2005 22:11:01 -0600
Subject: Linux MTD and NFTL - Question
In-Reply-To: <B14B7F022B43@baydel.com>
References: <43507b7c0502141847134e1e68@mail.gmail.com>
	<B14B7F022B43@baydel.com>
Message-ID: <43507b7c05021520114c6d4b2@mail.gmail.com>

Simon,

That is a good question.  Unfortunately, my USB device lacks any block
translation firmware that you would find in say the embedded
controllers of ATA/CF type devices.  The translation layer approach is
nice if you are using PCMCIA or a DOC part.  However, if you have a
raw NAND you leave yourself open to potential IP issues due the the
variety of patents held.  Thus, it would appear the best solution is
some sort of PC side filesystem profile that can read YAFFS or JFFS2.

Thanks,

Sean


On Tue, 15 Feb 2005 14:33:20 +0000, Simon Haynes <simon at baydel.com> wrote:
> Sean,
> 
> Do you know if the USB device contains any embedded block translation layer ?
> 
> I had a similar problem with Smart Media. All of the PC card readers I have
> come across have a embedded block translation layer and my ebmedded hardware
> did not. I had to write a software version of this translation layer so that
> I could interchange the media. I included this stuff in the mtd tree so you
> can get it there, if this is what you need ?
> 
> This is very basic code and it has limitiations which made writing the stuff
> quicker. These are ok for me but may not be for you.
> 
> Cheers
> 
> Simon
> 
> On Tuesday 15 Feb 2005 2:47 am, Sean Kelley wrote:
> > I've been looking into an NFTL implementation for a device that uses a
> > NAND part and needs to be mounted on a Window's PC Desktop.  Thus I
> > need a Block Device interface so as to present a surface on which a
> > FAT filesystem can be placed.  However, in the course of my research
> > it came to my attention that a company called M-Systems has a hefty
> > amount of IP with regards to FTL and NFTL for pseudo-block devices.
> > How does the Linux MTD-NFTL skirt the patents that M-Systems has in
> > place?  If I want to sell my product commercially what sort of risk?
> > It is not terribly clear.  I've looked at YAFFS and JFFS2, but those
> > won't work if I wish to support USB mass storage for the Windows
> > desktop.
> >
> > Any comments on NFTL and M-Systems patents much appreciated.
> >
> > Thanks,
> >
> > Sean
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
>



From martin at egholm-nielsen.dk  Wed Feb 16 02:41:39 2005
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Wed, 16 Feb 2005 08:41:39 +0100
Subject: Bug in jffs2/scan.c re: incorrect assumption of "all clean"block
In-Reply-To: <1108454688.26412.18.camel@sauron.oktetlabs.ru>
References: <004a01c512c2$60b92930$6ffea8c0@banana>
	<1108454688.26412.18.camel@sauron.oktetlabs.ru>
Message-ID: <cuutan$jl7$2@sea.gmane.org>

>>>>I believe there is a bug in fs/jffs2/scan.c that causes it to 
=== 8< 8< 8< ===
>>>Is your flash NOR or NAND?
>>The part is NOR flash (Intel 28F320C3).
So will this bug effect NAND users, as well?

// Martin




From martin at egholm-nielsen.dk  Wed Feb 16 02:38:42 2005
From: martin at egholm-nielsen.dk (Martin Egholm Nielsen)
Date: Wed, 16 Feb 2005 08:38:42 +0100
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND device
In-Reply-To: <1108497813.7801.12.camel@windu.rchland.ibm.com>
References: <4210DB19.9000808@ateme.fr>
	<4210DEDB.DD35E2DE@st.com>	<4210E6C3.9030208@ateme.fr>	<1108404250.16612.327.camel@tglx.tec.linutronix.de>	<1108425786.22597.6.camel@baythorne.infradead.org>	<cuti4g$g6h$1@sea.gmane.org>	<1108496777.7801.9.camel@windu.rchland.ibm.com>
	<1108497813.7801.12.camel@windu.rchland.ibm.com>
Message-ID: <cuut56$jl7$1@sea.gmane.org>

>>>Well, as someone told me the other day on the IRC-channel, the 
>>>writebuffer is flushed automatically if the buffer has not been accessed 
>>>for X (2?) seconds (controlled by the VFS, right?)...
>>>Correct me if I'm wrong...
>>Not quite.  The write buffer is flushed every 5 seconds, unless you tune
>>it using the /proc entry.  It's controlled by kupdated, which syncs the
>>supers, which flushes the write buffer in JFFS2.
But this might be the better solution for Frederic, instead of poluting 
his code with fsync's. That is, just tune the /proc entry (which one?) 
to a value suitable for your needs - e.g. 2 secs.

>>If the write buffer contains GC data, that isn't flushed at all.
> Just to clarify that, if the buffer contains _only_ GC data it isn't
> flushed.  If it contains GC + inode data, all of that data is.
:o)

// Martin




From dedekind at infradead.org  Wed Feb 16 02:57:38 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 16 Feb 2005 07:57:38 +0000 (GMT)
Subject: Bug in jffs2/scan.c re: incorrect assumption of "all clean"block
In-Reply-To: <cuutan$jl7$2@sea.gmane.org>
References: <004a01c512c2$60b92930$6ffea8c0@banana>
	<1108454688.26412.18.camel@sauron.oktetlabs.ru>
	<cuutan$jl7$2@sea.gmane.org>
Message-ID: <Pine.LNX.4.58.0502160756520.30538@phoenix.infradead.org>

On Wed, 16 Feb 2005, Martin Egholm Nielsen wrote:

> >>>>I believe there is a bug in fs/jffs2/scan.c that causes it to 
> === 8< 8< 8< ===
> >>>Is your flash NOR or NAND?
> >>The part is NOR flash (Intel 28F320C3).
> So will this bug effect NAND users, as well?
> 
No, it is NOR specific.
We'll commit the fix.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From kyungmin.park at samsung.com  Wed Feb 16 03:33:30 2005
From: kyungmin.park at samsung.com (Kyungmin Park)
Date: Wed, 16 Feb 2005 17:33:30 +0900
Subject: [PATCH] Remove duplicated Samsung NAND 512MiB 3,3V 8-bit device ID
Message-ID: <!~!UENERkVCMDkAAQACACsBAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAARU1TTURCLkRMTAAAAAAAAAAAG1X6IKpmEc2byACqAC/EWgwAAABTV0NFTQAvbz1zd2NlbnRlci9vdT1GaXJzdCBBZG1pbmlzdHJhdGl2ZSBHcm91cC9jbj1SZWNpcGllbnRzL2NuPWttcGFyawDYNSHzpwAAAAEAAAAUAAAAYwAAAC9vPXN3Y2VudGVyL291PUZpc>

	Remove duplicated Samsung NAND 512MiB 3,3V 8-bit device ID.
	Correct device ID is defined following.
	{"NAND 512MiB 3,3V 8-bit",      0xDC, 0, 512, 0,
NAND_SAMSUNG_LP_OPTIONS | NAND_NO_AUTOINCR},

Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

diff -u -r1.1.1.1 nand_ids.c
--- drivers/mtd/nand/nand_ids.c 13 Jan 2005 06:51:14 -0000      1.1.1.1
+++ drivers/mtd/nand/nand_ids.c 16 Feb 2005 08:19:48 -0000
@@ -62,8 +62,6 @@

        {"NAND 256MiB 3,3V 8-bit",      0x71, 512, 256, 0x4000, 0},

-       {"NAND 512MiB 3,3V 8-bit",      0xDC, 512, 512, 0x4000, 0},
-
        /* These are the new chips with large page size. The pagesize
        * and the erasesize is determined from the extended id bytes
        */




From kyungmin.park at samsung.com  Wed Feb 16 04:10:58 2005
From: kyungmin.park at samsung.com (Kyungmin Park)
Date: Wed, 16 Feb 2005 18:10:58 +0900
Subject: [PATCH] Find correct manufacture ID
Message-ID: <0IBZ008IQYUAKZ@mmp1.samsung.com>

	If you find 8-bit buswidth flash with 16-bit buswidth option, it
displays warning message.
	Before display you have to find correct manufacture ID.
 Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

diff -u -r1.1.1.1 nand_base.c
--- drivers/mtd/nand/nand_base.c        13 Jan 2005 06:51:14 -0000      1.1.
1.1
+++ drivers/mtd/nand/nand_base.c        16 Feb 2005 08:19:48 -0000
@@ -2259,9 +2259,15 @@
                /* Check, if buswidth is correct. Hardware drivers should
set
                 * this correct ! */
                if (busw != (this->options & NAND_BUSWIDTH_16)) {
+                       /* Try to identify manufacturer */
+                       for (j = 0; nand_manuf_ids[j].id != 0x0; j++) {
+                               if (nand_manuf_ids[j].id == nand_maf_id)
+                                       break;
+                       }
                        printk (KERN_INFO "NAND device: Manufacturer ID:"
                                " 0x%02x, Chip ID: 0x%02x (%s %s)\n",
nand_maf_id, nand_dev_id,
-                               nand_manuf_ids[i].name , mtd->name);
+                               nand_manuf_ids[j].name , mtd->name);
                        printk (KERN_WARNING
                                "NAND bus width %d instead %d bit\n",
                                        (this->options & NAND_BUSWIDTH_16)
? 16 : 8,




From tglx at linutronix.de  Wed Feb 16 04:34:02 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 16 Feb 2005 10:34:02 +0100
Subject: [PATCH] Remove duplicated Samsung NAND 512MiB 3,3V 8-bit
	device ID
In-Reply-To: <!~!UENERkVCMDkAAQACACsBAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAARU1TTURCLkRMTAAAAAAAAAAAG1X6IKpmEc2byACqAC/EWgwAAABTV0NFTQAvbz1zd2NlbnRlci9vdT1GaXJzdCBBZG1pbmlzdHJhdGl2ZSBHcm91cC9jbj1SZWNpcGllbnRzL2NuPWttcGFyawDYNSHzpwAAAAEAAAAUAAAAYwAAAC9vPXN3Y2VudGVyL291PUZpc>
References: <!~!UENERkVCMDkAAQACACsBAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAARU1TTURCLkRMTAAAAAAAAAAAG1X6IKpmEc2byACqAC/EWgwAAABTV0NFTQAvbz1zd2NlbnRlci9vdT1GaXJzdCBBZG1pbmlzdHJhdGl2ZSBHcm91cC9jbj1SZWNpcGllbnRzL2NuPWttcGFyawDYNSHzpwAAAAEAAAAUAAAAYwAAAC9vPXN3Y2VudGVyL291PUZpc>
Message-ID: <1108546442.24721.34.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-16 at 17:33 +0900, Kyungmin Park wrote:
>         Remove duplicated Samsung NAND 512MiB 3,3V 8-bit device ID.
>         Correct device ID is defined following.
>         {"NAND 512MiB 3,3V 8-bit",      0xDC, 0, 512, 0,
> NAND_SAMSUNG_LP_OPTIONS | NAND_NO_AUTOINCR},
> 
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> 

Applied. Thanks.

tglx





From lists at ku-gbr.de  Wed Feb 16 06:47:42 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Wed, 16 Feb 2005 12:47:42 +0100
Subject: Oops vanilla 2.6.10
Message-ID: <20050216114741.GA16239@synertronixx3>

This way 2.6.10 Oopses on a virgin jffs2. Second boot is fine.
cat /dev/mtdblock3 > /dev/null
lasts three times longer than with 2.6.10-rc2.

Please advise me to fix these two problems :/

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
EEEEEK. jffs2_mark_node_obsolete called with NULL node
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 5 [#1]
CPU: 0            
pc : [<c00bfee0>]    lr : [<00000001>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
sp : c0219d24  ip : 60000093  fp : c0219d44          
r10: c030c8ac  r9 : c030c8c4  r8 : 00000000
r7 : c030c800  r6 : c0219d48  r5 : c0320fac  r4 : 00000000
r3 : c01b1ed4  r2 : 00000000  r1 : 00000ba6  r0 : 0000003a
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: C000717F  Table: 08004000  DAC: 0000001D         
Stack: (0xc0219d24 to 0xc021a000)                 
9d20:          c0320fac 00000000 c030c800 c0219d4c 00000000 c0219d70 c0219d48 
9d40: c00bfd08 c00bfec0 00000000 0000000c c030c894 c030c89c c030c8a4 c030c8b4 
9d60: c030c8bc c0219db8 c0219d74 c00c0244 c00bfb34 c030c8f8 c030c800 c030c8dc 
9d80: c030c8d4 c030c8cc c030c8ec c00d3c90 00020000 c030c800 00000000 c030c600 
9da0: c02f7400 00000000 00000000 c0219ddc c0219dbc c00c1f1c c00c002c c030c600 
9dc0: c030c800 00008000 00000000 c02f7400 c0219e00 c0219de0 c00c2558 c00c1dfc 
9de0: ffffffea 00000003 c031a000 00008000 c01b97bc c0219e70 c0219e04 c00c27a4 
9e00: c00c24d0 c02f7400 c007e1b8 c0289a1c c0209600 c0219ed0 c0219ed0 c0219e68 
9e20: 00000001 00000001 00000000 0000000a c02092a0 c02fa240 c031a000 00008000 
9e40: 00000000 c0219e70 c0219e54 c02092a0 fffffff4 c01b97bc c031a000 00008000 
9e60: 00000000 c0219e98 c0219e74 c006d740 c00c2620 ffffffff c031a000 00000000 
9e80: 00008000 c0219ed0 00000000 c0219ec0 c0219e9c c0082424 c006d6f4 00008000 
9ea0: 00000000 c0319000 00000000 c031a000 c0219ed0 c0219f38 c0219ec4 c0082ac4 
9ec0: c00823b0 c031a000 00000000 c0318000 c020c554 c0209600 c0219ee4 00000000 
9ee0: c0187478 00000001 00000001 00000000 00000000 00000000 c0219f14 c0219f08 
9f00: c004f5c4 00001000 c0219f38 c0219f18 00000000 00000000 c0187478 c0319000 
9f20: 00008000 00000000 00000000 c0219f6c c0219f3c c0082ee4 c0082984 00000000 
9f40: 00000000 c031a000 c0318000 c0224000 c0224000 00008000 c0187478 c01cda20 
9f60: c0219f84 c0219f70 c0008f20 c0082e50 00000000 c0224000 c0219fc8 c0219f88 
9f80: c0009004 c0008f00 c0046328 01f00003 c0187478 00000000 00000000 00000000 
9fa0: 00000000 c0219fc8 c00166a0 00000000 00000000 00000000 00000000 c0219fe0 
9fc0: c0219fcc c000919c c0008fbc 00000000 c018728c c0219ff4 c0219fe4 c0018250 
9fe0: c000914c 00000000 00000000 c0219ff8 c003476c c0018210 c01d1170 c01bd7b4 
Backtrace:                                                                    
Function entered at [<c00bfeb0>] from [<c00bfd08>]
 r8 = 00000000  r7 = C0219D4C  r6 = C030C800  r5 = 00000000
 r4 = C0320FAC                                             
Function entered at [<c00bfb24>] from [<c00c0244>]
 r8 = C030C8BC  r7 = C030C8B4  r6 = C030C8A4  r5 = C030C89C
 r4 = C030C894                                             
Function entered at [<c00c001c>] from [<c00c1f1c>]
Function entered at [<c00c1dec>] from [<c00c2558>]
 r8 = C02F7400  r7 = 00000000  r6 = 00008000  r5 = C030C800
 r4 = C030C600                                             
Function entered at [<c00c24c0>] from [<c00c27a4>]
 r8 = C01B97BC  r7 = 00008000  r6 = C031A000  r5 = 00000003
 r4 = FFFFFFEA                                             
Function entered at [<c00c2610>] from [<c006d740>]
Function entered at [<c006d6e4>] from [<c0082424>]
Function entered at [<c00823a0>] from [<c0082ac4>]
Function entered at [<c0082974>] from [<c0082ee4>]
Function entered at [<c0082e40>] from [<c0008f20>]
 r8 = C01CDA20  r7 = C0187478  r6 = 00008000  r5 = C0224000
 r4 = C0224000                                             
Function entered at [<c0008ef0>] from [<c0009004>]
 r4 = C0224000                                    
Function entered at [<c0008fac>] from [<c000919c>]
 r8 = 00000000  r7 = 00000000  r6 = 00000000  r5 = 00000000
 r4 = C00166A0                                             
Function entered at [<c000913c>] from [<c0018250>]
 r4 = C018728C                                    
Function entered at [<c0018200>] from [<c003476c>]
 r4 = 00000000                                    
Code: 0a000005 e1a01004 e1a00007 ebffe497 (e5944000) 


>>EIP; c00bfee0 <jffs2_build_remove_unlinked_inode+30/ec>   <=====

>>r3; c01b1ed4 <log_wait+0/8>

Trace; c00bfeb0 <jffs2_build_remove_unlinked_inode+0/ec>
Trace; c00bfd08 <jffs2_build_filesystem+1e4/38c>
Trace; c00bfb24 <jffs2_build_filesystem+0/38c>
Trace; c00c0244 <jffs2_do_mount_fs+228/270>
Trace; c00c001c <jffs2_do_mount_fs+0/270>
Trace; c00c1f1c <jffs2_do_fill_super+130/238>
Trace; c00c1dec <jffs2_do_fill_super+0/238>
Trace; c00c2558 <jffs2_get_sb_mtd+98/f8>
Trace; c00c24c0 <jffs2_get_sb_mtd+0/f8>
Trace; c00c27a4 <jffs2_get_sb+194/1d0>

>>r8; c01b97bc <jffs2_fs_type+0/20>

Trace; c00c2610 <jffs2_get_sb+0/1d0>
Trace; c006d740 <do_kern_mount+5c/f4>
Trace; c006d6e4 <do_kern_mount+0/f4>
Trace; c0082424 <do_new_mount+84/b8>
Trace; c00823a0 <do_new_mount+0/b8>
Trace; c0082ac4 <do_mount+150/16c>
Trace; c0082974 <do_mount+0/16c>
Trace; c0082ee4 <sys_mount+a4/e8>
Trace; c0082e40 <sys_mount+0/e8>
Trace; c0008f20 <do_mount_root+30/bc>

>>r8; c01cda20 <names_cachep+0/4>
>>r7; c0187478 <__func__.4+454/18bec>

Trace; c0008ef0 <do_mount_root+0/bc>
Trace; c0009004 <mount_block_root+58/124>
Trace; c0008fac <mount_block_root+0/124>
Trace; c000919c <prepare_namespace+60/a0>

>>r4; c00166a0 <root_device_name+0/4>

Trace; c000913c <prepare_namespace+0/a0>
Trace; c0018250 <init+50/f0>

>>r4; c018728c <__func__.4+268/18bec>

Trace; c0018200 <init+0/f0>
Trace; c003476c <do_exit+0/3d8>

Code;  c00bfed0 <jffs2_build_remove_unlinked_inode+20/ec>
00000000 <_EIP>:
Code;  c00bfed0 <jffs2_build_remove_unlinked_inode+20/ec>
   0:   05 00 00 0a 04            add    $0x40a0000,%eax
Code;  c00bfed5 <jffs2_build_remove_unlinked_inode+25/ec>
   5:   10 a0 e1 07 00 a0         adc    %ah,0xa00007e1(%eax)
Code;  c00bfedb <jffs2_build_remove_unlinked_inode+2b/ec>
   b:   e1 97                     loope  ffffffa4 <_EIP+0xffffffa4>
Code;  c00bfedd <jffs2_build_remove_unlinked_inode+2d/ec>
   d:   e4 ff                     in     $0xff,%al
Code;  c00bfedf <jffs2_build_remove_unlinked_inode+2f/ec>   <=====
   f:   eb 00                     jmp    11 <_EIP+0x11>   <=====
Code;  c00bfee1 <jffs2_build_remove_unlinked_inode+31/ec>
  11:   40                        inc    %eax
Code;  c00bfee2 <jffs2_build_remove_unlinked_inode+32/ec>
  12:   94                        xchg   %eax,%esp
Code;  c00bfee3 <jffs2_build_remove_unlinked_inode+33/ec>
  13:   e5 00                     in     $0x0,%eax

 <0>Kernel panic - not syncing: Attempted to kill init!

1 error issued.  Results may not be reliable.


Kind regrads, desperated Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From dedekind at infradead.org  Wed Feb 16 06:51:42 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 16 Feb 2005 11:51:42 +0000 (GMT)
Subject: Oops vanilla 2.6.10
In-Reply-To: <20050216114741.GA16239@synertronixx3>
References: <20050216114741.GA16239@synertronixx3>
Message-ID: <Pine.LNX.4.58.0502161151020.30538@phoenix.infradead.org>

Err, can't get it, did you MTD CVS head?

On Wed, 16 Feb 2005, Konstantin Kletschke wrote:
> This way 2.6.10 Oopses on a virgin jffs2. Second boot is fine.
> cat /dev/mtdblock3 > /dev/null
> lasts three times longer than with 2.6.10-rc2.
> 
> Please advise me to fix these two problems :/
> 
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> EEEEEK. jffs2_mark_node_obsolete called with NULL node
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> Internal error: Oops: 5 [#1]
> CPU: 0            
> pc : [<c00bfee0>]    lr : [<00000001>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> sp : c0219d24  ip : 60000093  fp : c0219d44          
> r10: c030c8ac  r9 : c030c8c4  r8 : 00000000
> r7 : c030c800  r6 : c0219d48  r5 : c0320fac  r4 : 00000000
> r3 : c01b1ed4  r2 : 00000000  r1 : 00000ba6  r0 : 0000003a
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
> Control: C000717F  Table: 08004000  DAC: 0000001D         
> Stack: (0xc0219d24 to 0xc021a000)                 
> 9d20:          c0320fac 00000000 c030c800 c0219d4c 00000000 c0219d70 c0219d48 
> 9d40: c00bfd08 c00bfec0 00000000 0000000c c030c894 c030c89c c030c8a4 c030c8b4 
> 9d60: c030c8bc c0219db8 c0219d74 c00c0244 c00bfb34 c030c8f8 c030c800 c030c8dc 
> 9d80: c030c8d4 c030c8cc c030c8ec c00d3c90 00020000 c030c800 00000000 c030c600 
> 9da0: c02f7400 00000000 00000000 c0219ddc c0219dbc c00c1f1c c00c002c c030c600 
> 9dc0: c030c800 00008000 00000000 c02f7400 c0219e00 c0219de0 c00c2558 c00c1dfc 
> 9de0: ffffffea 00000003 c031a000 00008000 c01b97bc c0219e70 c0219e04 c00c27a4 
> 9e00: c00c24d0 c02f7400 c007e1b8 c0289a1c c0209600 c0219ed0 c0219ed0 c0219e68 
> 9e20: 00000001 00000001 00000000 0000000a c02092a0 c02fa240 c031a000 00008000 
> 9e40: 00000000 c0219e70 c0219e54 c02092a0 fffffff4 c01b97bc c031a000 00008000 
> 9e60: 00000000 c0219e98 c0219e74 c006d740 c00c2620 ffffffff c031a000 00000000 
> 9e80: 00008000 c0219ed0 00000000 c0219ec0 c0219e9c c0082424 c006d6f4 00008000 
> 9ea0: 00000000 c0319000 00000000 c031a000 c0219ed0 c0219f38 c0219ec4 c0082ac4 
> 9ec0: c00823b0 c031a000 00000000 c0318000 c020c554 c0209600 c0219ee4 00000000 
> 9ee0: c0187478 00000001 00000001 00000000 00000000 00000000 c0219f14 c0219f08 
> 9f00: c004f5c4 00001000 c0219f38 c0219f18 00000000 00000000 c0187478 c0319000 
> 9f20: 00008000 00000000 00000000 c0219f6c c0219f3c c0082ee4 c0082984 00000000 
> 9f40: 00000000 c031a000 c0318000 c0224000 c0224000 00008000 c0187478 c01cda20 
> 9f60: c0219f84 c0219f70 c0008f20 c0082e50 00000000 c0224000 c0219fc8 c0219f88 
> 9f80: c0009004 c0008f00 c0046328 01f00003 c0187478 00000000 00000000 00000000 
> 9fa0: 00000000 c0219fc8 c00166a0 00000000 00000000 00000000 00000000 c0219fe0 
> 9fc0: c0219fcc c000919c c0008fbc 00000000 c018728c c0219ff4 c0219fe4 c0018250 
> 9fe0: c000914c 00000000 00000000 c0219ff8 c003476c c0018210 c01d1170 c01bd7b4 
> Backtrace:                                                                    
> Function entered at [<c00bfeb0>] from [<c00bfd08>]
>  r8 = 00000000  r7 = C0219D4C  r6 = C030C800  r5 = 00000000
>  r4 = C0320FAC                                             
> Function entered at [<c00bfb24>] from [<c00c0244>]
>  r8 = C030C8BC  r7 = C030C8B4  r6 = C030C8A4  r5 = C030C89C
>  r4 = C030C894                                             
> Function entered at [<c00c001c>] from [<c00c1f1c>]
> Function entered at [<c00c1dec>] from [<c00c2558>]
>  r8 = C02F7400  r7 = 00000000  r6 = 00008000  r5 = C030C800
>  r4 = C030C600                                             
> Function entered at [<c00c24c0>] from [<c00c27a4>]
>  r8 = C01B97BC  r7 = 00008000  r6 = C031A000  r5 = 00000003
>  r4 = FFFFFFEA                                             
> Function entered at [<c00c2610>] from [<c006d740>]
> Function entered at [<c006d6e4>] from [<c0082424>]
> Function entered at [<c00823a0>] from [<c0082ac4>]
> Function entered at [<c0082974>] from [<c0082ee4>]
> Function entered at [<c0082e40>] from [<c0008f20>]
>  r8 = C01CDA20  r7 = C0187478  r6 = 00008000  r5 = C0224000
>  r4 = C0224000                                             
> Function entered at [<c0008ef0>] from [<c0009004>]
>  r4 = C0224000                                    
> Function entered at [<c0008fac>] from [<c000919c>]
>  r8 = 00000000  r7 = 00000000  r6 = 00000000  r5 = 00000000
>  r4 = C00166A0                                             
> Function entered at [<c000913c>] from [<c0018250>]
>  r4 = C018728C                                    
> Function entered at [<c0018200>] from [<c003476c>]
>  r4 = 00000000                                    
> Code: 0a000005 e1a01004 e1a00007 ebffe497 (e5944000) 
> 
> 
> >>EIP; c00bfee0 <jffs2_build_remove_unlinked_inode+30/ec>   <=====
> 
> >>r3; c01b1ed4 <log_wait+0/8>
> 
> Trace; c00bfeb0 <jffs2_build_remove_unlinked_inode+0/ec>
> Trace; c00bfd08 <jffs2_build_filesystem+1e4/38c>
> Trace; c00bfb24 <jffs2_build_filesystem+0/38c>
> Trace; c00c0244 <jffs2_do_mount_fs+228/270>
> Trace; c00c001c <jffs2_do_mount_fs+0/270>
> Trace; c00c1f1c <jffs2_do_fill_super+130/238>
> Trace; c00c1dec <jffs2_do_fill_super+0/238>
> Trace; c00c2558 <jffs2_get_sb_mtd+98/f8>
> Trace; c00c24c0 <jffs2_get_sb_mtd+0/f8>
> Trace; c00c27a4 <jffs2_get_sb+194/1d0>
> 
> >>r8; c01b97bc <jffs2_fs_type+0/20>
> 
> Trace; c00c2610 <jffs2_get_sb+0/1d0>
> Trace; c006d740 <do_kern_mount+5c/f4>
> Trace; c006d6e4 <do_kern_mount+0/f4>
> Trace; c0082424 <do_new_mount+84/b8>
> Trace; c00823a0 <do_new_mount+0/b8>
> Trace; c0082ac4 <do_mount+150/16c>
> Trace; c0082974 <do_mount+0/16c>
> Trace; c0082ee4 <sys_mount+a4/e8>
> Trace; c0082e40 <sys_mount+0/e8>
> Trace; c0008f20 <do_mount_root+30/bc>
> 
> >>r8; c01cda20 <names_cachep+0/4>
> >>r7; c0187478 <__func__.4+454/18bec>
> 
> Trace; c0008ef0 <do_mount_root+0/bc>
> Trace; c0009004 <mount_block_root+58/124>
> Trace; c0008fac <mount_block_root+0/124>
> Trace; c000919c <prepare_namespace+60/a0>
> 
> >>r4; c00166a0 <root_device_name+0/4>
> 
> Trace; c000913c <prepare_namespace+0/a0>
> Trace; c0018250 <init+50/f0>
> 
> >>r4; c018728c <__func__.4+268/18bec>
> 
> Trace; c0018200 <init+0/f0>
> Trace; c003476c <do_exit+0/3d8>
> 
> Code;  c00bfed0 <jffs2_build_remove_unlinked_inode+20/ec>
> 00000000 <_EIP>:
> Code;  c00bfed0 <jffs2_build_remove_unlinked_inode+20/ec>
>    0:   05 00 00 0a 04            add    $0x40a0000,%eax
> Code;  c00bfed5 <jffs2_build_remove_unlinked_inode+25/ec>
>    5:   10 a0 e1 07 00 a0         adc    %ah,0xa00007e1(%eax)
> Code;  c00bfedb <jffs2_build_remove_unlinked_inode+2b/ec>
>    b:   e1 97                     loope  ffffffa4 <_EIP+0xffffffa4>
> Code;  c00bfedd <jffs2_build_remove_unlinked_inode+2d/ec>
>    d:   e4 ff                     in     $0xff,%al
> Code;  c00bfedf <jffs2_build_remove_unlinked_inode+2f/ec>   <=====
>    f:   eb 00                     jmp    11 <_EIP+0x11>   <=====
> Code;  c00bfee1 <jffs2_build_remove_unlinked_inode+31/ec>
>   11:   40                        inc    %eax
> Code;  c00bfee2 <jffs2_build_remove_unlinked_inode+32/ec>
>   12:   94                        xchg   %eax,%esp
> Code;  c00bfee3 <jffs2_build_remove_unlinked_inode+33/ec>
>   13:   e5 00                     in     $0x0,%eax
> 
>  <0>Kernel panic - not syncing: Attempted to kill init!
> 
> 1 error issued.  Results may not be reliable.
> 
> 
> Kind regrads, desperated Konsti
> 
> -- 
> GPG KeyID EF62FCEF
> Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From tglx at linutronix.de  Wed Feb 16 07:01:08 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 16 Feb 2005 13:01:08 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <20050216114741.GA16239@synertronixx3>
References: <20050216114741.GA16239@synertronixx3>
Message-ID: <1108555269.24721.83.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-16 at 12:47 +0100, Konstantin Kletschke wrote:
> This way 2.6.10 Oopses on a virgin jffs2. Second boot is fine.
> cat /dev/mtdblock3 > /dev/null
> lasts three times longer than with 2.6.10-rc2.

Is this MTD from kernel or MTD CVS ? 
Is this with XIP enabled ?

tglx





From lists at ku-gbr.de  Wed Feb 16 07:20:16 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Wed, 16 Feb 2005 13:20:16 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <1108555269.24721.83.camel@tglx.tec.linutronix.de>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
Message-ID: <20050216122015.GB16239@synertronixx3>

Am 2005-02-16 13:01 +0100 schrieb Thomas Gleixner:
> On Wed, 2005-02-16 at 12:47 +0100, Konstantin Kletschke wrote:
> > This way 2.6.10 Oopses on a virgin jffs2. Second boot is fine.
> > cat /dev/mtdblock3 > /dev/null
> > lasts three times longer than with 2.6.10-rc2.
> 
> Is this MTD from kernel or MTD CVS ?

MTD out of vanilla Kernel 2.6.10.

> Is this with XIP enabled ?

No.

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From tglx at linutronix.de  Wed Feb 16 07:24:04 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 16 Feb 2005 13:24:04 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <20050216122015.GB16239@synertronixx3>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
Message-ID: <1108556645.24721.86.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-16 at 13:20 +0100, Konstantin Kletschke wrote:
> Am 2005-02-16 13:01 +0100 schrieb Thomas Gleixner:
> > On Wed, 2005-02-16 at 12:47 +0100, Konstantin Kletschke wrote:
> > > This way 2.6.10 Oopses on a virgin jffs2. Second boot is fine.
> > > cat /dev/mtdblock3 > /dev/null
> > > lasts three times longer than with 2.6.10-rc2.
> > 
> > Is this MTD from kernel or MTD CVS ?
> 
> MTD out of vanilla Kernel 2.6.10.

Can you verify, that this happens with MTD CVS code too ?

If yes, please set JFFS2_DEBUG_LEVEL = 1 and provide a log over serial
console.

tglx





From prasadamkumar at yahoo.com  Wed Feb 16 07:38:40 2005
From: prasadamkumar at yahoo.com (prasadam kumar)
Date: Wed, 16 Feb 2005 04:38:40 -0800 (PST)
Subject: How to make my IQ80321 flash Read/Write
Message-ID: <20050216123840.3449.qmail@web11608.mail.yahoo.com>


Hai to all,

I am working on intel IQ80321 flash, it is configured
as a ROM flash(map_rom.c) it supports only Read
functionality  here i am using as a char device
(/dev/mtd ) if i want to get Read/Write functionality
i am planning to move cfi_probe, so how should i
configure the cfi, if i am trying to do this it is
giving a kernel pannic like

  Cannot open root device "mtdblock2" on 1f:02

plz  suggest me to come out of this problem.


prashanth



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250



From lists at ku-gbr.de  Wed Feb 16 07:44:09 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Wed, 16 Feb 2005 13:44:09 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <1108556645.24721.86.camel@tglx.tec.linutronix.de>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
	<1108556645.24721.86.camel@tglx.tec.linutronix.de>
Message-ID: <20050216124409.GC16239@synertronixx3>

Am 2005-02-16 13:24 +0100 schrieb Thomas Gleixner:

> Can you verify, that this happens with MTD CVS code too ?

I linked drivers/mtd and fs/jffs2 into 2.6.10:

  LD      fs/built-in.o
  drivers/mtd/Makefile:11: /Makefile.inc: No such file or directory

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From tglx at linutronix.de  Wed Feb 16 08:36:28 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 16 Feb 2005 14:36:28 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <20050216124409.GC16239@synertronixx3>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
	<1108556645.24721.86.camel@tglx.tec.linutronix.de>
	<20050216124409.GC16239@synertronixx3>
Message-ID: <1108560988.24721.93.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-16 at 13:44 +0100, Konstantin Kletschke wrote:
> Am 2005-02-16 13:24 +0100 schrieb Thomas Gleixner:
> 
> > Can you verify, that this happens with MTD CVS code too ?
> 
> I linked drivers/mtd and fs/jffs2 into 2.6.10:
> 
>   LD      fs/built-in.o
>   drivers/mtd/Makefile:11: /Makefile.inc: No such file or directory

Please read

http://www.linux-mtd.infradead.org/ Section Installation 

or

mtd-cvsroot/INSTALL

tglx





From lists at ku-gbr.de  Wed Feb 16 08:37:54 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Wed, 16 Feb 2005 14:37:54 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <20050216124409.GC16239@synertronixx3>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
	<1108556645.24721.86.camel@tglx.tec.linutronix.de>
	<20050216124409.GC16239@synertronixx3>
Message-ID: <20050216133753.GD16239@synertronixx3>

Am 2005-02-16 13:44 +0100 schrieb Konstantin Kletschke:
> Am 2005-02-16 13:24 +0100 schrieb Thomas Gleixner:
> 
> > Can you verify, that this happens with MTD CVS code too ?
> 
> I linked drivers/mtd and fs/jffs2 into 2.6.10:
> 
>   LD      fs/built-in.o
>   drivers/mtd/Makefile:11: /Makefile.inc: No such file or directory

Stupid me, patchin.sh :)

elevator: using cfq as default io scheduler
Probing scb9328_flash at physical address 0x10000000 (16-bit buswidth)
scb9328_flash: Found 1 x16 devices at 0x0 in 16-bit bank              
 Intel/Sharp Extended Query Table at 0x0031             
Using buffer write method                  
cfi_cmdset_0001: Erase suspend on write enabled
5 cmdlinepart partitions found on MTD device scb9328_flash
Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
mtd: Giving out device 0 to U-boot
0x00020000-0x00040000 : "U-boot_env"
mtd: Giving out device 1 to U-boot_env
0x00040000-0x00140000 : "kernel"      
mtd: Giving out device 2 to kernel
0x00140000-0x00540000 : "root"    
mtd: Giving out device 3 to root
0x00540000-0x00940000 : "fs"    
mtd: Giving out device 4 to fs
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
NET: Registered protocol family 1                       
NET: Registered protocol family 17
EEEEEK. jffs2_mark_node_obsolete called with NULL node
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000                                                              
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in:          
CPU: 0            
pc : [<c00bfed0>]    lr : [<00000001>]    Not tainted
sp : c0219d24  ip : 60000093  fp : c0219d44          
r10: c031c8ac  r9 : c031c8c4  r8 : 00000000
r7 : c031c800  r6 : c0219d48  r5 : c033067c  r4 : 00000000
r3 : c01b1ed4  r2 : 00000000  r1 : 00000b1f  r0 : 0000003a
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: C000717F  Table: 08004000  DAC: 0000001D         
Process swapper (pid: 1, stack limit = 0xc0218190)
Stack: (0xc0219d24 to 0xc021a000)                 
9d20:          c033067c 00000000 c031c800 c0219d4c 00000000 c0219d70 c0219d48 
9d40: c00bfcf8 c00bfeb0 00000000 00000021 c031c894 c031c89c c031c8a4 c031c8b4 
9d60: c031c8bc c0219db8 c0219d74 c00c0234 c00bfb24 c031c8f8 c031c800 c031c8dc 
9d80: c031c8d4 c031c8cc c031c8ec c00d3c90 00020000 c031c800 00000000 c031c600 
9da0: c02f7400 00000000 00000000 c0219ddc c0219dbc c00c1f0c c00c001c c031c600 
9dc0: c031c800 00008000 00000000 c02f7400 c0219e00 c0219de0 c00c2548 c00c1dec 
9de0: ffffffea 00000003 c032a000 00008000 c01b97bc c0219e70 c0219e04 c00c2794 
9e00: c00c24c0 c02f7400 c007e1a8 c020ca1c c0209600 c0219ed0 c0219ed0 c0219e68 
9e20: 00000001 00000001 00000000 0000000a c02092a0 c02fa200 c032a000 00008000 
9e40: 00000000 c0219e70 c0219e54 c02092a0 fffffff4 c01b97bc c032a000 00008000 
9e60: 00000000 c0219e98 c0219e74 c006d730 c00c2610 ffffffff c032a000 00000000 
9e80: 00008000 c0219ed0 00000000 c0219ec0 c0219e9c c0082414 c006d6e4 00008000 
9ea0: 00000000 c0329000 00000000 c032a000 c0219ed0 c0219f38 c0219ec4 c0082ab4 
9ec0: c00823a0 c032a000 00000000 c0328000 c020c554 c0209600 c0219ee4 00000000 
9ee0: c0187708 00000001 00000001 00000000 00000000 00000000 c0219f14 c0219f08 
9f00: c004f5b4 00001000 c0219f38 c0219f18 00000000 00000000 c0187708 c0329000 
9f20: 00008000 00000000 00000000 c0219f6c c0219f3c c0082ed4 c0082974 00000000 
9f40: 00000000 c032a000 c0328000 c0224000 c0224000 00008000 c0187708 c01cda20 
9f60: c0219f84 c0219f70 c0008f20 c0082e40 00000000 c0224000 c0219fc8 c0219f88 
9f80: c0009004 c0008f00 c0046318 01f00003 c0187708 00000000 00000000 00000000 
9fa0: 00000000 c0219fc8 c0016720 00000000 00000000 00000000 00000000 c0219fe0 
9fc0: c0219fcc c000919c c0008fbc 00000000 c0187520 c0219ff4 c0219fe4 c0018250 
9fe0: c000914c 00000000 00000000 c0219ff8 c003475c c0018210 e3530000 091baff0 
Backtrace:                                                                    
Function entered at [<c00bfea0>] from [<c00bfcf8>]
 r8 = 00000000  r7 = C0219D4C  r6 = C031C800  r5 = 00000000
 r4 = C033067C                                             
Function entered at [<c00bfb14>] from [<c00c0234>]
 r8 = C031C8BC  r7 = C031C8B4  r6 = C031C8A4  r5 = C031C89C
 r4 = C031C894                                             
Function entered at [<c00c000c>] from [<c00c1f0c>]
Function entered at [<c00c1ddc>] from [<c00c2548>]
 r8 = C02F7400  r7 = 00000000  r6 = 00008000  r5 = C031C800
 r4 = C031C600                                             
Function entered at [<c00c24b0>] from [<c00c2794>]
 r8 = C01B97BC  r7 = 00008000  r6 = C032A000  r5 = 00000003
 r4 = FFFFFFEA                                             
Function entered at [<c00c2600>] from [<c006d730>]
Function entered at [<c006d6d4>] from [<c0082414>]
Function entered at [<c0082390>] from [<c0082ab4>]
Function entered at [<c0082964>] from [<c0082ed4>]
Function entered at [<c0082e30>] from [<c0008f20>]
 r8 = C01CDA20  r7 = C0187708  r6 = 00008000  r5 = C0224000
 r4 = C0224000                                             
Function entered at [<c0008ef0>] from [<c0009004>]
 r4 = C0224000                                    
Function entered at [<c0008fac>] from [<c000919c>]
 r8 = 00000000  r7 = 00000000  r6 = 00000000  r5 = 00000000
 r4 = C0016720                                             
Function entered at [<c000913c>] from [<c0018250>]
 r4 = C0187520                                    
Function entered at [<c0018200>] from [<c003475c>]
 r4 = 00000000                                    
Code: 0a000005 e1a01004 e1a00007 ebffe497 (e5944000) 
 <0>Kernel panic - not syncing: Attempted to kill init!

>>EIP; c00bfed0 <jffs2_build_remove_unlinked_inode+30/ec>   <=====

>>r3; c01b1ed4 <log_wait+0/8>

Trace; c00bfea0 <jffs2_build_remove_unlinked_inode+0/ec>
Trace; c00bfcf8 <jffs2_build_filesystem+1e4/38c>
Trace; c00bfb14 <jffs2_build_filesystem+0/38c>
Trace; c00c0234 <jffs2_do_mount_fs+228/270>
Trace; c00c000c <jffs2_do_mount_fs+0/270>
Trace; c00c1f0c <jffs2_do_fill_super+130/238>
Trace; c00c1ddc <jffs2_do_fill_super+0/238>
Trace; c00c2548 <jffs2_get_sb_mtd+98/f8>
Trace; c00c24b0 <jffs2_get_sb_mtd+0/f8>
Trace; c00c2794 <jffs2_get_sb+194/1d0>

>>r8; c01b97bc <jffs2_fs_type+0/20>

Trace; c00c2600 <jffs2_get_sb+0/1d0>
Trace; c006d730 <do_kern_mount+5c/f4>
Trace; c006d6d4 <do_kern_mount+0/f4>
Trace; c0082414 <do_new_mount+84/b8>
Trace; c0082390 <do_new_mount+0/b8>
Trace; c0082ab4 <do_mount+150/16c>
Trace; c0082964 <do_mount+0/16c>
Trace; c0082ed4 <sys_mount+a4/e8>
Trace; c0082e30 <sys_mount+0/e8>
Trace; c0008f20 <do_mount_root+30/bc>

>>r8; c01cda20 <names_cachep+0/4>
>>r7; c0187708 <__func__.4+450/18c48>

Trace; c0008ef0 <do_mount_root+0/bc>
Trace; c0009004 <mount_block_root+58/124>
Trace; c0008fac <mount_block_root+0/124>
Trace; c000919c <prepare_namespace+60/a0>

>>r4; c0016720 <root_device_name+0/4>

Trace; c000913c <prepare_namespace+0/a0>
Trace; c0018250 <init+50/f0>

>>r4; c0187520 <__func__.4+268/18c48>

Trace; c0018200 <init+0/f0>
Trace; c003475c <do_exit+0/3d8>

Code;  c00bfec0 <jffs2_build_remove_unlinked_inode+20/ec>
00000000 <_EIP>:
Code;  c00bfec0 <jffs2_build_remove_unlinked_inode+20/ec>
   0:   05 00 00 0a 04            add    $0x40a0000,%eax
Code;  c00bfec5 <jffs2_build_remove_unlinked_inode+25/ec>
   5:   10 a0 e1 07 00 a0         adc    %ah,0xa00007e1(%eax)
Code;  c00bfecb <jffs2_build_remove_unlinked_inode+2b/ec>
   b:   e1 97                     loope  ffffffa4 <_EIP+0xffffffa4>
Code;  c00bfecd <jffs2_build_remove_unlinked_inode+2d/ec>
   d:   e4 ff                     in     $0xff,%al
Code;  c00bfecf <jffs2_build_remove_unlinked_inode+2f/ec>   <=====
   f:   eb 00                     jmp    11 <_EIP+0x11>   <=====
Code;  c00bfed1 <jffs2_build_remove_unlinked_inode+31/ec>
  11:   40                        inc    %eax
Code;  c00bfed2 <jffs2_build_remove_unlinked_inode+32/ec>
  12:   94                        xchg   %eax,%esp
Code;  c00bfed3 <jffs2_build_remove_unlinked_inode+33/ec>
  13:   e5 00                     in     $0x0,%eax

 <0>Kernel panic - not syncing: Attempted to kill init!

K

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From tglx at linutronix.de  Wed Feb 16 09:05:56 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 16 Feb 2005 15:05:56 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <20050216133753.GD16239@synertronixx3>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
	<1108556645.24721.86.camel@tglx.tec.linutronix.de>
	<20050216124409.GC16239@synertronixx3>
	<20050216133753.GD16239@synertronixx3>
Message-ID: <1108562757.24721.103.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-16 at 14:37 +0100, Konstantin Kletschke wrote:
> Am 2005-02-16 13:44 +0100 schrieb Konstantin Kletschke:
> > Am 2005-02-16 13:24 +0100 schrieb Thomas Gleixner:
> > 
> > > Can you verify, that this happens with MTD CVS code too ?
> > 
> > I linked drivers/mtd and fs/jffs2 into 2.6.10:
> > 
> >   LD      fs/built-in.o
> >   drivers/mtd/Makefile:11: /Makefile.inc: No such file or directory
> 
> Stupid me, patchin.sh :)

:)

Please turn on JFFS2 debuglevel 1 and use a serial console for logging.

Boot with nfsroot and do

# cat /dev/mtd3 >image.bin

Then try to mount:

# echo 9 >/proc/sys/kernel/printk
# mount /dev/mtd3

Send me the log and the binary image.

I guess you create a jffs2 image with mkfs.jffs2. How do you program it
to the FLASH ? Please send me the original image too.

tglx





From estelle.hammache at st.com  Wed Feb 16 09:54:16 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Wed, 16 Feb 2005 15:54:16 +0100
Subject: Oops vanilla 2.6.10
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
	<1108556645.24721.86.camel@tglx.tec.linutronix.de>
	<20050216124409.GC16239@synertronixx3>
	<20050216133753.GD16239@synertronixx3>
Message-ID: <42135E98.E187DD1A@st.com>

Konstantin Kletschke wrote:
> EEEEEK. jffs2_mark_node_obsolete called with NULL node

> >>EIP; c00bfed0 <jffs2_build_remove_unlinked_inode+30/ec>   <=====
> 
> >>r3; c01b1ed4 <log_wait+0/8>
> 
> Trace; c00bfea0 <jffs2_build_remove_unlinked_inode+0/ec>
> Trace; c00bfcf8 <jffs2_build_filesystem+1e4/38c>
> Trace; c00bfb14 <jffs2_build_filesystem+0/38c>

Not sure this is relevant, (and I have no way to test it right now), 
but it could be related to the obsolete node merging. You have NOR
flash haven't you ?

In jffs2_build_remove_unlinked_inode 
	raw = ic->nodes;
	while (raw != (void *)ic) {
		struct jffs2_raw_node_ref *next = raw->next_in_ino;
		D1(printk(KERN_DEBUG "obsoleting node at 0x%08x\n", ref_offset(raw)));
		jffs2_mark_node_obsolete(c, raw);
		raw = next;
	}

However if "next" is also raw->next_phys and is already obsolete 
and is the last in the next_in_ino chain, I think it may be 
freed in jffs2_mark_node_obsolete:

	/* Merge with the next node in the physical list, if there is one
	   and if it's also obsolete and if it doesn't belong to any inode */
	if (ref->next_phys && ref_obsolete(ref->next_phys) &&
	    !ref->next_phys->next_in_ino) {
		struct jffs2_raw_node_ref *n = ref->next_phys;
		
		spin_lock(&c->erase_completion_lock);

		ref->__totlen += n->__totlen;
		ref->next_phys = n->next_phys;
                if (jeb->last_node == n) jeb->last_node = ref;
		if (jeb->gc_node == n) {
			/* gc will be happy continuing gc on this node */
			jeb->gc_node=ref;
		}
		spin_unlock(&c->erase_completion_lock);

		jffs2_free_raw_node_ref(n);
	}

This would explain things... if you think it is plausible you could
try commenting out the node merging in jffs2_mark_node_obsolete.

Estelle



From dedekind at infradead.org  Wed Feb 16 10:28:37 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 16 Feb 2005 15:28:37 +0000 (GMT)
Subject: Oops vanilla 2.6.10
In-Reply-To: <42135E98.E187DD1A@st.com>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
	<1108556645.24721.86.camel@tglx.tec.linutronix.de>
	<20050216124409.GC16239@synertronixx3>
	<20050216133753.GD16239@synertronixx3> <42135E98.E187DD1A@st.com>
Message-ID: <Pine.LNX.4.58.0502161528260.30538@phoenix.infradead.org>

Estelle HAMMACHE wrote:
> This would explain things... if you think it is plausible you could
> try commenting out the node merging in jffs2_mark_node_obsolete.
> 
I think Estelle is correct.
I would offer the following fix:

--- build.c     2005-02-16 18:21:41.253701801 +0300
+++ build.c-modified    2005-02-16 18:27:56.451612461 +0300
@@ -194,8 +194,10 @@
        D1(printk(KERN_DEBUG "JFFS2: Removing ino #%u with nlink == 
zero.\n", ic->ino));

        raw = ic->nodes;
-       while (raw != (void *)ic) {
+       while (raw && raw != (void *)ic) {
                struct jffs2_raw_node_ref *next = raw->next_in_ino;
+               while(next && ref_obsolete(next))
+                       next = next->next_in_ino;
                D1(printk(KERN_DEBUG "obsoleting node at 0x%08x\n", 
ref_offset(raw)));
                jffs2_mark_node_obsolete(c, raw);
                raw = next;

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From lists at ku-gbr.de  Wed Feb 16 11:29:45 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Wed, 16 Feb 2005 17:29:45 +0100
Subject: Oops vanilla 2.6.10
In-Reply-To: <Pine.LNX.4.58.0502161528260.30538@phoenix.infradead.org>
References: <20050216114741.GA16239@synertronixx3>
	<1108555269.24721.83.camel@tglx.tec.linutronix.de>
	<20050216122015.GB16239@synertronixx3>
	<1108556645.24721.86.camel@tglx.tec.linutronix.de>
	<20050216124409.GC16239@synertronixx3>
	<20050216133753.GD16239@synertronixx3> <42135E98.E187DD1A@st.com>
	<Pine.LNX.4.58.0502161528260.30538@phoenix.infradead.org>
Message-ID: <20050216162944.GE16239@synertronixx3>

Am 2005-02-16 15:28 +0000 schrieb Artem B. Bityuckiy:

> I think Estelle is correct.
> I would offer the following fix:

EEEEEK. jffs2_mark_node_obsolete called with NULL node

Internal error: Oops: 5 [#1]
CPU: 0            
pc : [<c00c319c>]    lr : [<00000001>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
sp : c020fd24  ip : 60000093  fp : c020fd44          
r10: c03248ac  r9 : c03248c4  r8 : 00000000
r7 : c0324800  r6 : c020fd48  r5 : c033867c  r4 : 00000000
r3 : c01b7ed4  r2 : 00000000  r1 : 00000b89  r0 : 0000003a
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: C000717F  Table: 08004000  DAC: 0000001D         
Stack: (0xc020fd24 to 0xc0210000)                 
fd20:          c033867c 00000000 c0324800 c020fd4c 00000000 c020fd70 c020fd48 
fd40: c00c2fc4 c00c317c 00000000 00000021 c0324894 c032489c c03248a4 c03248b4 
fd60: c03248bc c020fdb8 c020fd74 c00c3500 c00c2df0 c03248f8 c0324800 c03248dc 
fd80: c03248d4 c03248cc c03248ec c00d6f50 00020000 c0324800 00000000 c0324600 
fda0: c02fe400 00000000 00000000 c020fddc c020fdbc c00c51d8 c00c32e8 c0324600 
fdc0: c0324800 00008000 00000000 c02fe400 c020fe00 c020fde0 c00c5814 c00c50b8 
fde0: ffffffea 00000003 c0332000 00008000 c01bf85c c020fe70 c020fe04 c00c5a60 
fe00: c00c578c c02fe400 c00811a8 c0298bb4 c0210600 c020fed0 c020fed0 c020fe68 
fe20: 00000001 00000001 00000000 0000000a c02102a0 c02fff00 c0332000 00008000 
fe40: 00000000 c020fe70 c020fe54 c02102a0 fffffff4 c01bf85c c0332000 00008000 
fe60: 00000000 c020fe98 c020fe74 c0070730 c00c58dc ffffffff c0332000 00000000 
fe80: 00008000 c020fed0 00000000 c020fec0 c020fe9c c0085414 c00706e4 00008000 
fea0: 00000000 c0331000 00000000 c0332000 c020fed0 c020ff38 c020fec4 c0085ab4 
fec0: c00853a0 c0332000 00000000 c0330000 c0213554 c0210600 c020fee4 00000000 
fee0: c018c454 00000001 00000001 00000000 00000000 00000000 c020ff14 c020ff08 
ff00: c00525b4 00001000 c020ff38 c020ff18 00000000 00000000 c018c454 c0331000 
ff20: 00008000 00000000 00000000 c020ff6c c020ff3c c0085ed4 c0085974 00000000 
ff40: 00000000 c0332000 c0330000 c0225000 c0225000 00008000 c018c454 c01d3be0 
ff60: c020ff84 c020ff70 c0008f20 c0085e40 00000000 c0225000 c020ffc8 c020ff88 
ff80: c0009004 c0008f00 c0049318 6264746d 01f00003 00000000 00000000 00000000 
ffa0: 00000000 00000000 c0018d20 00000000 00000000 00000000 00000000 c020ffe0 
ffc0: c020ffcc c0009258 c0008fbc 00000000 c018c26c c020fff4 c020ffe4 c001b250 
ffe0: c0009208 00000000 00000000 c020fff8 c003775c c001b210 e91ba830 e51b2024 
Backtrace:                                                                    
Function entered at [<c00c316c>] from [<c00c2fc4>]
 r8 = 00000000  r7 = C020FD4C  r6 = C0324800  r5 = 00000000
 r4 = C033867C                                             
Function entered at [<c00c2de0>] from [<c00c3500>]
 r8 = C03248BC  r7 = C03248B4  r6 = C03248A4  r5 = C032489C
 r4 = C0324894                                             
Function entered at [<c00c32d8>] from [<c00c51d8>]
Function entered at [<c00c50a8>] from [<c00c5814>]
 r8 = C02FE400  r7 = 00000000  r6 = 00008000  r5 = C0324800
 r4 = C0324600                                             
Function entered at [<c00c577c>] from [<c00c5a60>]
 r8 = C01BF85C  r7 = 00008000  r6 = C0332000  r5 = 00000003
 r4 = FFFFFFEA                                             
Function entered at [<c00c58cc>] from [<c0070730>]
Function entered at [<c00706d4>] from [<c0085414>]
Function entered at [<c0085390>] from [<c0085ab4>]
Function entered at [<c0085964>] from [<c0085ed4>]
Function entered at [<c0085e30>] from [<c0008f20>]
 r8 = C01D3BE0  r7 = C018C454  r6 = 00008000  r5 = C0225000
 r4 = C0225000                                             
Function entered at [<c0008ef0>] from [<c0009004>]
 r4 = C0225000                                    
Function entered at [<c0008fac>] from [<c0009258>]
 r8 = 00000000  r7 = 00000000  r6 = 00000000  r5 = 00000000
 r4 = C0018D20                                             
Function entered at [<c00091f8>] from [<c001b250>]
 r4 = C018C26C                                    
Function entered at [<c001b200>] from [<c003775c>]
 r4 = 00000000                                    
Code: 0a000005 e1a01004 e1a00007 ebffe497 (e5944000) 


>>EIP; c00c319c <zlib_inflate_blocks+168/a6c>   <=====

>>sp; c020fd24 <__log_buf+3f5c/4000>
>>fp; c020fd44 <__log_buf+3f7c/4000>
>>r6; c020fd48 <__log_buf+3f80/4000>
>>r3; c01b7ed4 <ip_mc_source+290/3c0>

Trace; c00c316c <zlib_inflate_blocks+138/a6c>
Trace; c00c2fc4 <zlib_inflate_blocks_reset+5c/78>

>>r7; c020fd4c <__log_buf+3f84/4000>

Trace; c00c2de0 <iowrite16_rep+30/54>
Trace; c00c3500 <zlib_inflate_blocks+4cc/a6c>
Trace; c00c32d8 <zlib_inflate_blocks+2a4/a6c>
Trace; c00c51d8 <huft_build+ec/5b4>
Trace; c00c50a8 <zlib_inflate_addhistory+104/118>
Trace; c00c5814 <zlib_inflate_trees_dynamic+dc/180>
Trace; c00c577c <zlib_inflate_trees_dynamic+44/180>
Trace; c00c5a60 <zlib_inflate_trees_fixed+1a8/1e8>

>>r8; c01bf85c <sleep_on_timeout+a4/a8>

Trace; c00c58cc <zlib_inflate_trees_fixed+14/1e8>
Trace; c0070730 <sync_filesystems+6c/134>
Trace; c00706d4 <sync_filesystems+10/134>
Trace; c0085414 <do_umount+b8/154>
Trace; c0085390 <do_umount+34/154>
Trace; c0085ab4 <do_move_mount+24/250>
Trace; c0085964 <do_loopback+108/16c>
Trace; c0085ed4 <do_add_mount+13c/14c>
Trace; c0085e30 <do_add_mount+98/14c>
Trace; c0008f20 <do_mount_root+3c/bc>

>>r8; c01d3be0 <__func__.1+10098/1ee58>
>>r7; c018c454 <ip_route_output_slow+448/808>

Trace; c0008ef0 <do_mount_root+c/bc>
Trace; c0009004 <mount_block_root+64/124>
Trace; c0008fac <mount_block_root+c/124>
Trace; c0009258 <find_link+38/bc>

>>r4; c0018d20 <default_command_line+44/400>

Trace; c00091f8 <malloc+4/18>
Trace; c001b250 <check_irq_lock+58/94>

>>r4; c018c26c <ip_route_output_slow+260/808>

Trace; c001b200 <check_irq_lock+8/94>
Trace; c003775c <sys_exit_group+c/1c>

Code;  c00c318c <zlib_inflate_blocks+158/a6c>
00000000 <_EIP>:
Code;  c00c318c <zlib_inflate_blocks+158/a6c>
   0:   05 00 00 0a 04            add    $0x40a0000,%eax
Code;  c00c3191 <zlib_inflate_blocks+15d/a6c>
   5:   10 a0 e1 07 00 a0         adc    %ah,0xa00007e1(%eax)
Code;  c00c3197 <zlib_inflate_blocks+163/a6c>
   b:   e1 97                     loope  ffffffa4 <_EIP+0xffffffa4>
Code;  c00c3199 <zlib_inflate_blocks+165/a6c>
   d:   e4 ff                     in     $0xff,%al
Code;  c00c319b <zlib_inflate_blocks+167/a6c>   <=====
   f:   eb 00                     jmp    11 <_EIP+0x11>   <=====
Code;  c00c319d <zlib_inflate_blocks+169/a6c>
  11:   40                        inc    %eax
Code;  c00c319e <zlib_inflate_blocks+16a/a6c>
  12:   94                        xchg   %eax,%esp
Code;  c00c319f <zlib_inflate_blocks+16b/a6c>
  13:   e5 00                     in     $0x0,%eax

 <0>Kernel panic - not syncing: Attempted to kill init!

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From h.bobzin at icp-ag.de  Wed Feb 16 11:39:39 2005
From: h.bobzin at icp-ag.de (Bobzin,Heiko)
Date: Wed, 16 Feb 2005 17:39:39 +0100
Subject: Data corrupted
Message-ID: <256713DBAA00D911828C00065BF75DEB025F72@icpmail-hh.icp-intern.de>

Hello mtd-fellows,

I ran into trouble with a test I've implemented. It is basically the same
as the mtd-util checkfs: writing into the flash while powering down
the device. The problem is, that files which are never touched are
corrupted, not the data I write.
I diff'd the data and exactly one 4K block is set to zero in a 500k file
in a ~7MB JFFS2 flash partition.
It is reproducible in some hours, but the location differs.

Here is the info about the chips and the system:

MX29LV640T (64Mbit)
Flash:  8 MB

Linux version 2.4.27-vrs1 (root at linux) (gcc version 3.4.3) #16 Wed Feb 16
12:24:31 CET 2005
with latest stable mtd patched.

CPU: Arm920Tid(wb) revision 0
Machine: ATMEL AT91RM9200

 Amd/Fujitsu Extended Query Table at 0x0040
  Silicon revision: 0
  Address sensitive unlock: Required
  Erase Suspend: Read/write
  Block protection: 4 sectors per group
  Temporary block unprotect: Supported
  Block protect/unprotect scheme: 4
  Number of simultaneous operations: 0
  Burst mode: Not supported
  Page mode: Not supported
  Vpp Supply Minimum Program/Erase Voltage: 0.0 V
  Vpp Supply Maximum Program/Erase Voltage: 0.0 V
  Top/Bottom Boot Block: Top boot

Last messages while booting, before detecting the corrupted file:

Node header CRC failed at 001f4ec8. But it must have been OK earlier.
Node was: { 0000, 2000, 00000000, 00000000 }
Eep. Unknown node type 0000 at 00603348 was marked REF_UNCHECKED
Node header CRC failed at 00603348. But it must have been OK earlier.
Node was: { 0000, 2000, 00000000, 00000000 }
jffs2_do_read_inode(): No data nodes found for ino #294
Returned error for crccheck of ino #294. Expect badness...

I've also seen read errors, though after a later reboot the system was
intact
and the "read error" was gone.

Any ideas? Does it look like a hardware (chip timing) or software problem?

Thanks in advance,
Heiko




From dedekind at yandex.ru  Wed Feb 16 11:51:38 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Wed, 16 Feb 2005 19:51:38 +0300
Subject: Oops vanilla 2.6.10
In-Reply-To: <20050216162944.GE16239@synertronixx3>
References: <20050216114741.GA16239@synertronixx3>	<1108555269.24721.83.camel@tglx.tec.linutronix.de>	<20050216122015.GB16239@synertronixx3>	<1108556645.24721.86.camel@tglx.tec.linutronix.de>	<20050216124409.GC16239@synertronixx3>	<20050216133753.GD16239@synertronixx3>
	<42135E98.E187DD1A@st.com>	<Pine.LNX.4.58.0502161528260.30538@phoenix.infradead.org>
	<20050216162944.GE16239@synertronixx3>
Message-ID: <42137A1A.3090004@yandex.ru>

Then I'd like to see the full debug output.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From dedekind at infradead.org  Wed Feb 16 12:02:34 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 16 Feb 2005 17:02:34 +0000 (GMT)
Subject: Data corrupted
In-Reply-To: <256713DBAA00D911828C00065BF75DEB025F72@icpmail-hh.icp-intern.de>
References: <256713DBAA00D911828C00065BF75DEB025F72@icpmail-hh.icp-intern.de>
Message-ID: <Pine.LNX.4.58.0502161702270.30538@phoenix.infradead.org>

Hello

1. Messages like "Node header CRC failed at 001f4ec8." are normal after 
unclean reboots. 

But the fact that you lost data which weren't engaged is *not normal*. 
Theoretically, if JFFS2 has no bugs, static data can't be lost.

I suspect JFFS2 may have bug: after block is GCed, it is erased, and wbuf 
isn't sync-ed before erase. I'll see the relative places in JFFS2 and 
check if it possible. If it is, it definitely must be fixed.

Bobzin,Heiko wrote:
> Hello mtd-fellows,
> 
> I ran into trouble with a test I've implemented. It is basically the 
same
> as the mtd-util checkfs: writing into the flash while powering down
> the device. The problem is, that files which are never touched are
> corrupted, not the data I write.
> I diff'd the data and exactly one 4K block is set to zero in a 500k file
> in a ~7MB JFFS2 flash partition.
> It is reproducible in some hours, but the location differs.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From dedekind at infradead.org  Wed Feb 16 12:20:07 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 16 Feb 2005 17:20:07 +0000 (GMT)
Subject: Data corrupted
In-Reply-To: <256713DBAA00D911828C00065BF75DEB025F72@icpmail-hh.icp-intern.de>
References: <256713DBAA00D911828C00065BF75DEB025F72@icpmail-hh.icp-intern.de>
Message-ID: <Pine.LNX.4.58.0502161715080.30538@phoenix.infradead.org>

Please, provide the information about MTD/JFFS2 you use.
May you try the latest MTD snapshot? I don't think it will help, but this 
anyway good idea.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From rddunlap at osdl.org  Wed Feb 16 19:06:45 2005
From: rddunlap at osdl.org (Randy.Dunlap)
Date: Wed, 16 Feb 2005 16:06:45 -0800
Subject: [PATCH] MTD: use unsigned 1-bit fields
Message-ID: <20050216160645.3438421f.rddunlap@osdl.org>

since a 1-bit field cannot hold a truth value and a sign bit.

Fix (22) bitfield/boolean sparse warnings:
include/linux/mtd/flashchip.h:65:23: warning: dubious one-bit signed bitfield
include/linux/mtd/flashchip.h:66:23: warning: dubious one-bit signed bitfield

Signed-off-by: Randy Dunlap <rddunlap at osdl.org>

diffstat:=
 include/linux/mtd/flashchip.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp ./include/linux/mtd/flashchip.h~mtd_flashchip_bool ./include/linux/mtd/flashchip.h
--- ./include/linux/mtd/flashchip.h~mtd_flashchip_bool	2005-02-15 13:48:46.633263712 -0800
+++ ./include/linux/mtd/flashchip.h	2005-02-15 20:25:20.924981544 -0800
@@ -62,8 +62,8 @@ struct flchip {
 	flstate_t state;
 	flstate_t oldstate;
 
-	int write_suspended:1;
-	int erase_suspended:1;
+	unsigned int write_suspended:1;
+	unsigned int erase_suspended:1;
 	unsigned long in_progress_block_addr;
 
 	spinlock_t *mutex;


---



From dedekind at infradead.org  Thu Feb 17 09:25:01 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 17 Feb 2005 14:25:01 +0000 (GMT)
Subject: [PATCH] JFFS2 symlink cache
Message-ID: <Pine.LNX.4.58.0502171424040.30538@phoenix.infradead.org>

Hello,

here is the JFFS2 patch which adds the symlink caching. In practice, the 
patch speeds up the processes startup.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
diff --exclude=CVS -auNr mtd-pristine/fs/jffs2/dir.c mtd-symlink/fs/jffs2/dir.c
--- mtd-pristine/fs/jffs2/dir.c	2005-02-16 10:35:07.000000000 +0300
+++ mtd-symlink/fs/jffs2/dir.c	2005-02-15 12:45:02.000000000 +0300
@@ -296,11 +296,11 @@
 	struct jffs2_full_dirent *fd;
 	int namelen;
 	uint32_t alloclen, phys_ofs;
-	int ret;
+	int ret, targetlen = strlen(target);
 
 	/* FIXME: If you care. We'd need to use frags for the target
 	   if it grows much more than this */
-	if (strlen(target) > 254)
+	if (targetlen > 254)
 		return -EINVAL;
 
 	ri = jffs2_alloc_raw_inode();
@@ -314,7 +314,7 @@
 	 * Just the node will do for now, though 
 	 */
 	namelen = dentry->d_name.len;
-	ret = jffs2_reserve_space(c, sizeof(*ri) + strlen(target), &phys_ofs, &alloclen, ALLOC_NORMAL);
+	ret = jffs2_reserve_space(c, sizeof(*ri) + targetlen, &phys_ofs, &alloclen, ALLOC_NORMAL);
 
 	if (ret) {
 		jffs2_free_raw_inode(ri);
@@ -333,16 +333,16 @@
 
 	f = JFFS2_INODE_INFO(inode);
 
-	inode->i_size = strlen(target);
+	inode->i_size = targetlen;
 	ri->isize = ri->dsize = ri->csize = cpu_to_je32(inode->i_size);
 	ri->totlen = cpu_to_je32(sizeof(*ri) + inode->i_size);
 	ri->hdr_crc = cpu_to_je32(crc32(0, ri, sizeof(struct jffs2_unknown_node)-4));
 
 	ri->compr = JFFS2_COMPR_NONE;
-	ri->data_crc = cpu_to_je32(crc32(0, target, strlen(target)));
+	ri->data_crc = cpu_to_je32(crc32(0, target, targetlen));
 	ri->node_crc = cpu_to_je32(crc32(0, ri, sizeof(*ri)-8));
 	
-	fn = jffs2_write_dnode(c, f, ri, target, strlen(target), phys_ofs, ALLOC_NORMAL);
+	fn = jffs2_write_dnode(c, f, ri, target, targetlen, phys_ofs, ALLOC_NORMAL);
 
 	jffs2_free_raw_inode(ri);
 
@@ -353,6 +353,20 @@
 		jffs2_clear_inode(inode);
 		return PTR_ERR(fn);
 	}
+
+	/* We use f->dents field to store the target path. */
+	f->dents = kmalloc(targetlen + 1, GFP_KERNEL);
+	if (!f->dents) {
+		printk(KERN_WARNING "Can't allocate %d bytes of memory\n", targetlen + 1);
+		up(&f->sem);
+		jffs2_complete_reservation(c);
+		jffs2_clear_inode(inode);
+		return -ENOMEM;
+	}
+
+	memcpy(f->dents, target, targetlen + 1);
+	D1(printk(KERN_DEBUG "jffs2_symlink: symlink's target '%s' cached\n", (char *)f->dents));
+
 	/* No data here. Only a metadata node, which will be 
 	   obsoleted by the first data write
 	*/
diff --exclude=CVS -auNr mtd-pristine/fs/jffs2/read.c mtd-symlink/fs/jffs2/read.c
--- mtd-pristine/fs/jffs2/read.c	2005-02-16 10:35:08.000000000 +0300
+++ mtd-symlink/fs/jffs2/read.c	2005-02-15 13:23:05.000000000 +0300
@@ -218,7 +218,6 @@
 char *jffs2_getlink(struct jffs2_sb_info *c, struct jffs2_inode_info *f)
 {
 	char *buf;
-	int ret;
 
 	down(&f->sem);
 
@@ -232,15 +231,12 @@
 		up(&f->sem);
 		return ERR_PTR(-ENOMEM);
 	}
-	buf[f->metadata->size]=0;
 
-	ret = jffs2_read_dnode(c, f, f->metadata, buf, 0, f->metadata->size);
+	memcpy(buf, f->dents, f->metadata->size+1);
+
+	D1(printk(KERN_DEBUG "jffs2_getlink(): target path is '%s'\n", buf));
 
 	up(&f->sem);
 
-	if (ret) {
-		kfree(buf);
-		return ERR_PTR(ret);
-	}
 	return buf;
 }
diff --exclude=CVS -auNr mtd-pristine/fs/jffs2/readinode.c mtd-symlink/fs/jffs2/readinode.c
--- mtd-pristine/fs/jffs2/readinode.c	2005-02-16 10:35:07.000000000 +0300
+++ mtd-symlink/fs/jffs2/readinode.c	2005-02-17 17:18:01.629635056 +0300
@@ -4,7 +4,10 @@
  * Copyright (C) 2001-2003 Red Hat, Inc.
  *
  * Created by David Woodhouse <dwmw2 at infradead.org>
- *
+ * 
+ * 2005-02-16, Artem B. Bityuckiy, <dedekind at infradead.org>
+ * 	add symlink target caching support
+ * 	
  * For licensing information, see the file 'LICENCE' in this directory.
  *
  * $Id: readinode.c,v 1.117 2004/11/20 18:06:54 dwmw2 Exp $
@@ -623,6 +626,40 @@
 		   case. */
 		if (!je32_to_cpu(latest_node->isize))
 			latest_node->isize = latest_node->dsize;
+
+		if (f->inocache->state != INO_STATE_CHECKING) {
+			/* Symlink's inode data is the target path. Read it and
+			 * keep in RAM to facilitate quick follow symlink operation.
+			 * We use f->dents field to store the target path, which
+			 * is somewhat ugly. */
+			f->dents = kmalloc(je32_to_cpu(latest_node->csize) + 1, GFP_KERNEL);
+			if (!f->dents) {
+				printk(KERN_WARNING "Can't allocate %d bytes of memory "
+						"for the symlink target path cache\n",
+						je32_to_cpu(latest_node->csize));
+				up(&f->sem);
+				jffs2_do_clear_inode(c, f);
+				return -ENOMEM;
+			}
+			
+			ret = jffs2_flash_read(c, ref_offset(fn->raw) + sizeof(*latest_node),
+						je32_to_cpu(latest_node->csize), &retlen, (char *)f->dents);
+			
+			if (ret  || retlen != je32_to_cpu(latest_node->csize)) {
+				if (retlen != je32_to_cpu(latest_node->csize))
+					ret = -EIO;
+				kfree(f->dents);
+				f->dents = NULL;
+				up(&f->sem);
+				jffs2_do_clear_inode(c, f);
+				return -ret;
+			}
+
+			((char *)f->dents)[je32_to_cpu(latest_node->csize)] = '\0';
+			D1(printk(KERN_DEBUG "jffs2_do_read_inode(): symlink's target '%s' cached\n",
+						(char *)f->dents));
+		}
+		
 		/* fall through... */
 
 	case S_IFBLK:
@@ -680,12 +717,20 @@
 
 	jffs2_kill_fragtree(&f->fragtree, deleted?c:NULL);
 
-	fds = f->dents;
+	/* For symlink inodes we utilize f->dents to store the target path name */
+	if ((OFNI_EDONI_2SFFJ(f)->i_mode & S_IFMT) == S_IFLNK) {
+		if (f->dents) {
+			kfree(f->dents);
+			f->dents = NULL;
+		}
+	} else {
+		fds = f->dents;
 
-	while(fds) {
-		fd = fds;
-		fds = fd->next;
-		jffs2_free_full_dirent(fd);
+		while(fds) {
+			fd = fds;
+			fds = fd->next;
+			jffs2_free_full_dirent(fd);
+		}
 	}
 
 	if (f->inocache && f->inocache->state != INO_STATE_CHECKING)

From dwmw2 at infradead.org  Thu Feb 17 09:41:10 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 17 Feb 2005 14:41:10 +0000
Subject: [PATCH] JFFS2 symlink cache
In-Reply-To: <Pine.LNX.4.58.0502171424040.30538@phoenix.infradead.org>
References: <Pine.LNX.4.58.0502171424040.30538@phoenix.infradead.org>
Message-ID: <1108651270.19262.664.camel@hades.cambridge.redhat.com>

On Thu, 2005-02-17 at 14:25 +0000, Artem B. Bityuckiy wrote:
> 
> +       /* We use f->dents field to store the target path. */
> +       f->dents = kmalloc(targetlen + 1, GFP_KERNEL);

Why aren't you just using the standard page_symlink_ops so that the
cache can be correctly discarded on memory pressure?

-- 
dwmw2




From araav at hylink.am  Thu Feb 17 10:02:24 2005
From: araav at hylink.am (Ara Avanesyan)
Date: Thu, 17 Feb 2005 19:02:24 +0400 (AMT)
Subject: Software Requirement && DiskOnChip
Message-ID: <200502171502.j1HF2OtT044879@forof.hylink.am>

Hi,

  Everywhere in DiskOnChip files there are referneces to a magic "Software
Requirement 11.x.y".
Can someone please tell me where can I locate one?

  Also, where can I find the descriptions of the registers
DoC_Mplus_FlashControl through DoC_Mplus_WritePipeTerm
defined in doc2000.h? The data-sheet for MPlus DOC device does not contain
this info.

__
Thanks,
Ara



From dwmw2 at infradead.org  Thu Feb 17 11:24:18 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 17 Feb 2005 16:24:18 +0000
Subject: Software Requirement && DiskOnChip
In-Reply-To: <200502171502.j1HF2OtT044879@forof.hylink.am>
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
Message-ID: <1108657458.19262.671.camel@hades.cambridge.redhat.com>

On Thu, 2005-02-17 at 19:02 +0400, Ara Avanesyan wrote:
>   Everywhere in DiskOnChip files there are referneces to a magic
> "Software Requirement 11.x.y".
> Can someone please tell me where can I locate one?
> 
>   Also, where can I find the descriptions of the registers
> DoC_Mplus_FlashControl through DoC_Mplus_WritePipeTerm
> defined in doc2000.h? The data-sheet for MPlus DOC device does not
> contain this info.

Unfortunately I don't think these are publicly available. Although I
have a vague recollection of being corrected last time I said that.

-- 
dwmw2




From dedekind at infradead.org  Thu Feb 17 13:26:26 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 17 Feb 2005 18:26:26 +0000 (GMT)
Subject: Data corrupted
In-Reply-To: <256713DBAA00D911828C00065BF75DEB025F72@icpmail-hh.icp-intern.de>
References: <256713DBAA00D911828C00065BF75DEB025F72@icpmail-hh.icp-intern.de>
Message-ID: <Pine.LNX.4.58.0502171826130.30538@phoenix.infradead.org>

Heiko,

please try this patch (fs/jffs2/nodemgmt.c).

--- nodemgmt.c  2005-01-25 23:11:11.000000000 +0300
+++ nodemgmt-fixed.c    2005-02-17 21:22:30.608220411 +0300
@@ -483,7 +483,7 @@

        if (jeb == c->nextblock) {
                D2(printk(KERN_DEBUG "Not moving nextblock 0x%08x to 
dirty/erase_pending list\n", jeb->offset));
-       } else if (!jeb->used_size && !jeb->unchecked_size) {
+       } else if ((jeb->used_size + jeb->unchecked_size) == 
PAD(c->cleanmarker_size)) {
                if (jeb == c->gcblock) {
                        D1(printk(KERN_DEBUG "gcblock at 0x%08x completely 
dirtied. Clearing gcblock...\n", jeb->offset));
                        c->gcblock = NULL;

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From joseph.barnett at gmail.com  Thu Feb 17 15:25:22 2005
From: joseph.barnett at gmail.com (Joe Barnett)
Date: Thu, 17 Feb 2005 15:25:22 -0500
Subject: symlink corruption in jffs2
Message-ID: <52249cdc0502171225706e3cf8@mail.gmail.com>

I am trying to put a jffs2 filesystem down on a G5 ppc64 system. I can
build the filesystem fine, and get it into flash, mount it ect. The
problem I am finding is that a large number of the symbolic links are
corrupt. The file pointed to has garbage appended to the name (see
below). If I try to create a new symlink, it also gets corrupted. I
have turned on JFFS2 debug to level 3 and am still unable to locate
the source of the issue...  I am using the following options when I
run mkfs.jffs2:

mkfs.jffs2 -o myflashfs.img -d myroot -e 20000

I am using Common Intel StrataFlash, which I have confirmed that
driver is functional, as I can read and write large file to and from
the flash fine, so it isn't in the driver.  Has anyone seen this issue
before or does anyone have an idea of what may be causing this?  I did
see Any help would be greatly appreciated.

Kind regards,
Joseph Barnett

SYM LINK CORRUPTION:
:/flash/lib# ls -l
total 4934
drwxr-xr-x  2  500  500       0 Sep 10  2004 init
-rwxr-xr-x  1 root root   94420 Oct 14  2004 ld-2.3.2.so
lrwxrwxrwx  1 root root      11 Feb 17  2005 ld.so.1 -> ld-2.3.2.so?10
-rw-r--r--  1 root root    4832 Oct 14  2004 libBrokenLocale-2.3.2.so
lrwxrwxrwx  1 root root      24 Feb 17  2005 libBrokenLocale.so.1 ->
libBrokenLocale-2.3.2.so
-rw-r--r--  1 root root   14636 Oct 14  2004 libSegFault.so
lrwxrwxrwx  1 root root      15 Feb 17  2005 libacl.so.1 -> libacl.so.1.1.0?.3
-rw-r--r--  1 root root   31124 Feb  3  2004 libacl.so.1.1.0
-rw-r--r--  1 root root   11384 Oct 14  2004 libanl-2.3.2.so
lrwxrwxrwx  1 root root      15 Feb 17  2005 libanl.so.1 ->
libanl-2.3.2.so?.so?so
lrwxrwxrwx  1 root root      16 Feb 17  2005 libattr.so.1 -> libattr.so.1.1.0
-rw-r--r--  1 root root   17216 Apr 28  2004 libattr.so.1.1.0
lrwxrwxrwx  1 root root      15 Feb 17  2005 libblkid.so.1 -> libblkid.so.1.0?3?
-rw-r--r--  1 root root   31628 May  5  2004 libblkid.so.1.0
-rw-r--r--  1 root root 1298544 Oct 14  2004 libc-2.3.2.so
lrwxrwxrwx  1 root root      13 Feb 17  2005 libc.so.6 -> libc-2.3.2.so?
lrwxrwxrwx  1 root root      14 Feb 17  2005 libcap.so.1 -> libcap.so.1.10
-rw-r--r--  1 root root   19352 Apr 14  2004 libcap.so.1.10
lrwxrwxrwx  1 root root      17 Feb 17  2005 libcom_err.so.2 ->
libcom_err.so.2.1?
-rw-r--r--  1 root root   11824 May  5  2004 libcom_err.so.2.1
-rw-r--r--  1 root root   21104 Oct 14  2004 libcrypt-2.3.2.so
lrwxrwxrwx  1 root root      17 Feb 17  2005 libcrypt.so.1 ->
libcrypt-2.3.2.so?o?so
lrwxrwxrwx  1 root root      15 Feb 17  2005 libdb.so.2 ->
libdb1-2.2.5.so?.so?so
-rw-r--r--  1 root root  280284 Jun 10  2004 libdb.so.3
-rw-r--r--  1 root root   56140 Apr 12  2004 libdb1-2.2.5.so
lrwxrwxrwx  1 root root      15 Feb 17  2005 libdb1.so.2 ->
libdb1-2.2.5.so?.76?.so?
lrwxrwxrwx  1 root root      15 Feb 17  2005 libdb2.so.2 ->
libdb2.so.2.7.7?.76?.so?
-rw-r--r--  1 root root  312572 Jun 10  2004 libdb2.so.2.7.7
-rw-r--r--  1 root root   11252 Oct 14  2004 libdl-2.3.2.so
lrwxrwxrwx  1 root root      14 Feb 17  2005 libdl.so.2 -> libdl-2.3.2.so
lrwxrwxrwx  1 root root      13 Feb 17  2005 libe2p.so.2 -> libe2p.so.2.3?so
-rw-r--r--  1 root root   24944 May  5  2004 libe2p.so.2.3
lrwxrwxrwx  1 root root      16 Feb 17  2005 libext2fs.so.2 -> libext2fs.so.2.4
-rw-r--r--  1 root root  109108 May  5  2004 libext2fs.so.2.4
-rw-r--r--  1 root root   56732 Sep  8  2004 libgcc_s.so.1
lrwxrwxrwx  1 root root      17 Feb 17  2005 libhistory.so.4 ->
libhistory.so.4.3?
-rw-r--r--  1 root root   31468 Jun 13  2004 libhistory.so.4.3
-rw-r--r--  1 root root  478124 Oct 14  2004 libm-2.3.2.so
lrwxrwxrwx  1 root root      13 Feb 17  2005 libm.so.6 ->
libm-2.3.2.so?.25.0?2-2.10.0.so?libbz2.so.1.0.2??xZZZZZZZZZZZZZZ
-rw-r--r--  1 root root   18604 Oct 14  2004 libmemusage.so
lrwxrwxrwx  1 root root      17 Feb 17  2005 libncurses.so.5 ->
libncurses.so.5.4?
-rw-r--r--  1 root root  291516 May 27  2004 libncurses.so.5.4
-rw-r--r--  1 root root   78036 Oct 14  2004 libnsl-2.3.2.so
lrwxrwxrwx  1 root root      15 Feb 17  2005 libnsl.so.1 ->
libnsl-2.3.2.so?.so?2.so
-rw-r--r--  1 root root   32224 Oct 14  2004 libnss_compat-2.3.2.so
lrwxrwxrwx  1 root root      22 Feb 17  2005 libnss_compat.so.2 ->
libnss_compat-2.3.2.so
-rw-r--r--  1 root root   14488 Oct 14  2004 libnss_dns-2.3.2.so
lrwxrwxrwx  1 root root      19 Feb 17  2005 libnss_dns.so.2 ->
libnss_dns-2.3.2.so?so
-rw-r--r--  1 root root   43060 Oct 14  2004 libnss_files-2.3.2.so
lrwxrwxrwx  1 root root      21 Feb 17  2005 libnss_files.so.2 ->
libnss_files-2.3.2.so?2.10.0.so?libbz2.so.1.0.2??xZZZZZZZZZZZZZZ
-rw-r--r--  1 root root   16852 Oct 14  2004 libnss_hesiod-2.3.2.so
lrwxrwxrwx  1 root root      22 Feb 17  2005 libnss_hesiod.so.2 ->
libnss_hesiod-2.3.2.so
-rw-r--r--  1 root root   38984 Oct 14  2004 libnss_nis-2.3.2.so
lrwxrwxrwx  1 root root      19 Feb 17  2005 libnss_nis.so.2 ->
libnss_nis-2.3.2.so?2.so
-rw-r--r--  1 root root   47452 Oct 14  2004 libnss_nisplus-2.3.2.so
lrwxrwxrwx  1 root root      23 Feb 17  2005 libnss_nisplus.so.2 ->
libnss_nisplus-2.3.2.so?
lrwxrwxrwx  1 root root      14 Feb 17  2005 libpam.so.0 -> libpam.so.0.76
-rw-r--r--  1 root root   37772 Jul  2  2004 libpam.so.0.76
lrwxrwxrwx  1 root root      19 Feb 17  2005 libpam_misc.so.0 ->
libpam_misc.so.0.76?.so?
-rw-r--r--  1 root root   13996 Jul  2  2004 libpam_misc.so.0.76
lrwxrwxrwx  1 root root      15 Feb 17  2005 libpamc.so.0 -> libpamc.so.0.76?
-rw-r--r--  1 root root   15232 Jul  2  2004 libpamc.so.0.76
-rw-r--r--  1 root root   10292 Oct 14  2004 libpcprofile.so
lrwxrwxrwx  1 root root      16 Feb 17  2005 libpopt.so.0 -> libpopt.so.0.0.0
-rw-r--r--  1 root root   34736 Aug 29  2004 libpopt.so.0.0.0
-rw-r--r--  1 root root   51972 Apr 13  2004 libproc.so.3.2.1
-rw-r--r--  1 root root   85254 Oct 14  2004 libpthread-0.10.so
lrwxrwxrwx  1 root root      18 Feb 17  2005 libpthread.so.0 ->
libpthread-0.10.so
lrwxrwxrwx  1 root root      18 Feb 17  2005 libreadline.so.4 ->
libreadline.so.4.3
-rw-r--r--  1 root root  202856 Jun 13  2004 libreadline.so.4.3
-rw-r--r--  1 root root   64124 Oct 14  2004 libresolv-2.3.2.so
lrwxrwxrwx  1 root root      18 Feb 17  2005 libresolv.so.2 ->
libresolv-2.3.2.so
-rw-r--r--  1 root root   28460 Oct 14  2004 librt-2.3.2.so
lrwxrwxrwx  1 root root      14 Feb 17  2005 librt.so.1 -> librt-2.3.2.so
lrwxrwxrwx  1 root root      17 Feb 17  2005 libslang.so.1 -> libslang.so.1.4.9?
lrwxrwxrwx  1 root root      22 Feb 17  2005 libslang.so.1-UTF8 ->
libslang.so.1-UTF8.4.9
-rw-r--r--  1 root root  436276 Sep 22  2004 libslang.so.1-UTF8.4.9
-rw-r--r--  1 root root  436024 Sep 22  2004 libslang.so.1.4.9
lrwxrwxrwx  1 root root      12 Feb 17  2005 libss.so.2 -> libss.so.2.0
-rw-r--r--  1 root root   24552 May  5  2004 libss.so.2.0
-rw-r--r--  1 root root   19524 Oct 14  2004 libthread_db-1.0.so
lrwxrwxrwx  1 root root      19 Feb 17  2005 libthread_db.so.1 ->
libthread_db-1.0.so?so
-rw-r--r--  1 root root    8660 Oct 14  2004 libutil-2.3.2.so
lrwxrwxrwx  1 root root      16 Feb 17  2005 libutil.so.1 -> libutil-2.3.2.so
lrwxrwxrwx  1 root root      14 Feb 17  2005 libuuid.so.1 -> libuuid.so.1.2
-rw-r--r--  1 root root   16032 May  5  2004 libuuid.so.1.2
lrwxrwxrwx  1 root root      16 Feb 17  2005 libwrap.so.0 -> libwrap.so.0.7.6
-rw-r--r--  1 root root   36120 Aug 29  2004 libwrap.so.0.7.6
drwxr-xr-x  3  509  503       0 Feb 17  2005 modules
drwxr-xr-x  2  500  500       0 Jul  2  2004 security
:/flash/lib#



From killekulla at rdrz.de  Fri Feb 18 01:54:12 2005
From: killekulla at rdrz.de (Raphael Zimmerer)
Date: Fri, 18 Feb 2005 07:54:12 +0100
Subject: Software Requirement && DiskOnChip
In-Reply-To: <200502171502.j1HF2OtT044879@forof.hylink.am>
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
Message-ID: <20050218065412.GA10703@rdrz.de>

On Thu, Feb 17, 2005 at 07:02:24PM +0400, Ara Avanesyan wrote:
>   Also, where can I find the descriptions of the registers
> DoC_Mplus_FlashControl through DoC_Mplus_WritePipeTerm
> defined in doc2000.h? The data-sheet for MPlus DOC device does not contain
> this info.

On what DiskOnChip are you working? At the moment I'am trying to
extend diskonchip.c to support the Millennium Plus 32MB. If you are
doing the same, please let me know.

- Raphael



From dedekind at infradead.org  Fri Feb 18 03:05:27 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 18 Feb 2005 11:05:27 +0300
Subject: symlink corruption in jffs2
In-Reply-To: <52249cdc0502171225706e3cf8@mail.gmail.com>
References: <52249cdc0502171225706e3cf8@mail.gmail.com>
Message-ID: <1108713927.13420.14.camel@sauron.oktetlabs.ru>

On Thu, 2005-02-17 at 15:25 -0500, Joe Barnett wrote:
> I am trying to put a jffs2 filesystem down on a G5 ppc64 system. I can
> build the filesystem fine, and get it into flash, mount it ect. The
> problem I am finding is that a large number of the symbolic links are
> corrupt. The file pointed to has garbage appended to the name (see
> below). If I try to create a new symlink, it also gets corrupted. I
> have turned on JFFS2 debug to level 3 and am still unable to locate
> the source of the issue...  I am using the following options when I
> run mkfs.jffs2:
I wonder did anybody successfully use JFFS2 on 64-bit machine?

> 
> mkfs.jffs2 -o myflashfs.img -d myroot -e 20000
Er, do you mean your Flash block is exactly 20000 bytes?

> 
> I am using Common Intel StrataFlash, which I have confirmed that
> driver is functional
One obvious thing I may suggest to exclude driver problems is to use
mtdram device. It emulates NOR flash in RAM. (mtd/drivers/mtdram.c). If
your problem won't go when you've utilized mtdram, the problem is most
probably in JFFS2.

Another good experiment is just to format your flash (flash_eraseall -j)
and mount it (empty). Then to try to play with symlinks there (touch
file; ln -s link file; and like). This will exclude the possibility of
mistakes when you create and flash your image.

> , as I can read and write large file to and from
> the flash fine, so it isn't in the driver.  Has anyone seen this issue
> before or does anyone have an idea of what may be causing this?  I did
> see Any help would be greatly appreciated.
Another things I may suggest are:

1. Try my recent patch: http://lists.infradead.org/pipermail/linux-
mtd/2005-February/011936.html

2. If you post next time, please provide the JFFS2 level 1 debug output.

3. Just in case, provide cat /proc/mtd output.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From araav at hylink.am  Fri Feb 18 05:17:43 2005
From: araav at hylink.am (Ara Avanesyan)
Date: Fri, 18 Feb 2005 14:17:43 +0400
Subject: Software Requirement && DiskOnChip
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
	<1108657458.19262.671.camel@hades.cambridge.redhat.com>
Message-ID: <005401c515a3$166ef470$1000000a@araavanesyan>

David,

Thanks. I'll contact M-System for the document.
Bah! This somewhat violates my [very basic]
understanding of open source community. It's 
something like "open source and close source of 
source". Couldn't the driver writer (you:)) put the
document to the source tree documentation part?

__
Thanks,
Ara

----- Original Message ----- 
From: "David Woodhouse" <dwmw2 at infradead.org>
To: "Ara Avanesyan" <araav at hylink.am>
Cc: <linux-mtd at lists.infradead.org>
Sent: Thursday, February 17, 2005 8:24 PM
Subject: Re: Software Requirement && DiskOnChip


> On Thu, 2005-02-17 at 19:02 +0400, Ara Avanesyan wrote:
> >   Everywhere in DiskOnChip files there are referneces to a magic
> > "Software Requirement 11.x.y".
> > Can someone please tell me where can I locate one?
> > 
> >   Also, where can I find the descriptions of the registers
> > DoC_Mplus_FlashControl through DoC_Mplus_WritePipeTerm
> > defined in doc2000.h? The data-sheet for MPlus DOC device does not
> > contain this info.
> 
> Unfortunately I don't think these are publicly available. Although I
> have a vague recollection of being corrected last time I said that.
> 
> -- 
> dwmw2
> 
>



From araav at hylink.am  Fri Feb 18 05:22:24 2005
From: araav at hylink.am (Ara Avanesyan)
Date: Fri, 18 Feb 2005 14:22:24 +0400
Subject: Software Requirement && DiskOnChip
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
	<20050218065412.GA10703@rdrz.de>
Message-ID: <005a01c515a3$bd539070$1000000a@araavanesyan>

----- Original Message ----- 
From: "Raphael Zimmerer" <killekulla at rdrz.de>
To: "Ara Avanesyan" <araav at hylink.am>
Cc: <linux-mtd at lists.infradead.org>
Sent: Friday, February 18, 2005 10:54 AM
Subject: Re: Software Requirement && DiskOnChip


> On Thu, Feb 17, 2005 at 07:02:24PM +0400, Ara Avanesyan wrote:
> >   Also, where can I find the descriptions of the registers
> > DoC_Mplus_FlashControl through DoC_Mplus_WritePipeTerm
> > defined in doc2000.h? The data-sheet for MPlus DOC device does not
contain
> > this info.
>
> On what DiskOnChip are you working? At the moment I'am trying to
> extend diskonchip.c to support the Millennium Plus 32MB. If you are
> doing the same, please let me know.
>
> - Raphael
>
Actually I'm going to make it work for DOC G3.




From estelle.hammache at st.com  Fri Feb 18 09:06:32 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Fri, 18 Feb 2005 15:06:32 +0100
Subject: symlink corruption in jffs2
References: <52249cdc0502171225706e3cf8@mail.gmail.com>
Message-ID: <4215F668.F570E28B@st.com>

Notice how even-length names are ok and odd-length names are KO.
There was a thread about a similar problem, with a suggested
approach for finding the bug.
http://lists.infradead.org/pipermail/linux-mtd/2004-May/009735.html

> lrwxrwxrwx  1 root root      11 Feb 17  2005 ld.so.1 -> ld-2.3.2.so?10
> lrwxrwxrwx  1 root root      24 Feb 17  2005 libBrokenLocale.so.1 ->
> libBrokenLocale-2.3.2.so
> lrwxrwxrwx  1 root root      15 Feb 17  2005 libacl.so.1 -> libacl.so.1.1.0?.3
> lrwxrwxrwx  1 root root      15 Feb 17  2005 libanl.so.1 ->
> libanl-2.3.2.so?.so?so
> lrwxrwxrwx  1 root root      16 Feb 17  2005 libattr.so.1 -> libattr.so.1.1.0
> lrwxrwxrwx  1 root root      15 Feb 17  2005 libblkid.so.1 -> libblkid.so.1.0?3?

bye
Estelle



From jdub at us.ibm.com  Fri Feb 18 09:07:50 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Fri, 18 Feb 2005 08:07:50 -0600
Subject: Software Requirement && DiskOnChip
In-Reply-To: <005401c515a3$166ef470$1000000a@araavanesyan>
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
	<1108657458.19262.671.camel@hades.cambridge.redhat.com>
	<005401c515a3$166ef470$1000000a@araavanesyan>
Message-ID: <1108735670.7821.3.camel@windu.rchland.ibm.com>

On Fri, 2005-02-18 at 14:17 +0400, Ara Avanesyan wrote:
> David,
> 
> Thanks. I'll contact M-System for the document.
> Bah! This somewhat violates my [very basic]
> understanding of open source community. It's 
> something like "open source and close source of 
> source". Couldn't the driver writer (you:)) put the
> document to the source tree documentation part?

I don't think so.  The source code is definitely open source.  The
hardware documentation is whatever the vendor decides it should be.  In
this case, M-Systems decided that it should not be public, IIRC.

josh




From araav at hylink.am  Fri Feb 18 09:41:29 2005
From: araav at hylink.am (Ara Avanesyan)
Date: Fri, 18 Feb 2005 18:41:29 +0400
Subject: Software Requirement && DiskOnChip
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
	<1108657458.19262.671.camel@hades.cambridge.redhat.com>
	<005401c515a3$166ef470$1000000a@araavanesyan>
	<1108735670.7821.3.camel@windu.rchland.ibm.com>
Message-ID: <006c01c515c7$ef8c6d40$1000000a@araavanesyan>

ok,

My question is from theory only:)
Can't then the driver writer copy-paste the documentation to source files as
comment? really...
And what could be the reason to not sharing the hardware documentation to
the community???

__
Thanks,
Ara


----- Original Message ----- 
From: "Josh Boyer" <jdub at us.ibm.com>
To: "Ara Avanesyan" <araav at hylink.am>
Cc: "David Woodhouse" <dwmw2 at infradead.org>; <linux-mtd at lists.infradead.org>
Sent: Friday, February 18, 2005 6:07 PM
Subject: Re: Software Requirement && DiskOnChip


> On Fri, 2005-02-18 at 14:17 +0400, Ara Avanesyan wrote:
> > David,
> >
> > Thanks. I'll contact M-System for the document.
> > Bah! This somewhat violates my [very basic]
> > understanding of open source community. It's
> > something like "open source and close source of
> > source". Couldn't the driver writer (you:)) put the
> > document to the source tree documentation part?
>
> I don't think so.  The source code is definitely open source.  The
> hardware documentation is whatever the vendor decides it should be.  In
> this case, M-Systems decided that it should not be public, IIRC.
>
> josh
>
>




From joern at wohnheim.fh-wedel.de  Fri Feb 18 09:45:53 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 18 Feb 2005 15:45:53 +0100
Subject: Software Requirement && DiskOnChip
In-Reply-To: <006c01c515c7$ef8c6d40$1000000a@araavanesyan>
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
	<1108657458.19262.671.camel@hades.cambridge.redhat.com>
	<005401c515a3$166ef470$1000000a@araavanesyan>
	<1108735670.7821.3.camel@windu.rchland.ibm.com>
	<006c01c515c7$ef8c6d40$1000000a@araavanesyan>
Message-ID: <20050218144553.GB5307@wohnheim.fh-wedel.de>

On Fri, 18 February 2005 18:41:29 +0400, Ara Avanesyan wrote:
> 
> My question is from theory only:)
> Can't then the driver writer copy-paste the documentation to source files as
> comment? really...
> And what could be the reason to not sharing the hardware documentation to
> the community???

The legal papers signed before receiving the documentation.  In some
unfortunate cases, people get documentation und "You may not show
anyone!" style licenses.  With that, the alternatives are either
drivers without hardware documentation or no drivers at all.

J?rn

-- 
Fantasy is more important than knowledge. Knowledge is limited,
while fantasy embraces the whole world.
-- Albert Einstein



From jdub at us.ibm.com  Fri Feb 18 09:54:59 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Fri, 18 Feb 2005 08:54:59 -0600
Subject: Software Requirement && DiskOnChip
In-Reply-To: <006c01c515c7$ef8c6d40$1000000a@araavanesyan>
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
	<1108657458.19262.671.camel@hades.cambridge.redhat.com>
	<005401c515a3$166ef470$1000000a@araavanesyan>
	<1108735670.7821.3.camel@windu.rchland.ibm.com>
	<006c01c515c7$ef8c6d40$1000000a@araavanesyan>
Message-ID: <1108738499.7821.11.camel@windu.rchland.ibm.com>

On Fri, 2005-02-18 at 18:41 +0400, Ara Avanesyan wrote:
> ok,
> 
> My question is from theory only:)
> Can't then the driver writer copy-paste the documentation to source files as
> comment? really...

Not if there is an agreement with the documentation owners to not
release the documentation.  That would be similar to taking a
programming book and pasting the contents into a program you wrote using
information in the book.  It's known as plagiarism.

> And what could be the reason to not sharing the hardware documentation to
> the community???

I have no idea.  You'd have to ask M-Systems I guess.

(btw, top-posting is frowned upon on this list.)

josh




From araav at hylink.am  Fri Feb 18 10:09:29 2005
From: araav at hylink.am (Ara Avanesyan)
Date: Fri, 18 Feb 2005 19:09:29 +0400
Subject: Software Requirement && DiskOnChip
References: <200502171502.j1HF2OtT044879@forof.hylink.am>
	<1108657458.19262.671.camel@hades.cambridge.redhat.com>
	<005401c515a3$166ef470$1000000a@araavanesyan>
	<1108735670.7821.3.camel@windu.rchland.ibm.com>
	<006c01c515c7$ef8c6d40$1000000a@araavanesyan>
	<1108738499.7821.11.camel@windu.rchland.ibm.com>
Message-ID: <007601c515cb$d8dc2e60$1000000a@araavanesyan>

> On Fri, 2005-02-18 at 18:41 +0400, Ara Avanesyan wrote:
> > ok,
> >
> > My question is from theory only:)
> > Can't then the driver writer copy-paste the documentation to source
files as
> > comment? really...
>
> Not if there is an agreement with the documentation owners to not
> release the documentation.  That would be similar to taking a
> programming book and pasting the contents into a program you wrote using
> information in the book.  It's known as plagiarism.
>
> > And what could be the reason to not sharing the hardware documentation
to
> > the community???
>
> I have no idea.  You'd have to ask M-Systems I guess.
>
Josh,

Thanks for clarifications.

> (btw, top-posting is frowned upon on this list.)
Sorry about that. I'll keep this in mind for the future.

__
Thanks,
Ara




From lists at ku-gbr.de  Fri Feb 18 10:42:16 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Fri, 18 Feb 2005 16:42:16 +0100
Subject: freeze when mounting fs
Message-ID: <20050218154216.GA5926@synertronixx3>

I have also 2.6.10-rc2 kernel here with nodemgmnt.c from actual cvs. I
have a weird constellation here where adding file to /home makes mount
freeze when attepting to mount, regardeless if extra partition or root
partition. What the fuck can that be?

I go it mounted ro once though:

root at scb9328 ~ # mount -t jffs2 -o,ro /dev/mtdblock4 /mnt
Inode #170 was a directory with children - removing those too...
root at scb9328 ~ # Jan  1 02:00:55 scb9328 kern.notice klogd: Inode #170
was a directory with children - removing those too...

I did

root at scb9328 ~ # echo 9 >/proc/sys/kernel/printk
root at scb9328 ~ # 
root at scb9328 ~ # klogd           
root at scb9328 ~ # syslogd
root at scb9328 ~ # tail -f /var/log/messages &

But got no info.

:-( !!!!

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From lists at ku-gbr.de  Fri Feb 18 10:48:58 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Fri, 18 Feb 2005 16:48:58 +0100
Subject: freeze when mounting fs
In-Reply-To: <20050218154216.GA5926@synertronixx3>
References: <20050218154216.GA5926@synertronixx3>
Message-ID: <20050218154853.GB5926@synertronixx3>

Am 2005-02-18 16:42 +0100 schrieb Konstantin Kletschke:

I did

CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=2
# CONFIG_JFFS2_FS_NAND is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y

And when mounting functional rootfs it speaks a lot, but:

root at scb9328 ~ # mount -t jffs2 /dev/mtdblock4 /mnt

[ ... silence ... ]

Rootfs is at http://ludenkalle.de/mtd/52

created with 

mkfs.jffs2 -q --eraseblock=128KiB -o /tftpboot/52 -D
/home/konsti/svn/ptxdist-0.5.2-trunk/src/device_table.txt
--root=/home/konsti/svn/ptxdist-0.5.2-trunk/root

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From dedekind at infradead.org  Fri Feb 18 10:48:52 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 18 Feb 2005 18:48:52 +0300
Subject: freeze when mounting fs
In-Reply-To: <20050218154216.GA5926@synertronixx3>
References: <20050218154216.GA5926@synertronixx3>
Message-ID: <1108741733.13420.20.camel@sauron.oktetlabs.ru>

On Fri, 2005-02-18 at 16:42 +0100, Konstantin Kletschke wrote:
> But got no info.
Because you just mesages. You need to use synchronous output to capture
messages. 

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From lists at ku-gbr.de  Fri Feb 18 11:01:09 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Fri, 18 Feb 2005 17:01:09 +0100
Subject: freeze when mounting fs
In-Reply-To: <1108741733.13420.20.camel@sauron.oktetlabs.ru>
References: <20050218154216.GA5926@synertronixx3>
	<1108741733.13420.20.camel@sauron.oktetlabs.ru>
Message-ID: <20050218160108.GC5926@synertronixx3>

Am 2005-02-18 18:48 +0300 schrieb Artem B. Bityuckiy:
> On Fri, 2005-02-18 at 16:42 +0100, Konstantin Kletschke wrote:
> > But got no info.
> Because you just mesages. You need to use synchronous output to capture
> messages. 

You mean synchronous logging of syslogd/klogd?
Busybox's can't.
It seems adding some scripts to /home into the rootfs breaks things.
I removed /home before mkfs.jffs2, left the other stuff like it was,
voily, mounts, runs, works with no error.

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From tglx at linutronix.de  Fri Feb 18 11:09:18 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 18 Feb 2005 17:09:18 +0100
Subject: freeze when mounting fs
In-Reply-To: <20050218154853.GB5926@synertronixx3>
References: <20050218154216.GA5926@synertronixx3>
	<20050218154853.GB5926@synertronixx3>
Message-ID: <1108742958.24721.295.camel@tglx.tec.linutronix.de>

On Fri, 2005-02-18 at 16:48 +0100, Konstantin Kletschke wrote:

> CONFIG_JFFS2_FS_DEBUG=2

Please use level 1

> And when mounting functional rootfs it speaks a lot, but:

What happens when you mount the non-functional one ? Can you please
provide logs via serial console. klogd does not work for logging of that
stuff.

> Rootfs is at http://ludenkalle.de/mtd/52

The image is clean. There is no problem to see.

It would be interesting to have a binary image after you programmed it
to FLASH. cat /dev/mtdX >flash.img

tglx





From tglx at linutronix.de  Fri Feb 18 11:12:26 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 18 Feb 2005 17:12:26 +0100
Subject: freeze when mounting fs
In-Reply-To: <20050218160108.GC5926@synertronixx3>
References: <20050218154216.GA5926@synertronixx3>
	<1108741733.13420.20.camel@sauron.oktetlabs.ru>
	<20050218160108.GC5926@synertronixx3>
Message-ID: <1108743146.24721.297.camel@tglx.tec.linutronix.de>

On Fri, 2005-02-18 at 17:01 +0100, Konstantin Kletschke wrote:
> Am 2005-02-18 18:48 +0300 schrieb Artem B. Bityuckiy:
> > On Fri, 2005-02-18 at 16:42 +0100, Konstantin Kletschke wrote:
> > > But got no info.
> > Because you just mesages. You need to use synchronous output to capture
> > messages. 
> 
> You mean synchronous logging of syslogd/klogd?

No, serial log without syslogd/klogd 

> Busybox's can't.
> It seems adding some scripts to /home into the rootfs breaks things.
> I removed /home before mkfs.jffs2, left the other stuff like it was,
> voily, mounts, runs, works with no error.

Hmm, can you provide such a broken image and the serial log from mount ?

tglx





From dedekind at infradead.org  Fri Feb 18 11:15:34 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 18 Feb 2005 19:15:34 +0300
Subject: freeze when mounting fs
In-Reply-To: <20050218160108.GC5926@synertronixx3>
References: <20050218154216.GA5926@synertronixx3>
	<1108741733.13420.20.camel@sauron.oktetlabs.ru>
	<20050218160108.GC5926@synertronixx3>
Message-ID: <1108743334.13420.25.camel@sauron.oktetlabs.ru>

On Fri, 2005-02-18 at 17:01 +0100, Konstantin Kletschke wrote:
> You mean synchronous logging of syslogd/klogd?
> Busybox's can't.
> It seems adding some scripts to /home into the rootfs breaks things.
> I removed /home before mkfs.jffs2, left the other stuff like it was,
> voily, mounts, runs, works with no error.
> 
> Konsti

I mean via serial line. It is synchronous. In your case it is not,
meaning that first output goes to the circular buffer, then user space
daemons fetch it etc etc. Your system may die before the messages have
been conveyed to syslogd.  





From lists at ku-gbr.de  Fri Feb 18 11:36:37 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Fri, 18 Feb 2005 17:36:37 +0100
Subject: freeze when mounting fs
In-Reply-To: <1108742958.24721.295.camel@tglx.tec.linutronix.de>
References: <20050218154216.GA5926@synertronixx3>
	<20050218154853.GB5926@synertronixx3>
	<1108742958.24721.295.camel@tglx.tec.linutronix.de>
Message-ID: <20050218163636.GD5926@synertronixx3>

Am 2005-02-18 17:09 +0100 schrieb Thomas Gleixner:
> On Fri, 2005-02-18 at 16:48 +0100, Konstantin Kletschke wrote:
> 
> > CONFIG_JFFS2_FS_DEBUG=2
> 
> Please use level 1
> 
> > And when mounting functional rootfs it speaks a lot, but:
> 
> What happens when you mount the non-functional one ? Can you please

Nothing.

> provide logs via serial console. klogd does not work for logging of that
> stuff.

Even with level 3 _nothing_ happens.

> > Rootfs is at http://ludenkalle.de/mtd/52
> 
> The image is clean. There is no problem to see.
> 
> It would be interesting to have a binary image after you programmed it
> to FLASH. cat /dev/mtdX >flash.img

I will try what I can do or reproduce it later, I am sure my device
table triggered a bug or some sort of that:

I removed 3 lines mungling up some access permissions of subdirectories
under /home and now the image gets mounted.
I am fighting with svn ATM to get the actual change...

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From steve.wahl at qlogic.com  Fri Feb 18 11:48:23 2005
From: steve.wahl at qlogic.com (Steve Wahl)
Date: Fri, 18 Feb 2005 10:48:23 -0600
Subject: jedec_probe.c bug: AMD AM29LV800 in byte mode
Message-ID: <20050218164823.GE2119@qlogic.com>

Hello, list.

I'm newly returning to this list; I used to be on it, went through a
change in employment, and now, surprise, I'm doing some related work
again.

I emailed David (dwmw2) directly to ask how I should aproach this, but
he either didn't get it or correctly blew me off :-).  I'm assuming
the former, but hold nothing against him if it's the latter.

I did see one other post in the archives that refered to the *400, not
*800 version of this chip, but I didn't see any real solution.

The meat of the problem is: when this chip is in byte mode, the id
should be read from location 2, and when the chip is in word mode, the
id should be read from location 1.  The jedec_read_id() code does the
exact opposite.

I'd be more than willing to develop and offer a patch, but I don't
have a clue as to the range of chips this code applies to, and how to
know which ones need to change.  The best I can suggest at the moment
is reading both locations and indicating in the jedec_table[] which
location should be compared with. (Does anybody think that's the right
way to go?  I'll see if I can work such a patch up if so...)

I have a current patch which just changes the location where ID is
read from.  It makes this chip work, but of course breaks all the
others.  

Background:

    System is based on a PPC chip, is currently running Linux 2.4 with
    the old amd_flash.c driver (with a similar patch).  I'm porting
    Linux 2.6 to this system.  Previous 2.4 port person just did the
    patch on his own for this company and as far as I can tell didn't
    inform the world that a change had to be made.  I'd rather get the
    mainline MTD code working so that (A) future ports (Linux 2.8?)
    won't run into the problem, and (B) I have a set of code that will
    still work when my hardware guys decide to change to a flash chip
    that my current kludge breaks.

    If anyone cares, we're not running a filesystem on this chip, just
    need to re-write the boot code with it.  We have another chip
    that's NAND, on which we're using YAFFS.

Thanks for listening,

--> Steve Wahl, Qlogic Corporation.




From johnfkelly at earthlink.net  Fri Feb 18 15:20:40 2005
From: johnfkelly at earthlink.net (John Kelly)
Date: Fri, 18 Feb 2005 13:20:40 -0700 (GMT-07:00)
Subject: DoC-2000: NAND_CMD_READID hangs on stock 2.6.10 kernel
Message-ID: <18307332.1108758040913.JavaMail.root@bigbird.psp.pas.earthlink.net>

I'm working on getting a Technologics TS-5400 board runnig Linux-2.6 to see a 32MB DoC.

When inserting the diskonchip.ko driver from a vanilla 2.6.10 kernel, I get into an infinite loop in nand_command with command=0x90 (READID).  The loop is at the bottom of the function:

        /* Apply this short delay always to ensure that we do wait tWB in
         * any case on any machine. */
        ndelay (100);
        /* wait until command is processed */
        while (!this->dev_ready(mtd));

If I use a counter to break out of the loop after 40 tries, everything works--only READID seems to need this.

Is there some other way this should be handled?



From tglx at linutronix.de  Fri Feb 18 15:32:01 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 18 Feb 2005 21:32:01 +0100
Subject: DoC-2000: NAND_CMD_READID hangs on stock 2.6.10 kernel
In-Reply-To: <18307332.1108758040913.JavaMail.root@bigbird.psp.pas.earthlink.net>
References: <18307332.1108758040913.JavaMail.root@bigbird.psp.pas.earthlink.net>
Message-ID: <1108758722.24721.305.camel@tglx.tec.linutronix.de>

On Fri, 2005-02-18 at 13:20 -0700, John Kelly wrote:
> I'm working on getting a Technologics TS-5400 board runnig 
> Linux-2.6 to see a 32MB DoC.
> 
> When inserting the diskonchip.ko driver from a vanilla 
> 2.6.10 kernel, I get into an infinite loop in nand_command 
> with command=0x90 (READID).  The loop is at the bottom of the function:
> 
>         /* Apply this short delay always to ensure that we do wait tWB in
>          * any case on any machine. */
>         ndelay (100);
>         /* wait until command is processed */
>         while (!this->dev_ready(mtd));
> 
> If I use a counter to break out of the loop after 40 tries,
>  everything works--only READID seems to need this.

It's not READID, there is something wrong with the number of chips to
scan for. I have encountered the problem here too. I will post again
when I have fixed it.

tglx





From balkohen at gmail.com  Sat Feb 19 15:00:14 2005
From: balkohen at gmail.com (Lior Balkohen)
Date: Sat, 19 Feb 2005 21:00:14 +0100
Subject: JFFS3 & performance checksum test results.
Message-ID: <196b7d31050219120065170409@mail.gmail.com>

I don't know where/whom to provide to results, so I send the results
for my IBM embedded powerpc 405 based set top box to the linux-mtd
list. I hope, I'm right here.
/hdd > uname -a
Linux dreambox 2.6.9 #1 Wed Feb 2 18:18:47 CET 2005 ppc unknown

/hdd > cat /proc/cpuinfo
processor       : 0
cpu             : STB04xxx
clock           : 252MHz
revision        : 9.82 (pvr 4181 0952)
bogomips        : 250.88
machine         : Dream Multimedia TV Dreambox
plb bus clock   : 63MHz

/hdd > cat /proc/meminfo
MemTotal:        30048 kB
MemFree:          2440 kB
Buffers:          3860 kB
Cached:          10068 kB
SwapCached:          0 kB
Active:          11728 kB
Inactive:         9840 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        30048 kB
LowFree:          2440 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:          12260 kB
Slab:             2628 kB
Committed_AS:    86572 kB
PageTables:        240 kB
VmallocTotal:   475136 kB
VmallocUsed:     40976 kB
VmallocChunk:   432104 kB

/hdd > cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   sockfs
nodev   usbfs
nodev   usbdevfs
nodev   futexfs
nodev   tmpfs
nodev   pipefs
nodev   eventpollfs
nodev   devpts
        ext3
        cramfs
        squashfs
nodev   ramfs
        vfat
        iso9660
nodev   devfs
nodev   nfs
nodev   jffs2
nodev   rpc_pipefs

/hdd > cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00600000 00020000 "DreamBOX cramfs+squashfs"
mtd1: 001c0000 00020000 "DreamBOX jffs2"
mtd2: 00040000 00020000 "DreamBOX OpenBIOS"
mtd3: 007c0000 00020000 "DreamBOX (w/o bootloader)"
mtd4: 00800000 00020000 "DreamBOX (w/ bootloader)"
mtd5: 004e0000 00020000 "DreamBOX SquashedFS"
mtd6: 00120000 00020000 "DreamBOX Cramfs"

results:
[crctst] (get_cycles) Data pass both forward, 32 bytes: delta 168, ts1
1900967224, ts2 1900967392
[crctst] (get_cycles) Data pass both backward, 32 bytes: delta 133,
ts1 1902292182, ts2 1902292315
[crctst] (get_cycles) Data pass backward/forward, 32 bytes: delta 151,
ts1 1903616602, ts2 1903616753
[crctst] (get_cycles) Data pass forward/backward, 32 bytes: delta 141,
ts1 1904941004, ts2 1904941145
[crctst] (get_cycles) Data pass both forward, 4096 bytes: delta 12260,
ts1 1906265395, ts2 1906277655
[crctst] (get_cycles) Data pass both backward, 4096 bytes: delta 9936,
ts1 1907601961, ts2 1907611897
[crctst] (get_cycles) Data pass backward/forward, 4096 bytes: delta
11263, ts1 1908936265, ts2 1908947528
[crctst] (get_cycles) Data pass forward/backward, 4096 bytes: delta
10911, ts1 1910271873, ts2 1910282784
[crctst] (get_cycles) Data pass both forward, 32768 bytes: delta
104016, ts1 1911607110, ts2 1911711126
[crctst] (get_cycles) Data pass both backward, 32768 bytes: delta
87914, ts1 1913035490, ts2 1913123404
[crctst] (get_cycles) Data pass backward/forward, 32768 bytes: delta
92824, ts1 1914447816, ts2 1914540640
[crctst] (get_cycles) Data pass forward/backward, 32768 bytes: delta
91547, ts1 1915865013, ts2 1915956560
[crctst] (get_cycles) Data pass both forward, 65536 bytes: delta
208032, ts1 1917280917, ts2 1917488949
[crctst] (get_cycles) Data pass both backward, 65536 bytes: delta
175761, ts1 1918813312, ts2 1918989073
[crctst] (get_cycles) Data pass backward/forward, 65536 bytes: delta
188753, ts1 1920313475, ts2 1920502228
[crctst] (get_cycles) Data pass forward/backward, 65536 bytes: delta
187477, ts1 1921826629, ts2 1922014106
[crctst] (get_cycles) Data pass both forward, 131072 bytes: delta
416040, ts1 1923338509, ts2 1923754549
[crctst] (get_cycles) Data pass both backward, 131072 bytes: delta
351457, ts1 1925078969, ts2 1925430426
[crctst] (get_cycles) Data pass backward/forward, 131072 bytes: delta
380570, ts1 1926754905, ts2 1927135475
[crctst] (get_cycles) Data pass forward/backward, 131072 bytes: delta
379361, ts1 1928459900, ts2 1928839261
[crctst] (get_cycles) adler32, 32 bytes: delta 22, ts1 1928841073, ts2
1928841095
[crctst] (get_cycles) adler32, 4096 bytes: delta 1439, ts1 1929185219,
ts2 1929186658
[crctst] (get_cycles) adler32, 32768 bytes: delta 17190, ts1
1929213252, ts2 1929230442
[crctst] (get_cycles) adler32, 65536 bytes: delta 34363, ts1
1929269598, ts2 1929303961
[crctst] (get_cycles) adler32, 131072 bytes: delta 68704, ts1
1929385001, ts2 1929453705
[crctst] (get_cycles) adler32r, 32 bytes: delta 22, ts1 1929473296,
ts2 1929473318
[crctst] (get_cycles) adler32r, 4096 bytes: delta 1377, ts1
1929477555, ts2 1929478932
[crctst] (get_cycles) adler32r, 32768 bytes: delta 18489, ts1
1929506634, ts2 1929525123
[crctst] (get_cycles) adler32r, 65536 bytes: delta 36961, ts1
1929564783, ts2 1929601744
[crctst] (get_cycles) adler32r, 131072 bytes: delta 73900, ts1
1929686740, ts2 1929760640
[crctst] (get_cycles) engel32, 32 bytes: delta 25, ts1 1929770941, ts2
1929770966
[crctst] (get_cycles) engel32, 4096 bytes: delta 1761, ts1 1929779631,
ts2 1929781392
[crctst] (get_cycles) engel32, 32768 bytes: delta 19769, ts1
1929803626, ts2 1929823395
[crctst] (get_cycles) engel32, 65536 bytes: delta 39518, ts1
1929870497, ts2 1929910015
[crctst] (get_cycles) engel32, 131072 bytes: delta 79013, ts1
1929997549, ts2 1930076562
[crctst] (get_cycles) engel32r, 32 bytes: delta 26, ts1 1930089784,
ts2 1930089810
[crctst] (get_cycles) engel32r, 4096 bytes: delta 1871, ts1
1930093462, ts2 1930095333
[crctst] (get_cycles) engel32r, 32768 bytes: delta 14927, ts1
1930111477, ts2 1930126404
[crctst] (get_cycles) engel32r, 65536 bytes: delta 29853, ts1
1930163350, ts2 1930193203
[crctst] (get_cycles) engel32r, 131072 bytes: delta 59696, ts1
1930260093, ts2 1930319789
[crctst] (get_cycles) 16-bit CRC CCITT, 32 bytes: delta 42, ts1
1930330225, ts2 1930330267
[crctst] (get_cycles) 16-bit CRC CCITT, 4096 bytes: delta 4390, ts1
1930337184, ts2 1930341574
[crctst] (get_cycles) 16-bit CRC CCITT, 32768 bytes: delta 40829, ts1
1930383747, ts2 1930424576
[crctst] (get_cycles) 16-bit CRC CCITT, 65536 bytes: delta 81646, ts1
1930518699, ts2 1930600345
[crctst] (get_cycles) 16-bit CRC CCITT, 131072 bytes: delta 163270,
ts1 1930777816, ts2 1930941086
[crctst] (get_cycles) CRC32, 32 bytes: delta 34, ts1 1930963004, ts2 1930963038
[crctst] (get_cycles) CRC32, 4096 bytes: delta 2748, ts1 1930968343,
ts2 1930971091
[crctst] (get_cycles) CRC32, 32768 bytes: delta 27673, ts1 1931000739,
ts2 1931028412
[crctst] (get_cycles) CRC32, 65536 bytes: delta 55315, ts1 1931091292,
ts2 1931146607
[crctst] (get_cycles) CRC32, 131072 bytes: delta 110611, ts1
1931267188, ts2 1931377799
[crctst] (get_cycles) CRC32c, 32 bytes: delta 44, ts1 1931394196, ts2 1931394240
[crctst] (get_cycles) CRC32c, 4096 bytes: delta 4392, ts1 1931401121,
ts2 1931405513
[crctst] (get_cycles) CRC32c, 32768 bytes: delta 40834, ts1
1931453919, ts2 1931494753
[crctst] (get_cycles) CRC32c, 65536 bytes: delta 81651, ts1
1931587734, ts2 1931669385
[crctst] (get_cycles) CRC32c, 131072 bytes: delta 163274, ts1
1931851834, ts2 1932015108



From johnben345 at zipmail.com.br  Sat Feb 19 14:51:05 2005
From: johnben345 at zipmail.com.br (johnben345 at zipmail.com.br)
Date: Sat, 19 Feb 2005 20:51:05 +0100
Subject: SHIPMENT..
Message-ID: <4216E3F600004316@www.zipmail.com.br>


ATTN: HONORABLE CONTRACTOR
Dear Sir,
Sequel to the secretive arrangement in regards of the shipment of your
contract sum, I wish to inform you that all necessary modalities have been

automatically concluded and have left Nigeria to London via your Country
today by Express Cargo Flight.
Note carefully the content of the crate is "MONEY" but I did not
disclose it to the Courier Services as Money, rather I informed them that
the
crate contain Vital "DIPLOMATIC DOCUMENTS" belonging to my client (that?s

you).
Furthermore, the weight of the consignment is 90kg but I manage to pay
45kg,which cost US$9,000.00. On no account should you disclose the content

of the crate with the Diplomatic Courier Services for fear of betrayal.
So
do not allow them to know that the content is money.
In the meantime, contact the Global Trust Dipomatic Courier Services to

the Attn.MR CARL WAKEHAM,EMAIL;carlwakeham at yahoo.co.uk
 to know the actual situation with the consignment and also give them your
address where the consignment will be delivered and then get back to me
as soon as possible so that I can give you the shipment document.
Meanwhile, I will be coming over to your country immediately the
consignment arrives in your Country for my 10% share.
Please update me as you contact the Global Trust Diplomatic Courier
Services for more details you may need from me.
Congrats and remain blessed.
Best Regards,
Yours faithfully,
Dr.JOHN BEN..



------------------------------------------
Use o melhor sistema de busca da Internet
Radar UOL - http://www.radaruol.com.br






From tglx at linutronix.de  Mon Feb 21 01:59:05 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 21 Feb 2005 07:59:05 +0100
Subject: [PATCH] accessing NAND flash through an IDE interface
In-Reply-To: <4209C985.3020902@setabox.com>
References: <4209C985.3020902@setabox.com>
Message-ID: <1108969145.24721.419.camel@tglx.tec.linutronix.de>

On Wed, 2005-02-09 at 16:27 +0800, William J Beksi wrote:
> Hi Thomas,
> I am not sure if you received the patch I sent you last month for 
> accessing nand flash through an IDE interface so I am sending it again.

@@ -84,6 +84,8 @@
 #include <linux/mtd/partitions.h>
 #endif
 
+#define NAND_USE_IO_INSTR      0

As I said before, I'm not going to accept a change which needs to tweak
a source file to make use of it.

tglx







From steven.scholz at imc-berlin.de  Mon Feb 21 03:16:26 2005
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Mon, 21 Feb 2005 09:16:26 +0100
Subject: ioremap_cached in drivers/mtd/maps ?
Message-ID: <421998DA.1060503@imc-berlin.de>

Hi there,

it looks like only lubbock-flash.c is using ioremap_cached().

Can I use ioremap_cached() with normal NOR flashes?
Is it only for DMA transfer from/to flash?
Does it improve something when using JFFS2?
What do I have to consider? .inval_cache function?

Thanks a million!

-- 
Steven Scholz
imc Measurement & Control



From lists at ku-gbr.de  Mon Feb 21 03:21:44 2005
From: lists at ku-gbr.de (Konstantin Kletschke)
Date: Mon, 21 Feb 2005 09:21:44 +0100
Subject: freeze when mounting fs
In-Reply-To: <20050218154216.GA5926@synertronixx3>
References: <20050218154216.GA5926@synertronixx3>
Message-ID: <20050221082144.GA1704@synertronixx3>

I wan' to inform you I can send/commit debug output next wee, not now,
because we leave to the fair embedded world in Nurnberg now and all
other tasks sleep for a week now, sorry guys!

Regards, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF



From ben at fluff.org.uk  Mon Feb 21 04:31:00 2005
From: ben at fluff.org.uk (Ben Dooks)
Date: Mon, 21 Feb 2005 09:31:00 +0000
Subject: ioremap_cached in drivers/mtd/maps ?
In-Reply-To: <421998DA.1060503@imc-berlin.de>
References: <421998DA.1060503@imc-berlin.de>
Message-ID: <20050221093100.GF28744@home.fluff.org>

On Mon, Feb 21, 2005 at 09:16:26AM +0100, Steven Scholz wrote:
> Hi there,
> 
> it looks like only lubbock-flash.c is using ioremap_cached().
> 
> Can I use ioremap_cached() with normal NOR flashes?
> Is it only for DMA transfer from/to flash?

you could use it for such, but it also allows an cached
area for flash read, which makes it faster to execute
code from.

> Does it improve something when using JFFS2?
> What do I have to consider? .inval_cache function?

It allows the mapping driver to have a seperate read-only
cached area, the .inval_cache function is needed to flush
this area when writes happen to the un-cached area.

-- 
Ben (ben at fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'



From dedekind at infradead.org  Mon Feb 21 05:32:33 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 21 Feb 2005 13:32:33 +0300
Subject: JFFS3 & performance checksum test results.
In-Reply-To: <196b7d31050219120065170409@mail.gmail.com>
References: <196b7d31050219120065170409@mail.gmail.com>
Message-ID: <1108981953.13420.46.camel@sauron.oktetlabs.ru>

On Sat, 2005-02-19 at 21:00 +0100, Lior Balkohen wrote:
> I don't know where/whom to provide to results, so I send the results
> for my IBM embedded powerpc 405 based set top box to the linux-mtd
> list. I hope, I'm right here.

Thank you Lior.

After we've talked with Joern at IRC we are in substantial agreement
that it is good idea not to switch to adler32 and keep CRC32.

The main reason is weakness of adler32 checksum algorithm:
1. It is claimed that the a-priori probability of checksum collisions
might be much higher that 1/2^32 when adler32 ais applied to short data
chunks.

2. It is asserted that adler32 becomes weak (and doesn't detect even
some 1-bit errors) for data chunks > 5552 bytes.

Particularly, SCTP protocol's checksum has recently been changed from
adler32 to CRC32c. For more information, see RFC3309.

But the test is still actual - we can observe the difference between
forward/backward calculation directions.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From narinder at kritikalsolutions.com  Mon Feb 21 08:28:47 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Mon, 21 Feb 2005 18:58:47 +0530
Subject: mkfs.jffs2
Message-ID: <4219E20F.80908@kritikalsolutions.com>

Hi all,

             This is my first mail to the group and is hoping for some 
fruitful results from your mails. I am having problems in mounting my 
MTD device using mkfs.jffs2 . Though i have read mails on the group 
regarding mkfs.jffs2 but still i am not able to decipher my problem, so 
hoping a helpful hand from your side. Here are the steps that i am 
following:

eraseall -j /dev/mtd/1           ( -j as i need jffs2 file system 
/dev/mtd/1 is 1 MB partition)
mkfs.jffs2 -e 0x420 -d /tmp/Application -o image  ( created image of my 
application which is to be put into MTD)
cp image /dev/mtd/1           ( copied the image into MTD)
mount -t jffs2 /dev/mtdblock/1 /mnt is giving errors

Node at 0x00000048 with length 0x000006d2 would run over the end of the 
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000004c: 
0x06d2 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000050: 
0x39d7 instead
[...]
Further such events for this erase block will not be printed
Node at 0x0000071c with length 0x000003d7 would run over the end of the 
erase block
Perhaps the file system was created with the wrong erase size?
JFFS2: Erase block at 0x00000420 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000840: 
0xf42b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000844: 
0x68c7 instead
[....]
Further such events for this erase block will not be printed
Node at 0x00000af4 with length 0x000005a6 would run over the end of the 
erase block
Perhaps the file system was created with the wrong erase size?
JFFS2: Erase block at 0x00000840 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c60: 
0x6df1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c64: 
0x1283 instead
[...]
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000c60 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001080: 
0x8c70 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001084: 
0x8f13 instead
[...]

 From the output atleast i am sure that i am providing the right 
eraseblock to mkfs.jffs2 as Erase block is checking at an interval of 
0x420 everytime. When all these messages stops , i entered into /mnt to 
check if there is something in the mounted device and it does shows 
everthing that i copied into it, so why is this error coming ?
"Node at 0x00000048 with length 0x000006d2 would run over the end of the 
erase block" can this helps me out somehow where something is going 
wrong ???

Narinder



From dedekind at infradead.org  Mon Feb 21 08:58:30 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 21 Feb 2005 16:58:30 +0300
Subject: mkfs.jffs2
In-Reply-To: <4219E20F.80908@kritikalsolutions.com>
References: <4219E20F.80908@kritikalsolutions.com>
Message-ID: <1108994310.13420.50.camel@sauron.oktetlabs.ru>

On Mon, 2005-02-21 at 18:58 +0530, Narinder Kumar wrote:
> mkfs.jffs2 -e 0x420 -d /tmp/Application

0x420 is strange size. I believe it is wrong, try to look at your Flash
specification closer. 




From dedekind at infradead.org  Mon Feb 21 09:05:30 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 21 Feb 2005 17:05:30 +0300
Subject: mkfs.jffs2
In-Reply-To: <4219E20F.80908@kritikalsolutions.com>
References: <4219E20F.80908@kritikalsolutions.com>
Message-ID: <1108994730.13420.52.camel@sauron.oktetlabs.ru>

On Mon, 2005-02-21 at 18:58 +0530, Narinder Kumar wrote:
> mkfs.jffs2 -e 0x420 -d /tmp/Application -o image

Please, post the `cat /proc/mtd/` output.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From narinder at kritikalsolutions.com  Mon Feb 21 09:18:43 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Mon, 21 Feb 2005 19:48:43 +0530
Subject: mkfs.jffs2
In-Reply-To: <1108994310.13420.50.camel@sauron.oktetlabs.ru>
References: <4219E20F.80908@kritikalsolutions.com>
	<1108994310.13420.50.camel@sauron.oktetlabs.ru>
Message-ID: <4219EDC3.1060506@kritikalsolutions.com>

Hi ,

       First of all thanx for the reply . I am using AT45DB642 NAND 
Flash and it seems to have erase block of 0x420 i,e 1056 bytes. and when 
i have created my MTD partitions i have specified the partition sizes to 
be multiple of these eraseblock sizes in 
drivers/at91/mtd/at91_dataflash.c , My 3 partitions are 4*1024*1056  (4 
GB) , 3*1024*1056 (3 GB) and 1*1024*1056 (1 GB)


Artem B. Bityuckiy wrote:

>On Mon, 2005-02-21 at 18:58 +0530, Narinder Kumar wrote:
>  
>
>>mkfs.jffs2 -e 0x420 -d /tmp/Application
>>    
>>
>
>0x420 is strange size. I believe it is wrong, try to look at your Flash
>specification closer. 
>
>
>
>.
>
>  
>




From narinder at kritikalsolutions.com  Mon Feb 21 09:25:47 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Mon, 21 Feb 2005 19:55:47 +0530
Subject: mkfs.jffs2
In-Reply-To: <1108994730.13420.52.camel@sauron.oktetlabs.ru>
References: <4219E20F.80908@kritikalsolutions.com>
	<1108994730.13420.52.camel@sauron.oktetlabs.ru>
Message-ID: <4219EF6B.8040208@kritikalsolutions.com>

Hi all,

When the kernel boots it shows the message:
Creating 3 MTD partitions on "Atmel AT45DB642":
0x00000000-0x00108000 : "/dev/mtd/0"
0x00108000-0x00420000 : "/dev/mtd/1"
0x00420000-0x00840000 : "/dev/mtd/2"

and cat /proc/mtd prints out

dev:       size         erasesize    name
mtd0: 00108000 00000420  "/dev/mtd/0"
mtd1: 00318000 00000420  "/dev/mtd/1"
mtd2: 00420000 00000420  "/dev/mtd/2"



Artem B. Bityuckiy wrote:

>On Mon, 2005-02-21 at 18:58 +0530, Narinder Kumar wrote:
>  
>
>>mkfs.jffs2 -e 0x420 -d /tmp/Application -o image
>>    
>>
>
>Please, post the `cat /proc/mtd/` output.
>
>  
>




From dedekind at infradead.org  Mon Feb 21 09:35:45 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 21 Feb 2005 17:35:45 +0300
Subject: mkfs.jffs2
In-Reply-To: <4219EF6B.8040208@kritikalsolutions.com>
References: <4219E20F.80908@kritikalsolutions.com>
	<1108994730.13420.52.camel@sauron.oktetlabs.ru>
	<4219EF6B.8040208@kritikalsolutions.com>
Message-ID: <1108996545.13420.55.camel@sauron.oktetlabs.ru>

Could you please look at JFFS2 output during mount - it should inform
what Virtual block size it gonna use. This should appear before error
messages.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From andrew at sanpeople.com  Mon Feb 21 10:21:19 2005
From: andrew at sanpeople.com (Andrew Victor)
Date: 21 Feb 2005 17:21:19 +0200
Subject: mkfs.jffs2
In-Reply-To: <4219EDC3.1060506@kritikalsolutions.com>
References: <4219E20F.80908@kritikalsolutions.com>
	<1108994310.13420.50.camel@sauron.oktetlabs.ru>
	<4219EDC3.1060506@kritikalsolutions.com>
Message-ID: <1108999278.16852.46.camel@fuzzie.sanpeople.com>

hi,

>        First of all thanx for the reply . I am using AT45DB642 NAND 
> Flash and it seems to have erase block of 0x420 i,e 1056 bytes. and when 
> i have created my MTD partitions i have specified the partition sizes to 
> be multiple of these eraseblock sizes in 
> drivers/at91/mtd/at91_dataflash.c , My 3 partitions are 4*1024*1056  (4 
> GB) , 3*1024*1056 (3 GB) and 1*1024*1056 (1 GB)

Atmel AT45DB642 is DataFlash (not NAND).
mkfs.jffs2 is currently broken for DataFlash.

This is how I once fixed it.  I don't know if the current mkfs.jffs2
code is different.....

In mkfs.jffs2.c in function main().  Comment out the code:

//     /* If it's less than 4096, assume they meant KiB */
//     if (erase_block_size && erase_block_size < 0x1000)
//         erase_block_size *= 1024;
//     /* If it's less than 8KiB, they're not allowed */
//     if (erase_block_size < 0x2000) {
//         fprintf(stderr, "Increasing erase size to 8KiB minimum\n");
//         erase_block_size = 0x2000;
//     }

Then run mkfs.jffs2 with the parameters "-e 2112 -n -l"

The 2112 is because JFFS2 merges multiple 528-byte or 1056-byte physical
blocks into larger virtual blocks.
The 2112 is for a 4Mb dataflash device, and that value will probably
differ for differently sized dataflash devices.

You should see the message:
  JFFS2 write-buffering enabled (2112)
when you mount the JFFS2 partition.  The size of brackets is the virtual
blocks size.  You should also be using the code from the MTD/JFFS2 CVS.


Regards,
  Andrew Victor
  SAN People (Pty) Ltd.





From buytenh at wantstofly.org  Mon Feb 21 10:41:21 2005
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Mon, 21 Feb 2005 16:41:21 +0100
Subject: [PATCH,RFC] remove slowport mode setting from ixp2000 map driver
Message-ID: <20050221154121.GA31235@xi.wantstofly.org>

(please CC on replies, not on the list)

Setting the slowport to 8-bit mode is something that ought to be
done in the IXP2000 generic code, not in the MTD map driver.  See
the description for ARM patch 2493/1 for an explanation.

	http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2493/1

Now that 2493/1 has been accepted and will be upstream soon, this
doesn't need to be done in the map driver anymore.

Signed-off-by: Lennert Buytenhek <buytenh at wantstofly.org>


diff -urN linux-2.6.11-rc4.orig/drivers/mtd/maps/ixp2000.c linux-2.6.11-rc4/drivers/mtd/maps/ixp2000.c
--- linux-2.6.11-rc4.orig/drivers/mtd/maps/ixp2000.c	2004-12-24 22:35:39.000000000 +0100
+++ linux-2.6.11-rc4/drivers/mtd/maps/ixp2000.c	2005-02-21 16:12:03.313753034 +0100
@@ -216,11 +216,6 @@
 		goto Error;
 	}
 
-	/*
-	 * Setup read mode for FLASH
-	 */
-	*IXP2000_SLOWPORT_FRM = 1;
-
 #if defined(__ARMEB__)
 	/*
 	 * Enable erratum 44 workaround for NPUs with broken slowport




From nico at cam.org  Mon Feb 21 11:05:09 2005
From: nico at cam.org (Nicolas Pitre)
Date: Mon, 21 Feb 2005 11:05:09 -0500 (EST)
Subject: ioremap_cached in drivers/mtd/maps ?
In-Reply-To: <421998DA.1060503@imc-berlin.de>
References: <421998DA.1060503@imc-berlin.de>
Message-ID: <Pine.LNX.4.61.0502211059090.15845@localhost.localdomain>

On Mon, 21 Feb 2005, Steven Scholz wrote:

> Hi there,
> 
> it looks like only lubbock-flash.c is using ioremap_cached().

sa1100-flash could be using it as well.

> Can I use ioremap_cached() with normal NOR flashes?

Yes.

> Is it only for DMA transfer from/to flash?

>From flash only.

> Does it improve something when using JFFS2?

Much improved read throughput.

> What do I have to consider? .inval_cache function?

Yep.


Nicolas



From postmaster at infradead.org  Mon Feb 21 16:36:18 2005
From: postmaster at infradead.org (David Woodhouse)
Date: Mon, 21 Feb 2005 21:36:18 +0000
Subject: Administrivia - READ ME
Message-ID: <1109021779.26578.41.camel@localhost.localdomain>

If you receive spam from the mailing list, please don't report it to
spamcop without bothering to contact me. I do my best to filter the crap
out of the list, and I don't think we do too badly. I really don't want
to restrict the list to subscribers-only, which is about the only other
trick I can think of.

The machine lists.infradead.org is in a temporary home, and I've just
been jumped on by the people whose netblock it's currently living on,
after they heard from spamcop.

It's possible that whoever reported it didn't realise it was from the
mailing list because their filtering is broken. You shouldn't be looking
in the To: or Cc: headers of the mail. The SMTP reverse-path, usually
seen in the Return-Path: header when the mail has been delivered, is the
reliable way of detecting where mail came from and filtering list
traffic.

-- 
dwmw2




From narinder at kritikalsolutions.com  Tue Feb 22 00:03:05 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Tue, 22 Feb 2005 10:33:05 +0530
Subject: mkfs.jffs2
In-Reply-To: <1108996545.13420.55.camel@sauron.oktetlabs.ru>
References: <4219E20F.80908@kritikalsolutions.com>	
	<1108994730.13420.52.camel@sauron.oktetlabs.ru>	
	<4219EF6B.8040208@kritikalsolutions.com>
	<1108996545.13420.55.camel@sauron.oktetlabs.ru>
Message-ID: <421ABD09.2010006@kritikalsolutions.com>

Artem B. Bityuckiy wrote:

>Could you please look at JFFS2 output during mount - it should inform
>what Virtual block size it gonna use. This should appear before error
>messages.
>
>  
>
This is what is being shown when i mount the mtd block, can this help 
out in someway ?

$mount -t jffs2 /dev/mtdblock/1 /tmp/mmm/
Node at 0x00000048 with length 0x000006d2 would run over the end of the 
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000004c: 
0x06d2 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000050: 
0x39d7 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000054: 
0x0002 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000058: 
0x0002 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000005c: 
0x81a4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000060: 
0x022f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000064: 
0x13fb instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000068: 
0xa791 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000006c: 
0xa791 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000070: 
0xa791 instead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000420: 
0xad8f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000424: 
0xcfd9 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000428: 
0x4e0b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000042c: 
0x2792 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000430: 
0xfa51 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000434: 
0xf7bd instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000438: 
0xe348 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000043c: 
0xb366 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000440: 
0xe86b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000444: 
0x10f2 instead
Further such events for this erase block will not be 
printed                   
Node at 0x0000071c with length 0x000003d7 would run over the end of the 
erase block
Perhaps the file system was created with the wrong erase 
size?                 
JFFS2: Erase block at 0x00000420 is not formatted. It will be 
erased           
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000840: 
0xf42b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000844: 
0x68c7 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000848: 
0x0184 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000084c: 
0xfb02 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000850: 
0x6d29 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000854: 
0x5cbd instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000858: 
0x23a3 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000085c: 
0xe231 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000860: 
0xb762 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000864: 
0x3c62 instead
Further such events for this erase block will not be 
printed                   
Node at 0x00000af4 with length 0x000005a6 would run over the end of the 
erase block
Perhaps the file system was created with the wrong erase 
size?                 
JFFS2: Erase block at 0x00000840 is not formatted. It will be 
erased           
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c60: 
0x6df1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c64: 
0x1283 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c68: 
0x1cd8 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c6c: 
0x86dd instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c70: 
0x8594 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c74; 
0xb3c8 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c78: 
0x8922 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c7c: 
0x8d8c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c80: 
0x01f8 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000c84: 
0x9726 instead
Further such events for this erase block will not be 
printed                   
JFFS2: Erase block at 0x00000c60 is not formatted. It will be 
erased           
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001080: 
0x8c70 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001084: 
0x8f13 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001088: 
0x01fc instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000108c: 
0xbf8e instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001090: 
0x7b72 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001094: 
0x00c0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00001098: 
0x4ae2 instead
Node at 0x0000109c with length 0x0000055c would run over the end of the 
erase block
Perhaps the file system was created with the wrong erase 
size?                 
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000010a0: 
0x055c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000010a4: 
0x4686 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000010a8: 
0x0002 instead
Further such events for this erase block will not be 
printed                   
JFFS2: Erase block at 0x00001080 is not formatted. It will be 
erased           
[............................................................]

Best Regards,
Narinder Kumar,
New Delhi, India.



From thomas.brinker at gmx.de  Tue Feb 22 06:19:41 2005
From: thomas.brinker at gmx.de (Thomas Brinker)
Date: Tue, 22 Feb 2005 12:19:41 +0100
Subject: mounting jffs2 rw
Message-ID: <200502221219.41518.thomas.brinker@gmx.de>

Hi!

I have problems in remounting a jffs2 as read/writeable.

Currently it mounts successfully as root-fs but in ro, which is no wonder.
But how can I change it to rw?


Here is what I have tried so far:
---===---
# cat /proc/version
Linux version 2.6.9-uc0 (thomas at mobile) (gcc version 3.4.3) #141 Mon Feb 21 16:01:36 CET 2005
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00010000 "phys_mapped_flash"
# ls -l /dev/mtd*
crw-r--r--    1 root     root      90,   0 Feb  7  2005 /dev/mtd0
brw-r--r--    1 root     root      31,   0 Feb  7  2005 /dev/mtdblock0
crw-r--r--    1 root     root      90,   1 Feb  7  2005 /dev/mtdr0
# mount
/dev/rom0 on / type jffs2 (ro,noatime)                [<--- rom0 is strange]
/proc on /proc type proc (rw,nodiratime)
none on /dev/pts type devpts (rw)
none on /sys type sysfs (rw)
ram on /var type ramfs (rw)
# mount -o remount,rw /dev/mtdblock0 /
mount: Mounting /dev/mtdblock0 on / failed: No such file or directory
# mount -o remount,rw /dev/rom0 /
mount: Mounting /dev/rom0 on / failed: No such file or directory
# mount -o remount,rw /
mount:
Cannot read /etc/fstab: No such file or directory
---===---

Boot logs:
---===---
Linux version 2.6.9-uc0 (thomas at mobile) (gcc version 3.4.3) #141 Mon Feb 21 16:01:36 CET 2005
CPU: P2001 [41029000] revision 0 (ARMv4T)
Machine: P2001
Built 1 zonelists
Kernel command line: ip=dhcp root=/dev/mtdblock0 rootfstype=jffs2 console=ttyS0,57600n8
PID hash table entries: 128 (order: 7, 2048 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 16MB = 16MB total
Memory: 14508KB available (1440K code, 184K data, 64K init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
NET: Registered protocol family 16
NetWinder Floating Point Emulator V0.97 (extended precision)
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
JFFS2: default compression mode: priority
p2001_uart.c:v1.3 12/01/2004 Tobias Lorenz (tobias.lorenz at gmx.net)
ttyS0 at MMIO 0x140000 (irq = 1) is a P2001
p2001_eth.c:v1.19 12/17/2004 Tobias Lorenz (tobias.lorenz at gmx.net)
eth0: ADDR 0x180000, IRQ 17/18, MAC 00:09:4f:00:00:02.
eth0: PHY 0, ID 0x78e20013 (Intel LXT971A).
Setting PHY LEDs to:
  Red    = Link Status
  Yellow = Transmit Status
  Green  = Receive Status
eth1: ADDR 0x181000, IRQ 19/20, MAC 00:09:4f:00:00:03.
eth1: PHY 1, ID 0x78e20013 (Intel LXT971A).
Setting PHY LEDs to:
  Red    = Link Status
  Yellow = Transmit Status
  Green  = Receive Status
eth2: no more MII PHYs found
p2001_eth: 2 interfaces found.
Using anticipatory io scheduler
physmap flash device: 400000 at 2000000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: Receiving filtered multicast (0 entries).
eth0: Receiving filtered multicast (0 entries).
eth0: Receiving filtered multicast (0 entries).
eth1: Receiving filtered multicast (0 entries).
eth1: Receiving filtered multicast (0 entries).
eth1: Receiving filtered multicast (0 entries).
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 10.0.0.1, my address is 10.0.0.205
eth1: Receiving filtered multicast (0 entries).
eth0: Receiving filtered multicast (1 entries).
IP-Config: Complete:
      device=eth0, addr=10.0.0.205, mask=255.255.255.0, gw=255.255.255.255,
     host=p2001, domain=, nis-domain=(none),
     bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath=/root/linux/armroot
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing init memory: 64K
init: Mounting Filesystems:  proc devpts sys ram done.
init: Setting up Interfaces: lo done.
init: Starting Services: inetd done.                                                                                                                                 
---===---

Regards
Thomas

-- 
Wo k?men wir hin, wenn alle sagten, wo k?men wir hin,
und niemand ginge, um einmal zu schauen, wohin man k?me,
wenn man ginge.
?Kurt Marti?



From itsme.linux at gmail.com  Tue Feb 22 06:49:45 2005
From: itsme.linux at gmail.com (sunil m)
Date: Tue, 22 Feb 2005 12:49:45 +0100
Subject: Writing to flash
Message-ID: <a263d8370502220349409a2537@mail.gmail.com>

hello,

How a kernel module sees an onboard flash memory ? How is it possible
to write to onboard flash memory from a kernel module ? say writing
some informations to a file in flash. please help

br,

sunil m



From buytenh at wantstofly.org  Tue Feb 22 09:31:37 2005
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Tue, 22 Feb 2005 15:31:37 +0100
Subject: [PATCH,
	RFC] remove slowport mode setting from ixp2000 map driver
In-Reply-To: <A11645C193F77D429D800AED92117422016A1F76@swsmsx404>
References: <A11645C193F77D429D800AED92117422016A1F76@swsmsx404>
Message-ID: <20050222143137.GC4481@xi.wantstofly.org>

On Tue, Feb 22, 2005 at 01:05:12PM -0000, Mialkowski, Andrzej wrote:

> Lennert,

Hi Andrzej,

First of all, thanks for your reply.  (I'll still get back to you on
the erratum #66 issue, I've been doing some testing for that but it's
all pretty involved.)


> 	It seems that you get confused FRM (Flash Read Mode) with ADC
> register settings. FRM controls only logical behavior of read from
> flash. Setting FRM=1 causes that reads from flash are ~4 times faster.
> FRM=0 is required only for code execution from flash.

That is what I said here, isn't it?

	http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2493/1


My understanding of SP_FRM/SP_ADC is as follows.  SP_ADC controls how
many address and data cycles will be done for each slowport access.  The
slowport is 8 bit wide, and you can choose between one (8 bit), two
(16 bit), three (24 bit) or four (32 bit) address cycles, and the same
for data cycles.  Sort of like what single/dual address cycle does for
PCI.

About SP_FRM my copy of the Programmer's Reference Manual (p405) says
this:

	SP_FRM

	Flash Read More Register.  The SP_FRM is used to configure the
	SlowPort flash memory read mode, 8-bit read mode and 32-bit read
	mode.  For the 8-bit read mode, one read cycle is involved.  No
	packing process is needed.  The data will be directly placed onto
	the lower order byte, [7:0] of the APB bus.  For the 32-bit read
	mode, it needs 4 read cycles.  All 4 bytes are packed into a
	32-bit data and passed to the APB bus.  By default, it is
	configured to 32-bit mode.  The programmer should leave it to
	be 32-bit read mode most of the time unless they need to
	program the flash memory and access register inside the flash
	memory.

	[31:1]	RESERVED
	[0]	FRM		Configure flash memory read mode
				0 - Use 32-bit data
				1 - Use 8-bit data


So.  "8-bit flash read mode" (SP_FRM) doesn't mean the same thing as
"single data cycle (i.e. 8 bit slowport data bus width.)

FRM=0 (32-bit flash read mode) is required for code execution from
flash because the flash is always burned in little-endian, and this
way, the xscale will always read the instruction stream in the right
byte order no matter whether that is big or little endian.  It is
useless for slowport peripheral accesses because it always does 32-bit
slowport reads (which might not be what you want), and it's always in
little endian, which means that on big endian you get to swap everything
by hand.

FRM=1 (8-bit flash read mode) makes flash reads go four times faster
because it will do a single 8-bit slowport access for each slowport byte
access, whereas with FRM=0 (32-bit flash read mode), it will do a 32-bit
slowport read for each byte read and then return only 8 of those 32 bits
to the user, effectively requiring a 32-bit read for every 8-bit read.

So, SP_ADC="general slowport address/data bus width", SP_FRM="translate
access into a byte (FRM=1) or word (FRM=0) access".

Are we in agreement? :)

I submitted a patch to remove setting FRM=1 because it is now done in
the generic IXP2000 code.


cheers,
Lennert



From m.mikolaiczyk at rac.de  Tue Feb 22 11:44:36 2005
From: m.mikolaiczyk at rac.de (Marcus Mikolaiczyk)
Date: Tue, 22 Feb 2005 17:44:36 +0100
Subject: Where to put hardware related informations?
Message-ID: <90EB974D9BCBE2499D2C4B234F9EEDEB3AFEFD@neptun1.office.rac.de>

Hi,

we got an embedded device using the microcontroller tc1130(infineon), NOR
and NAND Flash. The Nor flash is working fine with mtd driver an jffs2. The
next thing is to implement the NAND support for the Hardware in the sources.
I'm new to this and need assistance where to add hardware related
information like memory adresses...
We use a Samsung 2Gbit NAND (8bit)K9E2G08U0M-YIB0 . The hardware is
connected in the folowing way:

TC1130	CPLD		NAND
------	-----		-----
CS2----------/CE--------/CE
A0-----------CLE--------CLE
A1-----------ALE--------ALE
/WR----------/WE--------/WE
/RD----------/RD--------/RD

P0.4(GPIO)--------------RB
TD[0:7]-----------------D[0:7]

Where do I need to add/change things like the RB for NAND support. P0.4
means something like Port 0 Pin 4 with the address range 0xF000 0C00 -
0xF000 0CFF. P0_In Register at 0xF000 0C14 Pin 4 is Bit 4. If the NAND is
working RB ist high? So the P0.4 is high which means 0xF000 0C14 is
something like 0000 0000 0000 1000 (Bit 4 is high).
Again for A0/A1... 

As I mentioned the Nor flash is working fine, so I hope changes to do don't
influence the Nor flash.

Marcus Mikolaiczyk
 
-------------------------------------------------------
RA Consulting GmbH
Zeiloch 6a
76646 Bruchsal
Germany
Tel.: +49 7251 3862 32
Fax.: +49 7251 3862 11
Mobil.: +49 176 18 3862 32
Email: m.mikolaiczyk at rac.de
-------------------------------------------------------
 



From alexn at dsv.su.se  Wed Feb 23 03:43:25 2005
From: alexn at dsv.su.se (Alexander Nyberg)
Date: Wed, 23 Feb 2005 09:43:25 +0100
Subject: [PATCH] Use after free in mtd/phram.c: unregister_devices()
Message-ID: <1109148205.2249.3.camel@boxen>

Use after free, found by the Coverity tool

Signed-off-by: Alexander Nyberg <alexn at dsv.su.se>

===== drivers/mtd/devices/phram.c 1.6 vs edited =====
--- 1.6/drivers/mtd/devices/phram.c	2005-01-05 19:08:36 +01:00
+++ edited/drivers/mtd/devices/phram.c	2005-02-23 09:29:59 +01:00
@@ -107,9 +107,9 @@ static int phram_write(struct mtd_info *
 
 static void unregister_devices(void)
 {
-	struct phram_mtd_list *this;
+	struct phram_mtd_list *this, *safe;
 
-	list_for_each_entry(this, &phram_list, list) {
+	list_for_each_entry_safe(this, safe, &phram_list, list) {
 		del_mtd_device(&this->mtd);
 		iounmap(this->mtd.priv);
 		kfree(this);





From joern at wohnheim.fh-wedel.de  Wed Feb 23 08:05:40 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Wed, 23 Feb 2005 14:05:40 +0100
Subject: [PATCH] Use after free in mtd/phram.c: unregister_devices()
In-Reply-To: <1109148205.2249.3.camel@boxen>
References: <1109148205.2249.3.camel@boxen>
Message-ID: <20050223130540.GB10908@wohnheim.fh-wedel.de>

On Wed, 23 February 2005 09:43:25 +0100, Alexander Nyberg wrote:
> 
> Use after free, found by the Coverity tool

Thanks!

> Signed-off-by: Alexander Nyberg <alexn at dsv.su.se>
> 
> ===== drivers/mtd/devices/phram.c 1.6 vs edited =====
> --- 1.6/drivers/mtd/devices/phram.c	2005-01-05 19:08:36 +01:00
> +++ edited/drivers/mtd/devices/phram.c	2005-02-23 09:29:59 +01:00
> @@ -107,9 +107,9 @@ static int phram_write(struct mtd_info *
>  
>  static void unregister_devices(void)
>  {
> -	struct phram_mtd_list *this;
> +	struct phram_mtd_list *this, *safe;
>  
> -	list_for_each_entry(this, &phram_list, list) {
> +	list_for_each_entry_safe(this, safe, &phram_list, list) {
>  		del_mtd_device(&this->mtd);
>  		iounmap(this->mtd.priv);
>  		kfree(this);
> 

J?rn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens



From buytenh at wantstofly.org  Wed Feb 23 10:23:24 2005
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Wed, 23 Feb 2005 16:23:24 +0100
Subject: [PATCH,
	RFC] remove slowport mode setting from ixp2000 map driver
In-Reply-To: <A11645C193F77D429D800AED92117422016CBF72@swsmsx404>
References: <A11645C193F77D429D800AED92117422016CBF72@swsmsx404>
Message-ID: <20050223152324.GF9272@xi.wantstofly.org>

On Wed, Feb 23, 2005 at 11:26:44AM -0000, Mialkowski, Andrzej wrote:

> Lennert,

Hi,


> 	I'm OK with this change I just not caught that you are moving
> this setting to other place in ixp2000 global code.

Ok, great.  Can you commit it, or can someone else do that?


> Little surprise for
> me is that you are saying that you have(seen?) problem with access to
> devices when FRM=0, I never noticed that. This may of course happen in
> some hardware implementations but this means that there is no access to
> devices when executing from flash :(.

There is, but it's somewhat tricky -- you have to keep byteswapping
in mind, and the slowport might do more reads than you expect it to.

I have a byte-addressable device on my slowport region #0 which has
byte-sized registers.  The first four registers of the device are
normally '31 13 19 00'.  When the xscale runs in big-endian, I get
this:

		word read	halfword reads		byte reads
SP_FRM=0	00191331	0019 1331		00 19 13 31
SP_FRM=1	31313131	3113 1900		31 13 19 00

In SP_FRM=0, the output still looks 'fixable'.

But note that when SP_FRM=0 and you're doing a byte or halfword read,
what actually happens is that the slowport does four byte reads, combines
that to a word using little-endian ordering (00191331), presents that
word to the xscale, and the xscale then picks one of the {byte,halfword}s
from that word.

So, even if you do only a single byte read, it can still be doing four
byte reads on the slowport.  This can obviously confuse attached devices.


cheers,
Lennert



From Muhammad.Yahya at Sun.COM  Wed Feb 23 18:13:29 2005
From: Muhammad.Yahya at Sun.COM (Muhammad Yahya)
Date: Wed, 23 Feb 2005 15:13:29 -0800
Subject: Errors writing to flash
Message-ID: <421D0E19.6030507@sun.com>

Hi,

I am running a PPC 875 board with Linux  2.4.25 and an 8MB flash.
When I try to write to the flash an image, as


>
> /tmp # wget -O - 
> http://129.148.183.102/~muhammad/flashupdate/spimage_nouboot |
> dd of=/dev/mtdblock0 bs=1k seek=256
> 7936+0 records in
> 7936+0 records out
>
> The write seems to go OK withiout any errors, but, on the console, we see
> the following messages which I an not sure if they are coming from 
> jffs or the mtd driver.
> Sometimes these messages are output right away after the write 
> completes and
> sometimes there is a delay before they are output:
>
>
> Node totlen on flash (0xffffffff) != totlen in node ref (0x000000c0)
> Node totlen on flash (0xffffffff) != totlen in node ref (0x00000064)
> Node totlen on flash (0xffffffff) != totlen in node ref (0x00000044)
>
> Any idea as to what this means and how to avoid this ? 

Thanks!
Muhammad

>
>
>
>
>
>
>






From anil.s.keshavamurthy at intel.com  Wed Feb 23 18:31:46 2005
From: anil.s.keshavamurthy at intel.com (Keshavamurthy, Anil S)
Date: Wed, 23 Feb 2005 15:31:46 -0800
Subject: xattr support  for JFFS3
Message-ID: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>

Hi,
	I am new to this mailing list but would like to contribute to
xattr for flash file system. While looking at the archive seems like
jffs2 is just a bug fix only and any new feature development should go
to jffs3. So here is my question.
1) Is JFFS3 a completely rewritten file system? If true, what stage are
we w.r.t JFFS3? 
2) Where can I find the sources for JFFS3? Sorry, if this is a stupid
question.


Thanks and appreciate your help.

-Anil




From jdub at us.ibm.com  Wed Feb 23 19:58:19 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Wed, 23 Feb 2005 18:58:19 -0600
Subject: xattr support  for JFFS3
In-Reply-To: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
Message-ID: <1109206700.8215.4.camel@windu.rchland.ibm.com>

On Wed, 2005-02-23 at 15:31 -0800, Keshavamurthy, Anil S wrote:
> Hi,
> 	I am new to this mailing list but would like to contribute to
> xattr for flash file system. While looking at the archive seems like
> jffs2 is just a bug fix only and any new feature development should go
> to jffs3. So here is my question.

xattr support seems to be a popular topic these days.  You might want to
take a look at this thread on the lkml:

http://lkml.org/lkml/2005/2/22/85

Lorenzo already has something started.  Perhaps the two of you could
work together.

> 1) Is JFFS3 a completely rewritten file system? If true, what stage are
> we w.r.t JFFS3? 

No, JFFS3 is a clone of JFFS2 with some minor changes and a new node
type.  The code bases will begin to differ as new features are added to
JFFS3.

> 2) Where can I find the sources for JFFS3? Sorry, if this is a stupid
> question.

It can be found in the MTD CVS tree.  It's also available in the nightly
tarballs.  See http://linux-mtd.infradead.org

josh




From anil.s.keshavamurthy at intel.com  Wed Feb 23 20:15:59 2005
From: anil.s.keshavamurthy at intel.com (Keshavamurthy Anil S)
Date: Wed, 23 Feb 2005 17:15:59 -0800
Subject: xattr support  for JFFS3
In-Reply-To: <1109206700.8215.4.camel@windu.rchland.ibm.com>;
	from jdub@us.ibm.com on Wed, Feb 23, 2005 at 06:58:19PM -0600
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
Message-ID: <20050223171559.A23461@unix-os.sc.intel.com>

On Wed, Feb 23, 2005 at 06:58:19PM -0600, Josh Boyer wrote:
> On Wed, 2005-02-23 at 15:31 -0800, Keshavamurthy, Anil S wrote:
> > Hi,
> > 	I am new to this mailing list but would like to contribute to
> > xattr for flash file system. While looking at the archive seems like
> > jffs2 is just a bug fix only and any new feature development should go
> > to jffs3. So here is my question.
> 
> xattr support seems to be a popular topic these days.  You might want to
> take a look at this thread on the lkml:
> 
> http://lkml.org/lkml/2005/2/22/85
> 
> Lorenzo already has something started.  Perhaps the two of you could
> work together.
Sure, I will take a look at his patch and will work with him to
get this feature into JFFS3.

Thanks,
Anil



From narinder at kritikalsolutions.com  Thu Feb 24 03:11:15 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Thu, 24 Feb 2005 13:41:15 +0530
Subject: mkfs.jffs2
In-Reply-To: <1108999278.16852.46.camel@fuzzie.sanpeople.com>
References: <4219E20F.80908@kritikalsolutions.com>	
	<1108994310.13420.50.camel@sauron.oktetlabs.ru>	
	<4219EDC3.1060506@kritikalsolutions.com>
	<1108999278.16852.46.camel@fuzzie.sanpeople.com>
Message-ID: <421D8C23.2000200@kritikalsolutions.com>

Andrew Victor wrote:

>hi,
>
>  
>
>>       First of all thanx for the reply . I am using AT45DB642 NAND 
>>Flash and it seems to have erase block of 0x420 i,e 1056 bytes. and when 
>>i have created my MTD partitions i have specified the partition sizes to 
>>be multiple of these eraseblock sizes in 
>>drivers/at91/mtd/at91_dataflash.c , My 3 partitions are 4*1024*1056  (4 
>>GB) , 3*1024*1056 (3 GB) and 1*1024*1056 (1 GB)
>>    
>>
>
>Atmel AT45DB642 is DataFlash (not NAND).
>mkfs.jffs2 is currently broken for DataFlash.
>
>This is how I once fixed it.  I don't know if the current mkfs.jffs2
>code is different.....
>
>In mkfs.jffs2.c in function main().  Comment out the code:
>
>//     /* If it's less than 4096, assume they meant KiB */
>//     if (erase_block_size && erase_block_size < 0x1000)
>//         erase_block_size *= 1024;
>//     /* If it's less than 8KiB, they're not allowed */
>//     if (erase_block_size < 0x2000) {
>//         fprintf(stderr, "Increasing erase size to 8KiB minimum\n");
>//         erase_block_size = 0x2000;
>//     }
>
>Then run mkfs.jffs2 with the parameters "-e 2112 -n -l"
>
>The 2112 is because JFFS2 merges multiple 528-byte or 1056-byte physical
>blocks into larger virtual blocks.
>The 2112 is for a 4Mb dataflash device, and that value will probably
>differ for differently sized dataflash devices.
>
>You should see the message:
>  JFFS2 write-buffering enabled (2112)
>when you mount the JFFS2 partition.  The size of brackets is the virtual
>blocks size.  You should also be using the code from the MTD/JFFS2 CVS.
>
>
>Regards,
>  Andrew Victor
>  SAN People (Pty) Ltd.
>
>
>
>
>
>  
>
I tried out the solution that you mentioned but it doesn't seems to work 
for me. I am using ATMEL AT45DB642 which is an 8MB Dataflash. Can anyone 
tell me what the erase size of this DataFlash. Currently i am trying out 
with 1056 ( i,e 0x420 in hex) . If anyone has success in making a jffs2 
partition on this dataflash and thereby reading/writing on it, please 
help me out. I tried out with different erasesizes but it doesn't seems 
to work.

                Can anyone tell me what are the parameters to be 
specified in drivers/at91/mtd/at91_dataflash.c where one can specify 
what static partitions are to be created in the data flash. I am 
currenlt giving
static struct mtd_partition static_partitions[] =
{
        {
                name:           "bootloader",
                offset:         0,
                size:           1 * 1024 * 1056,        // 1 MB
                mask_flags:     MTD_WRITEABLE           // read-only
        },
        {
                name:           "kernel",
                offset:         MTDPART_OFS_NXTBLK,
                size:           1 * 1024 * 1056,        // 1 MB
        },
        {
                name:           "ramdisk",
                offset:         MTDPART_OFS_NXTBLK,
                size:           3 * 1024 * 1056,        // 3 MB
        },
        {
                name:           "Application",
                offset:         MTDPART_OFS_NXTBLK,
                size:           MTDPART_SIZ_FULL,
        }
};

         Am i write on these parameters ?

Regards,
 Narinder
 KSPL, Delhi



From dedekind at yandex.ru  Thu Feb 24 05:32:23 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Thu, 24 Feb 2005 13:32:23 +0300
Subject: xattr support  for JFFS3
In-Reply-To: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
Message-ID: <421DAD37.7080406@yandex.ru>

Keshavamurthy, Anil S wrote:
> Hi,
> 	I am new to this mailing list but would like to contribute to
> xattr for flash file system. While looking at the archive seems like
> jffs2 is just a bug fix only and any new feature development should go
> to jffs3. So here is my question.
> 1) Is JFFS3 a completely rewritten file system? If true, what stage are
> we w.r.t JFFS3? 
> 2) Where can I find the sources for JFFS3? Sorry, if this is a stupid
> question.
Well, the situation with JFFS3, as *I* see it, is as follows.
Thus far, JFFS3 is on its design stage. There are a lot of interesting 
ideas and proposals (including xattr) exist. I'm trying to summarize 
them and to keep track of them in the "JFFS2 design issues" document 
which one might find either on the MTD Web page or in CVS 
(fs/jffs3/JFFS3design.tex). I'm trying to keep track of good offers 
there. I'm limited in time but I'm doing my best.

The JFFS3 stuff which you may find in MTD CVS is merely the test 
platform where one could try new features.

> 
> 
> Thanks and appreciate your help.
> 
> -Anil
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From vsauder at users.sourceforge.net  Thu Feb 24 05:57:31 2005
From: vsauder at users.sourceforge.net (Vern Sauder)
Date: Thu, 24 Feb 2005 05:57:31 -0500
Subject: JFFS2 stats
Message-ID: <421DB31B.7000900@users.sourceforge.net>

Hello all,

I am working on a "failed" PPC system with a 2.4.25 kernel. I saw a 
lockup where the JFFS2 GC took all the CPU time and the application was 
hung. All writes to the file system failed causing catastrophic problems.

On the way to fixing the application to not completely choke and go 
haywire, I updated the MTD and JFFS2 drivers to the snapshot as of 16 
Feb and now I am having different problems. One thing was that the patch 
did not apply cleanly; I had to modify several files to fit it into my 
kernel. I noticed that the mtd driver seems much faster (writes) which 
was one of my main goal. I was testing the FLASH to verify that the 
lockup wasn't the MTD failing to write to the FLASH. There were several 
instances on the FLASH that seemed to show a one bit difference (always 
a zero that should have been a one). The new drivers sped up the 
testing. I fixed some utilities/scripts I was using and it looks like 
the FLASH is writing and reading fine now.

I seem to have lost ZLIB compression. It is enabled but the JFFS2 debug 
says it doesn't know anything about compression 6. It fails to mount it 
as the root fs but it will mount it later but the data is not right 
then. I thought I saw somewhere that there was a /proc entry that showed 
the jffs2 compressors currently loaded. I can't find it now. Is the 
JFFS2_PROC meaningless for the time being?

I am ultimately looking for complete stats on the JFFS2 to tell what is 
going on in terms of fragmentation and GC. Our application may be 
overloading the JFFS2 by writing too fast or something like that. I 
accidentally found significant info from the U-Boot prompt that looks at 
first glance like it is a good start. Does anyone else have such a tool? 
Is it in JFFS2 and I haven't found it yet?

Vern



From thomas.brinker at gmx.de  Thu Feb 24 06:15:58 2005
From: thomas.brinker at gmx.de (Thomas Brinker)
Date: Thu, 24 Feb 2005 12:15:58 +0100
Subject: mounting jffs2 rw
In-Reply-To: <200502221219.41518.thomas.brinker@gmx.de>
References: <200502221219.41518.thomas.brinker@gmx.de>
Message-ID: <200502241215.58195.thomas.brinker@gmx.de>

Am Dienstag, 22. Februar 2005 12:19 schrieb Thomas Brinker:
> Hi!
>
> I have problems in remounting a jffs2 as read/writeable.
>
> Currently it mounts successfully as root-fs but in ro, which is no wonder.
> But how can I change it to rw?
>
>
> Here is what I have tried so far:
> ---===---
> # cat /proc/version
> Linux version 2.6.9-uc0 (thomas at mobile) (gcc version 3.4.3) #141 Mon Feb 21
> 16:01:36 CET 2005 # cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00400000 00010000 "phys_mapped_flash"
> # ls -l /dev/mtd*
> crw-r--r--    1 root     root      90,   0 Feb  7  2005 /dev/mtd0
> brw-r--r--    1 root     root      31,   0 Feb  7  2005 /dev/mtdblock0
> crw-r--r--    1 root     root      90,   1 Feb  7  2005 /dev/mtdr0
> # mount
> /dev/rom0 on / type jffs2 (ro,noatime)                [<--- rom0 is strange]
# ls -l rom0
brw-r--r--    1 root     root      31,   0 Feb 22  2005 rom0
# ls -l mtdblock0
brw-r--r--    1 root     root      31,   0 Feb 22  2005 mtdblock0

> /proc on /proc type proc (rw,nodiratime) 
> none on /dev/pts type devpts (rw)
> none on /sys type sysfs (rw)
> ram on /var type ramfs (rw)
> # mount -o remount,rw /dev/mtdblock0 /
> mount: Mounting /dev/mtdblock0 on / failed: No such file or directory
> # mount -o remount,rw /dev/rom0 /
> mount: Mounting /dev/rom0 on / failed: No such file or directory
> # mount -o remount,rw /

Adding 'rw' to the kernel command line solves the problem.

Regards
Thomas




From bunk at stusta.de  Thu Feb 24 06:11:25 2005
From: bunk at stusta.de (Adrian Bunk)
Date: Thu, 24 Feb 2005 12:11:25 +0100
Subject: [2.6 patch] remove drivers/mtd/maps/ich2rom.c
Message-ID: <20050224111125.GH8651@stusta.de>

drivers/mtd/maps/ich2rom.c is completely unused because it was renamed 
to drivers/mtd/maps/ichxrom.c .

This patch removes the stale ich2rom.c file.

Signed-off-by: Adrian Bunk <bunk at stusta.de>

---

 drivers/mtd/maps/ich2rom.c |  316 -------------------------------------
 1 files changed, 316 deletions(-)

--- linux-2.6.11-rc4-mm1-full/drivers/mtd/maps/ich2rom.c	2004-12-24 22:35:49.000000000 +0100
+++ /dev/null	2004-11-25 03:16:25.000000000 +0100
@@ -1,316 +0,0 @@
-/*
- * ich2rom.c
- *
- * Normal mappings of chips in physical memory
- * $Id: ich2rom.c,v 1.7 2003/05/21 12:45:18 dwmw2 Exp $
- */
-
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <asm/io.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/config.h>
-#include <linux/pci.h>
-#include <linux/pci_ids.h>
-
-#define RESERVE_MEM_REGION 0
-
-#define ICH2_FWH_REGION_START	0xFF000000UL
-#define ICH2_FWH_REGION_SIZE	0x01000000UL
-#define BIOS_CNTL	0x4e
-#define FWH_DEC_EN1	0xE3
-#define FWH_DEC_EN2	0xF0
-#define FWH_SEL1	0xE8
-#define FWH_SEL2	0xEE
-
-struct ich2rom_map_info {
-	struct map_info map;
-	struct mtd_info *mtd;
-	unsigned long window_addr;
-};
-
-static inline unsigned long addr(struct map_info *map, unsigned long ofs)
-{
-	unsigned long offset;
-	offset = ((8*1024*1024) - map->size) + ofs;
-	if (offset >= (4*1024*1024)) {
-		offset += 0x400000;
-	}
-	return map->map_priv_1 + 0x400000 + offset;
-}
-
-static inline unsigned long dbg_addr(struct map_info *map, unsigned long addr)
-{
-	return addr - map->map_priv_1 + ICH2_FWH_REGION_START;
-}
-	
-static __u8 ich2rom_read8(struct map_info *map, unsigned long ofs)
-{
-	return __raw_readb(addr(map, ofs));
-}
-
-static __u16 ich2rom_read16(struct map_info *map, unsigned long ofs)
-{
-	return __raw_readw(addr(map, ofs));
-}
-
-static __u32 ich2rom_read32(struct map_info *map, unsigned long ofs)
-{
-	return __raw_readl(addr(map, ofs));
-}
-
-static void ich2rom_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
-{
-	memcpy_fromio(to, addr(map, from), len);
-}
-
-static void ich2rom_write8(struct map_info *map, __u8 d, unsigned long ofs)
-{
-	__raw_writeb(d, addr(map,ofs));
-	mb();
-}
-
-static void ich2rom_write16(struct map_info *map, __u16 d, unsigned long ofs)
-{
-	__raw_writew(d, addr(map, ofs));
-	mb();
-}
-
-static void ich2rom_write32(struct map_info *map, __u32 d, unsigned long ofs)
-{
-	__raw_writel(d, addr(map, ofs));
-	mb();
-}
-
-static void ich2rom_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
-{
-	memcpy_toio(addr(map, to), from, len);
-}
-
-static struct ich2rom_map_info ich2rom_map = {
-	.map = {
-		.name = "ICH2 rom",
-		.phys = NO_XIP,
-		.size = 0,
-		.buswidth = 1,
-		.read8 = ich2rom_read8,
-		.read16 = ich2rom_read16,
-		.read32 = ich2rom_read32,
-		.copy_from = ich2rom_copy_from,
-		.write8 = ich2rom_write8,
-		.write16 = ich2rom_write16,
-		.write32 = ich2rom_write32,
-		.copy_to = ich2rom_copy_to,
-		/* Firmware hubs only use vpp when being programmed
-		 * in a factory setting.  So in place programming
-		 * needs to use a different method.
-		 */
-	},
-	.mtd = NULL,
-	.window_addr = 0,
-};
-
-enum fwh_lock_state {
-	FWH_DENY_WRITE = 1,
-	FWH_IMMUTABLE  = 2,
-	FWH_DENY_READ  = 4,
-};
-
-static int ich2rom_set_lock_state(struct mtd_info *mtd, loff_t ofs, size_t len,
-	enum fwh_lock_state state)
-{
-	struct map_info *map = mtd->priv;
-	unsigned long start = ofs;
-	unsigned long end = start + len -1;
-
-	/* FIXME do I need to guard against concurrency here? */
-	/* round down to 64K boundaries */
-	start = start & ~0xFFFF;
-	end = end & ~0xFFFF;
-	while (start <= end) {
-		unsigned long ctrl_addr;
-		ctrl_addr = addr(map, start) - 0x400000 + 2;
-		writeb(state, ctrl_addr);
-		start = start + 0x10000;
-	}
-	return 0;
-}
-
-static int ich2rom_lock(struct mtd_info *mtd, loff_t ofs, size_t len)
-{
-	return ich2rom_set_lock_state(mtd, ofs, len, FWH_DENY_WRITE);
-}
-
-static int ich2rom_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
-{
-	return ich2rom_set_lock_state(mtd, ofs, len, 0);
-}
-
-static int __devinit ich2rom_init_one (struct pci_dev *pdev,
-	const struct pci_device_id *ent)
-{
-	u16 word;
-	struct ich2rom_map_info *info = &ich2rom_map;
-	unsigned long map_size;
-
-	/* For now I just handle the ich2 and I assume there
-	 * are not a lot of resources up at the top of the address
-	 * space.  It is possible to handle other devices in the
-	 * top 16MB but it is very painful.  Also since
-	 * you can only really attach a FWH to an ICH2 there
-	 * a number of simplifications you can make.
-	 *
-	 * Also you can page firmware hubs if an 8MB window isn't enough 
-	 * but don't currently handle that case either.
-	 */
-
-#if RESERVE_MEM_REGION
-	/* Some boards have this reserved and I haven't found a good work
-	 * around to say I know what I'm doing!
-	 */
-	if (!request_mem_region(ICH2_FWH_REGION_START, ICH2_FWH_REGION_SIZE, "ich2rom")) {
-		printk(KERN_ERR "ich2rom: cannot reserve rom window\n");
-		goto err_out_none;
-	}
-#endif /* RESERVE_MEM_REGION */
-	
-	/* Enable writes through the rom window */
-	pci_read_config_word(pdev, BIOS_CNTL, &word);
-	if (!(word & 1)  && (word & (1<<1))) {
-		/* The BIOS will generate an error if I enable
-		 * this device, so don't even try.
-		 */
-		printk(KERN_ERR "ich2rom: firmware access control, I can't enable writes\n");
-		goto err_out_none;
-	}
-	pci_write_config_word(pdev, BIOS_CNTL, word | 1);
-
-
-	/* Map the firmware hub into my address space. */
-	/* Does this use to much virtual address space? */
-	info->window_addr = (unsigned long)ioremap(
-		ICH2_FWH_REGION_START, ICH2_FWH_REGION_SIZE);
-	if (!info->window_addr) {
-		printk(KERN_ERR "Failed to ioremap\n");
-		goto err_out_free_mmio_region;
-	}
-
-	/* For now assume the firmware has setup all relevant firmware
-	 * windows.  We don't have enough information to handle this case
-	 * intelligently.
-	 */
-
-	/* FIXME select the firmware hub and enable a window to it. */
-
-	info->mtd = NULL;
-	info->map.map_priv_1 = 	info->window_addr;
-
-	map_size = ICH2_FWH_REGION_SIZE;
-	while(!info->mtd && (map_size > 0)) {
-		info->map.size = map_size;
-		info->mtd = do_map_probe("jedec_probe", &ich2rom_map.map);
-		map_size -= 512*1024;
-	}
-	if (!info->mtd) {
-		goto err_out_iounmap;
-	}
-	/* I know I can only be a firmware hub here so put
-	 * in the special lock and unlock routines.
-	 */
-	info->mtd->lock = ich2rom_lock;
-	info->mtd->unlock = ich2rom_unlock;
-		
-	info->mtd->owner = THIS_MODULE;
-	add_mtd_device(info->mtd);
-	return 0;
-
-err_out_iounmap:
-	iounmap((void *)(info->window_addr));
-err_out_free_mmio_region:
-#if RESERVE_MEM_REGION
-	release_mem_region(ICH2_FWH_REGION_START, ICH2_FWH_REGION_SIZE);
-#endif
-err_out_none:
-	return -ENODEV;
-}
-
-
-static void __devexit ich2rom_remove_one (struct pci_dev *pdev)
-{
-	struct ich2rom_map_info *info = &ich2rom_map;
-	u16 word;
-
-	del_mtd_device(info->mtd);
-	map_destroy(info->mtd);
-	info->mtd = NULL;
-	info->map.map_priv_1 = 0;
-
-	iounmap((void *)(info->window_addr));
-	info->window_addr = 0;
-
-	/* Disable writes through the rom window */
-	pci_read_config_word(pdev, BIOS_CNTL, &word);
-	pci_write_config_word(pdev, BIOS_CNTL, word & ~1);
-
-#if RESERVE_MEM_REGION	
-	release_mem_region(ICH2_FWH_REGION_START, ICH2_FWH_REGION_SIZE);
-#endif
-}
-
-static struct pci_device_id ich2rom_pci_tbl[] = {
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0, 
-	  PCI_ANY_ID, PCI_ANY_ID, },
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0, 
-	  PCI_ANY_ID, PCI_ANY_ID, },
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_0, 
-	  PCI_ANY_ID, PCI_ANY_ID, },
-	{ 0, },
-};
-
-MODULE_DEVICE_TABLE(pci, ich2rom_pci_tbl);
-
-#if 0
-static struct pci_driver ich2rom_driver = {
-	.name =		"ich2rom",
-	.id_table =	ich2rom_pci_tbl,
-	.probe =	ich2rom_init_one,
-	.remove =	ich2rom_remove_one,
-};
-#endif
-
-static struct pci_dev *mydev;
-int __init init_ich2rom(void)
-{
-	struct pci_dev *pdev;
-	struct pci_device_id *id;
-	pdev = NULL;
-	for(id = ich2rom_pci_tbl; id->vendor; id++) {
-		pdev = pci_find_device(id->vendor, id->device, NULL);
-		if (pdev) {
-			break;
-		}
-	}
-	if (pdev) {
-		mydev = pdev;
-		return ich2rom_init_one(pdev, &ich2rom_pci_tbl[0]);
-	}
-	return -ENXIO;
-#if 0
-	return pci_module_init(&ich2rom_driver);
-#endif
-}
-
-static void __exit cleanup_ich2rom(void)
-{
-	ich2rom_remove_one(mydev);
-}
-
-module_init(init_ich2rom);
-module_exit(cleanup_ich2rom);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Eric Biederman <ebiederman at lnxi.com>");
-MODULE_DESCRIPTION("MTD map driver for BIOS chips on the ICH2 southbridge");




From dwmw2 at infradead.org  Thu Feb 24 08:20:32 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 24 Feb 2005 13:20:32 +0000
Subject: [2.6 patch] remove drivers/mtd/maps/ich2rom.c
In-Reply-To: <20050224111125.GH8651@stusta.de>
References: <20050224111125.GH8651@stusta.de>
Message-ID: <1109251232.5420.55.camel@hades.cambridge.redhat.com>

On Thu, 2005-02-24 at 12:11 +0100, Adrian Bunk wrote:
> drivers/mtd/maps/ich2rom.c is completely unused because it was renamed 
> to drivers/mtd/maps/ichxrom.c .
> 
> This patch removes the stale ich2rom.c file.
> 
> Signed-off-by: Adrian Bunk <bunk at stusta.de>

ack.

-- 
dwmw2




From dedekind at infradead.org  Thu Feb 24 08:20:42 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 24 Feb 2005 13:20:42 +0000 (GMT)
Subject: mkfs.jffs2
In-Reply-To: <421D8C23.2000200@kritikalsolutions.com>
References: <4219E20F.80908@kritikalsolutions.com> 
	<1108994310.13420.50.camel@sauron.oktetlabs.ru>
	<4219EDC3.1060506@kritikalsolutions.com>
	<1108999278.16852.46.camel@fuzzie.sanpeople.com>
	<421D8C23.2000200@kritikalsolutions.com>
Message-ID: <Pine.LNX.4.58.0502241318300.5525@phoenix.infradead.org>

Please, erase your flash then mount *empty* flash. Then type 'dmesg'. You 
should find the information about the block size implied by JFFS2 there.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From narinder at kritikalsolutions.com  Thu Feb 24 08:41:38 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Thu, 24 Feb 2005 19:11:38 +0530
Subject: mkfs.jffs2
In-Reply-To: <Pine.LNX.4.58.0502241318300.5525@phoenix.infradead.org>
References: <4219E20F.80908@kritikalsolutions.com>
	<1108994310.13420.50.camel@sauron.oktetlabs.ru>
	<4219EDC3.1060506@kritikalsolutions.com>
	<1108999278.16852.46.camel@fuzzie.sanpeople.com>
	<421D8C23.2000200@kritikalsolutions.com>
	<Pine.LNX.4.58.0502241318300.5525@phoenix.infradead.org>
Message-ID: <421DD992.60304@kritikalsolutions.com>

Hi all,

          I have finally mounted my dataflash's jffs2 partition. The 
problem was that the driver of dataflash was taking page size in erase 
size function (which was 1056 bytes) and mkfs.jffs2 takes the block 
size. So i changed the erasesize in the driver to be block size which is 
8 * page_size i,e ( 8 *1056) and then i mounted my device and it mounted 
without any errors.

Thanx to all
Narinder


Artem B. Bityuckiy wrote:

>Please, erase your flash then mount *empty* flash. Then type 'dmesg'. You 
>should find the information about the block size implied by JFFS2 there.
>
>--
>Best Regards,
>Artem B. Bityuckiy,
>St.-Petersburg, Russia.
>
>
>.
>
>  
>




From prasadamkumar at yahoo.com  Thu Feb 24 09:27:08 2005
From: prasadamkumar at yahoo.com (prasadam kumar)
Date: Thu, 24 Feb 2005 06:27:08 -0800 (PST)
Subject: crc error
Message-ID: <20050224142708.76840.qmail@web11603.mail.yahoo.com>


hai to all,

  I am working on intel IQ80321 flash(16MB), when i am
using cfi_cmdset_0001 to write into the flash it is
writing properly. When i am booting form flash
it is giving following problem..

my linux version : 2.4.19

> g 0x1008000
Uncompressing Linux ............................

crc error

-- System halted

before sending this mail to mtd group i tryied a lot 
to come out of this problem. plz give me any
suggestions to come out of this problem

bye
prashanth 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250



From ebiederman at lnxi.com  Thu Feb 24 09:28:32 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: 24 Feb 2005 07:28:32 -0700
Subject: [2.6 patch] remove drivers/mtd/maps/ich2rom.c
In-Reply-To: <1109251232.5420.55.camel@hades.cambridge.redhat.com>
References: <20050224111125.GH8651@stusta.de>
	<1109251232.5420.55.camel@hades.cambridge.redhat.com>
Message-ID: <m3acpurq0f.fsf@maxwell.lnxi.com>

David Woodhouse <dwmw2 at infradead.org> writes:

> On Thu, 2005-02-24 at 12:11 +0100, Adrian Bunk wrote:
> > drivers/mtd/maps/ich2rom.c is completely unused because it was renamed 
> > to drivers/mtd/maps/ichxrom.c .
> > 
> > This patch removes the stale ich2rom.c file.
> > 
> > Signed-off-by: Adrian Bunk <bunk at stusta.de>
> 
> ack.

ack.

Eric



From dwmw2 at infradead.org  Thu Feb 24 10:21:27 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 24 Feb 2005 15:21:27 +0000
Subject: crc error
In-Reply-To: <20050224142708.76840.qmail@web11603.mail.yahoo.com>
References: <20050224142708.76840.qmail@web11603.mail.yahoo.com>
Message-ID: <1109258488.5420.85.camel@hades.cambridge.redhat.com>

On Thu, 2005-02-24 at 06:27 -0800, prasadam kumar wrote:
> 
> > g 0x1008000
> Uncompressing Linux ............................
> 
> crc error
> 
> -- System halted

Check the contents of the flash precisely match the original kernel
image by reading it back from Linux. Check the contents of the flash
still match when you read it from your bootloader. Check that the bus
timings etc. are set up correctly, and that you're not trying to do
burst reads into the icache when they're not supported etc.

-- 
dwmw2




From gjohnson at lanl.gov  Thu Feb 24 12:55:52 2005
From: gjohnson at lanl.gov (Greg Johnson)
Date: Thu, 24 Feb 2005 10:55:52 -0700
Subject: MTD for Intel 28F320C3B BIOS flash?
Message-ID: <20050224175552.GR3347@durango.c3.lanl.gov>

Hi,

I would like to be able to update the BIOS of a bunch of Intel SE7520JR2
motherboards from Linux.  According to the spec for this board, it has a
Intel 28F320C3B flash chip.  

What would be required to support this under Linux MTD?  Grepping the
source reveals references to Intel 28F320B3 chips.  Are these supported?
If so, how similar are they?  I'm happy to read the spec and write code,
but I need a little direction first.

It would be great to be able to do this from Linux, as I have a cluster
of 128 to update.

Thanks,

Greg



From msundius at sundius.com  Thu Feb 24 14:34:34 2005
From: msundius at sundius.com (C. Michael Sundius)
Date: Thu, 24 Feb 2005 11:34:34 -0800
Subject: utilities for mtd
Message-ID: <1f065e28ae2a88eda8f37b9c40f54ed2@sundius.com>

Hi,

I am using a the mtd code from the 2.4.20 kernel. how/where do I get 
the corresponding utilities
such as flash_erase, flash_lock etc... I grabbed a random version of 
them somewhere and it
didn't seem to work.. for one the flash_erase program calls an ioctl 
"MEMGETREGIONCOUNT"
and my kernel returned:
	in appropriate ioctl for this device....

any help is appreciated.

thanks



C Michael Sundius
Solico Group LLC
232 Nevada St
San Francisco, CA 94110
msundius at sundius.com
(415)608-0121




From extabe at bredband.net  Thu Feb 24 18:17:39 2005
From: extabe at bredband.net (extabe at bredband.net)
Date: Thu, 24 Feb 2005 23:17:39 +0000
Subject: NAND Driver skeleton?
Message-ID: <20050224231739.LCON24441.mxfep03.bredband.com@mxfep03>

Hi all!
I will make a new NAND board driver for our own hardware. Is there a good and basic driver whitch I can start from?
I saw drivers/mtd/nand/skeleton was mentioned in the "MTD NAND Driver Programming Interface" manual, but I cant find the skeleton anyware.

Regards Andre




From anil.s.keshavamurthy at intel.com  Thu Feb 24 18:56:00 2005
From: anil.s.keshavamurthy at intel.com (Keshavamurthy Anil S)
Date: Thu, 24 Feb 2005 15:56:00 -0800
Subject: xattr support  for JFFS3
In-Reply-To: <1109259722.3796.22.camel@localhost.localdomain>;
	from lorenzo@gnu.org on Thu, Feb 24, 2005 at 04:42:02PM +0100
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
	<20050223171559.A23461@unix-os.sc.intel.com>
	<1109259722.3796.22.camel@localhost.localdomain>
Message-ID: <20050224155559.A727@unix-os.sc.intel.com>

On Thu, Feb 24, 2005 at 04:42:02PM +0100, Lorenzo Hern?ndez Garc?a-Hierro wrote:
> I've read the tech. specs. of JFFS2 as David recommended to me, so, we
> should separate two possible solutions:
Can you please point me to the same spec.
> 
> 	- use a new node type(s)     <- what David likes (& wants AFAIK)
> 	- use reiserfs style-storage <- what I have done partially
> 
> We need also a little road-map and to-do list to know what exactly needs
> to be done in each code "section" to achieve our goal.
Perfect.
> 
> Just let me know when do you want to start, I would like to talk with
> you at #mtd in irc.freenode.org if it's possible.
We can start from next monday, let me know what time you want to chat with
me next monday.

thanks once again.
Anil



From dedekind at infradead.org  Fri Feb 25 04:19:24 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 25 Feb 2005 09:19:24 +0000 (GMT)
Subject: xattr support  for JFFS3
In-Reply-To: <20050224155559.A727@unix-os.sc.intel.com>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
	<20050223171559.A23461@unix-os.sc.intel.com>
	<1109259722.3796.22.camel@localhost.localdomain>
	<20050224155559.A727@unix-os.sc.intel.com>
Message-ID: <Pine.LNX.4.58.0502250919100.5525@phoenix.infradead.org>

Keshavamurthy Anil S wrote:
> We can start from next monday, let me know what time you want to chat 
with
> me next monday.
I offer to keep you work public as the community might assist you. 
Furthermore, you probably may use the existing JFFS3 design document and 
to add your xattr design there.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From dedekind at infradead.org  Fri Feb 25 04:31:44 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 25 Feb 2005 09:31:44 +0000 (GMT)
Subject: NAND Driver skeleton?
In-Reply-To: <20050224231739.LCON24441.mxfep03.bredband.com@mxfep03>
References: <20050224231739.LCON24441.mxfep03.bredband.com@mxfep03>
Message-ID: <Pine.LNX.4.58.0502250931370.5525@phoenix.infradead.org>

extabe at bredband.net wrote:
> Hi all!
> I will make a new NAND board driver for our own hardware. Is there a 
good and basic driver whitch I can start from?
> I saw drivers/mtd/nand/skeleton was mentioned in the "MTD NAND Driver 
Programming Interface" manual, but I cant find the skeleton anyware.
> 
I don't know about drivers/mtd/nand/skeleton, but IMO nand_base.c contains 
good enough "skeleton" comprised on default handlers of NAND operations.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From tglx at linutronix.de  Fri Feb 25 04:39:09 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 25 Feb 2005 10:39:09 +0100
Subject: NAND Driver skeleton?
In-Reply-To: <Pine.LNX.4.58.0502250931370.5525@phoenix.infradead.org>
References: <20050224231739.LCON24441.mxfep03.bredband.com@mxfep03>
	<Pine.LNX.4.58.0502250931370.5525@phoenix.infradead.org>
Message-ID: <1109324349.3033.2.camel@lap02.tec.linutronix.de>

On Fri, 2005-02-25 at 10:31, Artem B. Bityuckiy wrote:
> extabe at bredband.net wrote:
> > Hi all!
> > I will make a new NAND board driver for our own hardware. Is there a 
> good and basic driver whitch I can start from?
> > I saw drivers/mtd/nand/skeleton was mentioned in the "MTD NAND Driver 
> Programming Interface" manual, but I cant find the skeleton anyware.
> > 
> I don't know about drivers/mtd/nand/skeleton, but IMO nand_base.c contains 
> good enough "skeleton" comprised on default handlers of NAND operations.

Na, nand_base.c is not a skeleton for a board driver.

I never came around to hack the skeleton driver as I wanted to do it
with platform_device support.

Use one of the simple drivers like  edb7312.c or autcpu12.c as
reference.

tglx





From tglx at linutronix.de  Fri Feb 25 04:51:45 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 25 Feb 2005 10:51:45 +0100
Subject: xattr support  for JFFS3
In-Reply-To: <20050224155559.A727@unix-os.sc.intel.com>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
	<20050223171559.A23461@unix-os.sc.intel.com>
	<1109259722.3796.22.camel@localhost.localdomain>
	<20050224155559.A727@unix-os.sc.intel.com>
Message-ID: <1109325105.3033.10.camel@lap02.tec.linutronix.de>

On Fri, 2005-02-25 at 00:56, Keshavamurthy Anil S wrote:
> On Thu, Feb 24, 2005 at 04:42:02PM +0100, Lorenzo Hern?ndez Garc?a-Hierro wrote:
> > I've read the tech. specs. of JFFS2 as David recommended to me, so, we
> > should separate two possible solutions:
> Can you please point me to the same spec.
> > 
> > 	- use a new node type(s)     <- what David likes (& wants AFAIK)
> > 	- use reiserfs style-storage <- what I have done partially

I backup Davids POV. xattrs should go into new node type(s) rather than
into the reiser style "everything is a directory" approach. It's an ugly
hack. I prefer designed functionality over the patchwork approach. I
know that it will take more time, but it will fit better and will be
easier to maintain.

tglx





From krom at dgt-lab.com.pl  Fri Feb 25 06:52:12 2005
From: krom at dgt-lab.com.pl (Wojciech Kromer)
Date: Fri, 25 Feb 2005 12:52:12 +0100
Subject: AMD S29GL512N 
Message-ID: <421F116C.2080803@dgt-lab.com.pl>

is this chip supported by MTD?

where can i find comlplete chip compability list?



From narinder at kritikalsolutions.com  Fri Feb 25 10:05:05 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Fri, 25 Feb 2005 20:35:05 +0530
Subject: JFFS2 CRC err
Message-ID: <421F3EA1.5040506@kritikalsolutions.com>

Dear Mr, Matthew,

             I have been working on Atmel's AT91RM9200DK board, which is 
using serial dataflash AT45DB62. I have created a JFFS2 partition on the 
device to store my filesystem. I have been able to mount the partition 
succesfully but when i do my read/write operations sometimes i get CRC 
errors. Here are the steps that i am following

1) Using kernel linux-2.4.26 patched with 2.4.26-vrs1
2) Partitioned the dataflash into 3 parts i,e 2 MB, 3MB and 3MB by 
specifying it in the driver code in at91_dataflash.c
3) booted the system and the erased the partitions . Last partition is 
my filesystem partition, so i erased it using -j option which makes it 
jffs2. Now i mounted the last partition as "mount -t jffs2 
/dev/mtdblock/2 /tmp/" and it mounts succefully and then i copy out my 
required files in this directory. And if i run my application now it 
runs successfully without any problem. Even if i kill my application and 
launch it again it run successfully . But if i do an unmount once and 
try the same procedure of mounting again and running the application it 
shows me an error

           Data CRC 0xABCD != calculated CRC 0xWXYZ

             Please let me know where i am going wrong ? and what was 
the kernel and patch used by you ?

Narinder




From gjohnson at lanl.gov  Fri Feb 25 11:48:02 2005
From: gjohnson at lanl.gov (Greg Johnson)
Date: Fri, 25 Feb 2005 09:48:02 -0700
Subject: MTD for Intel 28F320C3B BIOS flash?
In-Reply-To: <20050224175552.GR3347@durango.c3.lanl.gov>
References: <20050224175552.GR3347@durango.c3.lanl.gov>
Message-ID: <20050225164802.GA9612@durango.c3.lanl.gov>

On Thu, Feb 24, 2005 at 05:55:52PM +0000, Greg Johnson wrote:
> Hi,
> 
> I would like to be able to update the BIOS of a bunch of Intel SE7520JR2
> motherboards from Linux.  According to the spec for this board, it has a
> Intel 28F320C3B flash chip.  
> 
> What would be required to support this under Linux MTD?  Grepping the
> source reveals references to Intel 28F320B3 chips.  Are these supported?
> If so, how similar are they?  I'm happy to read the spec and write code,
> but I need a little direction first.

Ok, I was able to get the 28F320C3B to work as an MTD device by adding
the appropriate entry to jedec_table[] in jedec_probe.c:


diff -ur linux-2.6.10/drivers/mtd/chips/jedec_probe.c linux-2.6.10-fix/drivers/mtd/chips/jedec_probe.c
--- linux-2.6.10/drivers/mtd/chips/jedec_probe.c        2004-12-24 16:35:40.000000000 -0500
+++ linux-2.6.10-fix/drivers/mtd/chips/jedec_probe.c    2005-02-24 19:34:20.790309335 -0500
@@ -101,6 +101,7 @@
 #define I28F160B3B     0x8891
 #define I28F320B3T     0x8896
 #define I28F320B3B     0x8897
+#define I28F320C3B     0x88c5
 #define I28F640B3T     0x8898
 #define I28F640B3B     0x8899
 #define I82802AB       0x00ad
@@ -1018,6 +1019,20 @@
                }
        }, {
                .mfr_id         = MANUFACTURER_INTEL,
+               .dev_id         = I28F320C3B,
+               .name           = "Intel 28F320C3B",
+               .uaddr          = {
+                       [1] = MTD_UADDR_UNNECESSARY,    /* x16 */
+               },
+               .DevSize        = SIZE_4MiB,
+               .CmdSet         = P_ID_INTEL_STD,
+               .NumEraseRegions= 2,
+               .regions        = {
+                       ERASEINFO(0x02000, 8),
+                       ERASEINFO(0x10000, 63),
+               }
+       }, {
+               .mfr_id         = MANUFACTURER_INTEL,
                .dev_id         = I28F320B3T,
                .name           = "Intel 28F320B3T",
                .uaddr          = {

The parameters seem to be correct from the specs including the regions
and sizes.  

With this patch, I am able to read the entire 4MB of the device (using
mtdchar), and the resulting file appears to contain valid BIOSes.
However, I can only write to half of the chip, i.e. 2MB.  I believe that
this is because the BIOS does "rolling updates".  The flash chip
contains two copies of the BIOS.  The flash chip is 4MB, and the BIOS
image is 2MB.  When updating, the active BIOS is saved, and the new BIOS
is written to the other "partition".  Afterwards, a flag is set
somewhere telling the hardware which is the active partition to boot
from.  If for some reason the new BIOS is bad, the system falls back to
the old one.

In any case, I am able to update the inactive partition (with flashcp),
but don't know how to set the flag to make it active.  Any thoughts on
how to do this?  Alternatively, if I could write to both partitions that
would work.  Maybe something to do with locking?

Thanks for any help,

Greg



From dedekind at infradead.org  Fri Feb 25 14:14:51 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 25 Feb 2005 19:14:51 +0000 (GMT)
Subject: JFFS3 & checksum
Message-ID: <Pine.LNX.4.58.0502251912400.13994@phoenix.infradead.org>

Hello,

Looks like we've completed the JFFS3 checksum discussions. I've put the 
summary to the JFFS3 design issues. Please, review and make comments.

(http://www.linux-mtd.infradead.org/tech/JFFS3design/index.html
or 
http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf)

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From craigv at voxware.com  Fri Feb 25 16:40:40 2005
From: craigv at voxware.com (Craig A. Vanderborgh)
Date: Fri, 25 Feb 2005 16:40:40 -0500
Subject: JFFS2 Kernel Panic w/Xscale (PXA255) & 2.6.10
Message-ID: <421F9B58.60109@voxware.com>

Hello All:

This problem was recently reported in the mtd mailing list thread "Oops 
vanilla 2.6.10" by Konstantin Kletschke.  However, there was no 
resolution that I could see, so I am reporting it again in hopes that 
some mtd guru might take pity on us.

Our platform is a PXA-255 based SBC.  It is running kernel 2.6.10 
*extremely* well, with one exception - when accessing a VIRGIN jffs2 
filesystem, we get a kernel panic.  We cannot get past this unless we 
reload our 2.4.27 kernel and let it do the initial JFFS2 setup stuff.  
After reloading kernel 2.6.10, everything is then okay.  Just the 
uninitialized JFFS2 is a problem.  The JFFS2 error(s) and the KP should 
look familiar:

.
.
.
mice: PS/2 mouse device common for all mice
PXA Multimedia Card Interface Driver
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
mmcblk0: mmc0:0001 IFX032 31360KiB
 mmcblk0:<7>bound device 'mmc0:0001' to driver 'mmcblk'
EEEEEK. jffs2_mark_node_obsolete called with NULL node
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: f5 [#1]
Modules linked in:
CPU: 0
PC is at jffs2_build_remove_unlinked_inode+0x30/0xec
LR is at 0x1
pc : [<c00ccbd0>]    lr : [<00000001>]    Not tainted
sp : c0391d1c  ip : 60000093  fp : c0391d3c
r10: c7d9e8ac  r9 : c7d9e8c4  r8 : 00000000
r7 : c7d9e800  r6 : c0391d40  r5 : c7ded814  r4 : 00000000
r3 : c01dbd8c  r2 : 00000000  r1 : 0000d3a8  r0 : 0000003a
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: 397F  Table: A0004000  DAC: 0000001D
Process swapper (pid: 1, stack limit = 0xc0390190)
Stack: (0xc0391d1c to 0xc0392000)
1d00:                                                                
c7ded814
1d20: 00000000 c7d9e800 c0391d44 00000000 c0391d68 c0391d40 c00cc9f8 
c00ccbac
1d40: 00000000 00000000 c7d9e894 c7d9e89c c7d9e8a4 c7d9e8b4 c7d9e8bc 
c0391db0
1d60: c0391d6c c00ccf38 c00cc820 c7d9e8f8 c7d9e800 c7d9e8dc c7d9e8d4 
c7d9e8cc
1d80: c7d9e8ec c00dbf6c 00040000 c7d9e800 00000000 c7d9e600 c7d49600 
00000000
1da0: 00000000 c0391dd4 c0391db4 c00cec58 c00ccd18 c7d9e600 c7d9e800 
00008000
1dc0: 00000000 c7d49600 c0391df8 c0391dd8 c00cf2ac c00ceb34 ffffffea 
00000002
1de0: c7db4000 00008000 c01e2b78 c0391e68 c0391dfc c00cf500 c00cf220 
c7d49600
1e00: c0372554 c7d42c3c c0375600 c0391e5c c0391e64 c0375600 00000001 
00000001
1e20: 00000000 0000000a c03752a0 c7da05e0 c7db4000 00008000 00000000 
c0391e68
1e40: c0391e4c c03752a0 c7db4000 fffffff4 c01e2b78 00008000 00000000 
c0391e90
1e60: c0391e6c c006fd54 c00cf374 ffffffff c7db4000 00000000 00008000 
c0391ec8
1e80: 00000000 c0391eb8 c0391e94 c00851c0 c006fd00 00008000 00000000 
c7db3000
1ea0: 00000000 c7db4000 c0391ec8 c0391f30 c0391ebc c0085860 c0085148 
c7db4000
1ec0: 00000000 c7db2000 c0372554 c0375600 c0053760 00000000 c01ac62c 
00000001
1ee0: 00000001 00000000 00000000 00000000 c0391f0c c0391f00 c004ec30 
00001000
1f00: c0391f30 c0391f10 00000000 00000000 c01ac62c c7db3000 00008000 
00000000
1f20: 00000000 c0391f64 c0391f34 c0085c88 c008571c 00000000 00000000 
c7db4000
1f40: c7db2000 c0382000 c0382000 00008000 c01ac62c c0223e08 c0391f7c 
c0391f68
1f60: c000900c c0085bf0 00000000 c0382000 c0391fc0 c0391f80 c00090f0 
c0008fe8
1f80: c0044530 6264746d 01f00002 c001cae0 c0218b3c 00000000 00000000 
00000000
1fa0: 00000000 c001cae0 c0218b3c 00000000 00000000 c0391fe0 c0391fc4 
c000948c
1fc0: c00090a4 00000000 c01ac450 00000000 00000000 c0391ff4 c0391fe4 
c001f250
1fe0: c00093f4 00000000 00000000 c0391ff8 c0032644 c001f20c 00000000 
00000000
Backtrace:
[<c00ccba0>] (jffs2_build_remove_unlinked_inode+0x0/0xec) from 
[<c00cc9f8>] (jff
s2_build_filesystem+0x1e4/0x38c)
 r8 = 00000000  r7 = C0391D44  r6 = C7D9E800  r5 = 00000000
 r4 = C7DED814
[<c00cc814>] (jffs2_build_filesystem+0x0/0x38c) from [<c00ccf38>] 
(jffs2_do_moun
t_fs+0x22c/0x274)
 r8 = C7D9E8BC  r7 = C7D9E8B4  r6 = C7D9E8A4  r5 = C7D9E89C
 r4 = C7D9E894
[<c00ccd0c>] (jffs2_do_mount_fs+0x0/0x274) from [<c00cec58>] 
(jffs2_do_fill_supe
r+0x130/0x238)
[<c00ceb28>] (jffs2_do_fill_super+0x0/0x238) from [<c00cf2ac>] 
(jffs2_get_sb_mtd
+0x98/0xf8)
 r8 = C7D49600  r7 = 00000000  r6 = 00008000  r5 = C7D9E800
 r4 = C7D9E600
[<c00cf214>] (jffs2_get_sb_mtd+0x0/0xf8) from [<c00cf500>] 
(jffs2_get_sb+0x198/0
x1d4)
 r8 = C01E2B78  r7 = 00008000  r6 = C7DB4000  r5 = 00000002
 r4 = FFFFFFEA
[<c00cf368>] (jffs2_get_sb+0x0/0x1d4) from [<c006fd54>] 
(do_kern_mount+0x60/0x10
8)
[<c006fcf4>] (do_kern_mount+0x0/0x108) from [<c00851c0>] 
(do_new_mount+0x84/0xb8
)
[<c008513c>] (do_new_mount+0x0/0xb8) from [<c0085860>] 
(do_mount+0x150/0x16c)
[<c0085710>] (do_mount+0x0/0x16c) from [<c0085c88>] (sys_mount+0xa4/0xe8)
[<c0085be4>] (sys_mount+0x0/0xe8) from [<c000900c>] 
(do_mount_root+0x30/0xbc)
 r8 = C0223E08  r7 = C01AC62C  r6 = 00008000  r5 = C0382000
 r4 = C0382000
[<c0008fdc>] (do_mount_root+0x0/0xbc) from [<c00090f0>] 
(mount_block_root+0x58/0
x124)
 r4 = C0382000
[<c0009098>] (mount_block_root+0x0/0x124) from [<c000948c>] 
(prepare_namespace+0
xa4/0xe8)
 r8 = 00000000  r7 = 00000000  r6 = C0218B3C  r5 = C001CAE0
 r4 = 00000000
[<c00093e8>] (prepare_namespace+0x0/0xe8) from [<c001f250>] (init+0x50/0xf0)
 r6 = 00000000  r5 = 00000000  r4 = C01AC450
[<c001f200>] (init+0x0/0xf0) from [<c0032644>] (do_exit+0x0/0x40c)
 r4 = 00000000
Code: 0a000005 e1a01004 e1a00007 ebffe40e (e5944000)
 <0>Kernel panic - not syncing: Attempted to kill init!

Is there in fact a fix for this problem?  Please advise.

Thanks in advance
craig vanderborgh
voxware incorporated



From nico at cam.org  Fri Feb 25 17:04:08 2005
From: nico at cam.org (Nicolas Pitre)
Date: Fri, 25 Feb 2005 17:04:08 -0500 (EST)
Subject: JFFS2 Kernel Panic w/Xscale (PXA255) & 2.6.10
In-Reply-To: <421F9B58.60109@voxware.com>
References: <421F9B58.60109@voxware.com>
Message-ID: <Pine.LNX.4.62.0502251700220.25966@localhost.localdomain>

On Fri, 25 Feb 2005, Craig A. Vanderborgh wrote:

> Our platform is a PXA-255 based SBC.  It is running kernel 2.6.10 *extremely*
> well, with one exception - when accessing a VIRGIN jffs2 filesystem, we get a
> kernel panic.  We cannot get past this unless we reload our 2.4.27 kernel and
> let it do the initial JFFS2 setup stuff.  After reloading kernel 2.6.10,
> everything is then okay.  Just the uninitialized JFFS2 is a problem.

Are you using L18 Intel flash? If so you should consider applying the 
latest fixes from MTD CVS.


Nicolas



From craigv at voxware.com  Fri Feb 25 17:06:48 2005
From: craigv at voxware.com (Craig A. Vanderborgh)
Date: Fri, 25 Feb 2005 17:06:48 -0500
Subject: JFFS2 Kernel Panic w/Xscale (PXA255) & 2.6.10
In-Reply-To: <Pine.LNX.4.62.0502251700220.25966@localhost.localdomain>
References: <Pine.LNX.4.62.0502251700220.25966@localhost.localdomain>
Message-ID: <421FA178.1070103@voxware.com>

Nicolas Pitre wrote:

>On Fri, 25 Feb 2005, Craig A. Vanderborgh wrote:
>
>  
>
>>Our platform is a PXA-255 based SBC.  It is running kernel 2.6.10
>>    
>>
>*extremely*
>  
>
>>well, with one exception - when accessing a VIRGIN jffs2 filesystem,
>>    
>>
>we get a
>  
>
>>kernel panic.  We cannot get past this unless we reload our 2.4.27
>>    
>>
>kernel and
>  
>
>>let it do the initial JFFS2 setup stuff.  After reloading kernel
>>    
>>
>2.6.10,
>  
>
>>everything is then okay.  Just the uninitialized JFFS2 is a problem.
>>    
>>
>
>Are you using L18 Intel flash? If so you should consider applying the 
>latest fixes from MTD CVS.
>
>
>Nicolas
>
>  
>
Wow, sorry I forgot to mention this - we're using Intel K3 Strataflash - 
it's
2 32 MB K3 chips interleaved into one bank.

Regards,
craig vanderborgh
voxware incorporated



From dedekind at infradead.org  Sat Feb 26 05:16:25 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Sat, 26 Feb 2005 13:16:25 +0300
Subject: JFFS2 Kernel Panic w/Xscale (PXA255) & 2.6.10
In-Reply-To: <421F9B58.60109@voxware.com>
References: <421F9B58.60109@voxware.com>
Message-ID: <1109412985.4688.3.camel@sauron.oktetlabs.ru>

On Fri, 2005-02-25 at 16:40 -0500, Craig A. Vanderborgh wrote:
> Hello All:
> 
> This problem was recently reported in the mtd mailing list thread "Oops 
> vanilla 2.6.10" by Konstantin Kletschke.  However, there was no 
> resolution that I could see, so I am reporting it again in hopes that 
> some mtd guru might take pity on us.
> 
> Our platform is a PXA-255 based SBC.  It is running kernel 2.6.10 
> *extremely* well, with one exception - when accessing a VIRGIN jffs2 
> filesystem, we get a kernel panic.  We cannot get past this unless we 
> reload our 2.4.27 kernel and let it do the initial JFFS2 setup stuff.  
> After reloading kernel 2.6.10, everything is then okay.  Just the 
> uninitialized JFFS2 is a problem.  The JFFS2 error(s) and the KP should 
> look familiar:
> 
Hello Craig,

the first steps we ask everybody to do are:
1. try the latest MTD snapshot (download it from CVS);
2. if the problem hasn't gone, enable the JFFS2 debugging messages
(level 1) and send the JFFS2 output.

Please, do it.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From ptagliavini at flp-consultant.it  Sat Feb 26 11:06:47 2005
From: ptagliavini at flp-consultant.it (Paolo Tagliavini)
Date: Sat, 26 Feb 2005 17:06:47 +0100
Subject: writing jffs2 file system trought JTAG
Message-ID: <42209E97.2070201@flp-consultant.it>

Dear all ,

I'm working on ARM920 based embedded system. Linux kernel is 2.4.20.
This system mount a 64 Mbyte Samsung NAND flash.
My simple questions are:
    Is it  possible write in nand flash  the jffs2 image , made with 
mkfs.jffs2 , using JTAG interface ?
    Is there any way to handle nand bad block dowloadind jffs2 image 
trought JTAG interface ?

Best regards

Paolo Tagliavini




From tglx at linutronix.de  Sat Feb 26 11:30:56 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 26 Feb 2005 17:30:56 +0100
Subject: writing jffs2 file system trought JTAG
In-Reply-To: <42209E97.2070201@flp-consultant.it>
References: <42209E97.2070201@flp-consultant.it>
Message-ID: <1109435457.31108.21.camel@tglx.tec.linutronix.de>

On Sat, 2005-02-26 at 17:06 +0100, Paolo Tagliavini wrote:
> Dear all ,
> 
> I'm working on ARM920 based embedded system. Linux kernel is 2.4.20.
> This system mount a 64 Mbyte Samsung NAND flash.
> My simple questions are:
>     Is it  possible write in nand flash  the jffs2 image , made with 
> mkfs.jffs2 , using JTAG interface ?
>     Is there any way to handle nand bad block dowloadind jffs2 image 
> trought JTAG interface ?

Read

http://www.linux-mtd.infradead.org/tech/faq.html

The section "Must my bootloader be aware of NAND FLASH ?" has all the
answers. The requirements for JTAG programming are the same as for
bootloaders.

tglx





From dedekind at infradead.org  Sat Feb 26 14:19:53 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Sat, 26 Feb 2005 22:19:53 +0300
Subject: [BUGFIX] JFFS2 NOR problem
Message-ID: <1109445593.13512.1.camel@sauron.oktetlabs.ru>

Hello,

I've detected major JFFS2 bug and have attached the fix. The bug seems
to be NOR-only. I believe everybody who uses JFFS2 on top of NOR flash
should have this bug fixed.

The brief problem description:

JFFS2 clears the JFFS2_SB_FLAG_MOUNTING (c-flags) superblock flag after
it has done the 1st filesystem build pass. But it still has non NULL
ic->scan_dents pointers which are actually assigned NULL at the very end
of the file system build procedure. Next FS build passes call the
jffs2_mark_node_obsolete() function which, in turn, utilizes the
jffs2_raw_ref_to_ic() function which *requires* ic->scan_dents = NULL.

This might cause infinite loops and oopses.

I think it is safe to clear the JFFS2_SB_FLAG_MOUNTING flag at the end
of JFFS2 filesystem build routine. Comments?

P.S. Possibly, the patch will fix Konstantin Kletschke's and Craig A.
Vanderborgh's problems. Guys, please try.



--- build.c     2005-02-26 22:08:17.503657749 +0300
+++ build.c_fixed       2005-02-26 22:07:55.806278357 +0300
@@ -116,7 +116,6 @@
                        cond_resched();
                }
        }
-       c->flags &= ~JFFS2_SB_FLAG_MOUNTING;

        D1(printk(KERN_DEBUG "Pass 1 complete\n"));

@@ -164,6 +163,8 @@
                ic->scan_dents = NULL;
                cond_resched();
        }
+       c->flags &= ~JFFS2_SB_FLAG_MOUNTING;
+
        D1(printk(KERN_DEBUG "Pass 3 complete\n"));
        D2(jffs2_dump_block_lists(c));


-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From craigv at voxware.com  Sat Feb 26 22:43:52 2005
From: craigv at voxware.com (Craig A. Vanderborgh)
Date: Sat, 26 Feb 2005 22:43:52 -0500
Subject: [BUGFIX] JFFS2 NOR problem
In-Reply-To: <1109444967.4688.19.camel@sauron.oktetlabs.ru>
References: <1109444967.4688.19.camel@sauron.oktetlabs.ru>
Message-ID: <422141F8.7050707@voxware.com>

Artem B. Bityuckiy wrote:

>Hello,
>
>I've detected major JFFS2 bug and have attached the fix. The bug seems
>to be NOR-only. I believe everybody who uses JFFS2 on top of NOR flash
>should have this bug fixed.
>
>The brief problem description:
>
>JFFS2 clears the JFFS2_SB_FLAG_MOUNTING (c-flags) superblock flag after
>it has done the 1st filesystem build pass. But it still has non NULL
>ic->scan_dents pointers which are actually assigned NULL at the very end
>of the file system build procedure. Next FS build passes call the
>jffs2_mark_node_obsolete() function which, in turn, utilizes the
>jffs2_raw_ref_to_ic() function which *requires* ic->scan_dents = NULL.
>
>This might cause infinite loops and oopses.
>
>I think it is safe to clear the JFFS2_SB_FLAG_MOUNTING flag at the end
>of JFFS2 filesystem build routine. Comments?
>
>P.S. Possibly, the patch will fix Konstantin Kletschke's and Craig A.
>Vanderborgh's problems. Guys, please try.
>
>  
>
>------------------------------------------------------------------------
>
>--- build.c	2005-02-26 22:08:17.503657749 +0300
>+++ build.c_fixed	2005-02-26 22:07:55.806278357 +0300
>@@ -116,7 +116,6 @@
> 			cond_resched();
> 		}
> 	}
>-	c->flags &= ~JFFS2_SB_FLAG_MOUNTING;
> 
> 	D1(printk(KERN_DEBUG "Pass 1 complete\n"));
> 
>@@ -164,6 +163,8 @@
> 		ic->scan_dents = NULL;
> 		cond_resched();
> 	}
>+	c->flags &= ~JFFS2_SB_FLAG_MOUNTING;
>+
> 	D1(printk(KERN_DEBUG "Pass 3 complete\n"));
> 	D2(jffs2_dump_block_lists(c));
> 
>  
>
Hello Artem:

Thank you for taking pity on us :^)

I have succeeded in resolving the oops that I reported in 2 different ways:

1. I applied your patch to the "vanilla" 2.6.10 sources.  To test, I 
compiled and
installed the modified kernel, and had it mount a large (~7MB) JFFS2 
root filesystem
that was "virginal".  This works.  Previously, it was this very same 
testing procedure
that produced a kernel oops "every time".

2. Before receiving your patch, I back-ported the 2.6.11-rc5 sources for 
fs/jffs2
(and the required related header files). I tested using the same 
procedure mentioned
above, and this also works.

Would you please comment on this:  which solution do you think is the 
better one?  Now that we have the newer MTD code working in the 
otherwise "vanilla" 2.6.10 kernel, is this the best solution?  Or is the 
build.c patch solution the safer bet for us?

Please advise.

Thanks a lot for looking into this, we REALLY appreciate it and it's 
great to be fully operational on kernel 2.6!!

Best regards,
craig vanderborgh
voxware incorporated
The 4th Reich



From dwmw2 at infradead.org  Sun Feb 27 04:40:41 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 27 Feb 2005 09:40:41 +0000
Subject: [BUGFIX] JFFS2 NOR problem
In-Reply-To: <1109445593.13512.1.camel@sauron.oktetlabs.ru>
References: <1109445593.13512.1.camel@sauron.oktetlabs.ru>
Message-ID: <1109497241.27107.10.camel@localhost.localdomain>

On Sat, 2005-02-26 at 22:19 +0300, Artem B. Bityuckiy wrote:
>I think it is safe to clear the JFFS2_SB_FLAG_MOUNTING flag at the end
>of JFFS2 filesystem build routine. Comments?

Didn't we move it from there to where it is now quite recently for other
reasons?

-- 
dwmw2




From dwmw2 at infradead.org  Sun Feb 27 05:30:33 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 27 Feb 2005 10:30:33 +0000
Subject: [PATCH] JFFS[23] slab corruption
In-Reply-To: <41DBF5F2.5040208@yandex.ru>
References: <Pine.LNX.4.58.0501031923110.14981@phoenix.infradead.org>
	<1104924806.5547.49.camel@baythorne.infradead.org>
	<41DBF5F2.5040208@yandex.ru>
Message-ID: <1109500233.27107.20.camel@localhost.localdomain>

On Wed, 2005-01-05 at 17:13 +0300, Artem B. Bityuckiy wrote:
>I'd like to do some analysis. David, could you please comment my notes:
>
>1. Consider removing ic from mark_node_obsolete (NOR only).
>When ic may have no nodes?

ic will have no nodes when they've all been actually removed or marked
obsolete -- that's either in mark_node_obsolete() in the case of NOR
flash, or somewhere in erase.c in the case of NAND.

Until all the nodes are actually gone, we mustn't re-use the old inode
number for new inodes, so the ic has to stay in the list.

>a). When the inode is deleted. In this case all it's nodes are marked 
>obsolete (thankfully we may mark them obsolete physically). This happens 
>when ic->nlink == 0 and last iput() is called.

On NOR, yes. If !jffs2_can_mark_obsolete() it happens only later.

>b). I'm not sure, may be temporary it may have no valid nodes. I mean 
>some transient state when, for example, there is one node A, and another 
>node B is added, and B obsoletes A. Then possibly A will be first marked 
>obsolete, then B will be added. Between these two operations, ic may 
>have no nodes. I'm not sure, but it seems in the current implementation 
>in such situations A will be always added first. So, mark_node_obsolete 
>should not delete the ic in such temporary states.

No, that'll never happen because it wouldn't be powerfail-safe. We can't
ever obsolete an old node before writing the new one.

>But why do mark_node_obsolete code delete the correspondent ic if there 
>is no nodes left? It should not delete ic because of b) . Moreover, 
>conceptually it is not its work - the last iput handler should do that 
>(do_clean_inode() may be).

>Conclusions: a) remove that peace of code from the mark_node_obsolete. 
>b) be sure ic will be deleted by somebody else.

Perhaps. But I think we have to check for INO_STATE_READING and
INO_STATE_CLEARING even when we're removing the ic from erase.c, to
prevent a similar failure. And so I think that we have to do the check
when we leave read_inode() or clear_inode() (or have some other way of
postponing it). So since we need all this to handle the erase case, we
might as well just do the same in mark_node_obsolete() too.

>2. Conceder jffs2_remove_node_refs_from_ino_list() function. It deletes 
>ic if there are no nodes...
>
>At first this is only valid for NAND. In case of NOR obsolete nodes are 
>removed from the per-inode list as soon as they marked obsolete.
>
>In case of nand our live is complicated because we can not mark nodes 
>obsolete physically. And deletion/deleted direntries bring us 
>misfortune. We must keep track of them in the per-inode list and only 
>remove them when the last instance of the deleted direntry has been 
>erased...
>
>But before the erase code deletes ic, it should be sure there are no 
>open files (iget count = 0) and ic->nlink = 0. But it seems it does not 
>do so. ... May continue reasoning, but want to be sure I understand 
>thing correctly. So, will wait for comments.

You'll never delete ic for a file which is open because it can't be
actually deleted when it's open, and until it's actually deleted it'll
always have at least one node.

-- 
dwmw2




From lorenzo at gnu.org  Thu Feb 24 10:42:02 2005
From: lorenzo at gnu.org (Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?=)
Date: Thu, 24 Feb 2005 16:42:02 +0100
Subject: xattr support  for JFFS3
In-Reply-To: <20050223171559.A23461@unix-os.sc.intel.com>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
	<20050223171559.A23461@unix-os.sc.intel.com>
Message-ID: <1109259722.3796.22.camel@localhost.localdomain>

El mi?, 23-02-2005 a las 17:15 -0800, Keshavamurthy Anil S escribi?:
> On Wed, Feb 23, 2005 at 06:58:19PM -0600, Josh Boyer wrote:
> > On Wed, 2005-02-23 at 15:31 -0800, Keshavamurthy, Anil S wrote:
> > > Hi,
> > > 	I am new to this mailing list but would like to contribute to
> > > xattr for flash file system. While looking at the archive seems like
> > > jffs2 is just a bug fix only and any new feature development should go
> > > to jffs3. So here is my question.
> > 
> > xattr support seems to be a popular topic these days.  You might want to
> > take a look at this thread on the lkml:
> > 
> > http://lkml.org/lkml/2005/2/22/85
> > 
> > Lorenzo already has something started.  Perhaps the two of you could
> > work together.
> Sure, I will take a look at his patch and will work with him to
> get this feature into JFFS3.

Fine, it could be great if, apart of working together which would be a
pleasure for me, creating a work team for this.

I've read the tech. specs. of JFFS2 as David recommended to me, so, we
should separate two possible solutions:

	- use a new node type(s)     <- what David likes (& wants AFAIK)
	- use reiserfs style-storage <- what I have done partially

We need also a little road-map and to-do list to know what exactly needs
to be done in each code "section" to achieve our goal.

Just let me know when do you want to start, I would like to talk with
you at #mtd in irc.freenode.org if it's possible.

Thanks in advance and for your interest,
Cheers.
-- 
Lorenzo Hern?ndez Garc?a-Hierro <lorenzo at gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050224/b88bc8e9/attachment.bin 

From lorenzo at gnu.org  Fri Feb 25 09:07:15 2005
From: lorenzo at gnu.org (Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?=)
Date: Fri, 25 Feb 2005 15:07:15 +0100
Subject: xattr support  for JFFS3
In-Reply-To: <20050224155559.A727@unix-os.sc.intel.com>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
	<20050223171559.A23461@unix-os.sc.intel.com>
	<1109259722.3796.22.camel@localhost.localdomain>
	<20050224155559.A727@unix-os.sc.intel.com>
Message-ID: <1109340435.18747.12.camel@localhost.localdomain>

El jue, 24-02-2005 a las 15:56 -0800, Keshavamurthy Anil S escribi?:
> Can you please point me to the same spec.

Sure ;)
http://sources.redhat.com/jffs2/jffs2.pdf
http://sources.redhat.com/jffs2/jffs2-html/

> Perfect.

http://wiki.tuxedo-es.org/tuxedo/JFFS2xattr/RoadMap

> We can start from next monday, let me know what time you want to chat with
> me next monday.

OK, we could meet in the #mtd channel (irc.freenode.org) at 20:10 CET.
Let me know if it's OK for you.

> thanks once again.

Thanks to you for your interest ;).

Cheers,
-- 
Lorenzo Hern?ndez Garc?a-Hierro <lorenzo at gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050225/75b76b26/attachment.bin 

From lorenzo at gnu.org  Fri Feb 25 09:08:58 2005
From: lorenzo at gnu.org (Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?=)
Date: Fri, 25 Feb 2005 15:08:58 +0100
Subject: xattr support  for JFFS3
In-Reply-To: <Pine.LNX.4.58.0502250919100.5525@phoenix.infradead.org>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
	<20050223171559.A23461@unix-os.sc.intel.com>
	<1109259722.3796.22.camel@localhost.localdomain>
	<20050224155559.A727@unix-os.sc.intel.com>
	<Pine.LNX.4.58.0502250919100.5525@phoenix.infradead.org>
Message-ID: <1109340538.18747.15.camel@localhost.localdomain>

El vie, 25-02-2005 a las 09:19 +0000, Artem B. Bityuckiy escribi?:
> I offer to keep you work public as the community might assist you. 
> Furthermore, you probably may use the existing JFFS3 design document and 
> to add your xattr design there.

That's what we are going to do, the development is going on JFFS3, and
of course I've read the specifications and design of JFFS2 at RH's JFFS2
site (thanks to David for pointing this out).

Thanks for the comments,
Cheers. 
-- 
Lorenzo Hern?ndez Garc?a-Hierro <lorenzo at gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050225/3ff5c3ed/attachment.bin 

From lorenzo at gnu.org  Fri Feb 25 09:12:34 2005
From: lorenzo at gnu.org (Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?=)
Date: Fri, 25 Feb 2005 15:12:34 +0100
Subject: xattr support  for JFFS3
In-Reply-To: <1109325105.3033.10.camel@lap02.tec.linutronix.de>
References: <44BDAFB888F59F408FAE3CC35AB47041014F9285@orsmsx409>
	<1109206700.8215.4.camel@windu.rchland.ibm.com>
	<20050223171559.A23461@unix-os.sc.intel.com>
	<1109259722.3796.22.camel@localhost.localdomain>
	<20050224155559.A727@unix-os.sc.intel.com>
	<1109325105.3033.10.camel@lap02.tec.linutronix.de>
Message-ID: <1109340754.18747.20.camel@localhost.localdomain>

El vie, 25-02-2005 a las 10:51 +0100, Thomas Gleixner escribi?:
> I backup Davids POV. xattrs should go into new node type(s) rather than
> into the reiser style "everything is a directory" approach. It's an ugly
> hack. I prefer designed functionality over the patchwork approach. I
> know that it will take more time, but it will fit better and will be
> easier to maintain.

Me too, ignore my patches that use the weird reiserfs-based
implementation, among that they wouldn't compile yet :)

And yes, we can't break ABI/API compatibility by adding ugly hacks, so,
I will do as David commented, will try to start some new work on it this
weekend, but I'm still busy with exams and other stuff.

Thanks again for the comments,
Cheers.
PS: Those who are interested in this and also in contributing and
working together to get it, would write their names and contact info at
http://wiki.tuxedo-es.org/tuxedo/JFFS2xattr ?
-- 
Lorenzo Hern?ndez Garc?a-Hierro <lorenzo at gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050225/404ddc7a/attachment.bin 

From dedekind at infradead.org  Sun Feb 27 06:26:20 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Sun, 27 Feb 2005 14:26:20 +0300
Subject: [BUGFIX] JFFS2 NOR problem
In-Reply-To: <422141F8.7050707@voxware.com>
References: <1109444967.4688.19.camel@sauron.oktetlabs.ru>
	<422141F8.7050707@voxware.com>
Message-ID: <1109503580.13512.30.camel@sauron.oktetlabs.ru>

Craig, 

I've found that the patch I sent yesterday has defect which might cause
errors or at least lead to an inefficient behavior.

The problem is that if we have the JFFS2_SB_FLAG_MOUNTING flag set
during the entire FS build process we risk to loose proper blocks
accounting. Namely, jffs2_mark_node_obsolete() function moves blocks
between different lists, but this peace of code is skipped owing to the
JFFS2_SB_FLAG_MOUNTING flag.

New patch (attached) must be better. Comments?

On Sat, 2005-02-26 at 22:43 -0500, Craig A. Vanderborgh wrote:
> I have succeeded in resolving the oops that I reported in 2 different ways:
Good, I hope Konstantin Kletschke's problem will go away as well.

> Would you please comment on this:  which solution do you think is the 
> better one?  Now that we have the newer MTD code working in the 
> otherwise "vanilla" 2.6.10 kernel, is this the best solution?  Or is the 
> build.c patch solution the safer bet for us?
Well, I can't advice ably but I'd rather use CVS head albeit it is a bit
more dangerous. And last but not least, I'd like to stress - CVS head,
not 2.6.11-rc5 as its MTD snapshot doesn't have to be latest. You might
download the latest MTD snapshot and install it to your kernel
(patchin.sh utility). Refer to linux-mtd.infradead.org for more info.


On Sun, 2005-02-27 at 09:40 +0000, David Woodhouse wrote: 
> Didn't we move it from there to where it is now quite recently for other
> reasons?
Yes, we did. First the flag was set only around scan and we moved it 
lover to embrace the Pass 1 as well.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2_mount_fix-01.diff
Type: text/x-patch
Size: 3021 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050227/d4690484/attachment.bin 

From dedekind at infradead.org  Sun Feb 27 09:02:22 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Sun, 27 Feb 2005 17:02:22 +0300
Subject: [PATCH] JFFS[23] slab corruption
In-Reply-To: <1109500233.27107.20.camel@localhost.localdomain>
References: <Pine.LNX.4.58.0501031923110.14981@phoenix.infradead.org>
	<1104924806.5547.49.camel@baythorne.infradead.org>
	<41DBF5F2.5040208@yandex.ru>
	<1109500233.27107.20.camel@localhost.localdomain>
Message-ID: <1109512942.13512.44.camel@sauron.oktetlabs.ru>

On Sun, 2005-02-27 at 10:30 +0000, David Woodhouse wrote:
> ic will have no nodes when they've all been actually removed or marked
> obsolete -- that's either in mark_node_obsolete() in the case of NOR
> flash, or somewhere in erase.c in the case of NAND.
> 
> Until all the nodes are actually gone, we mustn't re-use the old inode
> number for new inodes, so the ic has to stay in the list.
> 
Well, I don't quite well remember why I asked that.

Now your patch looks sane for me. I've tried it with both NAND and NOR
and haven't seen something bad.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From rayl at mail.com  Sun Feb 27 13:10:12 2005
From: rayl at mail.com (Ray Lehtiniemi)
Date: Sun, 27 Feb 2005 11:10:12 -0700
Subject: [BUGFIX] JFFS2 NOR problem
In-Reply-To: <422141F8.7050707@voxware.com>
References: <1109444967.4688.19.camel@sauron.oktetlabs.ru>
	<422141F8.7050707@voxware.com>
Message-ID: <20050227181012.GA15280@mail.com>

On Sat, Feb 26, 2005 at 10:43:52PM -0500, Craig A. Vanderborgh wrote:
> Artem B. Bityuckiy wrote:
> 
> >Hello,
> >
> >I've detected major JFFS2 bug and have attached the fix. The bug seems
> >to be NOR-only. I believe everybody who uses JFFS2 on top of NOR flash
> >should have this bug fixed.

> Thanks a lot for looking into this, we REALLY appreciate it and it's 
> great to be fully operational on kernel 2.6!!


i have been experiencing this bug as well, and can confirm that the
patch to move "c->flags &= ~JFFS2_SB_FLAG_MOUNTING" seems to clear up
the panic for me.


however, there are still some issues... 


if i enable CONFIG_DEBUG_SLAB, i get this message a few seconds after
the filesystem is mounted:

   VFS: Mounted root (jffs2 filesystem).
   Freeing init memory: 84K
   Initializing random number generator... Slab corruption: start=c1475924, len=24
   Redzone: 0x5a2cf071/0x5a2cf071.
   Last user: [<c00fd468>](jffs2_mark_node_obsolete+0x1300/0x1648)
   010: 6b 6b 6b 6b 03 00 00 00
   Prev obj: start=c1475900, len=24
   Redzone: 0x170fc2a5/0x170fc2a5.
   Last user: [<c0102ac4>](jffs2_scan_make_ino_cache+0x34/0x7c)
   000: 00 00 00 00 34 be 47 c1 fc 68 47 c1 a1 00 00 00
   010: 01 00 00 00 03 00 00 00
   Next obj: start=c1475948, len=24
   Redzone: 0x170fc2a5/0x170fc2a5.
   Last user: [<c0102ac4>](jffs2_scan_make_ino_cache+0x34/0x7c)
   000: 00 00 00 00 7c be 47 c1 ec 65 47 c1 9f 00 00 00
   010: 01 00 00 00 03 00 00 00
   done.
   Starting network...

the boot process then appears to continue normally.



i had seen this message before applying the patch as well. i was able to
reproduce it as follows:

prior to trying this patch, i had determined that the panic occurred
while mounting a virgin (never-been-mounted) jffs2 root filesystem
while CONFIG_DEBUG_SLAB=y. if CONFIG_DEBUG_SLAB=n, the mount just
appeared to "work"... and then if i re-enabled slab debugging and
mounted the non-virgin jffs2 root, i would then see the above-mentioned
slab corruption message.

after applying the patch, i now proceed directly to the slab corruption
message, virgin fs or not.





i am running on a cirrus ep9302-based EDB9302 board. it has a non-intel
clone device on it, marked MT28F128J3:

   physmap flash device: 1000000 at 60000000
   phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
    Intel/Sharp Extended Query Table at 0x0031
   Using buffer write method
   cfi_cmdset_0001: Erase suspend on write enabled



my kernel is:

  - newest linux-cirrus bk tree
    - this tree is synced to linux-2.6.11-rc3
    - so it should contain russell's 2.6.11-rc1 pud_t slab corruption fix

  - mtd-snapshot-20050225.tar.bz2 has been applied using 'patchin.sh -j -c'

  - CONFIG_JFFS2_FS_DEBUG=1 (but i didn't see any extra output...)



my userspace is a 2005-02-26 svn checkout of buildroot,  using busybox
and uClibc snapshots.  my toolchain is also from buildroot, consisting
of binutils-2.15.91.0.2 and gcc-3.4.2. i replaced the standard mtd
download from debian with the mtd snapshot from linux.org.uk.



please let me know if i can provide any more info.



thanks

-- 
----------------------------------------------------------------------
     Ray L   <rayl at mail.com>



From dedekind at infradead.org  Sun Feb 27 13:31:55 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Sun, 27 Feb 2005 21:31:55 +0300
Subject: [BUGFIX] JFFS2 NOR problem
In-Reply-To: <20050227181012.GA15280@mail.com>
References: <1109444967.4688.19.camel@sauron.oktetlabs.ru>
	<422141F8.7050707@voxware.com>  <20050227181012.GA15280@mail.com>
Message-ID: <1109529115.13512.50.camel@sauron.oktetlabs.ru>

On Sun, 2005-02-27 at 11:10 -0700, Ray Lehtiniemi wrote:
> however, there are still some issues... 

I can't be completely certain but it is likely that your problem is the
same problem that I've observed about a month ago. Take a glimpse at:
http://lists.infradead.org/pipermail/linux-mtd/2005-January/011357.html

The discussion was stopped but has been resumed today. Please, follow
the thread if you're curious.

Here is a somewhat tweaked David's patch. I tried it and it looks like
it works pretty good. Please, try it together with my last mount fix.

P.S. We'll commit both patches to the CVS after you (and others) have
reported they are OK.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jff2_slab_fix-01.diff
Type: text/x-patch
Size: 3874 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050227/6f87d500/attachment.bin 

From rayl at mail.com  Sun Feb 27 17:44:20 2005
From: rayl at mail.com (Ray Lehtiniemi)
Date: Sun, 27 Feb 2005 15:44:20 -0700
Subject: [BUGFIX] JFFS2 NOR problem
In-Reply-To: <1109529115.13512.50.camel@sauron.oktetlabs.ru>
References: <1109444967.4688.19.camel@sauron.oktetlabs.ru>
	<422141F8.7050707@voxware.com> <20050227181012.GA15280@mail.com>
	<1109529115.13512.50.camel@sauron.oktetlabs.ru>
Message-ID: <20050227224420.GA19056@mail.com>

On Sun, Feb 27, 2005 at 09:31:55PM +0300, Artem B. Bityuckiy wrote:
> 
> I can't be completely certain but it is likely that your problem is the
> same problem that I've observed about a month ago. Take a glimpse at:
> http://lists.infradead.org/pipermail/linux-mtd/2005-January/011357.html

seems like it, yes.


> Here is a somewhat tweaked David's patch. I tried it and it looks like
> it works pretty good. Please, try it together with my last mount fix.
> 
> P.S. We'll commit both patches to the CVS after you (and others) have
> reported they are OK.

i have applied this patch against 2.6.11-rc3 + 20050225 mtd snapshot +
your previous patch, and it seems to cure both the oops with a virgin
fs and the slab corruption with a non-virgin fs.


thanks!

-- 
----------------------------------------------------------------------
     Ray L   <rayl at mail.com>



From prasadamkumar at yahoo.com  Sun Feb 27 23:57:01 2005
From: prasadamkumar at yahoo.com (prasadam kumar)
Date: Sun, 27 Feb 2005 20:57:01 -0800 (PST)
Subject: mtd cfi_cmdset_0001.c writing problem 
Message-ID: <20050228045701.31920.qmail@web11603.mail.yahoo.com>


 
 hai ,
   
   Thanks for response to my query, as u suggested i
checked 
the flash image with my original image, i found that
there is a 
some mismatch. Using fis it is writing properly to
flash but when 
i am trying to write through mtd drivers (here
versiong is 2.4.19)
it is changing some bits and writing to the flash, I
tryed a lot but 
i am unable to find why it is behaving like that. i am
using 
IQ80321 flash and cfi_cmdset_0001.c to update the
flash. 
plz help me out

 
bye
prashanth


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Sports - Sign up for Fantasy Baseball. 
http://baseball.fantasysports.yahoo.com/



From niraj.maheshwari at gmail.com  Mon Feb 28 02:57:01 2005
From: niraj.maheshwari at gmail.com (Niraj Maheshwari)
Date: Mon, 28 Feb 2005 13:27:01 +0530
Subject: utilities for mtd
In-Reply-To: <1f065e28ae2a88eda8f37b9c40f54ed2@sundius.com>
References: <1f065e28ae2a88eda8f37b9c40f54ed2@sundius.com>
Message-ID: <f6d0cd06050227235769c791c8@mail.gmail.com>

Hi,

I think you must have tried flash_erase on a block device
(/dec/mtdblock0) but flash_erase will work only for Char Device. So
you can create a char MTD device by giving below commands.

mknod /dev/mtd0 c 90 0

Now try the flash_erase command, it should work.

Regds
Niraj


On Thu, 24 Feb 2005 11:34:34 -0800, C. Michael Sundius
<msundius at sundius.com> wrote:
> Hi,
> 
> I am using a the mtd code from the 2.4.20 kernel. how/where do I get
> the corresponding utilities
> such as flash_erase, flash_lock etc... I grabbed a random version of
> them somewhere and it
> didn't seem to work.. for one the flash_erase program calls an ioctl
> "MEMGETREGIONCOUNT"
> and my kernel returned:
>        in appropriate ioctl for this device....
> 
> any help is appreciated.
> 
> thanks
> 
> C Michael Sundius
> Solico Group LLC
> 232 Nevada St
> San Francisco, CA 94110
> msundius at sundius.com
> (415)608-0121
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>



From narinder at kritikalsolutions.com  Mon Feb 28 03:16:27 2005
From: narinder at kritikalsolutions.com (Narinder Kumar)
Date: Mon, 28 Feb 2005 13:46:27 +0530
Subject: SPI DataFlash interfacing using 2.4.26
Message-ID: <4222D35B.7070909@kritikalsolutions.com>

Hi all,

         Did anyone on the group sucessfully interfaced a JFFS2 
partition on SPI DataFlash on Atmel's AT91RM9200 DK using  kernel 2.4.26 
? I have been able to mount the partition but read/write was giving CRC 
errors. If anyone has been able to do it succesfully please let me know 
your setup and what are the steps that you followed ?

Thanx
Narinder



From steven.scholz at imc-berlin.de  Mon Feb 28 09:19:01 2005
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Mon, 28 Feb 2005 15:19:01 +0100
Subject: SUMMARY for JFFS2?
Message-ID: <42232855.3020408@imc-berlin.de>

Hi there,

IIUC then the SUMMARY stuff goes into JFFS3.
But are there any plans to officially include it into the JFFS2 code?

It's quite cumbersome to update MTD CVS and then merge the patch 
http://www.inf.u-szeged.hu/jffs2/jffs2-summary-20050211.patch by hand.

Since its a compile time option is there anything speaking against such inclusion?

Thanks!

-- 
Steven



From dedekind at infradead.org  Mon Feb 28 09:40:54 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 28 Feb 2005 17:40:54 +0300
Subject: [PATCH] JFFS2 symlink cache
In-Reply-To: <Pine.LNX.4.58.0502171424040.30538@phoenix.infradead.org>
References: <Pine.LNX.4.58.0502171424040.30538@phoenix.infradead.org>
Message-ID: <1109601654.6211.22.camel@sauron.oktetlabs.ru>

Hello,

here is newer version of the symlink caching patch.

The problem:
~~~~~~~~~~~

When the symlink inode is cached (e.g. iget() was called for it), JFFS2
does not cache the symlink's target in RAM. Instead, it reads it from
flash on every follow_link() inode method invocation (see symlink.c,
jffs2_follow_link()).

Most of the conceivable Linux systems stores dozens of symlinks in /lib
directory and access them very often (i.e., ld and libc library's links
are accessed almost on every program load). Hence, the patch might
improve performance and it should be especially sensible during system
boot.

Implementation:
~~~~~~~~~~~~~~

The patch is implemented very simple way. On iget(), the target path of
symlink is cached in RAM. On iput() it is it is freed(). In effect, any
follow_link() call is satisfied by the cached target path, without the
physical flash reading.

I 've also tweaked jffs2_symlink() slightly (dir.c) introducing new
targetlen variable instead of invoking strlen() several times.

Issues:
~~~~~~

Please, take a glimpse how I have implemented the jffs2_follow_link()
operation (symlink.c). Surely it safe to provide f->dents string to VFS?
I do down(&f->sem) there, but this is just paranoia and I think it isn't
really needed. Please, comment this.




 

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2_symlink-03.diff
Type: text/x-patch
Size: 4636 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050228/d6c70df9/attachment.bin 

From pgrayson at realmsys.com  Mon Feb 28 21:14:07 2005
From: pgrayson at realmsys.com (Peter Grayson)
Date: Mon, 28 Feb 2005 19:14:07 -0700
Subject: Can you really write a jffs2 image with nandwrite?
Message-ID: <1109643247.5043.26.camel@pgrayson1.realmsys.com>

I am using a PowerPC 405 based Linux system running 2.6.10 kernel with
CVS head of mtd patched in. The board has a 256MB Samsung NAND flash
part with 2048 byte page size, 64 spare bytes per page, and 64 pages per
eraseblock (128kB eraseblock).

I want to use jffs2 partitions on this flash part. I can mount an empty
partition with jffs2 and that works well, but I have been unable to
weild mkfs.jffs2 and nandwrite to successfully write jffs2 images to
flash.

>From reading the mkfs.jffs2 code, it seems that mkfs.jffs2 has no
concept of out-of-bounds data. Consequently, it appears that the
nandwrite expects to find out-of-bounds data immediately after the in-
bounds data for every page. I have looked at the bits of the jffs2 image
produced by mkfs.jffs2 and I can see that it does not really produce out
of bounds data.

Below is the mkfs.jffs2 command line I am using. I have tried many other
combinations of options, but they do not yield appreciably different
results.

mkfs.jffs2
 	--pagesize=2048 \
	--eraseblock=128 \
	--pad \
	--output=image.jffs2 \
	--compression-mode none \
	--no-cleanmarkers \
	--big-endian \
	--squash \
	--verbose \
	--root=$ROOT_DIR

When I try using this image with "nandwrite -j", the image appears to be
written successfully, but when I try to mount the new filesystem, mount
fails with the following error message:

  mount: Mounting /dev/mtdblock0 on /mnt failed: Invalid argument

If I try to use "nandwrite -j -o", nandwrite complains about the image
not being aligned:

  Input file is not page aligned: Success
  Data did not fit into device, due to bad blocks
  : Success

In this case, nandwrite bails out early and does not write anything to
flash.

Is there something obvious I am missing? I have read the FAQ at:

  http://www.linux-mtd.infradead.org/tech/faq.html

so I know that the working theory is that this should work, but it is
not working for me. Has anyone else had a similar experience?

Thanks in advance for any help you can offer.

- Pete




From tglx at linutronix.de  Mon Feb 28 21:47:09 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 01 Mar 2005 03:47:09 +0100
Subject: Can you really write a jffs2 image with nandwrite?
In-Reply-To: <1109643247.5043.26.camel@pgrayson1.realmsys.com>
References: <1109643247.5043.26.camel@pgrayson1.realmsys.com>
Message-ID: <1109645229.3805.11.camel@tglx.tec.linutronix.de>

On Mon, 2005-02-28 at 19:14 -0700, Peter Grayson wrote:
> From reading the mkfs.jffs2 code, it seems that mkfs.jffs2 has no
> concept of out-of-bounds data. Consequently, it appears that the
> nandwrite expects to find out-of-bounds data immediately after the in-
> bounds data for every page. I have looked at the bits of the jffs2 image
> produced by mkfs.jffs2 and I can see that it does not really produce out
> of bounds data.

nandwrite does not expect oob data for jffs2 images.

> Below is the mkfs.jffs2 command line I am using. I have tried many other
> combinations of options, but they do not yield appreciably different
> results.
> 
> mkfs.jffs2
>  	--pagesize=2048 \
> 	--eraseblock=128 \
			
This one if definitely wrong. You meant 128kiB or 131072. 
	
> 	--pad \
> 	--output=image.jffs2 \
> 	--compression-mode none \

Why do you switch off compression ?

> 	--no-cleanmarkers \
> 	--big-endian \
> 	--squash \
> 	--verbose \
> 	--root=$ROOT_DIR
> 
> When I try using this image with "nandwrite -j", the image appears to be
> written successfully, but when I try to mount the new filesystem, mount
> fails with the following error message:
> 
>   mount: Mounting /dev/mtdblock0 on /mnt failed: Invalid argument

Did you ?
mount -t jffs2 /dev/mtdblock0 /mnt

> If I try to use "nandwrite -j -o", nandwrite complains about the image
> not being aligned:

JFFS2 has no oob data. nandwrite -j is correct.

> Is there something obvious I am missing? I have read the FAQ at:
> 
>   http://www.linux-mtd.infradead.org/tech/faq.html

I'm happy that somebody actually read it :)

> so I know that the working theory is that this should work, but it is
> not working for me. Has anyone else had a similar experience?

Before using nandwrite please erase the flash with 
flash_eraseall -j /dev/mtd0 .

tglx





