public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Steve Tsai" <startec@ms11.hinet.net>
To: "'Thomas Gleixner'" <tglx@linutronix.de>
Cc: "Linux MTD mailing list" <linux-mtd@lists.infradead.org>
Subject: RE: NAND Configuration
Date: Mon, 12 Aug 2002 14:30:24 +0800	[thread overview]
Message-ID: <000a01c241c9$be627270$80d1a8c0@synso.com.tw> (raw)
In-Reply-To: <1028968874.9586.69.camel@thomas.tec.linutronix.de>

> 
> On Sat, 2002-08-10 at 09:54, Steve Tsai wrote:
> > That's the fault of our board. We can not adujst a proper 
> chip_delay, 
> > so we add a circuit to check the ready bit and it does not 
> have these 
> > errors so far. Do you think chip_delay can be used with 
> NAND flash? I 
> > don't think it is good idea to use chip_delay.
> > 
> I'm pretty sure, that chip_delay is working. 
> 
> Cite from data sheet:
> '..Page Read... by writing 00h to the command register along 
> with three address cycles. ... The 528 bytes of data within 
> the selected page are transferred to the data registers in 
> _LESS_ than 10us(tR). The system controller _CAN_ detect the 
> completion of this data transfer(tR) by analyzing the output 
> of R/B pin. Once the data in a page is loaded into the 
> registers, they may be read out by sequential RE pulse of 
> 70ns/50n(K9F2808Q0B:70ns,
> K9F2808U0B:50ns) period cycle. High to low transitions of the 
> RE clock take out the data from the selected column address 
> up to the last column address. '
> 
> As tR is defined as a max value of x ms, it's safe to use it. 
> I tested this, when we started the work on JFFS2/NAND. I 
> could verify with the scope, that R/B high transition was 
> always within the specified time. 
> 
> For program and erase we use a different scheme. If we have 
> no access to the R/B pin, we read back the Status Register. 
> Bit 6 is a mirror of R/B pin.
> 
> 
> If increasing of chip_delay has no effect on your device, 
> could you verify all the other timing constraints ? AS you 
> use chipselects for WE and RE, are you sure that data hold 
> time (tdh) is guaranteed ? Usually tdh on a CPU is specified 
> from the rising egde of WE, which is earlier than the rising 
> egde of a CS.
> 
> Have you ever tried to set chip_delay to 1 ? Then you should 
> get a bunch of errors.
> 

We use udelay function here, but I found that ARM uClinux can not
provide a stable delay function. I write my own delay function and I
will not get errors. I will use ready bit , because it make the JFFS2
drivers faster.

Steve Tsai

  reply	other threads:[~2002-08-12  6:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-06  7:25 NAND Configuration Steve Tsai
2002-08-06  9:07 ` Thomas Gleixner
2002-08-06 10:40   ` Steve Tsai
2002-08-06 12:16     ` Thomas Gleixner
2002-08-07  9:08       ` Steve Tsai
2002-08-07 10:05         ` David Woodhouse
2002-08-07 10:19           ` Steve Tsai
2002-08-07 10:49             ` Thomas Gleixner
2002-08-07 21:11               ` Alice Hennessy
2002-08-08  8:59                 ` Thomas Gleixner
2002-08-08  9:14                 ` David Woodhouse
2002-08-08  9:28                   ` Thomas Gleixner
2002-08-08  2:47               ` Steve Tsai
2002-08-08  5:23               ` Steve Tsai
2002-08-08  9:11                 ` Thomas Gleixner
2002-08-08  9:37                   ` Steve Tsai
2002-08-08 11:05                     ` David Woodhouse
2002-08-09  6:53                       ` Steve Tsai
2002-08-09  8:09                         ` Thomas Gleixner
2002-08-10  7:54                           ` Steve Tsai
2002-08-10  8:41                             ` Thomas Gleixner
2002-08-12  6:30                               ` Steve Tsai [this message]
2002-08-06  9:45 ` Thomas Gleixner
2002-08-06 10:25   ` Steve Tsai
2002-08-06 12:28     ` Thomas Gleixner
2002-08-06 12:32       ` David Woodhouse
2002-08-06 12:40         ` Thomas Gleixner
2002-08-07 10:45       ` Steve Tsai

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='000a01c241c9$be627270$80d1a8c0@synso.com.tw' \
    --to=startec@ms11.hinet.net \
    --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