Database Info

[HELP NEEDED] How to build a Clockworkmod for LG P290?

Hi all,
I am serching the whole internet to findout how to build a Clockworkmod for LG P920.
This is what i got so far:
P920's boot.img and recovery.img are uImage format. it loads by uboot. and i can get info from it using uboot's mkimage -l command.
the uImage using by LG P920 is a Multi-File format.
this is the info of Clockworkmod 4.0.0.9 for LGP920:
PHP:
[email protected]:~/temp$ ./mkimage -l recovery-clockwork-4.0.0.9-p920.img.backup
Image Name: Image
Created: Sun Jul 10 03:55:14 2011
Image Type: ARM Linux Multi-File Image (uncompressed)
Data Size: 5149182 Bytes = 5028.50 kB = 4.91 MB
Load Address: 0x80008000
Entry Point: 0x80008000
Contents:
Image 0: 3325552 Bytes = 3247 kB = 3 MB
Offset = 00000050
Image 1: 1823618 Bytes = 1780 kB = 1 MB
Offset = 0032BEC0
i already get the Image 0 and Image 1 using dd withe command below:
PHP:
2018 dd if=recovery-clockwork-4.0.0.9-p920.img.backup of=ramdisk.img skip=3325632 bs=1 count=1823618
2019 dd if=recovery-clockwork-4.0.0.9-p920.img.backup of=kernel.img skip=80 bs=1 count=3325552
so am i right? and how to extra the ramdisk.img?
what i want to do is add external sd card support for this clockworkmod recovery. why the original clockwokmod just support for internal sdcard?
I am also try to find the kernel source for this device. where can i find it?
any help will do.... Thanks!

why do you ever need to build one when it already has one in Rom Manager? Just 2 cents, no expert here

precsmo said:
why do you ever need to build one when it already has one in Rom Manager? Just 2 cents, no expert here
Click to expand...
Click to collapse
the one in rommanager dont support external sdcard....

