i.MX25 NFC with 8 bit ecc strength
Baruch Siach
baruch at tkos.co.il
Mon Apr 20 23:24:28 PDT 2015
Hi Uwe,
On Mon, Apr 20, 2015 at 05:48:18PM +0200, Uwe Kleine-König wrote:
> On Mon, Apr 20, 2015 at 12:11:30PM +0300, Baruch Siach wrote:
> > On Mon, Apr 20, 2015 at 09:37:02AM +0200, Uwe Kleine-König wrote:
> > > On Mon, Apr 20, 2015 at 07:56:14AM +0300, Baruch Siach wrote:
> > > > I'm trying to get nand_ecclayout right on i.MX25 with the Micron
> > > > MT29F8G08ABABA (page size: 4096, oob size: 224). The large OOB size
> > > > allows using hardware ecc strength of 8bit per ecc step (512 bytes).
> > > > The mxc_nand driver code (get_eccsize()) and the reference manual
> > > > seems to indicate that enabling 8 bit ecc mode requires 26 oob bytes
> > > > per ecc step. However, this seems to contradict the actual hardware
> > > > test as the shown in the dump
> > > > below of a zero filled page + oob:
> > > >
> > > > # hexdump -C dump4
> > > > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > > > *
> > > > 00001000 ff ff ff ff ff ff ff 91 c4 45 be 32 45 6f 5d b1 |.........E.2Eo].|
> > > > 00001010 b1 b9 13 61 59 7d 42 58 eb ff ff ff ff ff ff ff |...aY}BX........|
> > > > 00001020 ff ff ff 91 c4 45 be 32 45 6f 5d b1 b1 b9 13 61 |.....E.2Eo]....a|
> > > > 00001030 59 7d 42 58 eb ff ff ff ff ff ff ff ff ff ff 91 |Y}BX............|
> > > > 00001040 c4 45 be 32 45 6f 5d b1 b1 b9 13 61 59 7d 42 58 |.E.2Eo]....aY}BX|
> > > > 00001050 eb ff ff ff ff ff ff ff ff ff ff 91 c4 45 be 32 |.............E.2|
> > > > 00001060 45 6f 5d b1 b1 b9 13 61 59 7d 42 58 eb ff ff ff |Eo]....aY}BX....|
> > > > 00001070 ff ff ff ff ff ff ff 91 c4 45 be 32 45 6f 5d b1 |.........E.2Eo].|
> > > > 00001080 b1 b9 13 61 59 7d 42 58 eb ff ff ff ff ff ff ff |...aY}BX........|
> > > > 00001090 ff ff ff 91 c4 45 be 32 45 6f 5d b1 b1 b9 13 61 |.....E.2Eo]....a|
> > > > 000010a0 59 7d 42 58 eb ff ff ff ff ff ff ff ff ff ff 91 |Y}BX............|
> > > > 000010b0 c4 45 be 32 45 6f 5d b1 b1 b9 13 61 59 7d 42 58 |.E.2Eo]....aY}BX|
> > > > 000010c0 eb ff ff ff ff ff ff ff ff ff ff 91 c4 45 be 32 |.............E.2|
> > > > 000010d0 45 6f 5d b1 b1 b9 13 61 59 7d 42 58 eb ff ff ff |Eo]....aY}BX....|
> > > >
> > > > As you can easily see, ecc steps start at 28 bytes interval, with 18
> > > > bytes for ecc (matches documentation), and 10 bytes free.
> > > How did you extract this page+oob from the nand flash? From Linux I
> > > assume?
> >
> > Got it form nanddump using:
> >
> > nanddump -s 5238784 -f dump4 -o /dev/mtd2
> OK, then there is also the driver in between the hardware and your
> image. Can you show the changes you did to mxc_nand?
I generated the dump above on an old kernel (v2.6.36.4) that includes a number
of changes needed to support 4K pages and large OOB.
I have generated an almost exact same dump using v4.0-rc1 based l2-mtd master
as of d09957fbb4d (which includes your mxc_nand ONFI support code; works
perfectly, BTW). My only local change is commenting out the copy_spare() call
in the NAND_CMD_PAGEPROG case at mxc_nand_command().
> > > Can you try from barebox something like:
> > >
> > > mw -w 0xbb001e08 0x0000 # READ0
> > > mw -w 0xbb001e1c 0x01 # CMD cycle
> > > mw -w 0xbb001e06 0x00 # Address = 0
> > > mw -w 0xbb001e1c 0x02 # Address cycle
> > > mw -w 0xbb001e1c 0x02 # Address cycle
> > > mw -w 0xbb001e1c 0x02 # Address cycle (do we need three? [1])
> > > mw -w 0xbb001e04 0x00
> > > mw -w 0xbb001e1c 0x08 # NAND OUTPUT
> > > md -w 0xbb000000+0x10f0
> > >
> > > with ecc being disabled (i.e. CONFIG1, bit 3 = 0). Does this show the 28
> > > bytes offset, too?
> >
> > I (hopefuly) disabled ECC with:
> >
> > mw -w 0xbb001e1a 0x0010
> looks ok.
>
> > Then, for the same page (using three address cycles, 0xff, 0x04, 0x00), I got
> > all zeros up to 0xbb001000 (inclusive), and then:
> >
> > bb001010: 0000 0000 0000 0000 0000 ffff 28a7 428a .............(.B
> > bb001020: 89fa 2cd4 4640 560a 2634 ac7e e5d8 20ea ..., at F.V4&~....
> > bb001030: caaa c809 0195 8411 6972 6bfc 84d6 10af ........ri.k....
> > bb001040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> > bb001050: 0000 0000 0000 0000 0000 ffff f1da 19c3 ................
> > bb001060: 21b2 0832 09c6 3c55 638c 3bb8 fd54 2983 .!2...U<.c.;T..)
> > bb001070: 8325 6d98 0814 0d64 ee73 675e 1943 5cf2 %..m..d.s.^gC..\
> > bb001080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> > bb001090: 0000 0000 0000 0000 0000 ffff c1bc 31fe ...............1
> > bb0010a0: 16ee ab6b 34a5 acad 0771 048c ac58 3f19 ..k..4..q...X..?
> > bb0010b0: b699 a88f eb5a 00ae 7e3c 9c6d 2ba8 d72e ....Z...<~m..+..
> > bb0010c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> > bb0010d0: 0000 0000 0000 0000 0000 ffff ae14 06c7 ................
> > bb0010e0: 89b9 eb67 00d0 3648 daeb 15f5 77ca 8c09 ..g...H6.....w..
>
> This is more or less expected. The "more" part is: Matching the hardware
> description the (virtual) spare area is sorted into the spare area
> buffers, so the first spare area is written to 0xbb001000, the 2nd to
> 0xbb001040 etc. (See table 36-3 in the manual.) So probably it's the
> driver who doesn't get the sorting right.
OK. I see what you mean. The 28 bytes interval has noting to do with hardware.
It comes from this line in copy_spare():
j = (mtd->oobsize / n >> 1) << 1;
In my case oobsize = 224, and n = 8 (512 bytes steps), so j == 28. This means
that we must generate nand_ecclayout at run time according to the actual
oobsize. This is probably also true for the 4 bit ecc case.
> The "less" part however is that the data doesn't match what you see in
> linux with nanddump. Hmm.
>
> Can you retry the above commands after initializing the NFC buffer with
> some pattern:
>
> memset -w 0xbb000000 0x55 0x1200
With this I get:
bb001010: 0000 0000 0000 0000 0000 5555 5555 5555 ..........UUUUUU
bb001020: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
bb001030: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
bb001040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
bb001050: 0000 0000 0000 0000 0000 5555 5555 5555 ..........UUUUUU
bb001060: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
bb001070: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
bb001080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
bb001090: 0000 0000 0000 0000 0000 5555 5555 5555 ..........UUUUUU
bb0010a0: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
bb0010b0: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
bb0010c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
bb0010d0: 0000 0000 0000 0000 0000 5555 5555 5555 ..........UUUUUU
bb0010e0: 5555 5555 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUUUUUU
with anything else zero filled. This is probably misleading, since I get the
same output (i.e. all zeros) even for pages that contain data.
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
More information about the linux-mtd
mailing list