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

[Marek Vasut]

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.
> 
> If you look at the mx28_nand_fcb_block() that generates the FCB block,
> it calls memset() to fill the entire 2112 bytes with zero. The
> mx28_nand_fcb struct is 512 bytes, so the copy to copy the fcb struct to
> the buffer at offset 12, and then the code to write the fcb ecc at
> offset 512+12 only writes the first 1036 bytes. The remaining bytes,
> including the OOB, will all be zero. A zero byte in the first OOB byte
> makes the NAND block as bad. Burning the mxsboot generated image with
> nand write.raw makes the blocks bad because it fills the OOB section
> with all zero.
> 
> It seems possibly either the FCB's should each be written separately,
> not overwriting the OOB area, or the image containing them needs to be
> aligned correctly and have proper OOB data?

I'll take one more stab at reading this tomorrow.

> The TL;DR summary is simply that mxsboot generates the image with
> misaligned FCB's and invalid OOB data.
> 
> While we're on the subject of mx28evk, I posted a couple simple
> questions to the list that I didn't see responses to; perhaps one of you
> guys knows the answers off the top of your head?

CC me and Fabio, then you have good chance of having them answered.

> First, I was wondering why the mx28evk board config doesn't define
> CONFIG_FIT? It seemed like that was the new preferred image format as
> opposed to the legacy image, when I added it seems to work fine so I
> wasn't sure why it's not there by default.

It's just disabled as we use uImage on those boards. Sure, you can enable FIT 
image and yes, it's the new preffered format.

> Second, the config defines a load address for the kernel and device
> tree, but none for a ramdisk image. Is there any particular address that
> would be best for that that could perhaps be added to the default
> environment?

I don't know many people who still use ramdisk, but any address above kernel 
works.

Best regards,
Marek Vasut