Large block NAND

Large block NAND

[llandre]

Hi all,

I'm going to write a driver for the Samsung Flash K9F1G08U0M (128MB).
The main characteristics are:
- erase block size: 128 KB
- page program size: 2 KB
- total chip size: 128 MB
- tR = 25 us

This chip is not fully compatible with the standard NAND flash commands 
defined in
nand.h (Samsung call these devices "large block").
Thus, in my understanding, I must provide the following custom functions:
my_board_nand_command
my_board_nand_wait
my_board_nand_block_bad

Anybody wrote a driver for a similar device?
Have the MTD maintainers already planned to support these devices?




Best regards,

llandre  

Re: Large block NAND

[Thomas Gleixner]

On Thursday 18 March 2004 13:14, llandre wrote:
> Hi all,
>
> I'm going to write a driver for the Samsung Flash K9F1G08U0M (128MB).
> The main characteristics are:
> - erase block size: 128 KB
> - page program size: 2 KB
> - total chip size: 128 MB
> - tR = 25 us
>
> This chip is not fully compatible with the standard NAND flash commands
> defined in
> nand.h (Samsung call these devices "large block").
> Thus, in my understanding, I must provide the following custom functions:
> my_board_nand_command
> my_board_nand_wait
> my_board_nand_block_bad

Those functions should be incorporated into nand.c, as they are generic. So 
all boards which use those "large block" devices can use them.

Be aware, that the available NAND aware filesystems must be changed too, as 
they are not aware of pagesizes > 512 byte, but if IIRC  the datasheet 
details it is possible to write 4  512 byte sub-pages to the device without 
violating the specs. Anyway changes will be neccecary.

> Anybody wrote a driver for a similar device?
> Have the MTD maintainers already planned to support these devices?

Yep, but nobody forced me / us to implement it by paying for it. :)

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Large block NAND

[David Woodhouse]

On Thu, 2004-03-18 at 14:11 +0100, Thomas Gleixner wrote:
> Be aware, that the available NAND aware filesystems must be changed too, as 
> they are not aware of pagesizes > 512 byte, but if IIRC  the datasheet 
> details it is possible to write 4  512 byte sub-pages to the device without 
> violating the specs. Anyway changes will be neccecary.

JFFS2 shouldn't actually have any problem with arbitrary page sizes as
long as they're a power of two.

-- 
dwmw2

Re: Large block NAND

[Thomas Gleixner]

On Thursday 18 March 2004 15:16, David Woodhouse wrote:
> On Thu, 2004-03-18 at 14:11 +0100, Thomas Gleixner wrote:
> > Be aware, that the available NAND aware filesystems must be changed too,
> > as they are not aware of pagesizes > 512 byte, but if IIRC  the datasheet
> > details it is possible to write 4  512 byte sub-pages to the device
> > without violating the specs. Anyway changes will be neccecary.
>
> JFFS2 shouldn't actually have any problem with arbitrary page sizes as
> long as they're a power of two.

Except for the oob handling, but thats only one function to adjust

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Large block NAND

[llandre]

Hi Thomas,

> > I'm going to write a driver for the Samsung Flash K9F1G08U0M (128MB).
> > The main characteristics are:
> > - erase block size: 128 KB
> > - page program size: 2 KB
> > - total chip size: 128 MB
> > - tR = 25 us
> >
> > This chip is not fully compatible with the standard NAND flash commands
> > defined in
> > nand.h (Samsung call these devices "large block").
> > Thus, in my understanding, I must provide the following custom functions:
> > my_board_nand_command
> > my_board_nand_wait
> > my_board_nand_block_bad
>
>Those functions should be incorporated into nand.c, as they are generic. So
>all boards which use those "large block" devices can use them.
>
>Be aware, that the available NAND aware filesystems must be changed too, as
>they are not aware of pagesizes > 512 byte, but if IIRC  the datasheet
>details it is possible to write 4  512 byte sub-pages to the device without
>violating the specs. Anyway changes will be neccecary.

I see.

> > Anybody wrote a driver for a similar device?
> > Have the MTD maintainers already planned to support these devices?
>
>Yep, but nobody forced me / us to implement it by paying for it. :)

In case we decide to implement this feature by ourselves:
1) will the code be included in the public CVS tree?
2) will we guided by you and David in order to write the code the right way (I
mean, for example, using the correct notations and coding style)?



Regards,

llandre 

Re: Large block NAND

[Thomas Gleixner]

On Thursday 18 March 2004 15:52, llandre wrote:
> >
> >Yep, but nobody forced me / us to implement it by paying for it. :)
>
> In case we decide to implement this feature by ourselves:
> 1) will the code be included in the public CVS tree?

Why not.

> 2) will we guided by you and David in order to write the code the right way
> (I mean, for example, using the correct notations and coding style)?

