Richard Woodruff [mailto:r-woodruff2 at ti.com] wrote:
> Has anyone used adapted/used any of the u-boot JFFS2 code to be NAND
> A very quick look at the JFFS2 code (called by fsload, fsinfo, ..) seems
> 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
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
> 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.
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 at sixnetio.com
Detailed product info: www.sixnetio.com