public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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.

  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