Related
THIS IS NOW OUTDATED!!
It uses the old sqsh method WITH a rootfs. So if you're using the NoMoRootfs method, this won't work. Please use the already complete builds in the Kaiser/Vogue threads as they are working the best at this moment.
DISCLAIMER:
I take no responsibility for anything that may happen to your phone/computer. Use at your own risk.
PURPOSE:
This is for informational/testing purposes. And for people to stop asking, "can somebody port X rom!!! PLZ!!!"
PREFACE:
I made this as a quick tool to port ROMs from the Dream/Sapphire forums to work with our phones. It's a very quick and dirty script I threw together using bash, so there's probably some problems with it. This tool is simply designed to make a copy of the Dream/Sapphire ROM. Once you get the setup, it's really easy and you'll be porting like crazy.
I did this all on Ubuntu 9.10 so things might not work properly if you're using another distro.
THANKS:
All credit goes to the people that made this possible, in no particular order...
dzo, vilord, mssmison, zen, enatefox, pmos, jamezelle, craig0r, cyanogen, and so many more. If I forgot you, I'm sorry, but you know if you helped in some way.
THE SETUP:
1) Download this file
2) Extract the folder to your desktop. Then copy and paste the following code into the terminal:
Code:
sudo mv -f $HOME/Desktop/Android/genext2fs /bin/genext2fs; sudo chmod 755 /bin/genext2fs; sudo dpkg -P squashfs-tools; sudo dpkg -i $HOME/Desktop/Android/squashfs-tools_3.3-7_i386.deb; sudo rm -r $HOME/Desktop/Android/squashfs-tools_3.3-7_i386.deb; sudo chmod 777 $HOME/Desktop/Android/*.build.script
3) Now go into synaptic package manager, search for squashfs-tools, select it and under Package, check Lock Version so that way it won't try to update.
4) Now cruise over to the Dream android development forum or the Sapphire android development forum and download the ROM you would like to port. Place the zip file in the Android folder. (no need to rename)
5) Place any .apk's you would like built into the system in the Apps folder.
ADVANCED SETUP:
If you would like to tweak the system before building, open the script in a text editor and you'll find a line to uncomment that will halt the script until you are ready.
HOW TO RUN:
Either run the script from a terminal
Code:
./$HOME/Desktop/Android/HERO.build.script
or
./$HOME/Desktop/Android/Donut.Build.script
Or double click and Run in Terminal
You will get a prompt for your password to use the sudo command. THIS IS NOT SAVED ANYWHERE OR MAGICALLY SENT TO ME. It is just to get the system.sqsh setup for you to use.
You will now see a Donut/Hero folder inside the Android folder. Inside that will be a nice little system.sqsh with the date ready to boot!
*Rename to system.sqsh when you put on your SD card*
Grab the latest basefiles from vogue-android and you're good to go.
~~~~~~ To get an output of what's happening run in a terminal as described above but add " > build.txt" and you'll see a txt file in the Android folder. ~~~~~~~
CHANGING SYSTEMS:
If you want to port a new rom, replace the .zip.
UPDATES:
1) Download the updates from HERE
2) Extract to the Android folder overwriting if necessary.
3) Copy and paste the following code into a terminal:
Code:
sudo chmod 777 $HOME/Desktop/Android/*.script
CLEANUP:
If you follow the advanced setup and/or accidentally closed the terminal before the build finishes, run the cleanup script. This will unmount everything that might be mounted and delete all folders that are made during the process.
DOWNLOADS:
If you're too lazy or just want a quick link:
Main "Android porting" folder
Updates
Input, testers, bugs, and tweaks to the scripts are appreciated!
FAQ:
Why does my system.sqsh not work?
Most likely cause is that you're not using the correct version of squashfs-tools. You'll have to find version 3.X for the distro you're using. Version 4.X will NOT work!!!
When I try to boot a system.sqsh I just made I keep getting something about android power wake locks. WTF?
You're probably trying to port an eclair or cyan ROM. These don't work at the current state. Hopefully soon I'll get these working.
Will update more when they arise.
CHANGELOG:
11-27-09:
-Created a cleanup script in case the terminal is closed during the build process.
-Bug fixes in Donut and Hero scripts
11-24-09:
-Added an Apps folder for apk's you want built into the system.
-Bug fixes in scripts
11-22-09:
-Combined everything needed into a zip file
-WAY easier to setup
11-20-09:
-Added feedback to make more user friendly
-Append time to system.sqsh
loserskater said:
Input, testers, bugs, and tweaks to the scripts are appreciated!
Click to expand...
Click to collapse
Will try today... Downloading
Tried and working. Had to change the script for it work with ubuntu version that i use. Thanks this is really great
garynsa said:
Will try today... Downloading
Tried and working. Had to change the script for it work with ubuntu version that i use. Thanks this is really great
Click to expand...
Click to collapse
What did you change?
Glad to see it's working.
loserskater said:
What did you change?
Glad to see it's working.
Click to expand...
Click to collapse
hI
For some reason I cannot use -a in the genext2fs command. Had to remove that..
One of the Donut is working. Couldnt get the Cyanogen build working . Struggling with hero build also.
Will try again in the next couple of days and post results.
Thanks
garynsa said:
hI
For some reason I cannot use -a in the genext2fs command. Had to remove that..
One of the Donut is working. Couldnt get the Cyanogen build working . Struggling with hero build also.
Will try again in the next couple of days and post results.
Thanks
Click to expand...
Click to collapse
Make sure you use the genext2fs that I referenced.
That one works with -a and might take care of some issues. try that and see if it works.
Updated script to now move system to a Hero or Donut folder.
Working on the cyanogen build now...
EDIT: Here's a cyanogen script that gets it to boot, but sits at a black screen. I haven't had much time to test it so it might boot further than that if you leave it. If somebody wants to test this out or tweak it in some way go for it.
It uses the donut.sqsh in the Android folder so you shouldn't have to do anything with it except make it executable.
EDIT 2: Still working on cyan builds... that script didn't work.
great job i like to see stuff like this to motivate people!!! also note this will work with any donut or hero build from the sapphire forum
jamezelle said:
great job i like to see stuff like this to motivate people!!! also note this will work with any donut or hero build from the sapphire forum
Click to expand...
Click to collapse
Good point, forgot to mention that. Updated first post.
I'm hoping it will help people start to learn to tweak system's. But I have a slight feeling wer're going to start seeing a lot of "MLIGN/DWANG/etc's Android Rom" threads from random people.
Hi
Was able to port the DWANGs build using your script. Thanks a lot for making life this simple. Howev3er, hero build is still not working. Tried your genesxt2fs. Is it possible to get the links to correct base hero version to use? I tried magic and normal version. It keeps giving me black screen and doesnt completely boot. I think the base hero version is not the right one i am using
Thanks
OK, I think I figured out the problem. The apps folders weren't copying over from the data folder to the system folder correctly. Testing now, and will update first post with new scripts.
EDIT: Finally got the Hero builds working correctly. You should still be able to use any hero.sqsh.
loserskater said:
OK, I think I figured out the problem. The apps folders weren't copying over from the data folder to the system folder correctly. Testing now, and will update first post with new scripts.
EDIT: Finally got the Hero builds working correctly. You should still be able to use any hero.sqsh.
Click to expand...
Click to collapse
Hi
The new script is great.. I was able to get the hero to boot I still have 2 check a few thing willl post later in the night with more
Thanks a lot
garynsa said:
Hi
The new script is great.. I was able to get the hero to boot I still have 2 check a few thing willl post later in the night with more
Thanks a lot
Click to expand...
Click to collapse
Glad to see its working. Thanks for the feedback!
Most things working
Hi
was able to get the hero ported and a few things worked
1. Calls
2. SMS
3. Wifi (getting ips)
4. Working with partition rootfs (speed quite great with this)
Not working
1. Camera
2. GPS
I am using he ION build to build the hero roms (based on the inputs of Zen). May be I need to use another hero rom for the camera to work? I recommend that the links to the recommended build to be used as template (donut, hero...) be updated on the first thread to make it easy for others to have a single starting platform
garynsa said:
Hi
was able to get the hero ported and a few things worked
1. Calls
2. SMS
3. Wifi (getting ips)
4. Working with partition rootfs (speed quite great with this)
using u
Not working
1. Camera
2. GPS
I am using he ION build to build the hero roms (based on the inputs of Zen). May be I need to use another hero rom for the camera to work? I recommend that the links to the recommended build to be used as template (donut, hero...) be updated on the first thread to make it easy for others to have a single starting platform
Click to expand...
Click to collapse
If using a hero.sqsh doesnt fix the problem it sounds like it might be the rootfs (probably not copying over correctly). Ill take a look at it when I get home and update the first post with hero/donut.sqsh's.
Im also thinking about combing the 2 into just one script and youll be able to just type which build you want when you run it. What do you think? Or is the 2 seperate scripts more convenient?
loserskater said:
If using a hero.sqsh doesnt fix the problem it sounds like it might be the rootfs (probably not copying over correctly). Ill take a look at it when I get home and update the first post with hero/donut.sqsh's.
Im also thinking about combing the 2 into just one script and youll be able to just type which build you want when you run it. What do you think? Or is the 2 seperate scripts more convenient?
Click to expand...
Click to collapse
Personally i prefer the separate scripts mainly because each requires a different base templates. However if you prefer to combine them may be have sub-folders within the main so that the work happen for each port within the sub-folder.
Few suggestions if you like (please ignore if not correct.. being a non-programmer of linux I can be a bit off )
1. Let the folder names be requested at start and use them
2. If possible to put in a log of the run to check if there were issue or not (because i use double-click to run the script sometimes there is a problem that i face if i dont watch the window. for now i have put some waits to check the errors. Had this issue while testing to port one)
If I can help (except on coding as I dont know it.. generally change the script just enough to work... )
Queries/questions
1. Is there a way to test the build on the comp itslef rather than to keep booting on the phone (takes a lot of time and the phone is not usable all that time...)
Thanks for all the work
garynsa said:
Personally i prefer the separate scripts mainly because each requires a different base templates. However if you prefer to combine them may be have sub-folders within the main so that the work happen for each port within the sub-folder.
Few suggestions if you like (please ignore if not correct.. being a non-programmer of linux I can be a bit off )
1. Let the folder names be requested at start and use them
2. If possible to put in a log of the run to check if there were issue or not (because i use double-click to run the script sometimes there is a problem that i face if i dont watch the window. for now i have put some waits to check the errors. Had this issue while testing to port one)
If I can help (except on coding as I dont know it.. generally change the script just enough to work... )
Queries/questions
1. Is there a way to test the build on the comp itslef rather than to keep booting on the phone (takes a lot of time and the phone is not usable all that time...)
Thanks for all the work
Click to expand...
Click to collapse
I'll try to make the script more user friendly with prompts if something doesn't happen correctly. And also work on naming folders.
But first I want to figure out the camera/gps issues...
There isn't a way to boot it on the comp that I know of. I'll upload blank data.img's for each build so that they'll boot faster but other than that I think moving to SD Card and booting is the only way. But once all these bugs get sorted out, you won't have to do it as often!
EDIT: Which folders would you like to name? Just where the system.sqsh gets stored?
loserskater said:
I'll try to make the script more user friendly with prompts if something doesn't happen correctly. And also work on naming folders.
But first I want to figure out the camera/gps issues...
There isn't a way to boot it on the comp that I know of. I'll upload blank data.img's for each build so that they'll boot faster but other than that I think moving to SD Card and booting is the only way. But once all these bugs get sorted out, you won't have to do it as often!
EDIT: Which folders would you like to name? Just where the system.sqsh gets stored?
Click to expand...
Click to collapse
Hi
Thanks for the answers. For me it should be both (but the starting folder is main. Other can be a sub-folder like u have now to be renamed as choice)
garynsa said:
Hi
Thanks for the answers. For me it should be both (but the starting folder is main. Other can be a sub-folder like u have now to be renamed as choice)
Click to expand...
Click to collapse
Are you referring to the Android folder? Or just a folder where everything is kept when it runs?
loserskater said:
Are you referring to the Android folder? Or just a folder where everything is kept when it runs?
Click to expand...
Click to collapse
Android folder... but its not a big deal as one can easily change it while startign the script
I take no responsibility if you brick your Vogue
Right now I thought that I should put something like this up so that my fellow Linux users can flash their Vogues without having to try and resort to using WINE or installing Windows, like I tried and failed
For this guide I am using Ubuntu Maverick Meerkat 10.10 so if things differ from your setup then I apologise.
Right on to the guide at hand.
1) Go to the following link and download HTCFlasher: Link
Now the it is a .deb file type so if you aren't using a Debain based Linux Distro then you can get the source code here and compile it from there
2) Now you also need the following file to get HTCFlasher to work properly: Link. Again this is a .deb file and I don't know if you can get the source for it or not but oh well.
3) Right, now that you have those two files you can now install them so to do this you need to go and launch the Terminal and do the following
Code:
cd Downloads (I'm assuming here that this is your default download directory)
sudo dpkg -i htcflasher_20080806-1_i386.deb
once you've done that enter your root password - you won't have to do it again
now for the gtkdialog - again do the same as above but with the gtkdialog
Code:
sudo dpkg -i gtkdialog_0.7.20-4_i386.deb
Right now after all that is all installed HTCFlasher will be able to be used properly now. Now on to the fun part, flashing your chosen ROM.
For this part I used NFSFAN's WM6.5 Custom ROM although you can use whatever ROM you want.
1) so once you have your ROM all nicely downloaded and un-RAR'd you need to to into Applications -> Accessories -> HTCFlasher
2) click on the little circle next to the option that says "Get Device Info", plug your Vogue in and click ok. Once it's done it's thing a new window will popup, close out of it and next to the Get Device info line will be soomething similar to this
Code:
CID : [TELNZ001] - ModelID: [VOGU001]
3) Put your phone into bootloader mode by pressing and holding the power+camera button while pushing in the soft reset button with your stylus. This can be awkward to hold but just find your own way to get it done.
4) Now click on the "Flash NBH file" little circle and click ok. Navigate your way to where you extracted your rom, double click it and a little message will pop up saying flash file '/home/user name/Downloads/RUU_signed.nbh'?
Click ok and let it rip. Should only take a couple of minutes. Once the ROM has been flashed click ok on the popup and then you are back to the main HTCFlasher menu do the next step BUT MAKE SURE YOUR VOGUE IS STILL PLUGGED IN!
5) Right so you are back to the main menu, click on the little circle next to Bootloader cmd prompt and click ok. MAKE SURE YOUR VOGUE IS STILL PLUGGED IN OR THIS WILL NOT WORK!
6) Once the Cmd Prompt has opened which is basically instantly type the following code. Please note that when I write {enter} you press the enter key.
Code:
set 16 0 {enter}
task 3 {enter}
Now soft reset your phone and VIOLA!! You have just flashed your Vogue on Linux Give yourself a pat on the back and enjoy your shiney new ROM!
A big thanks goes to mrkite38 who gave me that last bit of code. Without his help my Vogue would still be in bootloader mode
Could a mod please sticky this for me? Just as a reference for othe Linux users
Thanks a lot
Thanks for this info about flashing with Linux.
I had a struggle with finding gtkdialog couldn't be found in 10.10 repos.
But after using your gtkdialog link, everything worked out fine.
Many thanks for that.
Yeah I had heaps of problems trying to kind the gtkdiag files needed as well until I used the magic that is Google haha, took about 30 mins of searching until I found that particular version that worked though.
Glad that it helped you out
Ooh... nice addition. I always get questions about flashing from Linux, but I have no knowledge on the matter...
Thanks for putting this together..
Stuck.
egzthunder1 said:
Ooh... nice addition. I always get questions about flashing from Linux, but I have no knowledge on the matter...
Thanks for putting this together..
Stuck.
Click to expand...
Click to collapse
Yay!! Thanks egzthunder1!!!
Once I figure out how to use Linux ROM Kitchen I'll do another write up for that but at the moment I'm content using NuAngels NuVogue instead of cooking my own ROM
So, I decided to write this guide here as I couldn't find a complete one and had to jump from thread to thread (and sometimes even the sub-forum) for finding the answer.
First I wrote it in my blog and I decided to post it here. Maybe some steps are vague in details but I'm planning to detail it even more (remember, I wrote it in my personal blog first). So, here it is:
AIO LG Optimus Me P350 Guide
Some Personal History
My experience with Android. UF! Where to start? So, I got my phone from the United States. You have no idea how wonderful it was to have the phone in my hands. Anxiety and curiosity. For some reason I always read that the first thing anyone does is root the phone and then continue doing everyday activities that do not require root, so I tried to live without rooting the phone, but I couldn’t wait for the week to go by. I had to get the best! Small problems, fixes and updates. And since I have my phone on sale, I publish this step by step guide to modify it and not die trying.
Tech Specs
Let’s start from the beginning, know the phone. Mid/low-range phone created by LG for those in a short budget but want to have a good Android experience. It has a 600 MHz processor, 256 MB RAM and ROM capacity of 512 (140 MB available for applications and data). 2.8 inch capacitive screen, 240 × 320 screen resolution. Wi-Fi b/g wireless connection, Bluetooth 2.1 with EDR, and USB 2.0 up to 480 Mbit/s. 3.1 MP camera (no flash) and FM Radio. Not bad for a basic device. Complete specifications can be found here. Enough for a casual user. But if you’re not a casual user (hence a XDA member), read on.
First of all, everything you do on the phone number is on your own. You yourself are responsible for what you do, not do, stop doing, fail, fail to read and/or shortcut you may have taken. These steps are the ones that worked for me. I am not responsible if the phone dies in the process, the cat bites the cable in the middle process, the heavens begins to fall, the 3rd world war starts or if the neighbor has a heart attack … You’ll be calling 911 afterwards… You’ve been warned!
USB Debugging
The first thing you have to learn is to turn on USB debugging. Here is a guide how to do it (If you wanna see a pictorial guide). But essentially you have to go to Settings > Application > Development and check where it says USB Debugging. Pretty easy. What is this good for? Well, for starters. modify the phone however we see fit. But most important USB Debugging allows the phone to communicate verbosely with PC with the Android SDK installed. More on this later.
KDZ Updater
KDZ Updater is an application used by LG for flashing official operating systems themselves. How did this application saw daylight outside the company, I don’t know very well, but apparently a leak appeared on LG India, but not sure. In any case, this application is our last line of salvation and the main tool for our little friend.
To install official KDZs must follow these steps:
Install the updated drivers by following the steps listed on this page.
Connect the phone with USB Debugging activated
IMPORTANT: Disable the Virtual USB Modem device from Windows Device Manager. Omit this step and the device may brick in the upgrade process.
Run the application in Administrator mode (only required on Windows Vista / 7).
In the Type drop-down list select 3GQCT and in PhoneMode, DIAG. Where it says Version, will appear the version that is installed on the phone.
Select the KDZ file to install by clicking on the button with the folder icon. Preferably save the file KDZ in the root of the hard drive as there will be little chance for error when reading the file.
Press the button “Launch Software Update”. The phone will reboot into Emergency Mode. This is normal.
Pray all you know and go for a cup of tea. The process takes about 8 to 10 minutes.
If all went well, the phone will turn off and the program displays a line that says = FINISHED =.
To start, first go into recovery mode by pressing the following buttons: Vol- & Power. This will make any old or unnecessary information to be removed. The phone will reboot into the system normally.
Original Thread
Root (Gingerbreak and SuperOneClick)
Ok, what we came here for. Rooting the phone. How do I do? It’s scary! Says who?! Lets start with the choices we have. Ok, we have the phone, but we have not updated anything, How do I get root? Gingerbreak comes on the scene. Pretty simple process: download, Enable USB Debugging, run, press Root, wait for the restart, confirm. Simple, right? Also read the instructions and warning on the link above in case something I overlooked, but that basically is the process. By the way, install Busybox, very important for future processes.
Stop, stop, stop … And if I upgraded the phone? Gingerbreak seems not to work! What do I do?! Mainly, DO NOT PANIC! First things first. Go to “About phone” and see that version it says; something different than 2.2? Cool, no problem. SuperOneClick comes on scene. Download the application, unzip. I assume you already installed the drivers, right? Otherwise, do it and come back when you have done so. Ready? Continue. Turn on USB Debugging and connect the phone to the computer. Execute the application and press the button that says “Root”. Need more information? Here is a video explaining step by step (its in spanish, but graphics needs no language) and if the antivirus gets all paranoid, read the explanation here.
Recovery (Amon-RA and CWM)
Ok, moving on. Just as clarification: From this step on, the phone should already be rooted. Otherwise, you will mourn at the very end because the phone will brick and you’ll end with a very good and expensive paperweight. What is a Recovery? Here the answer.
This is essential before changing the insides of the phone and a step that I believe needs to be forever linked to rooting process. Why? Simple! Installing a Recovery allows full system backup and restore if something goes wrong. That linking to rooting process? Because if you install a root application, modify the system, and damage the system, it can be restored to a previous time and we’re all happy campers. See?
So this is where we get our hands dirty. Initially, I ask again, have you installed the drivers? (From this point on I shouldn’t ask) Have you rooted the phone? Responded twice yes? Perfect. Now, download the Android SDK or only the .zip attached here (unzip preferably in C:\ADB\) to continue this process. Also download the Recovery that you will install, we have Amon-RA and ClockworkMod (CWM) v5, v5 touch, and v6, extract the recovery.img file to the folder where adb.exe is (If you used the SDK installer, should be at C:\Program Files\Android\android-sdk\platform-tools\; if you used the .zip, and extracted as recommended, C:\ADB\). Which to choose? My recommendation, CWM v5 (either one). Connect the phone to the computer in with USB Debugging activated. By the way, how do you feel using command line in Windows? Moving on…
Open a command window, go to where adb.exe is and run the following commands:
Code:
adb push recovery.img /sdcard/
adb push flash_image /sdcard/
With this we have copied what we need into the phone’s SD card. Just to clarify: 1) the flash_image file can only be found in the recovery Amon-RA zip (not sure if it is generic or modified exclusively for the P350, then I’d rather play it safe) and 2) CWM recovery v5 and v5 touch files come in zip-installable, but you can open the file and use recovery.img in it. In CWM v6 there is an installable zip and another to follow this same process. Lets continue…
Code:
adb shell
$ su
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock1 /system
# cat /sdcard/flash_image > /system/bin/flash_image
# chmod 755 /system/bin/flash_image
# sync
Up to this we have only prepared the area to install the Recovery. It it recommended to reboot the phone in this step, in case you run out of virtual memory but is not really so necessary (If you see an error message, then reboot). That’s yours decision. Continue…
Code:
adb shell
$ su
# flash_image recovery /sdcard/recovery.img
# sync
To confirm that everything is installed without issues it must happen one thing and do another thing. What must happen is when you execute the flash_image command, no errors should appear, if otherwise reboot and repeat the last block of commands. What must be done is execute the command reboot recovery and if everything is alright, you should go into Recovery menu, if not then all the information has been erased and back to square 1 (it happened to me the first time).
Kernel
Just for safety: are drivers installed? Root acquired? Recovery installed? Already made a backup of the ROM in use at the moment (so far should be the LG ROM)? Do it!!
So, what’s a kernel? Here’s the answer. What choices do we have? Well not too many, it depends. Are we still on the LG Stock ROM or a Froyo-based ROM (oh, getting ahead aren’t we?!)? Well, the truth, with this ROMs there are not many: Team Pecan Kernel would be my recommendation, RoQ Kernel which also works quite well. CM7 ROM or any other Gingerbread-based? Ron's RM CAF Kernel (updated weekly), pax0r kernel (discontinued), Vivek Kernel (also discontinued but higher than pax0r). Read how to use Recovery for the installation of installable zip files from Recovery. This is also applicable for the installation of ROMs.
ROM
Still with me? Still no cardiac arrest? Relax, breathe! As we reach the last modification process of the phone. After surviving this, you will have the full capacity to recover the phone from any eventuality. Dictionary, which is a ROM? Here the answer.
ROM, What options do we have? Well, although it may seems, there are many options to choose from! We have some created from source code, based-on and others that have been “ported” to work with the device. Among those created from the source we have: CyanogenMod 7.2, Pure CM Invasion and CyanogenMod 9 (Work in Progress, not quite stable), based-on: Androm x4.2 (CM7) Arc XP (CM7), Gingerbread Optimus UI (CM7) Gingerblur (CM7) and MIUI v4 (based on CM7, Arc XP with a theme very close to the real MIUI, Japanese ROM). Ports: JoyOS, ICS (Discontinued unstable), BeautySense (Decent and functional).
Further Development/Tweaks
At the moment a new tool has been released called LG P350 Pecan Toolkit, developed by antdking. Its in early development and so far it roots, unroots and installs recovery. Saves some the hassle of the command line but if we haven’t gone through all the problems and commands, what have we learned? Anyways, here’s the original thread where you can follow the development and post ideas or bugs.
If you wanna go all-in into ROM cracking and research, we have also the LGExtract tool, which unpacks the KDZ file into bits and pieces. DZ Extract Tool extracts the files within a DZ package very much into source code. I've used these tools but as my experience with coding and android development is very close to none all I've done is extract the files and read them. Antdking reminded me of a simple yet powerful tool to continue decompiling the LG filesystem called unyaffsmbn. I came across it when we were trying to decompile baseband (amss.mbn) for CM9 without success, just lo later know that the tool just decompiled system.mbn. Oh well. Antdking compiled unyaffsmbn into a nice little tool ready to work, here it is.
The volume on this phone, as many may know, is low. But there is a way to elevate it. Execute the phone app and press: 3845#*350#. This will bring up a Hidden Menu. Go to: Device Test > Sound Test > Audio CAL Tool > Subsystem Calibration. In the Gain Type dropdown list, select Speaker Gain. Set Data textbox gets focus, input the number 90 and press OK button. In Gain Type, select Input1 Gain, and we press Ok button again. Exit the Hidden Menu. This will elevate the speaker volume but just temporary, it will be restored to default values when rebooted. So either don't reboot or repeat this process everytime you reboot.
And that would be all. Happy hacking!
Great kudos to the real developers here:
drapalyuk: For the first ever recovery for P350, Amon-RA
pax0r: Started it all, Kernel, ROM
ron gokhle: ROMs, Kernel and Recovery builds
vivekkalady: Kernel, Touch Recovery, first ICS port, and some other fix work
nikhil4186: For the KDZ Guide (although written originally for LG P500
antdking: For a great-to-be toolkit
great guide good job
Nicely written.Its a really good guide for all those who are new to P-350 and I believe that it will help them to learn some of the basic stuff.Well done!
to go on the end of this guide, how to extract the files out of the system.mbn to get the system files
http://db.tt/7VruqEzr
it returns similar files to what you find in a rom
I did not make unyaffsmbn
I made the tool that uses unyaffsmbn
enjoy
antdking said:
to go on the end of this guide, how to extract the files out of the system.mbn to get the system files
http://db.tt/7VruqEzr
it returns similar files to what you find in a rom
I did not make unyaffsmbn
I made the tool that uses unyaffsmbn
enjoy
Click to expand...
Click to collapse
got the PM and you reminded me of that tool (I remembder I came across it when we were trying to crack amss.mbn for CM9)... I'll post the original thread and the tool you just mentioned...
Updated adding unyaffsmbn tool... Thanks antdking!
Added Volume tweak for speaker to sound harder.
Added P350 (and guide) to XDA wiki. http://forum.xda-developers.com/wiki/LG_Optimus_Me
dbarrera said:
Added P350 (and guide) to XDA wiki. http://forum.xda-developers.com/wiki/LG_Optimus_Me
Click to expand...
Click to collapse
thanks man :good::good::good::good::good::good::good::good:
Guys We have got Official Support From XDA Please Move This Thread To Our Device Section
Very good!!!
I placed some problem I am having, just in case you have time an patience for this case.
Tks
http://forum.xda-developers.com/showthread.php?t=2461183
Great Guide Man! Thanks a lot.
MODERATORS: Please humor me on this... instructional writing is NOT something I'm good at, so I spend many hours writing these pages. It will take time - many weeks - for the entire "how to" to be completed. I think it'll be worth it.
PLEASE DO NOT REPLY TO THIS POST. I've created a separate thread for discussion and Q&A:
http://forum.xda-developers.com/showthread.php?p=34234642
This is NOT a new wiz-bang overvolting underclocking souped up power ranger wonder-kernel. If you're looking for a kernel to load on your phone for daily use, this thread isn't for you.
This is a thread for developing a kernel that works in the Samsung Galaxy Note II for AT&T (SGH-i317.) That previous sentence is carefully phrased: The thread is for DEVELOPING the thread. It's not a "download this kernel" thread. As a matter of fact, I will NOT be posting a precompiled kernel or installer for the kernel.
I'm hoping to try and share my experience making these things so that YOU can do it on your own... without my help. In that regard, this will likely start as a "HOWTO" type of thread, and hopefully move into actual development discussion. On the other hand, it is NOT a classroom.
My intended audience includes existing developers with little android experience, or even experienced android developers that would like to tinker with kernels. I'm sure even non-developers who want to learn might be able to pick something up from this. I fully expect that I'll be writing things that people already know - and much of this will be boring "review" for many readers. Remember that while "you" might already know something, someone else reading it might not. (This is something I often forget myself. When it happens, please remind me.)
There are a couple things you should know about me...
First and foremost, you have to understand that I'm not a "people person", I'm sarcastic, and I'm a horrible teacher. I also expect a certain amount of technical ability. If I provide a suggestion that you go to "http://source.android.com/source/index.html" and follow the instructions for setting up a build environment on a linux-based machine, I expect you to understand that you need a web browser to go to the URL, that you have to type the URL into the browser (or just click the link), and that you read the webpage and figure out that "Initializing the Build Environment" is probably the proper thing to click. If a person has issues with that, then there really isn't anything I can do to help. It might be because they are beyond all help, or it could be because I'm a grumpy engineer. Either way, I'm sorry - please move on.
I hope to retain the patience to walk people through setting up a github account, branching a stock kernel, pulling that kernel source to your own machine, insert the files for a ramdisk, compiling that kernel, manually pushing that kernel to your own device (for testing), writing an edify script (for installing the kernel), and packaging it all together for installing via a recovery-type program.
Once we have a working kernel, I intend to walk any remaining readers through the process of "cherry picking" (not nose picking) changes from another open source project into this kernel. This is a fairly common practice among open source developers where individual changes from one project can be copied to another. Many of the kernels posted on XDA are made up of nothing but cherry picking.
Then, I hope to add some simple modifications to that same kernel, and explain what those modifications are, why the are done, and HOW they are done. There will be no "new" features being added here... just reinventing the wheel (at least as far as I'm planning.) Actually, these "modifications" will probably be copies of the work of another for the sake of simplicity (and the fact that most of the simple things worth doing have likely already been done.)
There are many steps in between all these, of course. Kernel logs, kernel configs, troubleshooting, recovery, etc.
You will need to have a linux machine suitable for building linux kernels. It doesn't matter if you have a dedicated machine for it, a "dual boot" system, or even if you run it in a virtual machine. (It just so happens that I typically run it in a VM.) We aren't building the entire linux system, just the kernel, so you won't need 50GB of free drive space. No, I don't know exactly how much space you'll need. Plan on 15GB and you should be fine. You'll have to know what adb is, have it installed, AND have it working. That's something I won't walk anyone through - there are plenty of tutorials on the web for it and if you can't get that basic part done without help, you should consider just using your android phone and not developing with it. Really, "adb" is a fundamental android tool and is worth understanding even if you don't want to tinker with kernels.
You will need to have some tools (a toolchain) installed.. However, we'll get to that a bit later. There are MANY prebuilt toolchains floating around, and there's no reason not to take advantage of them. A text editor on that linux machine will be useful. I won't make any particular suggestions, but if you have no idea what to use, "gedit" is a servicable editor, is included in most linux distros, and is good enough.
Keep in mind that I have a real life outside of XDA. A full time job, a wife, two kids (7 & 9) and my own hobbies. There might be significant delays between "chapters" of this HOWTO. There's really nothing I can do about that. It's life.
What do I expect to get out of this? I expect that people LEARN methods, ideas and concepts... and that we DISCUSS and SHARE development. I'm freely giving my knowledge and the lessons I've learned, so I expect that people who learn from it will also give that knowledge freely to others. If this thread gets you going with building kernels and you figure out how to solve some problem as a result, I expect that you'll share that solution just as freely. I expect that when you start building kernels for other devices, you don't bribe people with "extra features" if they give you money. I expect that you give back to the open source community what the open source community is giving you - with interest.
Why am I doing it and What am I getting out of it myself? I'm not completely sure, to be honest. Chances are very high that I'll get extremely frustrated from doing this and regret it. On the other hand, I hope I'll learn from the experience and that I'll learn from the people who participate in the thread. I don't care what you currently do or don't know - there's always something I can learn from you.
I also have to admit that I'm doing this because I'm tired of seeing the "development" subforums on XDA looking like app stores with support threads instead of places where people share and discuss development.
The Build Machine
A short note: There might be some confusion about the use of the "cd" command without any parameters found in a few places. These are intentional, and have the effect of "change to the user home directory." I often use these before creating a new directory to ensure I'm creating it in a "known" location.
The build machine, as I mentioned earlier, should be a linux machine. For the sake of simplicity, (and because I'm too lazy to explain each and every possible program you'll need, how to get it from each linux distro, etc) I'm going to suggest that you follow Google's instructions for setting up your environment. Not only will this ensure you have everything required (except for adb and a toolchain), but also help me to know what kind of system I'm helping with. More advanced users might want to ignore this and set up their own build environment. That's fine too - but please don't ask me to help with it later.
In case you're wondering, I'm actually creating a new virtual machine for the sole purpose of this HOWTO so that I can make sure that each step I give actually works. Here are the specs of the VM I'm creating:
Ubuntu 12.04(LTS) 64 bit on a 30GB HDD with 8GB of RAM and access to 2 processor cores.
If you are doing a fresh install of Ubuntu for this, I'd suggest, after installing it, to press the "Dash Home" button near the upper left of the screen and typing "terminal" and clicking the icon for "Terminal." This will start a command line prompt in a window. It will also put an icon for the terminal program on the toolbar along the left side of the screen. RIGHT-click this icon and choose "Lock to Launcher." This will make it easier to start the terminal program in the future. (you'll need it.) Do the same thing for "gedit" (the icon name comes up as "Text Editor") if you don't already have another text editor you prefer.
If you are doing a new Ubuntu install, I'd suggest running the "Update Manager" and installing available updates.
From this point forward, I have to make certain assumptions about the technical ability of the readers. One of those assumptions is that you'll have the technical ability to follow the instructions I give. I simply cannot spend the time and space to break down HOW a user might "create a file as the root user and copy lines to it." The honest and blunt truth is that if you aren't already able to do that, the rest of this HOWTO will be a nightmare for (and me.) This isn't to be mean, rude, nasty or anything else - we all had to learn addition and subtraction before long division.
Time to begin!
Please go to the following URL and follow the instructions for initializing a build environment on a linux (Ubuntu) machine:
http://source.android.com/source/index.html.
There are instructions here for setting up on Mac OS X, but I have to be completely honest in saying I don't know if kernel development will work in OSX - I've never tried it. You can if you want, but I won't be able to help you getting the machine set up. If you're using a linux distro other than one of the suggested Ubuntu versions, you'll need to read the instructions given and figure out how to apply them to your own installation. Not all of the packages it wants installed are actually needed for kernel development, but I'm too lazy to pick through them. They really don't take too much space.
You will probably encounter an error when you get to the step for the java JDK. (If you don't, then you aren't following the directions.) The java JDK is no longer available when following Google's instructions (and they never bothered to update the page.) Don't worry about that, as we don't need java for kernel building.
For the "Configuring USB Access" section, you'll need to specify a different line for the udev rules (so it sees a Samsung phone.) You can either add this line to the end of what Google provides, or use this single line instead of what they provide (I did the latter on my VM):
Code:
SUBSYSTEM=="usb", ATTR{idVender}=="04e8", MODE="0666"
As an alternative, you could also just copy the following line into a terminal window :
Code:
sudo sh -c 'echo SUBSYSTEM==\"usb\", ATTR{idVender}==\"04e8\", MODE=\"0666\" >> /etc/udev/rules.d/51-android.rules'
If your phone is already plugged into your computer's USB port, those changes won't take effect until after you unplug the phone and plug it back in. If you are using Ubuntu in a VM, you'll probably need to perform some action so the VM takes over that USB port and redirects it to the VM.
Some versions of Ubuntu will pop up dialogs asking what to do with the recently connected device (or even show an error or warning saying that it's unable to lock the device.) If this happens, make the dialogs go away: Select "do nothing" for prompts asking what to do, and just "OK" for any error or warning. We don't want to access the phone as a media player or camera or even as a MTP device. We only need "adb" access!
A short word about adb: We actually don't need to use adb for this. However, it greatly simplifies repeatedly copying kernel image files to the phone, running a shell on the phone, rebooting the phone, getting into recovery, etc. Anyway, if you do kernel development and don't have adb, people will laugh at you. It'd be like using a fork to eat noodles in Hong Kong.
As mentioned previously, after you get the basic machine going, you should follow the steps for initializing a build machine at http://source.android.com/source/index.html (and not worry about the error when trying to install the java JDK.) Be careful that you follow the steps for the version of Ubuntu that you have... the required package list for 10.04 is different than the package list for 12.04. (So if you blindly copy/paste the commands from the wrong sections, you'll get errors... I did when I copied the 10.04 package list for my 12.04 machine.)
There's still a few more things needed. For example, we spent the time editing those udev rules so linux would "see" the phone and we can use "adb" but we haven't actually installed "adb" yet. For that, we'll go to this link: http://developer.android.com/sdk/index.html
There's a few different bundles on this page, as well as some other things. We actually only want a very tiny subset of a subset of what's on here. Near the bottom of the page find the section for "Download for other platforms", and the "SDK Tools Only" section below that. The actual download we want is the SDK tools (only) for linux. As of my writing this, the file is named "android-sdk_r21-linux.tgz." Download that to your linux machine.
You'll then need to unarchive the "tarball" somewhere on your machine. If you don't have a great place in mind to put it already, and assuming you're using a pretty default Ubuntu system, you can open a terminal window and copy the following commands:
Code:
cd
tar xzvf Downloads/android-sdk_r21-linux.tgz
This will end up creating a directory called "android-sdk-linux" and sticking everything in it. But Wait! "adb" isn't actually included with that. So, assuming you've been following along with me so far (and if you haven't, you'll have to adjust the following commands) copy the following commands:
Code:
cd android-sdk-linux
tools/android
This will pop up a window letting you pick and choose which SDK elements you want to install. There's a LOT of stuff here, but all we need are the "Android SDK Platform-tools" (under "tools".) Check that box and click "Install 1 package..." Accept the license and click "Install." When it's done, click "Close" and then close the "Android SDK Manager" window.
To access adb, you might type something like "~/android-sdk-linux/platform-tools/adb devices" That's a pain in the rear, so how about we simplify things? Copy the following commands in that terminal window:
Code:
cd
mkdir bin
cd bin
ln -s ../android-sdk-linux/platform-tools/adb adb
cd
echo 'PATH="$HOME/bin:$PATH"' >> .bashrc
Those lines will create a symbolic link (like a windows shortcut) from the actual adb program to a private "bin" Then it tells "bash" (which is the default command interpreter in ubuntu distros) to look in that private bin for commands you type. Some users who aren't setting up brand new ubuntu systems for this might want to check that they are actually using bash and that $home/bin isn't already in their path - and adjust this accordingly. You'll need to close any 'terminal' windows you have open and restart them in order for this to take effect. (Advanced users: I know this isn't the best way to modify the PATH on a default Ubuntu box, but it's the easiest way to get it working. If you're advanced enough to know that, then you're also advanced enough to do it better on your system.)
Now, you SHOULD be able to plug your samsung android phone into that ubuntu machine, wait a couple seconds (and close any silly warning dialogs about locking the device) and adb will see your phone. To test, use the command "adb devices" (in a newly opened terminal window.) You should see something like "List of devices attached" followed by a string of letters/numbers some spaces and the word "device." For example:
Code:
List of devices attached
12a34b567c890def device
There's only one more thing left to do for this post: Install the toolchain.
A "toolchain" is a set of tools that we use to get from a bunch of source files to a kernel that can be installed. We could build a toolchain from GNU (or other) sources, but google has made this much easier for us by providing a prebuilt toolchain, and even made it easy to get. Personally, I'm EXTREMELY happy about that, as this "page" of the HOWTO is getting entirely too long. (I hope XDA doesn't crash when I copy it into a new post!)
Copy the following in a new terminal window:
Code:
cd
git clone https://android.googlesource.com/platform/prebuilt
This might take a while to download, so go ahead and distract yourself while it's going. When it's done, you've finished this post!
I had originally intended to start discussing git and github in this post, but I'm putting that off for the next post when I'll also have you fork the actual kernel source and pull the source to your build machine.
Before I go on, I'm going to take a little side trip into some open source (and GPL) concepts. I'm not a lawyer and nothing I write should be interpreted as legal advice.
The linux kernel, which is the kernel that android uses, is open source software and licensed under the "GPL." Without knowing all the legal mechanisms, this means that the kernel is freely available. It's free to use and the source is also free. Anyone who distributes a product that makes use of this kernel is REQUIRED to make the source available for free. This includes any changes that a company might make to the linux kernel. As those changes are a derived work, it must retain the free licensing of the main body. That includes even large companies like Samsung, HTC, Google, TiVo, Netgear, etc. There are some things not covered such as separately compiled kernel modules (like some ethernet drivers), but non-GPL licensed kernel modules are fairly rare.
This same rule applies to you and I. If you or I distribute a linux kernel alone or as part of a larger product, we are bound by the licensing of that kernel to make our source code available to anyone who asks. If you post a linux kernel on a website or any other form of distribution, you are legally and morally required to also ensure that the source code for that very same kernel is available.
I feel very strongly about this, so if you have a problem with it, please do me and the entire community a large favor and go away.
In addition, here on XDA, you are required to ask permission to use kernel code that another member wrote. This isn't a GPL requirement, but an XDA one. For that reason, I've asked a couple of other dev's on here if I could use some of their modifications in this HOWTO (and in the spirit of open source software, each one welcomed me to do so.) Even if it weren't a requirement here on XDA, it's always polite to ask the author if you can use their works. In almost all cases, they'll agree to it. In addition, they'll often offer tips and suggestions for using certain things. For example, they might warn you that if you want to cherry pick a certain change, you should also get another one or things will break.
Before reading this page, I want to point out that I'm fairly weak on git and github. I might be giving instructions that use the incorrect phrasing or are just simply the wrong way of doing things. If you see me doing this and you know better, PLEASE post a message on the companion discussion thread. If there's a better way, I want to know about it, and I want to update this post to reflect it. Keep in mind, though, that I'm trying to simplify things here for the HOWTO, so if your suggestion is more complex (or would require me to type two pages to explain it) I might not update this post with it.
Most linux-based kernel development these days uses a form of version control (source control, revision control, etc) that will catalog each change made to the source as a change set (or a commit.) Of these, "git" is the most prevalent. Git was written from the ground up specifically for linux development (by the folks who originally created linux) and to meet the very distributed needs of linux kernel development. For more information on git, wikipedia has a good article: http://en.wikipedia.org/wiki/Git_(software)
Along with "git" as the version control system, we'll be using Github as a free hosting service for out git repositories. Github acts like a server for projects using git for revision control. While the site is somewhat geared as a "social" code sharing website, you don't have to be a friendly person to use it. (They even let me use it!) In fact, it's perfectly acceptable to use Github as a server for a project that only you are working on. It's extremely well suited to act as a remote backup for your code projects (which, I admit, I abuse it as) and it serves one other purpose for us: It's an extremely easy way to meet the legal requirement that our linux source is freely available.
Git (and Github) offers a really nice mechanism for a person (such as a reader of this thread) to start a new git project based on the source code of someone else (such as an original kernel project I'll set up for that purpose.) In git's terms, you will "fork" my project into something that belongs to you. Internally, you're only actually creating a link in your project to a very specific version of mine, but it appears and acts like a full copy. (In ways, it's actually BETTER than a normal copy.)
You can, of course, also create a new project from scratch and add new files directly. However, it's considered a better practice to fork from an existing project if possible. This saves a considerable amount of space on the Github server as it's really only keeping a single copy of that original source. It also makes it much easier to pull in changes from the original project (and push changes back to it.) Unfortunately, it's sometimes difficult to find a "clean" branch to fork from. For the purpose of this HOWTO, I've created a clean copy of the SGH-i317 sources in a project in Github and you'll be able to fork from that.
Before forking my project, you'll first need to create a Github account if you don't already have one. Just go to http://github.com and click "Sign up for free." You'll be presented with a page reminding you of the high cost of this service (free) and asking you for a username, email address, and password. Fill in that information and click "Create an account" (which implies acceptance of their terms of service and privacy policy.) That's it. You now have a Github account.
While logged in with your Github account, you want to find a project to fork from. As mentioned, I have a pristine copy of Samsung's actual source release for the i317 set up for just this purpose. Up at the top of the Github webpage, you can search for that project. Just type "linux_kernel_sgh-i317" into that search bar, and you should get a result pointing to "garyd9/linux_kernel_sgh-i317." If you click that link, you'll end up at "https://github.com/garyd9/linux_kernel_sgh-i317"
Finally, you'll go ahead and fork a copy of that for your own use. This is a highly complicated procedure so please pay very careful attention to these instructions: On the upper left of the Github webpage, there's a button labeled "Fork." Go ahead and press it. That's it. (Some people actually mess this up. I have no idea how.) You now have, at least on the github site, your own copy of the kernel source. Leave that browser window open while doing the next step. It contains something we'll need very shortly...
(Parts of this are taken from Github's own "Bootcamp/Set Up Git" webpage at: https://help.github.com/articles/set-up-git#platform-linux I'd encourage you to go to that link and review it as well.)
Back on your build machine, open up a 'terminal' window and type the following command, replacing "Your Name" with your own name. Leave the quotation marks in place.
Code:
git config --global user.name "Your Name"
This is telling your local git software what your name is. This shows up in all your git commits, so you probably don't want to put something stupid here.
Also in the terminal window, you'll type this next command. This time, replace "[email protected]" with the email address you used to register on Github. (This is important!)
Code:
git config --global user.email [email protected]
Finally, there is one more command to type. This last one will tell git to cache (store) your Github account information so you don't have to type a password every single time you push to the server. (By default, it caches for 15 minutes. Read the Github bootcamp article linked above to find out how to extend that.)
Code:
git config --global credential.helper cache
Before we tell git to actually pull the source code from Github, there's one more little organizational thing I like to do. I like to keep all files related to building of a kernel in a single directory on my linux machine. There's more than just a kernel required for building the kernel! So, go ahead and copy the following commands to your terminal window:
Code:
cd
mkdir kernel-howto
cd kernel-howto
Now, everything related to this HOWTO can be put into one place: That newly created "kernel-howto" directory that we also changed into.
Now, it's finally time to get the source code to your build machine. Remember I suggested leaving the browser window open on the github page showing your newly forked project? Well, what we actually want is the page URL. It should look something like "https://github.com/yourUserName/linux_kernel-i317" "yourUserName" should be your Github username. We need that URL and add ".git" to tell git what to fetch. In this case, we'll be using the "clone" command which basically just tells git to make a copy of the remote project. You won't be able to just copy/paste the following command into your terminal window, because you'll have to change at least the yourUserName part of the URL. Go ahead and type this command (making the change needed.)
Code:
git clone https://github.com/yourUserName/linux_kernel_sgh-i317.git
When the command finishes, you'll have a new sub-directory inside of "kernel-howto" that's called "linux_kernel_sgh-i317". Go ahead and change into this directory.
Code:
cd linux_kernel_sgh-i317
There's only one last thing I want to do here before ending this post, and that's to ensure anyone following this HOWTO is able to push changes. To do this, just copy the following commands that will create an empty (and meaningless) file, add it to git, commit it as a change, and push it to the server.
Code:
touch HOWTO
git add -A
git commit -m "test commit"
git push
After the "git push" command is sent, you should be prompted for your github username and password. After you enter that information, you should see something similar to the following (the characters before "master->master" will be different):
Code:
To https://github.com/yourUserName/linux_kernel_sgh-i317.git
e3d49d2..ea9fbe9 master -> master
You can also go back to your Github page for this project to see the commit on Github. If you aren't on that page anymore, log in to Github, and click the linux_kernel_sgh-i317 repository on the right side of the webpage. Then find and click the "Commits" link (which is between "Files" and "Branches" a few lines down from the top of the page.) The top commit will be the "test commit" that you did on your build machine and pushed to Github.
The kernel isn't quite ready to be compiled. We'll get to that in the next post. In the meantime, if you'd like to learn more about using git and github, there's an interesting interactive walk-through style tutorial at http://try.github.com.
gitignore
When we work with the kernel, we will generate a lot of temporary files that we don't want to put into the git system or upload to GitHub. To have "git" exclude those files from consideration, a file (or set of files) called ".gitignore" should be created that tells git what to ignore. A more complete explanation of the .gitignore file can be found here: https://help.github.com/articles/ignoring-files
Instead of having you create and edit several different ".gitignore" files, I've made a patch that you can apply directory to your kernel tree, using git, that will add those .gitignore files. The following commands, which you should copy to a terminal' window, will change into the kernel source directory, fetch the patch file (using wget), apply the patch (using git am) and then delete the patch file (as it's no longer needed.) If you have the kernel source in a different directory, you'll have to adjust one of the "cd" commands accordingly. After deleting the patch file, we push those changes to the github server. I'll explain the various git commands more in depth in a later section of this HOWTO.
Code:
cd
cd kernel-howto/linux_kernel_sgh-i317
wget https://raw.github.com/garyd9/kernel-howto-misc/master/add_gitignores.patch
git am < add_gitignores.patch
rm add_gitignores.patch
git push
Just a few more things...
The next item to mention before compiling the kernel is the kernel config file. Linux, as a kernel, can be used on literally thousands of different configurations. However, each platform might require a different kernel. How this works is that when the kernel is compiled, a kernel configuration is supplied that tells the compiling tools which drivers to include, how to configure them, what kind of processor the target platform has, etc. For now, we'll just use a default configuration file that Samsung provided with the kernel source. That configuration is called "t0att_04_defconfig" and (luckily for us) actually seems to be accurate. When building for another device, don't assume that the kernel configuration provided with the source is accurate... I've had at least one case when the configuration Samsung provided for their own device simply didn't work for that device. Later in this HOWTO, we'll be discussing the kernel configuration much more in depth, and even making changes to it.
Next, we need to talk about that prebuilt toolchain we downloaded earlier in the HOWTO. When compiling the kernel, we need to tell the system to use that very specific toolchain for doing the work. What we're actually doing is called "cross compiling", which means we're compiling for a different platform than the compiler itself is running on. In this case, we're running on an x86 (or x86_64) platform, but compiling for the "arm" platform. To tell the system which toolchain to use for cross compiling, we will use a command line parameter that defines "CROSS_COMPILE" to point to the proper toolchain files. Assuming you've been following this HOWTO (and if you haven't, you'll have to adjust this accordingly every place it occurs) that will look like this: "CROSS_COMPILE=$HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-"
Finally, there's just one more thing before we can compile. The actual tool we use to kick off compiles is called "make." Make doesn't really know much about compiling software, but it's a great tool for figuring out when things need to get done and for doing them. By default, "make" reads a file called "Makefile." A Makefile describes how files might be dependent on each other, how to compile files and put things together. Because of the magic of a Makefile, you won't have to recompile the entire kernel each time you make a minor change. Instead, "make" will only recompile what's needed to include updates to the source.
Are you ready for actually compiling? Okay, go ahead and copy these commands. There are two commands here. The first one just prepares the kernel config file, and the second one compiles the kernel. As always, if you've made changes to paths (locations) of things, you will have to edit these commands.
Code:
cd
cd kernel-howto/linux_kernel_sgh-i317
make arch=arm t0att_04_defconfig CROSS_COMPILE=$HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
make CROSS_COMPILE=$HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
Depending on the speed of your machine, this can take a while to complete. You'll be witness to many different files getting compiled and linked together as it runs. When it's done, you'll see something like this in your terminal window:
Code:
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 7 modules
CC arch/arm/mvp/commkm/commkm.mod.o
LD [M] arch/arm/mvp/commkm/commkm.ko
CC arch/arm/mvp/mvpkm/mvpkm.mod.o
LD [M] arch/arm/mvp/mvpkm/mvpkm.ko
CC arch/arm/mvp/pvtcpkm/pvtcpkm.mod.o
LD [M] arch/arm/mvp/pvtcpkm/pvtcpkm.ko
CC drivers/interceptor/vpnclient.mod.o
LD [M] drivers/interceptor/vpnclient.ko
CC drivers/net/wireless/bcmdhd/dhd.mod.o
LD [M] drivers/net/wireless/bcmdhd/dhd.ko
CC drivers/net/wireless/btlock/btlock.mod.o
LD [M] drivers/net/wireless/btlock/btlock.ko
CC drivers/scsi/scsi_wait_scan.mod.o
LD [M] drivers/scsi/scsi_wait_scan.ko
Congrats - you've just compiled a linux kernel for Android.
There's only one problem: It's completely useless in it's current form. If you were to install that kernel on your phone, it simply wouldn't boot. What it really needs now is a ramdisk.
The next sections (plural) in this HOWTO will discuss what ramdisks are, how to extract one from an existing kernel, and how to package a ramdisk image with a kernel to make a flashable boot image. We also need to talk about partitions, block devices, making backups, using the 'dd' command, and a few other things.
You didn't think this was easy, did you?
It would be a great idea to get familiar with the "adb" tool; particularly the "shell", "pull" and "push" commands. (Use Google to search for "how to use adb.") Over the next several sections, we make use of these adb commands to copy files to and from the Android device and to interact with the device's operating system. This document also assumes that the device has already been rooted.
To get a "rooted adb shell" on a Samsung TouchWiz device, you'll have to have your device attached to and seen by your linux build machine, and use the command "adb shell" in a terminal window. Now, turn on the display for your android device and unlock it (if required.) Finally, back in the terminal window on the linux build machine, type the command "su". You Android device might pop up a prompt asking to give permission for the root access. If it does, grant the access. After the su command, the prompt should have a "#" symbol (instead of a "$" symbol.)As you might already have realized, just having a linux kernel is interesting, but not extremely useful. The kernel can boot, but once it does, it needs a filesystem to load programs from, to store data, etc. In the UN*X world (which linux is derived from), there's a single root to all filesystems, and other filesystems mount (attach) to that single root. Android (and many other embedded systems) use a root filesystem that isn't real - instead it's a virtual filesystem called a RAM Disk. Briefly, a RAM Disk is a portion of the devices RAM that's put aside and make to look like a persistent storage device. Unlike a real storage device, the RAM Disk (usually typed as "ramdisk") is completely erased each time the device is rebooted.
Linux allows taking that concept to a higher level by allowing a kernel to specify an initial ramdisk image. The image is a snapshot of a portion of an actual filesystem which is used to create the ramdisk. That, in turn, is specified in the kernel configuration to be the "initramfs" - which means that it becomes the root filesystem for the entire device. ("initramfs" is short for "Initial RAM FileSystem.") The initramfs image is embedded within the kernel image, and each time the kernel boots up, it uses that image as a root filesystem. Being it's a ramdisk, we can even make changes within the root filesystem after the device boots, but those changes will be wiped out the next time the device reboots.
Some other initramfs features supported by linux, but that don't seem to be used in Android, include the ability to switch root filesystems from within the initramfs, and the ability to store the initramfs as a seperate file (instead of embedding it in the kernel image.)As well as being an anchor for all the persistent (and non-persistent) storage devices in the phone, the Android initramfs also kick-starts the Android OS itself. (Remember that "linux" is a kernel, not the OS!) It usually contains some lower level system utilities (such as the files needed for adb functionality), a few kernel drivers that might not already be compiled into the kernel, a few config files used at the early stage of booting the device, and scripts used to get the rest of the system going. On some Android devices, the initramfs also contains the files needed for booting the phone recovery. (On other phones, including most that have been released since Android 4.0, recovery has it's own private kernel.) Remember, however, that the initramfs uses RAM, so it shouldn't be bloated with things that could be stored in real persistent storage.
Another aspect of using the initramfs that can be useful is that it allows booting at least a minimally functioning linux system in cases when the rest of the Android OS doesn't load properly. That minimal system could even be used to manually flash a different kernel, recovery, or even the entire firmware for the device.
Now that we have an idea what the initramfs is, and why we need one, the question is how to obtain one. In most cases, it's usually better to at least start with a copy of the initramfs already used by our Android device. This way, we know that everything needed in the initramfs already is there. We can (and will) make changes to it later. The best way to get an unmodified copy of the kernel's initramfs is to use a special tool to pull the ramdisk out of the kernel image.
For this HOWTO, we'll start with a "stock" kernel image (instead of a custom image that might have already been modified.) This gives us a known starting place, and ensures that files haven't been modified by a previous kernel developer. There are a few ways to get this kernel image. Often times, the easiest is to find one online in either a "recovery" style zip file, or packaged in a proprietary file such as Samsung's ODIN tar files. If you haven't installed a custom kernel on your device, you can also usually extract the kernel image directly from our phone.
The remainder of this section will be devoted to the information needed to extract a kernel image from the phone. Even if you don't have a stock kernel installed, it would be useful to read the information and go through the steps. The knowledge (and experience) will be useful when we have a kernel to install. However, different types of devices might have different device configurations, so some of this information might not be accurate for every device.
The kernel image (along with the device modem, firmware, data, etc) is stored on a special type of "flash" RAM that doesn't lose it's memory when power is removed. It's very much like any type of removable memory (such as a SDCard, USB thumb drive, etc.) Unlike those examples, however, this special storage is built into the phone or tablet. This guide refers to that flash memory as "persistent storage" which indicates storage that retains data even when power is off or the device resets.
The persistent storage on our devices is treated in linux much as a hard drive is treated on a PC. As with a hard drive, the persistent storage is split into logical "partitions" and each partition can be (and usually is) treated as a separate logical storage device. Our devices might contain 16GB of persistent storage space, but that 16GB is partitioned into a dozen or more smaller chunks providing separate locations for storing the kernel, the bootloaders, the files needed for recovery, the system files, the modem firmware, user data, etc.
In linux, physical (and virtual) devices have drivers in the kernel, and are represented by a special virtual filesystem usually mounted (attached) to a directory called "dev" in the root filesystem. Modern versions of the linux kernel usually separate the devices into sub-directories based on category. Persistent storage devices are almost always "block" devices. Finally, individual block devices are given names based on their driver and other ordering information as determined by the driver. Actual devices being represented are called "nodes" but are often also just called "device files" to keep the description simple. (This is an intentional simplification of how the device nodes are created.)
Based on the above paragraph, we know that the device nodes for the persistent storage can be found in a directory called "/dev/block" on our device. To see this, we'll need a rooted adb shell on your device (or rooted shell via a terminal emulator installed on the phone) and to copy the following command:
Code:
ls /dev/block
On most modern Android devices, we'll see a device node for "mmcblk0" which represents the entire built-in persistent storage. There will also be devices for each partition, such as "mmcblk0p1", "mmcblk0p2", and so on. One of those device nodes represents the partition used to store the kernel image (often called the boot image) - and we need to figure out which one. This is an area that can get annoying, as there doesn't seem to be a simple generic way to determine which partition the kernel is stored on.
(NOTE: If someone can give me a good way to determine the boot/kernel partition regardless of platform, please let me know and I'll document it here.)
If we poke around the directory tree in /dev/block/platform, we might be able to find a sub-directory buried in there called "by-name" and, at least on some platforms, we can determine the boot/kernel partition from there. We need to be somewhat careful, as the boot LOADER is most certainly not something we want to mess with - and many platforms can make it confusing when they refer to the kernel partition as the "boot" partition. On the Galaxy Note II, that "by-name" sub-directory is in /dev/block/platform/dw_mmc, and you can see the full list of named partitions by copying the following command to a rooted adb shell running on your device:
Code:
ls -l /dev/block/platform/dw_mmc/by-name
The result of running that command will include the following (or something similar)
Code:
lrwxrwxrwx 1 root root 20 Nov 18 12:39 BOOT -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 Nov 18 12:39 BOTA0 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 Nov 18 12:39 BOTA1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 Nov 18 12:39 CACHE -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 20 Nov 18 12:39 EFS -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 Nov 18 12:39 HIDDEN -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 Nov 18 12:39 OTA -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 20 Nov 18 12:39 PARAM -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 Nov 18 12:39 RADIO -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 Nov 18 12:39 RECOVERY -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 Nov 18 12:39 SYSTEM -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 Nov 18 12:39 TOMBSTONES -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 Nov 18 12:39 USERDATA -> /dev/block/mmcblk0p16
This gives us the information we need to determine the kernel partition. It's called "BOOT" and the actual device node is /dev/block/mmcblk0p8. Similar information can be found for other device types as well. For example, on a Galaxy Nexus running CM10, the sub-directory containing this information is /dev/block/platform/omap/omap_hsmmc.0/by-name and on a Nexus7 running pure AOSP 4.2, a similar (but more crytpic) set of information is at /dev/block/platform/sdhci-tegra.3/by-name. Sometimes, we just need to search to find the proper partition.
Once we have the name of the device node for the partition containing the boot/kernel partition, we can use that to actually convert and copy the entire partition to a normal file. The command for doing this is "dd" and the parameters we use need to be typed carefully. A simple typo here can result in overwriting a valid kernel unintentionally. Be paranoid! The following command, which should be copied to a rooted adb shell, assumes that the "boot" (kernel) partition is mmcblk0p8, and stores a copy of that entire image to a file called orig_boot.img on the internal user storage (/sdcard):
Code:
dd if=/dev/block/mmcblk0p8 of=/sdcard/orig_boot.img bs=4096
"if" designates the "input file", "of" designates the "output file" and "bs" is the block size. The block size parameter isn't really needed here, but it tends to speed up the copy by telling "dd" to copy 4096 bytes at a time (instead of 1 byte at a time.)
We now have a boot image (kernel image) that we can use to extract an initramfs from. One last step is needed to get that file transferred to our linux build machine. Open a new terminal window and copy the following commands into it:
Code:
cd
cd kernel-howto
adb pull /sdcard/orig_boot.img ./orig_boot.img
This will change into the kernel-howto directory on your build machine, and pull the recently made image to your build machine. (If using the 'Terminal' program in Ubuntu, you can open a new terminal window by right-clicking on an existing terminal window and selecting "Open Terminal." You can also right-click on the 'Terminal' icon in the Launcher bar and select "New Terminal.")
If you are using a different starting image, such as from an ODIN compatible tar file or CWM Recovery compatible zip file, please find the kernel image within that archive, extract it, and place it in the proper directory, renaming it to match. If you can't find a stock image (or don't feel like searching for one) just execute the following commands to get a kernel image that was extracted from a stock LJ2 SGH-i317 (AT&T variant):
Code:
cd
cd kernel-howto
wget https://github.com/garyd9/kernel-howto-misc/raw/master/boot_orig.img.gz
gunzip boot_orig.img.gz
When Things Go Wrong...
Before going any further, there's something extremely important we must do: We must plan for things to go wrong. No matter how careful we might be, and no matter how smart or talented a person might be, something can (and often will) go wrong. Perhaps a kernel will get corrupted when building, or maybe it will accidentally be copied into the wrong partition on the phone. Bad Things happen all the time, and it's best to be as prepared as possible.
If the bootloader partitions get overwritten or corrupted, there isn't much we can do. Without the bootloader, nothing else can work. If that happens, the only resort might be an actual repair service. That repair will likely cost money, as no warranty covers damage like this caused by the customer - not even the "accidental" things sold by companies like SquareTrade. It's one of the risks that people take when working at this level. (There are people working on modifications that would allow booting the phone even if the bootloader is overwritten, but I'm not aware of any of them being available for the SGH-i317.)
Most of the other partitions can be backed up and restored with a recovery tool. At the present time, I'd recommend using TWRP over CWM Recovery for two reasons: First, it supports backing up the EFS partition that CWM Recovery doesn't. Second, it allows restoring individual partitions instead of restoring an entire backup. If you corrupt the kernel, you can use TWRP to only restore the corrupted boot partition without restoring everything else. It is my understanding that the TWRP people are working on adding support for backing up the RADIO firmware partition as well.
It's possible to accidentally overwrite the recovery partition when performing certain actions. With no recovery, any backup made with TWRP or CWM Recovery would be hard to restore. To deal with that, we'll go through some steps later in this section to make images of certain partitions (including the recovery partition) in order to be able to restore them later if they are overwritten. As well, for most Samsung devices, there are ODIN compatible images containing only the recovery partition. Nexus devices can use a tool called "fastboot" to boot into a recovery image that isn't even installed on the phone.
Finally, at least with a Samsung device, a last resort is to fall back to ODIN to restore the phone to a factory state. That's only useful if a full ODIN firmware is available (or at least an ODIN image containing the partition you need to restore.) At the time of writing this guide, there's no full ODIN image available for the SGH-i317. When you see one, be sure to download it and keep it around. Also learn to use the ODIN tool. Having the image doesn't do much good with you can't use the tool for flashing it! ODIN relies on the bootloader of the device not being corrupted, so even ODIN is useless if you corrupt the bootloader.
In order to manually create images of some of the device partitions, first determine which partitions you want backups of. Keep in mind that the size of the images can get quite large, so don't use this method for the USERDATA (/data) partition. I'd suggest backing up the boot/kernel, recovery, radio, param, and efs partitions using this method. Use the information in the previous section to determine the device nodes for each of those partitions, and then use a command nearly identical to how we copied the stock kernel image to a file. If you have an external sdcard in your device, this is the perfect place to store those images. If we are backing up partitions from a SGH-i317 to an external sdcard, here are the commands we'd copy into a rooted adb shell to get those images:
Code:
cd /mnt/extSdCard
mkdir backup_images
cd backup_images
dd if=/dev/block/mmcblk0p3 of=mmcblk0p3.img bs=4096
dd if=/dev/block/mmcblk0p7 of=mmcblk0p7.img bs=4096
dd if=/dev/block/mmcblk0p8 of=mmcblk0p8.img bs=4096
dd if=/dev/block/mmcblk0p9 of=mmcblk0p9.img bs=4096
dd if=/dev/block/mmcblk0p10 of=mmcblk0p10.img bs=4096
Notice that we're naming the images the same as the device nodes they came from (the of= parameter.) A person could also name them efs.img, param.img, boot.img and recovery.img if they want. For the SGH-i317 device, the 4 images will use a combined 132MB of storage space.
To restore one of these images, we'd use the same 'dd' command, but reverse the "if" and "of" parameters. For example, if we corrupted our recovery partition (perhaps by copying a normal boot kernel to it), we could boot the phone normally, get a rooted adb shell, and type the following commands:
Code:
cd /mnt/extSdCard/backup_images
dd if=mmcblk0p9.img of=/dev/block/mmcblk0p9 bs=4096
Again, be paranoid. I can't possibly stress enough the need for backing up, and doing so frequently.
Now that we have a copy of a factory boot image, we'll unpack that image into it's component parts. There are three tools used for manipulating boot images that we should download and place somewhere on our path. The following commands, copied into a terminal window on our build machine, will take care of that:
Code:
cd ~/bin
wget https://github.com/garyd9/kernel-howto-misc/raw/master/mkbootfs
wget https://github.com/garyd9/kernel-howto-misc/raw/master/mkbootimg
wget https://github.com/garyd9/kernel-howto-misc/raw/master/unpackbootimg
chmod a+x mkbootfs
chmod a+x mkbootimg
chmod a+x unpackbootimg
Before going on, it's important to give credit where due: The three boot image utilities were compiled from sources in the cyanogenmod 10 repository. mkbookimg and mkbootfs appear to originate from AOSP, and unpackbootimg appears to originate from Koush (of ClockworkMod fame.) The sources for cyanogenmod can be found at https://github.com/CyanogenMod.
The three tools are:
unpackbootimg - used to unpack a full boot/kernel image into the ramdisk, kernel, and other files containing certain parameters.
mkbootfs - used to combine or archive a directory structure into a ramdisk image. (The same thing can be accomplished with the cpio utility)
mkbootimg - used to combine a kernel and initramfs image into a boot image that can be installed on a device.
To unpack the parts of the stock boot image, open a terminal window on your build machine and copy the following commands. As always, if paths or filenames have been changed from this guide, the commands should be altered to correspond to those changes.
Code:
cd ~/kernel-howto
mkdir stockbootimg
unpackbootimg -i boot_orig.img -o stockbootimg
ls -l stockbootimg
Here, the -i parameter is used to specify "boot_orig.img" as the image to unpack, and the -o parameter specifies that the results of unpacking the image should be placed in a sub-directory called "stockbootimg".
In the list of commands above, the last one just will list the files unpacked in the "stockbootimg" sub-directory. At this point, the only one of those files that is significant to us is the one named "boot_orig.img-ramdisk.gz." That file is the actual compressed ramdisk image used as the initramfs in the stock kernel. The file ending with "zImage" is the actual stock kernel, and the remaining files contain boot image values that are beyond the scope of this guide. (If someone is planning on manipulating things like the page size or base address, they likely have a skill/knowledge level far exceeding the audience of this document.)
There's really nothing special about the compressed ramdisk image. It's simply a directory structure archived with the "cpio" utility and compressed with gzip. In fact, if you copy the following command to your terminal window, you'll be able to see what's inside:
Code:
gunzip -c ~/kernel-howto/stockbootimg/boot_orig.img-ramdisk.gz | cpio -it
Later, we'll extract the files from the stock initramfs and make some changes. For now, however, we'll just use the compressed ramdisk as it is and combine it with the kernel we built earlier. (Normally when rebuilding the kernel, the kernel modules in the initramfs are replaced with ones from the new kernel compile, but we'll skip that step for now.)
Assuming you've already built the kernel (as described a few sections ago), the finished kernel should exist as ~/kernel-howto/linux_kernel_sgh-i317/arch/arm/boot/zImage. The following command will combine that kernel we compiled with the stock initramfs image we just unpacked:
Code:
cd ~/kernel-howto
mkdir first_bootimg
mkbootimg --kernel ~/kernel-howto/linux_kernel_sgh-i317/arch/arm/boot/zImage --ramdisk ~/kernel-howto/stockbootimg/boot_orig.img-ramdisk.gz -o first_bootimg/boot.img
The "--kernel" and "--ramdisk" parameters should be pretty obvious, and the "-o" parameter specifies where to put the final boot image. There are several other parameters for mkbootimg, but none of them are needed here as the defaults work fine. In most cases, the values for the parameters can be found by examining the files unpacked after running unpackbootimg.
We now have a fully functional kernel that we can install on our device and test with. Connect your phone to the build machine, and run the following commands to copy the new boot image to your phone (but not yet installed it.) This uses adb to first create a new sub-directory to place the image, and then to push the new image into that location
Code:
adb shell mkdir /sdcard/first_bootimg
adb push ~/kernel-howto/first_bootimg/boot.img /sdcard/first_bootimg/boot.img
WAIT! DON'T INSTALL THIS KERNEL IF YOU DON'T HAVE A BACKUP. THIS KERNEL WON'T WORK PROPERLY AND YOU WILL NEED TO RESTORE A BACKUP KERNEL FOR FULL FUNCTIONALITY
The first step to installing a new kernel should always be to ensure that a backup has been made of the device. Once a good backup has been made, there are actually multiple ways to install the kernel. Each, however, just copies the boot image to the devices boot/kernel patition device node. This was identified in an earlier section and for the SGH-i317 is /dev/block/mmcblk0p8. To do this manually, and assuming the device is already connected to the build machine, get a rooted adb shell and copy the following command making any required change to the device node. Make sure to be in a rooted adb shell first!
Code:
dd if=/sdcard/first_bootimg/boot.img of=/dev/block/mmcblk0p8 bs=4096
That's it - it's installed. We can unplug our device and reboot the new kernel into existance.
If a person is using a Samsung device that's supported by Mobile ODIN (developed by Chainfire), they can also use that program to install the boot image directory by simply selecting it as the kernel to flash. This actually tends to be a bit safer than using the 'dd' command, as there's no risk of typing the wrong device node filename. However, the boot image MUST be named "boot.img" for this to work.
When it is done rebooting, you'll be using your new kernel. As we haven't made any changes to the kernel at this point, the only way to tell the difference will be to go into Settings (on the device), and tap "About device" The line for the "Kernel Version" should now include the username you use on your linux build machine. In this particular case, there's another way to determine if we're using the new kernel: Try using the "soft" keys (the 'menu' and 'back' keys on either side of the home button.) They don't work.
Welcome to the Wonderful World of Kernel Development. There's a reason why those soft keys don't work, and we'll discuss that reason (and a resolution) in the next section. For now, we should just restore our kernel backup and wait for the next section to be posted.
After a fully functional kernel is restored, copy the following commands into a terminal window with the device connected to clean up the mess:
Code:
adb shell rm -r /sdcard/first_bootimg
cd ~/kernel-howto
rm -rf first_bootimg
LG Pro Lite D680
{
"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"
}
Boot On Charge
Non-generic feature for commercial purposes
URGENT NEED! - WILL DONATE
What we need:
I am looking for an urgent solution to boot-on-charge LG D680 cell phone, I am asking for help to developers who have experience on this area. The subject is related to unlock the bootlaoder, fastboot and custom rom. I understand the task is not simple, I am looking forward to donate whoever hacks the non generic feature.
What we do:
We provide video service through LG D680 cell phone (Also known as LG Pro Lite D680), the phone has 3G connection and is plugged to the power supply when is working.
Problem:
Most of the day the phone is plugged and working properly, however when the weekend comes the cell phone is unplugged and the energy is completely consumed. Currently, when the power is back to the cell phone we need to start the cell phone MANUALLY by pressing the power on button.
Goal:
We need the phone to be booted into the OS automatically when is plugged into the power USB cable (the phone initial status is powered off).
Possible Solutions / Alternatives:
Unlock the bootloader and run fastboot command fastboot oem off-mode-charge 0.
Continue our research, based on the steps described below (see LG D680 experience)
Replace charge animation with boot file command /system/bin/reboot (see Huawei experience below replacing ipod file).
Finding a custom ROM that already contains a Boot on Charge behaviour.
Finding a custom ROM that at least has “Power On Schedule” feature (AOSP certificate permissions level).
Finding a generic Android vestion with “Power On Schedule”.
Cellphone specifications:
PLATFORM
OS - Android OS, v4.1.2 (Jelly Bean), upgradаble to v4.4.2 (KitKat)
Chipset - Mediatek MT6577
CPU - Dual-core 1 GHz Cortex-A9
GPU - PowerVR SGX531
Previous work and research:
We did this "boot on charge" research in two types of cell phones. One is HUAWEI G730 and the other is LG D680. Fortunately, it worked fine in G730, but we haven’t the same results up to now on LG D680.
In Huawei G730, we replaced charging animation located at /system/bin/ipod with an ipod file containing “/system/bin/reboot” and worked like charm!
LG D680, we could not find the animation file, but we found that it might be inside the boot image. We did some research in order to modify it, but we got blocked (someone might continue our steps if useful).
HUAWEI G730 Extended Procedure:
Since this phone has a Mediatek chipset, the “battery animation” app is running on /system/bin folder. Is running with the filename ipod. The main task is to exchange ipod content (which is originally binary) to an ipod file with this content: /system/bin/reboot.
So, create a brand new file called ipod, and wrote the line in there. We transferred the file to the phone via adb push, as shown in next steps below.
Copy procedure: So, we set our phone to USB Debugging Mode, then we connected it to the PC, and run the following script:
adb shell mkdir /storage/sdcard0/carga/ (We created a folder to store files being pushed from the PC to the phone)
adb push ipod /storage/sdcard0/carga/ (We are pushing the file to the storage folder within the phone)
adb shell "su -c 'mount -o rw,remount -t ext4 /dev/block/mmcblk0p5 /system'" (This step is very important, here we remount the /system folder with read-write permissions. Only doing this we will be able to copy programmatically the “hacked” file ipod to /system/app. Look out that we used mmcblk0p5 because the system folder is mapped there in this phone. You can check this running cat /proc/dumchar_info)
adb shell "su -c 'chattr -i /system/bin/ipod'" (doing this we took out immutability to the original file ipod)
adb shell "su -c 'cp /system/bin/ipod /storage/sdcard0/carga/ipod.old'" (just creating a backup file from the original ipod)
adb shell "su -c 'rm /system/bin/ipod'" (here we are removing original ipod file)
adb shell "su -c 'cp /storage/sdcard0/carga/ipod /system/bin/'" (now we copy the new file ipod to the destination folder)
adb shell "su -c 'chmod 755 /system/bin/ipod'" (change the permission ro rwx-rx-rx)
adb shell "su -c 'mount -o ro,remount -t ext4 /dev/block/mmcblk0p5 /system'" (we remount the /system folder with read-only permissions)
adb shell "su -c 'reboot'" (Finally we reboot the phone)
RESULT: Whenever you plug in the phone to the charger when it is off, it will try to boot on the battery animation, but instead, it will be redirected to a “reboot” command, which in turn will be redirecting execution to the O.S.
LG D680 Procedure:
We found that this phone also has a Mediatek chipset. Moreover, it also has a file called ipod within /system/bin. But in this case, the bootloader image doesn’t call ipod whenever it displays the battery animation. So we had to check where is mapped the boot image on the phone by executing adb shell "cat /proc/dumchar_info". As the picture shows, the boot image (bootimg) is mapped in /dev/block/mmcblk0, from offset 0x1200000, and with size 0x900000.
We tried the following steps, in order to test if we were able to download / upload booting without bricking the phone:
We copy bootimg partition to boot.img by doing adb shell "su -c dd if=/dev/block/mmcblk0 of=/storage/sdcard0/boot.img bs=1024 skip=18432 count=9216’. (Skip and Count are measured on KBytes, and those values are offset and size translated from hexa to dec).
Then we did the inverse operation by executing: adb shell "su -c dd if=/storage/sdcard0/boot.img of=/dev/block/mmcblk0 bs=1024 seek=18432”
RESULT: The phone WASN’T bricked, and reboot normally (obviously without any change on bootimg).
Because these steps worked, we went even further, this time by unpacking and repacking boot.img file. The steps done were:
Same as (b)
We pulled boot.img file from the phone to a folder within the PC, and then we unpacked the image with bootimg.exe as the picture shows below. One interesting fact is that the pulled file sized almost 9MB.
Then we repacked it without any change inside the image, as the picture shows below. The “repacked” image is now on file “boot-new.img”, but its size is almost 7.4MB. We don’t know why we have this difference.
Same as step (ii) on (b).
RESULT: The phone resulted in a SECURITY_ERROR. It is weird because we didn’t change anything. We didn’t tried further since we are not able to unpack-repack the same image, and loading it successfully.
Edited: The security error can be avoided please follow the just below instructions.
Avoid Security Error:
In order to avoid the security error above mentioned, you need to edit the default.prop file (located at /bootimg/initrd)
Change the value from 1 to 0.
FastBoot Note LG:
Fastboot is a solution performing these commands, the problem is that the bootloader is locked for these operations on the generic vesion:
fastboot oem unlock
fastboot oem off-mode-charge 0
fastboot oem lock
fastboot reboot
The command "adb reboot bootloader" does not enter on fastboot upon reboot. There seems to be an opened option while booting on "Download Mode". What I did find out is that when you go into "Download Mode" a new ADB Device is detected on my computer however no driver matched the device. I assume fastboot could be avilable on Download Mode. I have been suggested by romulocarlos to Install the drivers on LG's website however did not work out.
Files:
For making the tests your will need the system.img, boot.img images files. If you brick your phone and want to un-brick the phone please follow this guide [Guide] LG G PRO LITE- Unroot/Unbrick - flash official factory firmware. Currently we are using this kdz image.
Forum:
G Pro Lite D680 Android Development at Android General.
XDA considered the case and opened a new forum for the phone. Thanks very much laufersteppenwolf (aka Wolf), MikeChannon (forum moderator) and svetius.
Conclusion:
We have reached this spot and need help from more advanced hackers. As you guys can see, we have been working hard to trying to hack the boot-on-charge feature on the D680 however has not been yet possible. There is no precedent on this phone on custom CWM & TWRP and custom roms yet therefore the is no out of the box solution as on many other phones (i.e. cyanogen list). We have also tried XDA University practices with no results.
I am ready to donate whoever would help us in solving this problem, its an urgent matter that needs to be solved as soon as possible. I will reward a developer by making a donation.
Appreciate very much the help in advance and reading.
Best,
Jose
Well, it's not that easy without having the actual device, but it'd help quite a bit if you could upload a system dump as well as the boot.img
laufersteppenwolf said:
Well, it's not that easy without having the actual device, but it'd help quite a bit if you could upload a system dump as well as the boot.img
Click to expand...
Click to collapse
Hi laufersteppenwolf,
Congratulations for your achievements and career, amazing.
I am hereby sharing two link resoruces to download what you have asked for, system.html containing the system.img and boot.html containing boot.img. Please let me know if you have problems downloading.
I understand the side effects of not having the cellphone by your side, hope we can mitigate it with the image files you are asking. As extended solution I can open a vnc session or whatever remote tool you can consider.
Thanks so much for the answer and support.
Best,
Jose
JoseVigil said:
Hi laufersteppenwolf,
Congratulations for your achievements and career, amazing.
I am hereby sharing two link resoruces to download what you have asked for, system.html containing the system.img and boot.html containing boot.img. Please let me know if you have problems downloading.
I understand the side effects of not having the cellphone by your side, hope we can mitigate it with the image files you are asking. As extended solution I can open a vnc session or whatever remote tool you can consider.
Thanks so much for the answer and support.
Best,
Jose
Click to expand...
Click to collapse
I am DL'ing the files now, but please use another hoster, as 4shared is not allowed on XDA
laufersteppenwolf said:
I am DL'ing the files now, but please use another hoster, as 4shared is not allowed on XDA
Click to expand...
Click to collapse
Hi laufersteppenwolf,
Thanks for clarifying, I was not aware 4shared was not allowed. I am changing the hosting and updating the link.
Cheers,
Jose
Alright, what I have done so far is I have unpacked the boot image and the ramdisk, edited the ramdisk so it shoud execute /system/bin/reboot when the phone boots because of the charger. Then I repacked both and signed the boot.img again so the bootloader would accept it.
The result, however, is a bootloop. I am just not yet sure whether it is caused by a "false alarm" (the ramdisk always thinking the phone is being booted because of a plugged in charger) or caused by either the bootloader or other low-level security checks. But I also doubt that, as the bootloader seems to accept the repacked image (doesn't show the security error screen).
But I currently do not have any logs, which is why all this is wild guessing. So the highest priority now is to get some proper logs so I know what's going on
laufersteppenwolf said:
Alright, what I have done so far is I have unpacked the boot image and the ramdisk, edited the ramdisk so it shoud execute /system/bin/reboot when the phone boots because of the charger. Then I repacked both and signed the boot.img again so the bootloader would accept it.
The result, however, is a bootloop. I am just not yet sure whether it is caused by a "false alarm" (the ramdisk always thinking the phone is being booted because of a plugged in charger) or caused by either the bootloader or other low-level security checks. But I also doubt that, as the bootloader seems to accept the repacked image (doesn't show the security error screen).
But I currently do not have any logs, which is why all this is wild guessing. So the highest priority now is to get some proper logs so I know what's going on
Click to expand...
Click to collapse
Hi Wolf,
Great advance! Keep the great work up .
I have made some modifications on the original post. Yes you are right, the bootloader friendly accepts the original image and we have figured out the security error. We have found on our end that you need to edit the default.prop file (located at /bootimg/initrd) and set ro.secure to value 0. I also added the files to the post (yet to change the server origin on the boot.image though), added the kdz image to unbrick. Also appended the new forum for the phone.
I appreciate that you have favored to create the forum for the G Pro Lite D680 Android Development. Its great that we can help the community with our achievements.
Best,
Jose
JoseVigil said:
Hi Wolf,
Great advance! Keep the great work up .
I have made some modifications on the original post. Yes you are right, the bootloader friendly accepts the original image and we have figured out the security error. We have found on our end that you need to edit the default.prop file (located at /bootimg/initrd) and set ro.secure to value 0. I also added the files to the post (yet to change the server origin on the boot.image though), added the kdz image to unbrick. Also appended the new forum for the phone.
I appreciate that you have favored to create the forum for the G Pro Lite D680 Android Development. Its great that we can help the community with our achievements.
Best,
Jose
Click to expand...
Click to collapse
ro.secure doesn't trigger the security checks, this prop is only for other things like adb on early boot, enabling adb remount, adb as root by default,...
I also set ro.secure to 0 in the builds I sent you, so that's not the cause of the issue
@JoseVigil
I have some pretty good news The phone now does exactly what you want it to do, as soon as you plug in the charger, the phone boots into offline charging mode, but then directly reboots again into the normal system.
The reboot is not that nice, but it's by far the easiest, as well as safest, way to do it.
Turns out, LG did a pretty sloppy job, giving me adb access to the device when in offline charging mode, giving me the chance to read which process is running and patching the binary to run my hack before actually executing the binary. And that's it. A few lines of bash code and you're good to go
Now my question, do you want me to write a tiny script to do all the work patching the system, or shall I just explain what to do?
laufersteppenwolf said:
@JoseVigil
I have some pretty good news The phone now does exactly what you want it to do, as soon as you plug in the charger, the phone boots into offline charging mode, but then directly reboots again into the normal system.
The reboot is not that nice, but it's by far the easiest, as well as safest, way to do it.
Turns out, LG did a pretty sloppy job, giving me adb access to the device when in offline charging mode, giving me the chance to read which process is running and patching the binary to run my hack before actually executing the binary. And that's it. A few lines of bash code and you're good to go
Now my question, do you want me to write a tiny script to do all the work patching the system, or shall I just explain what to do?
Click to expand...
Click to collapse
You are the man Wolf!
Its great that you have been able to find a workaround.
Yes, ideally both. I would appreciate if you can write the script so we can run it on our rooted phones pragmatically and a brief description of what it does (comprehensive from reading the script too) with implementation steps to reproduce too.
With the script I will do the proper test on my end and provide you feedback in case we have an issue. I will place the donation the coming week early on right after the test, I will be pleased that you get your reaward .
Once that, I think It would be pertinent though that we can expose how far we have reached with our research. If you agree, we can set the ground for someone (either me or you or anyone) to get a bootable customized boot image and unlock the door for CM.
I would love to see this running on CM. But I also know we have to be realistic, as you mentioned, this could be a hell of a work to have a working custom recovery, the device tree and blobs with kernel (almost XDA University I have not been able to deal with too).
It has been a lot of fun and a pleasure to know you and interact with you. I hope this is our first experience.
Thanks very much for the great work.
Best,
Jose
JoseVigil said:
You are the man Wolf!
Its great that you have been able to find a workaround.
Yes, ideally both. I would appreciate if you can write the script so we can run it on our rooted phones pragmatically and a brief description of what it does (comprehensive from reading the script too) with implementation steps to reproduce too.
With the script I will do the proper test on my end and provide you feedback in case we have an issue. I will place the donation the coming week early on right after the test, I will be pleased that you get your reaward .
Once that, I think It would be pertinent though that we can expose how far we have reached with our research. If you agree, we can set the ground for someone (either me or you or anyone) to get a bootable customized boot image and unlock the door for CM.
I would love to see this running on CM. But I also know we have to be realistic, as you mentioned, this could be a hell of a work to have a working custom recovery, the device tree and blobs with kernel (almost XDA University I have not been able to deal with too).
It has been a lot of fun and a pleasure to know you and interact with you. I hope this is our first experience.
Thanks very much for the great work.
Best,
Jose
Click to expand...
Click to collapse
Alright, in the attachment I have uploaded the script, including all needed files in order to execute it. The script will also tell you what it's about to do before doing it, so in case you run into issues, you know where to look into
So, what the installer script is going to do:
It will first of all push a script temporarily to the internal sdcard, then it will back up /system/bin/rtcd to /system/bin/rtcd_original, as we need to execute it later again. Next it will copy the script over from the sdcard to /system/bin/rtcd, replacing the original binary (and setting the correct permissions to both modified files). As the last step it will delete the temp file from the sdcard again.
That's all the installer script does.
The actual "magic" is inside the script being pushed to /system. It gets executed before starting chargemon and reads out the devices boot mode. If the boot mode is charger, it executes /system/bin/reboot. Otherwise it executes the original binary in /system/bin/rtcd_original.
And that's about it As simple as it could only be
Regarding further development, up until now, every device I own received a werewolf kernel, and I'm not planning on making an exception for this phone
I will definitely keep on looking into it, though it will not be as high on my priorities list as this workaround was
I will most likely open a new thread in the next couple of days, stating my findings regarding the phone/boot image/bootloader.
@JoseVigil @laufersteppenwolf
I'm New In Rom Developing . But I Think This Can Help You To Find Security Checks
I need lg g pro lite dual d686 custom twrp recovery i cant find anywhere plz provide working recovery link for d686 as iam new it seems custom recovery for specific d686 dosnt exits so share tested link for d686
Sent from my LG-D686 using xda Forums PRO
Hello I need boot on charge on my LG E460 with MTK. I done ipod change, rctd replace from laufersteppenwolf file without results. I can't went into fastboot mode of course to set oem mode charge for 0
Phone have root, bootloader unlock, busybox and supersu. Any suggestions?
Maxjimme said:
I need lg g pro lite dual d686 custom twrp recovery i cant find anywhere plz provide working recovery link for d686 as iam new it seems custom recovery for specific d686 dosnt exits so share tested link for d686
Sent from my LG-D686 using xda Forums PRO
Click to expand...
Click to collapse
TWRP RECOVERY
http://forum.xda-developers.com/optimus-g-pro/d680-development/d686-unsecured-boot-img-twrp-2-8-7-x-t3163144
Same Problem here with LG E460. Is there a solution for fastboot mode with this device?
hi, do you think this script could work on a LG G Pro 2 ?
hi guys, any chance i could get this working on a chinese mediatek device running kitkat 4.4.2 ??