From: Sascha Hauer <s.hauer@pengutronix.de>
To: Marcus Folkesson <marcus.folkesson@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: Problem with nand_mxs driver
Date: Sun, 16 Sep 2012 22:30:37 +0200 [thread overview]
Message-ID: <20120916203037.GK6180@pengutronix.de> (raw)
In-Reply-To: <CAM8FrKKCQE7TkEEP3_2GwCA+nDYYY+C-SaYKDGiF_oCovkYSOQ@mail.gmail.com>
On Sun, Sep 16, 2012 at 01:06:34PM +0200, Marcus Folkesson wrote:
> Hi there,
>
> We are currently using a iMX23 EVK board while waiting for our "real" hardware.
> Unfortunately, we are not getting the NAND-flash to work properly.
> The NAND-flash is a 4GiB chip from Samsung, K9HCG08U1D.
>
> After we applied the patch "[PATCH] mtd: nand: extend NAND flash
> detection to new MLC chips" (please see mailing list), the NAND-flash
> shows up with right page- and oob-size.
> But we are getting error code EBADMSG (-74) when trying to read from
> the NAND-flash.
> The error shows up roughly every other time we accessing the chip for reading.
>
> See the dump below:
[...]
>
>
> Status description:
> 0x00, No errors found
> 0xFF, Block is erased
> 0xFE, Block is uncorrectable
>
> If I print the status and the read fails, It is allways status[0] and
> status[1] that is == 0xFE.
> The other statuses are.... 0xFF (block erased?!) as i remember, will
> check this at work tomorrow.
>
> I find it _very_ unlikely that the first two blocks have errors on all
> partitions on different EVK boards.
>
>
> Is it something wrong with the BCH handling in the driver?
> Is it an effect of the zeroed ecc-layout? (see probe-function)
>
> Does anyone recognize the problem or have a guess of what it could be?
First of all this driver is (at least here @pengutronix) only tested on
an i.MX28.
The gpmi nand controller unfortunately does not read the nand main+oob
area in the order it is supposed to. This means that the (factory) bad
block marker is not at the place the mtd layer expects it. To work
around this the gpmi driver swaps the place the factory bad block marker
with another byte on the nand.
This means that all code accessing the flash must agree which bytes to
swap. Which code has written the pages that now seem bad? Was it barebox
or a FSL U-Boot? Can barebox read the pages that it has written itself?
Grep for 'swap' in the nand drivers.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2012-09-16 20:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-16 11:06 Marcus Folkesson
2012-09-16 20:30 ` Sascha Hauer [this message]
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=20120916203037.GK6180@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=marcus.folkesson@gmail.com \
/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