linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Conn Clark <clark@esteem.com>
To: Andy Hawkins <a.hawkins@cabletime.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Slow read performance of NAND flash on PPC 405EP
Date: Mon, 26 Sep 2005 08:23:04 -0700	[thread overview]
Message-ID: <43381258.2060306@esteem.com> (raw)
In-Reply-To: <006101c5c27a$ca9c3280$153335bf@cabletime.com>

Andy Hawkins wrote:
> Hi,
> 
> Thanks for the reply.
> 
> 
>>It would be nice if you would break out the fields in the
>>PB2AP control
>>word. This is what I came up with.
>>
>>BME = 1, burst mode enabled
>>FWT = 2, 3 wait states
>>BWT = 4, 5 wait states
>>CSN = 0, 0 clock cycles before CS asserted
>>OEN = 1, 1 clock cycle before the PerOE is asserted
>>WBN = 1, 1 clock cycle delay until the first PerW line
>>assertion after CS
>>WBF = 1, 1 clock cycle delay
>>TH  = 2, 2 clock cycles in between each burst
>>RE  = 0, PerREADY line disabled
>>SOR = 1, no effect
>>BME = 0
> 
> 
> That matches how we decoded it, yes.
> 
> 
>>So you are reading things in burst mode. I have no experience doing
>>things in burst mode so I'm not going to be much help. I
>>would look at
>>your timing diagrams again. Try changing the TH to 1 or 0 and
>>see what
>>happens.
> 
> 
> We did try switching away from burst mode. However, as the flash is a serial
> read device with only one address, then each 'burst' transaction is only for
> a single ready anyway. We did try configuring without burst mode enabled,
> and it made little difference.
> 
> Are the figures we're seeing particularly slow, or are our expectations
> unrealistic?
> 
> Any other ideas?
> 
> Thanks again
> 
> Andy
> 


Without looking at the data sheet for your flash device I find it a 
little strange that the first wait state is 3 and the subsequent read 
wait states are 5 (i.e. 3,5,5,5,5... ) . Usually burst sequential 
devices have a long first wait state period followed by shorter ones 
(i.e. 5,3,3,3,3..... ). Are you sure you have this correct?

Unfortunately I don't have time to calculate your actual data rate. 
Other than reducing the Transfer Hold setting down from 2 to 1 or 0 I 
don't have any other ideas. In the end you get what you can get and 
thats it. If you have everything correct thats about all your going to 
get unless you start pushing timing beyond what they are rated for. I'm 
sure you don't want to do that.

Good Luck

-- Conn

*****************************************************************
Blessed be the heretic, for he causes some to think and unites
the rest against him.
*****************************************************************

Conn Clark
Engineering Assistant                clark@esteem.com
Electronic Systems Technology Inc.        www.esteem.com

Stock Ticker Symbol                ELST

       reply	other threads:[~2005-09-26 15:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <006101c5c27a$ca9c3280$153335bf@cabletime.com>
2005-09-26 15:23 ` Conn Clark [this message]
     [not found] <003401c5becc$6795bf00$153335bf@cabletime.com>
2005-09-21 16:58 ` Slow read performance of NAND flash on PPC 405EP Artem B. Bityutskiy
2005-09-21 17:00 ` Artem B. Bityutskiy
2005-09-22 17:13 ` Conn Clark
2005-09-21 16:49 Andy Hawkins

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=43381258.2060306@esteem.com \
    --to=clark@esteem.com \
    --cc=a.hawkins@cabletime.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /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;
as well as URLs for NNTP newsgroup(s).