MTD porting for Samsung Galaxy MSM7x27 series

114 posts
Thanks Meter: 250
By Mm7, Senior Member on 20th August 2014, 12:01 AM
Post Reply Subscribe to Thread Email Thread
MTD porting for Samsung Galaxy MSM7x27 series

I'm trying to restore this uncompleted project.

Original thread introduction by psyke83:

Yesterday I discovered a very interesting source release from Samsung:

Normally, there is a shared Samsung source release for the msm7k range of devices (Ace, Mini, Callisto, Beni, Gio; there is also partial support included for my GT-I5500/Europa, but I adapted the source to properly support my phone). All of these devices usually depend on Samsung's proprietary FSR (Flex Sector Remapper) drivers in order to access the flash memory, which are taken from the stock ROMs, but our dependence on this driver locks us into the 2.6.35 kernel since we don't have access to the driver source.

The new source that I found for the GT-S5830G model, however, appears to contain modifications for the purpose of transitioning from Samsung's proprietary FSR driver to the open source MTD (via msm_nand) driver. If this can work correctly, using this driver would be much preferred over the proprietary Samsung stuff.

Here's the source that I uploaded to github:

Some observations that I have made, keeping in mind that I'm testing on my GT-I5500:

There are two separate configs for the cooper rev03 (Galaxy Ace): the standard defconfig that uses fsr/rfs, and a "purenand" config that uses the mtd/yaffs2 drivers instead of fsr/rfs. In other words, it's using the open drivers for flash access. Here is the diff:
The dpram driver (Samsung's driver for communication with baseband, used by RIL) is patched to support MTD instead of BML when the proper config is set.
The drivers/mtd/devices/msm_nand.c driver is modified by Samsung, but they applied their patches to an older revision of msm_nand.c from Froyo. Here is the diff when comparing this file vs the Froyo revision, so you can see more clearly the changes:
By default, the msm_nand.c driver causes the kernel to hang on my device (this is true for both this source and the older 2.6.35 Samsung source not based on purenand). I have isolated the hang to the flash_onfi_probe function.
As you can see here, Samsung added code to bypass this function on the Cooper board, and use the secondary detection method only. If I include my board to this ifdef block, it solves the issue with the kernel hanging on my device. I also need to patch some checks in the onenand detection, because the driver explicitly looks for onenand devices with a device_id of 0x40 and num_of_buffers as 0x201, but the chip on the GT-I5500 is different (device_id is 0x50, num_of_buffers is 0x101). This patch solves these problems:
Here is a dmesg log from my device after patching the code: For comparison purposes, look at the block mapping that the fsr driver reports for my device when using the BML mapping:
As you can see, the partitions names and order detection is correct for the msm_nand driver, but the address mappings are exactly half of what they are supposed to be (e.g. the first partition, mibib, should range from 0x00000000-0x00180000, but the mtd driver detects the memory range as 0x00000000-0x000C0000.
If I try to perform a "nandump -f /sdcard/cache.img /dev/mtd/mtd13", there are no obvious errors in the dmesg log, but the tool will dump the cache partition until the sd card becomes full (over 300mb in my case, but the real /cache partition is only 25MB), and will then output "nanddump: short write". The resulting dump will be filled with 0xFF when examined with a hex editor (even though I'm sure that the /cache partition is not blank in reality).

These are my findings so far. I'd appreciate any kernel hackers to help me out. If we can crack this problem and get open onenand drivers working, then our devices will no longer be locked to any specific kernel release.

Actual status:
galaxy5 (europa): mtd can read/write partitions (via dd). But CM doesn't seem to work completely. All tests done by psyke83:gio (gio): mtd doesn't seem to be able to dump partitions correctly (perhaps a problem in onenand_read). All tests done by erikcas
Furthermore erikcas managed to mount a partition but its size was reported to 0. Probably a badblock problem -> onenand_read

ace (cooper): mtd can't dump parititons correctly. All tests done by me!
More info in next post.

Last patch:
You can apply this again 2.6.35 (purenand branch) or (with minor changes) again 3.0.8/3.0.31

psyke83 and erikcas stopped development and original thread seem abandoned, I hope that here in xda somebody can help me to restore this!
Last edited by Mm7; 20th August 2014 at 12:05 AM.
The Following User Says Thank You to Mm7 For This Useful Post: [ View ]
20th August 2014, 12:03 AM |#2  
OP Senior Member
Thanks Meter: 250
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:

<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"

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
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
This is strange! 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!
Post Reply Subscribe to Thread

legacy, msm7x27, mtd, samsung
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes