Hi list,
we have a custom legacy board based on OpenRD platform and using
OpenRD config with slight changes (few GPIOs remapped, slower
SDRAM timing and redundant environment).
Now we had to change to Samsung E-Die NAND for a new assembly, and I
can not write to the NAND any more. Switching to up-to-date U-Boot
(git pull from yesterday's master branch) did not help, even though
I set CONFIG_SYS_NAND_NO_SUBPAGE_WRITE which seems to be one of the
problems. The errors result in ECC errors during read, and I can see
that almost complete garbage is written in the flash. However, the
errors are absolutely reproducible over multiple write and read
attempts as well as old (some early 2010) and current U-Boot version.
(I changed nand->chip_delay to 50 in our old u-boot tree to make it
work at all.)
I am out of ideas, so I try to ask here if anybody has an idea what
might be the problem or where to start further investigation. All I
could find yet are hints to the to-be-increased chip_delay and
CONFIG_SYS_NAND_NO_SUBPAGE_WRITE which I both set at least for the
new U-Boot version.
Here's how I tested this:
tftp 0x800000 192.168.2.88:uImage
nand erase clean 0x200000 0x600000
nand write.jffs2 0x800000 0x200000 ${filesize}
nand read.jffs2 0xb00000 0x200000 0x300000
Data written to flash:
Marvell>> md.b 0x800000 0x80
00800000: 27 05 19 56 ec 84 36 50 54 07 3a d2 00 23 7d e8 '..V..6PT.:..#}.
00800010: 00 00 80 00 00 00 80 00 83 23 fb 58 05 02 02 00 .........#.X....
00800020: 4c 69 6e 75 78 2d 32 2e 36 2e 33 36 2d 73 76 6e Linux-2.6.36-svn
00800030: 33 34 38 30 32 00 00 00 00 00 00 00 00 00 00 00 34802...........
00800040: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 ................
00800050: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 ................
00800060: 02 00 00 ea 18 28 6f 01 00 00 00 00 e8 7d 23 00 .....(o......}#.
00800070: 01 70 a0 e1 02 80 a0 e1 00 20 0f e1 03 00 12 e3 .p....... ......
Data read back from flash:
Marvell>> md.b 0xb00000 0x80
00b00000: ff ff fd ff ff ff ff ff ff ff 3a d2 ff ff ff ff ..........:.....
00b00010: 00 00 80 00 00 00 ff ff ff ff fb 58 ff ff ff ff ...........X....
00b00020: 4c 69 6e 75 ff ff ff ff ff ff 33 36 ff ff 76 6e Linu......36..vn
00b00030: ff ff 38 30 ff ff ff ff ff ff ff ff 00 00 00 00 ..80............
00b00040: ff ff ff ff ff ff ff ff ff ff a0 e1 ff ff ff ff ................
00b00050: 00 00 a0 e1 00 00 ff ff ff ff a0 e1 ff ff ff ff ................
00b00060: 02 00 00 ea ff ff ff ff ff ff 00 00 ff ff 23 00 ..............#.
00b00070: ff ff a0 e1 ff ff ff ff ff ff ff ff 03 00 12 e3 ................
I can not recognize an actual pattern here, although some portions
seem regularly aligned.
When writing the same image using openocd (also some prehistoric
version dating back 2010.06), there are also errors, but only
very few single bit errors:
Marvell>> cmp.b 0x800000 0xb00000 0x237e28
byte at 0x008a923b (0x16) != byte at 0x00ba923b (0x12)
Total of 692795 byte(s) were the same
Marvell>cmp.b 0x8b0000 0xbb0000 0x187e28
byte at 0x0093983f (0x2a) != byte at 0x00c3983f (0x28)
Total of 563263 byte(s) were the same
[...]
Does all this sound familiar to anybody?
Any help is greatly appreciated!
Best regards,
Wolfgang
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
