[U-Boot] [RFC/PATCH] jffs2/mtdparts: Fix problem with usage from JFFS2 and MTDPARTS together
Currently using JFFS2 with MTDPARTS enabled doesn't work. This is because mtdparts_init() is available in both files, cmd_mtdparts.c and cmd_jffs2.c. Please note that in the original cmd_jffs2.c file (before the jffs2/mtdparts command/file split those 2 different versions already existed. So this is nothing new. The main problem is that the variables "current_dev" and "current_partnum" are declared in both files now. This doesn't work.
This patch now changes the names of those variable to more specific names: "current_mtd_dev" and "current_mtd_partnum". This is because this patch also changes the declaration from static to global, so that they can be used from both files.
Please note that my first tests were not successful. The MTD devices selected via mtdparts are now accessed but I'm failing to see the directory listed via the "ls" command. Nothing is displayed. Perhaps I didn't generate the JFFS2 image correctly (I never used JFFS2 in U-Boot before). Not sure. Perhaps somebody else could take a look at this as well. I'll continue looking into this on Monday.
Signed-off-by: Stefan Roese sr@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Detlev Zundel dzu@denx.de Cc: Ilya Yanok yanok@emcraft.com Cc: Renaud barbier renaud.barbier@ge.com --- Renaud, you reported this problem on 05-04-2009 [mtdparts and JFFS2]. Could you please take a look at my patch. Does this work for you? Or what else is missing?
Thank, Stefan.
common/cmd_jffs2.c | 44 ++++++++++++++++++----------- common/cmd_mtdparts.c | 74 ++++++++++++++++++++++++------------------------ 2 files changed, 64 insertions(+), 54 deletions(-)
diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c index 860d1d9..3bb6c3c 100644 --- a/common/cmd_jffs2.c +++ b/common/cmd_jffs2.c @@ -137,8 +137,15 @@ #define MTD_WRITEABLE_CMD 1
/* current active device and partition number */ -static struct mtd_device *current_dev = NULL; -static u8 current_partnum = 0; +#ifdef CONFIG_CMD_MTDPARTS +/* Use the ones declared in cmd_mtdparts.c */ +extern struct mtd_device *current_mtd_dev; +extern u8 current_mtd_partnum; +#else +/* Use local ones */ +struct mtd_device *current_mtd_dev = NULL; +u8 current_mtd_partnum = 0; +#endif
#if defined(CONFIG_CMD_CRAMFS) extern int cramfs_check (struct part_info *info); @@ -346,6 +353,9 @@ static inline u32 get_part_sector_size(struct mtdids *id, struct part_info *part * Parse and initialize global mtdids mapping and create global * device/partition list. * + * 'Static' version of command line mtdparts_init() routine. Single partition on + * a single device configuration. + * * @return 0 on success, 1 otherwise */ int mtdparts_init(void) @@ -360,18 +370,18 @@ int mtdparts_init(void) struct part_info *part;
initialized = 1; - current_dev = (struct mtd_device *) + current_mtd_dev = (struct mtd_device *) malloc(sizeof(struct mtd_device) + sizeof(struct part_info) + sizeof(struct mtdids)); - if (!current_dev) { + if (!current_mtd_dev) { printf("out of memory\n"); return 1; } - memset(current_dev, 0, sizeof(struct mtd_device) + - sizeof(struct part_info) + sizeof(struct mtdids)); + memset(current_mtd_dev, 0, sizeof(struct mtd_device) + + sizeof(struct part_info) + sizeof(struct mtdids));
- id = (struct mtdids *)(current_dev + 1); + id = (struct mtdids *)(current_mtd_dev + 1); part = (struct part_info *)(id + 1);
/* id */ @@ -386,7 +396,7 @@ int mtdparts_init(void) if ((mtd_id_parse(dev_name, NULL, &id->type, &id->num) != 0) || (mtd_device_validate(id->type, id->num, &size) != 0)) { printf("incorrect device: %s%d\n", MTD_DEV_TYPE(id->type), id->num); - free(current_dev); + free(current_mtd_dev); return 1; } id->size = size; @@ -413,7 +423,7 @@ int mtdparts_init(void)
part->sector_size = get_part_sector_size(id, part);
- part->dev = current_dev; + part->dev = current_mtd_dev; INIT_LIST_HEAD(&part->link);
/* recalculate size if needed */ @@ -424,11 +434,11 @@ int mtdparts_init(void) part->name, part->size, part->offset);
/* device */ - current_dev->id = id; - INIT_LIST_HEAD(¤t_dev->link); - current_dev->num_parts = 1; - INIT_LIST_HEAD(¤t_dev->parts); - list_add(&part->link, ¤t_dev->parts); + current_mtd_dev->id = id; + INIT_LIST_HEAD(¤t_mtd_dev->link); + current_mtd_dev->num_parts = 1; + INIT_LIST_HEAD(¤t_mtd_dev->parts); + list_add(&part->link, ¤t_mtd_dev->parts); }
return 0; @@ -516,7 +526,7 @@ int do_jffs2_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) if (mtdparts_init() !=0) return 1;
- if ((part = jffs2_part_info(current_dev, current_partnum))){ + if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
/* check partition type for cramfs */ fsname = (cramfs_check(part) ? "CRAMFS" : "JFFS2"); @@ -567,7 +577,7 @@ int do_jffs2_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) if (mtdparts_init() !=0) return 1;
- if ((part = jffs2_part_info(current_dev, current_partnum))){ + if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
/* check partition type for cramfs */ if (cramfs_check(part)) { @@ -602,7 +612,7 @@ int do_jffs2_fsinfo(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) if (mtdparts_init() !=0) return 1;
- if ((part = jffs2_part_info(current_dev, current_partnum))){ + if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
/* check partition type for cramfs */ fsname = (cramfs_check(part) ? "CRAMFS" : "JFFS2"); diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c index e7b6acc..6a0849f 100644 --- a/common/cmd_mtdparts.c +++ b/common/cmd_mtdparts.c @@ -166,8 +166,8 @@ struct list_head mtdids; struct list_head devices;
/* current active device and partition number */ -static struct mtd_device *current_dev = NULL; -static u8 current_partnum = 0; +struct mtd_device *current_mtd_dev = NULL; +u8 current_mtd_partnum = 0;
static struct part_info* mtd_part_info(struct mtd_device *dev, unsigned int part_num);
@@ -251,12 +251,12 @@ static void index_partitions(void)
DEBUGF("--- index partitions ---\n");
- if (current_dev) { + if (current_mtd_dev) { mtddevnum = 0; list_for_each(dentry, &devices) { dev = list_entry(dentry, struct mtd_device, link); - if (dev == current_dev) { - mtddevnum += current_partnum; + if (dev == current_mtd_dev) { + mtddevnum += current_mtd_partnum; sprintf(buf, "%d", mtddevnum); setenv("mtddevnum", buf); break; @@ -264,7 +264,7 @@ static void index_partitions(void) mtddevnum += dev->num_parts; }
- part = mtd_part_info(current_dev, current_partnum); + part = mtd_part_info(current_mtd_dev, current_mtd_partnum); setenv("mtddevname", part->name);
DEBUGF("=> mtddevnum %d,\n=> mtddevname %s\n", mtddevnum, part->name); @@ -285,9 +285,9 @@ static void current_save(void)
DEBUGF("--- current_save ---\n");
- if (current_dev) { - sprintf(buf, "%s%d,%d", MTD_DEV_TYPE(current_dev->id->type), - current_dev->id->num, current_partnum); + if (current_mtd_dev) { + sprintf(buf, "%s%d,%d", MTD_DEV_TYPE(current_mtd_dev->id->type), + current_mtd_dev->id->num, current_mtd_partnum);
setenv("partition", buf); strncpy(last_partition, buf, 16); @@ -498,18 +498,18 @@ static int part_del(struct mtd_device *dev, struct part_info *part)
/* otherwise just delete this partition */
- if (dev == current_dev) { + if (dev == current_mtd_dev) { /* we are modyfing partitions for the current device, * update current */ struct part_info *curr_pi; - curr_pi = mtd_part_info(current_dev, current_partnum); + curr_pi = mtd_part_info(current_mtd_dev, current_mtd_partnum);
if (curr_pi) { if (curr_pi == part) { printf("current partition deleted, resetting current to 0\n"); - current_partnum = 0; + current_mtd_partnum = 0; } else if (part->offset <= curr_pi->offset) { - current_partnum--; + current_mtd_partnum--; } current_save_needed = 1; } @@ -579,8 +579,8 @@ static int part_sort_add(struct mtd_device *dev, struct part_info *part)
/* get current partition info if we are updating current device */ curr_pi = NULL; - if (dev == current_dev) - curr_pi = mtd_part_info(current_dev, current_partnum); + if (dev == current_mtd_dev) + curr_pi = mtd_part_info(current_mtd_dev, current_mtd_partnum);
list_for_each(entry, &dev->parts) { struct part_info *pi; @@ -600,7 +600,7 @@ static int part_sort_add(struct mtd_device *dev, struct part_info *part) if (curr_pi && (pi->offset <= curr_pi->offset)) { /* we are modyfing partitions for the current * device, update current */ - current_partnum++; + current_mtd_partnum++; current_save(); } else { index_partitions(); @@ -842,15 +842,15 @@ static int device_del(struct mtd_device *dev) list_del(&dev->link); free(dev);
- if (dev == current_dev) { + if (dev == current_mtd_dev) { /* we just deleted current device */ if (list_empty(&devices)) { - current_dev = NULL; + current_mtd_dev = NULL; } else { /* reset first partition from first dev from the * devices list as current */ - current_dev = list_entry(devices.next, struct mtd_device, link); - current_partnum = 0; + current_mtd_dev = list_entry(devices.next, struct mtd_device, link); + current_mtd_partnum = 0; } current_save(); return 0; @@ -893,8 +893,8 @@ static void device_add(struct mtd_device *dev) u8 current_save_needed = 0;
if (list_empty(&devices)) { - current_dev = dev; - current_partnum = 0; + current_mtd_dev = dev; + current_mtd_partnum = 0; current_save_needed = 1; }
@@ -1050,7 +1050,7 @@ static int device_parse(const char *const mtd_dev, const char **ret, struct mtd_ static int mtd_devices_init(void) { last_parts[0] = '\0'; - current_dev = NULL; + current_mtd_dev = NULL; current_save();
return device_delall(&devices); @@ -1330,13 +1330,13 @@ static void list_partitions(void) if (list_empty(&devices)) printf("no partitions defined\n");
- /* current_dev is not NULL only when we have non empty device list */ - if (current_dev) { - part = mtd_part_info(current_dev, current_partnum); + /* current_mtd_dev is not NULL only when we have non empty device list */ + if (current_mtd_dev) { + part = mtd_part_info(current_mtd_dev, current_mtd_partnum); if (part) { printf("\nactive partition: %s%d,%d - (%s) 0x%08x @ 0x%08x\n", - MTD_DEV_TYPE(current_dev->id->type), - current_dev->id->num, current_partnum, + MTD_DEV_TYPE(current_mtd_dev->id->type), + current_mtd_dev->id->num, current_mtd_partnum, part->name, part->size, part->offset); } else { printf("could not get current partition info\n\n"); @@ -1709,13 +1709,13 @@ int mtdparts_init(void) strncpy(last_parts, parts, MTDPARTS_MAXLEN);
/* reset first partition from first dev from the list as current */ - current_dev = list_entry(devices.next, struct mtd_device, link); - current_partnum = 0; + current_mtd_dev = list_entry(devices.next, struct mtd_device, link); + current_mtd_partnum = 0; current_save();
- DEBUGF("mtdparts_init: current_dev = %s%d, current_partnum = %d\n", - MTD_DEV_TYPE(current_dev->id->type), - current_dev->id->num, current_partnum); + DEBUGF("mtdparts_init: current_mtd_dev = %s%d, current_mtd_partnum = %d\n", + MTD_DEV_TYPE(current_mtd_dev->id->type), + current_mtd_dev->id->num, current_mtd_partnum); }
/* mtdparts variable was reset to NULL, delete all devices/partitions */ @@ -1735,8 +1735,8 @@ int mtdparts_init(void) DEBUGF("--- getting current partition: %s\n", tmp_ep);
if (find_dev_and_part(tmp_ep, &cdev, &pnum, &p) == 0) { - current_dev = cdev; - current_partnum = pnum; + current_mtd_dev = cdev; + current_mtd_partnum = pnum; current_save(); } } else if (getenv("partition") == NULL) { @@ -1820,8 +1820,8 @@ int do_chpart(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) if (find_dev_and_part(argv[1], &dev, &pnum, &part) != 0) return 1;
- current_dev = dev; - current_partnum = pnum; + current_mtd_dev = dev; + current_mtd_partnum = pnum; current_save();
printf("partition changed to %s%d,%d\n",
Dear Stefan,
In message 1242468262-25814-1-git-send-email-sr@denx.de you wrote:
Currently using JFFS2 with MTDPARTS enabled doesn't work. This is because mtdparts_init() is available in both files, cmd_mtdparts.c and cmd_jffs2.c. Please note that in the original cmd_jffs2.c file (before the jffs2/mtdparts command/file split those 2 different versions already existed. So this is nothing new. The main problem is that the variables "current_dev" and "current_partnum" are declared in both files now. This doesn't work.
This patch now changes the names of those variable to more specific names: "current_mtd_dev" and "current_mtd_partnum". This is because this patch also changes the declaration from static to global, so that they can be used from both files.
Please note that my first tests were not successful. The MTD devices selected via mtdparts are now accessed but I'm failing to see the directory listed via the "ls" command. Nothing is displayed. Perhaps I didn't generate the JFFS2 image correctly (I never used JFFS2 in U-Boot before). Not sure. Perhaps somebody else could take a look at this as well. I'll continue looking into this on Monday.
My tests are not succesful wither. I tested on TQM8548; when booting Linux I see this:
... NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 628 at 0x000004e80000 Bad eraseblock 995 at 0x000007c60000 Bad eraseblock 2051 at 0x000010060000 Bad eraseblock 3608 at 0x00001c300000 Bad eraseblock 3992 at 0x00001f300000 cmdlinepart partition parsing not available Creating 1 MTD partitions on "e3010000.nand": 0x000000000000-0x000001000000 : "fs" ... -bash-3.2# cat /proc/mtd dev: size erasesize name mtd0: 00200000 00040000 "kernel" mtd1: 00300000 00040000 "root" mtd2: 07a00000 00040000 "user" mtd3: 00040000 00040000 "env1" mtd4: 00040000 00040000 "env2" mtd5: 00080000 00040000 "u-boot" mtd6: 01000000 00020000 "fs" -bash-3.2# mount -t jffs2 /dev/mtdblock6 /mnt -bash-3.2# ls -l /mnt total 8601 -rwxr-xr-x 1 root root 3660 Apr 2 2008 arch -rwxr-xr-x 1 root root 342308 Apr 2 2008 awk -rwxr-xr-x 1 root root 16008 Apr 2 2008 basename -rwxr-xr-x 1 root root 745340 Apr 2 2008 bash -rwxr-xr-x 1 root root 19352 Apr 2 2008 cat -rwxr-xr-x 1 root root 47796 Apr 2 2008 chgrp -rwxr-xr-x 1 root root 39412 Apr 2 2008 chmod -rwxr-xr-x 1 root root 48556 Apr 2 2008 chown -rwxr-xr-x 1 root root 60620 Apr 2 2008 cp -rwxr-xr-x 1 root root 117200 Apr 2 2008 cpio -rwxr-xr-x 1 root root 31116 Apr 2 2008 cut -rwxr-xr-x 1 root root 49372 Apr 2 2008 date -rwxr-xr-x 1 root root 52088 Apr 2 2008 dd ...
In U-Boot - with your patch applied - I get this:
=> mtdparts
device nor1 <f8000000.flash>, # parts = 6 #: name size offset mask_flags 0: kernel 0x00200000 0x00000000 0 1: root 0x00300000 0x00200000 0 2: user 0x07a00000 0x00500000 0 3: env1 0x00040000 0x07f00000 0 4: env2 0x00040000 0x07f40000 0 5: u-boot 0x00080000 0x07f80000 0
device nand0 <e3010000.nand>, # parts = 1 #: name size offset mask_flags 0: fs 0x01000000 0x00000000 0
active partition: nand0,0 - (fs) 0x01000000 @ 0x00000000
defaults: mtdids : none mtdparts: none => fsinfo ### filesystem type is JFFS2 Scanning JFFS2 FS: read_nand_cached: error reading nand off 0xabfe00 size 8192 bytes read_nand_cached: error reading nand off 0xadfe00 size 8192 bytes read_nand_cached: error reading nand off 0xac0000 size 8192 bytes read_nand_cached: error reading nand off 0xaffe00 size 8192 bytes read_nand_cached: error reading nand off 0xae0000 size 8192 bytes read_nand_cached: error reading nand off 0xb1fe00 size 8192 bytes read_nand_cached: error reading nand off 0xb00000 size 8192 bytes read_nand_cached: error reading nand off 0xb3fe00 size 8192 bytes read_nand_cached: error reading nand off 0xb20000 size 8192 bytes read_nand_cached: error reading nand off 0xb5fe00 size 8192 bytes read_nand_cached: error reading nand off 0xb40000 size 8192 bytes read_nand_cached: error reading nand off 0xb7fe00 size 8192 bytes read_nand_cached: error reading nand off 0xb60000 size 8192 bytes read_nand_cached: error reading nand off 0xb9fe00 size 8192 bytes read_nand_cached: error reading nand off 0xb80000 size 8192 bytes read_nand_cached: error reading nand off 0xbbfe00 size 8192 bytes read_nand_cached: error reading nand off 0xba0000 size 8192 bytes read_nand_cached: error reading nand off 0xbdfe00 size 8192 bytes read_nand_cached: error reading nand off 0xbc0000 size 8192 bytes read_nand_cached: error reading nand off 0xbffe00 size 8192 bytes read_nand_cached: error reading nand off 0xbe0000 size 8192 bytes read_nand_cached: error reading nand off 0xc1fe00 size 8192 bytes read_nand_cached: error reading nand off 0xc00000 size 8192 bytes read_nand_cached: error reading nand off 0xc3fe00 size 8192 bytes read_nand_cached: error reading nand off 0xc20000 size 8192 bytes read_nand_cached: error reading nand off 0xc5fe00 size 8192 bytes read_nand_cached: error reading nand off 0xc40000 size 8192 bytes read_nand_cached: error reading nand off 0xc7fe00 size 8192 bytes read_nand_cached: error reading nand off 0xc60000 size 8192 bytes read_nand_cached: error reading nand off 0xc9fe00 size 8192 bytes read_nand_cached: error reading nand off 0xc80000 size 8192 bytes read_nand_cached: error reading nand off 0xcbfe00 size 8192 bytes read_nand_cached: error reading nand off 0xca0000 size 8192 bytes read_nand_cached: error reading nand off 0xcdfe00 size 8192 bytes read_nand_cached: error reading nand off 0xcc0000 size 8192 bytes read_nand_cached: error reading nand off 0xcffe00 size 8192 bytes read_nand_cached: error reading nand off 0xce0000 size 8192 bytes read_nand_cached: error reading nand off 0xd1fe00 size 8192 bytes read_nand_cached: error reading nand off 0xd00000 size 8192 bytes read_nand_cached: error reading nand off 0xd3fe00 size 8192 bytes read_nand_cached: error reading nand off 0xd20000 size 8192 bytes read_nand_cached: error reading nand off 0xd5fe00 size 8192 bytes read_nand_cached: error reading nand off 0xd40000 size 8192 bytes read_nand_cached: error reading nand off 0xd7fe00 size 8192 bytes read_nand_cached: error reading nand off 0xd60000 size 8192 bytes read_nand_cached: error reading nand off 0xd9fe00 size 8192 bytes read_nand_cached: error reading nand off 0xd80000 size 8192 bytes read_nand_cached: error reading nand off 0xdbfe00 size 8192 bytes read_nand_cached: error reading nand off 0xda0000 size 8192 bytes read_nand_cached: error reading nand off 0xddfe00 size 8192 bytes read_nand_cached: error reading nand off 0xdc0000 size 8192 bytes read_nand_cached: error reading nand off 0xdffe00 size 8192 bytes read_nand_cached: error reading nand off 0xde0000 size 8192 bytes read_nand_cached: error reading nand off 0xe1fe00 size 8192 bytes read_nand_cached: error reading nand off 0xe00000 size 8192 bytes read_nand_cached: error reading nand off 0xe3fe00 size 8192 bytes read_nand_cached: error reading nand off 0xe20000 size 8192 bytes read_nand_cached: error reading nand off 0xe5fe00 size 8192 bytes read_nand_cached: error reading nand off 0xe40000 size 8192 bytes read_nand_cached: error reading nand off 0xe7fe00 size 8192 bytes read_nand_cached: error reading nand off 0xe60000 size 8192 bytes read_nand_cached: error reading nand off 0xe9fe00 size 8192 bytes read_nand_cached: error reading nand off 0xe80000 size 8192 bytes read_nand_cached: error reading nand off 0xebfe00 size 8192 bytes read_nand_cached: error reading nand off 0xea0000 size 8192 bytes read_nand_cached: error reading nand off 0xedfe00 size 8192 bytes read_nand_cached: error reading nand off 0xec0000 size 8192 bytes read_nand_cached: error reading nand off 0xeffe00 size 8192 bytes read_nand_cached: error reading nand off 0xee0000 size 8192 bytes read_nand_cached: error reading nand off 0xf1fe00 size 8192 bytes read_nand_cached: error reading nand off 0xf00000 size 8192 bytes read_nand_cached: error reading nand off 0xf3fe00 size 8192 bytes read_nand_cached: error reading nand off 0xf20000 size 8192 bytes read_nand_cached: error reading nand off 0xf5fe00 size 8192 bytes read_nand_cached: error reading nand off 0xf40000 size 8192 bytes read_nand_cached: error reading nand off 0xf7fe00 size 8192 bytes read_nand_cached: error reading nand off 0xf60000 size 8192 bytes read_nand_cached: error reading nand off 0xf9fe00 size 8192 bytes read_nand_cached: error reading nand off 0xf80000 size 8192 bytes read_nand_cached: error reading nand off 0xfbfe00 size 8192 bytes read_nand_cached: error reading nand off 0xfa0000 size 8192 bytes read_nand_cached: error reading nand off 0xfdfe00 size 8192 bytes read_nand_cached: error reading nand off 0xfc0000 size 8192 bytes done. Compression: NONE frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: ZERO frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: RTIME frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: RUBINMIPS frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: COPY frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: DYNRUBIN frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: ZLIB frag count: 0 compressed sum: 0 uncompressed sum: 0 =>
The addresses where the read errors occur don't seem to be related to the bad blocks reported by Linux.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Sunday 17 May 2009 15:54:28 Wolfgang Denk wrote:
My tests are not succesful wither. I tested on TQM8548; when booting Linux I see this:
... NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 628 at 0x000004e80000 Bad eraseblock 995 at 0x000007c60000 Bad eraseblock 2051 at 0x000010060000 Bad eraseblock 3608 at 0x00001c300000 Bad eraseblock 3992 at 0x00001f300000
<snip>
=> fsinfo ### filesystem type is JFFS2 Scanning JFFS2 FS: read_nand_cached: error reading nand off 0xabfe00 size 8192 bytes read_nand_cached: error reading nand off 0xadfe00 size 8192 bytes read_nand_cached: error reading nand off 0xac0000 size 8192 bytes read_nand_cached: error reading nand off 0xaffe00 size 8192 bytes
<snip>
The addresses where the read errors occur don't seem to be related to the bad blocks reported by Linux.
No. What does a "normal" "nand read" return when reading this complete partition into RAM? On PPC4xx it returned -117 here. I fixed it with the already posted patches for the 4xx NDFC ECC byte ordering. Perhaps the TQM8548 has similar incompatibility issues with the Linux kernel here too?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Stefan Roese,
In message 200905201201.50810.sr@denx.de you wrote:
=> fsinfo ### filesystem type is JFFS2 Scanning JFFS2 FS: read_nand_cached: error reading nand off 0xabfe00 size 8192 bytes read_nand_cached: error reading nand off 0xadfe00 size 8192 bytes read_nand_cached: error reading nand off 0xac0000 size 8192 bytes read_nand_cached: error reading nand off 0xaffe00 size 8192 bytes
<snip>
The addresses where the read errors occur don't seem to be related to the bad blocks reported by Linux.
No. What does a "normal" "nand read" return when reading this complete partition into RAM? On PPC4xx it returned -117 here. I fixed it with the already posted patches for the 4xx NDFC ECC byte ordering. Perhaps the TQM8548 has similar incompatibility issues with the Linux kernel here too?
I get this:
=> nand read 200000 0 1000000
NAND read: device 0 offset 0x0, size 0x1000000 NAND read from offset 0 failed -74 16777216 bytes read: ERROR
Hm, this is indeed a very helpful message. What does it tell you? I can't parse that. May we please have more readable error messages from the NAND code? Please?!
Is this -74 decimal as EBADMSG or -0x74 = NAND_CMD_STATUS_ERROR1 ?
Best regards,
Wolfgang Denk
On Sun, May 24, 2009 at 11:10:24PM +0200, Wolfgang Denk wrote:
I get this:
=> nand read 200000 0 1000000
NAND read: device 0 offset 0x0, size 0x1000000 NAND read from offset 0 failed -74 16777216 bytes read: ERROR
Hm, this is indeed a very helpful message. What does it tell you? I can't parse that. May we please have more readable error messages from the NAND code? Please?!
Is this -74 decimal as EBADMSG or -0x74 = NAND_CMD_STATUS_ERROR1 ?
It's the former. Not sure why that particular error is used rather than EIO (we inherited that from Linux), but it seems to represent an uncorrectable ECC error.
Yes, an explicit user message of "Uncorrectable ECC error" would be nice. :-)
-Scott
Dear Stefan,
In message 1242468262-25814-1-git-send-email-sr@denx.de you wrote:
Currently using JFFS2 with MTDPARTS enabled doesn't work. This is because mtdparts_init() is available in both files, cmd_mtdparts.c and cmd_jffs2.c. Please note that in the original cmd_jffs2.c file (before the jffs2/mtdparts command/file split those 2 different versions already existed. So this is nothing new. The main problem is that the variables "current_dev" and "current_partnum" are declared in both files now. This doesn't work.
I wonder how the mtdparts code is supposed to work at all. I was running some more tests on a TQM823L boiard, which has two banks of NOR flash, each 4 MiB, mapped at 0x40000000 and 0x40400000, respective, to form a contiguous area of 8 MiB from 0x40000000...0x407FFFFF. This is also what the default MTDPARTS setting assumes:
mtdparts=TQM8xxL-0:256k(u-boot),128k(dtb),1664k(kernel),2m(rootfs),4m(data)
However, it doesn't work. With DEBUGF enabled and an additional debug output, I see this:
=> mtdparts default
---mtdparts_init--- last_ids : env_ids : nor0=TQM8xxL-0 last_parts: env_parts : mtdparts=TQM8xxL-0:256k(u-boot),128k(dtb),1664k(kernel),2m(rootfs),4m(data)
last_partition : env_partition : <NULL>
---parse_mtdids--- mtdids = nor0=TQM8xxL-0
+ id nor0 4194304 bytes TQM8xxL-0
---parse_mtdparts--- mtdparts = mtdparts=TQM8xxL-0:256k(u-boot),128k(dtb),1664k(kernel),2m(rootfs),4m(data)
--- current_save --- => partition NULL --- index partitions --- => mtddevnum NULL => mtddevname NULL ===device_parse=== --- id_find_by_mtd_id: 'TQM8xxL-0' (len = 9) entry: 'TQM8xxL-0' (len = 9) dev type = 1 (nor), dev num = 0, mtd-id = TQM8xxL-0 parsing partitions 256k(u-boot),128k(dtb),1664k(kernel),2m(rootfs),4m(data) + partition: name u-boot size 0x00040000 offset 0xffffffff mask flags 0 part_validate: id: TQM8xxL-0 p->off: 00000000 p->sz: 00040000 end: 40000 id->sz: 00400000 + partition: name dtb size 0x00020000 offset 0xffffffff mask flags 0 part_validate: id: TQM8xxL-0 p->off: 00040000 p->sz: 00020000 end: 60000 id->sz: 00400000 + partition: name kernel size 0x001a0000 offset 0xffffffff mask flags 0 part_validate: id: TQM8xxL-0 p->off: 00060000 p->sz: 001A0000 end: 200000 id->sz: 00400000 + partition: name rootfs size 0x00200000 offset 0xffffffff mask flags 0 part_validate: id: TQM8xxL-0 p->off: 00200000 p->sz: 00200000 end: 400000 id->sz: 00400000 + partition: name data size 0x00400000 offset 0xffffffff mask flags 0 part_validate: id: TQM8xxL-0 p->off: 00400000 p->sz: 00400000 end: 800000 id->sz: 00400000 TQM8xxL-0: partitioning exceeds flash size
It seems that the part_validate() code increases the offset, such as if both banks of NOR flash were indeed just one big device (which I consider correct behaviour), but then it compares it against the size of the current bank instead of against the total flash size.
Am I missing something?
Best regards,
Wolfgang Denk
Dear Stefan,
on NOR fals systems with just a single bank of memory it seems to work:
=> chpart nor0,3 partition changed to nor0,3 => fsinfo ### filesystem type is JFFS2 Scanning JFFS2 FS: . done. Compression: NONE frag count: 25 compressed sum: 0 uncompressed sum: 0 Compression: ZERO frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: RTIME frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: RUBINMIPS frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: COPY frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: DYNRUBIN frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: ZLIB frag count: 719 compressed sum: 1649162 uncompressed sum: 2858640 => ls -rwxr-xr-x 14296 Tue Apr 01 22:51:21 2008 false -rwxr-xr-x 83624 Tue Apr 01 22:52:22 2008 fgrep -rwx------ 294912 Sun May 17 15:32:14 2009 gawk -rwxr-xr-x 5672 Fri Nov 21 12:32:02 2008 dmesg -rwxr-xr-x 10272 Tue Apr 01 22:57:28 2008 dnsdomainname -rwxr-xr-x 3596 Tue Apr 01 23:20:22 2008 doexec -rwxr-xr-x 10272 Tue Apr 01 22:57:28 2008 domainname -rwxr-xr-x 56972 Wed Apr 02 00:27:30 2008 dumpkeys ...
So we have:
- problems on NAND flash - problems on systems with more than one bank NOR - other storage media not tested yet
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Sunday 17 May 2009 19:25:07 Wolfgang Denk wrote:
on NOR fals systems with just a single bank of memory it seems to work:
<snip>
=> ls -rwxr-xr-x 14296 Tue Apr 01 22:51:21 2008 false -rwxr-xr-x 83624 Tue Apr 01 22:52:22 2008 fgrep -rwx------ 294912 Sun May 17 15:32:14 2009 gawk -rwxr-xr-x 5672 Fri Nov 21 12:32:02 2008 dmesg -rwxr-xr-x 10272 Tue Apr 01 22:57:28 2008 dnsdomainname -rwxr-xr-x 3596 Tue Apr 01 23:20:22 2008 doexec -rwxr-xr-x 10272 Tue Apr 01 22:57:28 2008 domainname -rwxr-xr-x 56972 Wed Apr 02 00:27:30 2008 dumpkeys ...
OK.
So we have:
- problems on NAND flash
- problems on systems with more than one bank NOR
- other storage media not tested yet
I just tested on an PPC4xx platform (405EX Kilauea) and enabled JFFS2 and MTDPARTS support there. After fixing some problems with the NAND ECC byte ordering (see patches already posted) I was able to mount JFFS2 filesystems on NOR and NAND:
=> mtdparts
device nor0 <nor>, # parts = 5 #: name size offset mask_flags 0: kernel 0x00200000 0x00000000 0 1: root 0x00200000 0x00200000 0 2: user 0x03b60000 0x00400000 0 3: env 0x00040000 0x03f60000 0 4: u-boot 0x00060000 0x03fa0000 0
device nand0 <nand>, # parts = 3 #: name size offset mask_flags 0: part1 0x01000000 0x00000000 0 1: part2 0x01000000 0x01000000 0 2: part3 0x02000000 0x02000000 0
active partition: nand0,1 - (part2) 0x01000000 @ 0x01000000
defaults: mtdids : nor0=nor mtdparts: mtdparts=nor:2m(kernel),2m(root),60800k(user),256k(env),-(u-boot) => chpart nor0,1 partition changed to nor0,1 => ls rescan: First time in use Scanning JFFS2 FS: . done. -rwxr-xr-x 14296 Wed Feb 20 17:47:23 2008 false -rwxr-xr-x 83624 Wed Feb 20 17:55:07 2008 fgrep -rwx------ 225280 Thu Jan 01 00:02:33 1970 gawk -rwxr-xr-x 15392 Wed Feb 20 17:47:23 2008 env -rwxr-xr-x 673648 Wed Feb 20 18:37:41 2008 ex
<snip>
=> chpart nand0,1 partition changed to nand0,1 => ls rescan: First time in use Scanning JFFS2 FS: . done. -rwxr-xr-x 62 Wed Feb 20 18:43:55 2008 zcat -rw-r--r-- 6 Thu Jan 01 00:01:22 1970 test.txt -rwxr-xr-x 10148 Wed Feb 20 18:04:36 2008 ypdomainname -rwxr-xr-x 673648 Wed Feb 20 18:37:41 2008 view -rwxr-xr-x 673648 Wed Feb 20 18:37:41 2008 vi -rwxr-xr-x 32796 Wed Feb 20 18:44:14 2008 usleep -rwxr-xr-x 16884 Wed Feb 20 17:47:23 2008 uname ...
Seems that I only had problems generating and/or flashing the JFFS2 images. I now mounted the mtd partitions in Linux and generated the JFFS2 fs via "mount" and copied the files to it. This worked in both cases, NOR and NAND. So it seems that the common JFFS2/MTDPARTS framework is working correctly.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Stefan Roese,
In message 1242468262-25814-1-git-send-email-sr@denx.de you wrote:
Currently using JFFS2 with MTDPARTS enabled doesn't work. This is because mtdparts_init() is available in both files, cmd_mtdparts.c and cmd_jffs2.c. Please note that in the original cmd_jffs2.c file (before the jffs2/mtdparts command/file split those 2 different versions already existed. So this is nothing new. The main problem is that the variables "current_dev" and "current_partnum" are declared in both files now. This doesn't work.
This patch now changes the names of those variable to more specific names: "current_mtd_dev" and "current_mtd_partnum". This is because this patch also changes the declaration from static to global, so that they can be used from both files.
Please note that my first tests were not successful. The MTD devices selected via mtdparts are now accessed but I'm failing to see the directory listed via the "ls" command. Nothing is displayed. Perhaps I didn't generate the JFFS2 image correctly (I never used JFFS2 in U-Boot before). Not sure. Perhaps somebody else could take a look at this as well. I'll continue looking into this on Monday.
Signed-off-by: Stefan Roese sr@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Detlev Zundel dzu@denx.de Cc: Ilya Yanok yanok@emcraft.com Cc: Renaud barbier renaud.barbier@ge.com
Renaud, you reported this problem on 05-04-2009 [mtdparts and JFFS2]. Could you please take a look at my patch. Does this work for you? Or what else is missing?
Thank, Stefan.
common/cmd_jffs2.c | 44 ++++++++++++++++++----------- common/cmd_mtdparts.c | 74 ++++++++++++++++++++++++------------------------ 2 files changed, 64 insertions(+), 54 deletions(-)
Applied to master, thanks.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Stefan Roese,
In message 1242468262-25814-1-git-send-email-sr@denx.de you wrote:
Currently using JFFS2 with MTDPARTS enabled doesn't work. This is because mtdparts_init() is available in both files, cmd_mtdparts.c and cmd_jffs2.c. Please note that in the original cmd_jffs2.c file (before the jffs2/mtdparts command/file split those 2 different versions already existed. So this is nothing new. The main problem is that the variables "current_dev" and "current_partnum" are declared in both files now. This doesn't work.
This patch now changes the names of those variable to more specific names: "current_mtd_dev" and "current_mtd_partnum". This is because this patch also changes the declaration from static to global, so that they can be used from both files.
Please note that my first tests were not successful. The MTD devices selected via mtdparts are now accessed but I'm failing to see the directory listed via the "ls" command. Nothing is displayed. Perhaps I didn't generate the JFFS2 image correctly (I never used JFFS2 in U-Boot before). Not sure. Perhaps somebody else could take a look at this as well. I'll continue looking into this on Monday.
Signed-off-by: Stefan Roese sr@denx.de Cc: Wolfgang Denk wd@denx.de Cc: Detlev Zundel dzu@denx.de Cc: Ilya Yanok yanok@emcraft.com Cc: Renaud barbier renaud.barbier@ge.com
Renaud, you reported this problem on 05-04-2009 [mtdparts and JFFS2]. Could you please take a look at my patch. Does this work for you? Or what else is missing?
This works for me. I had the "ls" problem before when current_mtd_dev was not declare global. This was because as a static current_mtd_dev. was NULL.
Thank, Stefan.
common/cmd_jffs2.c | 44 ++++++++++++++++++----------- common/cmd_mtdparts.c | 74 ++++++++++++++++++++++++------------------------ 2 files changed, 64 insertions(+), 54 deletions(-)
Applied to master, thanks.
Best regards,
Wolfgang Denk
On Monday 01 June 2009 10:59:16 Renaud barbier wrote:
Renaud, you reported this problem on 05-04-2009 [mtdparts and JFFS2]. Could you please take a look at my patch. Does this work for you? Or what else is missing?
This works for me.
Great, thanks for checking.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (4)
-
Renaud barbier -
Scott Wood -
Stefan Roese -
Wolfgang Denk