NAND partitioning

NAND partitioning

[Josh Boyer]

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

Re: NAND partitioning

[Artem B. Bityuckiy]

> 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.
Josh,

Am I correct that you are thinking about the idea to have "binary" data
on flash which does not belong to JFFS2 and JFFS2 should just move it
iact from time to time reusing their blocks for better wear-leveling?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: NAND partitioning

[Josh Boyer]

On Sat, 2005-01-29 at 14:39 +0300, Artem B. Bityuckiy wrote:
> > 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.
> Josh,
> 
> Am I correct that you are thinking about the idea to have "binary" data
> on flash which does not belong to JFFS2 and JFFS2 should just move it
> iact from time to time reusing their blocks for better wear-leveling?
> 

Not necessarily.  I was actually thinking of having JFFS2 just "ignore"
such eraseblocks.  Essentially treating them as bad blocks perhaps.

However, such blocks could be scattered across the entire device rather
than contained within a certain address range on the chip.  Updating the
data would be a bit tricky, which is why I said a driver would need to
be created in order to deal with it.

josh

Re: NAND partitioning

[Artem B. Bityuckiy]

On Sat, 2005-01-29 at 09:51 -0600, Josh Boyer wrote:
> Not necessarily.  I was actually thinking of having JFFS2 just "ignore"
> such eraseblocks.  Essentially treating them as bad blocks perhaps.
> 
> However, such blocks could be scattered across the entire device rather
> than contained within a certain address range on the chip.  Updating the
> data would be a bit tricky, which is why I said a driver would need to
> be created in order to deal with it.
> 
Hmm. If we have several binary blocks, and JFFS2 just skips them, why
should we have better wear-leveling? If we imagine we move binary blocks
sometimes, the wear-leveling would be really better.

Re: NAND partitioning

[Jörn Engel]

On Sat, 29 January 2005 09:51:00 -0600, Josh Boyer wrote:
> 
> Not necessarily.  I was actually thinking of having JFFS2 just "ignore"
> such eraseblocks.  Essentially treating them as bad blocks perhaps.
> 
> However, such blocks could be scattered across the entire device rather
> than contained within a certain address range on the chip.  Updating the
> data would be a bit tricky, which is why I said a driver would need to
> be created in order to deal with it.

Problem would be trivial to solve, if said blocks were not scattered
across the device.  Do you have a good reason to need this?

Jörn

-- 
I don't understand it. Nobody does.
-- Richard P. Feynman

Re: NAND partitioning

[Josh Boyer]

On Mon, 2005-01-31 at 13:56 +0100, Jörn Engel wrote:
> On Sat, 29 January 2005 09:51:00 -0600, Josh Boyer wrote:
> > 
> > Not necessarily.  I was actually thinking of having JFFS2 just "ignore"
> > such eraseblocks.  Essentially treating them as bad blocks perhaps.
> > 
> > However, such blocks could be scattered across the entire device rather
> > than contained within a certain address range on the chip.  Updating the
> > data would be a bit tricky, which is why I said a driver would need to
> > be created in order to deal with it.
> 
> Problem would be trivial to solve, if said blocks were not scattered
> across the device.  Do you have a good reason to need this?

If said blocks were not scattered across the device, then they could be
in a static partition and there would be nothing to discuss :).  We just
got done discussing this on IRC, so I'll try and summarize.

The main reason to not have static partitions is the concern of bad
blocks on NAND and the effects that can have on the available space for
updates, etc of binary data.  If a majority of a partition is bad
blocks, either from the factory or from eventual wear, then you don't
have much room for updating, etc.

Without a static mapping, one could "steal" free eraseblocks from JFFS2
to update or grow the binary data.  That would allow one to relocate the
binary data to different eraseblocks that might not be physically
contiguous.

There are problems with such an approach though.  Thomas pointed out the
AG-AND radiation problem, which is not trivial to solve.  Also, a hook
into JFFS[23] would be needed in order to ask it for eraseblocks if the
filesystem were mounted.

Artem asked about how this effects wear-leveling.  By allowing binary
data to be scattered throughout the device, it helps alleviate updates
to the same eraseblocks in a static partition.  One could even be
ambitious and make JFFS[23] move around such eraseblocks if they weren't
in use at the current time.  (Although that would present problems of
it's own.  I suppose you'd have to be quite ambitious to get that
working ;) ).

josh

Re: NAND partitioning

[Jörn Engel]

On Mon, 31 January 2005 09:10:38 -0600, Josh Boyer wrote:
> On Mon, 2005-01-31 at 13:56 +0100, Jörn Engel wrote:
> > 
> > Problem would be trivial to solve, if said blocks were not scattered
> > across the device.  Do you have a good reason to need this?
> 
> If said blocks were not scattered across the device, then they could be
> in a static partition and there would be nothing to discuss :).  We just
> got done discussing this on IRC, so I'll try and summarize.
> 
> The main reason to not have static partitions is the concern of bad
> blocks on NAND and the effects that can have on the available space for
> updates, etc of binary data.  If a majority of a partition is bad
> blocks, either from the factory or from eventual wear, then you don't
> have much room for updating, etc.

Not sure if there really is a problem that needs solving.

Your concern is that you need R blocks for the raw data, pick an
arbitrary number A of blocks, but notice that A-R is less than B, the
number of bad blocks in the area.  Sure.

So now you simply pick a sufficiently large A.  Let's say that your
flashes have 5% bad blocks on average.  I'm too lazy to do the math
properly, but if you pick A = 1.2*R, then well over 99% of all flash
chips should have less than 20% bad blocks in you boot partition.

And for the remaining 0.something%, you are the one to argue why those
chips have a sufficient quality to hit the field.  I'd be scared.

Jörn

-- 
Invincibility is in oneself, vulnerability is in the opponent.
-- Sun Tzu

Re: NAND partitioning

[Josh Boyer]

On Mon, 2005-01-31 at 16:29 +0100, Jörn Engel wrote:
> 
> Not sure if there really is a problem that needs solving.
> 
> Your concern is that you need R blocks for the raw data, pick an
> arbitrary number A of blocks, but notice that A-R is less than B, the
> number of bad blocks in the area.  Sure.
> 
> So now you simply pick a sufficiently large A.  Let's say that your
> flashes have 5% bad blocks on average.  I'm too lazy to do the math
> properly, but if you pick A = 1.2*R, then well over 99% of all flash
> chips should have less than 20% bad blocks in you boot partition.

Blocks go bad during usage, and data sizes change.  Also, often times
one is given a specific chip size and told "make it work".  That can put
some more restrictions on how large of a static partition you can make
for a given set of data.

> 
> And for the remaining 0.something%, you are the one to argue why those
> chips have a sufficient quality to hit the field.  I'd be scared.

I don't make those decisions.  But when something goes bad, and
something always does, I have to deal with it.

josh