[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

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.

[KERNEL][TUTORIAL] Stock 10.4.4.25 + insecure + init.d + nodpi

I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment kernel-10.4.4.25-insecure.zip
Update 2013-01-21: Here is a version that does not set lcd_density, so that custom dpi set in /system/build.prop work. Verified to work with CROMI 3.2.
View attachment kernel-10.4.4.25-insecure-nodpi.zip
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
For the tutorial how to unpack and repack a kernel, see post #4.
Update 2013-01-21: Updated with info how to unlock DPI.

_that said:
I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment 1657033
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
Click to expand...
Click to collapse
Nice work!!:good:

_that said:
I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment 1657033
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
Click to expand...
Click to collapse
Many thanks - I've been struggling with linux to unpack the blob.LNX file. Blob tools isn't working for me for some reason as ./blobunpack blob.LNX says unrecognised blob format.
What is the secret to get it working?

sbdags said:
Many thanks - I've been struggling with linux to unpack the blob.LNX file. Blob tools isn't working for me for some reason as ./blobunpack blob.LNX says unrecognised blob format.
What is the secret to get it working?
Click to expand...
Click to collapse
I firmly believe that this should not be a secret, so I'll explain in detail how to do it and not only give you steps but also a lot of background info. Many steps in the following tutorial are optional and useful for learning, for checking things and for troubleshooting - I don't want you to blindly follow a recipe without understanding what you are doing.
Unpacking the blob
We start with the full firmware, unpacked once - in this case, WW_epad-user-10.4.4.25.zip. First extract the blob from the zip:
Code:
[email protected] ~/android/tf700/kernel $ unzip WW_epad-user-10.4.4.25.zip blob
Archive: WW_epad-user-10.4.4.25.zip
signed by SignApk
inflating: blob
This is a signed blob. It begins with "-SIGNED-BY-SIGNBLOB-". You can check this with hexdump (this step is completely optional, just for illustration):
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 48 blob
00000000 2d 53 49 47 4e 45 44 2d 42 59 2d 53 49 47 4e 42 |-SIGNED-BY-SIGNB|
00000010 4c 4f 42 2d e9 1a d7 30 00 01 00 00 4d 53 4d 2d |LOB-...0....MSM-|
00000020 52 41 44 49 4f 2d 55 50 44 41 54 45 00 00 01 00 |RADIO-UPDATE....|
00000030
Also note the MSM-RADIO-UPDATE after the signature header - it is the start of an unsigned blob.
But what exactly is a blob? In database terminology, it stands for "binary large object" - a bunch of data that is just stored with no further interpretation by the database.The blobs for flashing NVIDIA Tegra devices have a specific structure - they contain one or more raw images to be flashed to one or more partitions on the device.
The full firmware blob for the TF700 contains images for 5 partitions, which we will now extract from the blob. If you don't have blobunpack, get the sources from https://github.com/AndroidRoot/BlobTools - how to do that and how to compile them may be part of another tutorial. I also assume you have blobunpack somewhere in your $PATH.
Code:
[email protected] ~/android/tf700/kernel $ blobunpack blob
Header size: 60
5 partitions starting at offset 0x3C
Blob version: 65536
Partition 0
Name: PT
Offset: 140 (0x8C)
Size: 524288 (0x80000)
Writing file blob.PT (524288 bytes)
Partition 1
Name: EBT
Offset: 524428 (0x8008C)
Size: 1566813 (0x17E85D)
Writing file blob.EBT (1566813 bytes)
Partition 2
Name: SOS
Offset: 2091241 (0x1FE8E9)
Size: 6410496 (0x61D100)
Writing file blob.SOS (6410496 bytes)
Partition 3
Name: LNX
Offset: 8501737 (0x81B9E9)
Size: 5595392 (0x556100)
Writing file blob.LNX (5595392 bytes)
Partition 4
Name: APP
Offset: 14097129 (0xD71AE9)
Size: 805306368 (0x30000000)
Writing file blob.APP (805306368 bytes)
OK, now we have separate files for each partition. The next step is again optional, just to illustrate what happened:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2059512
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
What's inside a firmware blob
blob.APP is a raw image of a Linux ext4 partition. If you are interested in the contents, you can loop mount this file and access all files inside directly on your Linux computer. This is the filesystem that is mounted as /system - the ROM as you all know it.
blob.EBT is the bootloader.
blob.LNX is the boot image - the Linux kernel and the ramdisk, which is later seen as "/". This is the one we are after.
blob.PT is the Tegra partition table. This is a proprietary format, not a PC-compatible partition table.
blob.SOS is the recovery boot image - another Linux kernel and another ramdisk, but this ramdisk contains the stock recovery (incl. the dreaded "dead android").
The boot image
Now, what's actually a boot image, and how do we recognize one if we see one? As usual, the best answer is: look inside! (again - optional, just to learn something)
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blob.LNX
00000000 41 4e 44 52 4f 49 44 21 58 0c 4e 00 00 80 00 10 |ANDROID!X.N.....|
00000010
An Android boot image begins with the text "ANDROID!". Easy.
(maybe sbdags now starts to smack his head and realizes why blobunpack does not work here - and if anyone is still in doubt - a boot image is not a blob)
Splitting a boot image
Good, but how do we crack this thing open? Fortunately there are two small perl scripts I extracted from dsixda's Android kitchen (they are in tools/extract_boot_files):
Code:
[email protected] ~/android/tf700/kernel $ extract-kernel.pl blob.LNX
[email protected] ~/android/tf700/kernel $ extract-ramdisk.pl blob.LNX
1932 blocks
OK, what happened?
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2064524
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
We got a new file (zImage) and a directory (blob.LNX-ramdisk)!
zImage is the kernel image. It is the result of compiling a kernel from sources. Today, we will not compile a new kernel, just repack this image with our modified ramdisk.
What blob.LNX-ramdisk contains should be obvious.
Modifying the ramdisk
Now we can start modifying the ramdisk. A CleanROM ramdisk differs from a stock ramdisk in only 3 files:
- sbin/adbd
- default.prop
- init.rc
sbin/adbd is the adb daemon - the program that handles the tablet's side of the adb protocol. The stock version runs under the "shell" user account, which has limited permissions and cannot access all files on the tablet. The CleanROM version of adbd runs as "root", so "adb push" and "adb pull" can write or read any file on the device, and "adb shell" goes directly to a root prompt.
I don't know where scrosler got this binary from, I just copied it from his CleanROM kernel's ramdisk. You can do the same - now you already know how to extract a ramdisk, so just do the same with the CleanROM kernel in another directory.
default.prop contains only a few lines. Here is the already modified CleanROM version:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
In the original file, ro.secure=1 (which would limit adb to the "shell" account again), ro.debuggable=0 (I'd have to look up what exactly this does), and persist.sys.usb.config=mtp without adb (I think this modification is what automatically enables "USB debugging" at boot time).
Finally, init.rc has a few additional lines to enable init.d support. This means the boot sequence will run any scripts in /etc/init.d - this a simplified version of a usual convention for desktop Linux systems. CleanROM uses it to set up various tweaks (look into /system/etc/init.d on your device).
To illustrate the changes in init.rc, I use the "diff" command (and you can too, if you want - just use the correct paths for your setup instead of mine):
Code:
[email protected] ~/android/tf700/kernel $ diff -u blob.LNX-ramdisk/init.rc ~/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc
--- blob.LNX-ramdisk/init.rc 2013-01-19 19:59:03.000000000 +0100
+++ /home/that/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc 2013-01-19 01:24:43.000000000 +0100
@@ -309,6 +309,8 @@
# Set this property so surfaceflinger is not started by system_init
setprop system_init.startsurfaceflinger 0
+ start sysinit
+
class_start core
class_start main
@@ -413,6 +415,10 @@
user drm
group drm system inet drmrpc sdcard_r
+service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ disabled
+ oneshot
+
service media /system/bin/mediaserver
class main
user media
If you have never read a diff before (also called a patch), here a quick guide:
- Lines beginning with "---" and "+++" identify the two files that were compared.
- Lines beginning with "@@" specify line numbers in the two files. -309,6 +309,8 means: The next block contains 6 lines starting with line 309 from file 1 (---), and 8 lines starting with line 309 in file 2 (+++). In other words, this means that two lines were inserted there.
- The following lines start with a blank - they are context lines. These lines are common in both files and only used to see some context around the change.
- Lines beginning with "+" exist only in file 2 (+++). You can easily remember all this if you know that a diff describes how to edit file 1 to be identical to file 2 - you delete lines marked with "-" and insert lines marked with "+". With only these two operations, you can transform any text file to any other - in the worst case you will delete all lines of the original file and insert all lines of the new file.
The second block works like the first one - here we insert 4 lines near line 413 (which has become line 415 after our first insertion).
You have the following options to apply this change:
1. Simply copy over the changed version from the previous CleanROM kernel. Do a diff before to verify that Asus didn't change anything, otherwise you will undo Asus' changes.
2. Use the "patch" tool to apply the diff file from above. This will automatically perform the edit steps in the diff file and it also has some tolerance if something changed in other sections of the file.
3. Use a text editor and perform the changes manually. If you copy lines from the diff (and not the original init.rc), make sure you don't accidentally copy the leading "+" - this is only for the diff and should not part of the file.
Update 2013-01-21 Start
Unlocking DPI
As usual I don't just tell you how to do it, but some background info first:
There is a read-only system property in Android named "lcd_density" that specifies the display resolution. This is done to ensure that the approximate size of display items is kept consistent across the wide range of devices Android runs on.
For normal users this is great, because they don't have to buy a magnifying glass and a pointed stylus just to use their super-hires-devices, but users here on xda-developers of course see a setting that can be modified and therefore it *must* be modified. Smaller values produce smaller icons and text (and thus more visible content at once); bigger values produce bigger icons and text.
The ASUS stock firmware is not only used on the TF700, but also for several other Transformers. The file /system/build.prop sets ro.sf.lcd_density=160, which means 160 dpi. This is good for the majority of tablets that have 1280*800 displays, but the TF700's display has a resolution of 224 pixels per inch, and with a setting of 160 dpi everything would be very tiny.
The bootloader passes an important parameter to the kernel: "androidboot.productid=0x04", This value depends on the Transformer model, and it is 4 for the TF700. If you look into the ramdisk, there are several files named init.00.rc to init.0d.rc. These are device-specific, and you guessed right if you think that init.04.rc is for the TF700. This file sets lcd_density to 240 dpi, and since it is a read-only property, it keeps its value even if the system's build.prop (which is read later) tries to set lcd_density to 160.
So how do we unlock dpi? Delete the line that says "setprop ro.sf.lcd_density 240" in init.04.rc! Of course this requires you to set the desired dpi value in /system/build.prop. If you install CleanROM Inheritance, you can choose this value in the installer. If you run this kernel with the stock ROM, everything will become very tiny, and now you know why.
Update 2013-01-21 End
Re-packing the boot image
OK, phew, we finally have a modified ramdisk - now we need to repack everything, basically the reverse of the first few steps. For this I use a self-written shell script. First let's just run it:
Code:
[email protected] ~/android/tf700/kernel $ repack-kernel.sh
Found 1 partitions as commandline arguments
Partname: LNX Filename: blob.LNX
Size: 60
1 partitions starting at offset 0x3C
Offset: 76
8+0 records in
8+0 records out
8 bytes (8 B) copied, 0,000136275 s, 58,7 kB/
OK, what happened here? Since I wrote this script myself, I can explain it line by line:
Code:
[email protected] ~/android/tf700/kernel $ cat ~/bin/repack-kernel.sh
#!/bin/bash
~/android/Android-Kitchen/tools/mkboot/mkbootfs blob.LNX-ramdisk | gzip > ramdisk.gz
~/android/Android-Kitchen/tools/mkboot/mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
blobpack blobtmp LNX blob.LNX
echo -n "-SIGNED-BY-SIGNBLOB-" > blob
dd if=/dev/zero bs=1 count=8 >> blob
cat blobtmp >> blob
The ramdisk is repacked and zipped again. This creates ramdisk.gz.
The kernel is merged with the ramdisk to a new boot image, to create blob.LNX. If you paid attention before, yes, this will overwrite the old blob.LNX. If you want, you can check again with hexdump that it is really a boot image (it begins with "ANDROID!").
Re-packing a blob
Now we pack the boot image into a blob. However, the "original" version of blobtools does not create a signed blob. See:
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blobtmp
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010
That was the blob format for the TF101. For later Transformers, we need to prepend a signature header. As we don't have Asus' cryptographic keys, we cannot create a valid signature - but fortunately, since we have an unlocked bootloader, we don't actually need to add a proper signature - the header is enough. There are two ways to create this header - there is a modified version of blobtools in circulation that has a command line option for it, but I do it "manually" with echo and dd.
The final output is again simply called "blob" - this is the new blob that now contains only the kernel. (It overwrites the original blob, which is not really intended, but I just didn't care).
For comparison, now we have this:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 1274980
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 5599336 19. Jän 20:35 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5599232 19. Jän 20:35 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5599308 19. Jän 20:35 blobtmp
-rw-r--r-- 1 that users 479752 19. Jän 20:35 ramdisk.gz
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
Congratulations, you have a flashable blob with your new kernel. But how do you get it onto your device?
Installation
Again, there are two ways:
Installing the blob directly with dd
The first option is to copy the blob to your tablet's staging partition manually and reboot:
Code:
[email protected] ~/android/tf700/kernel $ adb push blob /sdcard/kernel-10.4.4.25.blob
1324 KB/s (5599336 bytes in 4.128s)
[email protected] ~/android/tf700/kernel $ adb shell
sh-3.2# dd if=/sdcard/kernel-10.4.4.25.blob of=/dev/block/mmcblk0p4
10936+1 records in
10936+1 records out
5599336 bytes transferred in 0.129 secs (43405705 bytes/sec)
Be very careful with the dd command and double-check that you didn't swap "if" and "of", and that you specified the correct target partition *before* you hit Enter.
Now reboot your tablet, and the bootloader will flash your new kernel from the blob to the actual kernel partition (notice the progress bar on the boot screen with the slightly broken graphics, as usual). The tablet will reboot again automatically, and if you did everything right, your shiny new kernel will be running!
Creating a zip for flashing in the recovery
OK, now to option 2 - pack the blob into a flashable zip that you can flash in the recovery. The easiest way to do this is to reuse the original firmware zip. Just replace the blob inside the big firmware zip, and that's it - you have a recovery-flashable zip!
Code:
[email protected] ~/android/tf700/kernel $ mv WW_epad-user-10.4.4.25.zip kernel-10.4.4.25.zip
[email protected] ~/android/tf700/kernel $ zip -d kernel-10.4.4.25.zip blob
deleting: blob
[email protected] ~/android/tf700/kernel $ zip kernel-10.4.4.25.zip blob
adding: blob (deflated 1%)
This would not be a good tutorial if I didn't explain how and why this actually works. Let's look inside!
Code:
[email protected] ~/android/tf700/kernel $ unzip kernel-10.4.4.25.zip META-INF/*
Archive: kernel-10.4.4.25.zip
signed by SignApk
inflating: META-INF/com/google/android/resource
inflating: META-INF/com/google/android/rule
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
The core of a flashable zip is the updater-script. For a full firmware, it is very short:
Code:
[email protected] ~/android/tf700/kernel $ cat META-INF/com/google/android/updater-script
assert(package_extract_file("blob", "/tmp/blob"), write_raw_image("/tmp/blob", "staging"),delete("/tmp/blob"));
This line instructs the recovery to extract the blob from the zip file to /tmp/blob and then copy it to the staging partition - essentially it is exactly the same as we did manually in option #1 above!
OK, now the secret is fully disclosed - I hope you learned something. If you have further questions, or if you need help compiling some of the mentioned binaries, don't hesitate to ask (if it's not something like "how do I use the Linux command line" ).

uh huh, uh huh, What?
I think I need to go to blob school....:silly:

_that said:
I firmly believe that this should not be a secret, so I'll explain in detail how to do it and not only give you steps but also a lot of background info. Many steps in the following tutorial are optional and useful for learning, for checking things and for troubleshooting - I don't want you to blindly follow a recipe without understanding what you are doing.
We start with the full firmware, unpacked once - in this case, WW_epad-user-10.4.4.25.zip. First extract the blob from the zip:
Code:
[email protected] ~/android/tf700/kernel $ unzip WW_epad-user-10.4.4.25.zip blob
Archive: WW_epad-user-10.4.4.25.zip
signed by SignApk
inflating: blob
This is a signed blob. It begins with "-SIGNED-BY-SIGNBLOB-". You can check this with hexdump (this step is completely optional, just for illustration):
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 48 blob
00000000 2d 53 49 47 4e 45 44 2d 42 59 2d 53 49 47 4e 42 |-SIGNED-BY-SIGNB|
00000010 4c 4f 42 2d e9 1a d7 30 00 01 00 00 4d 53 4d 2d |LOB-...0....MSM-|
00000020 52 41 44 49 4f 2d 55 50 44 41 54 45 00 00 01 00 |RADIO-UPDATE....|
00000030
Also note the MSM-RADIO-UPDATE after the signature header - it is the start of an unsigned blob.
But what exactly is a blob? In database terminology, it stands for "binary large object" - a bunch of data that is just stored with no further interpretation by the database.The blobs for flashing NVIDIA Tegra devices have a specific structure - they contain one or more raw images to be flashed to one or more partitions on the device.
The full firmware blob for the TF700 contains images for 5 partitions, which we will now extract from the blob. If you don't have blobunpack, get the sources from https://github.com/AndroidRoot/BlobTools - how to do that and how to compile them may be part of another tutorial. I also assume you have blobunpack somewhere in your $PATH.
Code:
[email protected] ~/android/tf700/kernel $ blobunpack blob
Header size: 60
5 partitions starting at offset 0x3C
Blob version: 65536
Partition 0
Name: PT
Offset: 140 (0x8C)
Size: 524288 (0x80000)
Writing file blob.PT (524288 bytes)
Partition 1
Name: EBT
Offset: 524428 (0x8008C)
Size: 1566813 (0x17E85D)
Writing file blob.EBT (1566813 bytes)
Partition 2
Name: SOS
Offset: 2091241 (0x1FE8E9)
Size: 6410496 (0x61D100)
Writing file blob.SOS (6410496 bytes)
Partition 3
Name: LNX
Offset: 8501737 (0x81B9E9)
Size: 5595392 (0x556100)
Writing file blob.LNX (5595392 bytes)
Partition 4
Name: APP
Offset: 14097129 (0xD71AE9)
Size: 805306368 (0x30000000)
Writing file blob.APP (805306368 bytes)
OK, now we have separate files for each partition. The next step is again optional, just to illustrate what happened:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2059512
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
blob.APP is a raw image of a Linux ext4 partition. If you are interested in the contents, you can loop mount this file and access all files inside directly on your Linux computer. This is the filesystem that is mounted as /system - the ROM as you all know it.
blob.EBT is the bootloader.
blob.LNX is the boot image - the Linux kernel and the ramdisk, which is later seen as "/". This is the one we are after.
blob.PT is the Tegra partition table. This is a proprietary format, not a PC-compatible partition table.
blob.SOS is the recovery boot image - another Linux kernel and another ramdisk, but this ramdisk contains the stock recovery (incl. the dreaded "dead android").
Now, what's actually a boot image, and how do we recognize one if we see one? As usual, the best answer is: look inside! (again - optional, just to learn something)
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blob.LNX
00000000 41 4e 44 52 4f 49 44 21 58 0c 4e 00 00 80 00 10 |ANDROID!X.N.....|
00000010
An Android boot image begins with the text "ANDROID!". Easy.
(maybe sbdags now starts to smack his head and realizes why blobunpack does not work here - and if anyone is still in doubt - a boot image is not a blob)
Good, but how do we crack this thing open? Fortunately there are two small perl scripts I extracted from dsixda's Android kitchen (they are in tools/extract_boot_files):
Code:
[email protected] ~/android/tf700/kernel $ extract-kernel.pl blob.LNX
[email protected] ~/android/tf700/kernel $ extract-ramdisk.pl blob.LNX
1932 blocks
OK, what happened?
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2064524
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
We got a new file (zImage) and a directory (blob.LNX-ramdisk)!
zImage is the kernel image. It is the result of compiling a kernel from sources. Today, we will not compile a new kernel, just repack this image with our modified ramdisk.
What blob.LNX-ramdisk contains should be obvious.
Now we can start modifying the ramdisk. A CleanROM ramdisk differs from a stock ramdisk in only 3 files:
- sbin/adbd
- default.prop
- init.rc
sbin/adbd is the adb daemon - the program that handles the tablet's side of the adb protocol. The stock version runs under the "shell" user account, which has limited permissions and cannot access all files on the tablet. The CleanROM version of adbd runs as "root", so "adb push" and "adb pull" can write or read any file on the device, and "adb shell" goes directly to a root prompt.
I don't know where scrosler got this binary from, I just copied it from his CleanROM kernel's ramdisk. You can do the same - now you already know how to extract a ramdisk, so just do the same with the CleanROM kernel in another directory.
default.prop contains only a few lines. Here is the already modified CleanROM version:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
In the original file, ro.secure=1 (which would limit adb to the "shell" account again), ro.debuggable=0 (I'd have to look up what exactly this does), and persist.sys.usb.config=mtp without adb (I think this modification is what automatically enables "USB debugging" at boot time).
Finally, init.rc has a few additional lines to enable init.d support. This means the boot sequence will run any scripts in /etc/init.d - this a simplified version of a usual convention for desktop Linux systems. CleanROM uses it to set up various tweaks (look into /system/etc/init.d on your device).
To illustrate the changes in init.rc, I use the "diff" command (and you can too, if you want - just use the correct paths for your setup instead of mine):
Code:
[email protected] ~/android/tf700/kernel $ diff -u blob.LNX-ramdisk/init.rc ~/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc
--- blob.LNX-ramdisk/init.rc 2013-01-19 19:59:03.000000000 +0100
+++ /home/that/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc 2013-01-19 01:24:43.000000000 +0100
@@ -309,6 +309,8 @@
# Set this property so surfaceflinger is not started by system_init
setprop system_init.startsurfaceflinger 0
+ start sysinit
+
class_start core
class_start main
@@ -413,6 +415,10 @@
user drm
group drm system inet drmrpc sdcard_r
+service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ disabled
+ oneshot
+
service media /system/bin/mediaserver
class main
user media
If you have never read a diff before (also called a patch), here a quick guide:
- Lines beginning with "---" and "+++" identify the two files that were compared.
- Lines beginning with "@@" specify line numbers in the two files. -309,6 +309,8 means: The next block contains 6 lines starting with line 309 from file 1 (---), and 8 lines starting with line 309 in file 2 (+++). In other words, this means that two lines were inserted there.
- The following lines start with a blank - they are context lines. These lines are common in both files and only used to see some context around the change.
- Lines beginning with "+" exist only in file 2 (+++). You can easily remember all this if you know that a diff describes how to edit file 1 to be identical to file 2 - you delete lines marked with "-" and insert lines marked with "+". With only these two operations, you can transform any text file to any other - in the worst case you will delete all lines of the original file and insert all lines of the new file.
The second block works like the first one - here we insert 4 lines near line 413 (which has become line 415 after our first insertion).
You have the following options to apply this change:
1. Simply copy over the changed version from the previous CleanROM kernel. Do a diff before to verify that Asus didn't change anything, otherwise you will undo Asus' changes.
2. Use the "patch" tool to apply the diff file from above. This will automatically perform the edit steps in the diff file and it also has some tolerance if something changed in other sections of the file.
3. Use a text editor and perform the changes manually. If you copy lines from the diff (and not the original init.rc), make sure you don't accidentally copy the leading "+" - this is only for the diff and should not part of the file.
OK, phew, we finally have a modified ramdisk - now we need to repack everything, basically the reverse of the first few steps. For this I use a self-written shell script. First let's just run it:
Code:
[email protected] ~/android/tf700/kernel $ repack-kernel.sh
Found 1 partitions as commandline arguments
Partname: LNX Filename: blob.LNX
Size: 60
1 partitions starting at offset 0x3C
Offset: 76
8+0 records in
8+0 records out
8 bytes (8 B) copied, 0,000136275 s, 58,7 kB/
OK, what happened here? Since I wrote this script myself, I can explain it line by line:
Code:
[email protected] ~/android/tf700/kernel $ cat ~/bin/repack-kernel.sh
#!/bin/bash
~/android/Android-Kitchen/tools/mkboot/mkbootfs blob.LNX-ramdisk | gzip > ramdisk.gz
~/android/Android-Kitchen/tools/mkboot/mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
blobpack blobtmp LNX blob.LNX
echo -n "-SIGNED-BY-SIGNBLOB-" > blob
dd if=/dev/zero bs=1 count=8 >> blob
cat blobtmp >> blob
The ramdisk is repacked and zipped again. This creates ramdisk.gz.
The kernel is merged with the ramdisk to a new boot image, to create blob.LNX. If you paid attention before, yes, this will overwrite the old blob.LNX. If you want, you can check again with hexdump that it is really a boot image (it begins with "ANDROID!").
Now we pack the boot image into a blob. However, the "original" version of blobtools does not create a signed blob. See:
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blobtmp
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010
That was the blob format for the TF101. For later Transformers, we need to prepend a signature header. As we don't have Asus' cryptographic keys, we cannot create a valid signature - but fortunately, since we have an unlocked bootloader, we don't actually need to add a proper signature - the header is enough. There are two ways to create this header - there is a modified version of blobtools in circulation that has a command line option for it, but I do it "manually" with echo and dd.
The final output is again simply called "blob" - this is the new blob that now contains only the kernel. (It overwrites the original blob, which is not really intended, but I just didn't care).
For comparison, now we have this:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 1274980
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 5599336 19. Jän 20:35 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5599232 19. Jän 20:35 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5599308 19. Jän 20:35 blobtmp
-rw-r--r-- 1 that users 479752 19. Jän 20:35 ramdisk.gz
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
Congratulations, you have a flashable blob with your new kernel. But how do you get it onto your device?
Again, there are two ways:
The first option is to copy the blob to your tablet's staging partition manually and reboot:
Code:
[email protected] ~/android/tf700/kernel $ adb push blob /sdcard/kernel-10.4.4.25.blob
1324 KB/s (5599336 bytes in 4.128s)
[email protected] ~/android/tf700/kernel $ adb shell
sh-3.2# dd if=/sdcard/kernel-10.4.4.25.blob of=/dev/block/mmcblk0p4
10936+1 records in
10936+1 records out
5599336 bytes transferred in 0.129 secs (43405705 bytes/sec)
Be very careful with the dd command and double-check that you didn't swap "if" and "of", and that you specified the correct target partition *before* you hit Enter.
Now reboot your tablet, and the bootloader will flash your new kernel from the blob to the actual kernel partition (notice the progress bar on the boot screen with the slightly broken graphics, as usual). The tablet will reboot again automatically, and if you did everything right, your shiny new kernel will be running!
OK, now to option 2 - pack the blob into a flashable zip that you can flash in the recovery. The easiest way to do this is to reuse the original firmware zip. Just replace the blob inside the big firmware zip, and that's it - you have a recovery-flashable zip!
Code:
[email protected] ~/android/tf700/kernel $ mv WW_epad-user-10.4.4.25.zip kernel-10.4.4.25.zip
[email protected] ~/android/tf700/kernel $ zip -d kernel-10.4.4.25.zip blob
deleting: blob
[email protected] ~/android/tf700/kernel $ zip kernel-10.4.4.25.zip blob
adding: blob (deflated 1%)
This would not be a good tutorial if I didn't explain how and why this actually works. Let's look inside!
Code:
[email protected] ~/android/tf700/kernel $ unzip kernel-10.4.4.25.zip META-INF/*
Archive: kernel-10.4.4.25.zip
signed by SignApk
inflating: META-INF/com/google/android/resource
inflating: META-INF/com/google/android/rule
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
The core of a flashable zip is the updater-script. For a full firmware, it is very short:
Code:
[email protected] ~/android/tf700/kernel $ cat META-INF/com/google/android/updater-script
assert(package_extract_file("blob", "/tmp/blob"), write_raw_image("/tmp/blob", "staging"),delete("/tmp/blob"));
This line instructs the recovery to extract the blob from the zip file to /tmp/blob and then copy it to the staging partition - essentially it is exactly the same as we did manually in option #1 above!
OK, now the secret is fully disclosed - I hope you learned something. If you have further questions, or if you need help compiling some of the mentioned binaries, don't hesitate to ask (if it's not something like "how do I use the Linux command line" ).
Click to expand...
Click to collapse
Wow! Many thanks! :victory:
Will digest this tomorrow but yes I recognised my smack head moment! :laugh:

Hmmm, my extreme pro 16gb seems to work fine with this kernel. Using/testing it as an external storage, formatted as fat32. Before it wasen't even recognized when inserted. In recovery (twrp) the card is still not recognized but in android (cleanrom 3.1) it works fine.

New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
But still thanks for your work and sorry if it's all sounds not very good...

Blue cat said:
New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
Click to expand...
Click to collapse
That's a bit harsh don't you think.

sbdags said:
That's a bit harsh don't you think.
Click to expand...
Click to collapse
Yes,sorry if it's sounds harsh,forgot add in my post gratitude for his work,cant edit next 5 min.I just very want OC and new kernel.

Blue cat said:
Yes,sorry if it's sounds harsh,forgot add in my post gratitude for his work,cant edit next 5 min.I just very want OC and new kernel.
Click to expand...
Click to collapse
_that has only worked on the Asus Stock kernel, for which I am extremely grateful. It gives those users who don't want to OC anything the ability to have a custom rom on the new kernel. From my testing it works better than the old kernel and is very stable.
I will be looking at the Clemsyn kernels in the mean time to see if I can bring them onto the new kernel base and the benefits they bring.
Please be patient, these are not 5 minute jobs. It can take many hours to unpack, decompile, edit, recompile, repack a kernel into a working flashable package. Then we have to test it and live with bootloops and soft bricks if we get it wrong. I can not tell you how many times I have had to restore my Infinity due to one line of code wrong or a badly compiled apk. It's all so you don't have to.
Anyway I'm sure you understand :good: Why don't you read the guides and have a go yourself? Always good to have more people able to do this type of work

sbdags said:
Why don't you read the guides and have a go yourself?
Click to expand...
Click to collapse
I tried to understand,but it's all very hard for me and ok i will be wait your new kernel with OC

Blue cat said:
New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
Click to expand...
Click to collapse
This is a 100% stock kernel with just a custom ramdisk. Stock kernels never have any of the features you describe here.
Asus have not released their sources for 10.4.4.25 yet, and Clemsyn's kernel sources are a big mess. As soon as sources are released, it is possible to build a new kernel with OC features.
sbdags said:
I will be looking at the Clemsyn kernels in the mean time to see if I can bring them onto the new kernel base and the benefits they bring.
Click to expand...
Click to collapse
Do you have a clue how to build the kernels in your kernel installer from Clemsyn's sources?
sbdags said:
Please be patient, these are not 5 minute jobs.
Click to expand...
Click to collapse
Right, this kernel was more like 10 minutes work. Writing the tutorial took more than 2 hours.

_that said:
Do you have a clue how to build the kernels in your kernel installer from Clemsyn's sources?
/QUOTE]
Nope. Just unpacked yours and clemsyn's. Right, that's not going to happen anytime fast!
:laugh:
Click to expand...
Click to collapse

Great job, _that, you have my sincere thanks. I still cannot find the Thanks button on my screen because of all the blood and brain tissue that got on there when my head exploded. I'll take a walk over to the ED department to get that fixed with a printed plastic cranium, glue it shut, cover it up with a few bandages, get back to my own department and then clean up for a bit. When I finally regain something of a normal level of consciousness I'll try and step into the shadown you throw upon me, and press the damn button.
EDIT: button pressed. Speech still slurring a bit, minor tremor in the left hand and incontinent for both faeces and urine. Apart from that, I'm fine, thanks for asking.
Just kidding, obviously. I've read along, and I get most parts theoretically. Thanks for making me learn -- the most important mental facility we humans have.

Hey very good tutorial
I just unpacked your kernel and take a look inside the ramdisk and repacked the blob.
And it boots up normaly without problems.
Now I am waiting for Asus to release their latest kernel sources that I can modify the kernel itself, too and not only the ramdisk.
Thanks for helping me with that blob stuff!

blackmambazzz said:
Hey very good tutorial
I just unpacked your kernel and take a look inside the ramdisk and repacked the blob.
And it boots up normaly without problems.
Click to expand...
Click to collapse
:good: Great!
blackmambazzz said:
Now I am waiting for Asus to release their latest kernel sources that I can modify the kernel itself, too and not only the ramdisk.
Click to expand...
Click to collapse
Do you have any specific mods in mind?

_that said:
Do you have any specific mods in mind?
Click to expand...
Click to collapse
I think about this features but nothing for sure
more governors
more io-scheduler
compiled with linaro and -o3 optimizations
add fsync control
add oc (by this one i need help I think)
increase readahead

NODPI Update!
Excellent work _that! I will implement the nodpi kernel into the kernel flasher tomorrow and when the odex rom is finished I'll put it in instead of the one there now. :good::good::good:

Thank you, _that, for your hard work. Your kernel seems to be faster than Clemysn's, at least on first sight (scr** the benchmark hippies -- it feels faster, OK? ).
Flashing this was so fast, I thought I had accidentally pressed "reboot system now" instead of actually flashing your kernel. Off to testing a bit more! ; )

[GUIDE][UTIL][MT65xx] Create Scatter File and Dump Full ROM

[GUIDE][UTIL][MT65xx] Create Scatter File / Dump Full ROM
For any MT65xx device, no matter how obscure.
I will discuss a method for:
* making your own SPFT scatter file
* dumping your entire ROM (without root)
* dicing up your entire ROM into partition blocks
This is somewhat of a manual process. rua1's MTK Droid Root & Tools circumvents the need for doing most of this. I applaude his work, it's a big undertaking and he supports it well.
Here are a few reasons to use the method I discuss here:
* you want a ROM dump without rooting
* you want a ROM dump without your OS booted (clone cold system is safe)
* you want a guaranteed way to restore exactly current state (safety and return to store)
* you are just plain worried something will go wrong
-------------------------------------
I have two methods for creating a scatter file.
Method #1
Find your scatter information in SP Flash Tool's Logs
Well first, you have to make SP Flash Tool happy enough to give you some information about your device.
* Obtain a SPFT ROM that is known good for any phone/tablet, preferrably with the same chip as yours. Make sure that scatter file loads into SPFT without error, SPFT checks the PRELOADER and DSP_BL and if they aren't in the scatter directory, it will fail and maybe crash.
* Close SPFT, now modify the MT*scatter.txt file and introduce a few errors in the partition names, but don't change PRELOADER or DSP_BL. An example, instead of "ANDROID" replace it with "DEADBEEF". You ask why? Well you want to make SURE that the "Download" feature fails. You DON'T want the "Download" to actually work and write your random SPFT ROM to your new device. After loading the freshly broken scatter file, click "Download" and hook up your MTK device in preloader / META Mode. It will say your PMT block does not match the scatter file. ERROR:
* Go to SPFT's menu "Help / Open logs folder" and find the latest date. Open the BROM_DLL*.log in your text editor. Search for text that looks like this, I'd first search for "CMD_ReadPartitionInfo():
Code:
11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): command is allowed. (FlashToolLib/sv5/common/generic/src/da_c
md.cpp:5242)
11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): getting 20 partitions .. (FlashToolLib/sv5/common/generic/src
/da_cmd.cpp:5269)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): dump 20 partitions (FlashToolLib/sv5/common/generic/src/da_cm
d.cpp:5279)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[0 ](PRELOADER ) - offset (0x0000000000000000) - size (0x0000000000040000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[1 ](DSP_BL ) - offset (0x0000000000040000) - size (0x00000000005C0000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[2 ](MBR ) - offset (0x0000000000600000) - size (0x0000000000004000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[3 ](EBR1 ) - offset (0x0000000000604000) - size (0x000000000005C000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[4 ](__NODL_PMT ) - offset (0x0000000000660000) - size (0x0000000000400000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[5 ](__NODL_NVRAM ) - offset (0x0000000000A60000) - size (0x0000000000300000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[6 ](__NODL_SECCFG ) - offset (0x0000000000D60000) - size (0x0000000000020000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[7 ](UBOOT ) - offset (0x0000000000D80000) - size (0x0000000000060000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[8 ](BOOTIMG ) - offset (0x0000000000DE0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[9 ](RECOVERY ) - offset (0x00000000013E0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[10](SEC_RO ) - offset (0x00000000019E0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[11](__NODL_MISC ) - offset (0x0000000001FE0000) - size (0x0000000000060000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[12](LOGO ) - offset (0x0000000002040000) - size (0x0000000000300000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[13](__NODL_EXPDB ) - offset (0x0000000002340000) - size (0x00000000000A0000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[14](EBR2 ) - offset (0x00000000023E0000) - size (0x0000000000004000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[15](FAC ) - offset (0x00000000023E4000) - size (0x0000000010000000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[16](ANDROID ) - offset (0x00000000123E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[17](CACHE ) - offset (0x00000000324E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[18](USRDATA ) - offset (0x00000000525E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[19](FAT ) - offset (0x00000000726E4000) - size (0x0000000000000000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
Make sure you aren't looking at a dump of your scatter, but looking at the partition dump from your device. (If it contains DEADBEEF flag from above, you are looking at the wrong part of the log.) You can manually create a scatter file from that, or you can paste the lines with partition info into a text file and run this shell script:
Code:
cat pastedlog.txt | sed -n 's/.*](\([^ ]*\)[^(]*(\([^)]*\).*)/\1 \2\n{\n}/p' | sed 's/x00000000/x/g' > mynewscatter.txt
This will get you really close, but the last entry you see in a typical scatter file is BMTPOOL. I don't know much about BMTPOOL or __NODL_BMPPOOL other than it's not a real partition. It might not even be required? (You might be able to fake that entry if you look at similar scatter files. If not, read on)
Method #2
An alternate and supplemental way of getting scatter info is to use ADB on a running device. I'm sure this is similar to MTK Droid Root & Tools method.
Code:
adb pull /proc/dumchar_info
Now that you have that file local on your PC, you can run this python script:
Code:
import sys
import string
import re
ins = open( "dumchar.txt", "rb" )
outs = open( "scatter.txt", "wb" )
for line in ins:
linesp = re.split('\W+', line)
name = linesp[0].upper()
start = int(linesp[2],16)
block = linesp[5]
if block != 'misc':
start = start + 0x600000
outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n")
ins.close()
outs.close()
This method gives you the BMTPOOL entry that the other method does not, but it lacks the __NODL_ designator for all partitions. If you aren't familiar with that prefix, SPFT uses that to know if it should typically allow you to DownLoad over the top of the paritition.
With both scatter files, throw them side-by-side in a text editor (or diff tool) and with a brain, it's easy enough to merge one with the __NODL_ prefix and the one with the BMTPOOL entry.
Scatter file complete!
PS - Possibly another way, is to use SPFT to do a "Read back" (read memory) at 0x660000 of size 0x400000. Save this as the PMT block and analyse it with a hex editor. I believe the PMT block is always at address 0x66000 judging from a dozen different scatter files.
Dump Full ROM
Perfect Total Backup of your Firmware
The safe way to do this with or without a proper scatter file is the "Read back" feature of SP Flash Tool. There are MANY reasons to dislike MediaTek, but this feature is so nice that I can forgive them for most of their wrong doing.
Most of this section I will generalize from my Lenovo A2107A Guide.
Here is a cookbook for doing a total backup of your MTK device with MediaTek's SP Flash Tool. No rooting, you might even do this before you ever boot! I have basically done this with both of my devices before I fiddled too much. I recommend doing it before you do anything really.
1. Install VCOM Drivers.
2. Install SP Flash Tool.
3. Grab an SPFT ROM, really anything should work, you just have to make SP Flash Tool happy. SPFT validates the scatter file against some of the image files, so you have to calm SPFT down by giving it something it can make sense of. We won't use the scatter file or image files while we do the "Read back" operation.
4. Run SP Flash Tool, Open Scatter File
5. Don't play with anything, go into the "Read back" tab (This will read your flash to a file on your PC)
6. Click on any items in the list, then click the "Remove" button
7. Now click the "Add" button
8. Double click on the "N/A" under Read Flag
9. Type a file name to write to, like "WHOLE_ROM"
10. Now it will popup a window "Readback block start address"
11. Leave "Hex" selected, Start Address" 0x0000, Length: 0x40000000, Click OK (NOTE: this will get the first GIG of flash)
12. Click the "Read back" button
13. SPFT now waits for you to connect your device and put it in Meta Mode
14. Without plugging your phone/tablet in, tap the Reset Button or make sure it's fully off
15. Hold VolUp, plug in USB, Release VolUp (putting it in Meta Mode) <--- Important
16. You will see the progress bar moving. Total backup takes forever, because in this mode SPFT seems to not do USB HIGHSPEED
That's IT! It'll take a few hours, so go to bed.
If you ever restore, just go into Recovery and Wipe Data and Cache. (as these are large and we probably didn't back them up above)
Note: "Length" in Step 11 is probably long enough for most devices. You can reference the scatter file you made above to make sure get everything, but you don't need USRDATA or CACHE, as those get wiped anyway.
Dicing up Full ROM image into partition images
I've made a little bash shell script to dice up a whole ROM according to a scatter file. This creates files exactly the size of the partitions. Some post processing needs done below the script:
dice.sh
Code:
#!/bin/bash
scatterfile=$1
rom=$2
pdir=raw.partitions
rm -rf $pdir
mkdir $pdir
cat $scatterfile | grep "x" | while read line; do
name=$(echo $line | sed 's/ .*//g')
name=$(echo $name | sed 's/^__NODL_//g')
start=$(echo $line | sed 's/.* //g')
# echo $name
if [[ -n $last_name ]]; then
echo "Processing: $last_name"
echo " start: $last_start"
size=$(( $start - $last_start ))
if [[ $size -lt 0 ]]; then
size=0xFFFFF000
else
size=0x$(echo "obase=16; $size" | bc)
fi
echo " size: $size"
short_start=$(echo $last_start | sed 's/000$//g')
short_size=$(echo $size | sed 's/000$//g')
echo dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
fi
last_name=$name
last_start=$start
done
Now there is some post processing done. Truncate MBR, EBR1, EBR2 to 512 bytes. And remove trailing bytes of 0000 or FFFF on the end of PRELOADER and DSP_BL.
Here is a one off script for example use:
clean.sh
Code:
#!/bin/bash
pdir=raw.partitions
odir=out
rm -rf $odir
mkdir $odir
dd if=$pdir/PRELOADER of=$odir/preloader.bin bs=$(( 0x800 )) skip=1
./trim.sh $odir/preloader.bin
./trimFF.sh $odir/preloader.bin
dd if=$pdir/DSP_BL of=$odir/DSP_BL bs=$(( 0x8000 )) count=1
./trimFF.sh $odir/DSP_BL
dd if=$pdir/MBR of=$odir/MBR bs=512 count=1
dd if=$pdir/EBR1 of=$odir/EBR1 bs=512 count=1
dd if=$pdir/EBR2 of=$odir/EBR2 bs=512 count=1
cp $pdir/UBOOT $odir/uboot.bin
cp $pdir/LOGO $odir/logo.bin
./trim.sh $odir/logo.bin
cp $pdir/SEC_RO $odir/secro.img
cp $pdir/RECOVERY $odir/recovery.img
cp $pdir/BOOTIMG $odir/boot.img
cp $pdir/FAC $odir/fac.img
cp $pdir/ANDROID $odir/system.img
cp MT*.txt $odir/
And quickly, Here is my hack to remove 0000 and FFFF from the end of files:
trim.sh
Code:
#!/bin/bash
truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
| grep -v ": 00000000" | tail -n 1 | sed 's/:.*//') )) $1
trimFF.sh
Code:
#!/bin/bash
truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
| grep -v ": FFFFFFFF" | tail -n 1 | sed 's/:.*//') )) $1
You should be able to read the clean.sh script and figure out only in just those few cases, is special post processing needed. If you don't post process, SPFT will give errors.
I hope this helps. If you have any questions, ask... I'll try to clarify this first post.

