public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] scan jffs2 NAND slow and bad block
@ 2008-12-09 23:56 Derek Ou
  2008-12-10  0:27 ` Wolfgang Denk
  0 siblings, 1 reply; 2+ messages in thread
From: Derek Ou @ 2008-12-09 23:56 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [U-Boot] scan jffs2 NAND slow and bad block
  2008-12-09 23:56 [U-Boot] scan jffs2 NAND slow and bad block Derek Ou
@ 2008-12-10  0:27 ` Wolfgang Denk
  0 siblings, 0 replies; 2+ messages in thread
From: Wolfgang Denk @ 2008-12-10  0:27 UTC (permalink / raw)
  To: u-boot

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

-- 
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
There are three things I always forget. Names, faces -  the  third  I
can't remember.                                         - Italo Svevo

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-12-10  0:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-09 23:56 [U-Boot] scan jffs2 NAND slow and bad block Derek Ou
2008-12-10  0:27 ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox