Does mtd support two-plane page program for nand flash?

Does mtd support two-plane page program for nand flash?

[falls huang]

Hello!

    AFAIK , the samsung's nand flash K9LAG08U0M/K9HBG08U1M/K9MCG08U5M
support two-plane page program. For example: The K9LAG08U0M is
arranged in four 4Gb memory planes.Each plane contains 2,048 blocks
and 2112 byte page registers. This allows it to perform simultaneous
page program and block erase by selecting one page or block from each
plane. ( refer to the datasheet of K9LAG08U0M)

  I have searched the source of mtd/jffs2/jffs3 and I found that them
don't support two-plane page program . How should I add two-plane page
program ? Should I modify the source of mtd or jffs2/jffs3 ?

  Thanks in advance!


-- 
Regards
Falls Huang

Re: Does mtd support two-plane page program for nand flash?

[Jörn Engel]

On Wed, 7 March 2007 14:57:02 +0800, falls huang wrote:
> 
>     AFAIK , the samsung's nand flash K9LAG08U0M/K9HBG08U1M/K9MCG08U5M
> support two-plane page program. For example: The K9LAG08U0M is
> arranged in four 4Gb memory planes.Each plane contains 2,048 blocks
> and 2112 byte page registers. This allows it to perform simultaneous
> page program and block erase by selecting one page or block from each
> plane. ( refer to the datasheet of K9LAG08U0M)

Interesting.  I was wondering when devices like this would show up.
Do you have a spec for those chips?

>   I have searched the source of mtd/jffs2/jffs3 and I found that them
> don't support two-plane page program . How should I add two-plane page
> program ? Should I modify the source of mtd or jffs2/jffs3 ?

Not sure how much interest in this exists for JFFS2.  Two NOR chips can
work in parallel just as easily as your two-plane chip.  But noone has
ever tried to use this in any way.

For LogFS I am very interested.  Supporting parallel writes to several
chips (or planes on one chip) is on my list.  MTD should export roughly:
 - one device for all planes/chips,
 - preferrably eraseblock interleaving between all planes/chips or
 - alternatively linearly appending all planes/chips,
 - information about how many planes/chips exists.

What is the latency of reads/writes/erases?  I have already asked for
the spec, haven't I? ;)

Jörn

-- 
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown

Re: Does mtd support two-plane page program for nand flash?

[falls huang]

Hello!

You can download its datasheet from here:
ftp://218.22.45.5/misc/Books/K9LAG08U0M_0.7.pdf

K9LAG08U0M/K9HBG08U1M are MLC nand flash ,
MLC NAND flash is becoming more and more popular for its cheap price.
I think It'll make a sense if mtd/jffs3 can support two-plane page
program.

2007/3/7, Jörn Engel <joern@lazybastard.org>:
> On Wed, 7 March 2007 14:57:02 +0800, falls huang wrote:
> >
> >     AFAIK , the samsung's nand flash K9LAG08U0M/K9HBG08U1M/K9MCG08U5M
> > support two-plane page program. For example: The K9LAG08U0M is
> > arranged in four 4Gb memory planes.Each plane contains 2,048 blocks
> > and 2112 byte page registers. This allows it to perform simultaneous
> > page program and block erase by selecting one page or block from each
> > plane. ( refer to the datasheet of K9LAG08U0M)
>
> Interesting.  I was wondering when devices like this would show up.
> Do you have a spec for those chips?
>



-- 
Regards
Falls Huang

Re: Does mtd support two-plane page program for nand flash?

[Adrian Hunter]

ext Jörn Engel wrote:
> On Wed, 7 March 2007 14:57:02 +0800, falls huang wrote:
>>     AFAIK , the samsung's nand flash K9LAG08U0M/K9HBG08U1M/K9MCG08U5M
>> support two-plane page program. For example: The K9LAG08U0M is
>> arranged in four 4Gb memory planes.Each plane contains 2,048 blocks
>> and 2112 byte page registers. This allows it to perform simultaneous
>> page program and block erase by selecting one page or block from each
>> plane. ( refer to the datasheet of K9LAG08U0M)
> 
> Interesting.  I was wondering when devices like this would show up.
> Do you have a spec for those chips?

OneNAND DDP does this too (google: onenand "2x program")

I presume the possibility exists to have the driver pretend that the
page size is twice as large and there are half as many erase blocks.
It would have to map the addressses accordingly - and everything
else would have to be willing to accept a 4KiB page with 8
subpages and 128 bytes of oob.

