[Q] Error while compiling kernel from source!!! - Samsung Galaxy Player 4.0, 5.0

So..... I've been fussing with the kernel these days.
I managed to add cwm recovery just by editing initramfs.
also, I could enable init.d support
I had a repacker script that only involves original zImage and edited initramfs folder and it made my work easier.
Now, I became greedy and I wanted to add cpu governor.
If I want to do so, I 've gotta actually compile the kernel from source.
I first used this command
export ARCH=arm
export CROSS_COMPILE=/home/xxxxxxxx/arm-2009q3/bin/arm-none-eabi
make venturi_kor_defconfig #I have Korean device
make menuconfig # at the menu, i located my initramfs folder
make -j2
I've got numerous errors no matter what toolchain I used.
arm-eabi-4.4.0
arm-eabi-4.4.3
arm-eabi-4.7
arm-2009q3
arm-eabi-linaro 4.6.2
arm-eabi-linaro 4.7
all the zImages created had similar sizes as the original ones but none of them passed samsung logo (they do boot into recovery though)
4.4.3 and 4.7 didn't even make zImage so I guess that's guaranteed failure.
But Samsung's YP-GB70 Opensource zip says that I should use arm-2009q3 and when I do, it still gives me error
I use 12.04 LTS 64bit
any suggestion please? I'm dire

stylemate said:
So..... I've been fussing with the kernel these days.
I managed to add cwm recovery just by editing initramfs.
also, I could enable init.d support
I had a repacker script that only involves original zImage and edited initramfs folder and it made my work easier.
Now, I became greedy and I wanted to add cpu governor.
If I want to do so, I 've gotta actually compile the kernel from source.
I first used this command
export ARCH=arm
export CROSS_COMPILE=/home/xxxxxxxx/arm-2009q3/bin/arm-none-eabi
make venturi_kor_defconfig #I have Korean device
make menuconfig # at the menu, i located my initramfs folder
make -j2
I've got numerous errors no matter what toolchain I used.
arm-eabi-4.4.0
arm-eabi-4.4.3
arm-eabi-4.7
arm-2009q3
arm-eabi-linaro 4.6.2
arm-eabi-linaro 4.7
all the zImages created had similar sizes as the original ones but none of them passed samsung logo (they do boot into recovery though)
4.4.3 and 4.7 didn't even make zImage so I guess that's guaranteed failure.
But Samsung's YP-GB70 Opensource zip says that I should use arm-2009q3 and when I do, it still gives me error
I use 12.04 LTS 64bit
any suggestion please? I'm dire
Click to expand...
Click to collapse
Hmmm. First make sure you downloaded source for the gingerbread kernel (2.6.35) and not froyo (2.6.32) - it should also be a zip.
Second 4.4.3 is what I use, so that's quite strange. I'll need complete output to see what the problem is.

Mevordel said:
Hmmm. First make sure you downloaded source for the gingerbread kernel (2.6.35) and not froyo (2.6.32) - it should also be a zip.
Second 4.4.3 is what I use, so that's quite strange. I'll need complete output to see what the problem is.
Click to expand...
Click to collapse
Hmm sorrry for not clarifying that. I'm certain that I got Gingerbread source and it said to use G++ toolchain for EABI. Which is arm-2009q3-68
I made a mistake saying that It gave me an error. they were warnings. zImages were succesfully made along with other modules but it just doesn't boot.
btw, do you know how to fix bootloop when recovery can't locate cache partition and can't even factory reset?

stylemate said:
Hmm sorrry for not clarifying that. I'm certain that I got Gingerbread source and it said to use G++ toolchain for EABI. Which is arm-2009q3-68
I made a mistake saying that It gave me an error. they were warnings. zImages were succesfully made along with other modules but it just doesn't boot.
btw, do you know how to fix bootloop when recovery can't locate cache partition and can't even factory reset?
Click to expand...
Click to collapse
Do you have the initramfs packed into the rom because Samsung kernels have the initramfs inside them.
Sent from my Nexus 7 using Tapatalk HD

zaclimon said:
Do you have the initramfs packed into the rom because Samsung kernels have the initramfs inside them.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
....... hmmmmmm I'm having quite hard time comprehending that....... sorry
i first extracted initramfs from zImage, (you know by using magic number like 30 37 30 37)
Then I added cwm recovery from Entropy's source.
I repacked it to modified_ramdisk.cpio
Then I tried to compile kernel by samsung's open source zip (inside there were one tar.gz for platform and another for kernel)
I used those commands at the first post, using the right toolchain that the opensource specified.
I even located my initramfs directory in the GUI section of config.
What did I do wrong?

stylemate said:
....... hmmmmmm I'm having quite hard time comprehending that....... sorry
i first extracted initramfs from zImage, (you know by using magic number like 30 37 30 37)
Then I added cwm recovery from Entropy's source.
I repacked it to modified_ramdisk.cpio
Then I tried to compile kernel by samsung's open source zip (inside there were one tar.gz for platform and another for kernel)
I used those commands at the first post, using the right toolchain that the opensource specified.
I even located my initramfs directory in the GUI section of config.
What did I do wrong?
Click to expand...
Click to collapse
Oh sorry I meant kernel instead of ROM. Hmm why don't you take an initramfs from another source or copy-paste the scripts from your device and add the cwm binaries from entropy's?
Sent from my Nexus 7 using Tapatalk HD

stylemate said:
Hmm sorrry for not clarifying that. I'm certain that I got Gingerbread source and it said to use G++ toolchain for EABI. Which is arm-2009q3-68
I made a mistake saying that It gave me an error. they were warnings. zImages were succesfully made along with other modules but it just doesn't boot.
btw, do you know how to fix bootloop when recovery can't locate cache partition and can't even factory reset?
Click to expand...
Click to collapse
stylemate said:
....... hmmmmmm I'm having quite hard time comprehending that....... sorry
i first extracted initramfs from zImage, (you know by using magic number like 30 37 30 37)
Then I added cwm recovery from Entropy's source.
I repacked it to modified_ramdisk.cpio
Then I tried to compile kernel by samsung's open source zip (inside there were one tar.gz for platform and another for kernel)
I used those commands at the first post, using the right toolchain that the opensource specified.
I even located my initramfs directory in the GUI section of config.
What did I do wrong?
Click to expand...
Click to collapse
As far as I know, you didn't do anything wrong. The issue must be somewhere in the init scripts (init.<whatever>, recovery.rc, ueventd.<whatever>). Did you copy those from Entropy's ramdisk too? Which ones?

zaclimon said:
Oh sorry I meant kernel instead of ROM. Hmm why don't you take an initramfs from another source or copy-paste the scripts from your device and add the cwm binaries from entropy's?
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
I think I'm the only one with korean SGP5 initramfs source.....
anyway, I had a repacking script which doesn't bother with compiling the actual kernel.
I could make a kernel with just CWM recovery and it worked.
But I figured out that I had to compile the actual kernel to add governor or OC stuff... so......

Mevordel said:
As far as I know, you didn't do anything wrong. The issue must be somewhere in the init scripts (init.<whatever>, recovery.rc, ueventd.<whatever>). Did you copy those from Entropy's ramdisk too? Which ones?
Click to expand...
Click to collapse
Ho Thanks for your suggestion. I didn't copy the actual files of those scripts, I looked at his commit and saw those lines changed when he was adding CWM. So I just added or replaced few lines at recovery.rc
Then I copied bunch of files in sbin, which seemed necessary for the recovery.
I copied the clockworkmod image file
Then finally i copied the recovery.fstab
to misc/
I edited recovery.fstab several times to get mount and storage work.
So I think initramfs itself has no problem....... It got me a working kernel with CWM recovery.
But it's the problem when I actually try to compile kernel from the scratch.....

stylemate said:
Ho Thanks for your suggestion. I didn't copy the actual files of those scripts, I looked at his commit and saw those lines changed when he was adding CWM. So I just added or replaced few lines at recovery.rc
Then I copied bunch of files in sbin, which seemed necessary for the recovery.
I copied the clockworkmod image file
Then finally i copied the recovery.fstab
to misc/
I edited recovery.fstab several times to get mount and storage work.
So I think initramfs itself has no problem....... It got me a working kernel with CWM recovery.
But it's the problem when I actually try to compile kernel from the scratch.....
Click to expand...
Click to collapse
When you were just modifying the initramfs, did it boot normally then?

Mevordel said:
When you were just modifying the initramfs, did it boot normally then?
Click to expand...
Click to collapse
yes. very smoothly
I used linaro tool chain 4.6.2 and also arm-eabi-4.7 both worked fine when i just modified the initramfs with a simple script.

stylemate said:
yes. very smoothly
I used linaro tool chain 4.6.2 and also arm-eabi-4.7 both worked fine when i just modified the initramfs with a simple script.
Click to expand...
Click to collapse
Can you boot into CWM and (using adb shell) give me the output of
Code:
cat /proc/cpuinfo
ls -la /
Thanks.