syserr said:
[GUIDE][UTIL][MT65xx] Create Scatter File / Dump Full ROM
For any MT65xx device, no matter how obscure.
Dicing up Full ROM image into partition images
I've made a little bash shell script to dice up a whole ROM according to a scatter file. This creates files exactly the size of the partitions. Some post processing needs done below the script:
dice.sh
Code:
#!/bin/bash
scatterfile=$1
rom=$2
pdir=raw.partitions
rm -rf $pdir
mkdir $pdir
cat $scatterfile | grep "x" | while read line; do
name=$(echo $line | sed 's/ .*//g')
name=$(echo $name | sed 's/^__NODL_//g')
start=$(echo $line | sed 's/.* //g')
# echo $name
if [[ -n $last_name ]]; then
echo "Processing: $last_name"
echo " start: $last_start"
size=$(( $start - $last_start ))
if [[ $size -lt 0 ]]; then
size=0xFFFFF000
else
size=0x$(echo "obase=16; $size" | bc)
fi
echo " size: $size"
short_start=$(echo $last_start | sed 's/000$//g')
short_size=$(echo $size | sed 's/000$//g')
echo dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
fi
last_name=$name
last_start=$start
done
Click to expand...
Click to collapse
hi syserr,
i m tryin to run the script dice.sh and this is the trace i get
Code:
[email protected] ~/TESTbcup $ sh -x ./dice.sh
+
: not found2: ./dice.sh:
+ scatterfile=
+ rom=
+ pdir=raw.partitions
+
: not found6: ./dice.sh:
+ rm -rf raw.partitions
+ mkdir raw.partitions
+
: not found9: ./dice.sh:
./dice.sh: 37: ./dice.sh: Syntax error: end of file unexpected (expecting "then")
[email protected] ~/TESTbcup $
any advice would be welcome. I dumb a complete rom and try to dice it.
thank you syserr

