Database Info

[TOOL] rkflashtool for Linux and rk2808, rk2818 and rk2918 based tablets

Hi,
Because I don't run Windows nor NetBSD, I rewrote rkflash from scratch with the use of libusb-1.0, so you can now read and write your rk2818-based tablet's flash memory under Linux (also w/o the need to root your tablet). Credit for reverse-engineering the protocol goes to the original author of rkflash (see source).
Small guide
- unzip the file
- compile
Linux (Debian, Ubuntu, ...)
Code:
sudo apt-get install libusb-1.0-0-dev
gcc -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall -s
Mac OS X (thanks to surfer63, binary here)
Code:
sudo port install libusb
gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall
Preparation
- powerdown your tablet
- disconnect all cables
To get into flash mode differs for many tablets. Google around or use trial and error
- insert the USB cable in computer
- hold vol+ (or put on/off/locked-switch in the locked position)
- insert the other end of your cable in the tablet
- wait a few seconds
- release vol+
Now if you run lsusb, the following line should appear:
Bus 001 Device 044: ID 2207:281a (290a for rk2918 based tablets)
Bus and device number may be different. The screen of your tablet stays black.
The USB device must be readable and writable for the user running rkflashtool. If that's not the case, you'll see an error like this:
Code:
$ ./rkflashtool b
libusb couldn't open USB device /dev/bus/usb/001/048: Permission denied.
libusb requires write access to USB device nodes.
rkflashtool: fatal: cannot open device
This can be fixed in several ways (chmod, run as root, udev rules) but that's beyond the scope of this posting. For now, chmod 666 the device mentioned in the error message.
Usage of rkflashtool
Code:
$ ./rkflashtool
rkflashtool: fatal: usage:
rkflashtool b reboot device
rkflashtool r offset size >file read flash
rkflashtool w offset size <file write flash
offset and size are in units of 512 bytes
On my tablet, the boot partition starts at offset 0x8000 (in blocks of 512 bytes)
Its size is 0x2000 blocks
To backup the partition, issue:
Code:
$ ./rkflashtool r 0x8000 0x2000 >boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: reading flash memory at offset 0x00008000
rkflashtool: info: reading flash memory at offset 0x00008020
.......
rkflashtool: info: reading flash memory at offset 0x00009fe0
To write a new boot.img or an old backup back to the device:
Code:
$ ./rkflashtool w 0x8000 0x2000 <boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: writing flash memory at offset 0x00008000
rkflashtool: info: writing flash memory at offset 0x00008020
.......
rkflashtool: info: writing flash memory at offset 0x00009fe0
You can find a list of all partitions of your tablet in the HWDEF file, which is inside the update.img for your tablet. If no such file is available, you can also look at /proc/cmdline on a running device (either through adb or a terminal app running on the device itself). Depending on the tablet, you might need root access to view /proc/cmdline. Another option is dumping the first 0x2000 blocks of nand flash by issuing rkflashtool r 0x0000 0x2000 >parm. View the file with hexedit, xxd, or a similar program. The kernel parameters contain a description of several mtd partitions (sizes and offsets).
After reading and writing at will, you can reboot your tablet by issuing
./rkflashtool b
Note that if your tablet has an on/off/locked-switch and it is still in the locked position, rebooting won't work.
If the file you are writing is smaller than the specified size, the rest is padded with zeroes. If it's bigger, it will be truncated. This is different from rkflash, which will overwrite blocks beyond the partition size.
rkflashtool does not support flashing a new bootloader directly.
If you have a different tablet, please try rkflashtool b and r first before flashing (w) something new.
Standard DISCLAIMER with regard to bricking your tablet applies.
Enjoy!
EDIT: better build instructions, clean up text
EDIT2: works on rk2918 tablets too (tested on Arnova 7 G2) if you change the USB product id from 0x281a to 0x290a before compilation
EDIT3: released version 2 of rkflashtool. now supports rk2918 tablets out of the box. if it doesn't find one, it falls back to rk2808/rk2818. also, updated the wording a bit.
EDIT4: new mac osx binary
EDIT5: more ways to find offsets and sizes of partitions on your tablet
EDIT6: small emphasis changes above and...
version 1 is here ONLY for archival purposes or if version 2 does not work on your rk28xx tablet. In all other cases, you need to download rkflashtool-v2.zip

Thanks a lot for this flash tool. I'm on MacOSX and Ubuntu and don't have Windows either. I tried the original rkflash as well but couldn't get it to work. On my Ubuntu boxes your rkflashtool compiles and works fine.
My Archos 7 HT V2 presents itself also as:
Code:
Bus 002 Device 004: ID 2207:281a
Reading partitions works fine and so does writing.
I did a quick modification of a system.img (left some files out) of my custom froyo rom and wrote it to my tablet.
That works fine. As /data is a separate partition I even have all my downloaded apps, data, settings, etc. This makes modifying a new rom much faster then building a complete update.img, flashing it, restore some data and then start testing.
Nice work.