Mevordel said:
Can you boot into CWM and (using adb shell) give me the output of
Code:
cat /proc/cpuinfo
ls -la /
Thanks.
Click to expand...
Click to collapse
Sorry I couldn't do anything because my device was hard bricked and I fixed it today 0.0
Hope you are still around here.
I can't run adb shell with my newly compiled kernel
computer does not detect my device and i tried plugging it in and out several times, killing adb server each time.
interesting thing is that i can't mount USB storage, system, efs or anything else in CWM recovery.
Only cache partition is mounted which is strange. I used same initramfs source for both working kernel and newly compiled kernel,
but i don't know what happened during the compiling process.
I tried compiling with the original intiramfs folder (not modified one) and <3e> recovery also gave me numerous errors like can't mount where, where, where, where.
so there mustn't be a problem in both init.rc-like scripts and ultimately initramfs. It's probably the compiling process and how I set up the compilation.
Do i have to check all lines in venturi_kor_defconfig......?
oh btw, sdcard can be mounted with original ramdisk compiled kernel also, just checked it now.

stylemate said:
Sorry I couldn't do anything because my device was hard bricked and I fixed it today 0.0
Hope you are still around here.
I can't run adb shell with my newly compiled kernel
computer does not detect my device and i tried plugging it in and out several times, killing adb server each time.
interesting thing is that i can't mount USB storage, system, efs or anything else in CWM recovery.
Only cache partition is mounted which is strange. I used same initramfs source for both working kernel and newly compiled kernel,
but i don't know what happened during the compiling process.
I tried compiling with the original intiramfs folder (not modified one) and <3e> recovery also gave me numerous errors like can't mount where, where, where, where.
so there mustn't be a problem in both init.rc-like scripts and ultimately initramfs. It's probably the compiling process and how I set up the compilation.
Do i have to check all lines in venturi_kor_defconfig......?
oh btw, sdcard can be mounted with original ramdisk compiled kernel also, just checked it now.
Click to expand...
Click to collapse
I mean from CWM on your repacked-but-not-compiled kernel -- the one you said worked.
Also, which exactly zip did you download from Samsung's site? You don't need to go through the defconfig as long as you got the right one.
Third, please only compile with 4.4.3 or the one Samsung recommends. Anything newer will probably not work.
Fourth, as to partitions, they are all formatted to RFS, right? And can you run in CWM (where everything mounts and is mounted):
Code:
mount
fdisk -l /dev/block/mmcblk0

Mevordel said:
I mean from CWM on your repacked-but-not-compiled kernel -- the one you said worked.
Also, which exactly zip did you download from Samsung's site?
Third, please only compile with 4.4.3 or the one Samsung recommends. Anything newer will probably not work.
Click to expand...
Click to collapse
1st
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 99.40
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 2
Hardware : SMDKC110
Revision : 0000
Serial : 08c5603ec1690711
-rw-r--r-- 1 system system 118 Dec 25 12:19 default.prop
drwxr-xr-x 9 root root 2840 Jan 23 01:26 dev
drwxrwxr-x 1 radio system 0 Jan 23 01:26 efs
drwxr-xr-x 2 root root 0 Jan 23 01:26 emmc
lrwxrwxrwx 1 root root 11 Jan 23 01:26 etc -> /system/etc
-rwxr-xr-x 1 system system 1876 Dec 25 12:19 fota.rc
-rwxr-xr-x 1 system system 168364 Dec 25 12:27 init
-rw-r--r-- 1 system system 1677 Dec 25 12:19 init.goldfish.rc
-rwxr-xr-x 1 system system 30941 Dec 28 08:32 init.rc
-rwxr-xr-x 1 system system 30931 Dec 25 17:46 init.rc~
-rwxr-xr-x 1 system system 4489 Dec 25 12:19 init.smdkc110.rc
drwxr-xr-x 3 system system 0 Dec 25 12:19 lib
-rwxr-xr-x 1 system system 1419 Dec 25 12:19 lpm.rc
drwx------ 2 system system 0 Dec 26 16:21 misc
drwxrwxr-x 3 root root 0 Jan 23 01:26 mnt
drwxr-xr-x 2 root root 0 Jan 23 01:26 preload
dr-xr-xr-x 60 root root 0 Jan 1 1970 proc
-rwxr-xr-x 1 system system 410344 Dec 25 12:19 recovery
-rw-r--r-- 1 system system 2182 Dec 25 12:39 recovery.rc
drwxr-xr-x 3 system system 0 Dec 25 12:40 res
drwxr-xr-x 2 system system 0 Dec 26 16:31 sbin
drwxr-xr-x 2 root root 0 Jan 23 01:26 sdcard
drwxr-xr-x 12 root root 0 Jan 23 01:26 sys
drwxr-xr-x 1 root root 0 Jan 23 01:26 system
drwxrwxrwt 2 root root 60 Jan 23 01:26 tmp
-rw-r--r-- 1 system system 0 Dec 25 12:19 ueventd.goldfish.rc
-rw-r--r-- 1 system system 4245 Dec 25 12:19 ueventd.rc
-rwxr-xr-x 1 system system 1749 Dec 25 12:19 ueventd.smdkc110.rc
drwxrwxr-x 3 system system 0 Dec 28 08:33 vendor
init.rc~ file is the autocreated backup file that i forgot to erase
2nd
I downloaded YP-GB70-WW GB Opensource.zip
3rd
Yes I've been using the right toolchain that the readme file specified.
I have tried 4.4.3 too and many other toolchains.
4th
{
"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"
}
it's very normal... I had to fix this part of partition cause my partition was messed up beginning from block 12 but now it's perfect.
picture stolen from Siraki......

