From: Paul B. Henson <henson@acm.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks
Date: Fri, 05 Apr 2013 21:28:53 -0700 [thread overview]
Message-ID: <515FA485.1090709@acm.org> (raw)
In-Reply-To: <CA+7tXigZk+Q6ZXdXb96KGTYUUpSwMNY1z9Mu_tZc9R7fVX+pgQ@mail.gmail.com>
On 4/4/2013 3:09 AM, Trent Piepho wrote:
> It's something to do with the way u-boot writes to nand. If I write
> with nandwrite it doesn't happen, nandtest doesn't find any bad
Hmm, I'm pretty sure I tested burning the u-boot generated nand image
with nandwrite under Linux with exactly the same result, it seems to be
inherent in the underlying data, not the burn method.
Did you use the --oob option to nandwrite? The u-boot generated image is
actually written in two separate steps, the initial piece is written raw
and includes oob data, the second piece is written normally and the
ecc/oob is generated by the hardware. To burn it under linux, you need
to split the u-boot nand image into those two pieces, and write the
first with -oob, and the second normally.
> A bad block on that chip is marked with a non-0xff as the first OOB
> byte in the 1st page of a block. So, my guess is that when u-boot
> writes the FCB data it also writes something to the OOB data.
Yes, as would linux if you used the --oob option to nandwrite.
> You said you've booted from NAND. Did you have to program any of the
> OTP fuses to do this?
No. All I did was install the actual NAND chip and update the boot dip
switches. Testing u-boot, I followed the script in the default
environment other than updating it to load the firmware from SD rather
than tftp. For testing under Linux, I used dd to split the u-boot nand
image into two pieces, corresponding to the u-boot burn instructions.
> nandwrite didn't seem to want to program the blocks after they were
> marked bad. The only way fix this seemed to be to scrub nand from
> u-boot. So it's a problem if you want to be able to flash the
> bootloader from Linux, unless there is some way to get the blocks
> written when they have been marked bad.
No, from what I understand there is no way to clear bad block markers
from within linux short of modifying the mtd driver.
I followed up with Otavio off list, he said he had ordered some nand
chips for his board and would get back to me once he had received them
and had a chance to replicate the issue.
Are you targeting burning the nand with u-boot or linux? If you are
using an older kernel, the kobs-ng that comes with the mx28 BSP works
fine. It does not work with newer kernels though, there is a newer
version of kobs-ng that comes with a different chip BSP that I've heard
will work correctly on current kernels, it is on my to do list to try it
out.
next prev parent reply other threads:[~2013-04-06 4:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-19 0:50 [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks Paul B. Henson
2013-03-19 23:23 ` Scott Wood
2013-03-20 21:20 ` Paul B. Henson
2013-03-20 21:24 ` Scott Wood
2013-04-04 10:09 ` Trent Piepho
2013-04-06 4:28 ` Paul B. Henson [this message]
2013-04-06 7:18 ` Trent Piepho
2013-04-11 0:20 ` Paul B. Henson
2013-04-11 12:03 ` Trent Piepho
2013-04-11 18:33 ` Paul B. Henson
2013-04-11 23:25 ` Trent Piepho
2013-04-20 1:03 ` Paul B. Henson
2013-04-20 1:22 ` Trent Piepho
2013-04-23 0:42 ` Paul B. Henson
2013-04-26 1:13 ` Marek Vasut
2013-04-29 20:54 ` Paul B. Henson
2013-04-29 21:01 ` Marek Vasut
2013-05-04 0:08 ` Marek Vasut
2013-05-04 6:21 ` Trent Piepho
2013-05-04 13:20 ` Marek Vasut
2013-04-13 14:42 ` Marek Vasut
2013-04-13 16:31 ` Trent Piepho
2013-04-13 18:26 ` Marek Vasut
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=515FA485.1090709@acm.org \
--to=henson@acm.org \
--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