NAND partitioning

[Josh Boyer <jdub@us.ibm.com>]

Hi all,

>From what I understand, partitioning on NAND is the same as partitioning
on NOR.  A map driver calls add_mtd_partitions passing a mtd_partition
structure which has the partitions listed with name, physical offset
into the chip, and a size.

I stumbled upon the docboot directory today and read the README.  Seems
that M-Systems marks the eraseblocks for their 1st and 2nd stage boot
loaders using a special marker in the OOB area.  I assume that map
drivers that use such devices simply make partitions for these areas and
leave them be for the most part.

After thinking about that for a bit, why would one need to create
separate partitions for that?  Could JFFS2 grok a "binary eraseblock"
marker instead?  It would essentially ignore the data such an
eraseblock.

Some might be asking, "What's wrong with normal partitioning?"  Well,
given that NAND is somewhat unreliable it might be advantageous to use
JFFS2 across the entire device.  If normal partitions are used, they
limit the amount of wear-leveling that JFFS2 can do on the device.
Basically you only get wear-leveling within that partition.  The higher
the number of partitions, the worse wear-leveling you get across the
chip.

This concept extends to any sort of "binary" data that one would want on
the device.  To access the data contained in said eraseblocks, one could
write a device driver that understood the data and presented it to the
user via a MTD device.

Thoughts?

josh