Richard Woodruff [mailto:r-woodruff2@ti.com] wrote:

Has anyone used adapted/used any of the u-boot JFFS2 code to be NAND

aware?

A very quick look at the JFFS2 code (called by fsload, fsinfo, ..) seems

to

indicate to me that reading of raw data is done via a straight memcpy (direct dereference, assuming linear flash). I'm wondering if making it work might be as simple as conditionalizing that code to call the nand_mtd read.j equivalents....unfortunately few things are ever just simple...

I have it working, but in a simpler way. I have a 2 MiB boot partition at the start of the nand flash (with just the kernel image and maybe a backup kernel). I read the whole partition to RAM and let JFFS2 read it from there.

nand read.j 400000 0 200000; fsload 200000 image; bootm 200000

The only tricky part is that the configuration options for JFFS2 only work with memory in NOR flash, so I used CFG_JFFS_CUSTOM_PART and implemented jffs2_part_info() so it points to RAM.

Someday it would be good (IMHO) to accept CFG_JFFS2_BASE and CFG_JFFS2_SIZE as an alternative (even for NOR flash) to the sector/bank scheme (CFG_JFFS2_FIRST_SECTOR, etc.).

Copying the NAND to RAM means each sector is only read from NAND once, which is good since both reading the NAND and doing the ECC calculations can be slow.

The ideal case is to just allow the kernel to be part of the filesytem, though I suppose it might not be strictly necessary and a raw partition which ignores bad blocks might be enough....at the moment I'm wondering

how

one safely draw the lines of how big a partition would need to be at the "physical" level to guarantee that your kernel will always fit, assuming some of the blocks go bad over time.

If you use a separate boot partition very few blocks should wear out, since they won't be written very often. The safest way to update the kernel is to load the new kernel without deleting the old one, so if you allow twice the largest possible size of your kernel plus 15 or 20 erase blocks for JFFS2 overhead and bad blocks, you should be OK. But NAND is cheap and kernels grow, so I would allocate more if possible.

With the kernel in a larger partition with lots of files booting is slow, since both reading the flash and sorting all of the file fragments take a lot of time.

Dave

Dave Ellis ~~~~~~~~~~~~~~~~~~~~~~~~~~ SIXNET - "Leading the Industrial Ethernet Revolution" 331 Ushers Road, P.O. Box 767, Clifton Park, NY 12065 USA Tel +1 (518) 877-5173 Fax +1 (518) 877-8346 Email me at: dge@sixnetio.com Detailed product info: www.sixnetio.com ~~~~~~~~~~~~~~~~~~~~~~~~~~