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

[Trent Piepho]

On Fri, May 3, 2013 at 5:08 PM, Marek Vasut <marex at denx.de> wrote:

> > 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?
>

Completely different algorithms.  The BCH ECC is computed on a 512 byte
block at a time using a vastly more complex algorithm.  The 13_8 parity is
only used by the ROM bootloader code for checking the FCB blocks (and maybe
some other boot blocks too?  Not sure about that off the top of head).  It
produces one byte of parity (only 6 bits used I think) for each byte of
data.  This is because the FCB blocks are not in BCH format, as those
blocks contain the BCH parameters that are necessary to decode BCH encoded
blocks.  Thus the FCB blocks are raw so the BCH parameters can be read,
then the rest of the blocks can be in BCH mode.

I think what needs to be done is for u-boot to have a nand write.raw that
writes a block in non-BCH mode WITHOUT writing the OOB data.  Since the OOB
data in the FCB blocks should not actually be written, it's not necessarily
a problem that mxsboot fails to include it in the image.  The problem
really is that u-boot nand write expects it and the image does not have it.