great! finally I can remove one line from my todo list
thank you!
EDIT:
random notes (I don't see your code yet so it may be fixed, then sorry)
* I always specify b(reboot) for rk2818 tablets with my rkflash because it hanged easily if I try to write multiple times without b
* parameter file need to be converted with rkcrc -p. official RKAndroid tools flashed it 5 times with offsets. (read & check 1st 0x0-0x2000 block)
* I logged how to update bootloader, but it's complicated and I could not understand probably bootloader can be updated via misc partition. see update-script in update.img. (but not recommended/no reason to do it)
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.
on Windows, there is RKAndroidTool.exe (not batchupgrade). but "read" function in rkflash/rkflashtool may be useful on some case on Windows

Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.
Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.
About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools
Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.

ivop said:
About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools
Click to expand...
Click to collapse
probably you also need a needle to short pins of NAND chip
so I don't recommend to flash bootloader
ivop said:
Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.
Click to expand...
Click to collapse
I made that log several months ago with another windows machine which is not used lately. I'm not sure log is still exist... if I find it, I'll send it to you (but please don't expect)
probably you may also get log on Windows on VM on Linux. it seems VMware has log function (refer http://vusb-analyzer.sourceforge.net/tutorial.html) or there is "usbmon" function in Linux.
actually I didn't try this way myself so it may be wrong, sorry.

I've tryed a couple of firmwares, cooking my own.
Every time after flashing, tablet shows boot animation and after few seconds display becomes dark.
My investigation led me to following:
Log shows:
Code:
ERROR/Lights(865): write_int failed to open /sys/class/backlight/rk28_button_light/brightness
in /sys/class/backlight I found symlink (rk28_bl):
rk28_bl -> ../../devices/platform/rk28_backlight/backlight/rk28_bl
Shouldn't be there another symlink named r28_button_light ?
I'm using MANTA MID001 from Poland.

fun_ said:
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.
Click to expand...
Click to collapse
ivop said:
Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.
Click to expand...
Click to collapse
I did a couple of successive writes as well from ubuntu.
ivop said:
Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.
Click to expand...
Click to collapse
My main platform is OSX and I immediately added libusb. So far I have not been able to compile rkflashtool despite declaring all kind of CFLAGS, CXXFLAGS and/or LDFLAGS.
Trying a little bit more.

Could you post the compiler warnings/errors here? I might be able to help out.

ivop said:
Could you post the compiler warnings/errors here? I might be able to help out.
Click to expand...
Click to collapse
I managed to compile it. It took a lot of hurdles. I used the build environment I also use for Hugin for which I'm the OSX maintainer.
I now built a single combined 32/64bit (i386/x86_64) rkflashtool that will run on 10.4.x/10.5.x/10.6.x/10.7.x (building multi-architecture, multi-version binaries/libraries in one binary/library is possible on OSX. I'm not going to explain that here but it's a feature of OSX).
The compiled version is attached. You can also attach it to your first post if you like.
It works fine. I did some reading/writing of images without issues.

If you are on OSX and have macports installed, you can do the following to build rkflashtool.
Install libusb from Macports:
Code:
sudo port install libusb
cd into the folder where your rkflashtool.c is is and run the following command:
Code:
gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -W -Wall
This will build rkflashtool for your native environment (OSX version, hardware and config).
--- removed the rest of the post as well as the attachments. He/She who is interested in building a complete universal distributable rkflashtool can ask via this thread ---

UPDATE: Works on rk2918 tablet too
Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:
... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...
to
... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...
it'll work, except for rebooting the device if the tablet is still locked. To boot the tablet in bootloader mode, turn off the tablet completely, put the on/off-switch in the locked position and connect it to your computer. It should be visible now with lsusb. For further instructions, see first post. I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.

ivop said:
UPDATE: Works on rk2918 tablet too
Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:
... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...
to
... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...
Click to expand...
Click to collapse
Feature request :
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.

surfer63 said:
Feature request :
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.
Click to expand...
Click to collapse
I released a new version and updated the first post. It now tries to connect to an rk2918 tablet and if it doesn't find one, it falls back to rk2818.

The V2 version works fine too on MacOSX. The compilation is still the same for a "my machine only" version.
I compiled a universal Intel 32bit/64bit 10.4/10.5/10.6/10.7 V2 version as well.
See attached.
Note: I don't have a RK2918 so I can only test for a RK2818 tablet.

Hi,
Thanks for your thread it's very intersting.
I succeed flashing my boot partition with your tool but I don't success in remount,rw my system partition. It's cramFS and in init.rk28board.rc you can see those line :
Code:
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount cramfs [email protected] /system
mount cramfs [email protected] /system ro remount
I tried everything like replacing ro by rw, deleting the second line but my system stills in ReadOnly, don't understand why. I also tried deleting those lines to test if my flash process works properly and it's worked... So I'm lost. Any idea ?
----
Other thing, if I want to do same as flashing boot partition but with system partition is it possible with the same process ? Unfortunately I don't know the beginning offset of the partition. I don't know where to find HWDEF file. The size of partition is 00038000 (hex) bytes => 229376 (dec) bytes
Here is my /proc/mtd :
Code:
dev: size erasesize name
mtd0: 00002000 00000010 "misc"
mtd1: 00004000 00000010 "kernel"
mtd2: 00002000 00000010 "boot"
mtd3: 00004000 00000010 "recovery"
mtd4: 00038000 00000010 "system"
mtd5: 0003a000 00000010 "backup"
mtd6: 0003a000 00000010 "cache"
mtd7: 00080000 00000010 "userdata"
mtd8: 00534000 00000010 "user"
mtd9: 00020000 00000010 "pagecache"
mtd10: 00020000 00000010 "swap"
Thank you for your great job

My problem is solved. I was searching for a while but ivop gave the answer in a previous post
I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.
Click to expand...
Click to collapse
So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :
Code:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](user)
So system partition starts at E000 and has a length of 38000 (hex) bytes.
Thanks for your help this thread is now in my bookmarks
And really nice job with this flashtool

I pushed latest my rkutils to https://github.com/naobsd/rkutils
rkunpack can unpack RKFW image used in RK2918 ROM, RKAF image (update.img), KRNL/PARM image used in some single partition image. unpack will be done recursively.
rkcrc can make KRNL/PARM images with -k/-p.
rkafpack can make RKAF image. (I need to write docs/howtos...)
little off-topic,
latest RK2918 ROMs which is based on "SDK2.0", new format for boot.img/recovery.img is introduced. it's almost same as common boot.img format for android. unpackbootimg/mkbootimg can be used to unpack/repack it with one exception...
there is SHA1 hash value in header of boot.img (offset 0x240 bytes). Rockchip changes it by some unknown way. normal mkbootimg can't generate same hash value as Rockchip, so we can't make custom boot.img with new format
fortunately, we can split new boot.img, and we can make separate kernel.img and boot.img(ramdisk) like as pre-SDK2.0 RK2918 ROMs, which is loadable with new bootloader in SDK2.0 ROMs.
--
btw I just found interesting one: https://github.com/jhonxie/rk2918_tools

relsyou said:
My problem is solved. I was searching for a while but ivop gave the answer in a previous post
So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :
Code:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](user)
So system partition starts at E000 and has a length of 38000 (hex) bytes.
Thanks for your help this thread is now in my bookmarks
And really nice job with this flashtool
Click to expand...
Click to collapse
I'll add that to my first post. Also, you can view /proc/cmdline to see a list of partitions. It's part of the kernel command line.
Note that the lengths are not in bytes but in blocks of 512 bytes. This happens to be the same as the requirements of the rkflashtool btw (length in blocks).
As for having a writable system partition, currently the system partition is cramfs which cannot be written to. Ever. If you want a writable system partition, you need to change it to ext3 for example. That means unpacking fun_'s system.img and recreating it as an ext3 partition.
In short:
Unpack cramfs img with cramfsck -x (as root, so you preserve permissions and uid/gid)
Create an empty file the size of your system partition (dd if=/dev/null of=fubar.img bs=512 count=...... et cetera, do the math)
mkfs.ext3 fubar.img
mount -o loop fubar.img /someplacemountable
copy contents of old image to /someplacemountable (use cp -a to preserve ownership etc)
umount
flash fubar.img to system partition
change init.rk28board.rc to reflect the changes
reflash boot.img
reboot device
This is untested, but should work in theory.
Another option is to keep the system partition read-only and use unionfs to overlay a writable partition. I'm not sure if this can be a file on your userdata partition mounted with -o loop, but I suppose it can. This depends on your kernel having unionfs and loopback support though.

fun_ said:
I pushed latest my rkutils to https://github.com/naobsd/rkutils
Click to expand...
Click to collapse
Nice! I was thinking about creating an rkpack(tool ) myself, but I see it's not necessary anymore.

here is an example for rkafpack
Code:
$ rkunpack N3NET-2.3-20110722.img
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR]
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR]
MACHINE_ID:
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR]
unpacking 12 files
-------------------------------------------------------------------------------
00000800-00000fff [COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] 797 bytes
00001000-000017ff [COLOR="Red"][B]package-file:package-file[/B][/COLOR] 532 bytes
00001800-00021fff [COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR] 131700 bytes
00022000-000227ff [COLOR="Red"][B]parameter:parameter:[email protected][/B][/COLOR] 506 bytes
00022800-0002e7ff [COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] 49152 bytes
0002e800-0066bfff [COLOR="Red"][B]kernel:Image/kernel.img:[email protected][/B][/COLOR] 6541946 bytes
0066c000-006947ff [COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] 163844 bytes
00694800-008e8fff [COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] 2441220 bytes
008e9000-085fc7ff [COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] 131149828 bytes
----------------- [COLOR="Red"][B]backup:SELF:[email protected][/B][/COLOR] (N3NET-2.3-20110722.img) 140498948 bytes
085fc800-085fcfff [COLOR="Red"][COLOR="Red"][B]update-script:update-script[/B][/COLOR][/COLOR] 1294 bytes
085fd000-085fd7ff [COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] 266 bytes
-------------------------------------------------------------------------------
unpacked
$ rkafpack \
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR] \
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR] \
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR] \
[COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] \
[COLOR="Red"][B]package-file:package-file[/B][/COLOR] \
'[COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR]' \
[COLOR="Red"][B]parameter:parameter:[email protected][/B][/COLOR] \
[COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B][B]kernel:Image/kernel.img:[email protected][/B][/B][/COLOR] \
[COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]backup:SELF:[email protected][/B][/COLOR] \
[COLOR="Red"][B]update-script:update-script[/B][/COLOR] \
[COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] \
> new.img
$ sha1sum N3NET-2.3-20110722.img new.img
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826 N3NET-2.3-20110722.img
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826 new.img
some values are empty in RK2818 ROM.
--
here is how to make RKFW image
Code:
$ rkunpack N50-2.3-20111103-ZZ-SDK2.0.img
VERSION:2.0.3
unpacking
00000000-00000065 N50-2.3-20111103-ZZ-SDK2.0.img-HEAD 102 bytes
00000066-00022623 N50-2.3-20111103-ZZ-SDK2.0.img-BOOT 140734 bytes
00022624-0c342627 update.img 204603396 bytes
unpacking update.img
================================================================================
FIRMWARE_VER:0.2.3
MACHINE_MODEL:rk29sdk
MACHINE_ID:007
MANUFACTURER:RK29SDK
unpacking 10 files
-------------------------------------------------------------------------------
00000800-00000fff package-file:package-file 540 bytes
00001000-000237ff bootloader:RK29xxLoader(L)_V2.08.bin 140734 bytes
00023800-00023fff parameter:parameter:[email protected] 610 bytes
00024000-0002ffff misc:Image/misc.img:[email protected] 49152 bytes
00030000-006a3fff boot:Image/boot.img:[email protected] 6766592 bytes
006a4000-01167fff recovery:Image/recovery.img:[email protected] 11288576 bytes
01168000-0c31efff system:Image/system.img:[email protected] 186346496 bytes
----------------- backup:SELF:[email protected] (update.img) 204603396 bytes
0c31f000-0c31f7ff update-script:update-script 933 bytes
0c31f800-0c31ffff recover-script:recover-script 266 bytes
-------------------------------------------------------------------------------
================================================================================
00022624-0c342627 N50-2.3-20111103-ZZ-SDK2.0.img-MD5 32 bytes
unpacked
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-HEAD N50-2.3-20111103-ZZ-SDK2.0.img-BOOT update.img > new.img
$ md5sum new.img
[COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR] new.img
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-MD5
5191abc65649eacf8d2476e37d84a046
$ echo -n [COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR] >> new.img
$ sha1sum N50-2.3-20111103-ZZ-SDK2.0.img new.img
3120b13df8886e0ddfae0e35379443c27c925572 N50-2.3-20111103-ZZ-SDK2.0.img
3120b13df8886e0ddfae0e35379443c27c925572 new.img

