All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chin Liang See <clsee@altera.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] mtd: denali: improve nand_read_oob and fix nand_write_oob
Date: Wed, 23 Apr 2014 02:15:10 -0500	[thread overview]
Message-ID: <1398237310.4007.3.camel@clsee-VirtualBox.altera.com> (raw)
In-Reply-To: <1398193920.1694.219.camel@snotra.buserror.net>

On Tue, 2014-04-22 at 14:12 -0500, Scott Wood wrote:
> On Tue, 2014-04-22 at 10:04 +0900, Masahiro Yamada wrote:
> > Hi Scott,
> > 
> > 
> > > > It is really really painful to wait more than 10 seconds just for bad block
> > > > scanning to boot Linux.
> > > 
> > > Making bad block scans faster is a good thing, but why do you need to
> > > scan them just to boot Linux?  Aren't you using an on-flash BBT?
> > 
> > I did not know that.
> > I thought all blocks must be scanned.
> > 
> > Could you teach me the better way?
> 
> If you use NAND_BBT_USE_FLASH, and NAND_BBT_CREATE is present in the bbt
> descriptor (this is true of the default descriptors), then the scanning
> should only need to happen on first use.  On subsequent boots only the
> bad block table should need to be read.

Yup, I agreed with this statement :) I believe this bad block table can
be used by kernel in later stage. Probably someone can comment if I am
wrong.

Thanks
Chin Liang

> 
> -Scott
> 
> 

  reply	other threads:[~2014-04-23  7:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-18 11:30 [U-Boot] [PATCH 1/2] mtd: denali: improve nand_read_oob and fix nand_write_oob Masahiro Yamada
2014-04-18 11:30 ` [U-Boot] [PATCH 2/2] mtd: denali: recover the same function prototypes as Linux Kernel Masahiro Yamada
2014-04-23  7:02   ` Chin Liang See
2014-04-21 22:21 ` [U-Boot] [PATCH 1/2] mtd: denali: improve nand_read_oob and fix nand_write_oob Scott Wood
2014-04-22  1:04   ` Masahiro Yamada
2014-04-22 19:12     ` Scott Wood
2014-04-23  7:15       ` Chin Liang See [this message]
2014-04-24 10:25         ` Masahiro Yamada
2014-04-23  6:50 ` Chin Liang See
2014-04-24 10:20   ` Masahiro Yamada

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=1398237310.4007.3.camel@clsee-VirtualBox.altera.com \
    --to=clsee@altera.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.