Dear Paul B. Henson,
On 4/25/2013 6:13 PM, Marek Vasut wrote:
I didn't really track the thread and I'm plenty busy, besides I had quite a clash with Trent in another thread, sorry about me being plenty unpleasant. Anyway, can you please sum what is going on and what you came up with?
Most of the analysis came from Trent, but I can try to summarize the findings.
One problem is that the current mxsboot misaligns the FCB's:
for (i = 0; i < STRIDE_PAGES * STRIDE_COUNT; i += STRIDE_PAGES) { offset = i * nand_writesize; memcpy(buf + offset, fcbblock, nand_writesize + nand_oobsize); }The code writes out nand_writesize+nand_oobsize bytes, but updates the offset only by nand_writesize, so every FCB but the first one isn't in the right place:
hexdump of the u-boot image: 00000000 00 00 00 00 00 00 00 00 00 00 00 00 d6 fc ff ff
|................|
00000010 46 43 42 20 00 00 00 01 50 3c 19 06 00 00 00 00 |FCB ....P<......|
00020000 00 00 00 00 00 00 00 00 00 00 00 00 d6 fc ff ff
|................|
00020010 46 43 42 20 00 00 00 01 50 3c 19 06 00 00 00 00 |FCB ....P<......|
The first FCB block is at offset 0. The second FCB block is at offset 0x20000, 64 * 2048 bytes, not 64 * 2112 bytes, no OOB data. The next two FCBs are at 0x40000 and 0x60000, again not where they should be if they contained the OOB data.
Another problem is that the OOB section gets zeroed out.
Ok, I see the problem, but I don't see easy solution. For some reason, the BCH doesn't compute the same ECC as mx28_nand_parity_13_8() when writing regular data, do you know why?
Best regards, Marek Vasut