Extract blob from TF101G

Hi,
Newbie question for the TF101G. I just installed the OTA 9.2.2.4 update.
I am trying to obtain the blob (or update.zip) from the tablet itself. I tried:
dd if=/dev/block/mmcblk0p4 of=/sdcard/blob_9.2.2.4_extract bs=4096
That pulls out a 555,220,992 byte file ( similar to the 546,812,660 of the official 9.2.2.3 blob extracted from the update.zip).
But this blob doesn't seem to be a valid blob that blobunpack can unpack:
$ ./blobunpack.exe blob_9.2.2.4_extract
Unsupport blob file format
The blob from the update.zip can be unpacked fine.
I can even do with any pointers on how to get the recovery.img file from the partitions. I see that the following is the partition information:
9.2.2.4:
mmcblk0p1 - 536 MB, 536870912 bytes - System
mmcblk0p2 - 555 MB, 555220992 bytes -
mmcblk0p3 - 2 MB, 2097152 bytes -
mmcblk0p4 - 555 MB, 555220992 bytes - Blob (?)
mmcblk0p5 - 5 MB, 5242880 bytes- Recovery (?)
mmcblk0p6 - 0 MB, 524288 bytes
mmcblk0p7 - 29.2 GB, 29249503232 bytes - Data
Should this command give a valid recovery.img?
dd if=/dev/block/mmcblk0p5 of=recovery.img bs=4096
I can then create the recovery blob from this recovery.img file.
Basically I am trying to take a backup of the recovery partition before I flash CWM to it.
Thanks in advance.

The blob will be zipped in /cache/dlpkgfile, although I think it gets deleted after the update.
If the blob is still in staging, then you might have copied too much from the staging partition. A valid blob will start with something like msm radio update with some letter and numbers to indicate where all the blob pieces are located. Decypher those to calculate the end of the blob file and snip snip snip.
sent while running with scissors

Lastly, keep in mind the blob parts in the update will usually be the kernel, boot.img, and recovery. The actual rom is in the update as either patches to existing files or replacements.
sent while running with scissors

Success
gee one said:
The blob will be zipped in /cache/dlpkgfile
Click to expand...
Click to collapse
Thanks for that piece of information. I downgraded to 9.2.2.3 just to grab this file. Unzipped it and extracted the 9.2.2.4 blob from it.
Then I extracted the recovery.img from this blob and converted it to a standalone blob.
Then I applied this blob using:
dd if=/sdcard/blob_9.2.2.4_recovery of=/dev/block/mmcblk0p4
That did the trick. Stock recovery now.

[Solved] mmcblk* partitions

Where can I get a complete list of what each partition is? There's a list for the HTC Amaze at http://forum.xda-developers.com/showthread.php?t=1545911 but that list isn't correct for the Desire S.
I've worked out the following, but would like a complete list:
mmcblk0p17 misc_version
mmcblk0p18 hboot
mmcblk0p22 boot
mmcblk0p25 system
mmcblk0p26 data
mmcblk0p27 cache
mmcblk0p28 devlog
The command “cat /proc/partitions" lists all partitions, but not their name/function.
Sent from my Desire S

you can try to use command “cat /proc/emmc”

Here are my findings if you stil need the info:
Code:
mmcblk0p1 qcsbl_cfg part of radio.img
mmcblk0p2 qcsbl <empty>
mmcblk0p3 osbl part of radio.img
mmcblk0p4 extended part of radio.img elf-header of rex/amss
--------- --------- -------
mmcblk0p5 modem part of radio.img
mmcblk0p6 adsp part of radio.img
mmcblk0p7 htc rcdata.img Radio settings (IMEI,CID,S-OFF)
mmcblk0p8 rf_nv <empty>
mmcblk0p9 nv_mfg <empty>
mmcblk0p10 cdma_user_data <empty>
mmcblk0p11 rf_delta <empty>
mmcblk0p12 reserved <empty>
mmcblk0p13 modem_fs1
mmcblk0p14 modem_fs2
mmcblk0p15 htc_data <empty>
mmcblk0p16 htc_reserved <empty>
mmcblk0p17 misc device info
mmcblk0p18 appsbl hboot
mmcblk0p19 splash1
mmcblk0p20 wifi WiFi module
mmcblk0p21 recovery
mmcblk0p22 boot kernel & ramdisk
mmcblk0p23 mfg device config ?, contains WiFi MAC-address and Serial number
mmcblk0p24 splash2 <empty>
mmcblk0p25 system
mmcblk0p26 data userdata
mmcblk0p27 cache
mmcblk0p28 devlog
This is 0.98.x partition layout, on 2.00.x it has more partitions, but I believe that the first 27 are the same

