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

[Paul B. Henson]

On 4/11/2013 5:03 AM, Trent Piepho wrote:

> I'm talking about the image file as generated by mxsimage.  If I hex
>  dump that, it's clearly written entirely with 2048 byte pages.  If
> you hexdump your image are the FCB blocks exactly 128k apart?

Hmm, I don't have one in front of me to conveniently look at, but as I
recall when I was working with it the FCB blocks did indeed appear to be
evenly spaced at locations divisible by 1k.

> Looks wrong to me!  Notice that offset is equal to i *
> nand_writesize, not i * (nand_writesize + nand_oobsize).

Ah, good eye. They are writing the the correct amount of data, but in
the wrong places.

> All the rest are corrupted since they are written in the wrong
> location.  But since the first one was ok the bootloader never even
> looks at the bad ones.  Unless the NAND page goes bad, then the whole
>  point of having redundant copies will be defeated.

That sounds like a correct conclusion.

> What one should actually do to flash these blocks is write 2048 bytes
> in raw mode.

I guess that would only work if whatever reading the blocks also read 
them in raw mode, as otherwise the lack of ECC in the OOB area would 
fail the read?

> If the four blocks were already marked as bad, then nandwrite will
> not write them. So maybe you only have a working image because it
> was already working and wasn't modified?  Can you erase flash in
> u-boot, verify that nand does not boot, and the make a working nand
> using just nandwrite --oob?  I think you will also need to use the
> option --noecc to write in raw mode.

I did actually erase the NAND before testing the burn in Linux, so I can 
confirm it does actually work – the first time. After the first burn, 
the next time Linux is booted, it detects the blocks as bad, and will 
not overwrite them, even in raw mode. I unfortunately did not make good 
notes, and don't recall the specific flags I used with nandwrite during 
the test.

> I've done that before.  The u-boot env was written from Linux to tell
>  u-boot which kernel to boot, the firmware update kernel and rootfs
> or the main kernel and rootfs.

I think we're going to always have u-boot boot the recovery kernel and 
have that bootstrap the production kernel. We plan to have a physical 
reset button on the device, which if held down when powered on will 
reset the device to factory defaults. The recovery kernel will check if 
that button is pressed when it loads and rewrite the production area of 
the flash if so from a recovery partition, otherwise just load the 
production kernel.

Hopefully Otavio is watching this thread and can address the issues you 
found with mxsboot.

Thanks much…