Database Info

[Q] Own kernel or one with kexec

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.

[GUIDE] How to compile Sidekick 4G Kernel [Ubuntu]

1) download source code from https://opensource.samsung.com/index.jsp. You are looking for source code for SGH-T839.
2) Get initramfs (Need to make a kernel package)
Extract it using extract boot http://www.mediafire.com/?lc12eceeh617b97.
This is why I am looking for a boot.img
extract it
Code:
tar -xvf extractboot.tar.gz
now move into directory with extract boot and copy your boot.img into here and do
Code:
./extractboot boot.img
3) Get mkboot tools
http://www.mediafire.com/?w06d1m6n1dgo4op
untar it by doing
Code:
tar -xvf $FILENAMEHERE
Add the bin directory to your path by moving to the bin directory and copying down the path then
Now you will add this to your path by editing your .bashrc file.
Go to your bashrc file
Code:
gedit ~/.bashrc
and adding this
Code:
PATH=$PATH:/FULLDIRECTORYYOUWROTEDOWN/
export PATH
4) Download the ARM toolchain
https://sourcery.mentor.com/sgpp/lite/arm/portal/package5385/public/arm-none-linux-gnueabi/arm-2009q3-67-arm-none-linux-gnueabi.bin
and
https://sourcery.mentor.com/sgpp/lite/arm/portal/package5355/public/arm-none-eabi/arm-2009q3-68-arm-none-eabi.bin
5) Install the ARM Toolchain
create the directory /opt/toolchains/arm-2009q3/
Code:
sudo mkdir /opt/toolchains/arm-2009q3/
then install the toolchain using /opt/toolchains/arm-2009q3/
as the install directory
Code:
sudo chmod +x arm-2009q3-68-arm-none-eabi.bin
sudo chmod +x arm-2009q3-67-arm-none-linux-gnueabi.bin
sudo ./arm-2009q3-67-arm-none-linux-gnueabi.bin -i console
sudo ./arm-2009q3-68-arm-none-eabi.bin -i console
6) Compile
Extract your source code and go to the directory Kernel and do the following
WARNING: MAKE SURE THERE ARE NO SPACES IN YOUR FILEPATH BECAUSE THE MAKEFILE DOESNT LIKE THEM.
Code:
make clean
make arch=arm sidekick_rev02_defconfig
make ARCH=arm HOSTCFLAGS="-g -O3" -j8 CROSS_COMPILE=/opt/toolchain/bin/arm-none-eabi-
Now copy any of the resulting compiled ko files into the initramfs file you have extracted and you should have what you need to package a kernel.

you forget initramfs

windxixi said:
you forget initramfs
Click to expand...
Click to collapse
yeah I kept it out so that somebody would post a boot.img then could do steps related to that. I am looking for a boot.img to get initramfs from

unpack zImage
Sent from my SGH-T839 using XDA
---------- Post added at 08:46 AM ---------- Previous post was at 07:49 AM ----------
and how to pack a boot.img?

A request to anyone building SK4G kernels.
Please disable the keystroke logging printk statements in the file:
Code:
drivers/input/keyboard/s3c-keypad.c
The lines look like this:
Code:
//printk("\nkey Pressed : key %d map %d\n",i, pdata->keycodes[i]);
and
Code:
//printk("\nkey Released : %d map %d\n",i,pdata->keycodes[i]);
It is possible to recover the actual keystrokes from the numerical codes those statements log, and the messages go into the dmesg buffer. So it's pretty easy to extract them and determine exactly what the user typed.
In the latest Samsung sources I've seen, those lines were already commented out. It makes sense to enable them while debugging a new ROM build, but please do disable them prior to building a kernel intended for general consumption.

Do you guys know if the available source code will produce a kernel that will work with kj2? the kernel version in SGH-T839_Opensource_Update1 looks to match up, but I compilied a zImage and it didn't boot on stock kj2. but I could very well be missing something.
I have done a small amount of kernel work on an HTC device, but I basically just used the Rom Kitchen to pack up my zImages with a boot.img-ramdisk to create a boot.img. I guess I might need a little more instruction for packing up a Samsung kernel. Is it also an option to just tar up the zImage and flash it with Odin/Heindall?
Thanks for this thread, and for any other advice!
Sent from my SGH-T839 using Tapatalk 2

In case it might be useful to someone else working on building a kernel.
The official and Bali_SK4G sources both seem to insist on building with debug symbols enabled for some of the modules. In particular, i was ending up with dhd.ko being 2.4 MB in size, where it should have been less than 400 KB.
The ideal case would be to determine why the debug symbols are being included -- commenting out the labelled debug options in the bcm4329 Makefile didn't accomplish this.
But a workaround is to strip the modules after the build is finished, before assembling the initramfs.