stylemate said:
1st
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 99.40
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 2
Hardware : SMDKC110
Revision : 0000
Serial : 08c5603ec1690711
-rw-r--r-- 1 system system 118 Dec 25 12:19 default.prop
drwxr-xr-x 9 root root 2840 Jan 23 01:26 dev
drwxrwxr-x 1 radio system 0 Jan 23 01:26 efs
drwxr-xr-x 2 root root 0 Jan 23 01:26 emmc
lrwxrwxrwx 1 root root 11 Jan 23 01:26 etc -> /system/etc
-rwxr-xr-x 1 system system 1876 Dec 25 12:19 fota.rc
-rwxr-xr-x 1 system system 168364 Dec 25 12:27 init
-rw-r--r-- 1 system system 1677 Dec 25 12:19 init.goldfish.rc
-rwxr-xr-x 1 system system 30941 Dec 28 08:32 init.rc
-rwxr-xr-x 1 system system 30931 Dec 25 17:46 init.rc~
-rwxr-xr-x 1 system system 4489 Dec 25 12:19 init.smdkc110.rc
drwxr-xr-x 3 system system 0 Dec 25 12:19 lib
-rwxr-xr-x 1 system system 1419 Dec 25 12:19 lpm.rc
drwx------ 2 system system 0 Dec 26 16:21 misc
drwxrwxr-x 3 root root 0 Jan 23 01:26 mnt
drwxr-xr-x 2 root root 0 Jan 23 01:26 preload
dr-xr-xr-x 60 root root 0 Jan 1 1970 proc
-rwxr-xr-x 1 system system 410344 Dec 25 12:19 recovery
-rw-r--r-- 1 system system 2182 Dec 25 12:39 recovery.rc
drwxr-xr-x 3 system system 0 Dec 25 12:40 res
drwxr-xr-x 2 system system 0 Dec 26 16:31 sbin
drwxr-xr-x 2 root root 0 Jan 23 01:26 sdcard
drwxr-xr-x 12 root root 0 Jan 23 01:26 sys
drwxr-xr-x 1 root root 0 Jan 23 01:26 system
drwxrwxrwt 2 root root 60 Jan 23 01:26 tmp
-rw-r--r-- 1 system system 0 Dec 25 12:19 ueventd.goldfish.rc
-rw-r--r-- 1 system system 4245 Dec 25 12:19 ueventd.rc
-rwxr-xr-x 1 system system 1749 Dec 25 12:19 ueventd.smdkc110.rc
drwxrwxr-x 3 system system 0 Dec 28 08:33 vendor
init.rc~ file is the autocreated backup file that i forgot to erase
2nd
I downloaded YP-GB70-WW GB Opensource.zip
3rd
Yes I've been using the right toolchain that the readme file specified.
I have tried 4.4.3 too and many other toolchains.
Click to expand...
Click to collapse
Thanks. I edited my post after you quoted it. But from what you posted, everything looks in order. (A minor OCD is that you should delete init.rc~, but it shouldn't make a difference.)
It's somewhat a hunch, but try downloading the "YP-G1 US" source and compiling it with venturi_kor_defconfig,
And I'm not sure, as I don't have any of the Korean devices, but isn't there a difference between YP-G70 and YP-GB70? If so, then venturi may not even be the right config.

Mevordel said:
Thanks. I edited my post after you quoted it. But from what you posted, everything looks in order. (A minor OCD is that you should delete init.rc~, but it shouldn't make a difference.)
It's somewhat a hunch, but try downloading the "YP-G1 US" source and compiling it with venturi_kor_defconfig,
And I'm not sure, as I don't have any of the Korean devices, but isn't there a difference between YP-G70 and YP-GB70? If so, then venturi may not even be the right config.
Click to expand...
Click to collapse
DMB function and Camera is the major and maybe the only difference. But That doesn't really matter.
As long as i get bootable kernel I will be fine with it. Haha
Thank you, I will try with YP-G70 later.

Related

[Q] /efs recovery

Very bad news.
I appear to have had an accident with /efs. Not 100% sure what I did but suspect it related to a product code change.
My SGS2 now will not show an IMEI or connect to the cell network.
I connected with /adb and saw a number of files were updated earlier today
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_data.bak.md5
-rwx------ 1 radio radio 2097152 Jan 1 2011 .nv_data.bak
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin
-rw-r--r-- 1 system system 0 Nov 3 18:02 cryptprop_onetimeboot
drwxrwx--x 5 radio system 4096 Nov 3 21:23 .
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
You can see the changes to nv_data.bin.md5 and nv_data.bin -- I have no idea what crptprop_onetimeboot is but it looks a little suspicious.
Firstly I have a copy of the above as
- a directory on my sdcard
- a dd'd image on my sdcard
- a file copy on my PC (!)
I also see I still have backup files, so with a lot of difficulty (fs kept going read only when trying to copy files, so I ended up renaming the old name to the new name)
ie
.nv_data.bak -> nv_data.bin
.nv_data.bak.md5 -> nv_data.bin.md5
This didn't work (still no service/no imei), so I removed(renamed) the .md5 file -- but it still doesn't work
so it now looks like
# ls -latr
ls -latr
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rwx------ 1 radio radio 32 Jan 1 2011 nv_data.bin.md5.orig
-rwx------ 1 radio radio 2097152 Jan 1 2011 nv_data.bin
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5.bk
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin.bk
-rw-rw-rw- 1 root root 0 Nov 3 20:55 p
drwxrwx--x 5 radio system 4096 Nov 3 21:48 .
-rw-r--r-- 1 system system 0 Nov 3 21:52 cryptprop_onetimeboot
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
#
[/FONT]
I DID NOT BACKUP EFS beforehand (only just learnt I need to) and know this may now be screwed, but I'm still hopeful I have the original file and just made a silly error.
I could also
- try recreating the whole fs and copying files back
- checking the prod code within the rom (but why?)
- flashing original firmware
- modifying the dd'd image *offline*, swapping the files, and dd'ing the image back
Any advice. PLEASE....
if you have a backup the easiest way I have found is to use root explorer.
go in to the /efs folder, set to read/write, mark everything and delete (not scrictly necessary simply copying over will work) but if you have been tinkering probably better.
then paste all the back up files and folders in
finally reboot (in my experience when something has gone wrong even this is not necessary)
Root explorer is worth every penny
and keep multiple backup's of your /efs on different drives
If this does not work you are screwed. The file contains your IMEI encrypted and the only way to get that restored is by returning it.
oh I just realised you are saying the back up you have is only of it in the current state?
If that's the case you are probably screwed, have you ever used any apps like nitrality or any unlocking tools? they will create copies of your efs folder on the scard in various locations. have you run a file seach on you sdcard to see if there is any copies at all?
if you have no backups of this folder then I think you will find its a return to manufacturer / sevice centre / provider issue.
I *think* I have restored the files -- and the dates look reasonable, as if they were the originals.
I've now flashed an old ROM (KE5) for good measure, but still no signal
One discrepancy I did notice is that after installing a rom there was some bootup message about csc and XEU when copying files.
My original sales code was VOD (UK vodafone). I had then run XEU firmware and just recently tried to set the sales code to XEU using a *# code. I subsequently flashed back to vodafone firmware today.
So somewhere there's a lingering reference to XEU -- this prod code incompatability could be causing the error?
I definately feel I should have the data to fix this -- after all I have the encrypted file, but am not quite sure of all the factors involved (one being "you're stuffed I know")
type *#06# this should display you IMEI number
if this does not match your IMEI from the box then you have not fixed this
if it shows all zeros or 004999010640000 then you are on a generic IMEI number
strangely when I screwed mine up and got the generic one above I was still able to use mine with a vodafone (UK) sim but not an orange on
if this is the case, and there is no efs backup prior to this you might well be screwed.
if this backup is all you have an you believe the .bak file is intact then I believe you will find solutions for deleting the primary version of the file and keeping only the backups and rebooting
the log file should give you more information on how successful this was, but if this was the result of flashing you probably overwrote both primary and backup
*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?
*#06# is currently showing blank -- but those .bak files looked fine.
Annoyed and frustrated...
In that case I would try deleting nv_data.bin and nv_data.m5 and rebooting
(assuming you have copies of everything
with just nv_data.bak nv_data.bak.md5
At least with the SGS1 this would work provided those bak files are the originals but the nv.log file will tell you more after the boot.
HOWEVER the SGSII has a lot more in this folder and I do not claim to fully understand them all but if you have a back up it's worth a shot
planetf1 said:
*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?
Click to expand...
Click to collapse
Took some inspiration from http://www.communityhosting.net/sgsunlock/i9000.html and decided to check permissions & recreation of md5.
md5 wasn't recreated, so no matter, I had a backup. that is restored, but I don't know if the .bak files are needed. Yet trying to create them I get:
# mv nv_data.bin.md5.orig nv_data.bin.md5
mv nv_data.bin.md5.orig nv_data.bin.md5
# cp nv_data.bin .nv_data.bak
cp nv_data.bin .nv_data.bak
cp: write error: Read-only file system
#
This isn't a space issue.
There could be another cause -- /efs/imei/mps_info.dat contains the 3 characters "XEU" even though the file is dated Jan 2011
So either
- the date has been manually fudged
OR
- the code always was XEU -- unlikely.
I'm currently working on the basis that fundamentally the IMEI is intact, that the original nv_data.bin is intact & that the phone is validating the CSC in mps_info.dat (XEU) against nv_data.bin (VOD) and failing.
Though this wouldn't explain why before the fix, with XEU in the nv_data.bin, it wasn't working
Unless the issue is the filesystem itself. could it be corrupt? Is this in fact why it switched to R/O mode each time? I've tried multiple kernels including insecure. surely they wouldn't all "protect" this fs.
But if this is the case where is fsck? maybe I need to copy the fs image to another linux box with ext4 & inspect/correct before shipping back and dd'ing
Continuing.
Found /system/bin/e2fsck -- ran this against /efs with
# /system/bin/e2fsck /dev/block/mmcblk0p1
/system/bin/e2fsck /dev/block/mmcblk0p1
e2fsck 1.41.11 (14-Mar-2010)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determini
ng whether /dev/block/mmcblk0p1 is mounted.
/dev/block/mmcblk0p1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create<y>? y
yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(3202--3203) +4104
Fix<y>? yes
/dev/block/mmcblk0p1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p1: 60/1280 files (1.7% non-contiguous), 2188/5120 blocks
**** >>> I NOW HAVE AN IMEI <<< ****
AND SIGNAL
LOGGED ONTO VODAFONE
WOOOHAY.
THIS HAS BEEN FUN. LOOK AND LEARN..
and seriously thanks to all the other articles and some moral support here tonight.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE
planetf1 said:
Continuing.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE
Click to expand...
Click to collapse
and make several backups of the /efs folder in its current state one would assume
Phone seems working. restoring over a HSPA connection happily, recognized voda sim.
now reinstalling titanium backup and copying down from dropbox...
The final step was restoring from titanium backup.
I had erased my sdcard -- though my backup was on dropbox.
However titanium backup is awful at copying files to/from dropbox -- as is IMO the phone when in "phone/kies" mode.
Finally I simply copied the dropbox directory back in USB debug=mass storage mode which was quick and reliable -- and then restored most items en-masse (I have a pro license).
For the record so far phone is fine - and indeed I've since run a new efs backup
The key takeaways from this are
* Backup efs and save it somewhere offline
* get titanium backup pro. it's good (better if it backed up efs too!)
* usb mass storage mode is the most reliable way for file xfer
* backup efs (again)
* don't get complacent
And of course if you do get a similar problem to mine
a) take a backup of efs with dd if=/dev/mmcXXX of=/mnt/scard/myefs.img (check name - I forget)
b) copy files you can to sdcard
c) copy both of this to a seperate pc
d) Just try running fsck (as above) - If I'd done this sooner I'd have saved hours. I should have gone with the obvious -- I've seen this on enough linux systems in the past to know what was happening but was thrown by no kernel messages.
Thanks for letting us know, might be a nice reference for future problems, especially the filesystem check.
Writing about it also helped keep me sane.giving up and hitting the beer was becoming increasingly attractive.
I do think making the warning about efs clearer would help.backup really should be a must at the earliest opportunity
Sent from my GT-I9100 using Tapatalk
Another thought.do unmount /efs before fsck
Sent from my GT-I9100 using Tapatalk
Unable to restore
I know I had a valid IMEI during the last week or so.
I have flashed several ROM's during the last month.
Last night lost IMEI
Now , no matter what I try, I can't seem to restore my IMEI. I have the fake one that ends in a bunch of zero''s
My SDCARD has a folder called EFS_BACKUP with multiple efs_xxxxxxx.tar.gz files in it. If I extract any of these and try to restore them to the /EFS folder I still have the fake IMEI number.
Please help - I didn't understand all the adb code in this post
Hi there,
/efs is fairly new to me too, to be honest it took hours of careful rooting before I gained some useful knowledge in how that area works.
-- what I would suggest before *anything else* is to copy anything you do have left in /efs. You will need to be root to do this. I found the gui root explorer type tools a bit clunky so I used the android SDK (adb is one of the tools in this package) to help. IF YOU NEED HELP WITH THIS SAY. You need to copy the files to multiple places for safety. Someone OFF your phone, ie on a PC. This is just in case things get worse. Do the same with any of those .gz backups you have. Maybe you'll need them *if* you make things worse...
If you're familiar with linux/unix systems this is all fairly easy, but if you're not it can be quite scary. For example you have to be able to write to /efs as well as list files and move them around. One wrong step and you could make things worse.
If you're unsure perhaps you could find a friend who knows *nix well to help you out. The bottom line is that you need to
a) ensure the right files are in there
b) The filesystem itself was intact
I definately suffered from b -- less sure about a.
What you need to do will depend a fair bit on what files you find in there, and what dates they are.
You said you had some backup files. Are you sure you have some from before the problem started? Can you look inside those backup files (I think winzip or similar will expand them for you). WIthout divoluging the actual contents (since you don't want to share your IMEI with anyone), is there an nv_data.bin file in there? Out of all the files it seems to be the most critical. When's it dated (mine was Jan 2011). If you cant' find that file how about .nv_data.bak - is that a good size, and again an old one.
If you have either of these -- even without anything else I think you can probably recover.
If you can get up and running with adb, a good start would be
adb shell
ls -laR /efs
Thank you very much, fsck method fixed my efs. Phone just broke it while doing nothing :/
I love you
You just saved my Galaxy S2
Yay. Brilliant news

[Dev] Kboot release (Stable), boot multiple kernel/os

Hi,
Here a release of kboot.
Kboot permit to boot multiple os with different kernel.
It's based on a buildroot environment.
The source to make your own kboot filesystem are available here
The kernel source are available here
You can download the install archive :
ARCHIVE VERSIONS
0.0. Unstable release. Freeze bug. Install release ARCHIVE (Obsolete)
0.1. Fix freeze. Python bytecode generation (pyc files) is naturally not friend with squashfs. Install release ARCHIVE (Obsolete)
0.2. STABLE Release. Display timeout, migration from squashfs to initramfs. Install release ARCHIVE
The archive looks like :
zImage and initramfs.cpio.gz to flash in SDE menu
a directory kboot which contain:
conf directory : configuration file
os directory : os to boot
images directory : background menu image
Installation
Kboot directory
Copy the kboot directory on your archos in /mnt/storage/, you should have this path /mnt/storage/kboot. The path should be exactly the same otherwise kboot will not be launched
Flash zImage and initramfs.cpio.gz
Follow this link to setup SDE on your archos http://forum.xda-developers.com/showthread.php?t=930197
After Reboot
You should have the following screen. Note: after installing Kboot the device permanently reboot in Kboot.
The main menu will display the os put in os directory (see in Configuration OS boot menu to see how to include your os), advanced menu and halt.
Boot menu
OS boot menu
I have tried to make things simple. To add an OS, all you need is to create a directory in /mnt/storage/kboot/os/ and put in this newly created directory the files zImage and initramfs.cpio.gz.
Important, the name should be exactly zImage and initramfs.cpio.gz, if one file is missing or misnamed the menu item don't appear
For example, the menu above have the following content in /mnt/storage/kboot/os :
Code:
/mnt/storage/kboot/os/Android Froyo:
drwxrwxrwx 2 2000 2000 4096 Feb 27 23:42 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 726520 Feb 27 23:39 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2564460 Feb 27 23:39 zImage
/mnt/storage/kboot/os/Android Honeycomb:
drwxrwxrwx 2 2000 2000 4096 Feb 27 16:46 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 zImage
/mnt/storage/kboot/os/UrukDroid 1.6:
drwxrwxrwx 2 2000 2000 4096 Feb 28 15:03 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 2874800 Jan 3 19:41 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2302252 Jan 3 19:26 zImage
Note : for specific kernel you can add a file named cmdline containing kernel parameters
Advanced boot menu
Boot init : boot into android, if android kernel was uninstalled, this item didn't appear
Boot recovery : boot into recovery
Soft boot : For details about omap soft reboot see the discussion here
Configuration
There is a configuration file in kboot/conf directory named config.ini. This file is divided into 3 section
init
telnet : 1 to enable telnet, 0 to disable
usbip : set the ip address of usb ethernet interface
Code:
[init]
telnet = 1
usbip = 192.168.10.1
kboot
last_selection : enable (1) or disable (0) the boot by default of the last selectioned entry after a configured timeout
last_selection_timeout : timeout in second
softboot : enable or disable softboot menu
title_font_size : set the title font size
menu_font_size : set the menu font size
title_color : title color in r,g,b format
menu_item_color : menu unselected color in r,g,b format
menu_item_selected_color : menu selected color in r,g,b format
Code:
[kboot]
# boot last selection if no key pressed after 30 seconds
last_selection = 1
last_selection_timeout = 30
# enable soft boot menu (bootloader dev only)
softboot = 1
# some tuning
title_font_size = 36
menu_font_size = 32
# change the color, R,G,B format
title_color = 255,255,255
menu_item_color = 92,97,98
menu_item_selected_color = 0,0,255
softboot
item<n> : the boot sequence wanted
Code:
[softboot]
# put a list of items to display in Soft boot menu
# item<n> = sequence
item1 = uart,usb,mmc1,mmc2
item2 = uart,usb
item3 = mmc1,mmc2
background image
To customize the background image, just replace the file kboot/images/bkg.png with your own and adapt if necessary the size and the font color.
BUGS
Feedbacks are welcome
Cool stuff bro!
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
It seems to be good.I have tested it on my A101 and it can boot both openaos and urukdroid.
Thanks.
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
fzelle said:
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
Click to expand...
Click to collapse
As an early release I didn't take the time to put the different resolution. The background image have a 1500x1200 resolution, so on 101 it didn't display right too. However kboot adapt resolution for corresponding board. kboot didn't boot on 70s or display wrong the background image ?
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to test urukdroid on mine.
The menu is not readable because the resolution adaption is not doing what it should do.
fzelle said:
The menu is not readable because the resolution adaption is not doing what it should do.
Click to expand...
Click to collapse
I have uploaded a new archive here.
Replace rootfs.squashfs with the new one. Fixed : resolution was wrong for 70S and 70H*.
The zImage in new archive should be flashed, it seems to fix the random freeze.
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to say sorry again that Kboot can boot Urukdroid properly.It was because I copied my backup file to my archos by using MY PC.That is why I cannot boot urukdroid.Maybe I didn't find the real cause. I'm now using Kboot to boot Urukdroid and Openaos.
Really very well!!
Sorry For My Bad English
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
fzelle said:
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
Click to expand...
Click to collapse
. Kernel natively support usb gadget ethernet, when kboot is launched a telnetd is started, an interface usb0 is configured with ip address 192.168.10.1.
if you are on linux it should automatically detect this and on your pc an ifconfig let appear usb0 interface. On your pc type :
Code:
ifconfig usb0 192.168.10.2 netmask 255.255.255.0 up
telnet -l root 192.168.10.1
.
If you can paste a ps output, to see if it detect you board correctly.
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
fzelle said:
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
Click to expand...
Click to collapse
Its fixed now . Replace rootfs by this one
alephzain said:
Its fixed now . Replace rootfs by this one
Click to expand...
Click to collapse
Please adapt the first post also so that future users have the correct files.
Maybe add a version number....
---------- Post added at 04:27 PM ---------- Previous post was at 04:12 PM ----------
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
fzelle said:
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
Click to expand...
Click to collapse
Not really possible because the stock firmware (initramfs) always uses the same location for the root file system.
You could do it but it needs some changes to the initramfs that is placed in the dirs.
wdl1908 said:
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Click to expand...
Click to collapse
Files on first post have been updated, but you're right a better presentation to avoid confusion is necessary.
Simply because I use python (pygame which use sdl) to code Kboot. Python lib dir is about 13M ... . A minimal filesystem (compressed initramfs) for kboot work is about 8M + ~2M for the kernel give 10M, and it's too big to flash in SDE max 8M. But if i can optimize the size ... I will do
alephzain thanks for the sources on gitorious, I hope I have some time in the weekend to try it out
divx118
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Hi,
im just about testing...
But sadly I can't get it to work.
Each time the menu starts up i can navigate nicely though the menues.
But whenever I select an entry - noting happens
After that I can still navigate ONCE (up or down) to the next entry and then the device freezes.
It doesn't matter wich entry i select as it seems. I tested Boot init, and my custom entries (UrukDroid and BullRC) yet. But all behave the same.
Any ideas ?
Btw: I tested it with the acutal squashfs and the one packed in the zip (even they seemed to be the same in size)
EDIT:
SOLUTION: I had usb cable attached (since flash) and that made it freeze - juts removed the cable and all is fine
Thanks and gr8 work - was looking for this since ages
fzelle said:
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Click to expand...
Click to collapse
Yes, no problem.

Weirdness with CWM nandroid backup

I'm still running Task's 7/3 ICS - yes, I'm going to go to the Tasks JB sometime soon, but I was waiting for things to get fixed and settle down before I switched.
I did a nandroid backup today and the files that were generated are different than the ones from a previous version of Task's ICS - all the .tar files are zero size and there are files with ".a" appended to the filename that have all the data in them. The previous version of Task's ICS didn't generate the .a files, just .tar files. CWM version is 5.5.0.4.
Code:
-rwxr-xr-x. 1 root root 8388608 Oct 21 21:09 boot.img
-rwxr-xr-x. 1 root root 0 Oct 21 21:12 cache.ext4.tar
-rwxr-xr-x. 1 root root 11776 Oct 21 21:12 cache.ext4.tar.a
-rwxr-xr-x. 1 root root 0 Oct 21 21:10 data.ext4.tar
-rwxr-xr-x. 1 root root 479716352 Oct 21 21:12 data.ext4.tar.a
-rwxr-xr-x. 1 root root 510 Oct 21 21:13 nandroid.md5
-rwxr-xr-x. 1 root root 8388608 Oct 21 21:09 recovery.img
-rwxr-xr-x. 1 root root 0 Oct 21 21:09 system.ext4.tar
-rwxr-xr-x. 1 root root 289286144 Oct 21 21:10 system.ext4.tar.a
I did some google searches but didn't find much about this. Are these files going to restore properly if I need to do a restore? I'm somewhat concerned about this because I want to be able to go back to ICS if JB has some issues that I would rather wait until they are fixed before I switch to JB. And I'd like to get some advice before trying to do a restore and finding out it messes up my phone (the phone is owned by my employer so I need to keep it in working order in case I get an after-hours call).
mvi57 said:
I'm still running Task's 7/3 ICS - yes, I'm going to go to the Tasks JB sometime soon, but I was waiting for things to get fixed and settle down before I switched.
I did a nandroid backup today and the files that were generated are different than the ones from a previous version of Task's ICS - all the .tar files are zero size and there are files with ".a" appended to the filename that have all the data in them. The previous version of Task's ICS didn't generate the .a files, just .tar files. CWM version is 5.5.0.4.
Code:
-rwxr-xr-x. 1 root root 8388608 Oct 21 21:09 boot.img
-rwxr-xr-x. 1 root root 0 Oct 21 21:12 cache.ext4.tar
-rwxr-xr-x. 1 root root 11776 Oct 21 21:12 cache.ext4.tar.a
-rwxr-xr-x. 1 root root 0 Oct 21 21:10 data.ext4.tar
-rwxr-xr-x. 1 root root 479716352 Oct 21 21:12 data.ext4.tar.a
-rwxr-xr-x. 1 root root 510 Oct 21 21:13 nandroid.md5
-rwxr-xr-x. 1 root root 8388608 Oct 21 21:09 recovery.img
-rwxr-xr-x. 1 root root 0 Oct 21 21:09 system.ext4.tar
-rwxr-xr-x. 1 root root 289286144 Oct 21 21:10 system.ext4.tar.a
I did some google searches but didn't find much about this. Are these files going to restore properly if I need to do a restore? I'm somewhat concerned about this because I want to be able to go back to ICS if JB has some issues that I would rather wait until they are fixed before I switch to JB. And I'd like to get some advice before trying to do a restore and finding out it messes up my phone (the phone is owned by my employer so I need to keep it in working order in case I get an after-hours call).
Click to expand...
Click to collapse
Why not just make another backup? Or test restore and have you return to stock files ready
Bleh
122ninjas said:
Why not just make another backup? Or test restore and have you return to stock files ready
Bleh
Click to expand...
Click to collapse
I've done 3 or 4 backups with the same results, and no errors reported by CWM. I will probably end up testing it but I thought I'd ask about it first in case it does cause a problem so I don't have to do a complete wipe/reflash to recover from a busted restore.
mvi57 said:
I've done 3 or 4 backups with the same results, and no errors reported by CWM. I will probably end up testing it but I thought I'd ask about it first in case it does cause a problem so I don't have to do a complete wipe/reflash to recover from a busted restore.
Click to expand...
Click to collapse
Did you try restoring one of the backups yet, to see if it restores properly?
0p3nsrc said:
Did you try restoring one of the backups yet, to see if it restores properly?
Click to expand...
Click to collapse
Yes, I did that a few days ago before I upgraded to Task's AOKP JB. The restore worked.

[Kernel 3.18] Lambda Reborn for the LeEco Le Pro 3 [Nightly][EUI][03/23]

{
"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"
}
Your warranty is now void.
I am not responsible for bricked devices, dead SD cards, thermonuclear war.
Please do some research if you have any concerns about using custom ROMs/Kernels.
You are choosing to make these modifications, and if you point the finger at me for
messing up your device, I will laugh at you.​
​​
Lambda Kernel was my development start point in the LG G2 glorious period, now you're looking at a new "horizon of possibility" for the LeEco device family. This Kernel has been written from scratch since January 2017, resulting in a small, polished and minimal core that's migratable across Kernel revisions.
It follows the flash n' go principle, everything packed in the Kernel is already tweaked and ready to be used as a daily driver for everyone.
The downloads, contributors and source code are at the bottom of this post, it is recommended to read everything before flashing.
DEVEL: My own testing builds for certain features and tests. They aren't normally shared, although sometimes I publish them. If you see one of them, don't forget they are recommended for advanced users/developers only because of their potential changes that must be debugged before publishing a NIGHTLY version.
NIGHTLY: They are closer to the proper release version but still can have some errors or bugs to be reported and tested, they should be generally stable. Nightly doesn't mean it builds every night here since I don't use a build server, it means that is the regularly updated version.
SNAPSHOT: That's the version for the ones that don't want their devices to be lab rats for new features and staging changes. I don't know whether or not to say something is stable enough to be a SNAPSHOT but if you see one it's because it's been sometime running well.
Pretty straightforward once you get used to it, isn't it?
A general panorama for Lambda Kernel, always matching the latest release, in this case the NIGHTLY from 03-23-2018.
HOT ↠ Source-code changes for Lambda Kernel.
COLD ↠ Environment changes for Lambda Kernel.
Latest LA.HB Kernel base from CAF's upstream HOT
Minimal device tree stubs and OEM code HOT
Modular approach for EUI compatibility HOT
Built with Paranoid's patched GCC compiler HOT
Latest Wi-Fi qcacl-2.0 driver from CAF's upstream HOT
Refactored and update OEM sound code to catch up with CAF HOT
Removed the old WCD9330 sound driver dependencies HOT
Removed most of the OEM useless drivers to use the original ones from CAF HOT
Tailored down the preset configuration to reduce Kernel size HOT
Own headset detection code built on top of CAF HOT
Backports of the Android USB driver and gadget from LA.UM.5.5 (N) HOT
Patched battery type adjustments during charger code execution HOT
Corrected charging constants to charge safer with less heat dissipation HOT​
Read this twice before flashing/posting!​
Cod. 000:
State: Placebo!
Priority: Urgent.
Overview: The thread is under construction here as well.
Read this twice before flashing/posting!​
Q. How to install this Kernel?
A. Download the version you'd like to use and flash using a custom recovery like TWRP.
Q. What ROMs does this Kernel support?
A. It supports the version explicitly mentioned in the file name and its "forks".
Q. Will this Kernel support my ROM in future?
A. I've no clue, will it probably be the default Kernel of those in future? You tell me...
​​
Click the Downloads button above to go straight to Github releases page, find the appropriate file for your variant and flash it in recovery.​
Many developers and people helped to bring the pieces of code needed to build the Lambda Kernel Project, some of them are listed below.
AlexDNS
Codeworkx
Dorimanx
Faux
FranciscoFranco
Myfluxi
SultanXDA​
Source for Kernel at Github.
Source for AnyKernel2 at Github.
Guide and introduction to Lambda Kernel development at Github.​
~ All project resources were built with free and open source software. ~​~ Lambda Kernel trademark and logos are copyleft. ~​~ This is a development thread, be polite. ~​
Reserved
Reserved.
Reserved
Reserved.
For EUI, right? I'm curious how it runs but I'm on CM13 atm.
Sent from my LEX727 using XDA-Developers Legacy app
benjmiester said:
For EUI, right? I'm curious how it runs but I'm on CM13 atm.
Sent from my LEX727 using XDA-Developers Legacy app
Click to expand...
Click to collapse
I'm not sure if there are device and Kernel trees for CM13 on this device available (open source) to check whether it'd work or not. The Kernel shouldn't diverge much from stock and it may worth the shot. If it boots on stock, it boots on CM probably.
GalaticStryder said:
I'm not sure if there are device and Kernel trees for CM13 on this device available (open source) to check whether it'd work or not. The Kernel shouldn't diverge much from stock and it may worth the shot. If it boots on stock, it boots on CM probably.
Click to expand...
Click to collapse
Alright, I'll test it on a X727 (20s EUI). Just need to make a backup and cross my fingers lol.
Edit: The zip flashed correctly, but the phone just sits on the splash screen. I waited for about 10-12 minutes and didn't boot up or even reach the boot animation.
Ace42 said:
Alright, I'll test it on a X727 (20s EUI). Just need to make a backup and cross my fingers lol.
Edit: The zip flashed correctly, but the phone just sits on the splash screen. I waited for about 10-12 minutes and didn't boot up or even reach the boot animation.
Click to expand...
Click to collapse
Yeah, that was expected, that CAF merge introduced some pretty intrusive changes in device tree side of things, although none of them seem to hurt, splash screen stuck issues are usually something "minor" as the Kernel is still alive, probably trying to probe certain codec up but not being able to do so.
I may push another zip without the merge to query...
UPDATE: I'll be rolling a couple compilations with different changes, flashing in the version order will give better results. Please, check if /data/kernel_output.txt is present.
GalaticStryder said:
Yeah, that was expected, that CAF merge introduced some pretty intrusive changes in device tree side of things, although none of them seem to hurt, splash screen stuck issues are usually something "minor" as the Kernel is still alive, probably trying to probe certain codec up but not being able to do so.
I may push another zip without the merge to query...
UPDATE: I'll be rolling a couple compilations with different changes, flashing in the version order will give better results. Please, check if /data/kernel_output.txt is present.
Click to expand...
Click to collapse
I can't find that file. These are the only files in /data besides the folders.
Ace42 said:
I can't find that file. These are the only files in /data besides the folders.
Click to expand...
Click to collapse
So I wasn't generated at the ramdisk generation step, I've allocated the file, it will be in root right now.
Could you output the following:
Code:
ls -l /dev/block/bootdevice/by-name/boot
Code:
ls -l /system/lib/modules/
I'll push all builds to Drive, attachments aren't working quite well...
GalaticStryder said:
So I wasn't generated at the ramdisk generation step, I've allocated the file, it will be in root right now.
Could you output the following:
I'll push all builds to Drive, attachments aren't working quite well...
Click to expand...
Click to collapse
$ su
[email protected]_zl1:/data/data/com.termux/files/home # ls -l /dev/block/bootdevice/by-name/boot
lrwxrwxrwx root root 1970-03-22 08:01 boot -> /dev/block/sde18
[email protected]_zl1:/data/data/com.termux/files/home #
[email protected]_zl1:/data/data/com.termux/files/home #
ls -l /system/lib/modules/
-rw-r--r-- root root 11484 1970-03-10 00:35 ansi_cprng.ko
-rw-r--r-- root root 21644 1970-03-10 00:35 br_netfilter.ko
-rw-r--r-- root root 319628 1970-03-10 00:35 core_ctl.ko
-rw-r--r-- root root 7612 1970-03-10 00:35 evbug.ko
-rw-r--r-- root root 30740 1970-03-10 00:35 ghci-hcd.ko
-rw-r--r-- root root 32588 1970-03-10 00:35 gxhci-hcd.ko
-rw-r--r-- root root 62076 1970-03-10 00:35 jnl.ko
-rw-r--r-- root root 13916 1970-03-10 00:35 lcd.ko
-rw-r--r-- root root 56948 1970-03-10 00:35 mmc_block_test.ko
-rw-r--r-- root root 43732 1970-03-10 00:35 mmc_test.ko
-rw-r--r-- root root 2640 1970-03-18 01:00 modules.dep.bb
drwxr-xr-x root root 2017-01-05 15:31 qca_cld
-rw-r--r-- root root 19028 1970-03-10 00:35 rdbg.ko
-rw-r--r-- root root 20940 1970-03-10 00:35 spidev.ko
-rw-r--r-- root root 32116 1970-03-10 00:35 test-iosched.ko
-rw-r--r-- root root 45228 1970-03-10 00:35 ufs_test.ko
-rw-r--r-- root root 632820 1970-03-10 00:35 ufsd.ko
-rw-r--r-- root root 296948 1970-03-10 00:35 wil6210.ko
lrwxrwxrwx root root 2017-01-05 15:32 wlan.ko -> /system/lib/modules/qca_cld/qca_cld_wlan.ko
[email protected]_zl1:/data/data/com.termux/files/home #
Ace42 said:
$ su
[email protected]_zl1:/data/data/com.termux/files/home # ls -l /dev/block/bootdevice/by-name/boot
lrwxrwxrwx root root 1970-03-22 08:01 boot -> /dev/block/sde18
[email protected]_zl1:/data/data/com.termux/files/home #
[email protected]_zl1:/data/data/com.termux/files/home #
ls -l /system/lib/modules/
-rw-r--r-- root root 11484 1970-03-10 00:35 ansi_cprng.ko
-rw-r--r-- root root 21644 1970-03-10 00:35 br_netfilter.ko
-rw-r--r-- root root 319628 1970-03-10 00:35 core_ctl.ko
-rw-r--r-- root root 7612 1970-03-10 00:35 evbug.ko
-rw-r--r-- root root 30740 1970-03-10 00:35 ghci-hcd.ko
-rw-r--r-- root root 32588 1970-03-10 00:35 gxhci-hcd.ko
-rw-r--r-- root root 62076 1970-03-10 00:35 jnl.ko
-rw-r--r-- root root 13916 1970-03-10 00:35 lcd.ko
-rw-r--r-- root root 56948 1970-03-10 00:35 mmc_block_test.ko
-rw-r--r-- root root 43732 1970-03-10 00:35 mmc_test.ko
-rw-r--r-- root root 2640 1970-03-18 01:00 modules.dep.bb
drwxr-xr-x root root 2017-01-05 15:31 qca_cld
-rw-r--r-- root root 19028 1970-03-10 00:35 rdbg.ko
-rw-r--r-- root root 20940 1970-03-10 00:35 spidev.ko
-rw-r--r-- root root 32116 1970-03-10 00:35 test-iosched.ko
-rw-r--r-- root root 45228 1970-03-10 00:35 ufs_test.ko
-rw-r--r-- root root 632820 1970-03-10 00:35 ufsd.ko
-rw-r--r-- root root 296948 1970-03-10 00:35 wil6210.ko
lrwxrwxrwx root root 2017-01-05 15:32 wlan.ko -> /system/lib/modules/qca_cld/qca_cld_wlan.ko
[email protected]_zl1:/data/data/com.termux/files/home #
Click to expand...
Click to collapse
Thanks, that should be enough, see if the latest Experimental 3 boots after the quick fixes in anykernel. I'll add a wrapper to symlink the wlan module if needed. But first we need to force it boot up.
GalaticStryder said:
Thanks, that should be enough, see if the latest Experimental 3 boots after the quick fixes in anykernel. I'll add a wrapper to symlink the wlan module if needed. But first we need to force it boot up.
Click to expand...
Click to collapse
Success! It booted up.
Ace42 said:
Success! It booted up.
Click to expand...
Click to collapse
Thanks for testing it. The file kernel_output.txt is present in rootfs (/)?
Code:
cd /
cat kernel_output.txt
Code:
lsmod
Code:
dmesg
These should help to gather more on what is working or not.
http://pastebin.com/A3nBZ7gm
Ace42 said:
Success! It booted up.
Click to expand...
Click to collapse
and it boots with CM 13 but no wifi
Boots on slim rom as well
booted up here on my lex 720 Google Edition as well...[emoji122]
Sent from my LEX720 using XDA-Developers Legacy app
Okarina26 said:
booted up here on my lex 720 Google Edition as well...[emoji122]
Sent from my LEX720 using XDA-Developers Legacy app
Click to expand...
Click to collapse
Yup, seems that everyone is using the LeEco base Kernel so far, I know darkobas has a different Kernel source with a different tag from LA.UM (nougat) CAF tag, so I'd not encourage using this Kernel with Omni 7.1 if that's the case.
The modules didn't get injected, for some reason, I'll manage to patch this and then get rid of them.
New build 0.4 is up...
Could you be kindly so nice to talk about the features we will get with these kernel? Which configuration tool is recommended? Will it work with Cydras Rom?
... sent from my LEX720 with Tapatalk
GalaticStryder said:
Yup, seems that everyone is using the LeEco base Kernel so far, I know darkobas has a different Kernel source with a different tag from LA.UM (nougat) CAF tag, so I'd not encourage using this Kernel with Omni 7.1 if that's the case.
The modules didn't get injected, for some reason, I'll manage to patch this and then get rid of them.
New build 0.4 is up...
Click to expand...
Click to collapse
0.4 hangs on the splash screen just like 0.1. As soon as I revert to 0.3 it boots up to Android.

Working kdz extractor for V30

Hello,
is there any working linux script for extracting v30 kdz firmware and dz files?
Big thanks for help
H930g - lgv30 - kdz extract - linux
djsven said:
Hello,
is there any working linux script for extracting v30 kdz firmware and dz files?
Big thanks for help
Click to expand...
Click to collapse
Yes sir , I have found one
https://github.com/ehem/kdztools
Here are the output from my first test:
[email protected]:~/Android/kdztools-master$ ./unkdz -f H93011m_00_OPEN_EU_OP_1229.kdz -l
[!] Warning: Data between headers and payload! (offsets 826 to 83768)
[+] KDZ Partition List (format v2)
=========================================
0 : H93011m_00.dz (3563995785 bytes)
1 : LGUP_c.dll (3079120 bytes)
2 : LGUP_c.dylib (1229456 bytes)
[email protected]:~/Android/kdztools-master$ ./unkdz -f H93011m_00_OPEN_EU_OP_1229.kdz -x
[!] Warning: Data between headers and payload! (offsets 826 to 83768)
[+] Extracting all partitions from v2 file!
[+] Extracting H93011m_00.dz to kdzextracted/H93011m_00.dz
[+] Extracting LGUP_c.dll to kdzextracted/LGUP_c.dll
[+] Extracting LGUP_c.dylib to kdzextracted/LGUP_c.dylib
[+] Extracting extra data to kdzextracted/kdz_extras.bin
So far this is the only steps I have tried, I will give a later try to extract the whole DZ file
For your information I m running Ubuntu 16.04 LTS
I wish you good luck
Edit : Unfortunately I got this error when I try to list the DZ file
[email protected]:~/Android/kdztools-master$ ./undz -f H93011m_00.dz -l
[!] Error: Value supposed to be zero in field "reserved5" is non-zero (0x5900)
Sorry For this deception, maybe you know what this error is meaning ?
The format changed slightly, but the extraction still works. I didn't feel like figuring out what the data in the reserved field is for, so just comment out the two sys.exit(1).
You can use this patch...
Code:
diff --git a/undz.py b/undz.py
index 1078248..aa386a0 100755
--- a/undz.py
+++ b/undz.py
@@ -74,7 +74,7 @@ class UNDZUtils(object):
dz_item[key] = dz_item[key].rstrip(b'\x00')
if b'\x00' in dz_item[key]:
print("[!] Error: extraneous data found IN "+key, file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
elif type(dz_item[key]) is int:
if dz_item[key] != 0:
print('[!] Error: Value supposed to be zero in field "'+key+'" is non-zero ('+hex(dz_item[key])+')', file=sys.stderr)
@@ -86,7 +86,7 @@ class UNDZUtils(object):
# To my knowledge this is supposed to be blank (for now...)
if len(dz_item['pad']) != 0:
print("[!] Error: pad is not empty", file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
return dz_item
@@ -195,7 +195,7 @@ class UNDZChunk(dz.DZChunk, UNDZUtils):
zdata = self.dz.dzfile.read(self.dataSize)
# Decompress the data
- buf = zlib.decompress(zdata)
+ buf = zlib.decompress(zdata)
crc = crc32(buf) & 0xFFFFFFFF
-- Brian
runningnak3d said:
The format changed slightly, but the extraction still works. I didn't feel like figuring out what the data in the reserved field is for, so just comment out the two sys.exit(1).
You can use this patch...
Code:
diff --git a/undz.py b/undz.py
index 1078248..aa386a0 100755
--- a/undz.py
+++ b/undz.py
@@ -74,7 +74,7 @@ class UNDZUtils(object):
dz_item[key] = dz_item[key].rstrip(b'\x00')
if b'\x00' in dz_item[key]:
print("[!] Error: extraneous data found IN "+key, file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
elif type(dz_item[key]) is int:
if dz_item[key] != 0:
print('[!] Error: Value supposed to be zero in field "'+key+'" is non-zero ('+hex(dz_item[key])+')', file=sys.stderr)
@@ -86,7 +86,7 @@ class UNDZUtils(object):
# To my knowledge this is supposed to be blank (for now...)
if len(dz_item['pad']) != 0:
print("[!] Error: pad is not empty", file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
return dz_item
@@ -195,7 +195,7 @@ class UNDZChunk(dz.DZChunk, UNDZUtils):
zdata = self.dz.dzfile.read(self.dataSize)
# Decompress the data
- buf = zlib.decompress(zdata)
+ buf = zlib.decompress(zdata)
crc = crc32(buf) & 0xFFFFFFFF
-- Brian
Click to expand...
Click to collapse
hey , this doesnt work at all, its still showing the same error as before , im trying to extract G7 ThinQ kdz
[email protected]:~/kdztools-master$ ./undz.py -x -f G71010b_00.dz
[!] Error: Value supposed to be zero in field "reserved5" is non-zero (0x5900)
[email protected]:~/kdztools-master$
Click to expand...
Click to collapse
This was a quick hack to get V30 Nougat KDZs to extract. V30 Oreo KDZs require additional work, and I haven't even looked at G7 KDZs yet.
-- Brian
Encounter the same issue, patched the sys.exit() calls and flipped this line to avoid the error with reserved5:
('reserved5', ('I', False)), # currently always zero
But still errors. Further info at: hxxxs://github.com/ehem/kdztools/issues/16#issuecomment-435356938
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
SGCMarkus said:
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
Click to expand...
Click to collapse
Managed to unpack a modem partition LG changed the compression algorithm from zlib to zstd on LG V40 kdzs
SGCMarkus said:
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
Click to expand...
Click to collapse
Thank you very much for posting this.
It turns out I had a corrupt download of the H932 20o KDZ and no -- LG hasn't made any additional changes to the KDZ format.
When I saw that SALT was working for you, then I knew my extractor should work as well and that lead me to start looking elsewhere.
-- Brian
BINGO! LGV40 unpacked!
Code:
[20:10 [email protected] dzextracted] > sudo mount -t ext4 vendor_a.image /media/edu/ext4_tmp
[sudo] password for edu:
[20:10 [email protected] dzextracted] > cd /media/edu/ext4_tmp
[20:10 [email protected] ext4_tmp] > ll
total 220K
drwxr-xr-x. 10 root 2000 4.0K Dec 31 2008 app
drwxr-xr-x. 6 root 2000 8.0K Dec 31 2008 bin
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 carrier
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 dsp
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 els
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 eri
drwxr-xr-x. 23 root 2000 4.0K Dec 31 2008 etc
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 ffu
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 firmware
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 fota
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 framework
drwxr-xr-x. 11 root 2000 16K Dec 31 2008 lib
drwxr-xr-x. 9 root 2000 16K Dec 31 2008 lib64
drwx------. 2 root root 16K Dec 31 2008 lost+found
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 media
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 mpt
drwxr-xr-x. 83 root 2000 4.0K Dec 31 2008 overlay
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 package
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 persdata
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 persist-lg
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 power
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 priv-app
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 radio
drwxr-xr-x. 5 root 2000 4.0K Dec 31 2008 rfs
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 sns
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 srtc
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 vzw
-rw-------. 1 root root 8.8K Dec 31 2008 build.prop
-rw-r--r--. 1 root root 1.9K Dec 31 2008 compatibility_matrix.xml
-rw-------. 1 root root 684 Dec 31 2008 default.prop
lrw-r--r--. 1 root root 12 Dec 31 2008 factory_data -> /system/data
lrw-r--r--. 1 root root 19 Dec 31 2008 factory_etc -> /system/factory_etc
lrw-r--r--. 1 root root 19 Dec 31 2008 factory_lib -> /system/factory_lib
lrw-r--r--. 1 root root 21 Dec 31 2008 factory_lib64 -> /system/factory_lib64
-rw-r--r--. 1 root root 36K Dec 31 2008 manifest.xml
-rw-r--r--. 1 root root 16K Dec 31 2008 ueventd.rc
runningnak3d said:
Thank you very much for posting this.
It turns out I had a corrupt download of the H932 20o KDZ and no -- LG hasn't made any additional changes to the KDZ format.
When I saw that SALT was working for you, then I knew my extractor should work as well and that lead me to start looking elsewhere.
-- Brian
Click to expand...
Click to collapse
I PM you with the URL. I guess you don't need it but figured you would want an official link from LG Bridge.
Sent from my LG-H932 using XDA Labs
eduuk said:
Managed to unpack a modem partition LG changed the compression algorithm from zlib to zstd on LG V40 kdzs
Click to expand...
Click to collapse
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Dvalin21 said:
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Click to expand...
Click to collapse
I am also unable to get a useful unpack of a G7 or V40 KDZ.
@eduuk You don't even need to share your code, but if you could just point out the differences between the V30 and V40 KDZ format it would be appreciated.
-- Brian
@eduuk i got passed the reserved5 but now i get this error: [!] Error: extraneous data found IN pad
Also, if you can provide help with changing the compression algorithm from zlib to zstd i would appreciate it.
Dvalin21 said:
@eduuk i got passed the reserved5 but now i get this error: [!] Error: extraneous data found IN pad
Also, if you can provide help with changing the compression algorithm from zlib to zstd i would appreciate it.
Click to expand...
Click to collapse
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
runningnak3d said:
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
Click to expand...
Click to collapse
You rock sir, thank you
Dvalin21 said:
You rock sir, thank you
Click to expand...
Click to collapse
Well, that was more of a pain in the butt than it needed to be, but repo is incoming once I clean up some of my debug code:
Code:
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* ± ../undz2.py -f G71010f_00.dz -l
[+] DZ Partition List
=========================================
0/ 0 : PrimaryGPT_0.bin (1363 bytes)
0/ 1 : PrimaryGPT_0.bin (277 bytes)
0/ 2 : PrimaryGPT_0.bin (277 bytes)
0/ 3 : PrimaryGPT_0.bin (335 bytes)
0/ 4 : PrimaryGPT_0.bin (2355 bytes)
0/ 5 : PrimaryGPT_0.bin (404 bytes)
0/ 6 : PrimaryGPT_0.bin (213 bytes)
1/?? : mpt (<empty>)
2/?? : drm (<empty>)
3/?? : sns (<empty>)
4/?? : ssd (<empty>)
5/ 7 : persist_13446.bin (743 bytes)
6/?? : misc (<empty>)
7/ 8 : ftm_21894.bin (75 bytes)
8/?? : power (<empty>)
9/?? : encrypt (<empty>)
10/?? : eksst (<empty>)
11/?? : rct (<empty>)
12/?? : fota (<empty>)
13/?? : srtc (<empty>)
14/?? : pstore (<empty>)
15/?? : els (<empty>)
16/?? : carrier (<empty>)
17/?? : persdata (<empty>)
18/ 9 : oem_a_77574.bin (738 bytes)
<snip>
and
Code:
θ78° [swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 3s ± ../undz2.py -f G71010f_00.dz -s 20
[+] Extracting single slice^Wpartition!
[+] Extracting vendor_a_81670.bin to vendor_a.image
[+] Extracting vendor_a_114503.bin to vendor_a.image
[+] Extracting vendor_a_147206.bin to vendor_a.image
[+] Extracting vendor_a_147701.bin to vendor_a.image
<snip>
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 130 ± cd dzextracted/
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± mkdir mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± sudo mount vendor_a.image ./mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± cd mnt
[swango:~/dev … kdzextracted/dzextracted/mnt] $ ls -al
total 208
drwxr-xr-x 27 root root 4096 Dec 31 1969 .
drwxr-xr-x 3 swango swango 4096 Dec 15 10:29 ..
drwxr-xr-x 8 root 2000 4096 Dec 31 2008 app
drwxr-xr-x 6 root 2000 8192 Dec 31 2008 bin
-rw------- 1 root root 8664 Dec 31 2008 build.prop
drwxr-xr-x 2 root 2000 4096 Dec 31 2008 carrier
<snip>
The quick and dirty is that the header changed -- which is why there was data in the pad (that is the zero padding at the end of the header to make it 512 bytes) -- so I defined those, and they also changed the compression from zlib to zstandard (you need version 0.9 or greater) NOT zstd.
Lastly, when the compress, they don't include the size in the zstandard header, so I just picked a value that was big enough to decompress the largest partition.
Again, I have a lot of cleanup to do, and then I will commit this. Eventually I will make it so you can pass something like --zlib or --zst so that one file can be used to extract both old and new format KDZs, but for now there is undz2.py
-- Brian
OK - thread and link are here.
Please let me know if you come across any KDZs that you can't extract, but please post the errors in that thread.
-- Brian
Dvalin21 said:
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Click to expand...
Click to collapse
runningnak3d said:
OK - thread and link are here.
Please let me know if you come across any KDZs that you can't extract, but please post the errors in that thread.
-- Brian
Click to expand...
Click to collapse
hey guys,
sorry but I didnt get the time to answer you. Took me an entire day to patch the python code. It's so so ugly code, so I would prefer not share it if anyone can code it better than me
There was a guy who was sending me private messages to do the same as me, and he got it too. The only thing to do is to change the algorithm and patch out asserts and other checks.
Please let me know if you can do it without my ugly code. Otherwise, I will share it of course.
---------- Post added at 12:54 AM ---------- Previous post was at 12:51 AM ----------
runningnak3d said:
Well, that was more of a pain in the butt than it needed to be, but repo is incoming once I clean up some of my debug code:
Code:
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* ± ../undz2.py -f G71010f_00.dz -l
[+] DZ Partition List
=========================================
0/ 0 : PrimaryGPT_0.bin (1363 bytes)
0/ 1 : PrimaryGPT_0.bin (277 bytes)
0/ 2 : PrimaryGPT_0.bin (277 bytes)
0/ 3 : PrimaryGPT_0.bin (335 bytes)
0/ 4 : PrimaryGPT_0.bin (2355 bytes)
0/ 5 : PrimaryGPT_0.bin (404 bytes)
0/ 6 : PrimaryGPT_0.bin (213 bytes)
1/?? : mpt (<empty>)
2/?? : drm (<empty>)
3/?? : sns (<empty>)
4/?? : ssd (<empty>)
5/ 7 : persist_13446.bin (743 bytes)
6/?? : misc (<empty>)
7/ 8 : ftm_21894.bin (75 bytes)
8/?? : power (<empty>)
9/?? : encrypt (<empty>)
10/?? : eksst (<empty>)
11/?? : rct (<empty>)
12/?? : fota (<empty>)
13/?? : srtc (<empty>)
14/?? : pstore (<empty>)
15/?? : els (<empty>)
16/?? : carrier (<empty>)
17/?? : persdata (<empty>)
18/ 9 : oem_a_77574.bin (738 bytes)
<snip>
and
Code:
θ78° [swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 3s ± ../undz2.py -f G71010f_00.dz -s 20
[+] Extracting single slice^Wpartition!
[+] Extracting vendor_a_81670.bin to vendor_a.image
[+] Extracting vendor_a_114503.bin to vendor_a.image
[+] Extracting vendor_a_147206.bin to vendor_a.image
[+] Extracting vendor_a_147701.bin to vendor_a.image
<snip>
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 130 ± cd dzextracted/
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± mkdir mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± sudo mount vendor_a.image ./mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± cd mnt
[swango:~/dev … kdzextracted/dzextracted/mnt] $ ls -al
total 208
drwxr-xr-x 27 root root 4096 Dec 31 1969 .
drwxr-xr-x 3 swango swango 4096 Dec 15 10:29 ..
drwxr-xr-x 8 root 2000 4096 Dec 31 2008 app
drwxr-xr-x 6 root 2000 8192 Dec 31 2008 bin
-rw------- 1 root root 8664 Dec 31 2008 build.prop
drwxr-xr-x 2 root 2000 4096 Dec 31 2008 carrier
<snip>
The quick and dirty is that the header changed -- which is why there was data in the pad (that is the zero padding at the end of the header to make it 512 bytes) -- so I defined those, and they also changed the compression from zlib to zstandard (you need version 0.9 or greater) NOT zstd.
Lastly, when the compress, they don't include the size in the zstandard header, so I just picked a value that was big enough to decompress the largest partition.
Again, I have a lot of cleanup to do, and then I will commit this. Eventually I will make it so you can pass something like --zlib or --zst so that one file can be used to extract both old and new format KDZs, but for now there is undz2.py
-- Brian
Click to expand...
Click to collapse
Yeah 0x200 bytes of header, i removed that first with dd and then I coded in python changing offsets. Sorry but I dont have the time of coding this properly.
---------- Post added at 12:59 AM ---------- Previous post was at 12:54 AM ----------
eduuk said:
hey guys,
sorry but I didnt get the time to answer you. Took me an entire day to patch the python code. It's so so ugly code, so I would prefer not share it if anyone can code it better than me
There was a guy who was sending me private messages to do the same as me, and he got it too. The only thing to do is to change the algorithm and patch out asserts and other checks.
Please let me know if you can do it without my ugly code. Otherwise, I will share it of course.
---------- Post added at 12:54 AM ---------- Previous post was at 12:51 AM ----------
Yeah 0x200 bytes of header, i removed that first with dd and then I coded in python changing offsets. Sorry but I dont have the time of coding this properly.
Click to expand...
Click to collapse
The best way is to do a pull request at the main repo https://github.com/ehem/kdztools
---------- Post added at 01:00 AM ---------- Previous post was at 12:59 AM ----------
runningnak3d said:
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
Click to expand...
Click to collapse
Dude, did you read this by any chance? https://github.com/ehem/kdztools/issues
Cheers mate
Thanks for the answer @eduuk, however Brian did a kdztool working that I was able to fully extract all the image files for the G710TM10n firmware for T-Mobile. Still with that said we still appreciate all your work!

Categories

Resources