[RFC] adding support for OneNAND flash memory

[RFC] adding support for OneNAND flash memory

[kyungmin park]

Dear,

I'm working on a MTD driver-level support for OneNAND flash memory.
OneNAND is a new type of fusion flash memory which has a small control logic inside.
It is connected to the CPU via NOR flash interface, but acts like NAND device.

At first, I've tried using the existing nand framework and extending it. However, due to the difference in the interfacing scheme, the existing nand framework needs to be modified heavily. 
This is due to the fact that every NAND command is directly written to the OneNAND controller register accessed via address bus, while the data is read through specific buffer accessed via address bus and read via data bus.

E.g., write operation
In NAND nature, basic operations are based on address/command latch enable.

1. send start address (ALE)
2. send write command (CLE)
3. write data
4. send write command (CLE)
5. send status command (CLE)
6. check status

But OneNAND operations are different from NAND flash.
The OneNAND uses register based access

1. select DataRAM* (REG)
2. write data into DataRAM
3. write block and page to Start Address Register (REG)
4. write Start Buffer Register (REG)
5. write 0 to interrupt register (REG)
6. write program command to command register (REG)
7. wait for write completed
8. read controller status register (REG)
9. check status
Note: (1) must happen before data input

So it's hard to apply OneNAND access method to current nand directory

Moreover,

To identify the OneNAND scheme is changed. There's no read id command.
Just it reads from device id register (read-only).
Also the device ids can be conflicted between NAND and OneNAND.

For this reason, I'd like to suggest adding another directory (ex. drivers/mtd/onenand) to mtd source tree for supporting OneNAND flash memory instead of modifying/extending existing nand framework.

Comments are always welcome.

Regards,

ps. for detailed info about OneNAND, please visit the following link http://www.samsung.com/Products/Semiconductor/Flash/OneNAND_TM/512Mbit/KFG1216Q2M/KFG1216Q2M.htm

--
 
Kyungmin Park
Embedded Linux Group, System Lab.
Samsung Electronics Co., Ltd.
E-mail: kyungmin.park@samsung.com
Office: +82-31-200-3109

Re: [RFC] adding support for OneNAND flash memory

[Artem B. Bityuckiy]

Hi,

I wonder is the bad block handling the same in case of OneNAND?


On Mon, 2005-02-14 at 17:40 +0900, kyungmin park wrote:
> Dear,
> 
> I'm working on a MTD driver-level support for OneNAND flash memory.
> OneNAND is a new type of fusion flash memory which has a small control logic inside.
> It is connected to the CPU via NOR flash interface, but acts like NAND device.
> 
> At first, I've tried using the existing nand framework and extending it. However, due to the difference in the interfacing scheme, the existing nand framework needs to be modified heavily. 
> This is due to the fact that every NAND command is directly written to the OneNAND controller register accessed via address bus, while the data is read through specific buffer accessed via address bus and read via data bus.
> 
> E.g., write operation
> In NAND nature, basic operations are based on address/command latch enable.
> 
> 1. send start address (ALE)
> 2. send write command (CLE)
> 3. write data
> 4. send write command (CLE)
> 5. send status command (CLE)
> 6. check status
> 
> But OneNAND operations are different from NAND flash.
> The OneNAND uses register based access
> 
> 1. select DataRAM* (REG)
> 2. write data into DataRAM
> 3. write block and page to Start Address Register (REG)
> 4. write Start Buffer Register (REG)
> 5. write 0 to interrupt register (REG)
> 6. write program command to command register (REG)
> 7. wait for write completed
> 8. read controller status register (REG)
> 9. check status
> Note: (1) must happen before data input
> 
> So it's hard to apply OneNAND access method to current nand directory
> 
> Moreover,
> 
> To identify the OneNAND scheme is changed. There's no read id command.
> Just it reads from device id register (read-only).
> Also the device ids can be conflicted between NAND and OneNAND.
> 
> or this reason, I'd like to suggest adding another directory (ex. drivers/mtd/onenand) to mtd source tree for supporting OneNAND flash memory instead of modifying/extending existing nand framework.
May be it makes sense to put it to drivers/mtd/nand/onenand if some
parts of the existing code (like BBT, etc) may be reused? Possibly,
you'll need to split the existing code on what is NAND-specific and what
is OK for both OneNAND and NAND.

And one more offer: the AG-AND support has been added directly to the
nand, but seems it would be nice to separate it and put to
drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
doesn't fit nicely to NAND stuff.