fragargon said:
hi syserr,
i m tryin to run the script dice.sh and this is the trace i get
Code:
[email protected] ~/TESTbcup $ sh -x ./dice.sh
+
: not found2: ./dice.sh:
+ scatterfile=
+ rom=
+ pdir=raw.partitions
+
: not found6: ./dice.sh:
+ rm -rf raw.partitions
+ mkdir raw.partitions
+
: not found9: ./dice.sh:
./dice.sh: 37: ./dice.sh: Syntax error: end of file unexpected (expecting "then")
[email protected] ~/TESTbcup $
any advice would be welcome. I dumb a complete rom and try to dice it.
thank you syserr
Click to expand...
Click to collapse
Sorry Sorry Sorry. It takes 2 arguments, I should do some error checking and make sure the user supplies them.
Code:
./dice.sh scatterfile.txt FULLROM.img
It might have some syntax that is specific to bash, so "sh" might throw errors too.

Dumchar.txt
I did dumchar_info, I've renamed it dumchar.txt.
Run script , and it gives me error(He created and an scatter.txt), but empty - see image

Dumchar.txt
What happens and what is the solution?

Alex1948 said:
I did dumchar_info, I've renamed it dumchar.txt.
Run script , and it gives me error(He created and an scatter.txt), but empty - see image
Click to expand...
Click to collapse
I'm sorry, I didn't see this message before, I'm following about 10 threads and this got lost.
I also copied this over from the rua1 thread. I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.
Alex1948 said:
For @syserr
I do not know what all you write here, Python, etc.start adress + lenght , I think we know how to add two numbers in base 16 , no other ....MTKdroid is a software that solves everything,In Python a script of yours, gives me error.
I posted a picture of treadh and you did not answer why(Or you can not quite explain , and we do not understand) - see image
Click to expand...
Click to collapse
Answers:
I've never run it without putting it in a file. Put that python text in dumchar2scatter.py, or something like that. I'm 99% sure that will get rid of the error and give you stuff in your scatter file. You are using Python2, that is good!
You are free to PM me why you feel I didn't see a post. Again, sorry.
Because I think you are genuinely interested in learning, I will describe what my little script is doing. (btw, this is about my third program/script in Python ever)
Code:
import sys
import string
import re
ins = open( "dumchar.txt", "rb" ) [COLOR=Blue]# creates a file handle (ins) to read in dumchar.txt[/COLOR]
outs = open( "scatter.txt", "wb" ) [COLOR=Blue]# creates a file handle (outs) to write to scatter.txt[/COLOR]
for line in ins: [COLOR=Blue]# loops through each line of the input file and puts each line in variable "line"[/COLOR]
linesp = re.split('\W+', line) [COLOR=Blue]# this splits the line varable based on whitespace/spaces, results go into linesp array[/COLOR]
name = linesp[0].upper() [COLOR=Blue]# grabs the first thing in the line, uppercases it, puts it in a varable called name[/COLOR]
start = int(linesp[2],16) [COLOR=Blue]# start variable gets the value of the 3rd thing in the line, but also converts it to an int from text[/COLOR]
block = linesp[5] [COLOR=Blue]# block variable gets 6th thing in line - usually misc or blk[/COLOR]
if block != 'misc': [COLOR=Blue]# if the block variable is NOT 'misc' (only preloader and dsp_bl are these) then ...[/COLOR]
start = start + 0x600000 [COLOR=Blue]# add the offset to the start variable[/COLOR]
outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n") [COLOR=Blue]# write out name with start address followed by { } on newlines[/COLOR]
ins.close() [COLOR="Blue"]# just close the file handles here, to clean up, outs might need last writes to be flushed to file.[/COLOR]
outs.close()
I've previewed the code block above on this forum. Why is it so narrow, sorry you will need to use the scrollbar a lot.
UPDATE: Also it's important to have SPACES in a python file, not tabs. And the spaces are critical for python to know code blocks, it acts like {} in Java/C. So, when you make your python file, use spaces to make sure lines line up just right.

