[Android Software/Hacking General [Developers Only]] Mm7:
I'm testing on recovery environment (CWM 6 [cm-11.0 branch of androidarmv6]), my kernel is psyke83's 3.0.31 (jb_chocolate) kernel + 3 cooper support commits.

I applied this patch.

NOTE: fsr is not insmodded

Some info:

Insmod

<6>[ 41.065544] msm_nand_probe: phys addr 0xa0a00000
<6>[ 41.065569] msm_nand_probe: dmac 0x7
<6>[ 41.065619] msm_nand_probe: allocated dma buffer at ffdde000, dma_addr 2522a000
<6>[ 41.065716] status: 20
<6>[ 41.065728] nandid: d100d1 maker d1 device 00
<3>[ 41.065749] ERROR: unknown nand device manuf=d1 devid=0
<6>[ 41.065779] SFLASHC Async Mode bit: 0
<6>[ 41.065823] =================================================================
<6>[ 41.065838] flash_onenand_probe: manufacturer_id = 0xec
<6>[ 41.065849] flash_onenand_probe: device_id = 0x50
<6>[ 41.065861] flash_onenand_probe: version_id = 0x241 // galaxy5 here reports 0x13e
<6>[ 41.065873] flash_onenand_probe: data_buf_size = 0x800
<6>[ 41.065884] flash_onenand_probe: boot_buf_size = 0x200
<6>[ 41.065896] flash_onenand_probe: num_of_buffers = 0x101
<6>[ 41.065908] flash_onenand_probe: technology = 0x0
<6>[ 41.065918] =================================================================
<6>[ 41.065931] Found a supported onenand device
<5>[ 41.065949] Creating 14 MTD partitions on "msm_nand":
<5>[ 41.065974] 0x000000000000-0x000000180000 : "mibib"
<6>[ 41.067208] mtd: Giving out device 0 to mibib
<5>[ 41.068449] 0x000000180000-0x000000200000 : "qcsbl"
<6>[ 41.069323] mtd: Giving out device 1 to qcsbl
<5>[ 41.070398] 0x000000200000-0x0000002c0000 : "oemsbl"
<6>[ 41.071351] mtd: Giving out device 2 to oemsbl
<5>[ 41.072453] 0x0000002c0000-0x000001bc0000 : "amss"
<6>[ 41.073318] mtd: Giving out device 3 to amss
<5>[ 41.074399] 0x000001bc0000-0x0000024c0000 : "efs2"
<6>[ 41.075269] mtd: Giving out device 4 to efs2
<5>[ 41.076348] 0x0000024c0000-0x0000029c0000 : "nv_backup"
<6>[ 41.077188] mtd: Giving out device 5 to nv_backup
<5>[ 41.078196] 0x0000029c0000-0x000002bc0000 : "arm11boot"
<6>[ 41.079064] mtd: Giving out device 6 to arm11boot
<5>[ 41.080109] 0x000002bc0000-0x0000033c0000 : "boot"
<6>[ 41.081036] mtd: Giving out device 7 to boot
<5>[ 41.082081] 0x0000033c0000-0x000003bc0000 : "recovery"
<6>[ 41.082978] mtd: Giving out device 8 to recovery
<5>[ 41.084016] 0x000003bc0000-0x000003c80000 : "parameter"
<6>[ 41.084919] mtd: Giving out device 9 to parameter
<5>[ 41.085981] 0x000003c80000-0x000004280000 : "fota"
<6>[ 41.086868] mtd: Giving out device 10 to fota
<5>[ 41.087956] 0x000004280000-0x000011bc0000 : "system"
<6>[ 41.088869] mtd: Giving out device 11 to system
<5>[ 41.089961] 0x000011bc0000-0x00001d800000 : "userdata"
<6>[ 41.090971] mtd: Giving out device 12 to userdata
<5>[ 41.092133] 0x00001d800000-0x00001f500000 : "cache"
<6>[ 41.093076] mtd: Giving out device 13 to cache

cat /proc/mtd

dev: size erasesize name
mtd0: 00180000 00040000 "mibib"
mtd1: 00080000 00040000 "qcsbl"
mtd2: 000c0000 00040000 "oemsbl"
mtd3: 01900000 00040000 "amss"
mtd4: 00900000 00040000 "efs2"
mtd5: 00500000 00040000 "nv_backup"
mtd6: 00200000 00040000 "arm11boot"
mtd7: 00800000 00040000 "boot"
mtd8: 00800000 00040000 "recovery"
mtd9: 000c0000 00040000 "parameter"
mtd10: 00600000 00040000 "fota"
mtd11: 0d940000 00040000 "system"
mtd12: 0bc40000 00040000 "userdata"
mtd13: 01d00000 00040000 "cache"

Tests:

I tried to dump 2 partitions (to check if read function work): mtd13 and mtd8

mm7@pc5:~/test/mtd$ adb shell
~ # cd /sdcard/mtd_test
/storage/sdcard0/mtd_test # dd if=/dev/mtd/mtd13 of=mtd13.img bs=4096
7424+0 records in
7424+0 records out
30408704 bytes (29.0MB) copied, 10.068222 seconds, 2.9MB/s
/storage/sdcard0/mtd_test # dd if=/dev/mtd/mtd8 of=mtd8.img bs=4096
2048+0 records in
2048+0 records out
8388608 bytes (8.0MB) copied, 3.365025 seconds, 2.4MB/s
/storage/sdcard0/mtd_test # exit
mm7@pc5:~/test/mtd$ adb pull /sdcard/mtd_test/mtd13.img
4709 KB/s (30408704 bytes in 6.305s)
mm7@pc5:~/test/mtd$ adb pull /sdcard/mtd_test/mtd8.img
4712 KB/s (8388608 bytes in 1.738s)
mm7@pc5:~/test/mtd$ md5sum mtd8.img mtd13.img
e15d10332610037e8cbf2087e95dafa2 mtd8.img
94d0a523bcb0e2d63289fbc703258b6d mtd13.img
mm7@pc5:~/test/mtd$

This *seem* ok, but look at this:

mm7@pc5:~/test/mtd$ ls -la mtd8.img mtd13.img
-rw-r--r-- 1 mm7 mm7 30408704 Aug 19 23:39 mtd13.img
-rw-r--r-- 1 mm7 mm7 8388608 Aug 19 23:39 mtd8.img
mm7@pc5:~/test/mtd$ cp mtd13.img mtd13.img.bk
mm7@pc5:~/test/mtd$ truncate mtd13.img --size=8388608
mm7@pc5:~/test/mtd$ md5sum mtd8.img mtd13.img
e15d10332610037e8cbf2087e95dafa2 mtd8.img
e15d10332610037e8cbf2087e95dafa2 mtd13.img
mm7@pc5:~/test/mtd$

This is strange! :confused: But can be explained:

I hexdumped mtd8.img and I discovered that the entire file is a repetition of a fixed sequence of bytes! I found the same sequence also in mtd13.img. This explains why md5sum are equals (if I truncate files at the same size).

The sequence length is 0x1000 (4096), the same as page size.

I think that the read function doesn't set the page address properly, so It will read always the same bytes from data ram. Erikcas in this post reported a problem in dumping.. maybe he was getting my same issue. Unfortunately the links to those files are dead so I can't check.

The mystery is why page address is set properly for galaxy5 and not for cooper! Perhaps cooper set page address in a different way and nobody added support to it?

Naturally I assume that my conjecture about page address is right.. maybe the problem is somewhere else!