> 
> Comments are always welcome.
> 
> Regards,
> 
> ps. for detailed info about OneNAND, please visit the following link http://www.samsung.com/Products/Semiconductor/Flash/OneNAND_TM/512Mbit/KFG1216Q2M/KFG1216Q2M.htm
> 
> --
>  
> Kyungmin Park
> Embedded Linux Group, System Lab.
> Samsung Electronics Co., Ltd.
> E-mail: kyungmin.park@samsung.com
> Office: +82-31-200-3109
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [RFC] adding support for OneNAND flash memory

[kyungmin park]

Hi,

I wonder is the bad block handling the same in case of OneNAND?

=> Yes, It's the same as NAND. With regard to bad block handling, IMHO, I
think it would be better to use Bad Block Management (replace based scheme)
instead of Bad Block Table (skip based scheme). However, it's another issue
(from this OneNAND thread).

On Mon, 2005-02-14 at 17:40 +0900, kyungmin park wrote:
> Dear,
> 
> I'm working on a MTD driver-level support for OneNAND flash memory.
> OneNAND is a new type of fusion flash memory which has a small control
logic inside.
> It is connected to the CPU via NOR flash interface, but acts like NAND
device.
> 
> At first, I've tried using the existing nand framework and extending it.
However, due to the difference in the interfacing scheme, the existing nand
framework needs to be modified heavily. 
> This is due to the fact that every NAND command is directly written to
the OneNAND controller register accessed via address bus, while the data is
read through specific buffer accessed via address bus and read via data bus.
> 
> E.g., write operation
> In NAND nature, basic operations are based on address/command latch
enable.
> 
> 1. send start address (ALE)
> 2. send write command (CLE)
> 3. write data
> 4. send write command (CLE)
> 5. send status command (CLE)
> 6. check status
> 
> But OneNAND operations are different from NAND flash.
> The OneNAND uses register based access
> 
> 1. select DataRAM* (REG)
> 2. write data into DataRAM
> 3. write block and page to Start Address Register (REG)
> 4. write Start Buffer Register (REG)
> 5. write 0 to interrupt register (REG)
> 6. write program command to command register (REG)
> 7. wait for write completed
> 8. read controller status register (REG)
> 9. check status
> Note: (1) must happen before data input
> 
> So it's hard to apply OneNAND access method to current nand directory
> 
> Moreover,
> 
> To identify the OneNAND scheme is changed. There's no read id command.
> Just it reads from device id register (read-only).
> Also the device ids can be conflicted between NAND and OneNAND.
> 
> or this reason, I'd like to suggest adding another directory (ex.
drivers/mtd/onenand) to mtd source tree for supporting OneNAND flash memory
instead of modifying/extending existing nand framework.

May be it makes sense to put it to drivers/mtd/nand/onenand if some
parts of the existing code (like BBT, etc) may be reused? Possibly,
you'll need to split the existing code on what is NAND-specific and what
is OK for both OneNAND and NAND.

=> As I said before, it's difficult to modify/extend current nand directory
to support OneNAND. That's why I suggested to add onenand directory.

And one more offer: the AG-AND support has been added directly to the
nand, but seems it would be nice to separate it and put to
drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
doesn't fit nicely to NAND stuff.

=> I agree, but it's another issue.

> 
> Comments are always welcome.
> 
> Regards,
> 
> ps. for detailed info about OneNAND, please visit the following link
http://www.samsung.com/Products/Semiconductor/Flash/OneNAND_TM/512Mbit/KFG12
16Q2M/KFG1216Q2M.htm
> 
> --
>  
> Kyungmin Park
> Embedded Linux Group, System Lab.
> Samsung Electronics Co., Ltd.
> E-mail: kyungmin.park@samsung.com
> Office: +82-31-200-3109
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [RFC] adding support for OneNAND flash memory

[Thomas Gleixner]

Hi,

can you please fix your mail client to prepend the original text with ">
" ? It's hard to distiguish the original text and your answers.

On Mon, 2005-02-14 at 19:05 +0900, kyungmin park wrote:
> I wonder is the bad block handling the same in case of OneNAND?
> 
> => Yes, It's the same as NAND. With regard to bad block handling, IMHO, I
> think it would be better to use Bad Block Management (replace based scheme)
> instead of Bad Block Table (skip based scheme). However, it's another issue
> (from this OneNAND thread).

We use skip based scheme to allow filesystems to use the lowest level
and do their own management. It's no problem to add a replace based
scheme on top as the FLASH translation layers already do.

> May be it makes sense to put it to drivers/mtd/nand/onenand if some
> parts of the existing code (like BBT, etc) may be reused? Possibly,
> you'll need to split the existing code on what is NAND-specific and what
> is OK for both OneNAND and NAND.
> 
> => As I said before, it's difficult to modify/extend current nand directory
> to support OneNAND. That's why I suggested to add onenand directory.

