Database Info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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?

[Samsung] Unpacking 'Non-Standard' Boot.img Problems for 64 Bit Device

This is in relation to this and my post on xda.
The main reason I want to make a custom kernel is to gain root and once I successfully have then add other CPU governors, and since this is considered a low activity device on xda I will have to do this myself. Also I you are just gonna say use twrp to flash SuperSU, well I can't as it seems to not work with the device when its running Lollipop 5.1.1
Device Specifications:
Current Android Version: Android Lollipop 5.1.1
Chipset: Marvell Armada PXA1908 (Note: Due to this being a rarely used chip, the CF-Auto root won't work)
Custom Recovery Status: TWRP 3.0.2-0 (More on this later on)
Root Status (This is why I am here): Android KitKat 4.4.4 (Root) , Android Lollipop 5.1.1 (NO ROOT Yet)
ARMv8 64-bit
Now let's get into my steps up to the point and then my problem.
Note: In the kernel readme it states to use the toolchain 4.8 but when I use it, it complains of not being able to find gcc. Also in the read me it states "get Toolchain download and install arm-eabi-4.8 toolchain for ARM EABI.(64bit)" and when reading up on it, https://developer.android.com/ndk/guides/standalone_toolchain.html#syt , it says to use aarch64 for ARM 64 Bit devices.
Device Source Code can be found at Here
Code:
cd ~/android
export CROSS_COMPILE=~/android/ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-
cd ~/android/kernel
make ARCH=arm64 pxa1908_xcover3lte_eur_defconfig
make ARCH=arm64
This outputs: Image, Image.gz, .dts and .dtb files.
Where's the kernel readme (I believe this hasn't been update since kitkat) says the output will be,
- Kernel : Kernel/arch/arm/boot/zImage
- module : Kernel/drivers/*/*.ko
Note: when trying to compile with the 32- bit ARM toolchain it fails, as the config is found in arm64, wheres other configs are found in arm.
So know I have a kernel (Image or Image.gz), and some .dts and .dtb files. Now to unpack boot.img, this is where problems occur. When trying to use tools like abootimg or the various different versions of unmkbootimg, they complain about non-standard boot.img.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
or
While also try saving it as a zImage when its meant to be a Image.gz, or they extract it without throwing any errors, but when looking at the extracted files with a hex editor, it is all 00 throughout the files, therefore a useless file.
So their for I tried manually unpacking with a hex editor and managed to get the kernel. Left is my Compiled and Right is the hex version.
Notice the difference in size, is this because the kernel in boot.img is stripped of its debugging items while mine isn't? If so I should look up on how to fix that.
But am having troubles trying to extract the ramdisk via hex.
So is anyone able to either:
a) Help me extract the boot.img properly (with tools like unmkbootimg or with a hex editor)
or
b) do this for me and explain how you achieved it so I myself is am able to do it when needed.
I have attached necessary files if you want to have a look at them yourself.
Any help is appreciated.
FIles(XDA attachments not working): https://drive.google.com/file/d/0B_5mtquWAP3MZjJQay1ERFprbnM/view?usp=sharing

After Numerous trial and error, I finally managed to output ramdisk.cpio.gz.
The start of a Gzip file in hex is, 1F 8B 08, therefor when using the search function in you had editor application you can narrow down your results to 1 or 2 files (2 Files for me as my kernel and ramdisk are both gzipped). You then follow it all the way down till you find a big bunch of zeros(seems like they are passing between files). When you reach the bunch of zeros include the first "00" at the end of the other hexidecial. E.G. End of one of my gzip files is "CE 24 00 00 00....00 (ZERO PADDING BETWEEN FILES), Threaded the end of my file is "CE 24 00".
Knowing this I was able to successfully extract and verify both my kernel and ramdisk files are correct.

Perl script for unpacking
Code:
#!/usr/bin/perl
######################################################################
#
# File : split_bootimg.pl
# Author(s) : William Enck <[email protected]>
# Description : Split appart an Android boot image created
# with mkbootimg. The format can be found in
# android-src/system/core/mkbootimg/bootimg.h
#
# Thanks to alansj on xda-developers.com for
# identifying the format in bootimg.h and
# describing initial instructions for splitting
# the boot.img file.
#
# Last Modified : Tue Dec 2 23:36:25 EST 2008
# By : William Enck <[email protected]>
#
# Copyright (c) 2008 William Enck
#
######################################################################
use strict;
use warnings;
# Turn on print flushing
$|++;
######################################################################
## Global Variables and Constants
my $SCRIPT = __FILE__;
my $IMAGE_FN = undef;
# Constants (from bootimg.h)
use constant BOOT_MAGIC => 'ANDROID!';
use constant BOOT_MAGIC_SIZE => 8;
use constant BOOT_NAME_SIZE => 16;
use constant BOOT_ARGS_SIZE => 512;
# Unsigned integers are 4 bytes
use constant UNSIGNED_SIZE => 4;
# Parsed Values
my $PAGE_SIZE = undef;
my $KERNEL_SIZE = undef;
my $RAMDISK_SIZE = undef;
my $SECOND_SIZE = undef;
my $DT_SIZE = undef;
######################################################################
## Main Code
&parse_cmdline();
&parse_header($IMAGE_FN);
=format (from bootimg.h)
** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
** p = (dt_size + page_size - 1) / page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size != 0)
** 2. second is optional (second_size == 0 -> no second)
** 3. load each element (kernel, ramdisk, second) at
** the specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr. kernel_args[] is
** appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size != 0: jump to second_addr
** else: jump to kernel_addr*/
=cut
my $n = int(($KERNEL_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $m = int(($RAMDISK_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $o = int(($SECOND_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $p = int(($DT_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $k_offset = $PAGE_SIZE;
my $r_offset = $k_offset + ($n * $PAGE_SIZE);
my $s_offset = $r_offset + ($m * $PAGE_SIZE);
my $t_offset = $s_offset + ($o * $PAGE_SIZE);
(my $base = $IMAGE_FN) =~ s/.*\/(.*)$/$1/;
my $k_file = "kernel.gz";
my $r_file = "ramdisk.gz";
my $s_file = "second.gz";
my $t_file = "dt.img";
# The kernel is always there
print "Writing $k_file ...";
&dump_file($IMAGE_FN, $k_file, $k_offset, $KERNEL_SIZE);
print " complete.\n";
# The ramdisk is always there
print "Writing $r_file ...";
&dump_file($IMAGE_FN, $r_file, $r_offset, $RAMDISK_SIZE);
print " complete.\n";
# The Second stage bootloader is optional
unless ($SECOND_SIZE == 0) {
print "Writing $s_file ...";
&dump_file($IMAGE_FN, $s_file, $s_offset, $SECOND_SIZE);
print " complete.\n";
}
# The DT.img stage is optional
unless ($DT_SIZE == 0) {
print "Writing $t_file ...";
&dump_file($IMAGE_FN, $t_file, $t_offset, $DT_SIZE);
print " complete.\n";
}
######################################################################
## Supporting Subroutines
=header_format (from bootimg.h)
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
uint32_t dt_size; /* device tree size in bytes */
uint32_t dt_addr; /* device tree address in bytes */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE];
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
=cut
sub parse_header {
my ($fn) = @_;
my $buf = undef;
open INF, $fn or die "Could not open $fn: $!\n";
binmode INF;
# Read the Magic
read(INF, $buf, BOOT_MAGIC_SIZE);
unless ($buf eq BOOT_MAGIC) {
die "Android Magic not found in $fn. Giving up.\n";
}
# Read kernel size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($k_size, $k_addr) = unpack("VV", $buf);
# Read ramdisk size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($r_size, $r_addr) = unpack("VV", $buf);
# Read second size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($s_size, $s_addr) = unpack("VV", $buf);
# Read dt size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($t_size, $t_addr) = unpack("VV", $buf);
# Ignore tags_addr
read(INF, $buf, UNSIGNED_SIZE);
# get the page size (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE);
my ($p_size) = unpack("V", $buf);
# Read the name (board name)
read(INF, $buf, BOOT_NAME_SIZE);
my $name = $buf;
# Read the command line
read(INF, $buf, BOOT_ARGS_SIZE);
my $cmdline = $buf;
# Ignore the id
read(INF, $buf, UNSIGNED_SIZE * 8);
# Close the file
close INF;
# Print important values
printf "Page size: %d (0x%08x)\n", $p_size, $p_size;
printf "Kernel size: %d (0x%08x)\n", $k_size, $k_size;
printf "Ramdisk size: %d (0x%08x)\n", $r_size, $r_size;
printf "Second size: %d (0x%08x)\n", $s_size, $s_size;
printf "dt size: %d (0x%08x)\n", $t_size, $t_size;
printf "Board name: $name\n";
printf "Command line: $cmdline\n";
# Save the values
$PAGE_SIZE = $p_size;
$KERNEL_SIZE = $k_size;
$RAMDISK_SIZE = $r_size;
$SECOND_SIZE = $s_size;
$DT_SIZE = $t_size;
}
sub dump_file {
my ($infn, $outfn, $offset, $size) = @_;
my $buf = undef;
open INF, $infn or die "Could not open $infn: $!\n";
open OUTF, ">$outfn" or die "Could not open $outfn: $!\n";
binmode INF;
binmode OUTF;
seek(INF, $offset, 0) or die "Could not seek in $infn: $!\n";
read(INF, $buf, $size) or die "Could not read $infn: $!\n";
print OUTF $buf or die "Could not write $outfn: $!\n";
close INF;
close OUTF;
}
######################################################################
## Configuration Subroutines
sub parse_cmdline {
unless ($#ARGV == 0) {
die "Usage: $SCRIPT boot.img\n";
}
$IMAGE_FN = $ARGV[0];
}
The reason why none of tools support our image is because it has different header format. For example mkbootimg:
Code:
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */
but we need for our kernel such a code
Code:
unsigned dt_size; /* device tree size in bytes */
unsigned dt_addr; /* device tree address in bytes */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */

akuhak said:
Perl script for unpacking
The reason why none of tools support our image is because it has different header format. For example mkbootimg:but we need for our kernel such a code
Click to expand...
Click to collapse
Yes @akuhak I had realised that about a week ago (header sizes), also another thing is most of these tools deal with a zImage, where's I boot.img has a hOmage (which is a 64 byte uImage header followed by the kernel. I have succesfully unpacked this boot.img (the kernel, ramdisk and dt.img).
Now if this script works it will be good for other users, but for me my need has already been done.
I am just having trouble trying to get this booting up on my phone when I repack it (I haven't been paying to much attention to this project becuse of exam revision)
Edit: I have tested it and verified thatvit works by comparing the files produced by hand and the files produced by this script via the sha1sum command. I have uploaded it onto my xCover3 post linking back here and giving the credit to you for posting it here. Thanks for your help

It easier to found already existing tool. Our device (I am owning Xcover 3 too) has pxa1088 board. It is known that similar boards has similar structure. So i found these thread github(dot)com/kumajaya/degas-mkbootimg (he has also topic here in xda with his researchs)
It has the same board so these tools works fine for us The only difference I noticed - header unknown value is 0x03000000 for our device and 0x02000000 for Galaxy Tab 4. Maybe something wrong with dtb image - I didn't check these yet.
BTW our phone has same characteristics as Samsung SM-G531F Galaxy Grand Prime (same board, same cpu, same gpu, only screen a bit different) and grandprimevelte has 5.1.1 android onboard and working TWRP recovery (I was trying to flash it but was unsuccessful).
As for same board - For Example Xcover 3 Value Edition has completely different board (exynos3475 with mali-t760mp8 gpu). The same characteristics as for Samsung SM-J200 Galaxy J2. So we can use root methods from j2lte. This means - flash TWRP then install SuperSu zip archive - thats all.
But we cannot use TWRP from VE cause of very different hardwares.
Now Im working on improving degas utilities...

akuhak said:
It easier to found already existing tool. Our device (I am owning Xcover 3 too) has pxa1088 board. It is known that similar boards has similar structure. So i found these thread github(dot)com/kumajaya/degas-mkbootimg (he has also topic here in xda with his researchs)
It has the same board so these tools works fine for us The only difference I noticed - header unknown value is 0x03000000 for our device and 0x02000000 for Galaxy Tab 4. Maybe something wrong with dtb image - I didn't check these yet.
BTW our phone has same characteristics as Samsung SM-G531F Galaxy Grand Prime (same board, same cpu, same gpu, only screen a bit different) and grandprimevelte has 5.1.1 android onboard and working TWRP recovery (I was trying to flash it but was unsuccessful).
As for same board - For Example Xcover 3 Value Edition has completely different board (exynos3475 with mali-t760mp8 gpu). The same characteristics as for Samsung SM-J200 Galaxy J2. So we can use root methods from j2lte. This means - flash TWRP then install SuperSu zip archive - thats all.
But we cannot use TWRP from VE cause of very different hardwares.
Now Im working on improving degas utilities...
Click to expand...
Click to collapse
TWRP for xcover3 value editio came out about 7 says ago, and apparently one user has tried it and is working on their value edition version. (When I had a quick look at the source code yesterdau I happenend to notice it was a exynos board). I had previously tried the dagas scripts and they didn't work for our image at the time, yet your providerd version does. Great idea for searching up the board name (Marvell) as that is one of the only things I hadn't thought to Google.
Feel free to compile TWRP under android 5.1.1 branch. I can/will chime in with relevant info, as well as you can use info from TWRPs source code on the other twrp versions of our device. The only reason I haven't tried it as of yet is becuse i using my my mobile data 99% of the time and just don't have the data to so are downloading source code.
As for the dt.img, I veriefed the scripts output to my on manually extraction and it's the same for both files. (Sha1). But there is a little bit of trailing data (anything past SEANDROIDENFORCING) which is ignored, I am not sure id it's importance as of yet(other then SuperSu omits it from the boot.img when using SuperSu.zip.
Will pop back into here later today.

Ok I completed my tools collection for pxa1088
Source Code: github(dot)com/AKuHAK/pxa1088-mkbootimg
All necessary utilities can be achieved via my modified android_img_repack_tools repo: github(dot)com/AKuHAK/android_img_repack_tool
By just typing ./configure and make
If you are scared by traffic I released tools in one archive: github(dot)com/AKuHAK/android_img_repack_tools/releases/tag/1st.
How to use? I created README in github: github(dot)com/AKuHAK/pxa1088-mkbootimg/blob/master/README
Tools can extract and than pack back boot.img and recovery.img from XCover3. If you didn't extract uImage and dtb.img you can repack boot.img (recovery.img) without hash sum changes. If you extract zImage from uImage and than pack again in uImage your resulting uImage will be different cause uIimage header contain timestamp which will be taken from your PC settings. But resulting uImage still HAVE to be valid.

akuhak said:
Ok I completed my tools collection for pxa1088
Source Code: github(dot)com/AKuHAK/pxa1088-mkbootimg
All necessary utilities can be achieved via my modified android_img_repack_tools repo: github(dot)com/AKuHAK/android_img_repack_tool
By just typing ./configure and make
If you are scared by traffic I released tools in one archive: github(dot)com/AKuHAK/android_img_repack_tools/releases/tag/1st.
How to use? I created README in github: github(dot)com/AKuHAK/pxa1088-mkbootimg/blob/master/README
Tools can extract and than pack back boot.img and recovery.img from XCover3. If you didn't extract uImage and dtb.img you can repack boot.img (recovery.img) without hash sum changes. If you extract zImage from uImage and than pack again in uImage your resulting uImage will be different cause uIimage header contain timestamp which will be taken from your PC settings. But resulting uImage still HAVE to be valid.
Click to expand...
Click to collapse
Cool, will have a look tomorrow, it's hitting 1am for me now. Just one quick correction in the above post of yours. You mention zImage is extracted from the uImage. That is incorrect, is is in fact just a gzipped kernel image (Image.gz) not a zImage.
Yes I know both types of formats are compressed, but our device runs a armv8 cpu which is 64 bits (albeit our kernel is using a 32 but instruction set not a 64 bit instruction set and this means or OS is also 32 bits then). Apon reading the documentation found in the source code, you will realise that it can only handle a) the uncompressed kernel image (Image) or b) a compressed version of the image in gzip format (Image.gz). This is further proven when looking at the boot.img with a hex editor as you can clearly see 2 Files that start with the gzip header format (1F 8B 08) which are the gzipped kernel (also if you go back by 64 bytes then you will be at the start of the uImage header which holds or the appropriate info about the kernel.uImage file) and our ramdisk.
So hopefully you may have just made a mistake in the above post, but if not then you are outputting the incorrect file, which may confuse some users of they don't know much but just wanted to compile the kernel from source.
Sorry about the above rant, will now have a quick look at your github. Thanks for your work you have put into this phone.
Edit: when you mention the android img repack tools, did you use this, http://forum.xda-developers.com/showthread.php?t=2600364 , and if so what modification have you done since I already have the downloaded (used the last of my mobile data last month to get it)
EDIT2: Gonna have a mess around with them tomorrow. One question, sorry for sounding like a noon, but how does the compression differs between normal gzip and minigzip, how will these differences affect a repacked ramdisk and what got you onto that piece of info.
And I had a quick look at your github, seen all your ps2 back related source code.you using FMCB, a hardmod (a chip) or a internal hardrive via an Ethernet adapter. I see sp193, doctorxyz, have commuted to your repo, so sounds like your a ps2 dev, which is cool as ****

1) About zImage. Maybe I need to be more clear: Xcover 3 kernel has uImage onboard with gzip compression. You can extract kernel from that gzipped uImage - I just thought that zImage is name for extracted kernel Sorry if I made mistake in this case.
uImage can be created with use of u-boot tool (denx(dot)de/wiki/U-Boot/WebHome)
For example
Code:
mkimage -I boot.uImage
will provide such an information for our device
Code:
Image Name: pxa1928dkb linux
Created: Wed May 18 15:13:06 2016
Image Type: AArch64 Linux Kernel Image (gzip compressed)
Data Size: 6616640 Bytes = 6461.56 kB = 6.31 MB
Load Address: 01000000
Entry Point: 01000000
This information is extracted from uImage kernel (64 bytes). After header we will see our gzipped kernel - you are right. I just simply extracted it with 7zip from boot.img-uImage.
The difference is that your way didn't use uImage header at all - so you will be unable to pack it back without mistakes - or your gzipped kernel have to be completely the same in size which is almost impossible to achieve. With use of mkimage you can alter kernels (of course only if samsung doesnt check something else) and get correct uImage in output.
2) About difference between minigzip and gzip. In fact I don't know why its happened but I didn't found a reason why ramdisk have to be packed exactly with minigzip. I tried almost all flag combinations with gzip but I get the same result that was in output file only with minigzip
As about kernel it is packed with maximum compression without name with normal gzip.
So assuming minigzip for ramdisk, gzip -n -9 for kernel. But Im completely sure that we can use any combination of gzipers and image still will be valid (but of course will be different in hash). We need to use exactly this combination only if we need to get the same file.
3) Yes Im using exactly this kitchen - I just removed all branches except 5.1.1 added minigzip, my tools and u-boot mkimage tool generation.
4) Yes Im one of still alive ps2 developers I just realized that my phone isn't rooted and started to dig what I can do with it.

akuhak said:
1) About zImage. Maybe I need to be more clear: Xcover 3 kernel has uImage onboard with gzip compression. You can extract kernel from that gzipped uImage - I just thought that zImage is name for extracted kernel Sorry if I made mistake in this case.
uImage can be created with use of u-boot tool (denx(dot)de/wiki/U-Boot/WebHome)
For example will provide such an information for our device
This information is extracted from uImage kernel (64 bytes). After header we will see our gzipped kernel - you are right. I just simply extracted it with 7zip from boot.img-uImage.
The difference is that your way didn't use uImage header at all - so you will be unable to pack it back without mistakes - or your gzipped kernel have to be completely the same in size which is almost impossible to achieve. With use of mkimage you can alter kernels (of course only if samsung doesnt check something else) and get correct uImage in output.
2) About difference between minigzip and gzip. In fact I don't know why its happened but I didn't found a reason why ramdisk have to be packed exactly with minigzip. I tried almost all flag combinations with gzip but I get the same result that was in output file only with minigzip
As about kernel it is packed with maximum compression without name with normal gzip.
So assuming minigzip for ramdisk, gzip -n -9 for kernel. But Im completely sure that we can use any combination of gzipers and image still will be valid (but of course will be different in hash). We need to use exactly this combination only if we need to get the same file.
3) Yes Im using exactly this kitchen - I just removed all branches except 5.1.1 added minigzip, my tools and u-boot mkimage tool generation.
4) Yes Im one of still alive ps2 developers I just realized that my phone isn't rooted and started to dig what I can do with it.
Click to expand...
Click to collapse
1) yes a zImage is one type of you can get when compiling for ARM Devices, you Device is ARM64 so thierare differences. As for extracting the kernel I have always include the 64 byte header (since the middle of last week when I realised that it was there after running binwalk against the file). So yea your assumption was correct up untill a week ago.
2) Interesting. I will be sure to make changes accordingly.
3) cool I have 2 out of four so will download accordingly
4) cool, that the development scene is still going since the ps2 reached it 16 birthday this year.
5) as for root on this device chainfire has needed to go Systemless after/on 6.0 device or 5.1.1. Samsung devices, so to achive root on those devices it requires the modification of boot.img. what his SuperSu.zip does is patch the sepolicy file to allow 3 rules to run in permissive, modify other bits of the ramdisk accordingly to allow for it to run services and mount su.img at boot and it creates and place the necessary files inside su.img. I have completed all that by hand after reading his update-script numerous times. My only roadblock has been try to get the boot.img to boot.I was currently in the process, of try (I have tried alot of different ways including mkbootimg etc.) Manuallying replacing the ramdisk contents with the modified version, and then modify the bootmimg header to continue any modifed value (ramdisk size and dt offset) but am only partially done as I haven't had the chance the last few days to do it.

