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… _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