Has anyone been able to build a working zImage for KJ2 using Dr. Honk's Bali sources [1] and sduvick's KJ2 ramdisk files [2]?
I have been able to build a zImage of a reasonable size (6520 KB). But when I flash this to the KERNEL partition using heimdall, the device boot loops to the B&W Sidekick logo. It doesn't get far enough to show any adb log output.
I can then use the same heimdall flashing procedure to flash the Platypus Egg v1 zImage, or other KJ2-compatible zImage files, and the device boots and works properly.
So I'm trying to figure out what I'm doing wrong in building my zImage. If anyone has any advice I would be appreciative.
[1] https://github.com/drhonk/Bali_SK4G
[2] https://github.com/sduvick/SK4g_KJ2_Ramdisk

I got an updated Bali_SK4G kernel booting using the ramdisk from GenericGinger 2.0.
I have worked up some patches to disable the logging of keystrokes and other more trivial debug spew in dmesg. Also included is a Makefile patch that was required for the compile to complete with my toolchain.
https://carbon.flatlan.net/nxd/patches_Bali_SK4G_nxd.tar.bz2
md5sum: 5d14ac32de155cdca0fd82f14bc4ceca
These patches are GPL licensed, in compliance with the license for the Linux kernel itself. I make no guarantees about their suitability for any purpose. I grant permission to use them to anyone who would like to do so, so long as they comply with the GPL.
I'd like to make a compiled kernel available with these changes, but XDA's rules can be interpreted to mean that I must obtain permission from a series of upstream contributors, some of whom may not be reachable. Perhaps a moderator will clarify the parameters of the permission rule.

[HOWTO] Seamless integration of Android and GNU/Linux Debian (or Ubuntu)

I've integrated GNU/Linux Debian with Android in a way I've not seen anyone done before. By running Android in a chroot environment below a GNU/Linux Debian installation, I've got the best of both worlds.
This solution is primary intended for the experienced GNU/Linux hacker or app developer wanting full control over the Android device using a standard GNU/Linux environment.
For the novice wanting to run GNU/Linux for the fun of it, there are other less powerful solutions I'd recommend before this one. ​
A detailed HOWTO at http://whiteboard.ping.se/Android/Debian
Features
Full GNU/Linux Debian (or Debian based such as Ubuntu) installation with lots of apt-get:able packages
Full control of the Android environment from Debian
Simultaneous use of Debian as well as Android
Access the Android file system from your workstation desktop via ssh/sftp
No need to unmount/remount the SDcard accessing it via ssh/sftp
Android system untouched and unaware of any modifications
Android root file system no longer volatile, edits are kept between reboots
Critical file systems kept on SDcard for easy access in case of major f**k up
Graphic X11 Windows user interface, both client and server, local and remote, native, over SSH or VNC
Manage your Android device as any other GNU/Linux system
Architecture
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Running X11 with Gnome via VNC on the ASUS Transformer

Interesting work. Does the Android environment take much of a performance hit running under debian?
fluxist

fluxist said:
Interesting work. Does the Android environment take much of a performance hit running under debian?
Click to expand...
Click to collapse
No performance impact. Running in chroot does not impair the performance, but the boot may take a second or two longer with the extra init scripts. If you move the /system and/or /data partition(s) to the sdcard, the speed of the memory card may affect the performance, but benchmarking a class 10 card and you'll get about the same disk-I/O performance as using the internal nand partitions, take or give. My tests revealed some operations actually was faster to the sdcard compared to the nand - but other slower (e.g. random vs sequential, large blocks vs small etc). Myself I moved /system to the sdcard for safety and /data for more app space, increasing it from 400MB to 4GB on my Xperia. . Only keep in mind Android doesn't like more than four partitions on the sdcard in total.
The ssh server will of course consume some ram (less than 1MB rss for openssh-server, ~300kB for dropbear), but the ease of removing bloatware in this setup more than makes up for this, resulting in a faster phone than before.

Great job man.
Just 3 questions :
1) What's the difference with this project ? Linux on Android Project
2) Your solution has Audio and GPU Acceleration ?
3) Are you planning a "really easy noob-aware stupid-free ONE CLICK" Tool ?
Thanks !
TheMac