Awesome tool, unpack, repacked without a single modification and then ran "sha1sum" to both boot.img's and they are exactly the same. You are amazing . I have referenced your tools in this thread (http://forum.xda-developers.com/android/development/4-4-4-5-1-1-6-0-1-samsung-xcover3-t3465132 ) straight to your github. Now to try my modified ramdisk and see If my phone can boot it. Will post results soon.
======
Yes I can boot custom boot.img, without the SEANDORIDENFORCEING showing up. I can see my ramdisk changes, work, I can type adb root and I don't get the product in build message, but trying to do anything that requires root e.g. trying to push su.img to /data or /cache, gets me the error permission denied, but hey I am half way there to getting root.

[TOOL] imjtool - Unpack and extract a variety of OTA images from various vendors

Hello All,
My Imjtool is now at version 1.6 , supporting MediaTek images, improving QCom FBPK (SD845 and onwards ".img"), DTBO (Device tree blob overlay) slicing, super.img (liblp logical partitions) and block based update images (system.transfer.list and ..new.dat) even when compressed with Brotli (.br) compression.
By now, there's support for quite a few formats, including proprietary QCOM FBPK, Huawei UPDATE.APP, and even UEFI containers:
Code:
/**
*
* Rudimentary Android image and partition unpacking tool
*
* v0.1 - Support unpacking of BootLoader and Boot images, as well as imgdata
* v0.2 - Supports offset= (for HTC and other boot.imgs where ANDROID! is wrapped)
* Supports cmdline= (to override kernel command line)
*
* v0.3 - Integrated mkbootimg functionality, added dt_size and id
*
* v0.4 - cmdline, addrs..
*
* v0.4.1 - Fix for Edvard Holst on Essential PH1 images.. (who uses Essential nowadays, I wonder?)
*
* v0.5 - Update with LZ4 binaries, fix for extract devicetree even if can't uncompress kernel
*
* v0.6 - Samsung images (with DT > 0) - Device Tree now found whereever it may hide
*
* v0.7 - system.transfer.list support
*
* v0.8 - FBPK (SD845 CrossHatch (Pixel 3 XL) bootloader images) AND Huawei Mate
* Also compiles cleanly
*
* v0.85 - system.transfer.list support for v4 (MTK 64 bit)
*
* v1.0 - EFI. Worthy enough a feature that (after three years) I hit version 1 on it, and - JCOLOR
*
* v1.1 - Samsung baseband images ("TOC") - 03/04/2020
*
* v1.2 - DTBO, super.img (03/20/2020) and integrated Brötli
*
* v1.2.1 - Lots of QCOM EFI GUIDs added. Thanks to anonymous contributor!
*
* v1.3 - Can now also pack super.img and boot.img based on existing!
*
* v1.4 - uBoot uimage format
*
* v1.5 - MTK images!
*
* v1.5.1 - Fixes: QCOM FPBK fixed (accidentally removed during refactoring around 1.3.. oops)
* UEFI now unpacks files by UI, if presenr, rather than GUID
*
* 1.6 - Peek into images to detect payload format
*
*
* platform-innovation-framework-for-uefi-complete-specifications-v0.90-v0.97 from Intel
* was invaluable for figuring out EFI
*
*
* This tool is part of the free downloads for the book
* "Android Internals: A Confectioner's Cookbook"
* But (as of v1.0) is also quite useful or MacOS T2 firmwares
*
* Author: Jonathan Levin, http://NewAndroidBook.com
*
* (New edition of Book and the loooong overdue Vol II coming soon! Check /TOC.html on site!)
*
* License: Use freely, BUT give credit where due. This way people learn of the website and books.
*
* If you have suggestions for improvement/new image types/etc - let me know and I'll gladly
* add them in.
**/
Totally free to use, feedback or requests appreciated.
Link: NewAndroidBook.com/tools/imjtool.html

Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images are stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?

