JFFS2 command support on OneNAND

PATCH New Kyungmin Park 4 participants 7 messages Jul 7, 2008 – Jul 22, 2008

Subsystems (4)

Memory technology devices (MTD) NAND flash Journalling flash file system V2 (JFFS2) Onenand flash driver

lore

Share & tools

lore

Kyungmin Park

author

2008-07-07 02:22 UTC #0 lore raw

PATCH 1/1 JFFS2 command support on OneNAND

JFFS2 command support on OneNAND
Next time it will be more optimized and clean-up.

Signed-off-by Kyungmin Park <[email protected]>

---

common/cmd_jffs2.c +62 -5

index 1b67e73..959306f 100644
@@ -51,7 +51,7 @@
  * mtdids=<idmap>[,<idmap>,...]
  *
  * <idmap>    := <dev-id>=<mtd-id>
- * <dev-id>   := 'nand'|'nor'<dev-num>
+ * <dev-id>   := 'nand'|'nor'|'onenand'<dev-num>
  * <dev-num>  := mtd device number, 0...
  * <mtd-id>   := unique device tag used by linux kernel to find mtd device (mtd->name)
  *

@@ -103,6 +103,13 @@
 #include <nand.h>
 #endif /* !CFG_NAND_LEGACY */
 #endif
+
+#if defined(CONFIG_CMD_ONENAND)
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/onenand.h>
+#include <onenand_uboot.h>
+#endif
+
 /* enable/disable debugging messages */
 #define	DEBUG_JFFS
 #undef	DEBUG_JFFS

@@ -401,6 +408,43 @@ static int part_validate_nand(struct mtdids *id, struct part_info *part)
 }
 
 /**
+ * Performs sanity check for supplied OneNAND flash partition.
+ * Table of existing OneNAND flash devices is searched and partition device
+ * is located. Alignment with the granularity of nand erasesize is verified.
+ *
+ * @param id of the parent device
+ * @param part partition to validate
+ * @return 0 if partition is valid, 1 otherwise
+ */
+static int part_validate_onenand(struct mtdids *id, struct part_info *part)
+{
+#if defined(CONFIG_CMD_ONENAND)
+	/* info for OneNAND chips */
+	struct mtd_info *mtd;
+
+	mtd = &onenand_mtd;
+
+	if ((unsigned long)(part->offset) % mtd->erasesize) {
+		printf("%s%d: partition (%s) start offset"
+			"alignment incorrect\n",
+				MTD_DEV_TYPE(id->type), id->num, part->name);
+		return 1;
+	}
+
+	if (part->size % mtd->erasesize) {
+		printf("%s%d: partition (%s) size alignment incorrect\n",
+				MTD_DEV_TYPE(id->type), id->num, part->name);
+		return 1;
+	}
+
+	return 0;
+#else
+	return 1;
+#endif
+}
+
+
+/**
  * Performs sanity check for supplied partition. Offset and size are verified
  * to be within valid range. Partition type is checked and either
  * parts_validate_nor() or parts_validate_nand() is called with the argument

@@ -436,6 +480,8 @@ static int part_validate(struct mtdids *id, struct part_info *part)
 		return part_validate_nand(id, part);
 	else if (id->type == MTD_DEV_TYPE_NOR)
 		return part_validate_nor(id, part);
+	else if (id->type == MTD_DEV_TYPE_ONENAND)
+		return part_validate_onenand(id, part);
 	else
 		DEBUGF("part_validate: invalid dev type\n");

@@ -755,7 +801,15 @@ static int device_validate(u8 type, u8 num, u32 *size)
 #else
 		printf("support for NAND devices not present\n");
 #endif
-	}
+	} else if (type == MTD_DEV_TYPE_ONENAND) {
+#if defined(CONFIG_CMD_ONENAND)
+		*size = onenand_mtd.size;
+		return 0;
+#else
+		printf("support for OneNAND devices not present\n");
+#endif
+	} else
+		printf("Unknown defice type %d\n", type);
 
 	return 1;
 }

@@ -1065,8 +1119,8 @@ static struct mtdids* id_find_by_mtd_id(const char *mtd_id, unsigned int mtd_id_
 #endif /* #ifdef CONFIG_JFFS2_CMDLINE */
 
 /**
- * Parse device id string <dev-id> := 'nand'|'nor'<dev-num>, return device
- * type and number.
+ * Parse device id string <dev-id> := 'nand'|'nor'|'onenand'<dev-num>,
+ * return device type and number.
  *
  * @param id string describing device id
  * @param ret_id output pointer to next char after parse completes (output)

@@ -1085,6 +1139,9 @@ int id_parse(const char *id, const char **ret_id, u8 *dev_type, u8 *dev_num)
 	} else if (strncmp(p, "nor", 3) == 0) {
 		*dev_type = MTD_DEV_TYPE_NOR;
 		p += 3;
+	} else if (strncmp(p, "onenand", 7) == 0) {
+		*dev_type = MTD_DEV_TYPE_ONENAND;
+		p += 7;
 	} else {
 		printf("incorrect device type in %s\n", id);
 		return 1;

@@ -1489,7 +1546,7 @@ static int parse_mtdids(const char *const ids)
 	while(p && (*p != '\0')) {
 
 		ret = 1;
-		/* parse 'nor'|'nand'<dev-num> */
+		/* parse 'nor'|'nand'|'onenand'<dev-num> */
 		if (id_parse(p, &p, &type, &num) != 0)
 			break;