RE: Does mtd support two-plane page program for nand flash?

[Kyungmin Park]

> 
> ext Jörn Engel wrote:
> > On Wed, 7 March 2007 14:57:02 +0800, falls huang wrote:
> >>     AFAIK , the samsung's nand flash 
> K9LAG08U0M/K9HBG08U1M/K9MCG08U5M 
> >> support two-plane page program. For example: The K9LAG08U0M is 
> >> arranged in four 4Gb memory planes.Each plane contains 
> 2,048 blocks 
> >> and 2112 byte page registers. This allows it to perform 
> simultaneous 
> >> page program and block erase by selecting one page or 
> block from each 
> >> plane. ( refer to the datasheet of K9LAG08U0M)
> > 
> > Interesting.  I was wondering when devices like this would show up.
> > Do you have a spec for those chips?

NAND: There are also 512B 4-plane and 2KB 4-plane

> 
> OneNAND DDP does this too (google: onenand "2x program")
> 
> I presume the possibility exists to have the driver pretend 
> that the page size is twice as large and there are half as 
> many erase blocks.
> It would have to map the addressses accordingly - and 
> everything else would have to be willing to accept a 4KiB 
> page with 8 subpages and 128 bytes of oob.
> 

In my understand, If we use the 2x program, we assume physical 2 blcoks to logical 1 block in JFFS2 or others.
Since "2x program" writes each bufferram to each block instead of same block.
So if we assume 4KiB page, we programe block 0, page 0 and block 1, page 0, In my opinion, it's not fit for JFFS2.

Thank you,
Kyungmin Park

Re: Does mtd support two-plane page program for nand flash?

[Jörn Engel]

On Fri, 9 March 2007 10:09:37 +0200, Adrian Hunter wrote:
> 
> OneNAND DDP does this too (google: onenand "2x program")

Thanks!

> I presume the possibility exists to have the driver pretend that the
> page size is twice as large and there are half as many erase blocks.
> It would have to map the addressses accordingly - and everything
> else would have to be willing to accept a 4KiB page with 8
> subpages and 128 bytes of oob.

That would be the quick way to get extra bandwidth.

Interleaving writes to both planes can also help latency.  It is
possible to write to one plane while the other is erasing.  It is
possible to do two writes in parallel.  Keeping things seperate would
keep writesize and erasesize low.  And by combining two or more planes,
the slowest of them always decides how long a write/erase will take.

So in the long run, I would prefer to keep planes seperate and add
intelligence to filesystems, LogFS in particular.

Jörn

-- 
It does not matter how slowly you go, so long as you do not stop.
-- Confucius

Re: Does mtd support two-plane page program for nand flash?

[Marteo Tim]

MLC NAND Flash has already become the mainstream flash for
large-capacity on the market. But due to its low writting speed, there
will be introduced more parallel writting features such as multi-bank,
interleave, etc. So I think it is very necessary to modify MTD
structure to support multi-plane & interleave feature for speed
issure.

It is a good method to shield the details of flash type by composing
two or more page as a large page. Although it will be more slower for
small segment data read/write. But for large-capacity flash,
continuate writting speed maybe is more concerned.

Regards,
marteo

2007/3/9, Jörn Engel <joern@lazybastard.org>:
> On Fri, 9 March 2007 10:09:37 +0200, Adrian Hunter wrote:
> >
> > OneNAND DDP does this too (google: onenand "2x program")
>
> Thanks!
>
> > I presume the possibility exists to have the driver pretend that the
> > page size is twice as large and there are half as many erase blocks.
> > It would have to map the addressses accordingly - and everything
> > else would have to be willing to accept a 4KiB page with 8
> > subpages and 128 bytes of oob.
>
> That would be the quick way to get extra bandwidth.
>
> Interleaving writes to both planes can also help latency.  It is
> possible to write to one plane while the other is erasing.  It is
> possible to do two writes in parallel.  Keeping things seperate would
> keep writesize and erasesize low.  And by combining two or more planes,
> the slowest of them always decides how long a write/erase will take.
>
> So in the long run, I would prefer to keep planes seperate and add
> intelligence to filesystems, LogFS in particular.
>
> Jörn
>
> --
> It does not matter how slowly you go, so long as you do not stop.
> -- Confucius
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

Re: Does mtd support two-plane page program for nand flash?

[Charles Manning]