err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Typhus_ said:
Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images ares stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?
Click to expand...
Click to collapse

morpheus______ said:
err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Click to expand...
Click to collapse
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.

Just making sure there - better safe than sorry, as, even with "critical partitions" unlocked, I can't vouch for your boot sequence not rejecting this - whether the ELF is valid or corrupt won't be the main risk - what will be is that the bootROM (or UEFI runtime) might reject this xbl as it won't be validly signed.
Still, it's an interesting challenge. I can get on it. I'll update, and you can always get me over DM.
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Typhus_ said:
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.
Click to expand...
Click to collapse

morpheus______ said:
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Click to expand...
Click to collapse
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.

There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Typhus_ said:
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" it will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.
Click to expand...
Click to collapse

morpheus______ said:
There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Click to expand...
Click to collapse
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.

yep.
NewAndroidBook.com/tools/imjtool.tgz is direct link.
Patching ELF might take me a while
J
Typhus_ said:
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.
Click to expand...
Click to collapse

How to repack super.img
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...

bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse
Update: I've found my answer: https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70

That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse

This is very helpful. Many thanks!
Chaser

Yeah great stuff... just used imjtool to extract abl.img and hunt for hidden fastboot commands.
This is an awesome tool!!!
Thanks a lot and best regards,
scholbert

morpheus______ said:
That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
Click to expand...
Click to collapse
Thank you for this tool!! I could also definitely use the ability to do this ^^^ with imjtool.

Unpacking/Repacking for Samsung S9
Hey, nice work, thank you!
I pulled the working boot.img from a Samsung Galaxy S9. I am just trying to unpack it, repack it and flash it back, and see it working (as a test, if that works I'll move to replace the kernel).
Your tool also extracts the DTB, which is great, abootimg didn't do that. However, when I repack like
Code:
imjtool.x86_64 make boot-repacked.img extracted/kernel extracted/ramdisk extracted/kernelimage extracted/devicetree.dtb
the result is only 38M large, the original is 55M, which seems already fishy. When I flash it anyway (using heimdall if it matters), it results in a bootloop.
So my questions are:
Am I using your tool wrong? Is the Samsung S9 not supported? Or is it a bug?
Another thing that puzzles me:
imjtool unpacks
Code:
devicetree.dtb kernel kernelimage ramdisk
abootimg unpacks
Code:
bootimg.cfg initrd.img zImage
So I know abootimg apparently misses the DTB (and "kernelimage" which is the .config used when the kernel was built) - But is your tool missing the info in bootimg.cfg (e.g. kernel command line?)
Thanks for your work/help!
This is what imjtool printed when extracting, in case it matters:
Code:
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 13352456
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
57.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x2534800
Found DT Magic @800

Hi Arcepth,
Odd; I have an S9 myself, and re-creating the image worked for me way back when I tried it. Could you do me a favor and send your boot.img? DM is fine.
The kernel command line should be taken from the boot.img, (the .cfg file abootimg generates is artificial). You can specify cmdline= to imjtool and it will embed that cmdline.
Samsung's odd with their device tree. They put it as the secondary, whereas others just fuse it to the kernel.
Any deviation from what Samsung expects will boot loop. I know this the very hard way
Anyway, DM me.

Using imjtool on S20 boot.img
I am having the same issue with Galaxy S20's "boot.img".
The original is ~60MB but after repack is ~38MB
-----------------------------Log---------------------------
root:/home/tools/imjtool# ./imjtool.x86_64 boot.img extract
Boot image detected
Part Size Pages Addr
Kernel: 37801996 18459 0x10008000
Ramdisk: 889691 435 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 2 bytes
ID: ##################################
Name: S##########
CmdLine: androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 16951272
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
62.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x24e7800
Unable to locate device tree
-----------------------------------End Log---------------------------------
My command for repack:
roothome:/home/tools/imjtool# ./imjtool.x86_64 make boot2.img extracted/kernel extracted/ramdisk extracted/kernelimage [cmdline='androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive'] [addr=0x10008000]
I didn't try to flash this though.

Thank you for the feedback! The tool is built around my use cases, but I don't get to experience all the crazy variants in image formats out there..
Anyway - I got this one: It took a bit to figure out but Samsung shoves a LOT of stuff after the DT which isn't part of the boot.img specification, as well as stuff which now is (AVB0) but I wasn't aware of when I started imjtool. So - I'm updating imjtool to handle this. I can already reliably detect and extract all their extras:
Code:
[email protected]öst (~/Documents/Android/src/Imjtool) %./imjtool ~/Downloads/boot.original.img
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
Found Samsung DTBH @0x2534800 with 6 trees
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x10-0x10
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x11-0x11
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x12-0x13
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x14-0x16
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x17-0x19
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x1a-0xff
DTBH block ends @0x26e9000
Warning: DT ends 0x26e9000, but filesize is 0x3700000 - looking further
Found [email protected]
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
And I'm working on finalizing a "repack" command which will use the base boot.img you provide and just enable the select overriding of portions or values.
Please try this build: http:// NewAndroidBook.com /tools /imjtoolbeta.tgz
You can use repack (base.img) and then change a variety of parameters. New image will be repacked.img in same dir.

Repacked size looks better now
Tried the beta and it looks much better! The "repacked.img" is much closer to the original size (I tried with a kernel built from official source code).
Only issue left is that ODIN fails to flash my created "boot.img.tar" file to the S20.
Just see a generic "RQT_CLOSE" message on ODIN.
Any clue what I'm missing? (already LZ4 compressed, tarballed with various methods, even disabled AVB)

Question Rooting Galaxy Watch4

I've unlocked bootloader, got boot.img(hashes match in update.zip and my boot.img + it boots fine), patched it and vbmeta in tar by magisk 24.3, but when i flash new boot.img, it throws me "SECURE FAILED: BOOT" error on watch and system doesn't boot, flashing unpatched boot.img gets watch to work again. Why does it happen and is there any fix? SM-R860
Files:
files.zip
drive.google.com

Sounds like Samsung baked in something to keep it from being rooted

I wrote Conversation aka PM to you...
Best Regards

sermister1 said:
I've unlocked bootloader, got boot.img(hashes match in update.zip and my boot.img + it boots fine), patched it and vbmeta in tar by magisk 24.3, but when i flash new boot.img, it throws me "SECURE FAILED: BOOT" error on watch and system doesn't boot, flashing unpatched boot.img gets watch to work again. Why does it happen and is there any fix? SM-R860
Files:
files.zip
drive.google.com
Click to expand...
Click to collapse
Magisk patch is not enough to achieve root. You need to flash the stock boot image in order to fix that.

janjan said:
Magisk patch is not enough to achieve root. You need to flash the stock boot image in order to fix that.
Click to expand...
Click to collapse
My sm-r860 boots fine only with stock boot.img, how can i get magisk to work?

Wrong posting...

Example of vbmeta from Combination Firmware...
SM-G991B Android 11
Code:
COMBINATION_FAC_FAR0_G991BXXU1AUA3_FAC_CL20796681_QB37484630_REV01_user_mid_noship_MULTI_CERT.tar.md5
Summary for my tiny brain...
A
Magisk patch vbmeta.img only 1 Byte at Offset 0x7B
00 into 03
B
In attached "Combi Example" vbmeta have more Bytes changed in Header... and Offset 0x7B is:
01
C
Some Google search findings...
What is 02 in the magisk patched vbmeta.img?
According to the Additional Info given for rooting the Android device that doesn't have ramdisk but can be rooted via recovery: we need an empty vbmeta.img and I am trying to check what it actually
android.stackexchange.com
XDA search...
[TOOL][WIN,LIN,AND,DARW] Super image tools | extract or make partitions RW in super partition
Disclaimer: Super image tools was made for testing and educational purposes, ME is not responsible for what you do on/with your device using our tools, you must agree that you using our tools on your own risk, I am not responsible for anything...
forum.xda-developers.com

Dear janjan
Please share full info/instruction for Rooting GW4 via USB.
Thanx in advance.
Best Regards

adfree said:
Dear janjan
Please share full info/instruction for Rooting GW4 via USB.
Thanx in advance.
Best Regards
Click to expand...
Click to collapse
@janjan hopefully he'll get this sent alert!

adfree said:
Dear janjan
Please share full info/instruction for Rooting GW4 via USB.
Thanx in advance.
Best Regards
Click to expand...
Click to collapse
Dear adfree,
I am still working on it. I don't own the USB myself to share any knowledge about that. But I will ofc share my work whenever I have time. I just build a kernel and I will ofc share when I finish uploading the source to GitHub. Thank you for understanding.

galaxys said:
@janjan hopefully he'll get this sent alert!
Click to expand...
Click to collapse
I will ofc share my work when I finish uploading the source to the GitHub. Work in progress. The goal is to achieve root through Netodin and as you already know it is not a easy task. It takes time. Thank you for understanding

sermister1 said:
My sm-r860 boots fine only with stock boot.img, how can i get magisk to work?
Click to expand...
Click to collapse
I tired different magisk to patch the stock boot.img but it doesn't work.
I will compile a kernel for your device. I am still waiting for Samsung to share latest source. Seems the old source doesn't work with D4 unfortunately.

janjan said:
I tired different magisk to patch the stock boot.img but it doesn't work.
I will compile a kernel for your device. I am still waiting for Samsung to share latest source. Seems the old source doesn't work with D4 unfortunately.
Click to expand...
Click to collapse
if you're talking about evd4, currently i have fvc8 rom
And can't use usb bcs i don't have triple screwdriver.

Caution! Warning!
Own Risk!
SM-R860 FVC8 Kernel
For study...
Idea is to improve our Log files...
RDX Tool is confirmed working with GW4 connected with USB cable:
Upload Mode
There are several modes that Wave bootloader supports for certain purposes. The normal mode and low power mode just start the Nucleus kernel. I'm also pretty sure everybody knows what a DOWNLOAD MODE is (one with the red letters, but if initiated...
forum.xda-developers.com
Files are based on first post...
And idea about Values came to me after this:
Rooting Galaxy Watch4
I've unlocked bootloader, got boot.img(hashes match in update.zip and my boot.img + it boots fine), patched it and vbmeta in tar by magisk 24.3, but when i flash new boot.img, it throws me "SECURE FAILED: BOOT" error on watch and system doesn't...
forum.xda-developers.com
Tasks...
A
Create TAR files for netOdin/Odin...
I have simplified to see difference in files...
boot.img not changed... it is the Magisk patched FVC8 from first post...
B
Now IMHO 3 times flashing with Odin (we will start with USB, so we can use RDX Tool)
Round 1
Flashing
1_magisk_patched-24300_oLqH6
Then RDX dump for Log
Round 2
2_vbmeta_01
Then RDX dump for Log
Round 3
3_vbmeta_02
Then RDX dump for Log
With these 3 Logs and from Original Stock Booting... so 4 RDX Dumps...
IMHO maybe visible where exactly it fails...
Best Regards
edit 1.
Additional Control Step to be sure Knox is still alive... or dead...
Code:
D:\Android\ADB>adb shell getprop ro.boot.warranty_bit
0

Here are the RDX Screenshots... taken few weeks ago... SM-R860 FVC8...
RDX shows something like:
Code:
summary.html
auto_comment
extra_info
debug_history
boot_reset
acpm_dump
header
kernel
platform
kevents
s2d
arrdumpreset
arrdumppanic
MFC-log-mem
MFC-sfr-dmp0
LPD-log-mem
LPD-srm-dmp
SM-R860 connected via USB cable and RDX Tool 6.1.4
Upload Mode
There are several modes that Wave bootloader supports for certain purposes. The normal mode and low power mode just start the Nucleus kernel. I'm also pretty sure everybody knows what a DOWNLOAD MODE is (one with the red letters, but if initiated...
forum.xda-developers.com
Best Regards

Code:
[0: 4.451206 ] Footer.magic : AVBf
[0: 4.451210 ] Footer.version : 1.0
[0: 4.451214 ] Footer.original_image_size : 0x2f6330
[0: 4.451217 ] Footer.vbmeta_offset : 0x2f7000
[0: 4.451220 ] Footer.vbmeta_size : 0x840
[0: 4.451223 ] get_original_image_size: Found Footer Info for BOTA, original size: 0x2f6330
[0: 4.451228 ] Verify_Signature_Ecdsa 0xa3e80074 3105584, 0xa4176194 512
[0: 4.473469 ] check_signature (BOOTLOADER) valid.
[0: 4.483628 ] Check DRAM STORE training data..
[0: 4.483632 ] ACPM magic code: 0xAC8338A9
[0: 4.483636 ] Write magic code: 0xF67038A9
[0: 4.547556 ] Restore DRAM training data..
[0: 4.558104 ] _sbl_bota_update: BOOTLOADER Update Completed.
[0: 4.558111 ] _sbl_bota_update: tzar.img(6292240) -> TZAR(9) Update Start.
[0: 4.558122 ] avb_footer.c:41: ERROR: Footer magic is incorrect.
security_core.c:1358: ERROR: BOTA: Error validating footer.
BOTA : Error validating footer.
[0: 4.558138 ] Verify_Signature_Ecdsa 0xa4280098 6292240, 0xa4880198 512
[0: 4.588086 ] check_signature (TZAR) valid.
[0: 4.760372 ] _sbl_bota_update: TZAR Update Completed.
[0: 4.760379 ] _sbl_bota_update: tzsw.img(1572864) -> TZSW(8) Update Start.
[0: 4.760396 ] Footer.magic : AVBf
[0: 4.760400 ] Footer.version : 1.0
[0: 4.760403 ] Footer.original_image_size : 0x100310
[0: 4.760407 ] Footer.vbmeta_offset : 0x101000
[0: 4.760410 ] Footer.vbmeta_size : 0x840
[0: 4.760413 ] get_original_image_size: Found Footer Info for BOTA, original size: 0x100310
[0: 4.760418 ] Verify_Signature_Ecdsa 0xa48803cc 1049360, 0xa49804cc 512
[0: 4.777709 ] check_signature (TZSW) valid.
[0: 4.823222 ] _sbl_bota_update: TZSW Update Completed.
[0: 4.823231 ] _sbl_bota_update: uh.bin(276120) -> UH(15) Update Start.
[0: 4.846012 ] _sbl_bota_update: UH Update Completed.
[0: 4.846020 ] _sbl_bota_update: up_param.bin(706560) -> UP_PARAM(13) Update Start.
[0: 4.871416 ] _sbl_bota_update: UP_PARAM Update Completed.
[0: 4.871425 ] _sbl_bota_update: vbmeta.img(9744) -> VBMETA(23) Update Start.
[0: 4.871435 ] avb_footer.c:41: ERROR: Footer magic is incorrect.
security_core.c:1358: ERROR: BOTA: Error validating footer.
BOTA : Error validating footer.
[0: 4.871451 ] Verify_Signature_Ecdsa 0xa4af02d0 9744, 0xa4af26d0 512
[0: 4.886209 ] check_signature (VBMETA) valid.
[0: 4.899964 ] _sbl_bota_update: VBMETA Update Completed.
[0: 4.932208 ] s2mpw03_get_vbat: vBAT=4183mV
[0: 4.932309 ] s2mpw03_get_soc: capacity (0xec0:9218)
[0: 4.959070 ] sys_restart ('N':fota_up)
[0: 4.959074 ]
[0: 4.959077 ] [SECD] clear_debug_flags: Clear DINFOM and RAMBASE
[0: 4.959082 ] set_minform_magic: before: 4e4e0000 (type: 1, magic: 4e)
[0: 4.959090 ] set_minform_magic: after: 4e4e0000
[0: 4.959095 ] set_minform_magic: before: 4e4e0000 (type: 3, magic: 0)
[0: 4.959102 ] set_minform_magic: after: 4e4e0000
[0: 4.959107 ] set_minform_magic: before: 4e4e0000 (type: 2, magic: 0)
[0: 4.959114 ] set_minform_magic: after: 4e4e0000
[0: 4.959119 ] display_drv_clear was called
[0: 4.959123 ] panel_exit +
[0: 5.079213 ] dsim_set_panel_power off +
[0: 5.091298 ] MMC0 PON set in mmc_power_off_notification
[000.000000] NOTICE: EPBL Self Decryption success
[000.046719] NOTICE: SecureBoot: [BL2] Check digital signature and RP count success
I am looking through my old Debug Logs...
Search text string:
vbmeta.img
According to filename something taken in EVB4... dumpState...log

I am unsure if fail is because vbmeta.img is invalid... maybe patched boot.img is the problem...
Maybe also procedure is incorrect or incomplete...
According to fastboot hints... unlock not at same time with boot.img...
Example what I mean
Installation
The Magic Mask for Android
topjohnwu.github.io
(Optional) If your device has a separate vbmeta partition, you can patch the vbmeta partition with command:
fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img
Click to expand...
Click to collapse
And info fastboot not working...
??
This means the unlock Command not work?
Or all known Fastboot Commands not work?
Will try to find easy test...
Code:
D:\Android\ADB>fastboot
fastboot: usage: no command
D:\Android\ADB>fastboot -help
usage: fastboot [OPTION...] COMMAND...
flashing:
update ZIP Flash all partitions from an update.zip package.
flashall Flash all partitions from $ANDROID_PRODUCT_OUT.
On A/B devices, flashed slot is set as active.
Secondary images may be flashed to inactive slot.
flash PARTITION [FILENAME] Flash given partition, using the image from
$ANDROID_PRODUCT_OUT if no filename is given.
basics:
devices [-l] List devices in bootloader (-l: with device paths).
getvar NAME Display given bootloader variable.
reboot [bootloader] Reboot device.
locking/unlocking:
flashing lock|unlock Lock/unlock partitions for flashing
flashing lock_critical|unlock_critical
Lock/unlock 'critical' bootloader partitions.
flashing get_unlock_ability
Check whether unlocking is allowed (1) or not(0).
advanced:
erase PARTITION Erase a flash partition.
format[:FS_TYPE[:SIZE]] PARTITION
Format a flash partition.
set_active SLOT Set the active slot.
oem [COMMAND...] Execute OEM-specific command.
gsi wipe|disable Wipe or disable a GSI installation (fastbootd only).
wipe-super [SUPER_EMPTY] Wipe the super partition. This will reset it to
contain an empty set of default dynamic partitions.
boot image:
boot KERNEL [RAMDISK [SECOND]]
Download and boot kernel from RAM.
flash:raw PARTITION KERNEL [RAMDISK [SECOND]]
Create boot image and flash it.
--dtb DTB Specify path to DTB for boot image header version 2.
--cmdline CMDLINE Override kernel command line.
--base ADDRESS Set kernel base address (default: 0x10000000).
--kernel-offset Set kernel offset (default: 0x00008000).
--ramdisk-offset Set ramdisk offset (default: 0x01000000).
--tags-offset Set tags offset (default: 0x00000100).
--dtb-offset Set dtb offset (default: 0x01100000).
--page-size BYTES Set flash page size (default: 2048).
--header-version VERSION Set boot image header version.
--os-version MAJOR[.MINOR[.PATCH]]
Set boot image OS version (default: 0.0.0).
--os-patch-level YYYY-MM-DD
Set boot image OS security patch level.
Android Things:
stage IN_FILE Sends given file to stage for the next command.
get_staged OUT_FILE Writes data staged by the last command to a file.
options:
-w Wipe userdata.
-s SERIAL Specify a USB device.
-s tcp|udp:HOST[:PORT] Specify a network device.
-S SIZE[K|M|G] Break into sparse files no larger than SIZE.
--force Force a flash operation that may be unsafe.
--slot SLOT Use SLOT; 'all' for both slots, 'other' for
non-current slot (default: current active slot).
--set-active[=SLOT] Sets the active slot before rebooting.
--skip-secondary Don't flash secondary slots in flashall/update.
--skip-reboot Don't reboot device after flashing.
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.
--unbuffered Don't buffer input or output.
--verbose, -v Verbose output.
--version Display version.
--help, -h Show this message.
Edit 1.
IMHO easiest Fastboot command to check if Fastboot is working...
Code:
fastboot devices

Tiny heartattack after stupid test in FVD4:
Code:
D:\Android\ADB>adb shell
freshbs:/ $ reboot fastboot
Leads to black screen...
I remember in older Firmwares red text fastboot...
Few attempts to leave failed...
Hold both keys for few seconds make Reboot Menu accessable...
But no Kernel boots... only black screen... both in normal and Recovery...
I was able to leave the black screen massaker by entering Download Mode USB... and here I pressed both Keys few seconds...
Then normal Booting possible.
I will search the old fastboot info... IMHO Picture postet or something like this...
Best Regards
Edit 1.
fastboot visble in Recovery Mode...
Firmware and Combination Firmware and FOTA Delta and CSC change and...
Looks like it could be harder since Tizen... A Stock Firmware for netOdin/Odin not available yet... B Combination Firmware not available yet C FOTA Delta File for study I have...
forum.xda-developers.com
Edit 2.
Oh, found my old attempt:
Firmware and Combination Firmware and FOTA Delta and CSC change and...
Looks like it could be harder since Tizen... A Stock Firmware for netOdin/Odin not available yet... B Combination Firmware not available yet C FOTA Delta File for study I have...
forum.xda-developers.com
Here I tried:
reboot bootloader
Ah okay. Tested now on FVD4 and i see in tiny red text:
Fastboot Mode..
If I hold both keys for seconds... can normal boot again.

Short summary about Upload Mode for RDX Tool aka Ramdump aka Kernel Panic...
A
This is Samsung only stuff since yearS...
B
For GW4 it looks like this on Watch... See Photo left:
Firmware and Combination Firmware and FOTA Delta and CSC change and...
Looks like it could be harder since Tizen... A Stock Firmware for netOdin/Odin not available yet... B Combination Firmware not available yet C FOTA Delta File for study I have...
forum.xda-developers.com
We see UPLOAD MODE in red
C
At the moment I know only this way to make it visible on FVD4... FVC8 Firmware...
For USB connection
Firmware and Combination Firmware and FOTA Delta and CSC change and...
Looks like it could be harder since Tizen... A Stock Firmware for netOdin/Odin not available yet... B Combination Firmware not available yet C FOTA Delta File for study I have...
forum.xda-developers.com
Firmware and Combination Firmware and FOTA Delta and CSC change and...
Looks like it could be harder since Tizen... A Stock Firmware for netOdin/Odin not available yet... B Combination Firmware not available yet C FOTA Delta File for study I have...
forum.xda-developers.com
Only as info...
Best Regards

Preparing to compare what Magisk did to FVC8 Kernel...
First Step with imjtool...
Code:
[email protected]:~/imj$ ./imjtool stock.img extract
Boot image version 2 for OS version 0x16000163 (11.128 Patch Level 2022-3) detected (1660 byte header)
Part Size Pages Addr
Kernel (@0x0000800): 25194512 12303 0x10008000
Ramdisk (@0x1808000): 743485 364 0x10000000
Device Tree(@0x18be000): 110416 54 0x10000000
MAGIC: 0x1eabb7d7
Extracting dtbo
Found [email protected]
AVB0 (@0x18da000): 2112
AVBf (@0x23fffc0):
Tags: 0x10000000
Flash Page Size: 2048 bytes
ID: c769e71ef5bec23438102c4a3af78e13dcd7d587000
Name: SRPUC03B001
CmdLine:
Found GZ Magic at offset 14333096
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
-81.8% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x18be000
MAGIC: 0x1eabb7d7
Extracting dtbo - exists so renaming to _dtbo
[email protected]:~/imj$ ./imjtool patch.img extract
Boot image version 2 for OS version 0x16000163 (11.128 Patch Level 2022-3) detected (1660 byte header)
Part Size Pages Addr
Kernel (@0x0000800): 25194512 12303 0x10008000
Ramdisk (@0x1808000): 1252029 612 0x10000000
Device Tree(@0x193a000): 110416 54 0x10000000
MAGIC: 0x1eabb7d7
Extracting dtbo
Found [email protected]
AVB0 (@0x1956000): 2112
AVBf (@0x23fffc0):
Tags: 0x10000000
Flash Page Size: 2048 bytes
ID: 5477904380525186fa9fdb5eaf7863be8e37af2d000
Name: SRPUC03B001
CmdLine:
Found GZ Magic at offset 14333096
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
-81.8% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x193a000
MAGIC: 0x1eabb7d7
Extracting dtbo - exists so renaming to _dtbo