From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Sat, 4 May 2013 02:08:21 +0200
Subject: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad
	blocks
In-Reply-To: <517EDE05.1000805@acm.org>
References: <5147B63F.4020407@acm.org> <201304260313.33532.marex@denx.de>
	<517EDE05.1000805@acm.org>
Message-ID: <201305040208.21223.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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