Brilliant! Thanks.
Would you mind sharing how you found out all of this?
Sent from my HTC Desire S

How can you get this info? I need it ,Thanks.

BillGoss said:
Brilliant! Thanks.
Would you mind sharing how you found out all of this?
Sent from my HTC Desire S
Click to expand...
Click to collapse
A lot of searching through the Net, dumping partitions, hex analyzing, comparing to rom.zip images...
EDIT: some of the names are pure guess, such as mfg, but the content is 100 % verified. The names can be verified checking the hboot string if somebody is interested...

Thanks!
Sent from my Desire S

Need this for gt-i8150
amidabuddha said:
A lot of searching through the Net, dumping partitions, hex analyzing, comparing to rom.zip images...
EDIT: some of the names are pure guess, such as mfg, but the content is 100 % verified. The names can be verified checking the hboot string if somebody is interested...
Click to expand...
Click to collapse
Hey, I really need this for my model of phone (try to get a network unlock code from phone), but I'm really noob at hacking at using linux. What command would allow me to check the 'hboot' string of a given mmcblkXpXX file?
Thanks heaps,
Foxy

GrayedFox said:
Hey, I really need this for my model of phone (try to get a network unlock code from phone), but I'm really noob at hacking at using linux. What command would allow me to check the 'hboot' string of a given mmcblkXpXX file?
Thanks heaps,
Foxy
Click to expand...
Click to collapse
You have to dump the partition to the SD card via the dd command (you can use terminal emulator on your device) then copy the image to PC, open it with some HEX editor and look through the file
Sent from my HTC Desire S using Tapatalk

DD onto Mac
amidabuddha said:
You have to dump the partition to the SD card via the dd command (you can use terminal emulator on your device) then copy the image to PC, open it with some HEX editor and look through the file
Click to expand...
Click to collapse
Thanks. I've been using the strings command and piping to egrep for binary files, pulling only lines that have at least one 8 digit number present.I don't have very large SD cards on my phone - is there any way I could data dump directly to my mac, or alternatively (this would be much faster too) get my mac to do the work? Like... somehow open a terminal on the mac that had super user and root access to the phone?
Again, sorry for being a noob. I've been googling the above problem :S
EDIT: never mind. Downloading ADK now and will use ADB... pretty sure that will do it.

TF700T complete flash layout

