adding support for OneNAND flash memory

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.

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: [email protected]
Office: +82-31-200-3109

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

It is connected to the CPU via NOR flash interface, but acts like NAND

At first, I've tried using the existing nand framework and extending it.

This is due to the fact that every NAND command is directly written to

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

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.

Comments are always welcome.

Regards,

ps. for detailed info about OneNAND, please visit the following link

--

Kyungmin Park
Embedded Linux Group, System Lab.
Samsung Electronics Co., Ltd.
E-mail: [email protected]
Office: +82-31-200-3109

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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).

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.

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

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.

[snip]

Quoted 6 lines

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

Quoted 5 lines

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.

Quoted 3 lines

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.

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.

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.