Hi,
I had considered doing something similar to support NAND. After reading though Dave's comments as attached below (speed, size, ...) and some other reading I decided from my perspective it wasn't worth it. For the most part memory is abundant at the boot loader so copying a moderately sized kernel partition doesn't seem that bad, especially given the speed cost. In my board I've added a ram entry flash device array and copy data there.
Regards,
Richard W.
---------------------------------------------------------------------------- -- 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~
-----Original Message----- From: Kenneth Johansson [mailto:kenneth.johansson@etx.ericsson.se] Sent: Thursday, July 24, 2003 7:35 AM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] [PATCH] jffs2 indirect access.
This is a patch that alters the jffs2 code to work on flash devices that is not directly memory mapped without the need to copy the whole flash to RAM.
It is not ready for inclusion and I do not think I will push it as it was quite a bit slower than I expected. It also needs a little more cleanup.
A callback function is added to struct part_info that works like memcpy and is the thing actually reading the flash. The offset member is gone and the jffs2 code always uses 0 as the start address for the filesystem. It is up to the callback function to remap that into something useful.
This code however uses less memory than copying the flash to ram but it is slower. jffs2_scan_empty() could use some speedup but even in situations when that one is not taking mush time this is slower by a factor of 2-3. It's only faster if you happens to have ridiculously slow flash.
I'm going on vacation and is not going to work more on this so if someone wants this added to u-boot you have to fix a proper patch yourself.
-- Kenneth Johansson Ericsson AB Tel: +46 8 719 70 20 Tellusborgsvägen 90 Fax: +46 8 719 29 45 126 25 Stockholm ken@switchboard.ericsson.se