I spent some time in analyzing of flash layout. The comprehensive description below attempts to map each byte of the flash and describes way to extract it.
I would be glad if somebody could provide more detailed info about bootloader, signatures, DRM etc.
Patches are welcome.
Code:
mmcblk0 layout
All dumps were done on Asus Eee Pad Transformer Infinity TF700T, 64GB version, firmware 9.4.5.26, locked
mmcblk0 off-partition section
Offset: 0 (0x0)
Size: 38273024 (0x2480000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0pre1.img bs=524288 count=73
Offset: 0 (0x0)
Size: 3670016 (0x380000)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s1.img bs=3670016 count=1
Process command: tr -d '\0' <mmcblk0pre1s1.img >mmcblk0pre1s1nz.img # mmcblk0pre1s1nz.img must be empty file
Offset: 3670016 (0x380000)
Contains: Recovery kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s2.img bs=524288 skip=7 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s2.img
mkdir mmcblk0pre1s2.img-ramdisk
cd mmcblk0pre1s2.img-ramdisk
zcat ../mmcblk0pre1s2.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 12058624 (0xb80000)
Contains: Regular boot kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s3.img bs=524288 skip=23 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s3.img
mkdir mmcblk0pre1s3.img-ramdisk
cd mmcblk0pre1s3.img-ramdisk
zcat ../mmcblk0pre1s3.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 20447232 (0x1380000)
Contains: Block of 16 bytes followed by 0x2de0 hexadecimal numbers followed by FF
Size: 12288 (0x3000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s4.img bs=524288 skip=39
Vital data:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss2.img bs=4096 skip=3
Binary part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch1.img bs=16 count=1
Hexadecimal part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch2.img bs=16 count=734 skip=1
Process command: unhex <mmcblk0pre1s4ss1ch2.img >mmcblk0pre1s4ss1ch2bin.img
FF part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch3.img bs=16 skip=735
Process command: tr -d '\377' <mmcblk0pre1s4ss1ch3.img >mmcblk0pre1s4ss1ch3nff.img # mmcblk0pre1s4ss1ch3nff.img must be empty file
Zeroes:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss1.img bs=4096 count=3
Process command: tr -d '\0' <mmcblk0pre1s4ss2.img >mmcblk0pre1s4ss2nz.img # mmcblk0pre1s4ss2nz.img must be empty file
Purpose: Probably encrypted bootloader
mmcblk0p1
Offset: 38273024 (0x2480000)
Size: 805306368 (0x30000000)
File system size: 196608 * 4096 = 805306368 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /system
Mount options: read only, extended attributes, ACL
Permissions: only root can manipulate
Contains: Base system and embedded applications
Purpose: Base system
mmcblk0p2
Offset: 843579392 (0x32480000)
Size: 448790528 (0x1ac00000)
File system size: 109568 * 4096 = 448790528 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /cache
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, UID system and GID cache can read and write
Contains: Cache
Purpose: Application cache
Note: The volume has the same UUID as mmcblk0p1
mmcblk0p3
Offset: 1292369920 (0x4d080000)
Size: 2097152 (0x200000)
File system size: 512 * 4096 = 2097152 (fully occupies partition)
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /misc
Referenced by: /system/lib/libandroid_runtime.so recovery ramdisk: /etc/recovery.fstab
Note: File system is referenced in recovery as emmc, not ext3!
mmcblk0p4
Offset: 1294467072 (0x4d280000)
Size: 855638016 (0x33000000)
File system size: 208896 * 4096 = 855638016
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /staging
Referenced by: recovery ramdisk: init.rc /etc/recovery.fstab
mmcblk0p5
Offset: 2150105088 (0x80280000)
Size: 5242880 (0x500000)
File system size: 5092 * 1024 = 5147488
Format: FAT32 file system, no partition table, MS-DOS "Non-system disk" boot block
Not mounted
Permissions: only root can manipulate
Contains: File system with files:
Serial numbers (ISN, PPID, SSN, UUID)
Calibration data (AL3010 light sensor, AMI304 magnetic sensor, KXTF9 motion sensor)
Purpose: Device specific unique system data, mounted as /btmac during Android boot
Referenced by: /system/bin/wifimacwriter /system/bin/brcm_patchram_plus /system/bin/sensors-config /system/bin/sixpair ramdisk: /init recovery ramdisk: /etc/recovery.fstab /init
mmcblk0p5 off file-system area
Offset in section: 5147488 (0x4e8b60)
Size: 28672 (0x7000)
Read command: busybox dd if=/dev/block/mmcblk0p5 of=/mnt/sdcard/mmcblk0p5s2.img bs=1024 skip=5092
Process command: tr -d '\0' <mmcblk0p5s2.img >mmcblk0p5s2nz.img # mmcblk0p5s2nz.img must be empty file
mmcblk0p6
Offset: 2155347968 (0x80780000)
Size: 524288 (0x80000)
Format: binary data
Permissions: UID drm can manipulate
Contains: 208 bytes of binary data, the rest are zeroes
Purpose: DRM, probably contains encrypted DRM key
Referenced by: /system/bin/wvdrmserver /system/vendor/lib/drm/libdrmwvmplugin.so
mmcblk0p7
Offset: 2155872256 (0x80800000)
Size: 5242880 (0x500000)
Format: empty
Contains: Zeroes
Purpose: Unknown
mmcblk0p8
Offset: 2161115136 (0x80d00000)
Size: 61415620608 (0xe4ca80000)
File system size: 14994040 * 4096 = 61415587840
Format: Linux ext4 filesystem
Mounted at: /data
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, read and write are directory specific
Contains: User applications, user data, and virtual internal SD card
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
mmcblk0p8 off file-system area
Offset in section: 61415587840 (0xe4ca78000)
Size: 32768 (0x8000)
Read command: busybox dd if=/dev/block/mmcblk0p8 of=/mnt/sdcard/mmcblk0p8s2.img bs=4096 skip=14994040
mmcblk0 off-partition section
Offset: 63576735744 (0xecd780000)
Size: 524288 (0x80000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0post8.img bs=524288 skip=121263
Process command: tr -d '\0' <mmcblk0p8s2.img >mmcblk0p8s2nz.img # mmcblk0p8s2nz.img must be empty file
Offset: 63576735744 (0xecd780000)
Offset in section: 0 (0x0)
Size: 507392 (0x7be00)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s1.img bs=507392 count=1
Process command: tr -d '\0' <mmcblk0post8s1.img >mmcblk0post8s1nz.img # mmcblk0post8s1nz.img must be empty file
Offset: 63577243136 (0xecd7fbe00)
Offset in section: 507392 (0x7be00)
Size: 16896 (0x4200)
Contains: EFI Partition table (partition names: APP, CAC, MSC, USP, PER, YTU, CRA, UDA)
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s2.img bs=512 skip=991
Purpose: Partition table
Total size of mmcblk0: 63577260032 (0xecd800000)
Notes:
can manipulate = can read, write partition vital data, only root can mount
can read, write = can read, write partition file system contents
Read commands are ran on the Transformer
Extract and process commands are run anywhere, with pre-read image file in the current directory.
You need dd with large files support. Vanilla dd on TF700T does not support large files. Busybox dd does.
Dropbox link to Asus_Transformer_Infinity_TF700T/flash_layout.txt

Wow, thanks for this detailed analysis - much more detailed than mine.
So what can I add to your research?
Tegra-based systems have another partition table, which has a proprietary layout and an unknown purpose (maybe just important for NVFlash and for flashing blobs?). Looking at the flash.cfg in the NVFlash package from AndroidRoot.mobi, we can get the Tegra partition layout and partition names:
Partition number 1 is missing in the list, maybe it contains the extremely well-hidden APX mode recovery code or even the answer to life, the universe and everything.
The following 3 partitions are located at the beginning of mmcblk0 and their contents are apparently encrypted with a device-specific key. For some reason, with ICS-based ROMs it reads as all zeros; in JB-based ROMs additional mmcblk0boot0 and mmcblk0boot1 partitions appear which together cover this area. The "bricksafe.img" in the nvflash guide covers these 3 partitions.
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
You already know the following 2:
5 SOS: Recovery kernel - 8388608 bytes
6 LNX: Linux kernel - 8388608 bytes
Then some more funny ones:
7 CER: I think this stands for "Certificate" and contains the bootloader unlock token. - 8388608 bytes. If I calculated correctly, this is at 0x1380000 into mmcblk0. Saved as "unlock-token.img" in the nvflash guide.
8 IMG: no idea what this is for - 8388608 bytes
9 GP1: space for a GPT partition table, maybe unused - 1048576 bytes
Now the regular partitions follow (p1 to p8):
10 APP: p1 = /system (Android OS)
11 CAC: p2 = /cache (for communication between Android and recovery)
12 MSC: p3 ="misc", whatever that is. On the TF101 it was used for bootloader commands.
13 USP: p4 = The update staging partition. Update blobs are copied here and flashed to the correct partition by the bootloader.
14 PER: p5 = device-specific config in a FAT filesystem
15 YTU: p6 = Apparently the DRM key. Confirmed to be overwritten with 0 by the unlocking process.
16 CRA: p7 = unknown (reserved for crash dumps?)
17 UDA: p8 = /data (Android user data)
And finally:
18 GPT: the EFI partition table that is actually used by the kernel

Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.

utx said:
Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
Click to expand...
Click to collapse
Yes, before unlocking I had something very similar to you there - a 16 byte header followed by some hexdump. I don't know what it was. It was overwritten by the unlock process with a 4 byte data block prefixed with a "-SIGNED-BY-SIGNBLOB-" header and followed by 256 bytes of what looks like a digital signature, very similar to the signed update blobs.
utx said:
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
Click to expand...
Click to collapse
Definitely back up the YTU partition before unlocking (p6) and then make the nvflash backups - but maybe the key must match something that is broken by the unlocking process, or it is renewed periodically, etc., so it might not help. Maybe try using DRM before unlocking and watch if the content of the partition changes over time.
utx said:
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.
Click to expand...
Click to collapse
Never tried to write directly to the block device - too scared to break something.
---------- Post added at 09:32 PM ---------- Previous post was at 09:28 PM ----------
Another small addition:
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
Click to expand...
Click to collapse
This FUSE trick also makes /mnt/sdcard case-insensitive.

I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?

ostar2 said:
I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?
Click to expand...
Click to collapse
How do you define "data recovery process"? You cannot recover data that has been overwritten.

_that said:
How do you define "data recovery process"? You cannot recover data that has been overwritten.
Click to expand...
Click to collapse
Well, if the DRM partition is write enabled, it may be possible to restore its contents, if you backed it up before unlock (it is probably per-device unique). But it could be insufficient. Locked bootloader can be different than unlocked bootloader, and may drop cipher needed for DRM decihering. It is just a theory. Somebody could proof it or falsify, if:
1) Backed all accessible data before unlock.
2) Unlocked (and to be safe, also made brickproof image).
3) Recovered the data creates in step 1.
Will DRM work then? Or did we need the contents of (currently inaccessible) locked stock data of the first megabytes?
But I see no way, how to back-up first megabytes of locked device (on ICS; JB is not as interesting for us, once you upgrade to JB, you cannot create brickproof image for nvflash).
I even don't know, which part of the subsystem causes these megabytes being reported as zeroes. Is it stock Asus ICS kernel? Is it bootloader? Is it a hardware lock on the flash device?

Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.

ostar2 said:
Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.
Click to expand...
Click to collapse
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works

_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.

firetech said:
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.
Click to expand...
Click to collapse
Oops, thanks for noticing. I edited my post.

what if we were to read from the NAND externally (RAW)....xbox 360 style...wouldn't that be the same as nvflash....
except that the three partitions in question are encrypted with a key that is probably unique per Tegra...
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
but I would suppose it wouldn't be a problem since a raw flash would restore everything back to normal...even if we can't read it..the CPU can..and that's all that matters.
---------- Post added at 11:21 AM ---------- Previous post was at 11:13 AM ----------
never mind...its a BGA

