Related
Need some help from the gurus. I saw the threads on how to change the viewsonic birds and the boot animation, so I went on a trek to change the g-tablet logo. I know this and have gotten this far. That logo is in boot.img. I have been able to upack a TNT 2.2 boot image and get the ram disk. I see the logo file and know what to do when I change it. The problem comes when I go to repack the image. I get it repacked and use nvflash to get it on the tab... no boot. Hang at the viewsonic birds. nvflash back to the stock boot.img and everything is fine. I have tried to unpack and repack the boot.img without modifying anything with no luck. Still hangs.
What tools can I use to unpack and repack .img for the g-tab?
I used this URL, at first:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
Unpacking is OK, using the perl script. However, repacking was a problem so I did this.... first, to repack the ramdisk:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Then, to repack the boot.img with the new ramdisk:
Code:
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
I don't know if this is the best way, but at least the device will boot up.
Just found it on tegratab. You need to remove the --command... from the repack script. It causes the hang.
Thanks Roebeet!
Doh!
Hi all,
I am trying to rebuild the stock Froyo kernel on my Droid. I found the exact git version used as the stock kernel, and built the kernel with:
Code:
make sholes_defconfig LOCALVERSION=-g68eeef5
To the best of my understanding, that is the configuration file used.
I packaged the kernel with:
Code:
./mkbootimg --kernel omap/arch/arm/boot/zImage --ramdisk boot.img-ramdisk.gz --cmdline "console=ttyS2,115200n8 rw [email protected] init=/init ip=off brdrev=P3A_CDMA mtdparts=omap2-nand.0:[email protected](mbm),[email protected](cdt),[email protected](lbl),[email protected](misc),3584k(boot),4608k(recovery),143744k(system),94848k(cache),268032k(userdata),2m(kpanic)" -o boot.img
Then I flash the kernel image like the following:
Code:
flash_image boot /sdcard/boot.img
However, after the system boots and I get to my desktop I get the error:
Code:
Sorry! Process system is not responding.
I have compared the dmesg of booting the stock kernel and my rebuild of the kernel, found here:
http://www.ece.cmu.edu/~gnychis/diff.html
The one thing I am afraid of is around line 490,491 and some differences there after. Does anyone know what might be missing in my kernel configuration for those? I was pretty positive this was the exact configuration used, but maybe not. Has anyone had a problem like this trying to build a custom ROM?
Thanks!
solved... my boot.img-ramdisk.gz did not properly match. I extracted boot.img from the stock rom and paired my kernel with it.
NOTE: I started few days ago working with the boot image.
I'm not an Android expert. If you find an error in this post, let me know.
Use this information at your own risk. If you brick your tablet, don't blame on me.
Nothing of the tools used here are written by me. I'm not taking credit for another's work.
I have rooted my tf101 with the instructions from the mashi's thread. (http://forum.xda-developers.com/showthread.php?t=1125714)
I was curious about the root process of our beloved tablet.
For add root at the stock firmware you need the su packages and a proper boot image.
I've worked for years on linux machines, so I know that you need the "su" command to become root.
But what about the boot image? What does it need for?
I've googled and found some information that I'd like to share with you:
For using adb as superuser, and push the su package, you need to flash a so called "insecure boot" on your tablet/phone.
The process is easy:
NOTE: Even if I'm on a Windows machine, I prefer to do this work in linux. The entire process has been done in an Ubuntu 11.04 virtual machine.
What you need:
- a PC running linux
- BootTools and BlobTools from Rayman84 (http://androidroot.mobi/)
- mkbootimg (mkbootfs is optional) from the android repository
I assume that you have all the above tools in your $PATH variable.
First of all you need a stock boot image; you can extract one from your tablet (with nvflash) or from the latest stock firmware (US-VERSION - WW-VERSION)
We're going for the official packages from the ASUS website. Download it on your home directory (or wherever you want).
Let's start:
Code:
mkdir stock_firmware
cd stock_firmware
unzip ../UpdateLauncher_WW_epaduser_84411.zip
unzip ASUS/Update/WW_epad-user-8.4.4.11.zip
blobunpack blob
bootunpack blob.LNX
Now we have a lot of "strange" files:
Code:
ASUS
blob
blob.APP
blob.EBT
blob.HEADER
blob.LNX
blob.LNX-config
blob.LNX-kernel.gz
blob.LNX-ramdisk.cpio.gz
blob.PT
blob.SOS
META-INF
For our work, we just need blob.LNX-ramdisk.cpio.gz
Code:
mkdir boot_img
cd boot_img
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
vi default.prop (or "gedit default.prop" if you want a GUI)
Here you have to change the line "ro.secure=1" in "ro.secure=0"
The final file should appears as this:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
Almost done. Let's repack:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
or alternatively:
Code:
mkbootfs ./ | gzip > ../newramdisk.cpio.gz
Finally make the boot.img:
Code:
cd ..
mkbootimg --kernel blob.LNX-kernel.gz --ramdisk newramdisk.cpio.gz -o boot.img
Now you have your boot.img, ready to be flashed with nvflash.
For information on what to do with this file, please refer to the mashi or brk threads.
Again, I've taken this information from google.
All the credits and many thanks to:
Rayman for the BlobTools and the BootTools - http://androidroot.mobi/
Mashi for his thread on rooting the stock kernel - http://forum.xda-developers.com/showthread.php?t=1125714
Brk for his batch script - http://forum.xda-developers.com/showthread.php?t=1185104
If you found this guide useful, hit the "Thanks" button.
For your convenience, you can find the tools used attached in this post (compiled on Ubuntu 11.04).
UPDATE: I have written a script (thanks gnufabio for the idea) that automatically modify a stock boot.img into an insecure one.
ex:
Code:
./insecure.sh boot.img
when the script finishes you will find a file called my_boot.img ready to be flashed with nvflash.
Bootunpack and mkbootimg should be in your $PATH.
This script doesn't do much error checking, so keep your eyes open.
HF
hey thanks very nice guide
Excellent. I've been looking around trying to work out how to package up a kernel build, this helps a great deal.
I'm assuming that I just replace the blob.LNX-kernel.gz with my built zImage?
SammyC said:
Excellent. I've been looking around trying to work out how to package up a kernel build, this helps a great deal.
I'm assuming that I just replace the blob.LNX-kernel.gz with my built zImage?
Click to expand...
Click to collapse
I haven't try but i guess yes.
If you really want to recompile/repackage the kernel, you can refer to this http://www.droidforums.net/forum/rescue-squad-guides/31452-how-compile-your-own-kernel.html ; it's about the Motorola Droid, but some concepts are universal for all the android devices.
HF
Good work, btw give a look to this script i made: mcpio
Unpacking and repacking the ramdisk will be easier:
Code:
mcpio -c ramdisk-folder/
mcpio -e ramdis-archive.cpio.gz
Thanks - Very useful to have this in this section. I tried the example, and it all worked fine on an old Ubuntu dist.
gnufabio said:
Good work, btw give a look to this script i made: mcpio
Unpacking and repacking the ramdisk will be easier:
Code:
mcpio -c ramdisk-folder/
mcpio -e ramdis-archive.cpio.gz
Click to expand...
Click to collapse
Well, that's a lot easier...
I didn't know your script, thanks for sharing.
Updated the first post with a bash script to automate the entire process.
Yesterday I've succesfully recompiled the stock kernel and I'm thinking on write another guide like this one on the subject.
The process is a little complicate, i'm looking for an easy way to explain but it's hard.
Anyway I'm working on it in my spare time.
That would be great if you could.
ASUS haven't (yet) released the source for the kernel in their latest 3.2 build. If you've updated to 3.2, you can still root and repackage using this method. Just use nvflash to save off the kernel from your running device as per the backup/restore thread, then use bootunpack on that and follow the rest of the instructions
raypou said:
ASUS haven't (yet) released the source for the kernel in their latest 3.2 build. If you've updated to 3.2, you can still root and repackage using this method. Just use nvflash to save off the kernel from your running device as per the backup/restore thread, then use bootunpack on that and follow the rest of the instructions
Click to expand...
Click to collapse
it's exactly the method used here: http://forum.xda-developers.com/showthread.php?t=1198303
If anyone interested, here're win32 binaries of BlobTools and BootTools
Just compiled from git repo.
I unpacked a rom with a kernelblob in the root directory, and edited init.rc. Which command should I use to repackage it? If I follow the guide (instead of boot.img I used kernelblob, no extension) I get the EEE Pad logo then scrambled, colored lines all over.
If I, however, install the base rom, then the one where I changed something in the kernelblob, it boots up.
theMIROn said:
If anyone interested, here're win32 binaries of BlobTools and BootTools
Just compiled from git repo.
Click to expand...
Click to collapse
Hi, makebootimg.exe doesn't work. It gives error saying: error: could not load kernel 'blob.LNX-kernel.gz'
Tried same files in linux and worked fine.
Can you try to fix this?
EDIT: tried to compile myself but got the same issue. I think is related with the need to change source code to make this run on windows.
Working boottools for windows available here: http://forum.xda-developers.com/showpost.php?p=17237701&postcount=443
brk said:
Hi, makebootimg.exe doesn't work. It gives error saying: error: could not load kernel 'blob.LNX-kernel.gz'
Tried same files in linux and worked fine.
Can you try to fix this?
Click to expand...
Click to collapse
yep, it's code issue
attached BootTools-Win32.zip with fixed mkbootimg.exe
is there this guide for tf201?
BR
Maframan
maframan said:
is there this guide for tf201?
BR
Maframan
Click to expand...
Click to collapse
You should probably check the TF201 forum.
Could this method be used to pack a new Splash Screen? (I want to change that annoying ASUS logo to something better) Would I go about the Flash_Image method to flash the image after compiled? (I do Not have NvFlash, but I am rooted with Cwm)
Which blobs would I modify as well, just the EBT?
rebound821 said:
NOTE: I started few days ago working with the boot image.
I'm not an Android expert. If you find an error in this post, let me know.
Use this information at your own risk. If you brick your tablet, don't blame on me.
Nothing of the tools used here are written by me. I'm not taking credit for another's work.
I have rooted my tf101 with the instructions from the mashi's thread. (http://forum.xda-developers.com/showthread.php?t=1125714)
I was curious about the root process of our beloved tablet.
For add root at the stock firmware you need the su packages and a proper boot image.
I've worked for years on linux machines, so I know that you need the "su" command to become root.
But what about the boot image? What does it need for?
I've googled and found some information that I'd like to share with you:
For using adb as superuser, and push the su package, you need to flash a so called "insecure boot" on your tablet/phone.
The process is easy:
NOTE: Even if I'm on a Windows machine, I prefer to do this work in linux. The entire process has been done in an Ubuntu 11.04 virtual machine.
What you need:
- a PC running linux
- BootTools and BlobTools from Rayman84 (http://androidroot.mobi/)
- mkbootimg (mkbootfs is optional) from the android repository
I assume that you have all the above tools in your $PATH variable.
First of all you need a stock boot image; you can extract one from your tablet (with nvflash) or from the latest stock firmware (US-VERSION - WW-VERSION)
We're going for the official packages from the ASUS website. Download it on your home directory (or wherever you want).
Let's start:
Code:
mkdir stock_firmware
cd stock_firmware
unzip ../UpdateLauncher_WW_epaduser_84411.zip
unzip ASUS/Update/WW_epad-user-8.4.4.11.zip
blobunpack blob
bootunpack blob.LNX
Now we have a lot of "strange" files:
Code:
ASUS
blob
blob.APP
blob.EBT
blob.HEADER
blob.LNX
blob.LNX-config
blob.LNX-kernel.gz
blob.LNX-ramdisk.cpio.gz
blob.PT
blob.SOS
META-INF
For our work, we just need blob.LNX-ramdisk.cpio.gz
Code:
mkdir boot_img
cd boot_img
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
vi default.prop (or "gedit default.prop" if you want a GUI)
Here you have to change the line "ro.secure=1" in "ro.secure=0"
The final file should appears as this:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
Almost done. Let's repack:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
or alternatively:
Code:
mkbootfs ./ | gzip > ../newramdisk.cpio.gz
Finally make the boot.img:
Code:
cd ..
mkbootimg --kernel blob.LNX-kernel.gz --ramdisk newramdisk.cpio.gz -o boot.img
Now you have your boot.img, ready to be flashed with nvflash.
For information on what to do with this file, please refer to the mashi or brk threads.
Again, I've taken this information from google.
All the credits and many thanks to:
Rayman for the BlobTools and the BootTools - http://androidroot.mobi/
Mashi for his thread on rooting the stock kernel - http://forum.xda-developers.com/showthread.php?t=1125714
Brk for his batch script - http://forum.xda-developers.com/showthread.php?t=1185104
If you found this guide useful, hit the "Thanks" button.
For your convenience, you can find the tools used attached in this post (compiled on Ubuntu 11.04).
UPDATE: I have written a script (thanks gnufabio for the idea) that automatically modify a stock boot.img into an insecure one.
ex:
Code:
./insecure.sh boot.img
when the script finishes you will find a file called my_boot.img ready to be flashed with nvflash.
Bootunpack and mkbootimg should be in your $PATH.
This script doesn't do much error checking, so keep your eyes open.
HF
Click to expand...
Click to collapse
Hi Sir,
First of all thankyou for you guide because I did follow you guide and created the insecure boot.image succesfully. I still have one problem, after flashing the boot.image, I still could not root the android device. Why is that? Do I need to change something else in the boot.img?
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
-miska- said:
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
Click to expand...
Click to collapse
Here is what I've done. If you have successfully built a kernel with the resulting zImage, then you are part way there, I believe there is a kernel config option to enable kexec support but I haven't tried that. Next, you can take some other kernel's .zip file (CWM flashable) and unzip it. You may need to download a zip utility. You'll have 2 folders and a kernel blob. If you bootunpack this kernel blob, you'll end up with the kernel blob and a some *.LNX file. This *.LNX file is the same as a boot.img file. You can use dsixda's Android kitchen to split this into the initrd and the kernel (zImage) parts. Replace the zImage with your own and move any modules you may have also built if necessary into the initrd part, join them back together into a boot.img in the kitchen.
copy this boot.img back to where you unzipped the kernel.zip, delete the original *.LNX file, rename the boot.img to the same name as the previous *.LNX file and then bootpack it together and flash it through CWM. Zip the 2 folders and the kernel blob you just made back together with whatever name you want. You can edit the text in the updater script before you zip it all up, but whether you do or not it should boot.
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot :-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
-miska- said:
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot d:-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
Click to expand...
Click to collapse
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
sidneyk said:
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
Click to expand...
Click to collapse
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
https://github.com/koush/AnyKernel
Good luck -
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
sidneyk said:
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
Click to expand...
Click to collapse
hmmm, checked that one, uses blobed image and 'dd if=/tmp/blob of=/dev/block/mmcblk0p4' as well. Maybe I'll try different crosscompiler anyway, that's the one thing I haven't altered yet :-/
hachamacha said:
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
Click to expand...
Click to collapse
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
-miska- said:
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
Click to expand...
Click to collapse
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
hachamacha said:
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
Click to expand...
Click to collapse
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
lilstevie said:
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
Click to expand...
Click to collapse
OK: Thanks lilstevie,
That takes care of that. Time for me to make peace with blobs.
After steve's reply, I just went to using blobs. I've got my own kernel running fine on the tf101 using that method.
For the best reference I've seen on using blobs and boottools , try this post:
http://forum.xda-developers.com/showthread.php?t=1193737
---
Just got back from work, will ply with it some more, but I'll start with answering the questions...
hachamacha said:
1) Your linux distro and architecture (x86/x86_64)
Click to expand...
Click to collapse
Gentoo x86-64
hachamacha said:
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
Click to expand...
Click to collapse
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
hachamacha said:
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
Click to expand...
Click to collapse
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
-miska- said:
Just got back from work, will ply with it some more, but I'll start with answering the questions...
Gentoo x86-64
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
Click to expand...
Click to collapse
Pretty similar, although the kernel zImage itself is always a mystery unless you've not changed anything, but even then, getting it built with the right toolchain, etc isn't guaranteed. So lets assume that just works for now since it'll become obvious as it goes along.
I guess I have not heard of 'abootimg' as a tool for this, so I've been using the more manual way of dissecting the initrd as follows:
Code:
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
If you need to change something , for example, in default.prop like ro.secure=0, then you'd do it there.
Then repack into a new ramdisk:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Finally I just had a somewhat heavily modified zImage from my build, so did this to make the blob (I'd copied zImage to blob.LNK-zImage.gz below):
Code:
./mkbootimg --kernel blob.LNX-zImage.gz --ramdisk newramdisk.cpio.gz -o boot.img
./blobpack blob.HEADER newblob LNX boot.img
zip -r imagename.zip blob MET* system // whatever the syntax was.
NOTE: I did this on a native 64 bit ubuntu LTS 10.04 box.
Unless I typo'd up there, that 'should' work. If it does boot, then first thing, take a look at settings, and kernel info so you can verify that you're running the kernel you desired (hopefully you renamed it in Makefile the first 4-5 lines).
Solved
Ok, got it working!!! Problem was bad crosscompiler :-( Modules I crosscompiled worked fine, so I ruled crosscompiler out :-/ Looks like I was too quick in judgement :-( Now I have kernel recompiled with original settings and evne the modified one and it still works and boot. Now I'm going to play with new features I got! Thanks a lot for all help!!!
Just for the record, crosscompiler I was originally using was codesourcery 2011.03 and to make it work I switched to official crosscompiler from NDK. Rest of the commands was Ok, I was just suspecting wrong step as I was quite familiar with kernel building and quite unfamiliar with the blob stuff :-(
Congrats!
For some reason I avoid the codesourcery stuff and stick with either the prebuilt toolchains or else just build my own from gnu source.
Anyway, glad you figured it out.
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
sidneyk said:
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
Click to expand...
Click to collapse
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
hachamacha said:
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
Click to expand...
Click to collapse
If by 'native' you mean a hard disk install as opposed to a VM install, then that's where I'm at. I have Ubuntu 11.10 x86_64 installed to a separate partition. I have the recommended stuff installed including the ia32 libs, but I never see a blob.HEADER file with either kernel.zips or ROM zips. I can unpack and repack kernels without the HEADER though and they boot just fine.
But, yes, if you don't mind posting a link with your files I'll give them a try sometime. Thanks.
Preface: I'm currently using this device and really like it, and as you all may have realised, that this device is considered as a low activity device on XDA, and no developers that I know of have taken a crack at this phone. This thread is to consolidate all information pertaining to the device.
If some area are empty, they will have more content in the future as we progress with this awesome device.
Feel free to post any mods that have worked (preferably in systemless mode)
Table of Contents:
Post 1) Rooting, TWRP and useful Links
Post 2) Info for Developers
Post 3) Roms & Mods
Post 4) Reserved
Useful Links:
My Github (Matt07211) containing kernel source code, to keep with the GPL licenses.
Samsung Kernel Source Code 4.4.4/5.1.1 and 6.0.1
Firmware Samsung xCover 3 and Samsung xCover 3 Value Edition
TWRP for Samsung xCover3 (Kit Kat)
TWRP for Samsung xCover3 Value Edition Credits: @Heledir for the link
SuperSU
Prerequisites:
ADB Installed
USB Debugging Enabled
Samsung USB Drivers Installed
Samsung ODIN (Preferably Odin3_v3.10.7 or above)
A Brain that can use common sense, or Google
Disclaimer:
Anything you do with your own phone is done at your own risk. Don't complain if you accidentally brick your phone. Fix it by using Google, flash back stock firmware or post on XDA for help.
Knox will probably be voided, and so will your warranty.
We cannot say what works for us, may or may not work for you.
Good luck
Using ODIN:
1) Enable USB Debugging, and OEM Unlock (If available), these can be reached from the developer menu. The develpoer menu can be activated by taping "Build Number" 7 times in the about section.
Don't disable OEM Unlock (Ever) once modifing your phone, because FRP (Factoy Reset Protection) will be activated, and then you will be forced into reinstalling stock firmware, aalnd losing all your data in the process.
2) Turn phone off, boot into download mode (Power + Volume Down + Home) and then press Volume Up to use download mode when greeted with a yellow warning.
3) Launch ODIN, and plug phone into Computer. You should see some text like this "ID:COM" in blue.
4) Click the AP button (If it says PDA then you have an older version of ODIN, and are recommended to use a newer version) and Select the file that will be flashed. E.g. TWRP or a Boot.img. Making sure the only options ticked are "F.Reset Time" and "Auto-Reboot". If you are flashing a recovery (E.g. TWRP) then make sure "Auto-Reboot" is unticked, and when ODIN says successful flash then you'll have to then reboot the phone your self(Either by holding any combination of Volume Keys (Any one) + Power + Home or Removing the Battery and Placing back in) and reboot straight into recovery (at least once, else the stock recovery will replace TWRP on a normal boot bu a script called "install-recovery.sh").
5) If "Auto-Reboot is ticked, then the phone will automatically reboot once flashing has been completed.
Root:
SM-G388f:
KitKat:
1) Enable USB Debugging
2) Download the Newest TWRP from the above TWRP Link (the one marked with KitKat), making sure you download the file with the .img.tar extension.
3) Download the Newest SuperSu and place on the internal phone memory.
4) Flash the downloaded TWRP file, make sure "Auto-Reboot" is unticked (Refer to "Using ODIN" if needed). Click Start
5) Once flashed, reboot into recovery (Power + Volume Up + Home) straight away and Flash SuperSu.zip via the Flash Zip section.
Congrats you got root on KitKat
Lollipop:
Installation:
1) Make sure you have the prerequisites installed, and "xcover3-lollipop-root.zip"
unzipped. Then type
Code:
adb devices
to make sure adb recognises the phone and that its authorized.
2) Type (or copy) exaclty as below. *Please be paitent, as the first command
takes about 20 seconds to complete.
Code:
adb push su.img /data/local/tmp
adb install Superuser.apk
3) Once thats completed, turn off the device and then boot into download
mode (Volume Down + Home + Power).
4) Open the ODIN program, click "AP" then navigate to the "boot.tar.md5"
file that is in the "xcover3-lollipop-root: folder, then click open/okay.
Click start to flash.
5) The phone should auto-reboot. Once its fully booted, reboot once more
(perferabbly twice), this is to allow the script placed in the ramdisk to
move the su.img to /data.
6) Profit? Yay you've now got root. You can go and test it out by downloading
terminal emulator and typing "su", you then should be prompted to grant root
permissions to the app. Once granted, the "$" symbol will change to "#" to
signify root.
Thanks to:
@akuhak Thanks for build the custom tools necessary to modify the boot.img
@proguru Thanks for compiling a custom kernel for me, (for testing purposes) allowing me to test various things.
@kniederberger Thanks for providing the boot.img and su.img from the Value edition of the phone, allowing me to base my work around what was done on the value editon.
SM-G389f:
Marshmallow:
*Verified by @Heledir and @kniederberger
A user has uploaded a YouTube video HERE in case anyone wants a video tutorial.
1) Enable "OEM UNLOCK" and "USB Debugging" in developer settings (This can be found by tapping build number 7 times, then developer mode will be activated) then procedded to Flash TWRP.
2) Flash the Value Edition version of TWRP, Link at the top of this thread, making sure it has ".img.tar" extension (Refer to "Using ODIN" if needed).
3) Flash SuperSu.zip inside of TWRP via the Flash Zip section
Update to Newer Firmware while rooted:
Note: You'll lose root (re-root via relevant method) and modifications done to /system, but you're Apps and Data (/data and internal storage) will remain untouched.
0)Although you won't lose any apps/data, it's always recommended to make a backup. Perferrable a Nandroid backup or the backup of apps and data via the means of Titanium Backup and such.
1) Download Newest firmware matching the phones region and carrier (basically if the phone is from one country, dont download the firmware intended for a different country. Links at top of OP/Thread.
2) Out phone into download more, launch Odin and Flash the firmware package Downloaded. (Refer to the Using Odin section as needed.)
3) Give it some time for the inital reboot, and allow it to get setup and booted.
Optional) Re-root via relevant methods.
Un-root Samsung XCover 3 Devices:
1) Click un-root from SuperSu APP
*5.1.1 and 6.0.1: Flash Stock boot.img (Found in stock firmware) (Will post a Link for stock boot.tar.md5 soon, or read on in the next post to figure out how to create your own boot.tar.md5 file)
TWRP:
KitKat: Working
Lollipop: Not Working (I'm looking into it) The is a hacked together version of TWRP HERE, in case people want to flash files. I wouldn't recommend it for anything else other then flashing, as i would perfer to build a proper working TWRP for lollipop.
Note: You'll have to hold, Volume Up + Home + Power buttons straightafter flashing from Odin, keep hold of the key combo untill you see the TWRP logo (2 reboots).
Marshmallow: Working
Flash Stock Firmware:
1) Download the stock firmware from above links, making sure the version and region matches your phone
2) As with the other steps, boot into download mode and connect it to Odin, click the AP button and click on the stock firmware. Then Click Start. (Refer to "Using ODIN" if needed)
3) Give it some time after flashing (Max 10mins) to boot and setup for the first time, if it doesn't after a long time, re-flash the stock firmware again.
FAQ:
- Where is a ROM/Custom Kernel/ TWRP(for lollipop) for our devices? I currently can't provide/make these due to internet limitations, and no access to a 64 bit computer(of course these may change for me in the future). Feel free to build and provide these, and they can get linked to one of the opening pots for easy access.
- What is this thread? It aims to bring all the current work being done on this device into a single thread, so its easily accessible for everyone
- XYZ App doesn't detect root (systemless root)? These apps haven't been updated to work with systemless root, and therefor require SuperSu compatibility mode to be enabled to work with systemless root. Refer to the Troubleshooting section below to fix.
- My Device is sluggish/slow at each boot, how can I fix this? I have noticed that certain apps when used, E.g. CF.Lumen, Livebootetc. require patching the sepolicy at each boot, and this is a memory intensive task. This may not be the only cause for sluggishness, other things can include alot of apps checking for notifcations by pinging their servers, or alot of apps auto starting at boot. There are two different ways about fixing this, one, uninstall offending apps (or disbale their automatic launch), or two, live with it, just wait a couple of minutes after booting before unlocking and using the phone, becuse by then their tasks should be done and android should have cleared up some RAM.
- I keeping getting notifications that my device is unsafe/had unautorized actions have taken place, how to stop this notification/warning? Refer to the Troubleshooting section below to fix.
Troubleshooting:
- XYZ App doesn't detect root (systemless root):
For Value Edition (Android 6.0.1):
1) Type "(or paste)
Code:
echo "BINDSYSTEMXBIN=TRUE" >> /data/.supersu[/CODE
2) Reflash the latest SuperSu.zip via TWRP][/INDENT]
[INDENT][B]For the Normal/Original xCover 3[/B] [I](Android 5.1.1., using my root method)[/I]:
Note: This fix is for the root developed by me, once/if we get a working TWRP for lollipop, then the above instructions should suffice. These 2 scripts creates and mounts a folder to xbin, allowing for apps that check for system root to work properly with systemless. Also daemonsu should mount the folder at boot automatically, but I was having problems with it, so that's why I have a second script to automatically mount the needed folder. Now to the instructions :)
1) Download the "systemless-compatability-fix-lollipop.tar.gz" onto the device and unzip it
2) Using a file explorer that works with systemless root, E.g. Solid Explorer, Copy and paste the 2 files inside the "/su/su.d" directory, making sure it's permissions is "0700" or "700", if the permissions are incorrect you can use the file explorer or terminal emulator and "chmod 0700" on both of the files, Refer to both of the files below for reference.
[img]http://forum.xda-developers.com/attachment.php?attachmentid=3948945&d=1480154633[/img]
[img]http://forum.xda-developers.com/attachment.php?attachmentid=3948946&d=1480154633[/img][/INDENT]
Now all root apps should work (I'm loooking at you Secure Settings and ES File Explorer Pro)
- I keeping getting notifications that my device is unsafe/had unauthorized actions have taken place, how to stop this notification/warning:
I haven't formmaly looked into the cause of this problem as of yet, but some users reported that disabling/removing "SecurityLogAgent" and/or "Smart Manager" Fixs the problem. This can be achieved using Titanium Backup (or similar apps).
[I][B]Planned Work:[/B][/I]
[HIDE]
- Do the next post write up on how to modify the boot.img (or other files) of the devices.
- Get working TWRP on Lollipop
- Get Magisk v9 working
- Look it what is need to flash MM from the xCover 3 Value Edition devices onto the Normal xCover 3 Most users have. (Might be difficult, as they have different hardware)
- Get some ROM creators onto this device [/HIDE]
Anything else?
Development for the xCover3
By Matt07211
This post aims to cover some relevant info for developers, aspiring developers, or tinkers that are missing a crucial piece or knowledge need for it to work on this device (xCover3). This thread will be more bias towards the Original xCover 3 running Lollipop, this just means my knowledge might be lacking in some areas due to differences in hardware (They have different chip-sets)therefor a difference in procedure. This Post assumes your using Linux and is biased towards Ubuntu, as its easiest for anyone to setup.
These post will be split up into categories, and when needed will indicate a difference in procedure between the devices.
Table of Contents:
1) General Setup (Dependices and Tools)
2) Boot and Recovery Modifications
3) System image modification (Also applicable to cache and hidden images found in firmware package)
4) Miscellaneous
Links:
- XCover3:
android_device_samsung_xcover3ltexx(To be added)
platform_manifest (To be added)
local_manifests (To be added)
android_kernel_samsung_xcover3ltexx
proprietary_vendor_samsung(To be added)
- XCover3 Value Edition:
android_device_samsung_xcover3ltexxve(To be added)
platform_manifest (To be added)
local_manifests (To be added)
android_kernel_samsung_xcover3ltexxve(To be added)
proprietary_vendor_samsung(To be added)
- General Setup
# Installing dependices (assuming Ubuntu >=15.04).
A 64-bit Operating system is needed when compiling ROMS, Kernels or Recoverys.
The dependices used are gathered from Android Establishing a Build Enviromentpage and Android Image Repack tools thread.
Code:
sudo apt-get update
sudo apt-get install git git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev libncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip openssl libsdl-dev libesd0-dev valgrind libreadline6-dev x11proto-core-dev libz-dev gawk texinfo automake libtool cvs libsdl-dev
# Create Working Directory
It is also recommended to create a working directory for when working with android, keeping everything centeralized is helpful.
Code:
cd ~
mkdir android
# Compiling Android Image Repack Tools: Android Image Repack Tools is a kit of utilites for unpack/repack of android ext4 and boot images(Useful for working with android).
Refer to the thread linked above on different examples/instructions on using the binary files.
Note: I've provdided a copy of the precompiled binary files, compiled agianst android-5.1.1 branch on a 32-bit machine (meaning compatabile with 64/32 bit machines).
For Marshmallow:
Code:
cd ~/android
git clone https://github.com/ASdev/android_img_repack_tools
cd android_img_repack_tools
git checkout android-6.0.1
chmod +x configure
./configure
make
This creates the directory, downloads the source code, and creates the binary files.
For Lollipop (@AkuHaks version, extra tools included for the SM-G388F):
Code:
cd ~/android
git clone https://github.com/AkuHAK/android_img_repack_tools
cd android_img_repack_tools
chmod +x configure
./configure
make
# mkbootimg_tools, from xiaolu (Use for Value edition)
Code:
cd ~/android
git clone https://github.com/xiaolu/mkbootimg_tools
- Boot and Recovery Modifications
# Unpack boot and recovery
For Marshmallow:
Code:
cd ~/android/mkbootimg_tools
mkdir boot
./mkboot boot.img boot
usage: mkboot
unpack boot.img & decompress ramdisk:
mkboot [output dir]
[/INDENT]
Example output:
[CODE]
dt.img
img_info
kernel
ramdisk
ramdisk.cpio.gz
[/CODE]
For [B]Lollipop[/B]:
[CODE]
cd ~/android/android_img_repack_tools
mkdir boot
./pxa1088-unpackbootimg -i boot.img -o boot -p 2048
[/CODE]
Example output:
[CODE]
boot.img-base
boot.img-cmdline
boot.img-dt
boot.img-pagesize
boot.img-ramdisk.gz
boot.img-ramdisk_offset
boot.img-second
boot.img-second_offset
boot.img-signature
boot.img-tags_offset
boot.img-uImage
boot.img-unknown
[/CODE]
# Repack boot and recovery
For [B]Marshmallow[/B][I](Example, substitute names as necessary)[/I]:
[B]Note:[/B] I have yet to try a repacked boot.img on a Value Edition Variant
[CODE]
cd ~/android/mkbootimg_tools
./mkboot boot boot-new.img
[/CODE]
usage: mkboot
Use the unpacked directory repack boot.img(img_info):[INDENT]
mkboot [unpacked dir] [newbootfile]
[/INDENT]
For [B]Lollipop[/B][I](Example, substitute names as necessary)[/I]:
[CODE]
cd ~/android/android_img_repack_tools
./pxa1088-mkbootimg --kernel boot.img-uImage --ramdisk ramdisk-custom-supersu.cpio.gz --dt boot.img-dt --signature boot.img-signature --unknown 0x3000000 -o ../boot-supersu.img
[/CODE]
usage: mkbootimg [INDENT]
--kernel <filename>
[ --ramdisk <filename> ]
[ --second <2ndbootloader-filename> ]
[ --cmdline <kernel-commandline> ]
[ --board <boardname> ]
[ --base <address> ]
[ --pagesize <pagesize> ]
[ --dt <filename> ]
[ --ramdisk_offset <address> ]
[ --second_offset <address> ]
[ --tags_offset <address> ]
[ --id ]
[ --signature <filename> ]
-o|--output <filename>
[/INDENT]
# Ramdisk Unpack/Repack
Unpack
[CODE]
mkdir ramdisk
cd ramdisk
gunzip -c ../ramdisk.cpio.gz | cpio -i
[/CODE]
Repack
For [B]Marshmallow[/B]:
[B]Note:[/B] I have yet to repack the Value-edition/Marshmallow ramdisk so cannot verify it works (unlike lollipop), so if any errors please contact me. Feel free to try and unpack/repack the Value editon ramdisk/boot.img with lollipop instructions, if below doesn't work.
[CODE]
find . | cpio -o -H -R 0.0 newc | gzip > ../ramdisk-new.cpio.gz
[/CODE]
For [B]Lollipop[/B]:
[CODE]
./mkbootfs ramdisk-directory-name | ./minigzip > ramdisk-new.cpio.gz
[/CODE]
# Compile Kernel
Assumes kernel source is like "~/android/kernel" adapt paths as necessary.
For [B]Marshmallow[/B]:
[CODE]
cd ~/android
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9
export CROSS_COMPILE=~/android/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-
cd kernel
make ARCH=arm xcover3velte_eur_defconfig
# You can run "make menuconfig" now if you want to customize the config file. E.g. Adding driver support, enable other features etc.
make ARCH=arm -j<number-of-cpus>
# E.g. "make ARCH=arm -j4"
[/CODE]
[B]Note:[/B] Replace the "<number-of-cpus>" in "-j<number-of-cpus>" with the number of processors you have plus one. For example if you have 4 cores then enter 5. If your getting errors then rebuild it with "-j1" then scroll up till you found the source of the error.
If the compile succeded the you should see "kernel: arch/arm/boot/zImage is ready"
For [B]Lollipop[/B]:
[CODE]
cd ~/android
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.8
export CROSS_COMPILE=~/android/aarch64-linux-android-4.8/bin/aarch64-linux-android-
cd kernel
make ARCH=arm64 pxa1908_xcover3lte_eur_defconfig
# You can run "make menuconfig" now if you want to customize the config file. E.g. Adding driver support, enable other features etc.
make ARCH=arm64 -j<number-of-cpus>
# E.g. "make ARCH=arm64 -j4"
[/CODE]
[B]Note:[/B] Replace the "<number-of-cpus>" in "-j<number-of-cpus>" with the number of processors you have plus one. For example if you have 4 cores then enter 5. If your getting errors then rebuild it with "-j1" then scroll up till you found the source of the error.
If the compile succeded the you should see "kernel: arch/arm64/boot/Image.gz is ready"
# Package Kernel into uImage (SM-G388F ONLY)
[CODE]
mkimage -A arm64 -O linux -T kernel -C gzip -a 01000000 -e 01000000 -d Image.gz -n "pxa1928dkb linux" "boot.img-uImage.new"
[/CODE]
# Generate kernel Specific device tree table (From Kernel Sources, Post-Compile)
[B]NOTE:[/B] This shouldn't need to be done as stock dt.img is the same, so use that. This is only here for educational purposes.
This assumes ~/android/kernel/ is you kernel source code directory. Substite paths as neccessary
For [B]Marshmallow[/B]:
Place either dtbTool or dtbToolCM (Depending on what your using), into ~/android/kernel/scripts and run the binary files from there.
If unable to create use the below binarys then try the lollipop instructions.
dtbTool
[CODE]
cp ~/android/mkbootimg_tools/dtbTool ~/android/kernel/scripts
cd ~/android/kernel
scripts/dtbTool -s 2048 -o arch/arm/boot/dt.img -p scripts/dtc/ arch/arm/boot/
[/CODE]
usage: DTB combiner:
Output file must be specified
dtbTool [options] -o <output file> <input DTB path>
options:
--output-file/-o output file
--dtc-path/-p path to dtc
--page-size/-s page size in bytes
--verbose/-v verbose
--help/-h this help screen
OR
dtbToolCM (support dt-tag & dtb v2/3)
[CODE]
cp ~/android/mkbootimg_tools/dtbTool ~/android/kernel/scripts
cd ~/android/kernel
scripts/dtbToolCM -s 2048 -d "htc,project-id = <" -o arch/arm/boot/dt.img -p scripts/dtc/ arch/arm/boot/
[/CODE]
For [B]Lollipop[/B]:
[CODE]
cd ~/android/android_img_repack_tools
./pxa1088-dtbTool -o boot.img-dt-new -p kernel/scripts/dtc kernel/arch/arm64/boot/dts/
[/CODE]
# Repack as Flashable Odin File (Substitute name as neccessary)
tar -H ustar -c boot.img > boot.tar
md5sum -t boot.tar >> boot.tar
mv boot.tar boot.tar.md5
[/CODE]
[/HIDE]
- System image modifcation
[HIDE]
<To be ADDED>
[/HIDE]
- Miscellaneous
[HIDE]
<To be ADDED>
[/HIDE]
Kernels:
- MyKernel - Custom power kernel series ! (SM-G389f) (Originally called: Devhost97 Kernel's ....) @Devhost97
-DiXCOVERy kernel (SM-G388f) @IXgnas
Roms:
- Flint & Steel ROM (Modded Firmware), planned realse is hopefully at beginning of next year. Follow its progress at the post HERE . Creator is @Matt07211 (Me)
Recommended Mods:
- Xposed using wanam's framework (Lollipop & Marshmallow),HERE, and use the newest XposedInstaller apk from, HERE. Flash the framework via TWRP.
- Arise Sound Mod, HERE. Flash via TWRP.
Recommend Root Apps, by Matt07211:
- Liveboot
- CF.Lumen
- Titanium Backup
- Adaway
- Kernel Auditor
- Terminal Emulator
Recommend Xposed Apps, by Matt07211
- <To be added>
Miscellaneous:
- Debloater Thread by @Sonof8Bits
<Reserved for Future Use>
<Reserved for Future Use>
Problem
Matt07211 said:
Preface: I'm currently using this device and really like it, and as you all may have realised, that this device is considered as a low activity device on XDA, and know developers I know of have taken a crack at this phone. This is where I come in, I like hacking into stuff for the challenge it presents, and I have set myself the challenge that is this device. This is a continuous learning experience for me and all, so I am by far not considered an expert.
If some area are empty, they will have more content in the future as we progress with this awesome device.
Feel free to post any mods that have worked (preferably in systemless mode)
Table of Contents:
Post 1) Root and TWRP
Post 2) Mods (Mostly Systemless versions)
Post 3) Roms
Post 4) --Reserved for future use--
Useful Links:
My Github (Matt07211) to keep with the GPL licences I will upload evrything onto my github (Also its a shameless plug )
My Github Pages Blog for guide on how I manually applied systemless update to boot.img (To be linked)
Samsung Kernel Source Code 4.4.4/5.1.1 and 6.0.1
Firmware Samsung xCover 3 and Samsung xCover 3 Value Edition
TWRP
SuperSU
Prerequisites:
ADB Installed
USB Debugging Enabled
Samsung USB Drivers Installed
Samsung ODIN
A Brain that can use common sense or google
Disclaimer:
Anything you do with your own phone is done at your own risk. Don't complain if accidentally brick your phone, use google, flash back stock firmware or post on XDA for help.
Knox will probably be voided, and so will your warranty.
We cannot say what works for use may work for you.
Good luck
Root:
KitKat:
1) Download the Newest TWRP from the above links, making sure you download the file with the .img.tar extension
2) Download the Newest SuperSu and place on the internal phone memory
3) Turn on USB Debugging
4) Turn phone off, boot into download mode (Power + Volume Down + Home) and then press Volume Up for use when greeted with a yellow warning.
5) Launch ODIN, and plug phone into Computer. You should see some text like this "ID:COM" in green
6) Click the AP button and Select the Downloaded TWRP file, make sure "re-partition" is unticked. Click Start
7) Once flashed, reboot into recovery and Flash SuperSu.zip
Congrats you got root on KitKat
Lollipop (Systemless Root) (EXPERIMENTAL, USE WITH CAUTION):
NOTE: This is currently in the experimental phase as I need users to test and verify that this works
1) Turn on USB Debugging and Download "xCover3-Lollipop-Root-Matt07211.zip" from here.
2) Turn phone off, boot into download mode (Power + Volume Down + Home) and then press Volume Up for use when greeted with a yellow warning.
5) Launch ODIN, and plug phone into Computer. You should see some text like this "ID:COM" in green
6) Click the AP button and Select the Downloaded ".tar.md5, make sure "re-partition" is unticked. Click Start
7) Once flashed, reboot the phone normally, making sure USB Debugging is turned on
8) Copy over "su.img", "Superuser.apk" and "xCover3-root.bat" (For Windows Users) or "xCover3-root.sh" (For Linux Users) into your ADB directory (E.g. android-sdk\platform-tools)
9) Open up a command prompt in the ADB Directory and type either "xCover-root.bat" for windows and for Linux run "xCover-root.sh"
10) Your Device should reboot, and you should have root. Now get an app and verify its existence
NOTE: This is EXPERIMENTAL so this might not work, or will take a few trys to get working, please post if this has worked for you.
Marshmallow:
*To Be looked into, please be patient
Un-root Lollipop and Marshmallow Devices:
1) Click un-root from SuperSu APP
2) Flash Stock Firmware or Stock boot.img (Will post a Link for stock boot.tar.md5 soon)
TWRP:
KitKat: Working
Lollipop: Not Working (I'm looking into it)
Marshmallow: Not Working (I'm looking into it)
Flash Stock Firmware:
1) Download the stock firmware from above links, making sure the version matches your phone
2) As with the other steps, boot into download mode and connect it to Odin, click the AP button and click on the stockfirmware. Then Click Start
3) Give it some time (Max 10mins) to boot and setup for the first time, if it doesn't after a long time, reflash the stockfirmware again.
Now look at the next post
Click to expand...
Click to collapse
When I click on AP in Odin and choose boot_systemless_root_matt07211.tar.md5 ,it just says md5 error binary is invalid. (tested on ODIN 3.12.3 and 3.10)
Oh sorry you said its not working nvm
EzChillzz said:
When I click on AP in Odin and choose boot_systemless_root_matt07211.tar.md5 ,it just says md5 error binary is invalid. (tested on ODIN 3.12.3 and 3.10)
Oh sorry you said its not working nvm
Click to expand...
Click to collapse
I tryed the root for Lollipop. Odin will no flash the tar.md5. There is one mistake by md5. If you rename the file to *.tar odin accept the file. if try to flash odin hang of with outprint analyse file. i wait on this for 10 min nothing goes happen.
I can try to flash with heimdall. for this i need the *img file
sorry for my bad english
EzChillzz said:
When I click on AP in Odin and choose boot_systemless_root_matt07211.tar.md5 ,it just says md5 error binary is invalid. (tested on ODIN 3.12.3 and 3.10)
Oh sorry you said its not working nvm
Click to expand...
Click to collapse
yy1 said:
I tryed the root for Lollipop. Odin will no flash the tar.md5. There is one mistake by md5. If you rename the file to *.tar odin accept the file. if try to flash odin hang of with outprint analyse file. i wait on this for 10 min nothing goes happen.
I can try to flash with heimdall. for this i need the *img file
sorry for my bad english
Click to expand...
Click to collapse
Well I'm stupid when I created it I was pretty tired, so I only included the md5 hash of the .tar file but not the .tar file itself as @yy1 has stated, it should be reuploaded in a couple of minutes. It should all work then, and now you have the file to flash and an md5 hash to compare it to make sure it isn't courrupt. Good luck and please report back to me of it was succesful @yy1 and @EzChillzz
Try to flash your boot.img. Reboot stop with KERNEL IS NOT SEANDROID ENFORCING (Android 5.1.1.)
yy1 said:
Try to flash your boot.img. Reboot stop with KERNEL IS NOT SEANDROID ENFORCING (Android 5.1.1.)
Click to expand...
Click to collapse
The question is does it boot up? If so then that message can be ignored, if not then I will look into it. Just flash original boot.img or firmware to go back to a useable phone. Thanks for testing
Did you get a message with both these sentences in or just the first sentence"KERNEL IS NOT SEANDROID ENFORCING. Custom binary blocked by FRP Lock" ???
It doesn't boot up. Black screnn with boot logo and red warning on top. i flash the original boot.img anything okay.
what means fap lock?
yy1 said:
It doesn't boot up. Black screnn with boot logo and red warning on top. i flash the original boot.img anything okay.
what means fap lock?
Click to expand...
Click to collapse
Was ment to FRP not FAP, autocorrect strikes again. FRP = Factory Rest Protection.Google it if you want more info, basically another barrier to stop thieves. As I reading up on this user's are stating (in a sepolicy patch thread) that when flashing boot.img via odin their phone wouldn't boot up, but said flashing bootmimg via TWRP works.
Questions:
1) When you flash the custom boot.img, does it freeze and nothing happens? Or does it reboot automatically?
2) are you using heimdall or Odin?
Tasks:
1) Flash the boot.img via Heimdall (if you've been using odin) and report back if it was a succes.
2) if possible, if adb is running, can you pull the dmesg off the device before restoring the original boot.img as this will help in debugging this problem.
E.G. "G:\" is the hard drive plugged into my computer, adjust as necessary.
Code:
adb shell dmesg >> G:\dmesg.txt
3) ALSO TRY, after you flash the custom boot.img can you try booting into recovery (Volume Up + Home + Power Button) and try wiping cache before trying to properly boot the phone. Maybe you could also when in recovery tell me what the log files say? @yy1
Still currently searching what is blocking the custom boot.img from booting the phone.
I really appreciate the help
Flash your boot.img via heimdall once again. with no reboot option. go to recovery and wipe cache. after start the phone boot anytime in recovery. flash via heimdall original boot img anyhing okay.
adb not work. there are logfiles in recovery but i don't know they way to put that from phone to pc. Sorry for that.
yy1 said:
Flash your boot.img via heimdall once again. with no reboot option. go to recovery and wipe cache. after start the phone boot anytime in recovery. flash via heimdall original boot img anyhing okay.
adb not work. there are logfiles in recovery but i don't know they way to put that from phone to pc. Sorry for that.
Click to expand...
Click to collapse
I won't be able to look into it today as i have important stuff happening. Will post back later with some more info, sorry about the wait then. Thanks for the help
===================================
Can you try this, as it will greatly help in diagnosing the problem.
Flash the custom boot.img, don't boot the phone yet. Then can you run
Code:
adb start-server
In a terminal/command prompt, then turn on the phone with the adb dmesg command from the previous post already in the terminal for you to hit enter when needed.
Turn on the phone now, and hit enter to run the above command before the phone stops and reboots itself.
Thanks.
Edit 2: When devloping the boot.img, I had to use chainfires supolicy binary to patch the sepolicy in boot.img, with one of it tasks is to patch the recovery from enforcing to permissive mode.
So in an educated geuss, and with information in other forms (user reported that they are unable to flash a custom boot.img via odin but able to via TWRP), that we may be able to flash the boot.img via recovery. See instructions for testing this below.
1) Download both the 3.0.2-1 and 2.0.8-* version of twrp (.img.tar) as we should try both of them <Linked in original post>
2) Flash my custom boot.img and then the twrp files with auto reboot turned off
3) once they both flash, boot into recovery (give it 5-10 mins, if nothig happens then it didn't work)
4) if it actually worked and booted into recovery, flash the custom boot.img in TWRP and try rebooting normally
5) If it managed to get this far, then continue from my original post by tuning either the root script/bat file
Please Report how far you got in this process or if it worked.
===================================
I am currently trying different versions of my boot.img, will post once I have it working properly
No way for me to give you adb log-file, because adb find no device if phone in download- or recovery-mode.
try the second way. Flash boot.img and recovery.img (TWRP) start the phone in recovery-mode. red warning on top RECOVERY IS NOT SEANDROID ENFORCING.
wait 5 minutes phone starts automatic in normal-mode.
yy1 said:
No way for me to give you adb log-file, because adb find no device if phone in download- or recovery-mode.
try the second way. Flash boot.img and recovery.img (TWRP) start the phone in recovery-mode. red warning on top RECOVERY IS NOT SEANDROID ENFORCING.
wait 5 minutes phone starts automatic in normal-mode.
Click to expand...
Click to collapse
Yea thanks for that, I had been trying a bunch of combinations yesterday with none of them working. And when trying to find what blocks custom boot.img from booting up, all I come across is stuff staying to flash back stock firmware, but nothing for the reasons why.
But I have some stuff to look in to and will replie back when done (if I'm succesful or not)
These include:
- looking more into pains secure download mode and what it does
- having a go with exploiting a bug that had happend with stock recovery. Running 4.0 (we are not running this version of android) and recovery version 3e(our stock recovery version ) where you could flash updates.zip signed with testkeys instead of the manufacturers keys
- OR try getting TWRP to run on lollipop (probably have to rebuild it) this leaves us with two options in twrp. 1) Flash SuperSu and get system install (probably won't be able to unpack the boot.img) or then flash my customized boot.img for the Systemless version of root.
Either way it may be a little while before lolipop root is working.
I have important exams coming up so this project is gonna have to be out onto the backburner for about 4 weeks or so, meaning I won't be putting much effort into this for a while, but will continue it after the exams. @yy1
- '
@yy1 I belive I have found out why the phone won't boot when using the custom boot.img
I belive it has to do with the unpacking/repacking of the ramdisk.cpio.gz file. When ever I try to boot an image with a repacked ramdisk the phone won't boot.
I know that the phone can boot custom boot.img 's as I removed the word "SEANDORID" from the original and flashed it to my phone. My phone booted up, even when the red text (KERNEL IS NOT SEANDROID ENFORCING) was shown at the top of my phone.
So once I got it got it booting I will post back here.
My previous post, was somewhat on par. What I mean by this is yes, the ramdisk was a reason why it was not boot, but not for any reasons like permissions, ownership or the like, it was in fact that when unpacking and repacking the cpio archive increase the size, and from what I have reduced from my trial and errors is when the boot.img size is changed by even one byte in size it won't boot. But you are able to modify its contents with a hex editor, E.G. Zeroing out the word SEANDROIDENFORCING at the bottom of the raw image file, would still let the phone boot fully with the text show "KERNEL is not SEANDROIDENFORCING" and it showing up as a custom binary in Download more. I belive it may be becuse of some outside security verifying the boot.img. maybe download mode (it's in secure mode, haven't looked into it yet) or some script, I am not sure. And its all most impossible to get any errors logs or dmesg via adb or otherwise, with my only way to read them is via stock recovery, which is a bit impractical and inelegant reading as it speeds past lines you want to read when trying to scroll down (if anyone knows how to pull these logs from cache without a custom recovery or root, please tell me.
Now when I try to replace the ramdisk in boot.img via hex editor the size increase and thus unable to boot. When I try to repack it with various versions of mkbootimg, including Google's python script, other bi nary compiled versions of it by various people and mkbootimg's binary modified to also with with Device Tree Files which get appended onto the boot.img. I have analysed and reverse enginered the boot.img file, and analyzed the other files included with the stock firmware downloadable from sites like sammobile, sam-firmware etc.
I will be updating one of the is original post with all the information that I have uncovered, I'm great detail and when my internet situation allows (my mobile data is running low, lol), upload the reversed enginered files of boot.img for anyone else to inspect and have a crack at creating their own custom kernel/boot.img.
TL;DR: Uploading detailed information and reverse enginered files of boot.img. Any of my custom boot.img's won't boot if the size changes at the minimum one byte from the original boot.img, but the phone can boot a custom version if the size of the file size deos not change a single byte.
Hi;
TWRP is ready for SM-G389F :
https://twrp.me/devices/samsunggalaxyxcover3ve.html
Heledir said:
Hi;
TWRP is ready for SM-G389F :
https://twrp.me/devices/samsunggalaxyxcover3ve.html
Click to expand...
Click to collapse
This currently only works for Kit Kat, after I unpacked it I read the files at it was aimed at android 4.4.4. I am, after I have my exams in the next few weeks I am gonna try and get TWRP working on lollipop (after I got root )
Software for Samsung Galaxy Xcover 3 VE (SM-G389F) is Android 6.0, so I think it's for MM. The links:
- Device Tree / files
https://github.com/TeamWin/android_device_samsung_xcover3velte
Say its Android 6.0 branch.
I've install it yesterday with Odin and it works fine on my SM-G389F.
But i haven't find root for SM-G389F and MM.