On Monday 12 March 2007 17:49, Marteo Tim wrote:
> MLC NAND Flash has already become the mainstream flash for
> large-capacity on the market. But due to its low writting speed, there
> will be introduced more parallel writting features such as multi-bank,
> interleave, etc. So I think it is very necessary to modify MTD
> structure to support multi-plane & interleave feature for speed
> issure.

Multi-plane flash predates MLC and has been here for a while.

MLC is a bit slower, but  bigger overheads come from ECC. For example, Micron 
suggests using at minimum BCH to give 4 bits per 512-byte correction for MLC 
whereas they suggest only a minimum of 1-bit per 512 bytes correction for 
SLC.

>
> It is a good method to shield the details of flash type by composing
> two or more page as a large page. 
This approach works, but also forces you to have more bad blocks than you'd 
have otherwise. MLC will tend to have more bad blocks than SLC.

If you know how data is going to be written thern there are other 
possibilities (eg. buffering up pages and writing them in parallel).

> Although it will be more slower for 
> small segment data read/write. But for large-capacity flash,
> continuate writting speed maybe is more concerned.

I think anyone really wanting speed probably writes their own drivers anyway 
(well that's what people woho are most interested in speed tell me 
anyway :-)).

-- Charles


>
> Regards,
> marteo
>
> 2007/3/9, Jörn Engel <joern@lazybastard.org>:
> > On Fri, 9 March 2007 10:09:37 +0200, Adrian Hunter wrote:
> > > OneNAND DDP does this too (google: onenand "2x program")
> >
> > Thanks!
> >
> > > I presume the possibility exists to have the driver pretend that the
> > > page size is twice as large and there are half as many erase blocks.
> > > It would have to map the addressses accordingly - and everything
> > > else would have to be willing to accept a 4KiB page with 8
> > > subpages and 128 bytes of oob.
> >
> > That would be the quick way to get extra bandwidth.
> >
> > Interleaving writes to both planes can also help latency.  It is
> > possible to write to one plane while the other is erasing.  It is
> > possible to do two writes in parallel.  Keeping things seperate would
> > keep writesize and erasesize low.  And by combining two or more planes,
> > the slowest of them always decides how long a write/erase will take.
> >
> > So in the long run, I would prefer to keep planes seperate and add
> > intelligence to filesystems, LogFS in particular.
> >
> > Jörn
> >
> > --
> > It does not matter how slowly you go, so long as you do not stop.
> > -- Confucius
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Does mtd support two-plane page program for nand flash?

[Jörn Engel]

On Mon, 12 March 2007 19:53:58 +1300, Charles Manning wrote:
> On Monday 12 March 2007 17:49, Marteo Tim wrote:
> > MLC NAND Flash has already become the mainstream flash for
> > large-capacity on the market. But due to its low writting speed, there
> > will be introduced more parallel writting features such as multi-bank,
> > interleave, etc. So I think it is very necessary to modify MTD
> > structure to support multi-plane & interleave feature for speed
> > issure.

Flash will evolve much like hard disks and RAM does.  Size and bandwidth
will scale up, while latency remains roughly unchanged.  And just like
hard disks and RAM, much effort will be spent, trying to reduce the
effect of latency.

In case you don't remember: increasing bandwidth is trivial.  Reducing
latency is the real challange.

> > It is a good method to shield the details of flash type by composing
> > two or more page as a large page. 
> This approach works, but also forces you to have more bad blocks than you'd 
> have otherwise. MLC will tend to have more bad blocks than SLC.

And it will increase latency instead of reducing it.  Instead of sending
multiple independent commands to multiple planes, a single command is
sent to all planes.  Not only is the slowest of all planes dominating
the latency now, but the remaining independent commands still need to
run.

It is possible to reduce the number of commands somewhat by writing
larger amount of data in one go.  But that has disadvantages of its own
is not always possible.

> > Although it will be more slower for 
> > small segment data read/write. But for large-capacity flash,
> > continuate writting speed maybe is more concerned.

Again, increasing bandwidth is trivial, as you just showed.  Latency is
the real killer.

> I think anyone really wanting speed probably writes their own drivers anyway 
> (well that's what people woho are most interested in speed tell me 
> anyway :-)).

Absolutely.  Going down the easy route coupling all planes may be a
simple first step to get bandwidth up.  But supporting independent
operations is the interesting route to follow.

Jörn

-- 
"[One] doesn't need to know [...] how to cause a headache in order
to take an aspirin."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001