_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
Correct order maybe.
- get new TF700
- update to 9.4.5.26.
- root it using debugfs
- make a backup of /dev/block/*.*
- unlock (this erases mmcblk06 and voids warranty)
- install AndroidRoot hacked bootloader to make blobs for nvflash
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?

W3ber said:
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?
Click to expand...
Click to collapse
No way - the BCT, bootloader, etc. is not visible to the kernel at all (so it's not included in your images), and I don't know which kind of magic the blob creation tool uses, but I assume it's more than reading stuff from the nand.

CLOSE, please

All important information/ links will be moved to an INFO thread, since this is a question thread, we do not need it anymore.

Still looking.
Bump, can anyone help?
Saw this page:
forum.xda-developers .com/showthread.php?t=1959445
Was wondering if it's worth a shot.

Kernel released by Huawei.
For kernel/Rom Developers, Huawei has released the kernel for the Huawei Prism II online.
Attached is a notepad document with the links in them, since I am not allowed to post links. I apologize for the inconvenience.
ALSO
For anyone else with a Huawei device that has not released their kernel, I used the email format below:
Emal 1:
I would like the source code for my phone that is available to me. I am an android developer, and it would be useful to me if I have the
source code(that is offerred by Huawei).
The reply you will get:
Dear Customer,
Thank you for contacting Huawei device. The open source is under our technical department to make. Since the procedure is a little more complex, so please kindly be a little patient. We will keep you informed once available.Once again thank you for contacting Huawei device.
Best Regards.
Huawei Device Customer Care Team.
Give them 2-3 days, then E-mail once again! Be persistent!
2nd email:
Any new information about the source code?
The reply I got:
Dear Customer,
Thank you for contacting Huawei device. Please kindly check the source code link for your reference:
(link given above)
Once again thank you for contacting Huawei device.
Best Regards.
Huawei Device Customer Care Team.

Parted/FDisk Output on /dev/block/mmcblk0
streetdev22 said:
Bump, can anyone help?
Saw this page:
forum.xda-developers .com/showthread.php?t=1959445
Was wondering if it's worth a shot.
Click to expand...
Click to collapse
Tried the guide on my Prism II. Parted gave me an error. Possible reason for parted error is explained here: http://forum.xda-developers.com/showthread.php?t=2169709.
However, fdisk worked, but it doesn't clearly identify the partitons:
Edited to include gdisk output
parted:
Code:
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
Error: Unable to satisfy all constraints on the partition.
fdisk:
Code:
[email protected]:/ # fdisk -l /dev/block/mmcblk0
fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 3909 MB, 3909091328 bytes
1 heads, 16 sectors/track, 477184 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 3 20 4d Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 3 41 300 45 Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 41 16681 133120 c Win95 FAT32 (LBA)
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 16681 477184 3684031+ 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 16897 18432 12288 6a Unknown
/dev/block/mmcblk0p6 18433 18944 4096 46 Unknown
/dev/block/mmcblk0p7 18945 19456 4096 63 GNU HURD or SysV
/dev/block/mmcblk0p8 19457 19840 3072 58 Unknown
/dev/block/mmcblk0p9 19969 20352 3072 4a Unknown
/dev/block/mmcblk0p10 20481 20864 3072 4b Unknown
/dev/block/mmcblk0p11 20993 21504 4096 47 Unknown
/dev/block/mmcblk0p12 21505 22528 8192 48 Unknown
/dev/block/mmcblk0p13 22529 25088 20480 60 Unknown
/dev/block/mmcblk0p14 25089 25600 4096 6c Unknown
/dev/block/mmcblk0p15 25601 50176 196608 83 Linux
/dev/block/mmcblk0p16 50177 60416 81920 83 Linux
/dev/block/mmcblk0p17 60417 191488 1048576 83 Linux
/dev/block/mmcblk0p18 191489 338944 1179648 83 Linux
/dev/block/mmcblk0p19 338945 477184 1105920 6b Unknown
gdisk:
Code:
[email protected]:/ # gdisk -l /dev/block/mmcblk0
gdisk -l /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
***************************************************************
Exact type match not found for type code 4D00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4500; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6A00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4600; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6300; assigning type code for
'Linux filesystem'
Exact type match not found for type code 5800; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4A00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4B00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4700; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4800; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6000; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6C00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6B00; assigning type code for
'Linux filesystem'
Warning! Main partition table overlaps the first partition by 33 blocks!
You will need to delete this partition or resize it in another utility.
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/block/mmcblk0: 7634944 sectors, 3.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): E271C8D6-2001-435D-A466-BEFE7ED158CD
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7634910
Partitions will be aligned on 1-sector boundaries
Total free space is 9599 sectors (4.7 MiB)
Number Start (sector) End (sector) Size Code Name
1 1 40 20.0 KiB 8300 Linux filesystem
2 41 640 300.0 KiB 8300 Linux filesystem
3 641 266880 130.0 MiB 0700 Microsoft basic data
5 270336 294911 12.0 MiB 8300 Linux filesystem
6 294912 303103 4.0 MiB 8300 Linux filesystem
7 303104 311295 4.0 MiB 8300 Linux filesystem
8 311296 317439 3.0 MiB 8300 Linux filesystem
9 319488 325631 3.0 MiB 8300 Linux filesystem
10 327680 333823 3.0 MiB 8300 Linux filesystem
11 335872 344063 4.0 MiB 8300 Linux filesystem
12 344064 360447 8.0 MiB 8300 Linux filesystem
13 360448 401407 20.0 MiB 8300 Linux filesystem
14 401408 409599 4.0 MiB 8300 Linux filesystem
15 409600 802815 192.0 MiB 8300 Linux filesystem
16 802816 966655 80.0 MiB 8300 Linux filesystem
17 966656 3063807 1024.0 MiB 8300 Linux filesystem
18 3063808 5423103 1.1 GiB 8300 Linux filesystem
19 5423104 7634943 1.1 GiB 8300 Linux filesystem
[email protected]:/ #

Partition Layout
streetdev22 said:
Recently rooted and unlocked the bootloader on my Huawei Prism II, but there is no custom recovery nor custom roms for this phone. I have tried determing the partition layout in order to dump the recovery, but I am unable to do so.
Tried earlier versions of romdump, but they returned with a segmentation failure.
Click to expand...
Click to collapse
I believe I've found the partition layout based on the /etc/recovery_mmc.fstab extracted from mmcblk0p13, but am not sure. The excerpt of my /etc/recovery_mmc.fstab file from mmcblk0p13 shows some partition names correlated to device names. Could someone verify this is a legitimate way to determine the partition layout? I've also attached the whole recovery_mmc.fstab file.
recovery_mmc.fstab excerpt:
Code:
/boot emmc /dev/block/mmcblk0p12
/cache ext4 /dev/block/mmcblk0p15
# /* < DTS2012062603367 lizhigang 20120626 begin */
/data ext4 /dev/block/mmcblk0p18 length=-16384
#/* < DTS2012062603367 lizhigang 20120626 end */
/recovery emmc /dev/block/mmcblk0p13
/misc emmc /dev/block/mmcblk0p7
/sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
/system ext4 /dev/block/mmcblk0p17
/sys_boot vfat /dev/block/mmcblk0p3
/fat vfat /dev/block/mmcblk0p3
/HWUserData vfat /dev/block/mmcblk0p19
#/*< DTS2012020804291 weizhonghui 20120208 begin */
/cust ext4 /dev/block/mmcblk0p16
#/* DTS2012020804291 weizhonghui 20120208 end >*/
#/* DTS2012011906026 chendeng 20120120 end > */
# /* DTS2012031506621 lishubin 20120321 end > */
Easier to read (joined fdisk and the recovery_mmc.fstab)
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 3 20 4d Unknown /sdcard
/dev/block/mmcblk0p2 3 41 300 45 Unknown
/dev/block/mmcblk0p3 41 16681 133120 c Win95 FAT32 (LBA) /sys_boot and /fat
/dev/block/mmcblk0p4 16681 477184 3684031+ 5 Extended
/dev/block/mmcblk0p5 16897 18432 12288 6a Unknown
/dev/block/mmcblk0p6 18433 18944 4096 46 Unknown
/dev/block/mmcblk0p7 18945 19456 4096 63 GNU HURD or SysV /misc
/dev/block/mmcblk0p8 19457 19840 3072 58 Unknown
/dev/block/mmcblk0p9 19969 20352 3072 4a Unknown
/dev/block/mmcblk0p10 20481 20864 3072 4b Unknown
/dev/block/mmcblk0p11 20993 21504 4096 47 Unknown
/dev/block/mmcblk0p12 21505 22528 8192 48 Unknown /boot
/dev/block/mmcblk0p13 22529 25088 20480 60 Unknown /recovery
/dev/block/mmcblk0p14 25089 25600 4096 6c Unknown
/dev/block/mmcblk0p15 25601 50176 196608 83 Linux /cache
/dev/block/mmcblk0p16 50177 60416 81920 83 Linux /cust
/dev/block/mmcblk0p17 60417 191488 1048576 83 Linux /system
/dev/block/mmcblk0p18 191489 338944 1179648 83 Linux /data
/dev/block/mmcblk0p19 338945 477184 1105920 6b Unknown /HWUserData

