From: kyungmin park <kyungmin.park@samsung.com>
To: 'David Woodhouse' <dwmw2@infradead.org>,
'Thomas Gleixner' <tglx@linutronix.de>
Cc: linux-mtd@lists.infradead.org
Subject: [RFC] adding support for OneNAND flash memory
Date: Mon, 14 Feb 2005 17:40:59 +0900 [thread overview]
Message-ID: <0IBW007DE84BOU@mmp1.samsung.com> (raw)
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
next reply other threads:[~2005-02-14 8:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-14 8:40 kyungmin park [this message]
2005-02-14 8:58 ` [RFC] adding support for OneNAND flash memory Artem B. Bityuckiy
2005-02-14 10:05 ` kyungmin park
2005-02-14 10:23 ` Thomas Gleixner
2005-02-14 11:18 ` kyungmin park
2005-02-14 11:23 ` Thomas Gleixner
2005-02-14 11:29 ` Thomas Gleixner
2005-02-14 10:11 ` Thomas Gleixner
2005-02-14 9:00 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0IBW007DE84BOU@mmp1.samsung.com \
--to=kyungmin.park@samsung.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox