Related
Hi,
After downloading the official image with android-1.5 (also known as
signed-dream_devphone_userdebug-img-150275.zip) for adp1 from the link
(http://www.htc.com/www/support/android/adp.html#s3) provided by HTC
and unzipping the image into someplace you want in the terminal, and
then four files with the same extension of .img will be got, as shown
below.
boot.img
recovery.img
system.img
userdata.img
Here's a discussion mainly focused on how to extract these contents of
the last two images for adp1 on host.
With respect to how to extract these contents of the first two images
for adp1 on host, please refer to the following link. Meanwhile,
thanks for the community efforts as well!!
http://forum.xda-developers.com/showthread.php?t=443994
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_....
1> system.img
==> the unyaffs2 tool is used to extract the contents from system.img
on host.
For the tool, you can access its source code with the license of GPLv3
located at the link (http://code.google.com/p/unyaffs/) and download
the source code and its binary.
2> userdata.img
While using the aforementioned tool extracting these contents of
userdata.img, the contents fail to be got on host and just a message
of "end of image" is shown up in the terminal, as follows.
$ chmod a+x unyaffs
$ unyaffs userdata.img
end of image
So, the problem to be asked is about how to extract contents of
userdata.img for adp1 on host!!
Any input will be greatly appreciated!!
for the official rom, userdata should be empty isn't it?
You could flash userdata and then boot into recovery, mount data, and adb pull /data.
I'm also interested in extracting boot and recovery images, so any hints please post here
First off, thanks for your reply, billc.
As regards the issuse that if the image of userdata.img is empty, the two methods are taken, as follows. (so sorry that the below is too long. )
1. checking that with bash command in the terminal
$ ls -lh
total 57M
-rw-r--r-- 1 samuel samuel 1.6M 2009-01-01 00:00 boot.img
-rw-r--r-- 1 samuel samuel 1.8M 2009-01-01 00:00 recovery.img
-rw-r--r-- 1 samuel samuel 54M 2009-01-01 00:00 system.img
-rw------- 1 samuel samuel 2.1K 2009-07-02 08:23 userdata.img
With the first scenario, the size of "userdata.img" is shown as "2.1K", which seems to indicate that the image of "userdata.img" isn't empty, instead of with the size.
2. checing that with programs (unyaffs.c[1]/unyaff.h[2]) for the tool of "unyaffs"
[1]http://unyaffs.googlecode.com/files/unyaffs.c
[2]http://unyaffs.googlecode.com/files/unyaffs.h
(NOTE: the instruction of complicatioin is "gcc -o unyaffs unyaffs.c" with the version 4.2.4 of gcc)
After compiling, the executable tool is got in your directory, also known as "unyaffs". And then, type the instruction with the terminal below.
$ unyaffs userdata.img
end of image
Unfortunately, there is nothing out there after extracting contents of "userdata.img" with the size of "2.1K"(-the length really includes what contents?). Only a message of "end of image" is shown up with the terminal.
To get more information about the message of "end of image, therefore, diving into the C file used to generate the tool of "unyaffs", getting the following connents. Meanwhile, please also pay more attention to the lines with the bold.
int read_chunk()
{
ssize_t s;
int ret = -1;
memset(chunk_data, 0xff, sizeof(chunk_data));
s = read(img_file, data, CHUNK_SIZE + SPARE_SIZE);
if (s == -1) {
perror("read image file\n");
} else if (s == 0) {
printf("end of image\n");
} else if ((s == (CHUNK_SIZE + SPARE_SIZE))) {
ret = 0;
} else {
fprintf(stderr, "broken image file\n");
}
return ret;
}
And then, indexing the function in the Linux Programmer's Mannual with the command of "man read" in the terminal to get more info, as shown below. In the meantime, please pay more attention to the lines with the bold as well.
$man read
...
...
NAME
read - read from a file descriptor
SYNOPSIS
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
DESCRIPTION
read() attempts to read up to count bytes from file descriptor fd into
the buffer starting at buf.
If count is zero, read() returns zero and has no other results. If
count is greater than SSIZE_MAX, the result is unspecified.
RETURN VALUE
On success, the number of bytes read is returned (zero indicates end of
file), and the file position is advanced by this number.
...
...
Just judging from the combination of the snippet of "unyaffs.c" and the mannual of "read" above, the conclusion below can be come to.
The real contents of "userdata.img" with the size of "2.1k" is exactly empty ending up with "end of file".
When compared the two conclusions as mentioned above, it's found that the both are just contrary, the former ISN'T empty while the latter IS empty.
So, there are a set of problems about the above confusion herein.
Q1: What contents exactly does the "userdata.img" with the size of "2.1k" mean?
Q2: What contents and from which position does the function of "read" read in the file? In the case of "userdata.img", what are"what contents" and "from which position" respectively?
Q3: According to the above two scenarios, what steps to take are to judge if the file is really empty?
Looking forward to your replies, thanks!!
to jubeh,
As to extracting the images of boot and recovery from adp1/g1, you can refer to the following links. hope that that's helpful.
http://forum.xda-developers.com/showthread.php?t=443994
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
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
MKBOOTIMG-TOOLS
MY GITHUB SOURCE:
https://github.com/ModdingMyMind/mkbootimg_tools
Original Author: xiaolu (GITHUB SOURCE: https://github.com/xiaolu/mkbootimg_tools)
Heavily Modified By: Modding.MyMind
This project is originally based from xiaolu. To make this compatible for ARM I modified the script, compiled some binaries such as file, bash, grep, gzip, lzma, xz, mkbootimg, etc.
-- This project uses busybox but due to how stripped and limited busybox is it ultimately led to me having to compile a few binaries from source. These binaries must be part of the project in order for the project to be successful. For example, busybox grep will not always give accurate offsets for the android header. One of MANY bugs found with busybox.
This project supports device tree binaries found inside the Boot.img and Recovery.img.
This project supports multiple Ramdisk compressions.
-- This project will check the ramdisk compression and if it determines that the tool does not support that particular compression then it will display a hazard warning letting the user know that the compression is not supported and that the ramdisk currently cannot be decompressed or compressed until support has been officially added.
-- If the compression is supported it will display what type of compression the Ramdisk is and how many blocks it has when unpacked.
This project will determine your kernel size, ramdisk size, and TRUE OFFSETS (not just the standard mkbootimg.c offsets).
-- With respect to the offsets; You will learn that many available tools found available specifically handle images where the ANDROID! header is located at 0x0. Not all images are built like this from stock. This project will find the header, base, kernel offset, ramdisk offset, second offset, and tags offset. It will rebuild the image using DD to insure the android header is located at 0x0. The found offsets inside the image will be cross referenced to see if the OEM of that image built it using the standard mkbootimg.c. If it detects any offsets which are built using NON-standard offsets then it will display a warning as well as show you what the image TRUE offsets actually are. Those same offsets are then applied to properly rebuild your image to insure that it boots like it was intended to do.
-- The warning will let you know that you may modify mkbootimg.c with the NON-standard values if you wish to have a binary specific to your device. The offsets displayed are not the address. Because the offsets are determined and not the address this makes it possible for this project to not have to rebuild mkbootimg.c. When the project is used to rebuild your image using the mkbootimg args such as --ramdisk_offset, --kernel_offsets, etc, etc, this then tells mkbootimg.c to ignore the hardcoded offsets and only use the ones it has been instructed to use. This is even more successful by insuring the BASE is accurate and applying the base as one of the mkbootimg args (--base 0 <-- this is lazy and stupid).
The mkboot script requires two args whether unpacking the image or repacking the image.
-- mkboot boot.img bootfolder (This will unpack the image)
1. mkboot is the script.
2. boot.img is the actual image.
3. bootfolder will be created and become the project folder.
-- mkboot bootfolder newboot.img (This will repack the image)
1. mkboot is the script.
2. bootfolder is the project folder which has the needed files and information to repack.
3. This will be the name of the finished build.
UNPACK STANDARD IMAGE
This image uses standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot.img work
Unpack & decompress boot.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 2529072
ramdisk size : 230255
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Ramdisk is lzma format.
1436 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK STANDARD IMAGE
Image repacked with standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.lzma
page size : 2048
kernel size : 2529072
ramdisk size : 230029
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Kernel size: 2529072, new ramdisk size: 230029, boot.img: 2762752.
boot.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK NON-STANDARD IMAGE
This image uses non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot recovery.img work
Unpack & decompress recovery.img to work
****** WARNING ******* WARNING ******* WARNING ******
This image is built using NON-standard mkbootimg!
RAMDISK_OFFSET is 0x01608000
You can modify mkbootimg.c with the above value(s)
****** WARNING ******* WARNING ******* WARNING ******
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 5834192
ramdisk size : 4351685
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Ramdisk is gzip format.
14837 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK NON-STANDARD IMAGE
Image repacked with non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work recovery.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.gzip
page size : 2048
kernel size : 5834192
ramdisk size : 4358038
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Kernel size: 5834192, new ramdisk size: 4358038, recovery.img: 10194944.
recovery.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot-1.img work
Unpack & decompress boot-1.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 3580032
ramdisk size : 594701
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line :
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't unpack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]d:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot-1.img
mkbootimg from work/img_info.
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't repack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
*Reserved*
If your boot.img and/or recovery.img is found to not be supported using this tool then please send me your boot.img and recovery.img so I may review it and determine if official support can be added. Thanks.
Add support for MediaTek Images:
-- Unpack and repack boot/recovery images.
-- Append proper headers to ramdisk when repacking.
-- Compiled mkimage to assist with the headers.
-- This support currently does not include the logo images at this time.
-- MT6516
-- MT65x3 (MT6513 and MT6573)
-- MT65x5 (MT6515 and MT6575)
-- MT6577
-- MT65x2 (MT6572 and MT6582)
-- MT6589
-- MT83xx (MT8377 and MT8389)
Modding.MyMind said:
If your boot.img and/or recovery.img is found to not be supported using this tool then please send me your boot.img and recovery.img so I may review it and determine if official support can be added. Thanks.
Click to expand...
Click to collapse
getting error
Code:
[email protected]:/ $ su
/mkbootimg_tool/ARM <
/mkboot boot.img h3ll <
<Unpack and repack boot.img tool>
----------------------------------------------------------------------
Not enough parameters or parameter error!
unpack boot.img & decompress ramdisk
mkboot [img] [output dir]
mkboot boot.img boot20130905
^[[?1;2cUse the unpacked directory repack boot.img(img_info)
mkboot [unpacked dir] [newbootfile]
mkboot boot20130905 newboot.img
^[[?1;[email protected]:/data/local/tmp/mkbootimg_tool/A;2c1;2c <
sh: 1: not found
sh: 2c1: not found
sh: 2c: not found
127|[email protected]:/data/local/tmp/mkbootimg_tool/ARM #
H3LL said:
getting error
Code:
[email protected]:/ $ su
/mkbootimg_tool/ARM <
/mkboot boot.img h3ll <
----------------------------------------------------------------------
Not enough parameters or parameter error!
unpack boot.img & decompress ramdisk
mkboot [img] [output dir]
mkboot boot.img boot20130905
^[[?1;2cUse the unpacked directory repack boot.img(img_info)
mkboot [unpacked dir] [newbootfile]
mkboot boot20130905 newboot.img
^[[?1;[email protected]:/data/local/tmp/mkbootimg_tool/A;2c1;2c <
sh: 1: not found
sh: 2c1: not found
sh: 2c: not found
127|[email protected]:/data/local/tmp/mkbootimg_tool/ARM #
Click to expand...
Click to collapse
Check the permissions, check that bash is placed at /system/xbin, and insure the image you are trying to unpack is in the same directory where the mkboot script is located or else, insure you specify the image path properly.
If it still errors out insure your device is ARM and compatible for the project. If yes, then at the top of the script will be; #set -x. Uncomment it and run the script again, then copy and paste it's output here.
Also, send me your image to download and verify on my end. Thanks.
Modding.MyMind said:
Check the permissions, check that bash is placed at /system/xbin, and insure the image you are trying to unpack is in the same directory where the mkboot script is located or else, insure you specify the image path properly.
If it still errors out insure your device is ARM and compatible for the project. If yes, then at the top of the script will be; #set -x. Uncomment it and run the script again, then copy and paste it's output here.
Also, send me your image to download and verify on my end. Thanks.
Click to expand...
Click to collapse
tried same output as above here's boot.IMG
H3LL said:
tried same output as above here's boot.IMG
Click to expand...
Click to collapse
Your image doesn't have an android header. It's elf. This tool currently doesn't support it but now that I have your boot.img I can see about adding support. Can you send me your recovery image as well so I may verify that the process is the same for both when unpacking and repacking. Some images such as MediaTek have different headers for the ramdisk depending on whether it's the boot or recovery and so I would like to confirm the same with yours as well. Thanks.
Edit: Also, this tool won't work on your device unless the binaries are compiled from source for your machine. It's currently for ARM, but your device won't play nice with it.
Modding.MyMind said:
Your image doesn't have an android header. It's elf. This tool currently doesn't support it but now that I have your boot.img I can see about adding support. Can you send me your recovery image as well so I may verify that the process is the same for both when unpacking and repacking. Some images such as MediaTek have different headers for the ramdisk depending on whether it's the boot or recovery and so I would like to confirm the same with yours as well. Thanks.
Edit: Also, this tool won't work on your device unless the binaries are compiled from source for your machine. It's currently for ARM, but your device won't play nice with it.
Click to expand...
Click to collapse
there is no recovery. img for this device (its not mediatek) its in ramdisk of the boot.img....yeah my device is ARM
H3LL said:
there is no recovery. img for this device (its not mediatek) its in ramdisk of the boot.img....yeah my device is ARM
Click to expand...
Click to collapse
Reviewed the binaries and somehow overlooked a few after compiling them. Some aren't even true static when I originally thought I did compile them as such. There are also some which are true static but focus on either hard floats or soft floats. So, I need to go back and recompile the ones which stood out and push them to my repo. This may very well be why it isn't playing fair on your Sony device.
With that said, adding support for your image is gonna be a bit complicated to write out in bash since it is very involved lol. However, I am gonna make an attempt by taking on the challenge and seeing if I can get it done .
The github account doesn't exist anymore and there's no download link?
[null]
how to compile this for windows
I can't use one over the other because I need gamepass cuz Iwant to save money on hardware not buy games on steam but also i need linux because bash is miles better than some IDE which takes up 30 gb at minimum
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.
How to install:
Unlock bootloader:
Boot your device into the official OS.
Go to Settings > About phone, tap the "build number" several times to enable developer settings.
Go to Settings > System > Developer Settings, enable OEM unlocking and ADB debugging.
Connect your phone to your PC and open a terminal or a command line window.
Run adb reboot bootloader on your PC (there is no way to enter bootloader directly, only possible through adb).
Once your device has finished booting run fastboot flashing unlock and comfirm unlock on device (THIS WILL WIPE ALL DATA!).
Run fastboot reboot to reboot your device and now you should see an unlocked warning during boot screen.
Disable AVB:
Download vbmeta.img from the latest release page of your device.
Connect your phone to your PC and open a terminal or a command line window.
Run adb reboot bootloader on your PC to put your device in bootloader mode.
Once your device has finished booting run fastboot flash --disable-verification --disable-verity vbmeta vbmeta.img
Then run fastboot flash --disable-verification --disable-verity vbmeta_system vbmeta.img
Also run fastboot flash --disable-verification --disable-verity vbmeta_vendor vbmeta.img
Flash recovery image:
Connect your phone to your PC and open a terminal or a command line window.
Run adb reboot bootloader on your PC to put your device in bootloader mode.
Once your device has finished booting run fastboot erase recovery. For some reason, image may be not actually flashed, even if fastboot reported success (at least over the stock recovery image), so in order make sure that the custom image is always flashed it's better to always erase the partition before flashing. After the erasing run fastboot flash recovery recovery.img
Run fastboot reboot and after the screen goes dark press volume up until you see the TWRP logo. Also you can type fastboot reboot recovery to boot to recovery mode immediately.
Please note that booting in stock ROM will bring stock recovery back.
This recovery image is built using binaries from non-european (TEE) version of Jelly 2. Theoretically it should work on european (EEA). If it won't - contact me, I'll prepare an image based on EEA binaries.
Source code https://github.com/Meetoul/twrp_device_Unihertz_Jelly2
Thanks!
This fantastic!
its work on EEA!
Meetoul said:
Source code https://github.com/Meetoul/twrp_device_Unihertz_Jelly2
Click to expand...
Click to collapse
I just received my Jelly 2. It was on 2020 and I went straight through your files. Your TWRP does not respond on my European Jelly 2. Meaning, the touch screen does not respond. But I connected an USB trackball and switched in between adb sideloads. So I finally got it working.
For some reason during reboot TWRP warns me that there is no OS installed. But LoS 18.1 (yours) booted fine. Also flashed opengapps 2707 nano.
After a reboot (phone is still restoring apps) there is a "serial console is enabled" message "performance is impacted, check bootloader". Any instructions on how to get rid of that?.
I cannot seem to mount system as R/W with GSI image from https://github.com/phhusson/treble_experimentations/releases from within TWRP. I guess that's a more general problem, though
Any ideas?
kkazakov13 said:
I cannot seem to mount system as R/W with GSI image from https://github.com/phhusson/treble_experimentations/releases from within TWRP. I guess that's a more general problem, though
Any ideas?
Click to expand...
Click to collapse
Dave you tried the latest release a suggested by Meetoul?
[ROM] [UNOFFICIAL] Lineage OS 17.1 | Unihertz Jelly 2
https://drive.google.com/drive/u/0/folders/1VSmj_-a1PYNzFWtUfbsDGWg4uIh-Tgkd This ROM is built using binaries from non-european (TEE) version of Jelly 2. Theoretically it should work on european (EEA). If it won't - contact me, I'll prepare ROW...
forum.xda-developers.com
Release Fix gt1151qm touch in recovery · Meetoul/twrp_device_Unihertz_Jelly2_TEE
Recovery image based on new kernel image with patches for both gt1x and gt1151qm touch panel drivers.
github.com
Great Job!
I have Jelly2_JP.
I tried your recovery.img for Jelly2_TEE.
It can boot my Jelly2_JP, and it can enable adb shell, but it looped the splash screen.
But I execute following command in adb shell, twrp starts gui("Keep System Read only?" screen)
Jelly2_TEE:/ # mount -o ro /dev/block/mapper/system /
Touchscreen works fine.
Next, I tried to build twrp for Jelly2_JP using your device tree.
But it has same problem. (It looped the splash screen until I mount system partition.)
Do you have any advice?
Attachments
recovery_tee.log is pulled file from /tmp/recovery.log in your twrp for Jelly2_TEE. Line 1119 is after I mount system partition by adb shell.
recovery_jp.log is pulled file from /tmp/recovery.log in my twrp for Jelly2_JP. Line 1356 is after I mount system partition by adb shell.
My build instructions
$ cd ~/twrp
$ repo init -u https://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0
$ vi .repo/local_manifests/roomservice.xml
$ repo sync --force-sync
$ cd device/Unihertz
$ cp -r Jelly2_TEE Jelly2_JP
$ cd Jelly2_JP
$ mv omni_Jelly2_TEE.mk omni_Jelly2_JP.mk
$ grep -l Jelly2_TEE * | xargs sed -i 's/Jelly2_TEE/Jelly2_JP/g'
$ grep -l g55v71c2k_dfl_tee * | xargs sed -i 's/g55v71c2k_dfl_tee/g55v71c2k_dfl_jp_felica/g'
$ ./extract-files.sh ~/stock_jp/extracted
$ unpack_bootimg --boot_img ~/stock_jp/recovery.img --out ~/stock_jp/recovery
$ cp ~/stock_jp/recovery/kernel prebuilt/Image.gz
$ cp ~/stock_jp/recovery/dtb prebuilt/dtb/mt6771.dtb
$ cp ~/stock_jp/recovery/recovery_dtbo prebuilt/dtbo.img
$ cd ~/twrp
$ source build/envsetup.sh
$ lunch omni_Jelly2_JP-eng
$ mka recoveryimage
$ ls out/target/product/Jelly2_JP/recovery/root/vendor
bin etc
$ cp -r vendor/Unihertz/Jelly2_JP/proprietary/reovery/root/vendor out/target/product/Jelly2_JP/recovery/root
$ mka recoveryimage
file upload again.
Sorry, I can't upload Attach files.
I clicked "Attach files" button and choose file.
I clicked "Save" button, but file link did not inserted.
I uploaded recovery.log to github.
How to get vbmeta.img
Three knife said:
How to get vbmeta.img
Click to expand...
Click to collapse
Direct Link
Google Drive: Sign-in
Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).
drive.google.com
See Also
Jelly 2 firmware made available by Unihertz
A post to let people interested in small Android phones know that the firmware of the Jelly 2 has been made available by Unihertz. Would be great if a LineageOS version of this could be made...
forum.xda-developers.com
Or
[HOWTO] Flash a blank vbmeta
Hey guys, As some of you know samsung made had a bunch of different changes since the release of Android 10. It took me a week to figure it out but it was really simple. I had to do two things: Repatch the the magisk boot image with Preserve AVB...
forum.xda-developers.com
I found the crash point in Jelly2_JP.
The crash point is CHECK() on line 772 of twrp/hardware/interfaces/keymaster/4.0/support/Keymaster.cpp.
C++:
CHECK(error == ErrorCode::OK)
<< "Failed to get HMAC parameters from " << *keymaster << " error " << error;
CHECK() is defined on line 495 of twrp/system/core/base/include/android-base/logging.h
C++:
#define CHECK(x) \
LIKELY((x)) || ABORT_AFTER_LOG_FATAL_EXPR(false) || \
::android::base::LogMessage(__FILE__, __LINE__, ::android::base::DEFAULT, \
::android::base::FATAL, _LOG_TAG_INTERNAL, -1) \
.stream() \
<< "Check failed: " #x << " "
I thought /system/bin/recovery was crashing due to a bug.
But it is not a bug.
/system/bin/recovery is programmed to abort if CHECK() fails.
Next, I compared the results of CHECK().
1. using your recovery.img for Jelly2_TEE.
Code:
$ adb shell
Jelly2_TEE:/ # uname -a
Linux localhost 4.14.141+ #15 SMP PREEMPT Wed May 19 11:04:10 CST 2021 aarch64
Jelly2_TEE:/ # mount -o ro /dev/block/mapper/vendor /vendor
Jelly2_TEE:/ # md5sum /vendor/lib64/libkeymaster4.so
17f162aedb3a9584e51d7f732ebbac7f /vendor/lib64/libkeymaster4.so
Jelly2_TEE:/ # umount /vendor
Jelly2_TEE:/ # md5sum /vendor/lib64/libkeymaster4.so
22ede18944c5f47daf04d699a72717b2 /vendor/lib64/libkeymaster4.so
Jelly2_TEE:/ # logcat -v brief -d -s /system/bin/recovery
E//system/bin/recovery( 324): Failed to get IAshmemDeviceService.
W//system/bin/recovery( 324): [libfs_mgr]Warning: unknown flag: resize
W//system/bin/recovery( 324): [libfs_mgr]Warning: unknown flag: resize
I//system/bin/recovery( 324): [libfs_mgr]Created logical partition product on device /dev/block/dm-0
I//system/bin/recovery( 324): [libfs_mgr]Created logical partition system on device /dev/block/dm-1
I//system/bin/recovery( 324): [libfs_mgr]Created logical partition vendor on device /dev/block/dm-2
W//system/bin/recovery( 324): DM_DEV_STATUS failed for system_image: No such device or address
W//system/bin/recovery( 324): DM_DEV_STATUS failed for vendor_image: No such device or address
W//system/bin/recovery( 324): DM_DEV_STATUS failed for product_image: No such device or address
I//system/bin/recovery( 324): fscrypt_initialize_systemwide_keys
I//system/bin/recovery( 324): List of Keymaster HALs found:
I//system/bin/recovery( 324): Keymaster HAL #1: HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default
F//system/bin/recovery( 324): Keymaster.cpp:150] Check failed: error == ErrorCode::OK Failed to get HMAC parameters from HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default error SECURE_HW_COMMUNICATION_FAILED
2. using my recovery.img for Jelly2_JP.
This is built with Jelly2_JP's kernel and /vendor/*.
Code:
$ adb shell
Jelly2_JP:/ # uname -a
Linux localhost 4.14.141+ #5 SMP PREEMPT Wed May 19 12:15:37 CST 2021 aarch64
Jelly2_JP:/ # mount -o ro /dev/block/mapper/vendor /vendor
Jelly2_JP:/ # md5sum /vendor/lib64/libkeymaster4.so
17f162aedb3a9584e51d7f732ebbac7f /vendor/lib64/libkeymaster4.so
Jelly2_JP:/ # umount /vendor
Jelly2_JP:/ # md5sum /vendor/lib64/libkeymaster4.so
17f162aedb3a9584e51d7f732ebbac7f /vendor/lib64/libkeymaster4.so
Jelly2_JP:/ # logcat -v brief -d -s /system/bin/recovery
E//system/bin/recovery( 327): Failed to get IAshmemDeviceService.
W//system/bin/recovery( 327): [libfs_mgr]Warning: unknown flag: resize
W//system/bin/recovery( 327): [libfs_mgr]Warning: unknown flag: resize
I//system/bin/recovery( 327): [libfs_mgr]Created logical partition product on device /dev/block/dm-0
I//system/bin/recovery( 327): [libfs_mgr]Created logical partition system on device /dev/block/dm-1
I//system/bin/recovery( 327): [libfs_mgr]Created logical partition vendor on device /dev/block/dm-2
W//system/bin/recovery( 327): DM_DEV_STATUS failed for system_image: No such device or address
W//system/bin/recovery( 327): DM_DEV_STATUS failed for vendor_image: No such device or address
W//system/bin/recovery( 327): DM_DEV_STATUS failed for product_image: No such device or address
I//system/bin/recovery( 327): fscrypt_initialize_systemwide_keys
I//system/bin/recovery( 327): List of Keymaster HALs found:
I//system/bin/recovery( 327): Keymaster HAL #1: HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default
F//system/bin/recovery( 327): Keymaster.cpp:150] Check failed: error == ErrorCode::OK Failed to get HMAC parameters from HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default error SECURE_HW_COMMUNICATION_FAILED
They are same Error code SECURE_HW_COMMUNICATION_FAILED.
Unfortunately, my recovery.img wasn't improved from your recovery.img when used with Jelly2_JP.
I'm sorry for the continuous posting.
I solved the decryption by modifying omni_Jelly2_JP.mk as follows.
Code:
PRODUCT_NAME := omni_Jelly2_JP
PRODUCT_DEVICE := Jelly2_JP
PRODUCT_MODEL := Jelly2_JP
PRODUCT_BOARD := g55v71c2k_dfl_jp_felica
BUILD_FINGERPRINT := "Unihertz/Jelly2_JP/Jelly2_JP:10/QP1A.190711.020/root.20210422.092852:user/release-keys"
PRODUCT_BUILD_PROP_OVERRIDES += \
TARGET_DEVICE=Jelly2_JP \
PRODUCT_NAME=Jelly2_JP \
PRIVATE_BUILD_DESC="Jelly2-user 10 QP1A.190711.020 root.20210422.092852 release-keys"
My mistake was that I only replaced "Jelly2_TEE" with "Jelly2_JP".
I had to replace "Jelly2" with "Jelly2_JP".
Anyway, now I can display the decryption screen.
Next, I tried HOW-TO-PATCH.md.
However, the touch screen does not respond on the patched kernel.
Code:
$ head -n 1 symbl_tee.txt
ffffff81dd680800 T do_undefinstr
$ grep get_boot_mode symbl_tee.txt
ffffff81ddda5b30 T get_boot_mode
$ zcat twrp/device/Unihertz/Jelly2_TEE/prebuilt/Image.gz > Image
$ aarch64-linux-android-objdump -D -b binary -m aarch64 --adjust-vma=0xffffff81dd680000 --start-address=0xffffff81ddda5b30 Image| head
ffffff81ddda5b30: d0009cc8 adrp x8, 0xffffff81df13f000
ffffff81ddda5b34: b947ad09 ldr w9, [x8,#1964]
ffffff81ddda5b38: 7100093f cmp w9, #0x2
I think you are using a different technique to enable the touch screen, because "cmp w9, #0x2" is not patched to "cmp w9, #0x0".
Please teach me your technique after you are not busy with work.
谢谢你,我用的是中国的没有Google Play的版本,按照你的步骤成功了,不过在安装完recovery.img之后,内部存储有可能无法写入,需要在recovery里删除data分区,然后就可以了
Thanks for this!
I flashed this TWRP, then installed AOSP 11, v313 of this GSI: https://github.com/phhusson/treble_experimentations/releases/tag/v313
Things seem good, except:
the battery seems to drain a little quickly
no IR blaster (ZaZa remote does not recognize it)
TWRP cannot decrypt the phone's contents, so I cannot flash gapps.
Is TWRP not able to decrypt because I'm using Android 11 and the TWRP was built for 10?
@karoooo
Sorry for not responding to you, for some reason email notifications from XDA were stopped. Please tell me if you still need patched kernel, I will try to patch it explain you the technique.
zxczxc4 said:
Thanks for this!
I flashed this TWRP, then installed AOSP 11, v313 of this GSI: https://github.com/phhusson/treble_experimentations/releases/tag/v313
Things seem good, except:
the battery seems to drain a little quickly
no IR blaster (ZaZa remote does not recognize it)
TWRP cannot decrypt the phone's contents, so I cannot flash gapps.
Is TWRP not able to decrypt because I'm using Android 11 and the TWRP was built for 10?
Click to expand...
Click to collapse
Actually, data decryption on MTK SoCs is very painful thing. I'm still waiting for stable release of Android 11 from Unihertz, but they are in no hurry...
I know that beta 11 available. Unfortunately, I was not able to update using the official way. The bootloader was locked and the moment of updating, but probably the reason is that it was unlocked before (it possible to relock bootloader using SP Flash Tool). But I manager to fetch zip update package and install it via TWRP After that I even managed to make package for SP Flash Tool based on this package, so I can to flash pure FW without updating and have locked bootloader!
UPD. I see that Unihertz have published Android 11 SW package for SP Flash Tool on their Google Drive! Soon I will try to make recovery based on this package.
@Meetoul
Thank you for your response.
Yes, yes, yes!
I want to know your technique.
Best Regards.
HI.
Summary: FRONT CAMERA not working after Bootloader Unlock
I am using Jelly2_JP (on latest Android 10) and I was wondering,
has anyone has experinced the Front Camera not working after Bootloader Unlock, and possibly the three " --disable-verification --disable-verity" commands?
The stock camera app won't recognize the front camera (not front/back switch button where there should be one), and other apps cant use the front camera either.
I can confirm that the front camera worked before unlocking the bootloader.
Reflashing stock image using SP Flash Tool and relocking Bootlader did not fix the issue.
Is anyone else experiencing the same issue?
karoooo said:
@Meetoul
Thank you for your response.
Yes, yes, yes!
I want to know your technique.
Best Regards.
Click to expand...
Click to collapse
Since Unihertz has released Android 11, I think that there is no sense to work on patching the old kernel.
Btw, now I'm working on TWRP based on Android 11 binaries from the latest FW, but no luck so far, it seems that kernel doesn't even start to boot...
@Meetoul
I wanted to learn your technique so that I could work on my own when Android 11 was released.
If Android 11 is formidable, prioritize working with Android 11.
Unfortunately, Android 11 for Jelly2_JP has not been released yet.
@kendzhi
I unlocked the bootloader with Jelly2_JP, but the front camera is still working.
@karoooo
Thank you for the reply!
May I ask, was your Jelly2_JP shipped before the latest Andorid 10 update (2021051912_g55v71c2k_dfl_jp_felica), meaning did your phone come with the previous Firmware (2020101915_g55v71c2k_dfl_jp_felica)?
I have two Jelly2_JP from Japan which came preshipped with the latest andorid Andorid 10 update (there was no need for OTA update). And in both phones, upon executing "fastboot flashing unlock" (without disableling AVB & without Rooting), the the front camera stopped working (not recognized by the system).
I even went into the Debug/Diagnostic? mode that was in Chinese (Booting by Vol down + Connecting to PC via USB), and peformed a hardware test for the Front Camera and the test froze the phone.
So I'm suspecting that Jelly2_JP that was shipped to Japan with the latest Firmware has some issues with Bootloader Unlocking breaking the Front Cam...