Very nice!
Correlates with the hints found in other files as seen above, so I think we have successfully found the partition layout! I will take a look when my device gets here(originally was working on my relative's phone, but now I purchased it for myself). If this method is confirmed,we can to port CWM, thank you all!! After CWM, we should be able to make custom ROMs freely.

streetdev22 said:
Correlates with the hints found in other files as seen above, so I think we have successfully found the partition layout! I will take a look when my device gets here(originally was working on my relative's phone, but now I purchased it for myself). If this method is confirmed,we can to port CWM, thank you all!! After CWM, we should be able to make custom ROMs freely.
Click to expand...
Click to collapse
Great. I'm glad that someone can verify part of the partition layout. Hopefully, this means that the new information is credible too.

Prism 2 said:
Great. I'm glad that someone can verify part of the partition layout. Hopefully, this means that the new information is credible too.
Click to expand...
Click to collapse
How exactly did you extract the file? Did you extract it from mmcblk0p13? Have the device on hand, so I am trying to verify the findings.
Thanks.

Unpacking Recovery Image
streetdev22 said:
How exactly did you extract the file? Did you extract it from mmcblk0p13? Have the device on hand, so I am trying to verify the findings.
Thanks.
Click to expand...
Click to collapse
First, I made a selective backup using a google store app called Online Nandroid Backup https://play.google.com/store/apps/details?id=com.h3r3t1c.onnandbup&hl=en to make a backup on the "recovery" partition. Even though the app does not specify which block it copies, I believe the app makes a backup of /dev/block/mmcblk0p13 because it uses /system/partlayout4nandroid to determine the partition layout. If you look at the "cat /system/partlayout4nandroid" output below, you'll see that mmcblk0p13 corresponds to recovery.
Then I transferred the recovery.img from the sdcard to my computer.
From there, I followed the directions in Step 1 and Step 2 of http://www.imajeenyus.com/computer/20130301_android_tablet/android/unpack_repack_recovery_image.html to unpack and extract recovery.img.
Online Nandroid Backup Partition Layout:
Code:
[email protected]:/ # cat /system/partlayout4nandroid
cat /system/partlayout4nandroid
dev: size erasesize name
mmcblk0p1: 010000 000000 "modem"
mmcblk0p2: 000008 000000 "ssd"
mmcblk0p3: 000080 000000 "sbl1"
mmcblk0p4: 000100 000000 "sbl2"
mmcblk0p5: 000200 000000 "sbl3"
mmcblk0p6: 000200 000000 "aboot"
mmcblk0p7: 000200 000000 "rpm"
mmcblk0p8: 000200 000000 "tz"
mmcblk0p9: 002800 000000 "pad"
mmcblk0p10: 000c00 000000 "fsg"
mmcblk0p11: 002000 000000 "persist"
mmcblk0p12: 002800 000000 "boot"
[B]mmcblk0p13: 002800 000000 "recovery"[/B]
mmcblk0p14: 0b8000 000000 "system"
mmcblk0p15: 0d0000 000000 "cache"
mmcblk0p16: 000c00 000000 "modemst1"
mmcblk0p17: 000c00 000000 "modemst2"
mmcblk0p18: 040000 000000 "tombstones"
mmcblk0p19: 000400 000000 "misc"
mmcblk0p20: 001000 000000 "logo"
mmcblk0p21: 001000 000000 "logo2"
mmcblk0p22: 54c000 000000 "userdata"
mmcblk0p23: 00ffef 000000 "grow"
[email protected]:/ #

Probably correct.
My father(the owner of the phone) has once again left on a trip, so I will have to wait until Monday/Tuesday, when I receive my phone, to confirm these results.
My only issue with this is is why nandroid shows a different partition layout then what is shown in other files.
If partition 13 is recovery, there is no coincidence that you would find that fstab file in the extracted recovery.
Do you mind dumping all the extracted files from the recovery and uploading them to 4shared, mediafire, or any other cloud service as a compressed file(zip, tar)? I think the file is not coincidental, and that we have indeed found the partition layout(or at least the important partitions for our purposes).
Also, try dumping the boot partition that is currently identified (block 12) without using online nandroid backup(I think via dd should still work) and see if you can find similar files to that explained in the guide(.png, ramdisk directory, etc). If these files match up to what would be typically found in a boot.img or recovery.img, then the layout is most likely correct.
If these files match up to typical boot.img or recovery.img files, we can test the layout by changing something simple like a background before working on serious stuff.
Also, thanks for helping! Once we conclusively identify that this partition layout is correct, we can start to port clockworkmod.

streetdev22 said:
My father(the owner of the phone) has once again left on a trip, so I will have to wait until Monday/Tuesday, when I receive my phone, to confirm these results.
My only issue with this is is why nandroid shows a different partition layout then what is shown in other files.
If partition 13 is recovery, there is no coincidence that you would find that fstab file in the extracted recovery.
Do you mind dumping all the extracted files from the recovery and uploading them to 4shared, mediafire, or any other cloud service as a compressed file(zip, tar)? I think the file is not coincidental, and that we have indeed found the partition layout(or at least the important partitions for our purposes).
Also, try dumping the boot partition that is currently identified (block 12) without using online nandroid backup(I think via dd should still work) and see if you can find similar files to that explained in the guide(.png, ramdisk directory, etc). If these files match up to what would be typically found in a boot.img or recovery.img, then the layout is most likely correct.
If these files match up to typical boot.img or recovery.img files, we can test the layout by changing something simple like a background before working on serious stuff.
Also, thanks for helping! Once we conclusively identify that this partition layout is correct, we can start to port clockworkmod.
Click to expand...
Click to collapse
The extracted files in partition 13 can be found in post #44 of http://forum.xda-developers.com/showthread.php?t=2546455&page=5 labeled as "ramdisk.tar.bz2". I will make a dump of the boot partition using dd and run the tests tomorrow.

Looks validated, Also more tools
There are other guides on the matter of porting cyanogenmod..for example
http://wiki.cyanogenmod.org/w/Doc:_porting_intro
which even mentions a recovery.fstab file in recovery.img! So, that means the partition layout in the fstab file you found is most likely correct.
Another guide:
http://xda-university.com/as-a-developer/porting-clockworkmod-recovery-to-a-new-device
Also, there is an automated tool to porting cyanogenmod for new devices..
http://builder.clockworkmod.com/ (I would recommend avoiding the touch recovery for now, simple is all we need and we don't need more complications)
I am really feeling pretty confident about the partition layout found in the recovery.fstab, because one guide mentions it to be found in the recovery.img!
I would recommend making the changes to a recovery.img instead, because boot.img is still kinda scary (possible bricking )
Also, I think there is a command to try booting from a recovery.img without flashing the .img to the actual partition.
I think the command is mentioned here: http://forum.xda-developers.com/showthread.php?t=2233477
fastboot boot recovery.img is the command and it will not overwrite your existing recovery.
By using this command, you can try booting the stock recovery you extracted(to validate that we have a stock recovery available if we need it), and then boot the recovery.img you make with small edits, and then boot the recovery.img made from the automated CWM porter.
Thank you for replying so fast! We have made real progress in the last few days.
Edit:In the ramdisk that was extracted, another fstab exists on the root of the directory that is named fstab.msm7627, which is the same name from the file I located in post 1! They are the same file! I think this is validated.

Testing Recovery Partition
streetdev22 said:
I would recommend making the changes to a recovery.img instead, because boot.img is still kinda scary (possible bricking )
Also, I think there is a command to try booting from a recovery.img without flashing the .img to the actual partition.
I think the command is mentioned here: http://forum.xda-developers.com/showthread.php?t=2233477
fastboot boot recovery.img is the command and it will not overwrite your existing recovery.
By using this command, you can try booting the stock recovery you extracted(to validate that we have a stock recovery available if we need it), and then boot the recovery.img you make with small edits, and then boot the recovery.img made from the automated CWM porter.
Click to expand...
Click to collapse
I've made
a regular recovery.img using "dd if=/dev/block/mmcblk0p13 of=/sdcard/recovery.img" to make a copy of the recovery partition
a test recovery.img that is the same in every way to the original recovery.img except that all the images under /res/images is rotated 90 degrees. You can see the difference yourself by looking in res.rar attached below.
a clockworkmod recovery image from the clockworkmod recovery builder website
These images can be found attached below:
recovery.rar = original Huawei recovery image
recovery-test.rar = edited recovery image
recovery.img = clockworkmod recovery automatic builder image from http://jenkins.cyanogenmod.com/job/recovery/52069/
Unfortunately, I cannot test this image myself, because I do not want to unlock my bootloader yet.
If anyone with a rooted, unlocked Huawei Prism 2 is interested in helping to further the development of recovery roms for the Prism 2, I have made 3 tests to see if
the recovery partition is located in /dev/block/mmcblk0p13
the command "fastboot boot recovery.img", which we will be using extensively, can be used to boot the specified image file
the Clockworkmod Recovery image made from automated CWM porter successfully boots
The files you will need are provided below. I've also given instructions to the best of my ability without actually having done this.
To test if the recovery partition is located in /dev/block/mmcblk0p13:
Go into fastboot mode (step 2f in post #1 of http://forum.xda-developers.com/showthread.php?t=2546455)
Download the recovery.rar file below and extract it to get recovery.img.
Open up terminal
change directory to where you extracted recovery.img
type
Code:
fastboot boot recovery.img
See if phone boot into recovery
Next we test an edited recovery.img to see if "fastboot boot recovery.img" is truly letting us boot the image we've specified.
To find out, we're going to use the edited recovery.img and do pretty much the same thing except now with recovery-test.img:
Go into fastboot mode (step 2f in post #1 of http://forum.xda-developers.com/showthread.php?t=2546455)
Download the recovery-test.rar file below and extract it to get recovery-test.img.
Open up terminal
change directory to where you extracted recovery-test.img
type
Code:
fastboot boot recovery-test.img
See if any pictures are upside down (the battery symbol, numbers, or the android robot)
After completing the 2 tasks above, and verifying that we have a valid original recovery.img and that we can use
Code:
fastboot boot recovery.img
to boot a specific image file, we can start testing a very, very, very EXPERIMENTAL Clockworkmod Recovery image using fastboot. I would not rely on this image to make backups and I honestly do not know what kind of damage it might inflict on the phone so make a backup of everything before starting.
output from CWM automatic recovery builder: http://jenkins.cyanogenmod.com/job/recovery/52069/
To test if this CWM recovery image will boot and have the right partition layout:
Go into fastboot mode (step 2f in post #1 of http://forum.xda-developers.com/showthread.php?t=2546455)
Download the recovery.img.
Open up terminal
change directory to where you downloaded recovery.img
type
Code:
fastboot boot recovery.img
If the cwm recovery image boots, type
Code:
mount
See if /sdcard is mounted to the right partition)
If you're feeling lucky, make a backup to /sdcard **this step can cause damage to phone if /sdcard is mounted to the wrong partition**
Thanks for volunteering and bringing the Huawei Prism 2 one step closer to custom roms.

Will test as soon as I get the phone.
I should be getting my phone in the mail Tuesday-Wednesday, but I will test as soon as I get it in the mail and I get my bootloader unlocked. I shouldn't have an issue booting it, since it will boot without effecting my current recovery partition. Hopefully the cwm recovery boots as well.

streetdev22 said:
I should be getting my phone in the mail Tuesday-Wednesday, but I will test as soon as I get it in the mail and I get my bootloader unlocked. I shouldn't have an issue booting it, since it will boot without effecting my current recovery partition. Hopefully the cwm recovery boots as well.
Click to expand...
Click to collapse
Great! I really hope it works. Let me know if I can help with anything in the meantime.

Getting my phone today
My phone is coming today! I will let you know the results either later today or tomorrow. Also, could you pull a build.prop using ADB from your phone? This guy needs it: http://forum.xda-developers.com/showthread.php?p=49494728

niceeeee
Prism 2 said:
Great! I really hope it works. Let me know if I can help with anything in the meantime.
Click to expand...
Click to collapse
I tried them today and they work fine siiiiir. both booted while i was stuck in a boot loop from deleting my settins apk

Cjantolak said:
I tried them today and they work fine siiiiir. both booted while i was stuck in a boot loop from deleting my settins apk
Click to expand...
Click to collapse
Thats good news! Could you state specifically which 2 of the 3 images booted though? I'm assuming the original (recovery.rar file) and the edited (recovery-test.rar file) recovery.images, but want to make sure
In other words, did you test the clockworkmod recovery image?

first two
Prism 2 said:
Thats good news! Could you state specifically which 2 of the 3 images booted though? I'm assuming the original (recovery.rar file) and the edited (recovery-test.rar file) recovery.images, but want to make sure
In other words, did you test the clockworkmod recovery image?
Click to expand...
Click to collapse
I did just boot the clockworkmod recovery and i just booted up fine. os is running as it should other than the whole missing settings app. im stuck without root, without wifi, and usb debugging.
adb not installing the app either so idk.

Thanks for straightening out the confusion. Can you check the mounted partitions are correct? Afterwards you can use update.zip to install your settings.apk
---------- Post added at 01:11 AM ---------- Previous post was at 01:04 AM ----------
Never mind about checking the partition layout. I just remembered you don't have adb. I will try to make a better recovery image.