From: jbe@pengutronix.de (Juergen Beisert)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mx31pdk: Add NAND support
Date: Fri, 26 Feb 2010 10:56:36 +0100 [thread overview]
Message-ID: <201002261056.37618.jbe@pengutronix.de> (raw)
In-Reply-To: <210155.75899.qm@web51001.mail.re2.yahoo.com>
Fabio Estevam wrote:
> > Are you sure that this works? Don't you see a lot of Bad
> > blocks reports
> > in boot messages?
>
> I followed the same approach used on other i.MX boards. This is what I see:
> ...
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V
> 8-bit) Scanning device for bad blocks
> Bad eraseblock 42 at 0x000000540000
> Bad eraseblock 125 at 0x000000fa0000
> Bad eraseblock 887 at 0x000006ee0000
> Bad eraseblock 1750 at 0x00000dac0000
> Bad eraseblock 2046 at 0x00000ffc0000
> Bad eraseblock 2047 at 0x00000ffe0000
> Registering mxc_nand as whole device
>
> If I define it as:
>
> static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> .width = 1,
> .hw_ecc = 1,
> .flash_bbt =1,
> };
Your bootloader also use a Bad Block Table? Then also your kernel should use
it. If hardware ECC is in use, its always a good idea to collect the bad
blocks into a BBT. Most of the time you can't control at which offset in the
OOB data the NAND controller will store the ECC sum. There is the risk it
will destroy manufacturer's bad block markers. So, its better to collect
these marked bad blocks into a BBT the first time you use the NAND device.
After that _only_ the BBT should be used to handle bad blocks (in the boot
loader and the kernel).
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2010-02-26 9:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 0:58 [PATCH] mx31pdk: Add NAND support Fabio Estevam
2010-02-25 10:58 ` Alberto Panizzo
2010-02-25 22:09 ` Fabio Estevam
2010-02-26 9:36 ` Uwe Kleine-König
2010-02-26 10:19 ` Alberto Panizzo
2010-02-26 10:46 ` Uwe Kleine-König
2010-02-26 11:05 ` Alberto Panizzo
2010-02-26 13:14 ` Ivo Clarysse
2010-02-25 11:12 ` Alberto Panizzo
2010-02-25 21:59 ` Fabio Estevam
2010-02-25 22:19 ` Alberto Panizzo
2010-02-26 9:56 ` Juergen Beisert [this message]
2010-02-26 10:33 ` Alberto Panizzo
2010-02-26 11:48 ` Juergen Beisert
2010-02-26 13:29 ` Alberto Panizzo
2010-02-26 13:40 ` Juergen Beisert
2010-02-27 1:34 ` Fabio Estevam
2010-02-27 14:25 ` Alberto Panizzo
2010-02-27 15:38 ` Fabio Estevam
2010-02-27 16:17 ` Alberto Panizzo
-- strict thread matches above, loose matches on Subject: below --
2010-02-25 22:22 Fabio Estevam
2010-02-25 22:33 ` Alberto Panizzo
2010-02-25 22:52 ` Fabio Estevam
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=201002261056.37618.jbe@pengutronix.de \
--to=jbe@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.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).