Hi everynone,
I was building a kernel for the pixel c. I could build it, now the only problem i have is i can't unpack / repack boot.img of the pixel c (i would like to unpack it in order to extract the ramdisk ans generate the boot.img).
How do you generate boot.img after you have the compiled kernel image on a pixel c ?
These informations are very important to understand and mod Pixel C.
I will be very interested too to have some info about how to unpack/repack boot.img for pixel c (as it's a chromeos boot image)
Thanks a lot in advance,
Mathieu
Ok so after some analysis, here is what i understood :
boot.img contains in itself an android boot.img at the adress 0x1000.
So to extract the android boot.img image, we can use dd :
dd if=chromeosBoot.img of=androidBoot.img skip=8192 bs=8
This will extract the androidBoot.img. Then we will be able to use split_bootimg.pl to extract the kernel and the ramdisk (compressed in gz).
Now my questions : from 0x0 to 0x1000 in chromos boot img, there is some data i still don't understand clearly.
I would like to try to replace the kernel and the ramdisk, and then repack all keeping the same data from 0x0 to 0x1000.
Do you think it's gonna work ?
What are the risks to do so (i don't want to brick too much my tablet...)
Thanks a lot for your help,
Hope my researches will be helpful for other developers.
Mathieu
Samt434 said:
Ok so after some analysis, here is what i understood :
boot.img contains in itself an android boot.img at the adress 0x1000.
So to extract the android boot.img image, we can use dd :
dd if=chromeosBoot.img of=androidBoot.img skip=8192 bs=8
This will extract the androidBoot.img. Then we will be able to use split_bootimg.pl to extract the kernel and the ramdisk (compressed in gz).
Now my questions : from 0x0 to 0x1000 in chromos boot img, there is some data i still don't understand clearly.
I would like to try to replace the kernel and the ramdisk, and then repack all keeping the same data from 0x0 to 0x1000.
Do you think it's gonna work ?
What are the risks to do so (i don't want to brick too much my tablet...)
Thanks a lot for your help,
Hope my researches will be helpful for other developers.
Mathieu
Click to expand...
Click to collapse
Thanks for the unpacking help .. works quick and good.
It´s actually the same like ..
Code:
dd if=boot.img of=unpacked.img ibs=65536 skip=1
Have the same problem, as I want to repack Pixel C boot.img ..etc.
For the repacking part I was searching heavily .. like you.
boot-split.pl or mkbootimg is done ... only the signing part is missing ?!?
Here is a part of the solution : ( working on ubuntu 14.04 )
Code:
apt-get install vboot-kernel-utils
Code:
vbutil_kernel --repack boot.img --oldblob xceed-kernel-google-dragon-v6.10-RELEASE-mxc14g.img --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk
the output ...
Code:
Key block:
Size: 0x4b8
Flags: 7 !DEV DEV !REC
Data key algorithm: 4 RSA2048 SHA256
Data key version: 1
Data key sha1sum: d6170aa480136f1f29cf339a5ab1b960585fa444
Preamble:
Size: 0xfb48
Header version: 2.2
Kernel version: 1
Body load address: 0x100000
Body size: 0x57d000
Bootloader address: 0x67c000
Bootloader size: 0x1000
Body verification succeeded.
Just took the xceed kernel as example .. works with all other "CHROMEOS" images too.
But to sign a changed kernel it seems you need more/other parameter.
Still searching ...
Time to boot soon
Cheers
More infos !
Here is where my researches are :
You need to get and compile vboot_reference in order to have the lastest version :
git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference
after this :
futility vbutil_keyblock --pack boot.img.keyblock --datapubkey kernel_data_key.vbpubk --signprivate kernel_data_key.vbprivk
and next :
echo " " > empty.txt
futility vbutil_kernel --pack boot.img --keyblock boot.img.keyblock --signprivate kernel_data_key.vbprivk --version 1 --vmlinuz boot.img.unsigned --config empty.txt --arch arm --bootloader empty.txt --flags 0x1
And now it seems we have a valid boot.img image !
Thanks a lot for your researches followmsi, i was blocked due to the fact i couldn't generate a signing key, but it seems that the keys are public finally (in tests/devkeys/ of vboot_reference project) !!
Next step for me :
fastboot flash boot boot.img
This comment here helped me a lot :
https://bbs.archlinux.org/viewtopic.php?id=207385
Thanks anatolik if you read this !
Mathieu
I could unpack/repack the stock kernel with this :
From the boot.img :
dd if=boot.img of=androidBoot.img skip=8192 bs=8
Click to expand...
Click to collapse
This gives you the Android boot.img
then, we can use
split_bootimg.pl androidBoot.img
Click to expand...
Click to collapse
in order to extract the kernel.img and the ramdisk.gz.
To repack :
mkbootimg --kernel kernel.img --ramdisk ramdisk.gz --output boot.img.unsigned
futility vbutil_keyblock --pack boot.img.keyblock --datapubkey kernel_data_key.vbpubk --signprivate kernel_data_key.vbprivk --flags 7
futility vbutil_kernel --pack boot.img --keyblock boot.img.keyblock --signprivate kernel_data_key.vbprivk --version 1 --vmlinuz boot.img.unsigned --config empty --arch arm --bootloader empty --flags 0x1
Click to expand...
Click to collapse
We flash the new kernel :
fastboot flash boot boot.img : the kernel repacked is booting correctly !!
Samt434 said:
I could unpack/repack the stock kernel with this :
From the boot.img :
This gives you the Android boot.img
then, we can use
in order to extract the kernel.img and the ramdisk.gz.
To repack :
We flash the new kernel :
fastboot flash boot boot.img : the kernel repacked is booting correctly !!
Click to expand...
Click to collapse
Well done!
Works like a charm .. Thanks !
Just made a new stock rooted encrytable kernel for Pixel C .. to be installed via TWRP.
http://forum.xda-developers.com/pixel-c/development/twrp-flashable-monthly-update-zip-pixel-t3375591
Cheers
How to build pixel c kernel
Hi Samt434,
I have downloaded pixel c kernel code from chrome os git.
But I don't know which build config should I use or set.
When build other nexus device, from example, Nexus 9, I use:
make tegra_defconfig
make -j4
But what I should to do this for pixel c kernel code?
Thanks very much!
Samt434 said:
Ok so after some analysis, here is what i understood :
boot.img contains in itself an android boot.img at the adress 0x1000.
So to extract the android boot.img image, we can use dd :
dd if=chromeosBoot.img of=androidBoot.img skip=8192 bs=8
This will extract the androidBoot.img. Then we will be able to use split_bootimg.pl to extract the kernel and the ramdisk (compressed in gz).
Now my questions : from 0x0 to 0x1000 in chromos boot img, there is some data i still don't understand clearly.
I would like to try to replace the kernel and the ramdisk, and then repack all keeping the same data from 0x0 to 0x1000.
Do you think it's gonna work ?
What are the risks to do so (i don't want to brick too much my tablet...)
Thanks a lot for your help,
Hope my researches will be helpful for other developers.
Mathieu
Click to expand...
Click to collapse
make dragon_defconfig
Cheers
Sent from my Nexus 10 using Tapatalk
Samt434 said:
I could unpack/repack the stock kernel with this :
From the boot.img :
This gives you the Android boot.img
then, we can use
in order to extract the kernel.img and the ramdisk.gz.
To repack :
We flash the new kernel :
fastboot flash boot boot.img : the kernel repacked is booting correctly !!
Click to expand...
Click to collapse
hi Samt434,
I followed the instructions to flash my repacked boot image, and fastboot boot boot.img
After the boot animation, my Pixel C keeps telling me "To start Android, enter your password"
But I didn't setup any password
any clue? thanks
Samt434 said:
Here is where my researches are :
You need to get and compile vboot_reference in order to have the lastest version :
git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference
Click to expand...
Click to collapse
Is there someplace that I can download this from (already compiled)? Thanks, in advance.
I'm just trying to edit fstab.dragon, changing from force encrypt to encrytable.
cam30era said:
Is there someplace that I can download this from (already compiled)? Thanks, in advance.
I'm just trying to edit fstab.dragon, changing from force encrypt to encrytable.
Click to expand...
Click to collapse
if you have TWRP, do you mind testing https://build.nethunter.com/android-tools/no-verity-opt-encrypt/no-verity-opt-encrypt-5.1.zip for me?
It should do what you want if it succeeds. I'd like a recovery.log either way.
jcadduono said:
if you have TWRP, do you mind testing https://build.nethunter.com/android-tools/no-verity-opt-encrypt/no-verity-opt-encrypt-5.1.zip for me?
Click to expand...
Click to collapse
I will try it and report back, in a day or two. Thank you very much for the response.
@jcadduono,
It works. Thank you very much. Recovery log attached.
cam30era said:
@jcadduono,
It works. Thank you very much. Recovery log attached.
Click to expand...
Click to collapse
Thanks a lot! This is great news It also means Pixel C custom kernel dev can take advantage of https://github.com/jcadduono/lazyflasher now if they like!
It allows you to simply git clone, put an Image.gz-dtb in the folder, and type 'make' and you've got a TWRP flashable kernel!
If you guys want a simpler way to extract the boot images, you can use https://github.com/jcadduono/android_external_libbootimg
"make" will produce bootimg.exe for windows, bootimg for linux & mac. you can use "make bootimg" for just linux/mac.
Unfortunately it can only unpack ChromeOS images (bootimg xv boot.img) and not modify or create them. It will strip the ChromeOS signature and header if you do use the create/update functions of it, but you can just use futility vbutil_kernel to sign it again.
While it would certainly be nice to add the option to pack/modify ChromeOS images without needing futility, the feature alone would make my project increase in size tenfold.
Prebuilt binaries are here: https://build.nethunter.com/possibly-the-coolest-things/bootimg/
jcadduono said:
It will strip the ChromeOS signature and header if you do use the create/update functions of it, but you can just use futility vbutil_kernel to sign it again.
Click to expand...
Click to collapse
Where can I find the futility vbutil_kernel? I'd still like to be able to manually modify fstab.dragon myself.
Thanks for all of this. Much appreciated.
cam30era said:
Where can I find the futility vbutil_kernel? I'd still like to be able to manually modify fstab.dragon myself.
Thanks for all of this. Much appreciated.
Click to expand...
Click to collapse
It depends on Android libc and libcrypto inside Android build environment so it's not exactly portable but might be possible to force it static and include libc. I tried to do that myself but libcrypto doesn't seem to want to build staticly.
I'd suggest doing a shallow depth repo init of Omni 6.0 TWRP manifest if you want a smallish Android build tree to work with, allowing you to build the tool.
jcadduono said:
It depends on Android libc and libcrypto inside Android build environment so it's not exactly portable but might be possible to force it static and include libc. I tried to do that myself but libcrypto doesn't seem to want to build staticly.
I'd suggest doing a shallow depth repo init of Omni 6.0 TWRP manifest if you want a smallish Android build tree to work with, allowing you to build the tool.
Click to expand...
Click to collapse
I didn't understand a word you said.... You might as well have been speaking Greek!
I did get the part about it not being portable though. Obviously, I'm not a developer.
I'll just stick with your TWRP flashable zip!
Thanks for the feedback, though. I do appreciate it.
cam30era said:
I didn't understand a word you said.... You might as well have been speaking Greek!
I did get the part about it not being portable though. Obviously, I'm not a developer.
I'll just stick with your TWRP flashable zip!
Thanks for the feedback, though. I do appreciate it.
Click to expand...
Click to collapse
Another option as well is to flash your modified normal android boot image to your device.
Download no-verity-opt-encrypt zip 5.1+ and add a file in the patch.d folder of the zip, this should be the file's contents:
Code:
#!/sbin/sh
. "$env"
> "$split_img/boot.img-chromeos"
exit 0
(you can remove the verity/opt encrypt scripts from patch.d if you want to as well)
This will convince the zip to sign it for ChromeOS before flashing it back to the device
jcadduono said:
Another option as well is to flash your modified normal android boot image to your device.
Download no-verity-opt-encrypt zip 5.1+ and add a file in the patch.d folder of the zip, this should be the file's contents:
Code:
#!/sbin/sh
. "$env"
> "$split_img/boot.img-chromeos"
exit 0
This will convince the zip to sign it for ChromeOS before flashing it back to the device
Click to expand...
Click to collapse
I'll give it a try and let you know. Thank you.
@jcadduono,
Why don't you post your mods in the Android Development section for Pixel C. This doesn't get much visibility here, in Q&A.
Related
NEWS :
Koush's bmlunlock (a simple IOCTL send to the bml device) is just out and can replace redbend_ua !
http://github.com/CyanogenMod/android_device_samsung_bmlunlock
Hey
Is Flashing from update.zip the new trend ?
'Don't know but here is how you can do it quite easily using this template.
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
If you target another Galaxy S phone or another version of Android, you'll need to adjust ro.hardware and ro.build.id properties accordingly.
This template is done for Linux/Unixes/OSX.
If Linux cost too much for you or your employer, please contribute by sending a .bat equivalent to the .sh
Of course, you also need to put a valid zImage to replace the template's empty zImage
Feel free to adjust to your needs. License is WTFPL
Note : requirement are Java and Android source repo, already build.
Looks awesome!
I have a question though... why do you need to flash the kernel in an update.zip at boot?
As far as I know, the system will read the kernel at boot up time and load it into ram. It won't access the on-disk file again until the next boot. If that is true, then flashing while running should be 100% safe, right?
RyanZA it's an update.zip, not a ramdisk.
The point is getting an easy flashing method, requiring no computer.
And you don't even need to root your phone !
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
edit:
sorry for major dumbness, but do you think this could also somehow be used to reflash a nandroid backup?
FadeFx said:
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
Click to expand...
Click to collapse
I don't think the signing tool works on android -- maybe it does? Anyway editing scripts on a phone seems a bit silly!
FadeFx said:
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
edit:
sorry for major dumbness, but do you think this could also somehow be used to reflash a nandroid backup?
Click to expand...
Click to collapse
Nope actually this is not dumb at all
Yes the flashing part run in updater-script can be started manually.
In the script :
Code:
"redbend_ua", "restore", "zImage", "/dev/block/bml7"
The update.zip presented here mainly targets custom kernel creators in order to give them another way to distribute their work.
This is a working example of how to use redbend_ua programmatically, hopefully it may help new ideas coming. redbend_ua usage is not limited at all to kernel flashing.
PS : you can use this template with windows as well, you'll just need to translate the ulta-basic .sh to a .bat script, or do the signing part manually.
supercurio said:
Hey
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
Click to expand...
Click to collapse
quick question, the build-update-zip.sh is not a must if i only want to flash zImage, rite?
looks like that, I need to modify updater-script (if needed), as well as putting a zImage into ur zip file, and finally remove the build-update-zip.sh from ur zip attached
then, ur zip file can be used for flashing
is it correct?
thx
So this will let people flash any rom from an update.zip (once the ROM makers take this into account) via RomManager without ever having to use Odin to get off stock?
Awesome!
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
supercurio said:
Hey
Is Flashing from update.zip the new trend ?
'Don't know but here is how you can do it quite easily using this template.
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
If you target another Galaxy S phone or another version of Android, you'll need to adjust ro.hardware and ro.build.id properties accordingly.
This template is done for Linux/Unixes/OSX.
If Linux cost too much for you or your employer, please contribute by sending a .bat equivalent to the .sh
Of course, you also need to put a valid zImage to replace the template's empty zImage
Feel free to adjust to your needs. License is BSD anyway.
Note : requirement are Java and Android source repo, already build.
I'll add some documentation later.
Click to expand...
Click to collapse
dseo80 said:
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
Click to expand...
Click to collapse
Thats for the updater-script i believe. In most cases, theres a update-script in the zip's as well and the recovery picks that up in which case it doesn't need the binary and hence works.
Okay !
Answers hour
ykk_five said:
quick question, the build-update-zip.sh is not a must if i only want to flash zImage, rite?
looks like that, I need to modify updater-script (if needed), as well as putting a zImage into ur zip file, and finally remove the build-update-zip.sh from ur zip attached
then, ur zip file can be used for flashing
Click to expand...
Click to collapse
When you run ./build-update-zip.sh,
- it produce a temp zip file containing appropriate files in it.
- then there'is the signature part, building another .zip, ready to be used.
- this "final" update.zip is put in the same current directory and you can use it as it is.
No further complication
Brantyr said:
So this will let people flash any rom from an update.zip (once the ROM makers take this into account) via RomManager without ever having to use Odin to get off stock?
Awesome!
Click to expand...
Click to collapse
Yes, to flash a complete ROM (several partitions) one more thing is needed.
On command line, redbend_ua accept only one command.
In order to run several commands successively (ie flash multiple partition like Odin does), you'll need to write them in a file.
The file /cache/ota/command should do the trick, but it's untested right now.
There may be other method to prevent rebooting after flashing (hacking the redbend_ua binary, finding the appropriate command line option or removing the reboot command temporary)
dseo80 said:
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
Click to expand...
Click to collapse
Right, many update.zip done today are made without knowing anything about how it really works
I studied a bit before creating mine, here is a walk-through this fairly undocumented process :
- recovery mounts /sdcard/
- recovery search for a default file named : META-INF/com/google/android/update-binary in the zip and runs it : see the source in bootable/recovery/install.c
- update-binary is actually updater in sources
- updater looks into the zip file to the script file named updater-script, update-script is obsolete
- updater then runs the commands listed in updater-script : here is the list of commands.
- then reboot
The only documentation I know for this command is the recovery/updater/install.c file itself
supercurio said:
When you run ./build-update-zip.sh,
- it produce a temp zip file containing appropriate files in it.
- then there'is the signature part, building another .zip, ready to be used.
- this "final" update.zip is put in the same current directory and you can use it as it is.
Click to expand...
Click to collapse
ok,thx
but one more thing i want to know is, u said the path must be changed to the android repo, so do u mean the source code for the kernel like linux-xxx-2.xxx dir?
Thx
@ykk_five
Content of build-update-zip.sh v1 :
Code:
#!/bin/sh
DROID_HOME="/home/curio/dev/mydroid"
zip -r /tmp/update.zip META-INF/ redbend_ua zImage
java -jar \
$DROID_HOME/out/host/linux-x86/framework/signapk.jar \
$DROID_HOME/build/target/product/security/testkey.x509.pem \
$DROID_HOME/build/target/product/security/testkey.pk8 \
/tmp/update.zip update.zip
rm /tmp/update.zip
adb push update.zip /sdcard/
DROID_HOME="/home/curio/dev/mydroid" : you set here the directory of your Android AOSP directory.
See : http://source.android.com/source/download.html
Create an empty directory to hold your working files:
$ mkdir mydroid
$ cd mydroid
Run "repo init" to bring down the latest version of Repo with all its most recent bug fixes. You must specify a URL for the manifest:
$ repo init -u git://android.git.kernel.org/platform/manifest.git
* If you would like to check out a branch other than "master", specify it with -b, like:
$ repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake
Click to expand...
Click to collapse
This is this mydroid directory
The one that contains Android git source home directory, and compiled files in the out/ subdir
many thx for ur detailed explanation, supercurio!
Thanks curio,
very helpful explanation!
Thanks supercurio for the template!
However, there is no need to spend many hours (depending on hardware and bandwidth) pulling down 100s of megabytes of source and compiling it all if all you want is to sign an update.zip with test keys (if you already have the zImage)!
Just google around for "signapk.jar test keys" and you will get there.
BTW: I know that koush, leshak and wesgamer have Samsung Galaxy S trees up at Github but are they fully merged with AOSP yet?
I'm planning to go build my own kernel for this beast to try to solve the mono FM radio mystery, but last time I checked around it was said that the SGS tree required the use of a custom toolchain to get it to work at all.
Any comments on this?
Hey miki4242 !
Good to know that signapk.jar doesn't require hundred of megs of dependencies
About toolchain, you can use the one indicated by Samsung (CodeSourcery) but you'll face the big and ugly WakeLag.
I recommend you crosstool-ng or buildroot to build toolchains, with gcc 4.3.x march=arm mcpu=cortex-a8 mtune=cortex-a8 (no 4.4.x with march=armv7-v)
The building tutorial will be a part of the documentation I'll publish with my lagfix opensource release
Right now these info are too hard to find.
PS : I send you a mail with attached .config for ct-ng !
supercurio said:
Hey miki4242 !
Good to know that signapk.jar doesn't require hundred of megs of dependencies
Click to expand...
Click to collapse
supercurio said:
PS : I send you a mail with attached .config for ct-ng !
Click to expand...
Click to collapse
Thanks for the info !
Sorry for my ignorance, but does this mean someone can package Froyo in an update.zip and we could update it directly on our phone without needing Samsung Kies or Odin?
@supercurio:
Thanks for this well working template.
In updater-script:
Code:
line 17: package_extract_dir("zImage", "zImage");
should be
Code:
package_extract_file("zImage", "zImage");
But it did work with package_extract_dir, for some reason, too.
Btw, could you send me the config for ct-ng ?
I'm also struggling with this wakelag.
Overview
Here are the steps to build your own kernel from source. This example does nothing special. It just shows you how to build the stock kernel. It is a good starting point to making your own stuff. Experts, please correct me where I am wrong. This stuff is still new to me also.
These instructions work for both T989 (T-Mobile) and I727 (AT&T) variants of the Samsung Galaxy S2 phones.
Special Thanks
Special thanks to "interloper" and "dtm_stretch" for helping me learn all of this. Couldn't have done it without them.
Requirements
I am using Ubuntu 10.10 32-bit to do all my builds
Instructions
1) Get Samsung Source Code
First you need to get a copy of the kernel source code from Samsung. You can download it from the link below.
For T-Mobile users download the one that says T989:
https://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SGH-T989
For AT&T users download the one that says SGH-I727:
https://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SGH-I727
2) Unzip Samsung Source Code
Unzip the source code you just download with this command:
For T989:
Code:
unzip SGH-T989_GB_Opensource.zip
For I727:
Code:
unzip SGH-I727_ATT_Opensource.zip
There will be 4 files extracted. The one we are interested in for this exercise is SGH-T989_Kernel.tar.gz for T989 devicees or SGH-I727_ATT_Kernel.tar.gz for I727 devices.
3) Extract Kernel
Next we need to extract the kernel into a directory.
For T989:
Code:
mkdir kernel
tar xzf SGH-T989_Kernel.tar.gz -C kernel
or
For I727:
Code:
mkdir kernel
tar xzf SGH-I727_ATT_Kernel.tar.gz -C kernel
4) Get a Copy of initramfs
Next you need to get a copy of the initramfs for your phone. For T989 users you can get the stock initramfs from bubby323's github here: https://github.com/bubby323/anomaly_kernel_platform_SGH-T989
For I727 users you must use the alternate method below to get the initramfs. T989 users can choose to use the link above or go with the alternate method below.
Alternate method:
You can extract it yourself from an existing boot.img file. I got mine off of my phone using clockworkmod backup (boot.img file) and using the extractboot tool to extract the initramfs. The tool can be downloaded here: http://www.mediafire.com/?lc12eceeh617b97
Extract extractboot.tar.gz
Code:
tar xzf extractboot.tar.gz
Call this to extract your boot.img to get the initramfs folder
Code:
extractboot boot.img
If you get any errors with calling extractboot, make sure "extractboot" and "split_bootimg.pl" are executable first. If not, use "chmod a+x extractboot" (do the same for split_bootimg.pl).
Once extracted, the "out/ramdisk" folder is your extracted initramfs folder.
reference: http://www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows
5) Download Arm Toolchain
This toolchain will allow you to cross compile for your phone. There are several versions to choose. I currently use the 2010q1 version here: https://sourcery.mentor.com/sgpp/li...1-188-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
Or choose another version if you like (version 2009q3 seems to be popular): https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription3053
6) Extract Toolchain
Code:
tar xjf arm-2010q1-188-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
7) Download mkbootimg Tools
Download mkbootimg tools from here: http://www.mediafire.com/?w06d1m6n1dgo4op
Extract the file with
Code:
tar xzf mkboottools.tar.gz
There will be three files
Code:
mkbootfs
mkbootimg
mkbootimg-sg2x
"mkbootimg" is the original program to make the boot image but is not used for our phone. Our phone requires an edit to the ramdisk address which is why I also included "mkbootimg-sg2x" which we will use instead.
*Extra Info: the default ramdisk offset is 0x01000000 while our phone needs 0x01400000.
Move the three files to somewhere in your system PATH.
8) Compile Script
Now we are ready to compile the kernel. I have provided a script below to automate the process. You will need to change the paths to work with your environment.
*For I727 users only: change "msm8660_celox_usa_tmo_defconfig" to "msm8660_celox_usa_att_defconfig" in the script below.
*Update: Thanks to InstigatorX for his comment:
Also, for ATT the celox make command should be "make msm8660_celox_usa_att_rev02_defconfig" to make the latest 2.3.6 kernel.
Click to expand...
Click to collapse
Code:
INITRAMFSDIR=~/t989/initramfs
export ARCH=arm
export CROSS_COMPILE=~/arm-2010q1/bin/arm-none-eabi-
cd kernel
make clean
make mrproper
make msm8660_celox_usa_tmo_defconfig
make -j4
# copy the freshly compiled modules to the initramfs.
cp crypto/ansi_cprng.ko $INITRAMFSDIR/lib/modules/
cp drivers/bluetooth/bthid/bthid.ko $INITRAMFSDIR/lib/modules/
cp arch/arm/common/cpaccess.ko $INITRAMFSDIR/lib/modules/
cp arch/arm/mach-msm/dal_remotetest.ko $INITRAMFSDIR/lib/modules/
cp drivers/net/wireless/bcm4330/dhd.ko $INITRAMFSDIR/lib/modules/
cp arch/arm/mach-msm/dma_test.ko $INITRAMFSDIR/lib/modules/
cp drivers/input/evbug.ko $INITRAMFSDIR/lib/modules/
cp drivers/media/video/gspca/gspca_main.ko $INITRAMFSDIR/lib/modules/
cp arch/arm/perfmon/ksapi.ko $INITRAMFSDIR/lib/modules/
cp drivers/video/backlight/lcd.ko $INITRAMFSDIR/lib/modules/
cp drivers/net/wireless/libra/librasdioif.ko $INITRAMFSDIR/lib/modules/
cp drivers/misc/msm_tsif.ko $INITRAMFSDIR/lib/modules/
cp arch/arm/oprofile/oprofile.ko $INITRAMFSDIR/lib/modules/
cp drivers/crypto/msm/qcedev.ko $INITRAMFSDIR/lib/modules/
cp drivers/crypto/msm/qce.ko $INITRAMFSDIR/lib/modules/
cp drivers/crypto/msm/qcrypto.ko $INITRAMFSDIR/lib/modules/
cp drivers/scsi/scsi_wait_scan.ko $INITRAMFSDIR/lib/modules/
cp drivers/spi/spidev.ko $INITRAMFSDIR/lib/modules/
cp drivers/misc/tsif_chrdev.ko $INITRAMFSDIR/lib/modules/
cp drivers/misc/vibetonz/vibrator.ko $INITRAMFSDIR/lib/modules/
9) Get Compiled Kernel
The compiled kernel image is in the kernel source folder under "arch/arm/boot/zImage"
Copy the zImage file to a working area, preferably where you keep your initramfs folder.
Here is an example folder structure:
Code:
work
- zImage
- initramfs
10) Make boot.img File
Next we need to merge the kernel and initramfs directory into a boot.img file.
zip up ramdisk
Code:
mkbootfs initramfs | gzip > ramdisk.gz
make boot image
Code:
mkbootimg-sg2x --kernel zImage --ramdisk ramdisk.gz --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img --base 0x40400000 --pagesize 2048
11) tar boot.img
Tar your boot.img file so it can be flashed with Odin.
Code:
tar cvf MyKernel.tar boot.img
md5sum -t MyKernel.tar >> MyKernel.tar
mv MyKernel.tar MyKernel.tar.md5
12) Flash with Odin
Flash MyKernel.tar.md5 with odin under PDA. Please follow the flashing guides found in other posts. They do a better job at explaining.
13) Experiment *
Now try to customize your kernel to add in new features and experiment. I am going to learn how to compile the stock platform also. Once I know how I will post up a guide for that also. If someone already has a guide to build the platform please post. Also it would be great if you can post sources for me to read so I can learn how to build the platform. Thanks.
Optional
You might notice that the modules you compiled are significantly bigger than the original stock modules that came with the phone. That is because the stock modules were stripped of all debug info. To do this you need to run the below command at the end to get the "stripped" modules. Change INSTALL_MOD_PATH to point to any folder you like to hold the modules. You then need to copy these modules instead of the ones in the build script above.
Code:
make INSTALL_MOD_STRIP=1 INSTALL_MOD_PATH=~/stripped/modules modules_install
What's Next?
Go here to learn how to start making changes to your ROM: http://forum.xda-developers.com/showthread.php?p=23343879
Good heads up. Thanks for putting this out there.
Once edited this needs to get stuckod
Sent from my SGH-T989 using xda premium
Thanks so much for this! I've been trying to figure this out for months. (Learned alot in that time).
Kernel Built!
Daunting....ill stick to this side of the fence
Thanks though. Must be tough explaining all of that...
Sent from my Phablet. The Purple Phone Tablet.
Great info !! Super !
Some questions: 1. How does one allow for SELECTION of custom boot animation? Is that a kernel thing or some thing else?
2. What about adding things like Voodoo Sound or some mod like that?
Thanks for any info !!
chappatti said:
Great info !! Super !
Some questions: 1. How does one allow for SELECTION of custom boot animation? Is that a kernel thing or some thing else?
2. What about adding things like Voodoo Sound or some mod like that?
Thanks for any info !!
Click to expand...
Click to collapse
I am glad you like it. I wanted to post this guide up so that noobs like me have a good starting point to learn this stuff.
I can take a crack at answering your questions, but do note that I am also a noob:
1) I would think a custom boot animation would be part of the ROM but not sure
2) I do not know what Voodoo Sound is but if it is an application then it would be modifying the ROM. If it is an enhancement to the audio drivers then it is kernel. Either way I would not know what to change. Sorrry.
I know I wasn't much help. But I tried
By the way, I am currently trying to learn how to make my own custom ROM. If you know of any guides that would be great if you can post them here. I will definitely post what I find. Currently I am downloading ROMs from this forum and seeing what they did to learn. One thing I am still confused about is if these guys built these ROM from source or used the binaries from the Stock ROM as base.
Thanks.
Nice Guide man...
datzstr8 said:
I am glad you like it. I wanted to post this guide up so that noobs like me have a good starting point to learn this stuff.
I can take a crack at answering your questions, but do note that I am also a noob:
1) I would think a custom boot animation would be part of the ROM but not sure
2) I do not know what Voodoo Sound is but if it is an application then it would be modifying the ROM. If it is an enhancement to the audio drivers then it is kernel. Either way I would not know what to change. Sorrry.
I know I wasn't much help. But I tried
By the way, I am currently trying to learn how to make my own custom ROM. If you know of any guides that would be great if you can post them here. I will definitely post what I find. Currently I am downloading ROMs from this forum and seeing what they did to learn. One thing I am still confused about is if these guys built these ROM from source or used the binaries from the Stock ROM as base.
Thanks.
Click to expand...
Click to collapse
Roms such as AOKP or CM are compiled from source, otherwise known as AOSP. However, the majority of the roms you'll find here are not. To build a non-source rom a good starting point would be a system dump from your own phone, or find a pre-deodexed, stock base rom. From there, the tool of the trade is 7zip. View all the file via 7zip, pull files and modify. Now obviously, this is only a starting point, couldn't possibly go into advanced development with you. It takes time to learn and it's a lot of trial and error. Another helpful tool to learn is ADB commands and functionality. If you know this, it will save you a lot of time. Good luck!
This guide is a life-saver. I have compiled my own kernel for my desktop literally dozens of times, and have built distributions entirely from scratch two or three times (using Linux From Scratch), but was unable to figure this out myself due to the lack of a guide and things being scattered everywhere and people unwilling to help.
THANK YOU!!!!
I am really looking forward to your guide on how to build an Android system from scratch. I have also been trying to do this as well (Cyanogen), but am running into the same lack of information.
sombionix said:
Roms such as AOKP or CM are compiled from source, otherwise known as AOSP. However, the majority of the roms you'll find here are not. To build a non-source rom a good starting point would be a system dump from your own phone, or find a pre-deodexed, stock base rom. From there, the tool of the trade is 7zip. View all the file via 7zip, pull files and modify. Now obviously, this is only a starting point, couldn't possibly go into advanced development with you. It takes time to learn and it's a lot of trial and error. Another helpful tool to learn is ADB commands and functionality. If you know this, it will save you a lot of time. Good luck!
Click to expand...
Click to collapse
So Som,
When are we going to see another nice Bionix build from you. anything in plan or not really.
An automation script would be a juicy treat and i may have just the thing...will need to be modified for this and tested but tomorrow (today, oh look at the time) i can put it together. Also, try building using make gconfig. Load your default config with the gui and you can see what bits of the kernel can be changed.
Sent from my SPH-D710 using xda premium
Very nice guide! Thanks a lot!
I wondering about what is the difference between Hercules and Skyrocket sources? Is it only this "*For I727 users only: change "msm8660_celox_usa_tmo_defconfig" to "msm8660_celox_usa_att_defconfig" in the script below." ?
erickwill said:
Very nice guide! Thanks a lot!
I wondering about what is the difference between Hercules and Skyrocket sources? Is it only this "*For I727 users only: change "msm8660_celox_usa_tmo_defconfig" to "msm8660_celox_usa_att_defconfig" in the script below." ?
Click to expand...
Click to collapse
You will still need the proper source for i727. Config file just tells the compiler what to build.
:: LOVE MY HATERS :: DARKSIDE ::
These instructions assume the user already has the boot.img tools, bubby's initramfs and source code from the OP
1. Create a directory called t989-kernel
2. Download this package of tool chains and unzip it, making sure it is named "toolchains" toolchains
NOTE: There are many toolchains included in this pack and I have used them all to make kernel for the E4GT and they are all
sufficient for this task. However, should you move on to 3.X kernel I suggest using the Mjolnar or Linaro tools as they
are more suitable for that version.
3. Inside the "t989" directory deposit bubby's initramfs, the kernel source (extracted directory), toolchains and boot.img tools.
4. The names of the directories must be "ramdisk", "kernel" (kernel source), "toolchain", and "bin". Change them accordingly.
5. Put the attached "tmo-build.sh" into the "kernel" directory
6. Edit line 9 to reflect you version number and name. It will be what you see when you look at the phone properties
7. Change line 20 of the script to reflect your machine's name
8. cd into "kernel"
9. Type "./tmo-build.sh" and watch the magic as your kernel is made right before your eyes!
10. Go to "kernel_tmp/out" and get your shiny new homemade kernel complete with custom recovery and all the fixins'
NOTE: You can change line 41 to say "make gconfig" if you have GTK2 installed on your system. This will allow you to launch a GUI
through the script to make changes in a visual manner. If you get any "file not found" or "no such file" etc, make sure the
permissions are set to executable for all directories/files.
I'm still working on the error logging output so I will post an updated script as soon as it's ready. For the i727 users I will post a script for you too, but to make this work for you all you need to do is choose the make gconfig route and load your def_config from /arch/arm/configs/
Enjoy the silence!
interloper, thanks for the great script!!! This will help a lot of people.
afawzi said:
So Som,
When are we going to see another nice Bionix build from you. anything in plan or not really.
Click to expand...
Click to collapse
+1
From a galaxy better than yours.
I am starting another GUIDE post on how to modify your ROM here: http://forum.xda-developers.com/showthread.php?p=23343879
Sweet guide. Worked great. Only thing I had issue with was Haptic feedback and WiFi wouldn't work. Any ideas? I'm on the SkyRocket.
Also, for ATT the celox make command should be "make msm8660_celox_usa_att_rev02_defconfig" to make the latest 2.3.6 kernel.
how do you make it cwm flashable?
Hi Guys...
I really can't figure out how I go about installing CM7.2 on my arc again, after upgrading to BaseBand70 + ICS.
I tried a lot of different stuff and what ussually happens, is when I install the CM bootmloader, the phone won't turn on and the screen keeps on being black.
Right now I have the Arconium rom installed and it works fine, but I miss the smootness and the awesome battery life I had on with CM7.2
I've tried to install various tft files flashtool, but the only thing I can get to work is the BB70 one.
Hope you guys can help
You can return to CM7 but you must flash CM7 kernel with flash tool.
view topic : here
fabou said:
You can return to CM7 but you must flash CM7 kernel with flash tool.
view topic : here
Click to expand...
Click to collapse
Thanks...
But I have already tried that and that doesn't work... I thought it was because I needed to flash an older baseband or something similar?
i think the baseband is not linked with the kernel, but you can flash the kernel and you can upgrade baseband.
Did you try the FXP117 kernel? maybe the kernel work, it's a bluid problem.
On CM9 I had the same problem .
adrianom said:
Guys,
The problem of boot image is again in ramdisk, and is only a build problem, I extract the 117 boot.img and only recompress and work.
If someone wants to build for other devices, the command to build the boot.img, is:
Use unpack-bootimg.pl to extract the boot.img:
Code:
unpack-bootimg.pl boot.img
Rebuild the ramdisk:
Code:
cd boot_117.img-ramdisk
find . -name ".DS_Store" -depth -exec rm {} \;
find . | cpio -o -H newc | gzip > ../ramdisk.cpio.gz;
cd ..
Rebuild the boot.img:
Code:
mkbootimg --base 0x00200000 --kernel boot_117.img-kernel --ramdisk ramdisk.cpio.gz -o boot.img
Ps.: the script above is for Mac, but should also work for Linux.
Attached below is the fix boot.img.
Click to expand...
Click to collapse
WARNING : this quote is for CM9!!
follow this thread and maybe it will have a patch
Hello everyone.
This guide will help you in building a kernel from source for your Nexus 10
Later, when 4.2 hits AOSP, i'll add a guide for building that too
You will need a computer running Linux / OSX to build the kernel, natively, or via a VM.
This guide assumes you’re running any Linux distro.
Getting a toolchain:
You need a toolchain to build the kernel.
The preferred one is Google’s toolchain, the same they use to build AOSP.
In a terminal, type:
Code:
git clone [url]https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/[/url]
export PATH=$PATH:$(pwd)/arm-linux-androideabi-4.6/bin
export CROSS_COMPILE=arm-linux-androideabi-
TIp: paste the export statements in your ~/.bashrc to have them exported each login.
Getting the kernel source:
The kernel source for Nexus devices is available from Google’s servers.
Source : https://android.googlesource.com/kernel/exynos
Github Mirror: https://github.com/chirayudesai/android_kernel_exynos
Open the terminal, and type the below commands to get the kernel source on your computer.
Code:
mkdir -p android/kernel
cd android/kernel
For Nexus 10, we get the exynos kernel sources.
Code:
git clone [url]https://android.googlesource.com/kernel/exynos[/url]
Next, we change our directory to the newly fetched source.
Type
Code:
cd exynos
Figuring out what to build:
Now, we need to figure out which revision to build.
You need to be exactly sure about this, otherwise there are chances that the compiled kernel won’t work.
The commit to build upon can be found by a few ways.
To get the kernel sources matching the device tree, type the below in the device tree.
Code:
git log kernel
Then type the below in the kernel tree
Code:
git checkout <commit>
The commit of the version running on the current review units is 52f6ab1 (probably), which is same as branch android-exynos-manta-3.4-jb-mr1-fr .
Compiling:
Name of defconfig: manta_defconfig
cd to the directory of the kernel source, then type the below in a terminal.
Code:
export ARCH=arm
export SUBARCH=arm
Code:
make <name_of_defconfig>
make
The kernel image will be ready at arch/arm/boot/zImage
To flash it, you need to make it into a boot.img, more on that later. when we have more sources.
Nice work, it's been nice to see some instructions on building additional kernel modules too.
Sent from my GT-I9300 using Tapatalk 2
Great guide! I look forward to seeing your tutorial on compiling 4.2 from source .
Sent from my SCH-I535 using xda premium
Super awesome! I'm currently thoroughly:good: learning the rom building process with my nexus... ill get to this!
looking forward towards the development
Great! This is very helpful and useful
hey man, i got stuck at this point
Code:
git log kernel
it gives me this error
Code:
fatal: ambiguous argument 'kernel': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
didn't really get that point... thanks :good:
matt95 said:
hey man, i got stuck at this point
Code:
git log kernel
it gives me this error
Code:
fatal: ambiguous argument 'kernel': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
didn't really get that point... thanks :good:
Click to expand...
Click to collapse
It has to be typed in the device tree, which hasn't hit AOSP yet, but should soon.
Sent from my GT-P1000
cdesai said:
It has to be typed in the device tree, which hasn't hit AOSP yet, but should soon.
Sent from my GT-P1000
Click to expand...
Click to collapse
oh, now i get this :good:
i was able to make a build tonight from aosp, waiting for my device to arrive & then ill be able to test. but as far as i could tell the output sizes were pretty on compared to the factory image files i extracted http://renzy.me/aoi
...just realized i didnt extract proprietary binaries.
Hello, Cdesai.
Thanks for your guide!
I will do my best to learn it.
so you say that you need to make the zImage into a boot.img (being a noob about this...) on my SGSII, I can flash zImages and boot.img, so I'm confused, lol
jrod091 said:
so you say that you need to make the zImage into a boot.img (being a noob about this...) on my SGSII, I can flash zImages and boot.img, so I'm confused, lol
Click to expand...
Click to collapse
i think it depends on how youre flashing. with the sgsii youre prob using odin/heimdall & it might just overwrite the kernel. flashing with fastboot might require the boot.img cause it contains a ramdisk image after the kernel & is writing a partition. thats just my guess at least, someone else might have a better/more accurate answer for ya
renzyyy said:
i think it depends on how youre flashing. with the sgsii youre prob using odin/heimdall & it might just overwrite the kernel. flashing with fastboot might require the boot.img cause it contains a ramdisk image after the kernel & is writing a partition. thats just my guess at least, someone else might have a better/more accurate answer for ya
Click to expand...
Click to collapse
yeah that's true, but for instance with HTC S-OFFed devices you don't even need to flash the boot.img....
cdesai said:
... To flash it, you need to make it into a boot.img, more on that later. when we have more sources.
Click to expand...
Click to collapse
you can extract the contents from the factory image & use getramdisk.py to get the ramdisk.img out of the current boot.img (or use this ramdisk.img)
then once youve compiled the kernel successfully, use mkbootimg from android_bootimg_tools.tar.gz to repack your boot.img.
if you want to just test...
fastboot boot [new-boot.img]
and flash if satisfied...
fastboot flash boot [new-boot.img]
just tested out if anyone wants some verification... screenshot
@cdesai, shouldn't we be using arm-eabi- instead of arm-linux-androideabi- as CROSS_COMPILE
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/
export PATH=$PATH:$(pwd)/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
Building with arm-linux-androideabi- causes issues with kernel modules... here's an example of such an issue https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/dzEIOVuxtEo
And the most updated kernel branch is android-exynos-manta-3.4-jb-mr1 not android-exynos-manta-3.4-jb-mr1-fr
Is there any chance of this becoming an OC kernel in the future?
craigacgomez said:
@cdesai, shouldn't we be using arm-eabi- instead of arm-linux-androideabi- as CROSS_COMPILE
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/
export PATH=$PATH:$(pwd)/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
Building with arm-linux-androideabi- causes issues with kernel modules... here's an example of such an issue https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/dzEIOVuxtEo
And the most updated kernel branch is android-exynos-manta-3.4-jb-mr1 not android-exynos-manta-3.4-jb-mr1-fr
Click to expand...
Click to collapse
Yes, I couldn't get md4 and cifs modules to load with arm-linux-androideabi-4.6:
<3>[ 1250.492203] md4: unknown relocation: 27
<4>[ 1260.230901] cifs: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)
However, with this:
git clone https://android.googlesource.com/platform/prebuilt
export PATH=$PATH:$PWD/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
export CROSS_COMPILE=arm-eabi-
The modules load okay:
[email protected]:/mnt/shell/emulated/0 # lsmod
cifs 269223 0 - Live 0x00000000
md4 3442 0 - Live 0x00000000
(Now I have to work out why neither mount nor cifsmanager are working as expected...)
sam3000 said:
Yes, I couldn't get md4 and cifs modules to load with arm-linux-androideabi-4.6:
<3>[ 1250.492203] md4: unknown relocation: 27
<4>[ 1260.230901] cifs: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)
However, with this:
git clone https://android.googlesource.com/platform/prebuilt
export PATH=$PATH:$PWD/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
export CROSS_COMPILE=arm-eabi-
The modules load okay:
[email protected]:/mnt/shell/emulated/0 # lsmod
cifs 269223 0 - Live 0x00000000
md4 3442 0 - Live 0x00000000
(Now I have to work out why neither mount nor cifsmanager are working as expected...)
Click to expand...
Click to collapse
I know the reason... busybox needs to be patched... i guess it's something new in 3.4.5 kernel... I haven't done the patch yet
https://github.com/OpenELEC/OpenELEC.tv/commit/f66041febdb07d13a158dab5da901d208cf4fff9
craigacgomez said:
I know the reason... busybox needs to be patched... i guess it's something new in 3.4.5 kernel... I haven't done the patch yet
https://github.com/OpenELEC/OpenELEC.tv/commit/f66041febdb07d13a158dab5da901d208cf4fff9
Click to expand...
Click to collapse
I had actually just got to the point of realising I could make it work by explicitly setting the unc path in mount command options. The missing patch would explain it.
Hello,
In order to debug the bluetooth problem, I'm trying to compile a kernel for the Captivate Glide. I can't get it to boot properly.
@steadfasterX 's SediROM is the highest-version ROM I know of on which bluetooth works so I've got it installed (version 2.1.2) on the phone.
The steps I've taken so far:
1. I have sedikernel from https://github.com/steadfasterX/kernel_samsung_i927 at commit 088aa4109ad144c583f32da5ffba7bac200f0575
2. I copied /proc/config.gz from a running phone, which contains CONFIG_LOCALVERSION="-sediKERNEL-v1.0", ungzipped it and saved it as .config . Haven't changed anything in it yet.
3. I ran `make CROSS_COMPILE=arm-linux-gnueabihf- zImage` (also tried arm-none-eabi- (both from Debian Jessie) as well as ~/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi- from the NDK)
4. I also made a TWRP backup of the boot partition, and used split_bootimg.pl from William Enck to split it into a kernel and initrd
5. I then ran mkbootimg with the initrd extracted in step 4 and the kernel obtained in step 3 in arch/arm/boot/zImage
6. Finally I flashed this new boot.img onto the phone with odin (Heimdall, specifically)
I see the white "SAMSUNG" logo (which is normal when booting) with a yellow-triangle with an exclamation mark in it. No further boot stage happens (no bootanim from sediROM). If I re-pack the original kernel with bootimg and flash that via odin, then after the next boot the yellow triangle changes into a blue one and sediROM boots correctly.
I'm a bit stuck at the moment, not sure what's going wrong there. Probably the kernel panics for some reason. Is there a way to read the kernel boot messages before android starts? Any help would be greatly appreciated.
Thanks!
Successful!
Thanks to a lot of help from @steadfasterX on IRC I finally managed to compile a working kernel
Here's a list of steps I had to follow in addition to https://github.com/steadfasterX/android_device_samsung_i927/blob/sediROM_CM-ICS/README.md :
1. as discussed on IRC, `repo sync` was not finding a branch. Needed to add
Code:
revision="refs/heads/ics-release"
in .repo/manifests/default.xml in the line with
Code:
CyanogenMod/android_vendor_qcom_opensource_v8
2. I removed the spurious comma in device/samsung/i927/cm.dependencies
3. In device/samsung/i927/, I changed vendorsetup.sh to point to vendorsetup.sh.nopatching rather than .patching (none of the patches could be applied)
4. lunch target was therefore the one with -eng, not -userdebug
5. I installed java 6 manually (didn't have sudo)
6. I installed schedtool
7. I adjusted the path to Java and my toolchain in build_sediROM.sh (taken from https://github.com/steadfasterX/android_buildtools )
8. I downgraded GNU make from 4.0 to 3.81
9. I installed linux-headers and created a symlink from /usr/include/asm-generic to /usr/include/asm
10. I changed the toolchain prefixes in device/samsung/i927/BoardConfig.mk to have 4.4.3 rather than 4.7
11. I built with
Code:
BUILDID=samsung/i927 LOKIFY=0 ../android_buildtools/build_sediROM.sh bootimage
12. I used the original ramdisk I had extracted from sediROM's boot image, rather than the one that was built (we discussed this on IRC too)
This got me a working kernel, yay
uukgoblin said:
Thanks to a lot of help from @steadfasterX on IRC I finally managed to compile a working kernel
Here's a list of steps I had to follow in addition to https://github.com/steadfasterX/android_device_samsung_i927/blob/sediROM_CM-ICS/README.md :
1. as discussed on IRC, `repo sync` was not finding a branch. Needed to add
Code:
revision="refs/heads/ics-release"
in .repo/manifests/default.xml in the line with
Code:
CyanogenMod/android_vendor_qcom_opensource_v8
2. I removed the spurious comma in device/samsung/i927/cm.dependencies
3. In device/samsung/i927/, I changed vendorsetup.sh to point to vendorsetup.sh.nopatching rather than .patching (none of the patches could be applied)
4. lunch target was therefore the one with -eng, not -userdebug
5. I installed java 6 manually (didn't have sudo)
6. I installed schedtool
7. I adjusted the path to Java and my toolchain in build_sediROM.sh (taken from https://github.com/steadfasterX/android_buildtools )
8. I downgraded GNU make from 4.0 to 3.81
9. I installed linux-headers and created a symlink from /usr/include/asm-generic to /usr/include/asm
10. I changed the toolchain prefixes in device/samsung/i927/BoardConfig.mk to have 4.4.3 rather than 4.7
11. I built with
Code:
BUILDID=samsung/i927 LOKIFY=0 ../android_buildtools/build_sediROM.sh bootimage
12. I used the original ramdisk I had extracted from sediROM's boot image, rather than the one that was built (we discussed this on IRC too)
This got me a working kernel, yay
Click to expand...
Click to collapse
its really long guide. You have to replace kernel modules, wifi wouldnt work without modules.
Imho best is compile kernel, modules, replace zImage + modules in this
file and flash from recovery. You dont need to compile whole android just the kernel, you dont need java and other special things, this method is much more faster.
bubor said:
its really long guide. You have to replace kernel modules, wifi wouldnt work without modules.
Imho best is compile kernel, modules, replace zImage + modules in this
file and flash from recovery. You dont need to compile whole android just the kernel, you dont need java and other special things, this method is much more faster.
Click to expand...
Click to collapse
You are right for the kernel but we discussed on IRC to build ram disk too then you need all that stuff but most important he wants to build CM too.
However I'm always a fan of making it right so building a ram disk is the correct way of creating a bootimage. But to start its ok replacing kernel and modules first.
.
Sent from my LG-H815 using XDA Labs
steadfasterX said:
Sent from my LG-H815 using XDA Labs
Click to expand...
Click to collapse
correct way is rebuild whole android, and reflash everything, wipe data/cache
You dont want to make new ramdisk without replace system. System and ramdisk bound together.
I hope you find something, and fix bluetooth or voip audio.
good luck
bubor said:
correct way is rebuild whole android, and reflash everything, wipe data/cache
You dont want to make new ramdisk without replace system. System and ramdisk bound together.
I hope you find something, and fix bluetooth or voip audio.
good luck
Click to expand...
Click to collapse
Well no and yes. I build kernels including ram disk without building system. This is not necessary as long both are compatible.
But you are right that booting fails when system and ram disk are not compatible so the correct way depends
However @uukgoblin I hope you get the fix you want :fingers-crossed:
Sent from my LG-H815 using XDA Labs
steadfasterX said:
Well no and yes. I build kernels including ram disk without building system. This is not necessary as long both are compatible.
But you are right that booting fails when system and ram disk are not compatible so the correct way depends
However @uukgoblin I hope you get the fix you want :fingers-crossed:
Sent from my LG-H815 using XDA Labs
Click to expand...
Click to collapse
would you tell me an example when kernel doesnt compatible with ramdisk but kernel does compatible with system?
bubor said:
would you tell me an example when kernel doesnt compatible with ramdisk but kernel does compatible with system?
Click to expand...
Click to collapse
No no my friend that's not what I said. :cyclops:
I meant if you have CM 9 as system you can build a boot image which includes kernel and a CM9 based ram disk without building cm9 system again. :laugh:
.
Sent from my LG-H815 using XDA Labs