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