From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v6 2/8] lpc32xx: mtd: nand: add MLC NAND controller
Date: Mon, 23 Mar 2015 20:20:50 -0500 [thread overview]
Message-ID: <1427160050.22867.33.camel@freescale.com> (raw)
In-Reply-To: <20150323094516.5b23f9df.albert.aribaud@3adev.fr>
On Mon, 2015-03-23 at 09:45 +0100, Albert ARIBAUD wrote:
> Bonjour Scott,
>
> Le Fri, 20 Mar 2015 17:41:11 -0500, Scott Wood
> <scottwood@freescale.com> a ?crit :
>
> > On Fri, 2015-03-20 at 10:35 +0100, Albert ARIBAUD wrote:
> > > BTW, is there a standard way to ask a NAND chip which page(s) in a bad
> > > block should be checked?
> >
> > Yes and no:
> > http://lists.infradead.org/pipermail/linux-mtd/2011-November/038419.html
>
> ... right.
>
> How about this: the driver expects a driver-specific configuration
> option which tells it which page(s) in a block, and which byte in a
> page's OOB area, should be scanned for bad block markers, and "my"
> board provides a value for said option.
It looks like the common NAND code will set
NAND_BBT_SCANLASTPAGE/NAND_BBT_SCAN2NDPAGE automatically if it sees
certain manufacturer IDs, so I don't think drivers should be setting
them at all (and currently, none do).
That still leaves the question of what to do in SPL. For simplicity you
could check every page as you do the normal read.
> This leads me to a half-OT question: so those SPL, while too tiny to
> handle non-raw images, still do include the whole common/spl/spl.c
No, there's no room for that.
> > If you want to do this, just put a comment in explaining why you're
> > skipping in that situation.
>
> Ok -- I will go with the 'option' method then, and add a (lengthy, I'm
> afraid) comment in common/spl/spl.c explaining that skipping the raw
> image handling is required when chainloading from NAND and the NAND
> driver considers totally unreadable sectors bad, in order not to
> confuse a missing image header with a raw image.
Skipping raw wouldn't be needed for all NAND drivers, only those that
aren't guaranteed to halt on a legitimate unrecoverable ECC error.
-Scott
next prev parent reply other threads:[~2015-03-24 1:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 9:04 [U-Boot] [PATCH v6 0/8] Extend LPC32xx functionality and add LPC32xx-based work_92015 board Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 1/8] lpc32xx: add Ethernet support Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 2/8] lpc32xx: mtd: nand: add MLC NAND controller Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 3/8] lpc32xx: i2c: add LPC32xx I2C interface support Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 4/8] lpc32xx: add GPIO support Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 5/8] lpc32xx: add LPC32xx SSP support (SPI mode) Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 6/8] dtt: add ds620 support Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 7/8] lpc32xx: add lpc32xx-spl.bin boot image target Albert ARIBAUD
2015-03-18 9:04 ` [U-Boot] [PATCH v6 8/8] lpc32xx: add support for board work_92105 Albert ARIBAUD
2015-03-30 6:30 ` [U-Boot] [PATCH v6 5/8] lpc32xx: add LPC32xx SSP support (SPI mode) Jagan Teki
2015-03-19 21:39 ` [U-Boot] [PATCH v6 2/8] lpc32xx: mtd: nand: add MLC NAND controller Scott Wood
2015-03-20 9:35 ` Albert ARIBAUD
2015-03-20 22:41 ` Scott Wood
2015-03-23 8:45 ` Albert ARIBAUD
2015-03-24 1:20 ` Scott Wood [this message]
2015-03-24 14:12 ` Albert ARIBAUD
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=1427160050.22867.33.camel@freescale.com \
--to=scottwood@freescale.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