Sure, Try it. Join #mtd on irc.freenode.net. 

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Large block NAND

[David Woodhouse]

On Thu, 2004-03-18 at 15:52 +0100, llandre wrote:
> In case we decide to implement this feature by ourselves:
> 1) will the code be included in the public CVS tree?
> 2) will we guided by you and David in order to write the code the right way (I
> mean, for example, using the correct notations and coding style)?

The code will be included if it's acceptable, certainly. Guidance is
also likely to be forthcoming, but not excessive handholding. If it
takes us so long to talk you through it that we might as well have done
it ourselves, then it's not going to help :)

Have a look, come up with a plan, and join the IRC channel to discuss
it. 

-- 
dwmw2

Re: Large block NAND

[David Updegraff]

I am looking at the existing 'drivers' in drivers/mtd/nand; am a bit 
baffled; need help understanding approach.

The files (spia, autcpu12..) are apparently drivers for particular NAND 
chips, but it appears to me that they all call nand_scan in nand.c, 
which in turn just looks for ids enumerated in nand_ids.h.  Does this 
not make it necessary to hand-tune which driver you want to compile with 
nand.c instead of having the drivers themselves control with nand chip 
they know how to drive -- based on what ID one finds?  Or is the 
thinking that the quirks of each little embedded gadget to too wierd 
anyway; so must hand-tune?

-dbu.

Re: Large block NAND

[David Woodhouse]

On Mon, 2004-03-22 at 09:37 -0600, David Updegraff wrote:
> I am looking at the existing 'drivers' in drivers/mtd/nand; am a bit 
> baffled; need help understanding approach.
> 
> The files (spia, autcpu12..) are apparently drivers for particular NAND 
> chips, 

They're not. They're drivers for particular ways wiring up a NAND chip. 

The code in nand.c handles all currently-supported (i.e 8-bit, 256- or
512-byte per page) NAND chips, and uses access functions provided by the
board-specific 'wiring' driver to waggle the control lines, etc.



> but it appears to me that they all call nand_scan in nand.c, 
> which in turn just looks for ids enumerated in nand_ids.h.  Does this 
> not make it necessary to hand-tune which driver you want to compile with 
> nand.c instead of having the drivers themselves control with nand chip 
> they know how to drive -- based on what ID one finds?  Or is the 
> thinking that the quirks of each little embedded gadget to too wierd 
> anyway; so must hand-tune?
> 
> -dbu.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
dwmw2

Re: Large block NAND

[David Updegraff]

Does anyone know how 'industry-standard' the format of the 4th ID byte 
in these large NAND chips from Samsung is?  Y'know, the one that tells 
you pagesize, buswidth, etc.  I'd sure be sweet to be able to reliably 
use them.


>> > I'm going to write a driver for the Samsung Flash K9F1G08U0M (128MB).
>> > The main characteristics are:
>> > - erase block size: 128 KB
>> > - page program size: 2 KB
>> > - total chip size: 128 MB
>> > - tR = 25 us
>> >
>> > This chip is not fully compatible with the standard NAND flash commands
>> > defined in
>> > nand.h (Samsung call these devices "large block").
>> > Thus, in my understanding, I must provide the following custom 
>> functions:
>> > my_board_nand_command
>> > my_board_nand_wait
>> > my_board_nand_block_bad
>>
>> Those functions should be incorporated into nand.c, as they are 
>> generic. So
>> all boards which use those "large block" devices can use them.
>>
>> Be aware, that the available NAND aware filesystems must be changed 
>> too, as
>> they are not aware of pagesizes > 512 byte, but if IIRC  the datasheet
>> details it is possible to write 4  512 byte sub-pages to the device 
>> without
>> violating the specs. Anyway changes will be neccecary.
> 
> 
> I see.
> 
>> > Anybody wrote a driver for a similar device?
>> > Have the MTD maintainers already planned to support these devices?
>>
>> Yep, but nobody forced me / us to implement it by paying for it. :)
> 
> 
> In case we decide to implement this feature by ourselves:
> 1) will the code be included in the public CVS tree?
> 2) will we guided by you and David in order to write the code the right 
> way (I
> mean, for example, using the correct notations and coding style)?
> 
> 
> 
> Regards,
> 
> llandre
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Large block NAND

[llandre]

>Does anyone know how 'industry-standard' the format of the 4th ID byte in 
>these large NAND chips from Samsung is?  Y'know, the one that tells you 
>pagesize, buswidth, etc.  I'd sure be sweet to be able to reliably use them.

Hi David,

I'm not sure I understood exactly your question anyway the 4th ID byte is 
usually described in the
technical datasheet. For example, for the K9F1G08U0M, it is detailed on 
pages 28 and 29.

PS: which chip are you going to work with?



Regards,

llandre