syserr said:
I'm sorry, I didn't see this message before, I'm following about 10 threads and this got lost.
I also copied this over from the rua1 thread. I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.
Answers:
I've never run it without putting it in a file. Put that python text in dumchar2scatter.py, or something like that. I'm 99% sure that will get rid of the error and give you stuff in your scatter file. You are using Python2, that is good!
You are free to PM me why you feel I didn't see a post. Again, sorry.
Because I think you are genuinely interested in learning, I will describe what my little script is doing. (btw, this is about my third program/script in Python ever)
Code:
import sys
import string
import re
ins = open( "dumchar.txt", "rb" ) [COLOR=Blue]# creates a file handle (ins) to read in dumchar.txt[/COLOR]
outs = open( "scatter.txt", "wb" ) [COLOR=Blue]# creates a file handle (outs) to write to scatter.txt[/COLOR]
for line in ins: [COLOR=Blue]# loops through each line of the input file and puts each line in variable "line"[/COLOR]
linesp = re.split('\W+', line) [COLOR=Blue]# this splits the line varable based on whitespace/spaces, results go into linesp array[/COLOR]
name = linesp[0].upper() [COLOR=Blue]# grabs the first thing in the line, uppercases it, puts it in a varable called name[/COLOR]
start = int(linesp[2],16) [COLOR=Blue]# start variable gets the value of the 3rd thing in the line, but also converts it to an int from text[/COLOR]
block = linesp[5] [COLOR=Blue]# block variable gets 6th thing in line - usually misc or blk[/COLOR]
if block != 'misc': [COLOR=Blue]# if the block variable is NOT 'misc' (only preloader and dsp_bl are these) then ...[/COLOR]
start = start + 0x600000 [COLOR=Blue]# add the offset to the start variable[/COLOR]
outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n") [COLOR=Blue]# write out name with start address followed by { } on newlines[/COLOR]
ins.close() [COLOR="Blue"]# just close the file handles here, to clean up, outs might need last writes to be flushed to file.[/COLOR]
outs.close()
I've previewed the code block above on this forum. Why is it so narrow, sorry you will need to use the scrollbar a lot.
UPDATE: Also it's important to have SPACES in a python file, not tabs. And the spaces are critical for python to know code blocks, it acts like {} in Java/C. So, when you make your python file, use spaces to make sure lines line up just right.
Click to expand...
Click to collapse
OK, I get it("" I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.""
, and why I posted here.
I do not know python, but try to understand more about these phones and their software.
A carefully read what I've written for other questions, as I have, and across from method 1, and there I have some questions.
Especially that last for hours at a READ BACK ,Dump Full ROM , with start adress and lenght by you.
I understand your explanation, written in the program right lines.I did not need them, I know what each instruction written there.
I do not know python but I want to understand .Look - I send you dumchar_info and firmware.info , with partitions start adress and lenght and see what you get.
And finally you get scatter file , my SCATTER FILE , block info - start adress , size , etc.
It's OK. ?As we do not just theory.
I liked your idea, what you wrote but I want to see it completed

Crashes
I did as you said. Look :
Send and dumchar.txt and dumchar2scatter.py
It's ok, I'm sorry you do not answer.I also sent a file and I wanted to enlighten and method 1.
I feel that all that script and dump rom are stupid
I think you should post here on this thred, not on MTKDroid Tool.
Sorry, if you prove me wrong
I'm sorry special excuse but if the script does not work , I posted the file dumchar.txt ,the idea that a fix you
It again sorry, did not mean to upset

Scatter.txt
Successful scatter.txt.As shown in the picture has the same start adress with MTKDroid scatter file , without __NODL_ to 10 partitions.
SP Flash Tool , scatter - loading , load all - see image 2.
For Read Back why use it or one obtained with MTKDroid(see image 3)
Tks.

Alex1948 said:
It's ok, I'm sorry you do not answer.
Click to expand...
Click to collapse
Hi Alex, I figured out why I wasn't catching your posts here. I'm normally looking at my Subscribed threads, and I hadn't subscribed to this thread. I should subscribe and look at my notifications too.
I will look at your messages today. My script is "dumb" as it's looking for a certain path for the block device in the output of dumchar. If that output changes, my script will probably fail.

Alex1948 said:
Successful scatter.txt.As shown in the picture has the same start adress with MTKDroid scatter file , without __NODL_ to 10 partitions.
SP Flash Tool , scatter - loading , load all - see image 2.
For Read Back why use it or one obtained with MTKDroid(see image 3)
Tks.
Click to expand...
Click to collapse
I see it's working for you now. Great. We could make great tools, but MediaTek is changing things that cause problems for even rua1's MTKDRT. Personally, I think it's good to understand things. I'm glad you want to understand too.

Nice share :fingers-crossed:

WHOLE_ROM
4. Run SP Flash Tool, Open Scatter File :
- What scatter file upload ? images 1(that obtained with MTKDroid) or scatter.txt (renamed) and otained with dumchar , script pyton....see images 2. ???
- Start adress is 0x00000000 , but Lenght can pass 0xE7F20000 (start adress FAT=0xC81C0000+FAT lenght=0x1FD60000) END adress FAT ???
With this file, probably higher, than 1GB ,WHOLE_ROM - without extension , What do I do next ?
- to get all the MTKDroid A5_Duo_130806_ForFlashtoolFromReadBack_131007-212823 - see image 3(for this we used start adress 0x00000000 and Lenght 0x3c9c0000 - my CACHE start adress) and My ROM_0 has - 969 MB
And another CWM recovery, more personalized for this phone with can be done?Android-Kitchen-0.224 ? Need 2 files(system.img and boot.img)
I installed and cygwin but does not work, crashes

Alex1948 said:
4. Run SP Flash Tool, Open Scatter File :
- What scatter file upload ? images 1(that obtained with MTKDroid) or scatter.txt (renamed) and otained with dumchar , script pyton....see images 2. ???
- Start adress is 0x00000000 , but Lenght can pass 0xE7F20000 (start adress FAT=0xC81C0000+FAT lenght=0x1FD60000) END adress FAT ???
With this file, probably higher, than 1GB ,WHOLE_ROM - without extension , What do I do next ?
- to get all the MTKDroid A5_Duo_130806_ForFlashtoolFromReadBack_131007-212823 - see image 3(for this we used start adress 0x00000000 and Lenght 0x3c9c0000 - my CACHE start adress) and My ROM_0 has - 969 MB
And another CWM recovery, more personalized for this phone with can be done?Android-Kitchen-0.224 ? Need 2 files(system.img and boot.img)
I installed and cygwin but does not work, crashes
Click to expand...
Click to collapse
#3 and #4 go hand in hand. You just need to make SPFT happy. In all my testing, the scatter and img files can be WRONG... *IF* all you are doing is using "Read back" and "Write memory". It makes sense that to do raw reads and writes, you wouldn't need to know the structure. But this tool forces you to have a scatter and images so it will perform the read/write tasks.
On your second issue, the "FAT" block is not very important and at least on ICS 4.0.4 on my device, if it is all zeros, then on first boot Android will ask to format it. On 4.0.3, I think I had to create a FAT image, which is pretty easy on Linux.

I used this "tool".
But with clean.sh I get a error about DSP_BL. In my scatterfile (MT6589) it is not there. I attached scatterfile.
Is there another "replacement" which i need to clean ?

Thanks for the guide!

Lost calibration data - Unresponsive screen
Hey guys, I have Star N9800 phone. During the last week I've been trying hard to fix my touchscreen driver since I flashed a stock ROM. The problems I was facing were checking and comparing lk.bin (lcm driver) with other people who also have same phone, downloading different ROMs and boot images, tried almost everything. I even opened my phone and disconnected the digitizer to check if it's the problem. When it's connected it says: touchscreen: ili2113a when I check version in factory mode (VOL- + HOME + POWER). When it's disconnected it says: touchscreen: (null), so obviously digitizer is working fine.
Today I think i've found the problem. While using SP Flash Tool I've used manual format from 0x00000000 to whatever it said. It deleted calibration data. And apparently calibration data is stored in nvram.bin which can be backed up using MTK Droid Tools while running a working ROM.
I have flashed original stock ROM now, I'm rooted and I can control my phone from the PC but can't use the screen. It's fully unresponsive. I've checked some answers here on XDA and some guy said I should make a nvram backup of stock ROM and then flash userdata_nvram_only.tar as USERDATA in SP Flash Tool. When I tried unzipping that .tar it clearly has /data/nvram/ folder which also contains some calibration and other files. But when I flashed that .tar as USERDATA my phone isn't booting anymore. I've tried flashing different boot.img but the problem is still here.
Does anybody know how to fix my touchscreen?
I contacted few people on www.NeedRom.com to upload userdata_nvram_only.tar for me, but I don't know whether they are going to do it or not.
I appreciate all help I can get, and I'd seriously hate if I had to send the phone back to china. I wouldn't really do it.

Posted my reply to his PM:
JoeSip said:
Wow you cleared some things for me now. I have Star N9800 smartphone. I've flashed 15 ROMs and tried disconnecting and connecting back the digitizer but screen is still unresponsive. It doesn't react at all. It could be because I used Format option and manual format option in SP Flash tool. Do you have any clue how to get my screen working again? Apparently when doing manual format from adress 0x00000000 calibration data gets removed. Please help me, i'm really desperate.
I can ask people from www.NeedRom.com to help me. They already tried because some of us have the same problems...
You could be the saviour of us all.
Click to expand...
Click to collapse
I think you are totally on track. The NVRAM block/partition is special and it really bugs me that I didn't know this up front when I killed my first MTK device, and people I trusted (ahead of me) didn't talk about it. (FYI, I bought an identical device to repair my device's NVRAM block)
The trick here is... most MTK SP Flash ROMs available don't have the NVRAM block. This is because, they are unique to the device (IMEI and MAC) and if you don't Format with SP Flash, then you don't need them.
What you need... someone with an identical device that is willing to run SP Flash and do a "Read Memory" on the address range of NVRAM block. You would get the address range from the scatter file.

JoeSip said:
Hey guys, I have Star N9800 phone. During the last week I've been trying hard to fix my touchscreen driver since I flashed a stock ROM. The problems I was facing were checking and comparing lk.bin (lcm driver) with other people who also have same phone, downloading different ROMs and boot images, tried almost everything. I even opened my phone and disconnected the digitizer to check if it's the problem. When it's connected it says: touchscreen: ili2113a when I check version in factory mode (VOL- + HOME + POWER). When it's disconnected it says: touchscreen: (null), so obviously digitizer is working fine.
Today I think i've found the problem. While using SP Flash Tool I've used manual format from 0x00000000 to whatever it said. It deleted calibration data. And apparently calibration data is stored in nvram.bin which can be backed up using MTK Droid Tools while running a working ROM.
I have flashed original stock ROM now, I'm rooted and I can control my phone from the PC but can't use the screen. It's fully unresponsive. I've checked some answers here on XDA and some guy said I should make a nvram backup of stock ROM and then flash userdata_nvram_only.tar as USERDATA in SP Flash Tool. When I tried unzipping that .tar it clearly has /data/nvram/ folder which also contains some calibration and other files. But when I flashed that .tar as USERDATA my phone isn't booting anymore. I've tried flashing different boot.img but the problem is still here.
Does anybody know how to fix my touchscreen?
I contacted few people on www.NeedRom.com to upload userdata_nvram_only.tar for me, but I don't know whether they are going to do it or not.
I appreciate all help I can get, and I'd seriously hate if I had to send the phone back to china. I wouldn't really do it.
Click to expand...
Click to collapse
I'll say a couple more things:
Yes, right now your NVRAM block is probably all zeros. And yes, you can use MTK Droid Tools to back up a good NVRAM... I like using SP Flash Tool to read the memory range of the NVRAM block, then I know it's in a shutdown state etc. All MKDRT is doing is running an adb command and doing something like "dd if=/dev/mc***** of=nvram.bin bs=1M count=1"... You could do that too with adb.
You don't need the USERDATA block at all. I would correct your request, to just ask for NVRAM. As USERDATA/USRDATA/DATA (all aliases of the same thing) is a block for your installed apps and data. It is what gets wiped when you do a Factory Reset with typical ROMs or with CWM etc.

Thank you very much man!
So now I'm supposed to just get backup of NVRAM that someone has done in MTK Droid Tools and not the whole ROM?
What if I flash full backup of someone's whole ROM? Will that save me too?