NAND driver

NAND driver

[Thomas Gleixner]

Hi all,

the NAND driver was reworked to support the new 2K page size chips.
There is support for autoplacement of OOB data built in now, as discussed some 
time ago,

Status:
	JFFS2 mounts on small / large chips (current JFFS2 CVS code)
	YAFFS mounts on small chips (Patch is sent to YAFFS maillist)

Some TODO's remain, like optimization of non page aligned read access and 
support for the cached page programming, which is provided by the new Samsung 
chips. Most of this is already designed in, but not enabled yet as I wanted 
to have it working with the standard functionality first. This will happen in 
the next weeks.
And of course updating the nand html documentation.

This makes some small modifications to the board drivers neccecary. 
We need one additional buffer. The sizeof this buffer is oobsize * pages per 
block, e.g.
blocksize 16384
pagesize 512
= 32 pages per block
* 16 byte out of band data
= 512 byte buffer
The pointer must be set  _before_  calling nand_scan
The pointer for the data buffer, which was neccecary also before the change,
must be set now before calling nand_scan(), as nand_scan() contains a check 
for both pointers now.
Check the modifications in autcpu12.c for reference.


I want to say thanks to 
	Aleph One Ltd. and Toby Churchil Ltd. They supported this work
and
	llandre in Italy, who seems to be the only one in the universe who has a 
board with those new chips up and running. He did all the testing. 


Please check it out and help testing.

-- 
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

NAND driver

[Thomas Gleixner]

Hi all,

the NAND driver has some more new features

- support for AG-AND chips (currently tested with HN29V1G91T-30)
- bad block table support (memory and flash based)
- a new API documentation (online version is available on MTD homepage)

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: NAND driver

[Pantelis Antoniou]

Thomas Gleixner wrote:

>Hi all,
>
>the NAND driver has some more new features
>
>- support for AG-AND chips (currently tested with HN29V1G91T-30)
>- bad block table support (memory and flash based)
>- a new API documentation (online version is available on MTD homepage)
>
>
Sounds interesting...

I'll test when I have some spare time available.

Just a question.

Does it do the automatic bad block skipping on read-only
like my patch did, so I can mount CRAMFS?

That is, is something like my patch still required,
or it is no longer necessary?

Regards

Pantelis

Re: NAND driver

[Thomas Gleixner]

On Wednesday 02 June 2004 08:08, Pantelis Antoniou wrote:
> Thomas Gleixner wrote:
> >Hi all,
> >
> >the NAND driver has some more new features
> >
> >- support for AG-AND chips (currently tested with HN29V1G91T-30)
> >- bad block table support (memory and flash based)
> >- a new API documentation (online version is available on MTD homepage)
>
> Sounds interesting...
>
> I'll test when I have some spare time available.
>
> Just a question.
>
> Does it do the automatic bad block skipping on read-only
> like my patch did, so I can mount CRAMFS?
>
> That is, is something like my patch still required,
> or it is no longer necessary?

No, it does not. This is the job of a translation layer. So your patch os not 
obsolete

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

NAND driver

[Mark Underwood]

I’m writing a NAND driver for an ASIC. The NAND controller has been designed to handle page read &
writes with little SW intervention using interrupts or DMA, so I plan to implement the
write_page_raw & read_page_raw functions.
However, looking through nand_base.c it looks like not all NAND access go through these functions
so to start with I have implemented the cmd_ctrl function & supplied the IO_ADDR_R & IO_ADDR_W
address with the thinking that these would be a fall back when the access doesn't go through the
raw functions.
Unfortunately it seems the single write functionality of the controller is broken. The page  read
& write functionality only allow me to work in 512byte blocks so I can't write OOB that way. Can
you confirm that there are cases where OOB is written separately and if so do you have any
suggestions for getting around this problem?

Many thanks,

Mark



      ___________________________________________________________ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/

Re: NAND driver

[Mark Underwood]

--- Mark Underwood <basicmark@yahoo.com> wrote:

> I’m writing a NAND driver for an ASIC. The NAND controller has been designed to handle page read
> &
> writes with little SW intervention using interrupts or DMA, so I plan to implement the
> write_page_raw & read_page_raw functions.
> However, looking through nand_base.c it looks like not all NAND access go through these
> functions
> so to start with I have implemented the cmd_ctrl function & supplied the IO_ADDR_R & IO_ADDR_W
> address with the thinking that these would be a fall back when the access doesn't go through the
> raw functions.
> Unfortunately it seems the single write functionality of the controller is broken. The page 
> read
> & write functionality only allow me to work in 512byte blocks so I can't write OOB that way. Can
> you confirm that there are cases where OOB is written separately and if so do you have any
> suggestions for getting around this problem?
> 
> Many thanks,
> 
> Mark
> 

I forgot to say that I'm working on a 2.6.21.1 kernel.

After some pondering I managed to implement the single write functionality by abusing the command
fifo and playing with GPIO pins.

Looking through nand_base.c I notice that although I can pass in *_page_raw operations in the
nand_chip structure they are not used in the *_page_swecc functions but instead they call the
internal *_page_raw functions directly. I propose just to replace the direct calls with indirect
ones (via the function pointers in the nand_chip structure). Does this proposal sound OK?

Mark

> 
> 
>       ___________________________________________________________ 
> Rise to the challenge for Sport Relief with Yahoo! For Good  
> 
> http://uk.promotions.yahoo.com/forgood/
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 



      ___________________________________________________________ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/

RE: NAND driver

[RadhaKumar Pulyala]

I have faced situation similar to yours.

What I did was to start afresh instead of tweaking the generic nand
interface driver. I would suggest you to look at the OneNAND interface
driver. That will have a lot of similarities to an interface written for
a controller.

Hope that helps.

Regards,
RK

-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org
[mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Mark
Underwood
Sent: Tuesday, February 26, 2008 2:34 PM
To: linux-mtd@lists.infradead.org
Subject: Re: NAND driver


--- Mark Underwood <basicmark@yahoo.com> wrote:

> I'm writing a NAND driver for an ASIC. The NAND controller has been
designed to handle page read
> &
> writes with little SW intervention using interrupts or DMA, so I plan
to implement the
> write_page_raw & read_page_raw functions.
> However, looking through nand_base.c it looks like not all NAND access
go through these
> functions
> so to start with I have implemented the cmd_ctrl function & supplied
the IO_ADDR_R & IO_ADDR_W
> address with the thinking that these would be a fall back when the
access doesn't go through the
> raw functions.
> Unfortunately it seems the single write functionality of the
controller is broken. The page 
> read
> & write functionality only allow me to work in 512byte blocks so I
can't write OOB that way. Can
> you confirm that there are cases where OOB is written separately and
if so do you have any
> suggestions for getting around this problem?
> 
> Many thanks,
> 
> Mark
> 

I forgot to say that I'm working on a 2.6.21.1 kernel.

After some pondering I managed to implement the single write
functionality by abusing the command
fifo and playing with GPIO pins.

Looking through nand_base.c I notice that although I can pass in
*_page_raw operations in the
nand_chip structure they are not used in the *_page_swecc functions but
instead they call the
internal *_page_raw functions directly. I propose just to replace the
direct calls with indirect
ones (via the function pointers in the nand_chip structure). Does this
proposal sound OK?

Mark

> 
> 
>       ___________________________________________________________ 
> Rise to the challenge for Sport Relief with Yahoo! For Good  
> 
> http://uk.promotions.yahoo.com/forgood/
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 



      ___________________________________________________________ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/

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

Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer **************************** 

"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." 

********************************************************************** 

---------------------------------------------------------------------