On Mon, Mar 18, 2013 at 5:50 PM, Paul B. Henson <hen...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
