[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 at samsung.com
> Office: +82-31-200-3109
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/