[U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

[Trent Piepho]

On Mon, Mar 18, 2013 at 5:50 PM, Paul B. Henson <henson at acm.org> wrote:
> I'm prototyping a project that's going to need to boot linux from NAND on a
> mx28evk board.
>
> I was able to successfully use the u-boot mxsboot utility to generate a nand
> image and burn it, then boot from it. I noticed one anomaly though, when
> using mxsboot/u-boot to generate and burn the bootstream to NAND, when the
> linux kernel boots it finds bad blocks:
>
> [    1.090000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1 (Micron
> MT29F14
> [    1.100000] Scanning device for bad blocks
> [    1.110000] Bad eraseblock 0 at 0x000000000000
> [    1.110000] Bad eraseblock 1 at 0x000000020000
> [    1.120000] Bad eraseblock 2 at 0x000000040000
> [    1.120000] Bad eraseblock 3 at 0x000000060000
>
> When I burn the exact same bootstream with kobs-ng, linux does not find any
> bad blocks, so it seems to be a byproduct of either the image generated by
> mxsboot or the u-boot burning.

I get the same problem, with an iMX28 based board and the same NAND
chip (correct name MT29F1G08ABADAWP, MT29F14 is from serial terminal
line wrapping).

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
blocks, the chip is supposed to guarantee that block 0 is not bad, and
those four blocks contain all copies of the FCB so if they were all
bad you couldn't boot.

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.  It's
not entirely clear to me if the ROM bootloader uses the OOB data in
the FCB blocks or not, which pages used by the ROM are BCH encoded,
and how the that affects the OOB data.

You said you've booted from NAND.  Did you have to program any of the
OTP fuses to do this?  Try as I might, the ROM bootloader refuses to
accept anything I flash into NAND.  Of course the error code doesn't
tell you WHY it didn't like the image.  One thing I found was the
OCOTP fuse bits for NAND_ROW_ADDRESS_BYTES.  The default is for 3
bytes of row address.  Yet the MT29F1 has 2 bytes of row address.  Did
you program the fuse bits to change the number of row address bytes to
two?

> I don't think this is having any functional impact, as the scrub component
> of burning a new nand image wipes out the bad blocks, and once linux is
> booted it really has no need to read the bootstream from the bootloader mtd
> partition.

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.