public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Daniel Mack <zonque@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] am335x: GPMC: reading speed with prefetch mode
Date: Fri, 20 Mar 2015 15:54:29 +0100	[thread overview]
Message-ID: <550C34A5.9050901@gmail.com> (raw)
In-Reply-To: <CAGm1_ksmOPhJ=esbHJWy1TwfUS0gv35E0pxpPyQw1sjthT93CA@mail.gmail.com>

Hi,

On 03/20/2015 12:24 PM, Yegor Yefremov wrote:
> I've also put printf() into omap_nand_read_prefetch8() just to make
> sure it is called - it was called.

Does it fall back to polled mode because the engine is busy maybe? See
the comment in the code that deals with the return value of
__read_prefetch_aligned(). Not that I'd be aware of such an issue, but
maybe you need to enable to enable some module or clock?

> Further ideas?

It's been a while, but when I worked on cutting down the boot times of a
custom AM335x board months ago, these were the steps that I took:


* I tweaked the NAND timing values in the DTS, and then looked at the
GPMC timing values Linux calculated from that and copied it over to
U-Boot. This gave a NAND read speed-up of ~20-30% in comparison to the
defaults U-Boot ships with.

* Implementing the GPMC prefetch operations boosted the speed by of raw
NAND reads by approximately factor 2.

* The NAND bad block table scan was reduced to the first 64 blocks,
because this is all I cared for from U-Boot anyway, and Linux will do
the same anyway at a later point. This brought down the scan process
from ~2s to some milliseconds.

* In the SPL code, the CPU was put in GHz mode as early as possible.
That improved load times again, and also reduced the time spent in the
kernel decompressor.

> I Linux I had ti,nand-xfer-type = "polled";. After replacing it with
> ti,nand-xfer-type = "prefetch-polled"; I now get
> 
> # dd if=/dev/mtdblock5 of=/dev/null bs=2M count=8
> 8+0 records in
> 8+0 records out
> 16777216 bytes (17 MB) copied, 2.58744 s, 6.5 MB/s
> 
> instead of:
> 
> # dd if=/dev/mtdblock5 of=/dev/null bs=2M count=8
> 8+0 records in
> 8+0 records out
> 16777216 bytes (17 MB) copied, 6.05157 s, 2.8 MB/s
> 
> Do I see it right, that DMA support is not implemented in am33xx.dtsi?

Right, I just double-checked with the DTS we were using. It had no
specific "ti,nand-xfer-type" setting, so it should default to
"prefetch-polled". So it seems DMA is not in place for this board and
the gpmc-nand driver. Sorry for the confusion.


Daniel

  parent reply	other threads:[~2015-03-20 14:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19 13:41 [U-Boot] am335x: GPMC: reading speed with prefetch mode Yegor Yefremov
2015-03-19 13:56 ` Daniel Mack
2015-03-19 15:13   ` Yegor Yefremov
2015-03-19 15:56     ` Daniel Mack
2015-03-20 11:24       ` Yegor Yefremov
2015-03-20 12:37         ` Roger Quadros
2015-03-20 13:37           ` Yegor Yefremov
2015-03-20 14:05             ` Roger Quadros
2015-03-20 15:09               ` Tony Lindgren
2015-03-20 14:54         ` Daniel Mack [this message]
2015-03-20 15:06           ` Yegor Yefremov

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=550C34A5.9050901@gmail.com \
    --to=zonque@gmail.com \
    --cc=u-boot@lists.denx.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