[U-Boot] scan jffs2 NAND slow and bad block
Dear all,
I just enabled CMD_JFFS2 and JFFS2_NAND in the uboot 1.3.4 for my at91sam9263 based board. In general, it works in loading the jffs2 file system and loading files from it. However, it takes almost an hour to scan the jffs2 partition, which is 512 MiB. Is it because of the size of the partition? Linux loads and starts within a minute. How come it takes so long for u-boot?
Also, it seems that fsload/scanning FS routine does not skip the bad blocks in NAND. So it complains about "read_nand_cached: error reading nand off 0x########", with the address within bad blocks reported by "nand bad". Did I forget something in the configuration?
Thanks, Derek
******** my related configuration ******** #undef CONFIG_CMD_FLASH #define CONFIG_CMD_NAND 1 #define CONFIG_CMD_JFFS2 #define NAND_MAX_CHIPS 1 #define CFG_MAX_NAND_DEVICE 1 #define CFG_NAND_BASE 0x40000000 #define CFG_NAND_DBW_8 1 #undef CONFIG_JFFS2_CMDLINE #define CONFIG_JFFS2_NAND 1 #define CONFIG_JFFS2_DEV "nand0" #define CONFIG_JFFS2_PART_SIZE 0x20000000 #define CONFIG_JFFS2_PART_OFFSET 0
Dear Derek Ou,
In message 493F05B7.70307@siconix.com you wrote:
I just enabled CMD_JFFS2 and JFFS2_NAND in the uboot 1.3.4 for my at91sam9263 based board. In general, it works in loading the jffs2 file system and loading files from it. However, it takes almost an hour to scan the jffs2 partition, which is 512 MiB. Is it because of the size of the partition? Linux loads and starts within a minute. How come it takes so long for u-boot?
You may want to try top of tree from the git repository instead.
See the patch series just checked in:
... commit 142a80ffc3b537a9c45acd2444a42a77f147c602 Author: Ilya Yanok yanok@emcraft.com Date: Thu Nov 13 19:49:36 2008 +0300
jffs2: cache data_crc results
As we moved data_crc() invocation from jffs2_1pass_build_lists() to jffs2_1pass_read_inode() data_crc is going to be calculated on each inode access. This patch adds caching of data_crc() results. There is no significant improvement in speed (because of flash access caching added in previous patch I think, crc in RAM is really fast) but this patch impacts memory usage -- every b_node structure uses 12 bytes instead of 8.
Signed-off-by: Alexey Neyman avn@emcraft.com Signed-off-by: Ilya Yanok yanok@emcraft.com
commit 9b7076229ec6a958bd835ab70745f7676297ce82 Author: Ilya Yanok yanok@emcraft.com Date: Thu Nov 13 19:49:35 2008 +0300
jffs2: summary support
This patch adds support for reading fs information from summary node instead of scanning full eraseblock.
Signed-off-by: Ilya Yanok yanok@emcraft.com
commit 70741004dc28946cd82c7af6789c4ddb3fc94526 Author: Ilya Yanok yanok@emcraft.com Date: Thu Nov 13 19:49:34 2008 +0300
jffs2: add buffer to cache flash accesses
With this patch JFFS2 code allocates memory buffer of max_totlen size (size of the largest node, calculated during scan time) and uses it to store entire node. Speeds up loading. If malloc fails we use old ways to do things.
Signed-off-by: Alexey Neyman avn@emcraft.com Signed-off-by: Ilya Yanok yanok@emcraft.com
commit 8a36d31f72411144ac0412ee7e1880e801acd754 Author: Ilya Yanok yanok@emcraft.com Date: Thu Nov 13 19:49:33 2008 +0300
jffs2: rewrite jffs2 scanning code based on Linux one
Rewrites jffs2_1pass_build_lists() function in style of Linux's jffs2_scan_medium() and jffs2_scan_eraseblock(). This includes: - Caching flash acceses - Smart dealing with free space
Signed-off-by: Alexey Neyman avn@emcraft.com Signed-off-by: Ilya Yanok yanok@emcraft.com
commit e0b5532579eda8b4629f1b4f6e49c3cc60f52237 Author: Ilya Yanok yanok@emcraft.com Date: Thu Nov 13 19:49:32 2008 +0300
jffs2: add sector_size field to part_info structure
This patch adds sector_size field to part_info structure (used by new JFFS2 code).
Signed-off-by: Ilya Yanok yanok@emcraft.com
commit f73846956778a7dfee83403ef9747aff77198848 Author: Ilya Yanok yanok@emcraft.com Date: Thu Nov 13 19:49:31 2008 +0300
jffs2: fix searching for latest version in jffs2_1pass_list_inodes()
We need to update i_version inside cycle to find really latest version inside jffs2_1pass_list_inodes(). With that fixed we can use isize inside dump_inode() instead of calling expensive jffs2_1pass_read_inode().
Signed-off-by: Alexey Neyman avn@emcraft.com Signed-off-by: Ilya Yanok yanok@emcraft.com
Best regards,
Wolfgang Denk
participants (2)
-
Derek Ou -
Wolfgang Denk