themac said:
Great job man.
Just 3 questions :
1) What's the difference with this project ? Linux on Android Project
Click to expand...
Click to collapse
The difference is who's on top. In my solution, the Debian/Ubuntu is on top, owning the Android installation. This way you can use Debian/Ubuntu to access, manage, change anything in the Android world, and the Android world don't even need to be aware of Debian/Ubuntu, and does not need to be rooted or anything. E.g. you can edit the init.rc file from Debian/Ubuntu, save it as any ordinary file, and the next time Android boots, it's still there, your changes included. Or remove bloat-ware, or get file access via ssh/sftp to the entire file system, etc. This is not possible using the other solutions.
themac said:
2) Your solution has Audio and GPU Acceleration ?
Click to expand...
Click to collapse
No. Yes. Well, no. All (local) access to the Debian/Ubuntu uses Android as a front end, and Android still owns all the devices (screen, input methods, audio device etc). If you've got a remote terminal access supporting sound, sure. But I don't think VNC does. I'll answer "no" on this question.
themac said:
3) Are you planning a "really easy noob-aware stupid-free ONE CLICK" Tool ?
Click to expand...
Click to collapse
I don't know if I would be doing the world a favour doing this. Today it requires knowledge in GNU/Linux to install, and a user without knowledge enough can do lots of damage really quick, because of the power to make changes in the Android environment this solution gives. The installation complexity is kind of a safe-guard, I'd say.
Also I find this solution more suitable for the hacker wanting control of his Android, not the person only wants to run GNU/Linux. If all you want to do is run Debian/Ubuntu, I guess the Android-on-top-solution is better. More safe, anyhow.
Since the installation requires a new boot image, it would look more like a custom ROM than a OneClick App anyway. Different images for different phones etc.
themac said:
Thanks !
TheMac
Click to expand...
Click to collapse
You're welcome!
tl;dr
This GNU/Linux integration is:
Good for the GNU/Linux hacker wanting full control of his Android device.
Bad for the mortal user wanting to run GNU/Linux just for fun.