It's not hard to extend. Just add onenand.c to it, if thats all what is
needed. The question is whether the bad block table code can be shared
or not. I agree that nand_base.c can not be tweaked for OneNAND.

> And one more offer: the AG-AND support has been added directly to the
> nand, but seems it would be nice to separate it and put to
> drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
> doesn't fit nicely to NAND stuff.
> 
> => I agree, but it's another issue.

I don't see a point to touch AG-AND support. AG-AND is NAND with some
extra features. As I said already it shares >90% of the NAND code.

It is more interesting whether OneNAND and superAND could share a fair
amount of code.

tglx

RE: [RFC] adding support for OneNAND flash memory

[kyungmin park]

[snip]
> May be it makes sense to put it to drivers/mtd/nand/onenand if some
> parts of the existing code (like BBT, etc) may be reused? Possibly,
> you'll need to split the existing code on what is NAND-specific and what
> is OK for both OneNAND and NAND.
> 
> => As I said before, it's difficult to modify/extend current nand
directory
> to support OneNAND. That's why I suggested to add onenand directory.

> It's not hard to extend. Just add onenand.c to it, if thats all what is
> needed. The question is whether the bad block table code can be shared
> or not. I agree that nand_base.c can not be tweaked for OneNAND.

Although OneNAND uses NAND core internally, the interface is very different
from NAND. The viewpoint of the hardware it seems to be connected with NOR.
Also OneNAND supports synchronous burst read as NOR does
I wonder the different interface of flash putting together is accptable?

Currently, I don't apply bad block table code to onenand. But I think
there's no problem to use current bbt code.

RE: [RFC] adding support for OneNAND flash memory

[Thomas Gleixner]

On Mon, 2005-02-14 at 20:18 +0900, kyungmin park wrote:
> [snip]
> > May be it makes sense to put it to drivers/mtd/nand/onenand if some
> > parts of the existing code (like BBT, etc) may be reused? Possibly,
> > you'll need to split the existing code on what is NAND-specific and what
> > is OK for both OneNAND and NAND.
> > 
> > => As I said before, it's difficult to modify/extend current nand
> directory
> > to support OneNAND. That's why I suggested to add onenand directory.
> 
> > It's not hard to extend. Just add onenand.c to it, if thats all what is
> > needed. The question is whether the bad block table code can be shared
> > or not. I agree that nand_base.c can not be tweaked for OneNAND.
> 
> Although OneNAND uses NAND core internally, the interface is very different
> from NAND. The viewpoint of the hardware it seems to be connected with NOR.
> Also OneNAND supports synchronous burst read as NOR does
> I wonder the different interface of flash putting together is accptable?
> 
> Currently, I don't apply bad block table code to onenand. But I think
> there's no problem to use current bbt code.

Ok, so I guess it makes sense to put it into drivers/mtd/onenand. If you
want to use the bbt code from nand it's no problem, just a tweak in
KConfig.

tglx

RE: [RFC] adding support for OneNAND flash memory

[Thomas Gleixner]

On Mon, 2005-02-14 at 12:23 +0100, Thomas Gleixner wrote:
> > 
> > Currently, I don't apply bad block table code to onenand. But I think
> > there's no problem to use current bbt code.
> 
> Ok, so I guess it makes sense to put it into drivers/mtd/onenand. If you
> want to use the bbt code from nand it's no problem, just a tweak in
> KConfig.

If you are going to implement a block replacement scheme, please put it
into a seperate file, so it can be used by others too. 

thanks

tglx

Re: [RFC] adding support for OneNAND flash memory

[Thomas Gleixner]

On Mon, 2005-02-14 at 11:58 +0300, Artem B. Bityuckiy wrote:
> And one more offer: the AG-AND support has been added directly to the
> nand, but seems it would be nice to separate it and put to
> drivers/mtd/nand/ag-and/ stuff - because ASFAICS, some of AG-AND code
> doesn't fit nicely to NAND stuff.

I don't see a real good reason to remove AG-AND from the NAND code. It
fits quite well and ripping it out would just duplicate 95% of the NAND
driver code. The tweaks to integrate AG-AND are really simple

tglx

Re: [RFC] adding support for OneNAND flash memory

[Thomas Gleixner]

Hi,

On Mon, 2005-02-14 at 17:40 +0900, kyungmin park wrote:
> For this reason, I'd like to suggest adding another directory 
> (ex. drivers/mtd/onenand) to mtd source tree for supporting OneNAND 
> flash memory instead of modifying/extending existing nand framework.

This makes sense. I had a look into OneNAND datasheets some time ago and
I can only agree that it does not fit into the NAND driver. 

tglx