Hardware Information Gathering
Coolpad Note 3 Hardware Information
Chipset | MediaTek MT6753 |
CPU | Octa-core 1.3 GHz Cortex-A53 |
Supported ABI | arm64-v8a, armeabi-v7a, armeabi |
RAM | 3 GB |
Partition Information Required for Building Cyanogen Recovery
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x1000000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x1000000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0xa2800000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x2d9d80000
Obtained from /proc/partinfo in the device
Prerequisite
- Enable USB Debugging
- Ensure ADB is working
I was unable to figure out the developer options in device settings. Apparently the customised UI in Coolpad Note 3 hides debugging option from user access. I was able to use ADB Toggle to access development options and enable USB debugging.
Ensure ADB is working for the device:
$ adb devices
List of devices attached
ZTBAWCGU7949EQWG device
$ adb shell id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
How to Gather Information
The build.prop file has a lot of information about the hardware and chipset. This file can be used to identify most of the information required to find similar devices for porting Cyanogen for our target device.
$ adb -d pull /system/build.prop
167 KB/s (7241 bytes in 0.042s)
$ head -n 20 build.prop
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=LMY47D
ro.build.version.incremental=5.1.019.P1.151101.8676_I02
ro.build.version.sdk=22
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=5.1
ro.build.date=Sun Nov 1 22:53:24 CST 2015
ro.build.date.utc=1446389604
ro.build.type=user
ro.build.user=mine
ro.build.host=ubuntu
ro.build.tags=release-keys
ro.build.flavor=CP8676_I02-user
ro.product.model=CP8676_I02
ro.product.brand=Coolpad
ro.product.name=CP8676_I02
ro.product.device=CP8676_I02
$ cat build.prop |grep -i platform
ro.board.platform=mt6753
ro.mediatek.platform=MT6735
Update: All partition information required for building CM recovery can be found from /proc/partinfo in the device:
$ adb shell cat /proc/partinfo
Name Start Size
pgpt 0x0000000000000000 0x0000000000080000
proinfo 0x0000000000080000 0x0000000000300000
nvram 0x0000000000380000 0x0000000000500000
protect1 0x0000000000880000 0x0000000000a00000
protect2 0x0000000001280000 0x0000000000a00000
lk 0x0000000001c80000 0x0000000000080000
para 0x0000000001d00000 0x0000000000080000
boot 0x0000000001d80000 0x0000000001000000
recovery 0x0000000002d80000 0x0000000001000000
logo 0x0000000003d80000 0x0000000000800000
yl_params 0x0000000004580000 0x0000000000100000
autobak 0x0000000004680000 0x0000000001000000
panic 0x0000000005680000 0x0000000001400000
lk_bak 0x0000000006a80000 0x0000000000080000
expdb 0x0000000006b00000 0x0000000000a00000
seccfg 0x0000000007500000 0x0000000000080000
oemkeystore 0x0000000007580000 0x0000000000200000
secro 0x0000000007780000 0x0000000000600000
keystore 0x0000000007d80000 0x0000000000800000
tee1 0x0000000008580000 0x0000000000500000
tee2 0x0000000008a80000 0x0000000000500000
frp 0x0000000008f80000 0x0000000000100000
nvdata 0x0000000009080000 0x0000000002000000
metadata 0x000000000b080000 0x0000000002780000
system 0x000000000d800000 0x00000000a2800000
cache 0x00000000b0000000 0x0000000019000000
userdata 0x00000000c9000000 0x00000002d9d80000
flashinfo 0x00000003a2d80000 0x0000000001000000
sgpt 0x00000003a3d80000 0x0000000000080000
Apart from the chipset and ABI information, another important information required for compiling a suitable recovery for the device are its partition info. The device uses an EMMC based internal storage which is of our primary interest. The broad partitioning scheme used by the device can be identified easily:
$ adb shell cat /proc/emmc
partno: start_sect nr_sects partition_name
emmc_p1: 00000400 00001800 "proinfo"
emmc_p2: 00001c00 00002800 "nvram"
emmc_p3: 00004400 00005000 "protect1"
emmc_p4: 00009400 00005000 "protect2"
emmc_p5: 0000e400 00000400 "lk"
emmc_p6: 0000e800 00000400 "para"
emmc_p7: 0000ec00 00008000 "boot"
emmc_p8: 00016c00 00008000 "recovery"
emmc_p9: 0001ec00 00004000 "logo"
emmc_p10: 00022c00 00000800 "yl_params"
emmc_p11: 00023400 00008000 "autobak"
emmc_p12: 0002b400 0000a000 "panic"
emmc_p13: 00035400 00000400 "lk_bak"
emmc_p14: 00035800 00005000 "expdb"
emmc_p15: 0003a800 00000400 "seccfg"
emmc_p16: 0003ac00 00001000 "oemkeystore"
emmc_p17: 0003bc00 00003000 "secro"
emmc_p18: 0003ec00 00004000 "keystore"
emmc_p19: 00042c00 00002800 "tee1"
emmc_p20: 00045400 00002800 "tee2"
emmc_p21: 00047c00 00000800 "frp"
emmc_p22: 00048400 00010000 "nvdata"
emmc_p23: 00058400 00013c00 "metadata"
emmc_p24: 0006c000 00514000 "system"
emmc_p25: 00580000 000c8000 "cache"
emmc_p26: 00648000 016cec00 "userdata"
emmc_p27: 01d16c00 00008000 "flashinfo"
While it might be possible to compute the offset and size of each partition in the EMMC using the above information, I was able to identify the required information from the vendor supplied scatter file and fastboot information.
During network monitoring, I could identify the URL for an OTA update package. Inside this package I found a scatter file:
$ cat data/updates/update_1446480447774/scatter.txt
preloader 0x0
pgpt 0x0
proinfo 0x80000
nvram 0x380000
protect1 0x880000
protect2 0x1280000
lk 0x1c80000
para 0x1d00000
boot 0x1d80000
recovery 0x2d80000
logo 0x3d80000
yl_params 0x4580000
autobak 0x4680000
panic 0x5680000
lk_bak 0x6a80000
expdb 0x6b00000
seccfg 0x7500000
oemkeystore 0x7580000
secro 0x7780000
keystore 0x7d80000
tee1 0x8580000
tee2 0x8a80000
frp 0x8f80000
nvdata 0x9080000
metadata 0xb080000
system 0xd800000
cache 0xb0000000
userdata 0xc9000000
flashinfo 0xFFFF0084
sgpt 0xFFFF0004
The partition sizes can again be computed from the scatter file above. It can be verified from the bootloader data as well that can be accessed while the device is in fastboot mode:
# Reboot the device into fastboot mode
$ adb reboot bootloader
# While the device is in fastboot mode
$ fastboot -i 0x1ebf getvar all > bootloader_var.txt 2>&1
$ cat bootloader_var.txt | grep recovery
(bootloader) partition-size:recovery: 1000000
(bootloader) partition-type:recovery: raw data
Extracting Stock ROM
As far as I could figure out, the only way to access raw storage without rooting the device is by using hardware/chipset specific features to access the raw storage in special flashing mode. For MediaTek MTK based devices, the popular SP Flash Tool can be used to flash or read-back stock images such as boot, recovery or system. There are multiple tutorials on how to extract stock images from a MTK device using the SP Flash Tool.
Notes:
- Ensure MTK VCOM drivers are installed before using the SP Flash Tools
- This is NOT same as the ADB drivers.
- Disconnect phone from USB and turn-off
- Start SP Flash Tool and select scatter file
- Start Read-back process
- Connect phone to computer via. USB in turned-off state
If everything goes well, the tool should read raw data from phone storage and create the image file. I was able to extract boot.img, system.img, recovery.img from the phone using the SP Flash Tool.
For VMware users like myself, it might be required to auto connect the phone identified by USB Vendor Id to the VM while it is in download mode.
The Mediatek preloader connects to USB as a different device than ADB interface. The device id can be obtained from dmesg if you are on Linux:
$ dmesg
[...]
[134881.637448] usb 2-1.3: new high-speed USB device number 70 using ehci-pci
[134881.731159] usb 2-1.3: New USB device found, idVendor=0e8d, idProduct=2000
[134881.731165] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[134881.731168] usb 2-1.3: Product: MT65xx Preloader
[134881.731171] usb 2-1.3: Manufacturer: MediaTek
[134884.256877] usb 2-1.3: USB disconnect, device number 70
[...]
As you can notice, the device will disconnect immediately if it does not receive a specific command from the SP Flash Tool. Actually the device waits for 150ms for START command to enter the download mode before continuing with power-off charging boot. More details on this available here
Playing with Boot Image
The SP Flash tool can be used to extract the boot image as shown earlier. The information required for the extraction is readily available from /proc/partinfo file in a running device. Once the boot.img is obtained, it can be unpacked using the unpackbootimg tool. This tool comes as a part of Cyanogen source tree or can be downloaded/built independently as well:
$ unpackbootimg -i /tmp/boot.img
Android magic found at: 0
BOARD_KERNEL_CMDLINE bootopt=64S3,32N2,64N2
BOARD_KERNEL_BASE 40078000
BOARD_RAMDISK_OFFSET 03f88000
BOARD_SECOND_OFFSET 00e88000
BOARD_TAGS_OFFSET 0df88000
BOARD_PAGE_SIZE 2048
BOARD_SECOND_SIZE 0
BOARD_DT_SIZE 0
These information are required for building Cyanogen Recovery. The kernel and ramdisk are extracted as boot.img-zImage and boot.img-ramdisk.gz respectively. The ramdisk contains a whole bunch of useful configuration files that can be re-used while building Cyanogen for the device. The ramdisk can be extracted using the below commands:
$ bzip -d boot.img-ramdisk.gz
$ mkdir ramdisk-extract; cd ramdisk-extract
$ cpio -idv < ../boot.img-ramdisk
$ ls
charger factory_init.rc init.modem.rc init.ssd.rc init.zygote64_32.rc sbin system
data file_contexts init.mt6735.rc init.trace.rc meta_init.modem.rc seapp_contexts ueventd.rc
default.prop fstab.mt6735 init.mt6735.usb.rc init.trustonic.rc meta_init.project.rc selinux_version
dev init init.project.rc init.usb.rc meta_init.rc sepolicy
enableswap.sh init.aee.rc init.rc init.xlog.rc proc service_contexts
factory_init.project.rc init.environ.rc init.recovery.mt6735.rc init.zygote32.rc property_contexts sys
References:
- http://forum.xda-developers.com/showthread.php?t=1982587
- http://mattboyer.github.io/PYaffs/
- https://github.com/visi0nary/android_device_elephone_p8000/