Enviado desde mi GT-N7000 usando Tapatalk 2

Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Took me a while to get the proper hardware-specific configuration, but I was able to do it. ^_^
I had to use some of the info here (http://forum.xda-developers.com/showthread.php?t=1516051) - reason: "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
To turn on framebuffer logging (where you see the kernel text scrolling by during initial boot) add this to the kernel cmdline:
console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8
(from http://forum.xda-developers.com/showthread.php?t=829817)
Here's my command line after re-gzipping the modified initramfs:
./mkbootimg-sg2x --kernel boot.img-kernel --ramdisk ramdisk.gz --cmdline "console=tty0,115200 fbcon=rotate:0 fbcon=font:VGA8x16 androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img.new --base 0x40400000 --pagesize 2048
--Weasel5i2

weasel5i2 said:
Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Click to expand...
Click to collapse
Neat! Added it the the list of verified devices, linking your post.
Yes, baseaddress and command line parameters can be a bit tricky, but they all are included in the boot.img. Myself I wrote a small hack to reverse the doings of mkbootimg.
$ ./unmkbootimg boot.img
Kernel size 2419636
Kernel address 0x20008000
Ramdisk size 152656
Ramdisk address 0x21000000
Secondary size 0
Secondary address 0x20f00000
Kernel tags address 0x20000100
Flash page size 2048
Board name is ""
Command line "no_console_suspend=1"
Extracting kernel.gz ...
Extracting initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbooting --kernel kernel.gz --ramdisk initramfs.cpio.gz --base 0x20000000 --cmdline 'no_console_suspend=1' -o new_boot.img
---------------
Click to expand...
Click to collapse
This tool can be found in this thread.

weasel5i2 said:
Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Took me a while to get the proper hardware-specific configuration, but I was able to do it. ^_^
I had to use some of the info here (http://forum.xda-developers.com/showthread.php?t=1516051) - reason: "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
To turn on framebuffer logging (where you see the kernel text scrolling by during initial boot) add this to the kernel cmdline:
console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8
(from http://forum.xda-developers.com/showthread.php?t=829817)
Here's my command line after re-gzipping the modified initramfs:
./mkbootimg-sg2x --kernel boot.img-kernel --ramdisk ramdisk.gz --cmdline "console=tty0,115200 fbcon=rotate:0 fbcon=font:VGA8x16 androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img.new --base 0x40400000 --pagesize 2048
--Weasel5i2
Click to expand...
Click to collapse
I also follow the same thread default ramdisk offset 0x01000000 while our phone needs 0x01400000.
But I'd like to know where or how to set ramdisk offset( to 0x01400000). Is it hard coded some where?.
And how could we know that each hardware requires different ramdisk offset.

basha.ram said:
I also follow the same thread default ramdisk offset 0x01000000 while our phone needs 0x01400000.
But I'd like to know where or how to set ramdisk offset( to 0x01400000). Is it hard coded some where?.
And how could we know that each hardware requires different ramdisk offset.
Click to expand...
Click to collapse
"base" is the address of the beginning of ram memory your device's board is using, i.e. the hardware design. By supplying this information to mkbootimg, it knows how to layout and where to load the kernel, root ramdisk etc.
I've written quite a lot about how to find out this address, including a tool extrating it from your original boot.img
http://whiteboard.ping.se/Android/Debian#base
http://whiteboard.ping.se/Android/Unmkbootimg

kuisma said:
"base" is the address of the beginning of ram memory your device's board is using, i.e. the hardware design. By supplying this information to mkbootimg, it knows how to layout and where to load the kernel, root ramdisk etc.
I've written quite a lot about how to find out this address, including a tool extrating it from you original boot.img
http://whiteboard.ping.se/Android/Debian#base
http://whiteboard.ping.se/Android/Unmkbootimg
Click to expand...
Click to collapse
Okay, reboot loop
steps:
1. Obtain base address from unmkbootimg
2. repack with mkbootimg
Code:
./mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-boot --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o newBoot.img --base 0x40400000
3. make a tar of new boot img
4. flash via ODIN -> successful
5. device restart-> reboot in a loop.
No Idea what went wrong.. can't even dump logs

basha.ram said:
Okay, reboot loop
steps:
1. Obtain base address from unmkbootimg
2. repack with mkbootimg
Code:
./mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-boot --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o newBoot.img --base 0x40400000
3. make a tar of new boot img
4. flash via ODIN -> successful
5. device restart-> reboot in a loop.
No Idea what went wrong.. can't even dump logs
Click to expand...
Click to collapse
You get a boot loop when init terminates. The easiest way to see why, is to follow weasel5i2s example and enable frambuffer logging.
Also look for the file /android/log/boot.log at the SDcard and see if you have any clue there. If this file is non-existent, init terminated before stage two was launched.
As a last resort, after double checking all mount points, execute access (see "Common mistakes" in my HOWTO), and if you are not able to enable logging, you can clock the time it takes for the device to reboot. Then insert a "busybox sleep 30" in the init script and see if the boot loops take 30s longer time. If so, you know everything worked well up to this point, and you can move the sleep forward etc, until you've isolated exactly where it fails.

kuisma said:
You get a boot loop when init terminates. The easiest way to see why, is to follow weasel5i2s example and enable frambuffer logging.
Also look for the file /android/log/boot.log at the SDcard and see if you have any clue there. If this file is non-existent, init terminated before stage two was launched.
As a last resort, after double checking all mount points, execute access (see "Common mistakes" in my HOWTO), and if you are not able to enable logging, you can clock the time it takes for the device to reboot. Then insert a "busybox sleep 30" in the init script and see if the boot loops take 30s longer time. If so, you know everything worked well up to this point, and you can move the sleep forward etc, until you've isolated exactly where it fails.
Click to expand...
Click to collapse
I see in weasel5i2 post using customized version of mkbootimg ( mkbootimg-sg2x ) and reason stated as "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
how do we find that phone needs 0x01400000 as ramdisk offset.
---------- Post added at 04:40 PM ---------- Previous post was at 04:29 PM ----------
weasel5i2 said:
Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Took me a while to get the proper hardware-specific configuration, but I was able to do it. ^_^
I had to use some of the info here (http://forum.xda-developers.com/showthread.php?t=1516051) - reason: "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
To turn on framebuffer logging (where you see the kernel text scrolling by during initial boot) add this to the kernel cmdline:
console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8
(from http://forum.xda-developers.com/showthread.php?t=829817)
Here's my command line after re-gzipping the modified initramfs:
./mkbootimg-sg2x --kernel boot.img-kernel --ramdisk ramdisk.gz --cmdline "console=tty0,115200 fbcon=rotate:0 fbcon=font:VGA8x16 androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img.new --base 0x40400000 --pagesize 2048
--Weasel5i2
Click to expand...
Click to collapse
Could you please post your .config file enabled with framebuffer logging.. I followed the link in your post but I still see a back screen.

basha.ram said:
I see in weasel5i2 post using customized version of mkbootimg ( mkbootimg-sg2x ) and reason stated as "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
how do we find that phone needs 0x01400000 as ramdisk offset.
Click to expand...
Click to collapse
Ah, you used the vanilla mkbootimg? Let's just take weasel5i2's word for it, ok?
In mkbootimg.c you'll find a line;
hdr.ramdisk_addr = base + 0x01000000;
Click to expand...
Click to collapse
Change it to
hdr.ramdisk_addr = base + 0x01400000;
Click to expand...
Click to collapse
... compile, and you've got weasel5i2's customised mkbootimg-sg2x.

kuisma said:
Ah, you used the vanilla mkbootimg? Let's just take weasel5i2's word for it, ok?
In mkbootimg.c you'll find a line;
Change it to
... compile, and you've got weasel5i2's customised mkbootimg-sg2x.
Click to expand...
Click to collapse
Thanks again,
That did the trick, my phone is up and running with custom-built kernel but the ramdisk offset value as 0x01400000 still remains a question?. I've no idea why or on what basis I need to change ramdisk offset.
Do you have any idea on how to find the correct offset value for individual phones.. in fact it was stated under weasel5i2's post which is pointing to anther post in xda.

basha.ram said:
Thanks again,
That did the trick, my phone is up and running with custom-built kernel but the ramdisk offset value as 0x01400000 still remains a question?. I've no idea why or on what basis I need to change ramdisk offset.
Click to expand...
Click to collapse
Great work!
The base supplied to mkbootimg is the address the devices RAM begin. mkbootimg uses this calculating the addresses of the atag area, the kernel image, the ramdisk space, etc. If a manufacturer puts too much goodies into their kernel, it will be too big to fit in the space mkbootimg assigns it by default, hence the need for Samsung here to increase the offset of the ramdisk (as it follows the kernel space).
basha.ram said:
Do you have any idea on how to find the correct offset value for individual phones.. in fact it was stated under weasel5i2's post which is pointing to anther post in xda.
Click to expand...
Click to collapse
Again, use my unmkbootimg on your original boot.img. It will list the individual offsets of the kernel, ramfs etc. Then calculate backwards by subtracting the offsets mkbootimg.c uses. In the Samsung case, you'll notice they don't add up - i.e. subtracting the ramdisk offset from the listed ramdisk address does not give you the same base address as if you would subtract the kernel offset from the kernel address of the same image. Hence you can conclude Samsung must have adjusted the offsets, and with how much.
Maybe I should add support in unmkbootimg for this, doing those calculations for you and issue a warning if a non-standard mkbootimg was and must be used. Send me a link where I can get your original boot.img, and I have something to test it with, when and if I'll decide to do this.

Have you looked at the "Linux on Android!" project: http://forum.xda-developers.com/showthread.php?t=1299962
He, theGanymedes , recompiled libs such as glibc and others to run from within android itself, including apt, Bash, NCurses Library, Readline Library, etc all to run the full versions cross-compiled for android, well arm anyway.
He even was able to utilize the framebuffer directly for enlightenment(17) window manager. No VNC.
With this in mind, I was wondering if it would be possible to blend together that idea and your idea, whereas the android part would just utilize the libs found in the debian part of your project. Eventually merging the two. Prior to the merge it would facilitate smaller ROMs as they would be sharing libs, apps, etc. And the android portion would get access to full blown applications and libs, not to mention apt.
This just seems like the next logical step, at the very least it would allow you to remove the vnc dependency, and draw directly to the FB.
-I take no credit for the "Linux on Android!" project, hell, I take no credit period.

ggolemg said:
Have you looked at the "Linux on Android!" project: http://forum.xda-developers.com/showthread.php?t=1299962
He, theGanymedes , recompiled libs such as glibc and others to run from within android itself, including apt, Bash, NCurses Library, Readline Library, etc all to run the full versions cross-compiled for android, well arm anyway.
[...]
Click to expand...
Click to collapse
Been there, done that. I started out compiling libc (uClibc) for Android, but running two different libc in the same root causes a big mess. The directory structures clashes, requiring either a rewrite of the libc moving e.g. /etc to /usr/etc and so, or the use of an overlay file system. And even if solved, the end result is a big mess with files who knows belonging to what, what program uses which environment etc. So when I realised I could jail the Android environment, I immediate saw how this would resolve all conflicts, creating a clean, simple and yet more powerful and usable solution.
The next project will be a GNU/Linux you can run on your non-rooted Android device, aimed to the user who believes this solution is too complicated.

kuisma said:
Great work!
The base supplied to mkbootimg is the address the devices RAM begin. mkbootimg uses this calculating the addresses of the atag area, the kernel image, the ramdisk space, etc. If a manufacturer puts too much goodies into their kernel, it will be too big to fit in the space mkbootimg assigns it by default, hence the need for Samsung here to increase the offset of the ramdisk (as it follows the kernel space).
Again, use my unmkbootimg on your original boot.img. It will list the individual offsets of the kernel, ramfs etc. Then calculate backwards by subtracting the offsets mkbootimg.c uses. In the Samsung case, you'll notice they don't add up - i.e. subtracting the ramdisk offset from the listed ramdisk address does not give you the same base address as if you would subtract the kernel offset from the kernel address of the same image. Hence you can conclude Samsung must have adjusted the offsets, and with how much.
Maybe I should add support in unmkbootimg for this, doing those calculations for you and issue a warning if a non-standard mkbootimg was and must be used. Send me a link where I can get your original boot.img, and I have something to test it with, when and if I'll decide to do this.
Click to expand...
Click to collapse
Thanks for the pointers.
I've attached stock boot.img and the output of unmkbootimg below.
Code:
Kernel size 4905092
Kernel address 0x40408000
Ramdisk size 893395
Ramdisk address 0x41800000
Secondary size 0
Secondary address 0x41300000
Kernel tags address 0x40400100
Flash page size 2048
Board name is ""
Command line "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4"
Extracting kernel.gz ...
Extracting initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbooting --kernel kernel.gz --ramdisk initramfs.cpio.gz --base 0x40400000 --cmdline 'androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4' -o new_boot.img
one more question, the output line "To recompile this image, use:...mkbooting --kernel...." is based on vanilla version?

basha.ram said:
one more question, the output line "To recompile this image, use:...mkbooting --kernel...." is based on vanilla version?
Click to expand...
Click to collapse
Yes, unmkbootimg is quite literally the inverse of the vanilla mkbootimg. If a non-standard mkbootimg is used to compile the image, the command line unmkbootimg suggests will only work using this modified mkbootimg. But I'll update unmkbootimg informing the user about this, in the case it detects odd offsets, as well as supplying the new offsets needed to modify mkbootimg.c

[TOOL] Boot.img tools [unpack, repack, ramdisk]

I have not seen this posted anywhere, so I thought I would post it here. This is NOT purely my work, and I do not take credit for it as such.
Included in the attached ZIP are the following files:
boot_info - prints information about the boot.img passed to it, including the base address and ramdisk address. This tool prints out everything needed to repack the boot.img correctly.
split_boot - More commonly known as split_bootimg.pl, this rips apart the boot.img to extract the ramdisk and zImage. It has been modified by me to split the boot.img into a separate folder (specified by the file name of the boot.img passed to it) and to extract the ramdisk into a sub-folder as well (extracts the cpio from the gz and then extracts the actual files from the cpio archive)
unpack_ramdisk - unpacks the given ramdisk file.
Code:
Usage: unpack_ramdisk <ramdiskFile>
repack_ramdisk - repacks the ramdisk from the given directory (found online and modified slightly to take a directory)
Code:
Usage: repack_ramdisk <ramdiskDirectory> [outputFile]
mkbootimg - mkbootimg binary that creates a boot.img file from the given ramdisk and zImage. Updated to a version compiled by me to support the --ramdiskaddr option (ramdisk address) so that even nonstandard boot.img's can be repacked correctly (Use with boot_info for best results).
umkbootimg - included for convenience. Not made by me. Original thread here.
unpack - wrapper script made by me for the umkbootimg binary^ to unpack the boot.img into a separate directory and then unpack the ramdisk into a sub-directory.
Note: These tools were made for Linux. They may also work on Cygwin, but I have not personally tested them.
ANYONE is free to use / modify / kang these files as they see fit. No need to ever ask or do anything more than download.
Enjoy.

UPDATE: If you downloaded, please redownload. There was an error with my repack_ramdisk script, but it's fixed now.

Updated tools with a new boot_info script, also added my own mkbootimg binary compiled with the ramdisk address option.
Boot_info now displays the following information:
Commandline
Pagesize
Base address
Ramdisk address.
Which is everything you need to make a functional boot.img, even when the original boot.img is packed with a non-standard mkbootimg (ie, the ramdisk offset is different than the normal offset).

How exactly do we use these files to unpack and repack?
I've tried running the scripts with chmod at 755 but it doesn't work.
I am i missing something?

All the scripts must be in a folder in your path (~/bin for example)
Then it should work, because they call on each other. I keep all of them in my ~/bin folder, but they can be anywhere in your PATH
Sent from my buttered S3

if Android Magic Word not found at offset 0, it fail.

twins.7 said:
if Android Magic Word not found at offset 0, it fail.
Click to expand...
Click to collapse
No, if you use unmkbootimg instead split_boot, it also finds embedded images.

CNexus said:
No, if you use unmkbootimg instead split_boot, it also finds embedded images.
Click to expand...
Click to collapse
OK, it work. But .... sorry to much complain
My boot.img has magic word in offset 2048. so it mean, there is additional header in first 2048 byte.
umkbootimg succesfully extract embedded boot.img, but in repacking, I lost the first 2048 byte, because magic header placed in offset 0.
Actually, what is the additional header for? really asking...
I fail to fastboot flash if the image have no additional header.
And it will fail to verify, if the additional header is wrong. or is it called signed boot.img?
If I change the content of boot.img, I can't flash it to device. It always said verify fail. I though, the additional header has CRC or hash or anything.
If you have spare time and want to help me, I'll post my image

Thanks for this tools
Send from my AMOI N828 using Xda Premium

twins.7 said:
OK, it work. But .... sorry to much complain
My boot.img has magic word in offset 2048. so it mean, there is additional header in first 2048 byte.
umkbootimg succesfully extract embedded boot.img, but in repacking, I lost the first 2048 byte, because magic header placed in offset 0.
Actually, what is the additional header for? really asking...
I fail to fastboot flash if the image have no additional header.
And it will fail to verify, if the additional header is wrong. or is it called signed boot.img?
If I change the content of boot.img, I can't flash it to device. It always said verify fail. I though, the additional header has CRC or hash or anything.
If you have spare time and want to help me, I'll post my image
Click to expand...
Click to collapse
I'm not sure. No tool will work for all devices, and since I've never had a device that has this special packing, it would be best if you asked one of your kernel devs for help unpacking/repacking

CNexus said:
I'm not sure. No tool will work for all devices, and since I've never had a device that has this special packing, it would be best if you asked one of your kernel devs for help unpacking/repacking
Click to expand...
Click to collapse
ok thank's

CNexus said:
I have not seen this posted anywhere, so I thought I would post it here. This is NOT purely my work, and I do not take credit for it as such.
Included in the attached ZIP are the following files:
boot_info - prints information about the boot.img passed to it, including the base address and ramdisk address. This tool prints out everything needed to repack the boot.img correctly.
split_boot - More commonly known as split_bootimg.pl, this rips apart the boot.img to extract the ramdisk and zImage. It has been modified by me to split the boot.img into a separate folder (specified by the file name of the boot.img passed to it) and to extract the ramdisk into a sub-folder as well (extracts the cpio from the gz and then extracts the actual files from the cpio archive)
unpack_ramdisk - unpacks the given ramdisk file.
Code:
Usage: unpack_ramdisk <ramdiskFile>
repack_ramdisk - repacks the ramdisk from the given directory (found online and modified slightly to take a directory)
Code:
Usage: repack_ramdisk <ramdiskDirectory> [outputFile]
mkbootimg - mkbootimg binary that creates a boot.img file from the given ramdisk and zImage. Updated to a version compiled by me to support the --ramdiskaddr option (ramdisk address) so that even nonstandard boot.img's can be repacked correctly (Use with boot_info for best results).
umkbootimg - included for convenience. Not made by me. Original thread here.
unpack - wrapper script made by me for the umkbootimg binary^ to unpack the boot.img into a separate directory and then unpack the ramdisk into a sub-directory.
Note: These tools were made for Linux. They may also work on Cygwin, but I have not personally tested them.
ANYONE is free to use / modify / kang these files as they see fit. No need to ever ask or do anything more than download.
Enjoy.
Click to expand...
Click to collapse
is it possible to make these run on the device?
i have tried
adb root
adb remount
adb push * /sdcard/tmp/
adb push * /system/xbin/
adb push * /system/bin/
adb shell
cd /sdcard/tmp/
for f in $(ls)
do
chmod 755 /system/bin/$f
chmod 775 /system/xbin/$f
done
cd /
rm -r /sdcard/tmp
cd /sdcard/working
split_bootimg.pl boot.img
returns "Permission denied"
hmmmmm???????? what could be the problem????????

ricky310711 said:
is it possible to make these run on the device?
i have tried
adb root
adb remount
adb push * /sdcard/tmp/
adb push * /system/xbin/
adb push * /system/bin/
adb shell
cd /sdcard/tmp/
for f in $(ls)
do
chmod 755 /system/bin/$f
chmod 775 /system/xbin/$f
done
cd /
rm -r /sdcard/tmp
cd /sdcard/working
split_bootimg.pl boot.img
returns "Permission denied"
hmmmmm???????? what could be the problem????????
Click to expand...
Click to collapse
The Perl script should work if you have Perl (compiled for ARM x86) on your device.
The binaries will not work as they are not compiled for ARM. The scripts (at least some of them) should work if you change all instances of "#!/bin/bash" and "#!/usr/bin/env bash" to "#!/system/bin/sh".

CNexus said:
The Perl script should work if you have Perl (compiled for ARM x86) on your device.
The binaries will not work as they are not compiled for ARM. The scripts (at least some of them) should work if you change all instances of "#!/bin/bash" and "#!/usr/bin/env bash" to "#!/system/bin/sh".
Click to expand...
Click to collapse
will see if i can get it working tonight! this could be pretty good if i can get it to unpack on device!

ricky310711 said:
will see if i can get it working tonight! this could be pretty good if i can get it to unpack on device!
Click to expand...
Click to collapse
No need...download this zip and extract http://www12.zippyshare.com/v/37266634/file.html
It already contains an unmkbootimg binary compiled for ARM. Then you would just need to unpack the ramdisk to finish it off.

CNexus said:
No need...download this zip and extract http://www12.zippyshare.com/v/37266634/file.html
It already contains an unmkbootimg binary compiled for ARM. Then you would just need to unpack the ramdisk to finish it off.
Click to expand...
Click to collapse
no way, ive been looking for something like this for ages, who is the author?

ricky310711 said:
no way, ive been looking for something like this for ages, who is the author?
Click to expand...
Click to collapse
I don't know who originally compiled that unmkbootimg binary for ARM.

CNexus said:
I don't know who originally compiled that unmkbootimg binary for ARM.
Click to expand...
Click to collapse
hmm, gotta findout! i wanna use it in my tool!

Is this boot.img tool compatible with Microsoft windows as well?
Sent from my SPH-L710 using XDA Premium 4 mobile app

shakim24 said:
Is this boot.img tool compatible with Microsoft windows as well?
Sent from my SPH-L710 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Read the OP.

[Q] Editing livesuit image (new Android kernel - cubieboard)

Hello everyone,
I read all the topics related but, unfortunately, it did not solve my problem.
I have a cubieboard (allwinner A10) and a screen that doesn't have HDMI input, instead it has DVI input. Therefore, I use a hdmi>dvi connector and i lose all the EDID, and Android doesn't show up (note: if i a specify some resolution in script0.bin, Android shows up in small resolution).
I have to specify the resolution in the firmware, but unfortunately the kernel distributed by Cubieboard is 3.0.52 and doesn't contain mine (1280x1024). Therefore, I have to build my own Android firmware with a recent kernel... and i fail every time, for months. (note: with gnu/linux i don't have any issue, i juste have to specify the resolution in kernel arguments on a txt file.. because the kernel is ulterior).
Please look at my method hereunder and tell me if you see some problems. Thanks in advance.
***
After lots of searches, i think that unpacking and repacking an existing livesuit image is the "easiest" way to upgrade the android kernel.
PHASE 1 : unpacking a stock livesuit android image
I use the "imgRePacker" utility (forum.xda-evelopers.com/showthread.php?t=1753473) and I unpack the "tvbox_2.2_8188eu.img" image from cubieoard.org. Now i have to change the files boot.fex and boot.fex.iso before repacking this livesuit image. Boot.fex and boot.fex.iso are the same file and are the "boot.img" containing bootheader, kernel and ramdisk (innovantesindia.com/wordpress/2011/04/18/bootimage-and-recovery-image-unveiled/).
I copy one of these two files and use the "split_bootimg.pl" to unpack it. I get kernel and ramdisk ; so i juste have to replace the old kernel by the new and execute "mkbootimg".
PHASE 2 : building a recent kernel
As the commit who interests me is your, i download a kernel containing it : the "sunxi-v3.0.76-r0" (github.com/jwrdegoede/linux-sunxi/releases/tag/sunxi-v3.0.76-r0). I unzip it and modify the sun4i_defconfig file to put maximum in the kernel and not in modules (because i'll send the modules later via adb, so maximum of things have to be in kernel). I modify the kernel cmdline by "console=ttyS0,115200 rw init=/init loglevel=5".
Then i execute
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sun4i_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j5 uImage modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=output modules_install
FINAL PHASE : repacking with new kernel
The gzipped kernel is zImage in arch/arm/boot. I copy this file in the phase 1 directory and i execute
tools/mkbootimg --base 0x40000000 --kernel zImage --ramdisk boot.img-kernelramdisk.gz --cmdline 'console=ttyS0,115200 rw init=/init loglevel=5' -o new-recovery.img
Now i copy thenew-recovery.img file and put it in the imgRePacker folder instead of boot.fex and boot.fex.iso. I repack the image and flash it in the cubieboard and ... The cubieboard has its red the green led on but doesn't boot more .. I can't communicate with it via adb because it's not even recognized by windows (because it isn't booted).....
***
Please ! Can you help me ? Do you see any problem in my method ?
Thanks in advance.

up