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
next prev parent 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