fs/jffs2/jffs2_1pass.c +118 -0

142 lines not on this page · raw message

include/jffs2/load_kernel.h +8 -3

index 882a80e..b46eca3 100644
@@ -28,9 +28,14 @@
 #include <linux/list.h>
 
 /* mtd device types */
-#define MTD_DEV_TYPE_NOR      0x0001
-#define MTD_DEV_TYPE_NAND     0x0002
-#define MTD_DEV_TYPE(type) ((type == MTD_DEV_TYPE_NAND) ? "nand" : "nor")
+enum {
+	MTD_DEV_TYPE_NOR,
+	MTD_DEV_TYPE_NAND,
+	MTD_DEV_TYPE_ONENAND,
+};
+
+#define MTD_DEV_TYPE(type) ((type == MTD_DEV_TYPE_NAND) ? "nand" :	\
+			(type == MTD_DEV_TYPE_ONENAND) ? "onenand" : "nor")
 
 struct mtd_device {
 	struct list_head link;

include/linux/mtd/onenand.h +1 -0

index 4b0c2df..5bc905e 100644
@@ -17,6 +17,7 @@
 /* Note: The header order is impoertant */
 #include <onenand_uboot.h>
 
+#include <linux/mtd/compat.h>
 #include <linux/mtd/bbm.h>
 
 #define MAX_BUFFERRAM		2

include/onenand_uboot.h +2 -0

index 4449f98..24ace2a 100644
@@ -27,6 +27,8 @@ typedef int wait_queue_head_t;
 struct mtd_info;
 struct erase_info;
 
+extern struct mtd_info onenand_mtd;
+
 /* Functions */
 extern void onenand_init(void);
 extern int onenand_read(struct mtd_info *mtd, loff_t from, size_t len,

Scott Wood

2008-07-11 21:43 UTC #1 lore raw

PATCH 1/1 JFFS2 command support on OneNAND

Quoted 16 lines · Kyungmin Park

common/cmd_jffs2.c +16 -0

+static int part_validate_onenand(struct mtdids *id, struct part_info *part)
+{
+#if defined(CONFIG_CMD_ONENAND)
+	/* info for OneNAND chips */
+	struct mtd_info *mtd;
+
+	mtd = &onenand_mtd;
+
+	if ((unsigned long)(part->offset) % mtd->erasesize) {
+		printf("%s%d: partition (%s) start offset"
+			"alignment incorrect\n",
+				MTD_DEV_TYPE(id->type), id->num, part->name);
+		return 1;
+	}
+
+	if (part->size % mtd->erasesize) {

common/cmd_jffs2.c static int part_validate_nand(struct mtdids *id, struct part_info *part) · line 444

Quoted 10 lines

common/cmd_jffs2.c +10 -0

+		printf("%s%d: partition (%s) size alignment incorrect\n",
+				MTD_DEV_TYPE(id->type), id->num, part->name);
+		return 1;
+	}
+
+	return 0;
+#else
+	return 1;
+#endif
+}

This looks like a duplicate of part_validate_nand (note that nand_info_t is just an obfuscatory alias of struct mtd_info).

Quoted 30 lines

fs/jffs2/jffs2_1pass.c +30 -0

+static int read_onenand_cached(u32 off, u32 size, u_char *buf)
+{
+	u32 bytes_read = 0;
+	size_t retlen;
+	int cpy_bytes;
+
+	while (bytes_read < size) {
+		if ((off + bytes_read < onenand_cache_off) ||
+		    (off + bytes_read >= onenand_cache_off + ONENAND_CACHE_SIZE)) {
+			onenand_cache_off = (off + bytes_read) & ONENAND_PAGE_MASK;
+			if (!onenand_cache) {
+				/* This memory never gets freed but 'cause
+				   it's a bootloader, nobody cares */
+				onenand_cache = malloc(ONENAND_CACHE_SIZE);
+				if (!onenand_cache) {
+					printf("read_onenand_cached: can't alloc cache size %d bytes\n",
+					       ONENAND_CACHE_SIZE);
+					return -1;
+				}
+			}
+
+			retlen = ONENAND_CACHE_SIZE;
+			if (onenand_read(&onenand_mtd, onenand_cache_off, retlen,
+						&retlen, onenand_cache) != 0 ||
+					retlen != ONENAND_CACHE_SIZE) {
+				printf("read_onenand_cached: error reading nand off %#x size %d bytes\n",
+					onenand_cache_off, ONENAND_CACHE_SIZE);
+				return -1;
+			}
+		}

fs/jffs2/jffs2_1pass.c static void put_fl_mem_nand(void *buf) · line 331

Quoted 10 lines

fs/jffs2/jffs2_1pass.c +10 -0

+		cpy_bytes = onenand_cache_off + ONENAND_CACHE_SIZE - (off + bytes_read);
+		if (cpy_bytes > size - bytes_read)
+			cpy_bytes = size - bytes_read;
+		memcpy(buf + bytes_read,
+		       onenand_cache + off + bytes_read - onenand_cache_off,
+		       cpy_bytes);
+		bytes_read += cpy_bytes;
+	}
+	return bytes_read;
+}

I really would rather not duplicate all of this, which looks extremely similar to regular NAND. Is there reason why we don't use the mtd_info function pointer interface?

-Scott

Kyungmin Park

author

2008-07-12 01:47 UTC #2 lore raw

PATCH 1/1 JFFS2 command support on OneNAND

Quoted 67 lines · Scott Wood

Quoted 16 lines · Kyungmin Park

common/cmd_jffs2.c +16 -0

+static int part_validate_onenand(struct mtdids *id, struct part_info *part)
+{
+#if defined(CONFIG_CMD_ONENAND)
+     /* info for OneNAND chips */
+     struct mtd_info *mtd;
+
+     mtd = &onenand_mtd;
+
+     if ((unsigned long)(part->offset) % mtd->erasesize) {
+             printf("%s%d: partition (%s) start offset"
+                     "alignment incorrect\n",
+                             MTD_DEV_TYPE(id->type), id->num, part->name);
+             return 1;
+     }
+
+     if (part->size % mtd->erasesize) {

common/cmd_jffs2.c static int part_validate_nand(struct mtdids *id, struct part_info *part) · line 444

Quoted 10 lines

common/cmd_jffs2.c +10 -0

+             printf("%s%d: partition (%s) size alignment incorrect\n",
+                             MTD_DEV_TYPE(id->type), id->num, part->name);
+             return 1;
+     }
+
+     return 0;
+#else
+     return 1;
+#endif
+}

This looks like a duplicate of part_validate_nand (note that nand_info_t is just an obfuscatory alias of struct mtd_info).

Quoted 36 lines

fs/jffs2/jffs2_1pass.c +36 -0

+static int read_onenand_cached(u32 off, u32 size, u_char *buf)
+{
+     u32 bytes_read = 0;
+     size_t retlen;
+     int cpy_bytes;
+
+     while (bytes_read < size) {
+             if ((off + bytes_read < onenand_cache_off) ||
+                 (off + bytes_read >= onenand_cache_off + ONENAND_CACHE_SIZE)) {
+                     onenand_cache_off = (off + bytes_read) & ONENAND_PAGE_MASK;
+                     if (!onenand_cache) {
+                             /* This memory never gets freed but 'cause
+                                it's a bootloader, nobody cares */
+                             onenand_cache = malloc(ONENAND_CACHE_SIZE);
+                             if (!onenand_cache) {
+                                     printf("read_onenand_cached: can't alloc cache size %d bytes\n",
+                                            ONENAND_CACHE_SIZE);
+                                     return -1;
+                             }
+                     }
+
+                     retlen = ONENAND_CACHE_SIZE;
+                     if (onenand_read(&onenand_mtd, onenand_cache_off, retlen,
+                                             &retlen, onenand_cache) != 0 ||
+                                     retlen != ONENAND_CACHE_SIZE) {
+                             printf("read_onenand_cached: error reading nand off %#x size %d bytes\n",
+                                     onenand_cache_off, ONENAND_CACHE_SIZE);
+                             return -1;
+                     }
+             }
+             cpy_bytes = onenand_cache_off + ONENAND_CACHE_SIZE - (off + bytes_read);
+             if (cpy_bytes > size - bytes_read)
+                     cpy_bytes = size - bytes_read;
+             memcpy(buf + bytes_read,
+                    onenand_cache + off + bytes_read - onenand_cache_off,
+                    cpy_bytes);

Quoted 8 lines

fs/jffs2/jffs2_1pass.c static void put_fl_mem_nand(void *buf) · line 331
Quoted 4 lines
fs/jffs2/jffs2_1pass.c +4 -0
+             bytes_read += cpy_bytes;
+     }
+     return bytes_read;
+}
I really would rather not duplicate all of this, which looks extremely similar to regular NAND. Is there reason why we don't use the mtd_info function pointer interface?

Agreed, It's almost same as NAND code.
Now nand code uses two modes, legacy and mtd. Because I don't want to break the NAND code , I used the duplicated code. Basically it should be used the common mtd style code except legacy.

So first it added the current code, next time it tries to use the common interface and some code clean up.

Thank you,
Kyungmin Park
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 4911 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080712/5cef9070/attachment.icz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite20080712T110000.ics
Type: application/ics
Size: 4989 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080712/5cef9070/attachment.bin

Wolfgang Denk

2008-07-13 09:51 UTC #3 lore raw

PATCH 1/1 JFFS2 command support on OneNAND

Quoted 5 lines · In message <[email protected]> you…

Quoted 4 lines
I really would rather not duplicate all of this, which looks extremely similar to regular NAND. Is there reason why we don't use the mtd_info function pointer interface?

Quoted 7 lines

Agreed, It's almost same as NAND code.
Now nand code uses two modes, legacy and mtd. Because I don't want to break the NAND code , I used the duplicated code. Basically it should be used the common mtd style code except legacy.
So first it added the current code, next time it tries to use the common interface and some code clean up.

I understand that you will submit a cleaned up patch later?

Best regards,

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Given a choice between two theories, take the one which is funnier.

Fathi Boudra

2008-07-18 14:09 UTC #4 lore raw

PATCH 1/1 JFFS2 command support on OneNAND

Hi,

Quoted 4 lines

Quoted 4 lines
I really would rather not duplicate all of this, which looks extremely
Quoted 2 lines
similar to regular NAND. Is there reason why we don't use the mtd_info function pointer interface?

Quoted 8 lines

Quoted 7 lines
Agreed, It's almost same as NAND code.
Now nand code uses two modes, legacy and mtd. Because I don't want to break the NAND code , I used the duplicated code. Basically it should be used the common mtd style code except legacy.
So first it added the current code, next time it tries to use the common interface and some code clean up.

As it is right now, you can't have jffs2 command support on both NAND and OneNAND.
Dunno if you could have this case (both NAND and OneNAND enabled) but it will fail to build:
In file included from /u-boot-1.3.3/include/linux/mtd/onenand.h:21,

from
jffs2_1pass.c:279:

/u-boot-1.3.3/include/linux/mtd/bbm.h:49: error: redefinition of 'struct nand_bbt_descr'
In file included from
jffs2_1pass.c:279:

/u-boot-1.3.3/include/linux/mtd/onenand.h:36: error: redeclaration of enumerator 'FL_READY' /u-boot-1.3.3/include/linux/mtd/nand.h:212: error: previous definition of 'FL_READY' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:37: error: redeclaration of enumerator 'FL_READING' /u-boot-1.3.3/include/linux/mtd/nand.h:213: error: previous definition of 'FL_READING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:38: error: redeclaration of enumerator 'FL_WRITING' /u-boot-1.3.3/include/linux/mtd/nand.h:214: error: previous definition of 'FL_WRITING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:39: error: redeclaration of enumerator 'FL_ERASING' /u-boot-1.3.3/include/linux/mtd/nand.h:215: error: previous definition of 'FL_ERASING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:40: error: redeclaration of enumerator 'FL_SYNCING' /u-boot-1.3.3/include/linux/mtd/nand.h:216: error: previous definition of 'FL_SYNCING' was here
jffs2_1pass.c: In function
'put_fl_mem':

jffs2_1pass.c:466: error: redefinition of
'id'

jffs2_1pass.c:459: error: previous definition of 'id' was here

make[1]: *** [jffs2_1pass.o] Error 1

cheers,

Fathi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080718/5f151deb/attachment.htm

Kyungmin Park

author

2008-07-22 05:32 UTC #5 lore raw

PATCH 1/1 JFFS2 command support on OneNAND

Quoted 46 lines · Fathi Boudra

Hi,
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
I really would rather not duplicate all of this, which looks extremely similar to regular NAND. Is there reason why we don't use the mtd_info
function pointer interface?
Quoted 7 lines
Quoted 7 lines
Agreed, It's almost same as NAND code.
Now nand code uses two modes, legacy and mtd. Because I don't want to break the NAND code , I used the duplicated code. Basically it should be used the common mtd style code except legacy.
So first it added the current code, next time it tries to use the common interface and some code clean up.
As it is right now, you can't have jffs2 command support on both NAND and OneNAND.
Dunno if you could have this case (both NAND and OneNAND enabled) but it will fail to build:
In file included from /u-boot-1.3.3/include/linux/mtd/onenand.h:21,
from
jffs2_1pass.c:279:
/u-boot-1.3.3/include/linux/mtd/bbm.h:49: error: redefinition of 'struct nand_bbt_descr'
In file included from
jffs2_1pass.c:279:
/u-boot-1.3.3/include/linux/mtd/onenand.h:36: error: redeclaration of enumerator 'FL_READY' /u-boot-1.3.3/include/linux/mtd/nand.h:212: error: previous definition of 'FL_READY' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:37: error: redeclaration of enumerator 'FL_READING' /u-boot-1.3.3/include/linux/mtd/nand.h:213: error: previous definition of 'FL_READING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:38: error: redeclaration of enumerator 'FL_WRITING' /u-boot-1.3.3/include/linux/mtd/nand.h:214: error: previous definition of 'FL_WRITING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:39: error: redeclaration of enumerator 'FL_ERASING' /u-boot-1.3.3/include/linux/mtd/nand.h:215: error: previous definition of 'FL_ERASING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:40: error: redeclaration of enumerator 'FL_SYNCING' /u-boot-1.3.3/include/linux/mtd/nand.h:216: error: previous definition of

Quoted 10 lines

'FL_SYNCING' was here
jffs2_1pass.c: In function
'put_fl_mem':
jffs2_1pass.c:466: error: redefinition of
'id'
jffs2_1pass.c:459: error: previous definition of 'id' was here
make[1]: *** [jffs2_1pass.o] Error 1

Yes, you're right. it's complicit.
However it's not related with this patch. It happens always at current source. Next time it will fix it.

Thank you,
Kyungmin Park

Fathi Boudra

2008-07-22 06:47 UTC #6 lore raw

PATCH 1/1 JFFS2 command support on OneNAND

Quoted 5 lines

Yes, you're right. it's complicit.
However it's not related with this patch. It happens always at current source.
Next time it will fix it.

The kernel implementation is similar. You'll probably have to fix it there also.

cheers,

Fathi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080722/38405c78/attachment.htm