Related
hey everyone, this all started when i began to try and get my sd partitioned for apps. i have the stock rogers fw with haykuro's root based off cyangens recovery? anyway, i got the partition to work and all and even copied files over. my only problem is that the ext2 does not mount unless i do it manually from the terminal on device. i have come up with an init.rc file that i believe should work. currently it is in /etc
Code:
on boot
export PATH /data/busybox
mount -rw -t ext2 /dev/block/mntblk0p2 /system/sd
on device-added-/dev/block/mntblk0p2
mount -rw -t ext2 /dev/block/mntblk0p2 /system/sd
any ideas?
Tried lucids script to do everything?
http://forum.xda-developers.com/showthread.php?t=480582 I mean I know that rom you have has a adds2sd thing in it, but I can only speak with what I use and know. =)
i'll check it out, but my rom is stock. there is no apps2sd in it. i just partitioned and was going to set up some links when i realized the partition wasn't mounting on it's own. thanks for the link though
The init.rc isn't a shell script, and doesn't run normal commands - its built-in mount command has a different syntax from normal mount. Check out the source or other init.rc files for the syntax.
gwydionwaters said:
i'll check it out, but my rom is stock. there is no apps2sd in it. i just partitioned and was going to set up some links when i realized the partition wasn't mounting on it's own. thanks for the link though
Click to expand...
Click to collapse
Check your PM
i figured it out a little, i have noticed that the init i create is being overwritten when i reboot. i would assume perhaps i need to add the modified file into the system.img and then flash that version on? does that sound right to anyone?
The init is flashed during boot. Its in the boot.img. you can check the stickys to see how to crack one open and put it back together. Ill fix it for you this weekend as promised. Ill even show you what I did but I gotta get time at my computer. Patience my internet friend, patience.
Edit
Also check the "all you need to know" post by haykuro. Its the most recent thread started by him in this forum I believe
If you are using a stock rom did you get the modified mount.conf that supports partition mounts?
lol no i didn't know there was one. i did modify my mount.conf on my own and added the entry for the ext.
i'm having some serious trouble unpacking my boot image, and yes i have read all there is to read and then some. i originally tried unyaffs on the image i got from my nandroid back up i made before root, but it was claiming a broken image. so i made a current back up and tried that boot, the same problem. i figured maybe the nandroid backup utility was creating bad images so i went another route. i started on device and created an image of my boot mount
Code:
cat /dev/mtd/mtd2 > /sdcard/boot.img
i stripped off the header and kernel, saved the remainder as a raw file. then
Code:
gunzip -c boot | cpio -i
and it sort of works, maybe with errors and then asks for the name of archive 2 ..
cpio: Cannot identify format. Searching...
cpio: Cpio file name length 46200 is out of range
cpio: Invalid header, starting valid header search.
cpio: Cpio file name length 6960 is out of range
cpio: Cpio file name length 40367 is out of range
cpio: Cpio file name length 21330 is out of range
gunzip: /device/here/boot: decompression OK, trailing garbage ignored
cpio: End of archive volume 1 reached
ATTENTION! cpio archive volume change required.
Ready for archive volume: 2
Input archive name or "." to quit cpio.
Archive name >
Click to expand...
Click to collapse
and if i enter anything it can't find/read the file (the one i named of course) and if i quit there is nothing gained, no files or anything
AS MENTIONED IN THE INTRODUCTION TEXT THIS HAS ONLY BEEN TESTED ON AMON RA ROM 1.6.2 BUT SHOULD REALLY WORK ON ANY ROM THAT HAS NO EXT2 AUTO-MOUNT. AND YEAH THIS WHOLE PROCESS HAS BEEN DONE ON A 32a BOARD. FOR THOSE THAT TRY THIS ON OTHER ROMS LET ME KNOW HOW IT GOES.
I've searched and shuffled through the entire forum and made inquiries to ROM authors without much light being shed on this issue. I doubt I am the only one who has been looking for a way of doing this so I decided to do a small HOW-TO. Here I will explain step by step as to how you can implement a script to be part of your ROM that will auto mount an ext2 partition on boot up if such partition is present. I have included all the tools I've used in order to pull this off, and as the title suggests this has only been done on Amon Ra's latest 1.6.2 ROM. In order to follow these instructions you are expected to allready have set up an adb enviroment on your linux box and for the signing process to work you must have sun-java present, the gnu java wont work. And of course a microSD card with an ext2 partition
1. Download install.sh to your home directory
Code:
wget http://www.grindhouse.no/androidtools/install.sh
chmod a+x install.sh
2. Now execute the install.sh script which will create a directory to work in and download a tool and script package and unpack it.
Code:
./install.sh
When the install.sh script is done you need to move the mkbootimg preferebly to your tools directory of your SDK.
Code:
mv toolstomove/mkbootimg <path/to/sdk/tools/mkbootimg>
3. Unpack the RA1.6.2 ROM into a directory in your home dir. In this HOW-TO we will use directory name "ra1.6.2" as an example through out the entire process.
4. Copy the boot.img from ra1.6.2 to the ROM-cooker dir
Code:
cp $HOME/ra1.6.2/boot.img $HOME/ROM-cooker/boot.img
cd $HOME/ROM-cooker
5. Use unpack.pl to extract the ramdisk from the boot image. I've modified the script a little so it automates the entire process and decompresses the ramdisk to a directory
Code:
./unpack boot.img
6. Now you can either replace the init.rc file here with the one I've included in this package or you can add these lines by yourself. In wich case do the following
Code:
cd boot.img-ramdisk
pico init.rc
Press CTRL+w and then CTRL+t and input 27. hit enter. This will take you to line 27 of init.rc so you can add a line right before the init process remounts the rootfs in read-only mode. Add following line:
Code:
mkdir /sdext2 0771 system system
Now scroll down to the end of the init.rc file and add the following:
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
7. You have now edited (or replaced) your init.rc file and prepared it to execute a script on boot that will detect an ext2 partition and boot it if there is one to be found. Now you have to make the mountsd script a part of the ROM. Do the following:
Code:
cd $HOME/ROM-cooker
mv toolstomove/mountsd $HOME/ra1.6.2/system/bin/mountsd
rm -rf toolstomove
8. Now that the init.rc file is sorted out and mountsd has been placed in /system/bin of the ROM so it is time to re-pack the boot.img:
Code:
cd $HOME/ROM-cooker
./repack boot.img-kernel boot.img-ramdisk boot.img
rm $HOME/ra1.6.2/boot.img
mv boot.img $HOME/ra1.6.2/boot.img
9. Your ROM now has a new boot image with an updated init.rc and the /system/bin dir has the script needed to auto-mount the microsd ext2. Now you must re-zip the ROM and sign it. Do the following:
Code:
cd $HOME/ra1.6.2
zip -r update.zip *
mv update.zip $HOME/ROM-cooker/update.zip
cd $HOME/ROM-cooker
./sign.pl update.zip
10. The ROM is now signed and you now have a file called update-signed.zip. Connect the phone to your computer and execute thus:
Code:
./push update-signed.zip
11. Now you are ready to flash the modified ROM which will auto-mount an ext2 partition on your microSD. There is no need to wipe before flashing. If you have no prior experience with ROM flashing or whatever just backup your current install. If you're using OpenHOME or anything similar, nothing will be changed or damaged but if you're using MontAlbert's themes with the ROM you will have to flash them again after flashing this modified ROM.
Code:
adb reboot recovery
12. Flash from choose zip and of course choose update-signed.zip. Reboot. After the system boots up again you can now check whats what with either one of the commands:
Code:
[email protected]:~$ adb shell mount | grep sdext2
/dev/block/mmcblk0p2 on /sdext2 type ext2 (rw,noatime,nodiratime,errors=continue)
[email protected]:~/boot$ adb shell busybox df -h | grep sdext2
/dev/block/mmcblk0p2 893.7M 13.0K 846.0M 0% /sdext2
13. Voila! Your RA 1.6.2 ROM now detects and mounts your microSD ext2 partition on boot. Woohoo?
I hope the HOW-TO was easy reading and that you have succeeded in hacking up your ROM. I know that certain ROMs have this as a built-in function but Amon Ra's does not. But since alot of people including myself use his ROM because of the high speed and stability I thought I should contribute to his project and add a cool (and missed?) function to it.
Mind you that you can use the ROM-cooker set to further adjust and hack up the ROM as you see fit. Happy learning!
Very nice!
Now the question many people will ask : why would you automount ext2 if you don't use apps2sd ?
I personally have ubuntu on my ext2 And besides this approach can be used for a number of things, people who have had the need, or wanted to experiment with init.rc doing things on boot, the mountsd script can easily be altered to do what ever needed.
For me its been a learning curve finding these things out, so by sharing it I may spare some people breaking their backs over this whole init.rc thing. people may want to modify init.rc for whatever reason, so I'm sure people wont have a problem finding a way of putting this to use, and its a subject that isnt all that covered on the forum .. and hey .. at least they get a rom kitchen out of the whole shabang
Very interesting! Thank you.
I used your unpack-program to unpack a recovery-image. It seems to work fine. What I am trying to do is change the state the recovery-image returns the phone to. Would it be possible to just replace your mountsd-script with, for example, a script that installs apps? Or is there a better way to do what Im trying to achieve?
Cheers,
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
sandis84 said:
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
Click to expand...
Click to collapse
That's indeed all you need to do.
Hi!
So I tried to create a signed update.zip, but it failed. It didnt create a "update-script"-file, so my device refused to install it. I wrote my own "update-script"-file, but then it complained "no digest" for the file. How do I solve this?
post the contents of your script people might see whats up
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
Says where its at in the first line : )
Code:
wget http://www.grindhouse.no/androidtools/install.sh
But now that I checked, I have to apologize, I see I have a missed payment with my hosting, I'll fix that within the day. Also sorry I havent been answering the few questions here I've been afk cause of surgery.
sitimber said:
post the contents of your script people might see whats up
Click to expand...
Click to collapse
well, I looked in another "update-script" file and found this:
assert compatible_with("0.2") == "true"
assert getprop("ro.product.device") == "dream" || getprop("ro.build.product") == "dream"
show_progress 0.5 0
write_radio_image PACKAGE:radio.img
show_progress 0.5 10
Click to expand...
Click to collapse
So I figured that nothing was essential other then the line "write_radio_image PACKAGE:radio.img". Also ofcourse I made sure it contained the name of my image-file instead of "radio.img". This gave me the "no digest" message, so now I feel unsure on how to create a working update.zip.
edit:
SOLVED! How silly of me. When you sign the update, a hash of each file is put in manifest.mf. Since I added the update-script after signing the file, ofcourse the digest(hash) was missing. Now everything works alot better and I can proceed... until I get stuck again
Cheers,
edit2:
Just to get a better understanding, what exactly does each line do here? Or where can I read about this?
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
edit3:
Ok, so I have experimentet, but I still dont manage to solve those last steps. I tried to edit init.rc and just add "mkdir /testdir 0000 system system" where the other directories were created. I then repacked it, zipped it, signed it, put it on my sdcard, started up a custom recovery, installed the update and rebooted. Everything seems to work fine. But when I start adb and check around, I dont see the "testdir"-directory. Also when I check in init.rc my line is gone. Do you guys have an idea of where I went wrong?
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
it doesnot necesarily have to be linux ...you can also do it in windows using cygwin and dsxda's android rom kitchen
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
-miska- said:
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
Click to expand...
Click to collapse
Here is what I've done. If you have successfully built a kernel with the resulting zImage, then you are part way there, I believe there is a kernel config option to enable kexec support but I haven't tried that. Next, you can take some other kernel's .zip file (CWM flashable) and unzip it. You may need to download a zip utility. You'll have 2 folders and a kernel blob. If you bootunpack this kernel blob, you'll end up with the kernel blob and a some *.LNX file. This *.LNX file is the same as a boot.img file. You can use dsixda's Android kitchen to split this into the initrd and the kernel (zImage) parts. Replace the zImage with your own and move any modules you may have also built if necessary into the initrd part, join them back together into a boot.img in the kitchen.
copy this boot.img back to where you unzipped the kernel.zip, delete the original *.LNX file, rename the boot.img to the same name as the previous *.LNX file and then bootpack it together and flash it through CWM. Zip the 2 folders and the kernel blob you just made back together with whatever name you want. You can edit the text in the updater script before you zip it all up, but whether you do or not it should boot.
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot :-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
-miska- said:
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot d:-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
Click to expand...
Click to collapse
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
sidneyk said:
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
Click to expand...
Click to collapse
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
https://github.com/koush/AnyKernel
Good luck -
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
sidneyk said:
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
Click to expand...
Click to collapse
hmmm, checked that one, uses blobed image and 'dd if=/tmp/blob of=/dev/block/mmcblk0p4' as well. Maybe I'll try different crosscompiler anyway, that's the one thing I haven't altered yet :-/
hachamacha said:
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
Click to expand...
Click to collapse
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
-miska- said:
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
Click to expand...
Click to collapse
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
hachamacha said:
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
Click to expand...
Click to collapse
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
lilstevie said:
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
Click to expand...
Click to collapse
OK: Thanks lilstevie,
That takes care of that. Time for me to make peace with blobs.
After steve's reply, I just went to using blobs. I've got my own kernel running fine on the tf101 using that method.
For the best reference I've seen on using blobs and boottools , try this post:
http://forum.xda-developers.com/showthread.php?t=1193737
---
Just got back from work, will ply with it some more, but I'll start with answering the questions...
hachamacha said:
1) Your linux distro and architecture (x86/x86_64)
Click to expand...
Click to collapse
Gentoo x86-64
hachamacha said:
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
Click to expand...
Click to collapse
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
hachamacha said:
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
Click to expand...
Click to collapse
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
-miska- said:
Just got back from work, will ply with it some more, but I'll start with answering the questions...
Gentoo x86-64
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
Click to expand...
Click to collapse
Pretty similar, although the kernel zImage itself is always a mystery unless you've not changed anything, but even then, getting it built with the right toolchain, etc isn't guaranteed. So lets assume that just works for now since it'll become obvious as it goes along.
I guess I have not heard of 'abootimg' as a tool for this, so I've been using the more manual way of dissecting the initrd as follows:
Code:
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
If you need to change something , for example, in default.prop like ro.secure=0, then you'd do it there.
Then repack into a new ramdisk:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Finally I just had a somewhat heavily modified zImage from my build, so did this to make the blob (I'd copied zImage to blob.LNK-zImage.gz below):
Code:
./mkbootimg --kernel blob.LNX-zImage.gz --ramdisk newramdisk.cpio.gz -o boot.img
./blobpack blob.HEADER newblob LNX boot.img
zip -r imagename.zip blob MET* system // whatever the syntax was.
NOTE: I did this on a native 64 bit ubuntu LTS 10.04 box.
Unless I typo'd up there, that 'should' work. If it does boot, then first thing, take a look at settings, and kernel info so you can verify that you're running the kernel you desired (hopefully you renamed it in Makefile the first 4-5 lines).
Solved
Ok, got it working!!! Problem was bad crosscompiler :-( Modules I crosscompiled worked fine, so I ruled crosscompiler out :-/ Looks like I was too quick in judgement :-( Now I have kernel recompiled with original settings and evne the modified one and it still works and boot. Now I'm going to play with new features I got! Thanks a lot for all help!!!
Just for the record, crosscompiler I was originally using was codesourcery 2011.03 and to make it work I switched to official crosscompiler from NDK. Rest of the commands was Ok, I was just suspecting wrong step as I was quite familiar with kernel building and quite unfamiliar with the blob stuff :-(
Congrats!
For some reason I avoid the codesourcery stuff and stick with either the prebuilt toolchains or else just build my own from gnu source.
Anyway, glad you figured it out.
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
sidneyk said:
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
Click to expand...
Click to collapse
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
hachamacha said:
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
Click to expand...
Click to collapse
If by 'native' you mean a hard disk install as opposed to a VM install, then that's where I'm at. I have Ubuntu 11.10 x86_64 installed to a separate partition. I have the recommended stuff installed including the ia32 libs, but I never see a blob.HEADER file with either kernel.zips or ROM zips. I can unpack and repack kernels without the HEADER though and they boot just fine.
But, yes, if you don't mind posting a link with your files I'll give them a try sometime. Thanks.
Introduction
Hi guys, so im seeing a real lack of dev work going on in these forums so here i going to make a guide on making a custom rom and a custom kernel for the optimus 3d. XDA's about sharing so im going to tell you nearly everthing i know to get you started. This is no means the best/definative way as im still learning alot myself only starting this kind of stuff about 6 months ago. I dont call myself a dev so there could be things wrong but here is how ive made my stuff to share with you. Ill probably update these posts as time goes on too, to improve & answer questions. Plus ill probably forget something too. Plus it would be good if other dev types in this forum could maybe share a few of there words of advice, wisdom & tips. This will hopefully encourage people to use & create for the device.
Chapters/Posts
Post 1- Getting Started
Part 1- Prequisites
Part 2- Getting Necessary Basic Stuff Done For Your Rom
Post 2- Making The Rom Custom & Extra Mods
Part 1- Basic Mods
Part 2- Advanced & More Complex Mods
Post 3- Making The Custom Kernel
Part 1- Getting Set-Up
Part 2- Compiling Your zImage
Part 3- Making Your RamDisk
Part 4- Making Your Boot.img
Post 4- Changelog
Post 5- Dev Bible!
Getting Started
Presquisites
This guide assumes you have some knowledge on how to use basic computer stuff, use other guides in the forum, know how to use a rooted phone & have some general common sense. If you dont what some of this stuff research it before you carry on reading.
Youll need a computer(dugh) with preferably a linux distro like ubuntu 10,11 or 12(for kernels) and windows, xp, vista, 7 & 8 should all be fine. These arent necessety, im sure you can probably complile stuff on windows and on other distro's and versions but this is how ive done my stuff. Again dont ask where to get these.
Youll also need a memeory card with enough room to hold a cwm backup & some mods so 1gb is/should be plenty and fully charged battery too, we wouldnt want the battery to go flat during a risky process would we.
I recommend you also have these apps/tools too, they will make the process alot easier and your gonna need some of them along the way.
For Windows
Kdz flasher or .bin flasher- http://forum.xda-developers.com/showthread.php?t=1287236 Big Thanks To adixtra
Winrar (trial version is fine)- http://www.rarlab.com/download.htm
Or 7zip As Recommended By Pandaball- http://www.7-zip.org
Notepad+ From Here- http://notepad-plus-plus.org/
Megatron Root Method- http://vulnfactory.org/blog/2012/02/26/rooting-the-lg-thrill-optimus-3d/
CWR Flash Tool By Paki0402- http://forum.xda-developers.com/showthread.php?t=1482713
For Ubuntu/Linux
LG's Source Code Page: http://www.lg.com/global/support/opensource/opensource.jsp
Kernel Build Tools- sudo apt-get install uboot-mkimage (In Terminal)
Ramdisk Compile/Decomplie Tool- http://forum.xda-developers.com/attachment.php?attachmentid=1215193&d=1342992085
ARM Toolchain- https://sourcery.mentor.com/public/...-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 (Recommended)
disxda Kitchen- http://forum.xda-developers.com/showthread.php?t=633246
For Yourself
Computer, Preferably Modern Otherwise Things Could Get Slow
Coffee- http://www.starbucks.com/coffee/reserve/galapagos-san-cristobal
Patience
Time (Definatly Dont Ask Me Where To Get This Since I Couldnt Find A Link)
Getting Necessary Basic Stuff Done For Your Rom
Firstly youll need a rom to modify for this you can either download a ready made rip of a rom like from fabio in this thread http://forum.xda-developers.com/showthread.php?t=1155874 or you can make your own. For this youll need to have a fresh kdz flahed to you phone from here http://lg-phone-firmware.com/ or from another source if you prefer .bin. Once you have flashed i recommend just skipping all the setup stuff like market, wifi and accounts stuff since your not gonna need it yet.
Next we need to make a copy of your freshly flashed kdz if you going down this root(no pun intended) otherwise youll already have it in zip format & probably already rooted too. Talking about rooting this will be the next thing you need to do & since were running gingerbread youll need to root with megatron found here -insert link here- follow that guide & thanks to Dan for that breakthrough which without, this probably wouldnt be possible.
After your rooted youll need to get ClockWorkMod recovery. There are two ways you can get it either through rom manager in the Playstore or from this tool here -insert thread here-. Cheers paki for that very useful tool and koush for the recovery. For SU760 people use ibluemind version here http://forum.xda-developers.com/showthread.php?t=1565412 thank you iblue too.
Now were all rooted and have recovery installed we can now make a copy of the entire system. This bit is easy youve all probably done it before too. You will need to boot into recovery either with the button command or through rom manager app. Then just simply make a backup of you rom, while your waiting put the kettle on make yourself a coffee & enjoy a litttle break.
Ok so now we have a base for our custom rom based on whatever version kdz you flashed. Now we need to transfer this to our pc. So go to you backup & simply copy & paste the system.ext3, data.ext3 & boot.img to where you want to do your work, the rest you wont need unless something goes wrong later. The backup is located on the external memory card in the clockworkmod/backup directory.
So we have the necessary parts on your computer, youll need to decompress the system.ext3 and data.ext3 using winrar or other zip app. Then once you have your system and data folders set up you can start the modding but first thing to do is delete anything personal from the data folder so make sure only the app folder remains in the data partition like this data/app and no other folders like app-private, fota & data. If you want you can do away with the data part all together and just keep it simple.
We now have a basic stock rom in its raw form. So now youll need to package it up. For this ill provide a donate install script zip at the bottom of this post for which you can simply drap & drop your system folder and data folder if your including it. Youll also need to drag over the boot.img, this can be one you have made from the guide below, one from your backup folder which would be the stock kernel or one from a kind dev if they will let you use there's.
Thats it you should now have basic stock rom from which you can build upon, just flash it to your phone and test if it works. If you want to get creative i recommend you download and use disxda's Kitchen this will do the extraction part too.
Making The Rom Custom & Extra Mods
Ok guys & gals we now have a lovely stock base zip but its not lovely enough is it, we need to set it apart from from stock. This is where it could get complicated depending on your experience or your understanding on things. First off youll need to scour the realm's of XDA for what you want, but ill give you a few links & mods here that you can try yourself. Just remember not all these may work or be fully compatible with our device. I recommend you try these on your device first before applying them to your rom zip, just in case if they work then go ahead try them in your zip.
Basic Mods
Basic Mods are what i would consider as copy & paste mods like build.prop mods, some simple ready made zip packages such as Beats & Bravia mods and etc tweaks like apn's, hosts, .conf tweaks etc.
Here's some links to some you could try.
Beats- http://forum.xda-developers.com/showthread.php?t=1525226 (Recommend 0314 Package)
Build.prop Tweaks- http://forum.xda-developers.com/showthread.php?t=1631092
Boot Animations- http://forum.xda-developers.com/showthread.php?t=1053250
To apply a build.prop mod simply open your build.prop in the system directory and copy & past them at the bottom of the file like this:
Code:
#
# my build.prop mods
#
dalvik.vm.heapsize=64
Then simply save. In the build.prop you can also change you rom name in the ro.build.display.id= and other small mods too.
Next we want to apply zipped based mod like a boot animation or even Beats mod. There are 2 ways you can do this, so one way for this is to simply download the mod & extract to a folder for example modz folder and copy each file/folder into the relevent directory of your system folder or you can have both your mod zip and rom zip open and simply drag them over to the rom zip from the mod zip. Just be wary if there is a build.prop tweak within like in the Bravia & Xloud mod or text based part of the mod you will have to manually copy the extra lines from one modded one to yours. For example:
Code:
#
# my build.prop mods
#
dalvik.vm.heapsize=64
# Xloud Engine
ro.semc.sound_effects_enabled=true
ro.semc.xloud.supported=true
persist.service.xloud.enable=1
# BRAVIA Engine
ro.service.swiqi.supported=true
persist.service.swiqi.enable=1
Advanced & More Complex Mods
These are the sort of mods that can make a big impact on your rom. Usually involves changing or even coding system variables for asthetic & performance purposes. Things such as framework editing and scripts would come under this category. Although scripts are easy to apply some of them require modifications to get the best or even work with our device. Scripts are placed in the system/etc/init.d directory. You probably wont have this cause your developing from a stock rom, so youll need to create that folder. To enable the use of init.d scripts you will also need init.d support from the kernel, this will be covered later in the guide but if your using a custom kernel youll most probably already have this feature.
Here are some links to some popular script based mods that work well with our device:
http://forum.xda-developers.com/showthread.php?t=1227269
http://forum.xda-developers.com/showthread.php?t=1556013
http://forum.xda-developers.com/showthread.php?t=1236779
Once you have added your scripts we need to edit the updater-script to ensure they have the correct permissions. This is located in your zip in the /META-INF/com/google/android/ directory. To edit open in notepad+ or gedit and enter as below for every script you add.
Example
Code:
set_perm(0, 0, 0777, "/system/etc/init.d");
set_perm(0, 0, 0777, "/system/etc/init.d/01Your1stScriptName");
set_perm(0, 0, 0777, "/system/etc/init.d/02Your2ndScriptName");
set_perm(0, 0, 0777, "/system/etc/init.d/03Your3rdScriptName");
And so on for more scripts then save. If your script needs different permissions, set them according to the authors/devs's instructions.
Now on to deodexing, this isnt necessary but it makes theming your rom much easier later. To do the deodexing i recommend you use disxda's Kitchen. This part of the instruction is based on using Ubuntu but it probably applies to the Windows version too. Its easy and quick to use. Just simply drag the your roms zip into the original_update folder and load up the kitchen. If your using Ubuntu it will ask if you want to run in terminal, select this option. So now you have the kitchen up, go to create working folder for rom, press enter and then select your zip(My1stRom.zip). the kitchen will then ask you about the script just select 2 (do nothing) then press enter again when it comes up with a warning about update-script. Then go to advanced options and select deodex it will ask you whether or not you want to do system apps and some other stuff, just select option b, both folders (recommended). Press enter again at logging. Then this should deodex everthing in you rom. On ocassions there some certain apk's that cant be deodexed, dont worry there's only a few that cant be done. Thats it after about 10-15 minutes, now youre deodexed. This may take longer on a slower pc though. Just press enter again to get to continue and exit to the main menu.
So there we go, youve incorperated your mods that you want, its time to repackage it all up but this time we will use the kitchen to do this. Select 99 Build Rom from working folder, select interactive mode, select yes to zipaligning, select no to adding updater script, select yes to signing your rom, select yes to changing name, enter a new name My1stRom for example.
Now just copy the zip to your phone from the OUTPUT_ZIP directory then flash to you phone and see/feel/hear the difference. If all is well then congratulations you have now made a custom rom. Obviously these are just the begining of modifying your rom there are loads more things you can change and do things different ways but these come with experience and research such as modules and modified libraries, media hacks and such.
Making The Custom Kernel
So this is the post some of youve probably been waiting for & probably going to be the hardest one to write up so im gonna apologise now for my lack of typing & explaining skill You will need a linux distro for this bit, as ive not tryed using compilers for Windows. Any distro should be fine im currently using Ubuntu 12.04 LTS but have sucessfully done this on older versions. Im only going to cover the basic stuff with this guide it would be impossible to show you everything but ill show you a couple of mods to get started like overclock, a few fixes of LG's mistakes (For V21E Base only, other LG kernel's may have there own problems too PM me if your stuck) & changing a few variables stuff.
Getting Set-Up
Ok first off we will need to get our source. You get this from the LG Open Source website, link is attached in the first post. Obviously we want the latest 21E source or if your doing this for P925, get the latest or the one you want for that. Then youll need to download & extract it. This will be fine to do in the 'Download' folder. Once you have extracted it youll have another 2 tar archives. You will want to extract the LGP920_Gingerbread_Kernel.tar.gz, again in the same directory your in will be fine. So now you should have a folder named 'kernel'. Before you can continue we will need to rename the base directory to something more simple like LGP920v21ESource otherwise if you have brackets and other punctuation stuff it will give you a syntax error later.
Next we will need the ARM Toolchain in order to compile your kernel source. This is in the first post, this is the same toolchain that LG uses to compile it. You can use other compilers but you will have to modify a few things to get it working. That is for another post another day maybe. So now we need to extract the toolchain, do this in the same way as before in the 'Download' folder. Now youll have a folder named 'insert proper folder name here' this is your toolchain. Now we have our toolchain and source all unpacked and ready to go, youll need to open Terminal or your prefered terminal app. This next bit will be much easier if you extracted everything in the explanation above. For the next set of instructions just change my user name with yours and if you did the same directories as me this should be simple.
Ok so in terminal cd to inside your kernel like this for expample:
cd /home/samno/Downloads/LGP920v21ESource/kernel
Dont get confused about the kernel directory inside the kernel folder you want to be at the base of the rest of the files.You should have the kernel directory open in file browser too. If you want you can type cd in terminal and then drag the folder in the top of the file manager and drag it into the terminal window where you typed cd, this will save you making typo's and be quicker/easier.
Next we need to set the export/path for our toolchain so in terminal enter this for example:
Code:
export CROSS_COMPILE=/home/samno/Downloads/arm-2010q1/bin/arm-none-linux-gnueabi-
Code:
export PATH=$PATH:/home/samno/Downloads/arm-2010q1/bin
Exporting the path isnt completely necessary but is useful if you want to compile other things than this. Now we should be ready to compile.
Compiling The zImage
First thing we will need to to is edit the makefile in the base directory. Open with gedit and add '+' to the 7 where it says EXTRAVERSION = .7. This will make the kernel compatible with the 21E modules such as wifi. If you are devoloping for sources without a '+' such as 20F you can leave this bit. You could also make your own modules if you wanted but i might cover that later. I dont do this cause it can cause compatibilty problems for people swapping kernel all the time, especially when the kernel they flash isnt compatible with the modules of another kernel for example my kernel uses stock modules found already in the roms we use where as iblue for example compiles and includes his own in the kernel package. If you flash one over another then the modules wont work with another kernel version.
Ok what we want to do next is fix the defconfig for our device or just use a different one in our case. This is located in the arch/arm/configs directory. This was a problem when devs first started compiling to find out when they flashed it they no signal and charging issues when the phone is off. Cause we are meant to use the cosmo_rev_1.11_defconfig but it had cricial lines missing. Only by me messing about did i discover that the lines needed were located in the cosmo_rev_1.11_mipi_defconfig.
So in terminal you should still be in the kernel directory, now enter this command:
Code:
make ARCH=arm cosmo_rev_1.11_mipi_defconfig zImage
Dont worry it come up with loads of stuff as it compiles but i will come to an error which we need to fix before it will continue. The good thing about the complier it will give you a good idea where to look like the file and error location.
So it should come up with something like this:
Code:
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/staging/omap_hsi/xmd-hsi-ll.o
In file included from drivers/staging/omap_hsi/xmd-hsi-ll.c:33:
drivers/staging/omap_hsi/xmd-hsi-ll-internal.h:256: error: expected specifier-qualifier-list before 'if'
drivers/staging/omap_hsi/xmd-hsi-ll-internal.h:434: error: #endif without #if
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_read_complete_cb':
drivers/staging/omap_hsi/xmd-hsi-ll.c:707: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:707: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:708: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:711: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:711: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:713: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:714: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:715: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:718: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:720: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:722: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:722: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:733: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:734: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:736: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:737: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_check_channel':
drivers/staging/omap_hsi/xmd-hsi-ll.c:1476: error: operator '/' has no right operand
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_open':
drivers/staging/omap_hsi/xmd-hsi-ll.c:1642: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:1643: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:1644: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_reset':
drivers/staging/omap_hsi/xmd-hsi-ll.c:2725: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:2726: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:2727: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
make[4]: *** [drivers/staging/omap_hsi/xmd-hsi-ll.o] Error 1
make[3]: *** [drivers/staging/omap_hsi] Error 2
make[2]: *** [drivers/staging] Error 2
make[1]: *** [drivers] Error 2
So lets go to the first error, line 256 of the xmd-hsi-ll-internal.h. Simply add # before 'if defined' like this '#if defined'. Save the file then go back to terminal and enter the make command or press up arrow and press enter. Youll notice alot of errors have gone when it errors out again and it should look like this:
Code:
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/staging/omap_hsi/xmd-hsi-ll.o
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_check_channel':
drivers/staging/omap_hsi/xmd-hsi-ll.c:1476: error: operator '/' has no right operand
make[4]: *** [drivers/staging/omap_hsi/xmd-hsi-ll.o] Error 1
make[3]: *** [drivers/staging/omap_hsi] Error 2
make[2]: *** [drivers/staging] Error 2
make[1]: *** [drivers] Error 2
make: *** [zImage] Error 2
Again fixing this error is like the first one, goto line 1476 of xmd-hsi-ll.c simply delete the '/' like this '#if 1' where it was '#if 1 /'. Save again then back to terminal again where it will you guessed it error out again. Should look like this;
Code:
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/staging/omap_hsi/xmd-hsi-ll.o
CC drivers/staging/omap_hsi/hsi_driver_if.o
drivers/staging/omap_hsi/hsi_driver_if.c: In function 'hsi_ioctl':
drivers/staging/omap_hsi/hsi_driver_if.c:930: error: 'HSI_IOCTL_SET_WAKE_RX_3WIRES_MODE' undeclared (first use in this function)
drivers/staging/omap_hsi/hsi_driver_if.c:930: error: (Each undeclared identifier is reported only once
drivers/staging/omap_hsi/hsi_driver_if.c:930: error: for each function it appears in.)
drivers/staging/omap_hsi/hsi_driver_if.c:945: error: 'HSI_IOCTL_SET_WAKE_RX_4WIRES_MODE' undeclared (first use in this function)
make[4]: *** [drivers/staging/omap_hsi/hsi_driver_if.o] Error 1
make[3]: *** [drivers/staging/omap_hsi] Error 2
make[2]: *** [drivers/staging] Error 2
make[1]: *** [drivers] Error 2
make: *** [zImage] Error 2
Fixing this one will be similar too. If you read the error its says this bit of code hasnt been declared for a function, most probably LG have missed some more code here for it to work or it was left over from testing the ghost call stuff. The only way to get rid of this error that i know of is to do away with the line completely. So go to line 930 of hsi_driver_if.c and delete 'case HSI_IOCTL_SET_WAKE_RX_3WIRES_MODE:' and the space that it leaves and do the same for 'case HSI_IOCTL_SET_WAKE_RX_4WIRES_MODE:'.
Do the make command again and thats it no more errors and it should look like this:
Code:
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy.gzip
AS arch/arm/boot/compressed/piggy.gzip.o
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
SHIPPED arch/arm/boot/compressed/lib1funcs.S
AS arch/arm/boot/compressed/lib1funcs.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Congratulations! Youve just compiled your first kernel.
Making Your RamDisk & Boot.img
Well done! Now we need to package your zImage up into a useable form. This part will be similar to Urabewe's guide here http://forum.xda-developers.com/showthread.php?t=1358717 , kudos to him for such an excellent guide, the only difference is were using our own zImage.Remember the backup you did earlier of your stock rom, were gonna need it again for this part. Firstly were gonna need to make sure we have got the tools to decompress/compress the boot.img. Again you will need a Linux distrubution like Ubuntu to be able to do this. So first off if you havnt got it already, we need to download the packaging tool using terminal. Enter the command as follows:
Code:
sudo apt-get install uboot-mkimage
Good now we need the perl script from the first post. Download and extract it to a folder and call it 'My1stKernel' for example. In this folder paste the boot.img from you stock backup. This will be used as our ramdisk base which we will work from. Now we need to unpack the boot.img but first we need to make sure were in the 'My1stKernel' directory so in terminal:
Code:
cd /home/samno/Downloads/My1stKernel
Then to unpack the kernel:
Code:
./unpack-bootimg.pl boot.img
When completed you will have a new directory inside named 'boot.img-ramdisk' & two gunzip compressed files, 'boot.img-kernel' is the stock zImage and 'boot.img-ramdisk.cpio.gz' is the stock ramdisk. The 'boot.img-ramdisk' contains the decompressed ramdisk contents. First thing to do now is delete 'boot.img-kernel' , 'boot.img-ramdisk.cpio.gz' & the old 'boot.img' since we only need the 'boot.img-ramdisk' cause were editing the ramdisk and using our own zImage. Now copy and paste the zImage you created earlier from the 'arch/arm/boot' directory of the kernel folder into 'My1stKernel' folder.
Now were gonna add some tweaks to the ramdisk to do this open the 'boot.img-ramdisk' folder and open the 'init.rc'.
First were gonna add a cpu variable for the screen off state, this helps save a bit of power.
Where the line says '# switch CPUfreq from performance to hotplug & tune it' add this underneath to keep the max frequency when screen is off to 300mhz:
Code:
write /sys/devices/system/cpu/cpu0/cpufreq/screen_off_max_freq 300000
Next were gonna add init.d support. So after these few lines in the init.rc:
Code:
service bootanim /system/bin/bootanimation
user graphics
group graphics
disabled
oneshot
Add this:
Code:
service userscript /system/bin/sh /sbin/initd.sh
user root
group system
critical
oneshot
This basically tells the system to load this file, which were gonna add next. Now save the file and start a new text document. In the document add this bit of text:
Code:
#!/system/bin/sh
if [ -d /system/etc/init.d ]
then
logwrapper busybox run-parts /system/etc/init.d
fi
sync
This is basically a script that runs the items in the init.d folder at boot so now save it as initd.sh in the sbin directory of your 'boot.img-ramdisk' folder. Youll notice the top command should turn blue, that means you have saved the file in the correct format. Good so now we should package all this up, but if you want you can add more mods to the init.rc like your memory management, more cpu controls, IO controls & lots of other stuff, anyway.
Making Your Boot.img
Almost there now guys! Let's package this up and enjoy the fruits of your labour. Assuming you still have your terminal window open in 'My1stKernel' directory type this command:
Code:
cd boot.img-ramdisk
Then this to compress the ramdisk:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Now in your 'My1stKernel' folder you will have a new gunzip archive named 'newramdisk.cpio.gz' this is the ramdisk you modified earlier. Now we need to bind it with your custom zImage to make a boot.img. So get terminal back up and go back to the previous directory:
Code:
cd /home/samno/Downloads/My1stKernel
Then enter this to combine them:
Code:
mkimage -A ARM -T multi -n newboot -C None -a 0x80008000 -e 0x80008000 -d zImage:newramdisk.cpio.gz boot.img
You should then have a lovely file named boot.img, simply just paste it into the flash package ive provided below for you then flash to your phone through CWR. Thats it, you & me we have come a long way, you should now have a rom and kernel you have made by yourself. Now lets party, unless it dosnt work just restore or flash another kernel . If you need any clarification or help just post in this thread and we can all help each other. Also would love to here your sucess stories if you used my guide and on a final note i want to thank everyone who's ever developed for this device and those who will cause youve helped me so much (even though you probably dont know ) through my entire time with this.
Changelog
To-Do
-Add Over Clocking/Frequency Instructions
-Add Voltage Changing Instructions
-Governors & IO Schedulers
Monday 30th July 2012
-Finished All Posts To A Finished Standard
Dev Bible!
From Pandaball 1 Verse's 1 & 2 http://forum.xda-developers.com/showpost.php?p=29185146&postcount=9
Just a few comments if I may:
I use 7zip over Winrar, it's a pretty badass alternative for something which is free.
Also, making a CWM backup isn't entirely necessary, you can do adb pull /system and the files will be pulled over to your adb directory. Saves you the trouble of extracting the nandroid backups. Normally I don't touch /data at all, just create /data/app and add the necessary lines in updater-script and you're good to go.
Some more tips:
Get the LG source code, it really tells you how Android works and all.
Linux is better than Windows for things like this. Both work fine, but Linux has the compilers and tools.
Test, test and test again. Make sure everything and everything works. Failure to do so (like I do sometimes ) will result in horrible things happening.
CWM's updater-script is a PITA. If there's an install script error, check your syntax. Did you forget a semicolon? A quotation mark? Did you ensure you used the correct command and parameters? If you really have to, weed out your updater-script down to the very basics and debug from there. Nice things such as ui_print are unnecessary until you're sure the basic functionality works.
Finally, doublecheck your permissions. Don't make everything 0777 (rwxrwxrwx) for no reason at all. Assign 0755 only when it's needed by the tweak, else 0644 will suffice. Also, things like su and busybox require special permissions like 4755 and 6755. If you don't assign these permissions, something's bound to break. Make sure your permissions are assigned correctly, else you have only yourself to blame when you bootloop your phone.
tl;dr it sucks to be a developer
Click to expand...
Click to collapse
From Pandaball 1 Verse 3 http://forum.xda-developers.com/showpost.php?p=29298911&postcount=12
Well, since there's an open invitation, might as well crash the how-to-dev party with some scripts you can use right off the bat. They are as attached, feel free to use them.They are a part of the tweaks I use for my rom. Noticeable improvements over stock this way, although they more or less deal with usability rather than performance so benchmarks might not improve as much as you'd expect. Dump them in /system/etc/init.d with permissions 0644 with a kernel that supports init.d (in other words, any custom kernel on this forum) and you're good to go.
However, since we're here, why not study how init.d works? Better to understand what these scripts do and how they impact performance, no?
Disclaimer: Some of these tweaks (like the one I'm going to explain below) were taken from the very awesome knzo (http://forum.xda-developers.com/show....php?t=1227269). However it has a ways to go in terms of explaining what the commands do so this post is entirely dedicated to that.
The scripts are very nicely named, giving you an idea of what they do. However, what do the strange numbers in front mean? Simply put, during bootup the kernel will run these scripts according to the numbers, so 65ZipAlign will run first, followed by 70Ext4Mount and so on.
Now, open 70Ext4Mount using notepad, notepad++, what have you. You'll see a bunch of variables and values, but at the start it is of paramount importance to add #!/system/bin/sh to the first line, else the script will not even execute as there is nothing defined to execute or write these values.
What do the values/commands do, you may ask.
tune2fs -o journal_data_writeback /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Let's analyse this command in sections.
tune2fs is just the code that runs the commands that follow after it.
-o journal_data_writeback tells tune2fs to write to the filesystem to enable journal data writeback. This typically provides the best ext4 filesystem performance.
/dev/block/mmcblk0p7 is the partition to apply the above commands to. In this case, mmcblk0p7 is /system.
Now, the other command is this
tune2fs -O ^has_journal /dev/block/mmcblk0p7
Click to expand...
Click to collapse
This time, the parameters are slightly different.
-O ^has_journal removes journaling, which is basically a filesystem log service. It takes up system resources, so removing journaling will improve system responsiveness. Note that -o and -O are different, the parameters are case-sensitive. -o configures the mount/filesystem options, -O enables/disables features.
Finally, at the bottom you get this line
busybox mount -o remount,noatime,noauto_da_alloc,nodiratime,barrier =0,nobh /system
Click to expand...
Click to collapse
As seen, the above is just a bunch of parameters. What do they all mean?
busybox mount -o mounts the partition named at the end, which is system. -o enables the mounting options.
remount, well, remounts the partition with the options named.
noatime disables the filesystem from writing the last accessed time to each file. When enabled, every read operation must have a write operation to write the last access time. With this option, only the read operations are done, removing the need for a write operation as well, giving a significant I/O boost.
noauto_da_alloc is a bit complex. When a file is edited in Linux, a new file is created containing the changes, then when it is saved, the new file is renamed and overwrites the old file. In ext3, it causes no problems since ext3 guarantees that either the old or new data will be on disk (when I say disk, it really means memory/eMMC) due to its default journaling mode. However, ext4 delays allocation, and thus the new file contents may not be written to disk before the file is renamed. Because of this, Linux kernels force the data to be written immediately which creates a performance hit. Disabling this will improve I/O by a bit. This may not be to everyone's liking since it creates the possibility of losing data, but such a thing has never happened to me. You can remove it if you like
nodiratime is the same as noatime, except this applies to directories being accessed rather than files.
barrier=0 disables the use of write barriers. Write barriers enforce proper on-disk ordering of journal commits, and is usually enabled due to possibility of data loss if power is lost. However because the O3D is a phone, it has a battery and this ensures data will not be lost as the system will not shut off abruptly due to power loss. Removing barriers gives a performance boost.
nobh makes the phone avoid assigning buffer heads. Similar effects to barrier=0, similar dangers.
/system selects the partition to remount.
That's all for 70Ext4Mount. Congrats, you now know how one of the init.d scripts work Now try figuring out the other 3. Google is your friend
This post is meant as a complement to samno's init.d mods, and only covers and explains a small section of what can be accomplished with init.d. I'll cover more when I find time
Click to expand...
Click to collapse
You are the man!!!!I was wondering will someone post something like this and i was to newbie to ask.Thank you good sir!
Sent from my LG-P920 using xda app-developers app
skilovan said:
You are the man!!!!I was wondering will someone post something like this and i was to newbie to ask.Thank you good sir!
Sent from my LG-P920 using xda app-developers app
Click to expand...
Click to collapse
I agree with you, I did notice things seemed pretty mellow here vs other forums, this'll be a great start for those of us that are picky and wanna combine and mess around with stuff. And i wasn't totally sure where to look for kernels and rom building so thanks this should make the community a little bigger. And i'm sure we'd end up providing some better support than lg lol
love it gj cant wait for the custom kernel section cuz thats what i am interested in is building my own kernel
Just a few comments if I may:
I use 7zip over Winrar, it's a pretty badass alternative for something which is free.
Also, making a CWM backup isn't entirely necessary, you can do adb pull /system and the files will be pulled over to your adb directory. Saves you the trouble of extracting the nandroid backups. Normally I don't touch /data at all, just create /data/app and add the necessary lines in updater-script and you're good to go.
Some more tips:
Get the LG source code, it really tells you how Android works and all.
Linux is better than Windows for things like this. Both work fine, but Linux has the compilers and tools.
Test, test and test again. Make sure everything and everything works. Failure to do so (like I do sometimes ) will result in horrible things happening.
CWM's updater-script is a PITA. If there's an install script error, check your syntax. Did you forget a semicolon? A quotation mark? Did you ensure you used the correct command and parameters? If you really have to, weed out your updater-script down to the very basics and debug from there. Nice things such as ui_print are unnecessary until you're sure the basic functionality works.
Finally, doublecheck your permissions. Don't make everything 0777 (rwxrwxrwx) for no reason at all. Assign 0755 only when it's needed by the tweak, else 0644 will suffice. Also, things like su and busybox require special permissions like 4755 and 6755. If you don't assign these permissions, something's bound to break. Make sure your permissions are assigned correctly, else you have only yourself to blame when you bootloop your phone.
tl;dr it sucks to be a developer
the aroma installer is great addon for roms
but it needs some time to add it to roms...
Sent from my LG-P920 using Tapatalk
Getting There
Almost done guys but been busy setting up my old laptop so i can take my stuff to work and work on it in my break, which will be good ics comes out i will be able to jump straight on it.
Toolchain link fixed and most of the kernel bits done. You could use the rest of another boot.img guide for now if you cant wait for mine.
Also are there any other dev's willing to contribute to my bible post. I would be grateful and it would be more of a community thing then. Any tips tricks, links, dev related story's or something to push the development on in here.
Well, since there's an open invitation, might as well crash the how-to-dev party with some scripts you can use right off the bat. They are as attached, feel free to use them.They are a part of the tweaks I use for my rom. Noticeable improvements over stock this way, although they more or less deal with usability rather than performance so benchmarks might not improve as much as you'd expect. Dump them in /system/etc/init.d with permissions 0644 with a kernel that supports init.d (in other words, any custom kernel on this forum) and you're good to go.
However, since we're here, why not study how init.d works? Better to understand what these scripts do and how they impact performance, no?
Disclaimer: Some of these tweaks (like the one I'm going to explain below) were taken from the very awesome knzo (http://forum.xda-developers.com/showthread.php?t=1227269). However it has a ways to go in terms of explaining what the commands do so this post is entirely dedicated to that.
The scripts are very nicely named, giving you an idea of what they do. However, what do the strange numbers in front mean? Simply put, during bootup the kernel will run these scripts according to the numbers, so 65ZipAlign will run first, followed by 70Ext4Mount and so on.
Now, open 70Ext4Mount using notepad, notepad++, what have you. You'll see a bunch of variables and values, but at the start it is of paramount importance to add #!/system/bin/sh to the first line, else the script will not even execute as there is nothing defined to execute or write these values.
What do the values/commands do, you may ask.
tune2fs -o journal_data_writeback /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Let's analyse this command in sections.
tune2fs is just the code that runs the commands that follow after it.
-o journal_data_writeback tells tune2fs to write to the filesystem to enable journal data writeback. This typically provides the best ext4 filesystem performance.
/dev/block/mmcblk0p7 is the partition to apply the above commands to. In this case, mmcblk0p7 is /system.
Now, the other command is this
tune2fs -O ^has_journal /dev/block/mmcblk0p7
Click to expand...
Click to collapse
This time, the parameters are slightly different.
-O ^has_journal removes journaling, which is basically a filesystem log service. It takes up system resources, so removing journaling will improve system responsiveness. Note that -o and -O are different, the parameters are case-sensitive. -o configures the mount/filesystem options, -O enables/disables features.
Finally, at the bottom you get this line
busybox mount -o remount,noatime,noauto_da_alloc,nodiratime,barrier=0,nobh /system
Click to expand...
Click to collapse
As seen, the above is just a bunch of parameters. What do they all mean?
busybox mount -o mounts the partition named at the end, which is system. -o enables the mounting options.
remount, well, remounts the partition with the options named.
noatime disables the filesystem from writing the last accessed time to each file. When enabled, every read operation must have a write operation to write the last access time. With this option, only the read operations are done, removing the need for a write operation as well, giving a significant I/O boost.
noauto_da_alloc is a bit complex. When a file is edited in Linux, a new file is created containing the changes, then when it is saved, the new file is renamed and overwrites the old file. In ext3, it causes no problems since ext3 guarantees that either the old or new data will be on disk (when I say disk, it really means memory/eMMC) due to its default journaling mode. However, ext4 delays allocation, and thus the new file contents may not be written to disk before the file is renamed. Because of this, Linux kernels force the data to be written immediately which creates a performance hit. Disabling this will improve I/O by a bit. This may not be to everyone's liking since it creates the possibility of losing data, but such a thing has never happened to me. You can remove it if you like
nodiratime is the same as noatime, except this applies to directories being accessed rather than files.
barrier=0 disables the use of write barriers. Write barriers enforce proper on-disk ordering of journal commits, and is usually enabled due to possibility of data loss if power is lost. However because the O3D is a phone, it has a battery and this ensures data will not be lost as the system will not shut off abruptly due to power loss. Removing barriers gives a performance boost.
nobh makes the phone avoid assigning buffer heads. Similar effects to barrier=0, similar dangers.
/system selects the partition to remount.
That's all for 70Ext4Mount. Congrats, you now know how one of the init.d scripts work Now try figuring out the other 3. Google is your friend
This post is meant as a complement to samno's init.d mods, and only covers and explains a small section of what can be accomplished with init.d. I'll cover more when I find time
As always, props to samno for having such a thread. I must say, I haven't seen many forums where devs band together to impart to the community what we know
samno - feel free to copy the contents of this post into the OP(s) if you want to.
hi samno thanks for the tutorial but if I want to compile the kernel i get this error:
[email protected]:~/Downloads/LGP920(Optimus_3d)_Android_Gingerbread_LGP920v21e/kernel$ make ARCH=arm cosmo_rev_1.11_mipi_defconfig zImage
/bin/sh: Syntax error: "(" unexpected
make: *** [cosmo_rev_1.11_mipi_defconfig] error 2
[email protected]:~/Downloads/LGP920(Optimus_3d)_Android_Gingerbread_LGP920v21e/kernel$
Click to expand...
Click to collapse
I tried it with root to but the same error.
I hope it isn't a too silly fail and I didn't forget something.
greets berni
Sorry berni the syntax error is because of the _'s & ()'s in the directory name, rename it to something similar but without them example LGP920v21ESource. I will amend the op forgot about this since i set mine up a while ago.
Thank you very much panda i will add i to the bible Pandaball verse 3.
Just requested the kernel source code for v20c Rogers and lg will get it to me in a couple days and once I get some time I wanna build a customer kernel from it so I can use all your guys great roms and keep my 4G data
i'm not sure if I'm the only one who gets errors like this:
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
/bin/sh: /home/bernhard/Downloads/arm-2010q1/bin/arm-none-linux-gnueabinm: not found
No valid symbol.
make[1]: *** [.tmp_kallsyms1.S] Error 1
make: *** [zImage] Error 2
Click to expand...
Click to collapse
but it is easy to fix just rename the
/home/bernhard/Downloads/arm-2010q1/bin/arm-none-linux-gnueabi-nm
to arm-none-linux-gnueabinm
after fixing this it was no problem to
make the zImage
thanks again for this guide!!
---------- Post added at 08:13 PM ---------- Previous post was at 07:52 PM ----------
I just wanted to add some stuff to this guide :
after you compiled your zImage you want to
test it but how?
Parts of this are taken from Urabewe guide so credits are going to him
first run this in terminal :
sudo apt-get install uboot-mkimage
then you have to unpack a working boot.img
with this script (link by samno):
http://forum.xda-developers.com/attachment.php?attachmentid=1215193&d=1342992085
unpack it and put it in the same folder of boot.img
cd to this folder in terminal
run in terminal
./unpack-bootimg.pl boot.img
you should now have a directory called boot.img-ramdisk
here you can add some tweaks if you want.
If you change some things in the ramdisk you have to do this:
go in this directory with terminaal and run
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
cd back to the folder within the boot.img and the other stuff
Click to expand...
Click to collapse
place now your zImage in that folder and run
mkimage -A ARM -T multi -n NAME YOUR IMAGE -C None -a 0x80008000 -e 0x80008000 -d zImage:newramdisk.cpio.gz newboot.img
now you shold have a file called newboot.img just put it in a zip
and flash it from cwm but make a backup to restore the boot partition
if something wents wrong
hope i did not forget any credits or steps
greets berni
Excelent samno! Bravo!
You're the best.
Yaaay!
Just to let you know guy's ive finished the guide, please tell me if you see anything wrong or you think i should change. Good luck to those who try it out too.
Also has anyone else got/know anything i could/should add to this?
great work sir !!!
u gave an inspiration to young developers..
hatts off
I wonder why the export command sometimes doesn't do :/
I had to copy the files contained in arm2010-1 into /usr to get it working with CROSS_COMPILE=arm-none-linux-gnueabi
Without this was starting the arm-linux-gnueabi already installed in ubuntu which gives errors..
Anyway i'm doing experiments with sources and kernels here.. i feel like a mad compiler doing my "frankenstein" kernel..
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko (note: for TF300, I think you need bcmdhd_29.ko instead)
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine. In case you have trouble finding and/or compiling them, you can find the result of this step in post #2.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.
Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
Update: -that6 enables SELinux.
Shortcut
In case you don't want to extract the CM ramdisk from the blob yourself (or you have trouble finding/compiling the tools to do so), you can try using mine - from my unofficial build of cm-10.2-20131024: View attachment boot.blob.LNX-ramdisk.gz
Automated solution
See http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
(reserved for additions)
_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.
Click to expand...
Click to collapse
It is a nice detail instruction for new users like me. I really like it a lot and I can use some information from your post for my system2sd... However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu. I know a little bit of ramdisk and can get around it but that information will help the first time users... Just my opinion and thanks for sharing a valuable information to us...
LetMeKnow said:
However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu.
Click to expand...
Click to collapse
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.
_that said:
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.
Click to expand...
Click to collapse
Oop, I forgot that you use it in your boot folder... It is my bad.. I will give it a try when I am done with my system2sd testing and will ask more questions on the way.. Thanks for the information...
Cheers,
LMK
_that said:
Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
(reserved for additions)
Click to expand...
Click to collapse
You should be fine until I enforce SELINUX. But I haven't finished the policies yet. Still have some issues to iron out with that. Have about 90% of them done, I think.. lol
Just out of curiosity, will this only work with primary partitions?
johnlgalt said:
Just out of curiosity, will this only work with primary partitions?
Click to expand...
Click to collapse
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
_that said:
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
Click to expand...
Click to collapse
Yeah, I quoted it that way b/c I was asking specifically about that part - but it that part works I suppose the rest would too, huh? :silly:
Wow
Thx for this, easy cheesey, Great work, Love the dual boot!!!!
_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Click to expand...
Click to collapse
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.
kali113 said:
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.
Click to expand...
Click to collapse
Looks like commercial software, so ask the devs of that app.
Here is an experimental flashable zip file that redirects the TWRP recovery to the ROM2SD environment. It doesn't really install anything to storage, it just reconfigures the device nodes so that the recovery is tricked into accessing the system and data partitions on the microSD card instead of internal storage.
It works so well that after "installing" this, a following ROM install that unmounts and formats /system and installs itself to /system on mmcblk0p1 will actually be installed on the microSD card, so you don't need to replace the partition names in the updater-script any longer (but you still need to comment out the blob flashing line for now or reflash my kernel after the ROM).
It also works so well that after "installing" this, you don't see your internal /sdcard any longer, so put whatever you want to flash on the first partition of the external microSD card.
"Installing" the script again will undo its actions, so you can toggle back and forth between external and internal storage.
Warning: I tested this only once, and the script does not have any error handling - if the inserted microSD is not prepared for ROM2SD, behavior is undefined - most likely the recovery will complain that it can't mount system or data. Use this at your own risk and make sure you have backed up all valuable data and your ROM, just in case.
View attachment dev-rom2sd.zip
The script also contains a nice example how to output text from a shell script to the recovery console. It shows a list of device nodes so you can see what the script did (the device numbers of mmcblk0p1 and mmcblk1p3 are identical).
Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?
vnphatbuddha said:
Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?
Click to expand...
Click to collapse
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).
_that said:
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).
Click to expand...
Click to collapse
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...
vnphatbuddha said:
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...
Click to expand...
Click to collapse
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180
JoinTheRealms said:
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180
Click to expand...
Click to collapse
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?
vnphatbuddha said:
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?
Click to expand...
Click to collapse
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.
_that said:
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.
Click to expand...
Click to collapse
Wow this is too complicated to compile, having to setup and run debian on usb. Guess I can't try out rom2sd