CM12 - building, optimising, fixing, having fun - Galaxy S 4 Mini Android Development

Hi all o/
To celebrate two weeks of my successful CM12 building and hacking, I'm starting this thread. Its purpose is to discuss general CM12 building steps for beginners like myself, bugs and fixes, applying @JustArchi's optimisation flags, solving the resulting build failures.... and all the other CM12/S4Mini-related questions that don't belong to F4k's [ROM] thread but end up there (I was guilty of that).
First of all, my thanks go to:
@arco68 for making it possible to build ROMs for our S4mini
CyanogenMod team for the ROM itself
@F4k for his kernel and all the other excellent contributions to this forum
@JustArchi for finding what he found
In this first post I will outline the steps needed to build a vanilla unofficial CM12 for serranoltexx. serranoltexx is the only device I have so this is what I'll introduce. I suspect building serrano3gxx is just as simple (just replace the device name in all the relevant steps). I don't know what to do to build for i9192, if you do please contribute
Building your own CM12 ROM
Main article: http://wiki.cyanogenmod.org/w/Build_for_serranoltexx
The article above tells you how to build CM11, but CM12 builds just as well with minor modifications I'll outline here. To follow those steps you need a Linux installation. I will write how you can make an example Lubuntu-based virtual machine on your Windows box in a post below.
Modifications to the build steps:
"Install the SDK" -- you can skip that, because in the end we will not use any SDK tools.
"Install the Build Packages" - replace jdk6 with jdk7 everywhere, as Java 7 is needed to build Lollipop.
"Create the directories" - I will assume you've followed those steps and everything is under ~/android/system/
"Initialize the CyanogenMod source repository" replace "cm-11.0" with "cm-12.0" of course
"Extract proprietary blobs" we will do this completely differently. If you try to use extract-files.sh, the script will fail, and when I finally fixed the script my camera didn't work...
So, do this instead (credit to @F4k and @kyrillos13 for answering my question on page 90 of F4k's ROM thread)
* Go to https://github.com/TheMuppets/proprietary_vendor_samsung
* Switch branch to cm-12.0
* Use the "Download ZIP" button to get the copy of the entire thing. The zip is big (500 MB? ish) and 95% of it useless for us, so if you're trying to save some bandwidth you can try to do this trick to get only the "serrano-common" folder. If you do, make a post here with exact steps for others
* Copy the "serrano-common" folder to ~/android/system/vendor/samsung/ (to clarify, final directory structure should include ~/android/system/vendor/samsung/serrano-common/proprietary/app/ folder among others)
"Turn on caching to speed up build" - sounds like a good idea but we're going to be playing with compiler options, which diminishes its usefulness. It also uses a lot of disk space. Only follow it if you want your daily increments to build fast, and you don't expect to be doing global changes such as optimisation flag changes often. I didn't do this step.
This concludes my first post in this thread. I personally have never had problems with building after this part (except when I had not enough space or memory) and the resulting vanilla builds always worked for me fine. Feel encouraged!
Next post: some tricks and useful commands

A random selection of interesting things:
What recovery is good for applying my builds
Well they're all good, and they all work I bet. What I use is Phil's Touch and I'm on version 6.48.4 and it's worked perfectly.
How do I dirty flash my build on top of another CM12 build
I keep doing that since early F4k's builds and have no problems (yet!!). The trick is to only keep /data, while wiping everything else:
* Copy your newly build .zip file to your sdcard (you'll want to have a large enough sd card, I think)
* (if you want to) copy F4k's kernel and/or gapps too.
* Reboot your phone, go to recovery
* Backup your current phone. Seriously, never miss that step.
* Format /system (in Phil's Touch that's under "mounts and storage")
* Format /cache (as above)
* Select "install zip from sd card" and choose your ROM
* (if you want to) repeat "install zip from sd card" for F4k's kernel and/or gapps.
* Reboot your phone. It will take ~5 minutes or so for ART to re-compile all your apps
Soo my build didn't work. Wat do??
* Reboot to Recovery
* What I do is another backup. This gives me a nice archive containing my broken build, which I can later investigate
* Use recovery to restore the backup you've made before applying your build
* Reboot. You're back on a build that worked. Phew~
* (if you want to investigate) copy both backups (one that works and one that doesn't) to your PC. Uncompress the contents of /system for both, see if they obviously differ (such as one having binary blobs and one not lol).
Use F4k's kernel if you want to
Up to you, but here it is: https://s.basketbuild.com/devs/F4k/kernel_f4k-lp
I use it and as a result, I don't bother to optimise/improve CM12 kernel. I also don't care if I ever mis-compile CM12 kernel (not that it ever happens).
Gapps location
I use "mini" from here: https://s.basketbuild.com/devs/TKruzze/Android 5.0.1 GApps and all I can say is that it worked for me so far.
I made some changes and I forgot what I did
Command "repo status" will give you a list of all the files you've modified across all the git repositories.
I made some changes to a file and I forgot how it looked before
Go to that file's directory (or at least its git repository, but it's somewhat hard to figure out what is the repository structure in your workspace) and issue "git diff" command. It will produce a diff file with all your changes.
I made some changes to a file and I want to undo that
Go to that file's directory and issue "git checkout [filename]" command. It will drop your changes and replace the file with original.
My build finished and I want to make a new, fresh, one
You want to say "make clean" before you do "brunch serranoltexx" again.
Coming up: Basic JustArchi-inspired optimisations

Main article: http://forum.xda-developers.com/showthread.php?t=2754997
In the mid of 2014, @JustArchi recognised that all of Android has always been built with -Os option - meaning that the binaries are optimised for small size and not for execution speed. -Os is sometimes necessary (as it was on very early Android devices), but the "usual" build optimisation has always been -O2 meaning optimise for speed. Or -O3, which runs even more optimisations for speed (which might or might not help relative to O2 and will always make compilation slower).
Applying those optimisations has never been easier, because Lollipop is already built with GCC 4.8 (which was very highly recommended, but not in default toolchain, before). So all we need to do is activate -O3 by modifying some makefiles.
Does it do anything
In 0xbenchmark, several graphics-related tests (draw-arc, draw-circle) are up to six times faster. Does it matter? Dunno! But it's fun to see such a thing anyway!
What is THE most important file to modify?
Here: ~/android/system/build/core/combo/TARGET_linux-arm.mk
Line 70 defines "TARGET_arm_CFLAGS", this is the base compiler flags for *kernel* and starts with -O2. You can change that -O2 to -O3 if you want, but if you use F4k's kernel then it will do nothing in practice.
Line 77 defines TARGET_thumb_CFLAGS, this is the base compiler flags for android binaries. It clearly has -Os staring you in the face. Aha!! Change that to -O3 (or -O2) and you've just applied 90% of all compiler optimisations you can make. Build again. Your zip will be larger, this means it worked.
So I did that and it didn't finish building
Heh you're right, I lied. Unfortunately GCC is not as perfect as we'd wish and it will produce new errors or warnings with -O3 flag. Some of them make sense, some baffle me... Here's a list of what I had to change:
Error building android/system/frameworks//media/libstagefright/codecs/amrwbenc/src/isp_az.c, compiler detects array index out of bounds
It doesn't make any sense if you ask me (and I stared at the code a lot). There are two arrays f1 and f2. f1 has size [NC16k + 1] and f2 has size [NC16k], and if f1 is big enough then f2 should be big enough, but GCC disagrees.
For an off chance that GCC is right, I made f2 bigger [NC16k + 1]. Since nobody does sizeof(f2) it causes no change in logic, it marely allocates one extra (unused) word on stack. Made GCC happy.
[edit] this fix is unnecessary on gcc 4.8.5; see "Using SaberMod toolchain to build your CM12" on page 3 for how to use updated gcc[/edit]
Error building android/system/frameworks/av/media/libstagefright/codecs/m4v_h263/dec/src/deringing_[chroma|luma].cpp, cryptic "assuming when assuming" message
Another weird one. It *seems* to me that GCC unrolled a loop, and then looked at the unrolled loop index condition and concluded it's dumb after the unrolling, and complains. Modify:
android/system/frameworks/media/libstagefright/codecs/m4v_h263/dec/Android.mk
Find line: Local_CFLAGS += -Werror
Replace with: Local_CFLAGS += -Werror -Wno-error=strict-overflow
Error linking libhwcomposer, symbols "configRotator", "configMdp" and "updateSource" not found
Those three functions are defined with |inline| in the cpp files, while a compiler option tells gcc that inline implies static (dunno why it works with -Os, it really should never work). Open:
~/android/system/hardware/qcom/display-caf/msm8960/libhwcomposer/hwc_utils.cpp
Line 1238, remove "inline"
Line 1309, remove "inline"
Line 1335, remove "inline"
That is all, should build now!
Anything else uses -Os?
Yes, there's a bunch of Android.mk files that locally override the -O3 flag we just set with -Os (or -O2). You can make a global search, but here's a list of some important ones:
* every makefile under external/chromium_org/. This is the built-in web browser and unfortunately every single makefile does the override, and there's over9000 of them. If you want to change them all, you probably want to write a script of some sort. If you do, share one here lol.
* third_party/android_crazy_linker/src/Android.mk, adds -Os to LOCAL_CFLAGS. I do not know what crazy linker is, but if you want that to be bigger and faster, change that to -O3.
* third_party/zlib/zlib.target.linux-arm.mk, adds -Os to MY_CFLAGS_Release. Zlib sounds like something that should be fast, change that to -O3.
* modules/audio_processing/ lots of .mk files use -Os. How weird. You're only interested in *.target.linux-arm.mk, other targets do not apply to us.
* external/... some of the Android.mk files there use -Os. Some seem to matter.
Phew ~ next up: some more interesting optimisations that worked for me.

Compile for cortex-a15 target
The CPU in our S4mini is called Krait. It's neither Cortex-A9 nor Cortex-A15, but it's supposed to be similar to A15. However, the CM12 build system does not have an appropriate entry for Krait and defaults to generic A7+Neon, a choice that is not VERY bad but presumably not optimal either.
Go to file: ~/android/system/build/core/combo/arch/arm/armv7-a-neon.mk
Find the line that detects a15-compatible architectures (cortex-a15 and denver):
ifneq (,$(filter cortex-a15 denver,$(TARGET_$(combo_2nd_arch_prefix)CPU_VARIANT)))
add krait to the list:
ifneq (,$(filter krait cortex-a15 denver,$(TARGET_$(combo_2nd_arch_prefix)CPU_VARIANT)))
Activate neon vector extensions
[edit] see "Activate neon vector extensions, for real this time" on page 3 for a working, but hacky, solution[/edit]
Activate linker optimisations
In the in file: build/core/combo/select.mk there's room for some linker parameters.
Find the line that says:
$(combo_var_prefix)GLOBAL_LDFLAGS :=
and change it to:
$(combo_var_prefix)GLOBAL_LDFLAGS := -Wl,-O1
(that's: dash whiskey lima comma dash oscar one, no spaces, in case it's not readable)
I do not know what kind of optimisations linker makes, but this parameter asks it to make them.

Thanks a lot for this helpful and informative how-to. This is really appreciated if one likes to build the rom on his own.
Regards!

where can i download YOUR build of cm12?

well done!

This is a great write up. Anybody contributing for necessary mods required for duos will value add

I'm glad you guys like it I'll post some more tomorrow.
Howdareme said:
where can i download YOUR build of cm12?
Click to expand...
Click to collapse
Mine? I don't upload them anywhere because I don't see much point, making a near-identical copy of F4k's rom. Plus I am very lazy ;ppp
Now, to say something useful: if you're building any time soon, you might want to include this patch: http://review.cyanogenmod.org/#/c/82572/
It seems like there's a serious resource leak any time you switch your screen off.

Thanks for sharing this wonderful information!
sysKin said:
* Go to https://github.com/TheMuppets/proprietary_vendor_samsung
* Switch branch to cm-12.0
* Use the "Download ZIP" button to get the copy of the entire thing.
Click to expand...
Click to collapse
You might wanna consider adding that repo to a local manifest instead. See also @k2wls excellent guide: How to make your own CM-11.0 for your S4 mini

you can save the 500mb download by just adding this to .repo/local_manifests/roomservice.xml
Code:
<project name="TheMuppets/proprietary_vendor_samsung" path="vendor/samsung" remote="github" />
although perhaps we should be using arco's repo instead of the muppets?
https://github.com/arco/proprietary_vendor_samsung
also we should make a list of recommend patches from gerrit.
arco doesn't seem to be doing anything s4mini-specific at the moment, tonnes of work on bluetooth it seems:
http://review.cyanogenmod.org/#/q/owner:"Arne+Coucheron"+branch:"cm-12.0",n,z

sej7278 said:
you can save the 500mb download by just adding this to .repo/local_manifests/roomservice.xml
Code:
<project name="TheMuppets/proprietary_vendor_samsung" path="vendor/samsung" remote="github" />
although perhaps we should be using arco's repo instead of the muppets?
https://github.com/arco/proprietary_vendor_samsung
Click to expand...
Click to collapse
Wooo thanks, this is exactly the kind of knowledge I'm hoping we can put in one place, and I'm a noob when it comes to android build system (and |repo| script).
also we should make a list of recommend patches from gerrit.
Click to expand...
Click to collapse
Yup!

sysKin said:
Wooo thanks, this is exactly the kind of knowledge I'm hoping we can put in one place, and I'm a noob when it comes to android build system (and |repo| script).
Click to expand...
Click to collapse
well it won't actually save you a 500mb download, it'll just download it using repo, but at least it'll keep it up-to-date this way (as i recall there is a way to just checkout the directories you want, but i can't remember it, think you have to list every directory you don't want and remove it).
you can also add revision="cm-12.0" to the end of the tag, but cm-12.0 is the default now anyway.
i'd say USE_CCACHE=1 is worth doing, unless you're making major changes for every build, it defaults to only using 1Gb these days.
also if like me you've already checked out the cm-11.0 branch, you can switch to cm12 using:
Code:
repo init -b cm-12.0
repo sync -j16

built ok after a second repo sync (think i was in the middle of a merge window) and it turns out you don't need to get the prebuilts anymore, the terminal app is part of the source now.
oh and the screen off memory leak patch has been merged now.
it did take my 3.2ghz core-i5 with ccache on an ssd and 12gb ram about 2.5 hours to build, so a lot longer than cm7/9/10 (30-45mins) and a bit longer than cm11 (1.5-2 hours)
edit: actually a warm ccache only saved 5-10mins it seems, much more java than c/c++ in android these days i guess.

stop "settings > device > buttons" from crashing: http://review.cyanogenmod.org/#/c/83030/ (merged)
still looking for how to:
1. enable editting quick settings tiles
2. unmount usb mass storage,
3. take a screenshot from reboot menu / edit the reboot menu
4. edit the lockscreen settings

For those of us suffering from network-derived timezone resetting to GMT+0 (not a fun thing to happen overnight when you need your alarm clock!), there is this possible solution:
http://review.cyanogenmod.org/#/c/83219/

Love this thread.......
Thanks @sysKin., have you try diffrenent toolchain ?

happyta5 said:
have you try diffrenent toolchain ?
Click to expand...
Click to collapse
Not yet, not on this build. I did use a different toolchain when I compiled CM 10.2 but without any knowledge about how repo works it was just one huge mess. Many guides here only deepened my misunderstandings by showing me how to replace kernel toolchain (ie what builds the kernel) saying nothing about rest-of-android toolchain (and I don't even remember some details of that anymore...).
Also, I never managed to successfully compile CM 10.2 with contemporary GCC 4.9 - too many weird internal compiler errors and other strangeness. Do you have any information about successes with current tools? There wouldn't be much point using different toolchains if GCC/clang/etc remain the same (well, GCC 4.8.4 was released on 19th of December, might be worth trying).

With some pointers from this thread, I'm able to build CM12 using ArchiDroid linaro 4.8 and 4.9 ToolChain with -O3 Optimized. CM seems run faster. I'm using @F4k kernel for the moment since I like the undervolt alot. May be I'll try SaberMod ToolChain later .....
Cheers ...

happyta5 said:
With some pointers from this thread, I'm able to build CM12 using ArchiDroid linaro 4.8 and 4.9 ToolChain with -O3 Optimized. CM seems run faster.
Click to expand...
Click to collapse
Could you share more about what you did? In particular, did you change the "android-eabi" toolchain or the "arm-eabi" toolchain?
The only instructions I've seen which explain how to use linaro toolchain refer to the "android-eabi" one, and if my understanding is correct, that's used only for building the kernel...

Related

[TOOL] guestekrnL doItYourself STOCK KERNEL BUILDER for dummies - MAKE UR OWN KERNEL!

Ohai, everypwny!​Wanna impress your girlfriend without spending any money? Show her your love through compiling her your own O2X stock kernel! ​
Requirements: A PC capable of running a virtual Linux machine -- if your PC isn't much older than 5-6 years there shouldn't be a problem. Just make sure you have enough RAM (at least 1,5 - 2 GB recommended) -- no programming - or special linux knowledge required!
## Info: The VMWare image has been created by Jonas Hendrickx for XDA (I just altered/modified it for my needs).
5 simple steps to success: -- EVERYONE can do that!
Download and install Vmware Player (Freeware): http://www.vmware.com/go/get-player (VirtualBox will work too if you like this app better)
Download the file "guestekrnL_doItYourself_developer.rar" (http://guendhoer.com:9000/guestekrnL_doItYourself_developer.rar or https://docs.google.com/open?id=0B5HJ_FpcC9ymM3ZCS0l5RFJtZnc , 1.5GB) and unpack it (using WinRar or 7Zip or...) to any folder of your choice, and afterwards double-click the file "Android Developer.vmx" -- or alternatively open VMware Player first and then import the virtual machine located in the unpacked .rar contents
Click "I copied it" and wait until virtual machine starts up, login with password "root"
Open folder "kernel_source" (on Desktop), double-click file "buildkernel" and click "run in terminal"
Wait until terminal window closes, and start using your new kernel located in folder Desktop/kernel_source/guestekrnL_BUILDS
After this an exact copy of current guestekrnL "SR99R100.1PI.1337-GoodBye" has been built and packaged to a flashable CWM-Zip.
Possible things you can easily change yourself for making your own different/improved kernel versions:
Use a different compilation toolchain
(p.ex. http://releases.linaro.org/<choose a release version>/components/android/toolchain/<choose a gcc version>/)
download the file "android-toolchain-eabi-linaro-..." and replace the folder "android-toolchain-eabi" on Desktop of virtual machine with the unpacked content of the downloaded file
There are many different builds of linaro toolchains available, resulting in different smoothness, battery life and stability of the built kernel. Important:
[*]After toolchain change you have to edit the file "buildkernel" (rightclick -> open with gedit) and change the gcc version number to the one of your new toolchain (you find it here: Desktop/android-toolchain-eabi/lib/gcc/arm-eabi/<gcc version number>), save the file afterwards
Attention: if you switch to a toolchain newer than september 2011, you MUST change
# CONFIG_ALLOW_CPU_ALIGNMENT is not set
Click to expand...
Click to collapse
to
CONFIG_ALLOW_CPU_ALIGNMENT=y
Click to expand...
Click to collapse
in file Desktop/kernel_source/arch/arm/configs/gueste_defconfig -- otherwise kernel won't boot!
Only use toolchains with a number up to "4.6" in name, the newer ones ("4.7") are for ICS and not Gingerbread!
NOT every new toolchain will work with O2X stock kernels -> p.ex. 4.6.4 might not work while 4.6.2 works. Every toolchain older or equal to september 2011 should work BUT maybe you will have to remove some of the build flags not recognized by the older chain.
Always check Desktop/kernel_source/guestekrnL_BUILDS/build.log for errors after you made a new kernel build, especially at the bottom of the file. (Warnings don't matter.)
Use a different version-name for the built kernel
right-click file "buildkernel" in kernel_source folder -> open with gedit -> change kernelVersion there
Use a different general name for the built kernel (other than "guestekrnL")
double-click file "Makefile" in kernel_source folder -> click "Display" -> change kernel name there (change ".9-guestekrnL" to ".9-<yourKernelName>")
Attention: the Android app GuesteOC won't work if it doesn't find the String "guestekrnL" in kernel name! You then have to use the function-reduced version of the OC app by TrymHansen available for all kernels!
Use different build optimization flags
double-click file "Makefile" in kernel_source folder -> click "Display" -> search "CFLAGS_GUESTE" -> edit the build flags there
you find a good overview + explainations of available build flags here http://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/Optimize-Options.html
and an interesting article on which flags the toolchain guys use here: http://www.linaro.org/linaro-blog/2...aro-android-2011-10-and-future-optimizations/
it is completely up to YOU which flags to use and not to use!
Stock standard would be:
CFLAGS_GUESTE = -O2
Click to expand...
Click to collapse
while the flags of current guestekrnL are:
CFLAGS_GUESTE = -O3 -ffast-math \
-mtune=cortex-a9 -march=armv7-a \
-mfloat-abi=softfp -mfpu=vfpv3-d16 \
-fsingle-precision-constant -fgraphite-identity \
-ftree-loop-distribution -ftree-loop-linear \
-floop-interchange -floop-strip-mine -floop-block \
-fmodulo-sched -fmodulo-sched-allow-regmoves \
-fno-inline-functions
Click to expand...
Click to collapse
if you have many flags like above, make line-breaks using slashes like above and only put 2-3 flags in one line!
Use different basic kernel configuration values
open folder "kernel_source", click the search-icon, search for "gueste"
edit the 2 files "guestekrnl.c" and "guestekrnl.h" of the result set according to your needs
guestekrnl.c and guestekrnl.h contain many default voltage/speed/... values, you can change them easily there
if you change MAX_OVERCLOCK to a higher value, you might need to change MAX_VOLTAGE as well and have to alter the whole cpu voltage and frequency table (see next point)
Help & explainations here: http://forum.xda-developers.com/showpost.php?p=26696158&postcount=25
Change CPU scaling voltages and speed steps
Edit the file Desktop/kernel_source/arch/arm/mach-tegra/nvrm/core/common/nvrm_clocks_limits.c and alter the two arrays "FakeShmooVoltages[]" and "FakepScaledCpuLimits"
the difference from one voltage step to another one needs to be lower or equal than 100mV;; too low voltages for a step results in freezes !!
the values for MAX_VOLTAGE and MAX_OVERCLOCK are located in file guestekrnL.h!
Help & explainations here: http://forum.xda-developers.com/showpost.php?p=26696158&postcount=25
Example of creating a kernel overclockable to 1.5 GHz: http://forum.xda-developers.com/showpost.php?p=26759653&postcount=58
Enable/Disable kernel features you want to use or don't want to use
open folder "kernel_source", click the search-icon, search for "gueste", edit the file "gueste_defconfig" according to your needs
"<featureName>=y" means the feature is enabled
"#<featureName> is not set" means the feature is disabled
Google for more information about what the different kernel features do, just past the kernel feature name in Google and you will find a description for most of them
Change the text shown to user on CWM installation of kernel
Edit the file Desktop/kernel_source/zipstructure/META-INF/com/google/android/updater-script according to your needs
If you are completely bad-ass you can also compile the compilation toolchain from the official sources yourself instead of using a prebuilt one (even if the prebuilt ones tend to be much more stable than the self-compiled ones)
Useful & important additional tipps/hints: Check this out
Info: If you ever stop the compilation progress before finishing, you have to edit the file "Makefile" in kernel folder and remove the version number from the version string (so only .9-guestekrnL should remain), otherwise you will have double version number in next kernel build.
Start being a kernel developer for XDA right now, today!
Advantages:
- U can impress many users by presenting them your hard work
- You will be acknowledged
- You will be able to easily express your creativity to the world wide web
- And much much more ,,, Sign up today! Oh, wait, no signup needed
If you think you have created an extremely good version of guestekrnL or maybe a completely new kernel, think about posting it here in the thread (I will link the posted kernels here in first posting) or open your own thread for your new kernel, it is up to you
As always I'm not responsible for any harm you might do to your system
Wanna build other stock sources than the ones of guestekrnL? Check this out
Awesome, Stefan!
Downloading...
Yeehhaawwwww!!! This is what im searching for.. thank you very very very much..
Edit: You need to edit your post.. looks unorganized.. quite difficult to read..
Sent from my LG-P990 using XDA
ghadap said:
Yeehhaawwwww!!! This is what im searching for.. thank you very very very much..
Edit: You need to edit your post.. looks unorganized.. quite difficult to read..
Sent from my LG-P990 using XDA
Click to expand...
Click to collapse
Thx I restructured a bit
Great work!
sent from my wii remote
You are great, thx!!!
Hy Stefan,
thx a lot
Herzlichen Dank
Craxx
Direct download Link from my own FTP server coming soon, because some users might have problems with download of the 1.5GB .rar from current mirror
Stefan Gündhör said:
Ohai, everypwny!​Wanna impress your girlfriend without spending money? Show her your love through compiling her your own O2X stock kernel! ​
Click to expand...
Click to collapse
LOL..! I can't think of any more evil scheme that this . Great work, Stefan..!
OH, on afterthoughts, a better thing that serves the purpose would be "How to build a theme..."
Yes Stefan, i have tried 3 times and download stops after around 300 MB, so i wait for direct download link
This is so awesome! Thanks alot!
Sent from my LG-P990 using Tapatalk
Great initiative Stefan. Download stops at ~300MB for me as well, looking forward to trying it.
Are the guestekrnl-scripts included in the finished kernel installer? (Just wondering if GuesteOC will work out of the box.)
TrymHansen said:
Great initiative Stefan. Download stops at ~300MB for me as well, looking forward to trying it.
Are the guestekrnl-scripts included in the finished kernel installer? (Just wondering if GuesteOC will work out of the box.)
Click to expand...
Click to collapse
Yeah I'm just uploading to a new FTP mirror, will take about 2 more hours I guess!
And yeah, the exact zipstructure of current guestekrnL release will be built automatically, including GuesteOC v2.1.5 + Myrt UV GUI, all working out of the box!
(In fact the most actual guestekrnL release was built exactly the way I describe it in first posting: I ran the virtual machine and double-clicked/ran the buildkernel-script. That's it.)
great tutorial Stefan...made it look very simple....NOTHING IS IMPOSSIBLE IN THIS WORLD..I am going to try doing it myself Stefan...as they say...the modern world is a place where a butcher can become a goldsmith, a carpenter can be a captain of the ship and a cleaner can be a pilot....
Thanks for the make urself tool kit mate.I am sure that we will find a lot of Kernels floating in this forum....
just a matter how many are good like urs or temaseks or vadonkas or so many others....time will tell that...have to wait to see that.
I appreciate the hard work put by you to make it so simple for starters and noobs morons like me to understand.
THANKS THANKS THANKS a million.I really mean it truthfully my friend
Stefan, will your tutorial works with original source (eg, V20q) and others (eg, spica HP)? and which file/folder to make our kernel support ext4?
My idea was using stock kernel but add ext4..
Downloading with FF stopped at 500MB, but with Free Download Manager, I could download it without problems.
The sources are very cool. Playing a bit around with them...
ghadap said:
Stefan, will your tutorial works with original source (eg, V20q) and others (eg, spica HP)? and which file/folder to make our kernel support ext4?
My idea was using stock kernel but add ext4..
Click to expand...
Click to collapse
Example of building unchanged stock kernel and only add ext4 compatibility:
start the kernelBuilder,
delete all folders located in Desktop/kernel_source except the folders "guestekrnl_BUILDS" and "zipstructure"
delete all files located in Desktop/kernel_source except the file "buildkernel"
edit the file "buildkernel" (rightClick-> open with gEdit) and change line
make ARCH=arm gueste${1}_defconfig;
Click to expand...
Click to collapse
to
make ARCH=arm star_ifx${1}_defconfig;
Click to expand...
Click to collapse
if you use v20 sources or to
make ARCH=arm star_rev_f_android${1}_defconfig;
Click to expand...
Click to collapse
if you use v10 sources
Download the official kernel sources you want from http://www.lg.com/global/support/opensource/opensource-detail.jsp?detailCustomerModelCode=LGP990
Extract the sources until you get a folder kalled "kernel"
copy the contents from inside "kernel" folder to Desktop/kernel_source
edit file Desktop/kernel_source/drivers/net/wireless/bcm4329/Makefile -> change line
-Wall -Wstrict-prototypes -Werror \
Click to expand...
Click to collapse
to
-Wall -Wstrict-prototypes \
Click to expand...
Click to collapse
edit file Desktop/kernel_source/arch/arm/configs/star_ifx_defconfig (or star_rev_f_android_defconfig): enable ext4 through replacing ext4 config (search for it in the file) with following:
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_XATTR=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
Click to expand...
Click to collapse
run the buildkernel script, kernel will be built
Attention: don't use linaro/gcc toolchain newer than september 2011, otherwise kernel won't boot without additional modifications (the included default toolchain will work fine)
For every other stock kernel sources (in order to compile & zip-package them using kernelBuilder) the procedure should work similar!
Spica horsepower kernel however won't work that way, because spica does not upload his defconfig to his sources @GitHub (thus making rebuilding more difficult).
And default defconfig of stock kernel won't work with spica kernel. (Without the right defconfig the kernel does not boot.)
Older spica kernels (older than SR3) completely won't work and can't be rebuilt because spica never offered full sources @GitHub until SR3.
So in order to get a current spica kernel source working, you have to additionally
install the kernel you want to rebuild first on your phone and then
copy the file /proc/config.gz first to your internal SD and then to your PC,
unpack it and then rename the file you get to "spica_defconfig" and
place it in Desktop/kernel_source/arch/arm/configs/
finally edit the buildkernel file again so you have
make ARCH=arm spica${1}_defconfig;
Click to expand...
Click to collapse
in there!
In order to see the differences of guestekrnL compared to stock kernel, Download Meld Diff Viewer in App Store of virtual linux machine and make a folder-comparison of folder Desktop/kernel_source and a folder where you keep unchanged v10E kernel sources!
New direct download mirrors online! (Thx to cojo & myself ) Please report if the .rar files are error-free thx!
Additional tipps/hints:
change your keyboard layout to the one of your language/country (right-click top right most left icon and choose "change keyboard layout")
use versioning! :
double-click "Terminal" on desktop
enter "sudo apt-get install git-core git-gui" (internet connection is required)
enter the password ("root") , confirm installation, after install exit the window
enter "cd Desktop/kernel_source"
enter "git init"
enter "git add ./"
enter "git commit -a" then enter "first commit" & save & exit (the keyboard combinations for this are shown)
enter "git gui" and in first menu click "visualize master's history" -> you will see all commits and changes you made in each commit there
everytime you have made a few changes to the kernel, run "git commit -a" again (and if you add new file git add ./), so a new commit will be added to the commit history and you can see all changes there
use a diff viewer (Meld Diff Viewer of virtual machine linux software repository) for comparing guestekrnL sources with unchanged v10E stock kernel sources, so you can understand custom kernel making better! -- you can find orig sources here http://www.lg.com/global/support/opensource/opensource-detail.jsp?detailCustomerModelCode=LGP990 , download the v10E archive and unpack until you get a folder called "kernel", make a folder-comparison with Meld Diff Viewer afterwards!
Just take your time, begin with only compiling the kernel without changes (and try if it boots) and then slowly change more and more stuff, don't change too many things at once, always compile&try the kernel between more changes.
Learn by viewing the commits other developers make for their kernels, but pay attention that some commits might not be complete or incompatible with your kernel! Some commits of CM7 kernels can be useful, but not all will be compatible. When I started I learned much by just reading the commits of ironkrnL, from this commit page upwards: https://github.com/SetiroN/lge-kernel-star/commits/v2?page=5 (only the things "SetIron" directly commited) -- Please note that my own git repo is a mess, as I don't split up changes to single commits, I just make a commit for all changes a new kernel version has, so my repo won't help u much in learning
Always check Desktop/kernel_source/guestekrnL_BUILDS/build.log for errors after you made a new kernel build, especially at the bottom of the file. (Warnings don't matter.)
Stefan Gündhör said:
New direct download mirrors online! (Thx to cojo & myself ) Please report if the .rar files are error-free thx!
Click to expand...
Click to collapse
Downloaded from Google Docs and unpacked without incident. Now compiling under VirtualBox, which also worked without any modification.
...and as I was writing this it finished. Whole compilation job took less than 2 mins on a 4-core VM. ;-)

[ROM][KANG³][CM9][UNOFFICIAL] Linaro Optimized Droid Incredible CM9 ROM

Because the CyanogenMod developers decided not to switch to the Linaro toolchain, I decided that I would do it myself. This ROM is very similar to invisiblek's nightlies, but has a few more patches from the CyanogenMod queue applied and other changes made to enable building with GCC 4.7 and -O3. I will try to put up a new build at least once every few days if there is much being merged into the CM9 tree.
The main benefit of using the Linaro optimized ROM is that the UI is faster and snappier. Some applications (especially heavy ones like Google Play) are noticeably less laggy. Also, you get higher benchmark scores. (Yay!)
My kernel is included as the stock kernel in this ROM.
As always, if you are in any doubt whatsoever, you should do a Nandroid backup before flashing this ROM.
Changelog:
8/15/2012
No changes from me; just updates from the CM repo
8/12/2012
Revert the patch increasing the number of cached app pages, as this used more memory and made the launcher homescreens lag
8/10/2012
No changes from me; just updates from the CM repo
8/7/2012
Remove the ext4 sdcard patch because it was causing multiple regressions in handling the sdcard, even though it was still fat32
8/6/2012
Apply patch (http://review.cyanogenmod.com/#/c/20061/) to remove videos intended only for the tuna device
Attempt to workaround the lag issues by making the browser kill itself when the last tab is closed
8/3/2012
Apply patch (http://review.cyanogenmod.com/#/c/20654/) to enable HTTPS Google searches in the stock browser for better privacy
Apply patch (http://review.cyanogenmod.com/#/c/19807/) to allow mounting ext4 sdcards
7/31/2012
Update to the Linaro 2012.7 toolchain
Compile the kernel with "-O3 -fno-tree-vectorization"
7/22/2012
Add TCP MSS iptables filter to the kernel as it seems to be used during tethering
Add the Linaro string processing optimizations to the ROM
7/21/2012
Include my "Lite" kernel with the ROM
Update to a new, unreleased-as-of-yet version of my kernel with more optimizations
7/16/2012
Disable WebGL again. It was causing hardlocks on a number of enabled sites
Apply patch (http://review.cyanogenmod.com/#/c/18490/) to allow for the downloading of "unsafe" attachment files in Email
7/10/2012
Apply patch (http://review.cyanogenmod.com/#/c/18319/) to speed up some app starts
Apply patch (http://review.cyanogenmod.com/#/c/17552/) to add more NEON optimizations to pixelflinger
Enable WebGL
7/8/2012
Apply Evan McClain's libskia update (fixes the blacked-out JPEG issue)
Fix some media players like MX Player (an instruction was missing because it was optimized out by O3)
Apply more optimization flags
6/27/2012
Initial release
Apply CM9 patches to fix compile failures with GCC 4.7 and enable O3 optimizations
Switch to libjpeg-turbo
Disable scrolling cache (increases scrolling smoothness for non-hardware-accelerated listviews)
Issues (specific to the Linaro optimized version):
Turning off Bluetooth causes the Phone app to crash. It restarts immediately, so there are no long-term effects.
Bluetooth file transfer (OPP) does not work. The Linaro team experiences this bug too and is currently looking for a solution. I will update as soon as a solution is found.
You can download the source I use to compile this ROM by following these instructions: https://github.com/invisiblek/android_device_htc_inc/blob/ics/README.md
Compiling Instructions:
These compiling instructions are for Linux. They should work on any distro, but I am using the latest release of (K)ubuntu.
Follow all of the instructions from the source link above except for the last one. This will download the source tree and get you set up to build.
Assuming you are already in the root directory of your source tree ("~/cm9" if you followed the above instructions), run the following commands in the terminal. Some of the git pulls will display a text editor screen. When you get this, just press Ctrl-O, Enter, and finally Ctrl-X.
Code:
cd external/skia
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_skia refs/changes/85/14585/1
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_skia refs/changes/86/14586/1
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_skia refs/changes/87/14587/1
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_skia refs/changes/88/14588/1
git commit -a
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_skia refs/changes/89/14589/1
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_skia refs/changes/10/15810/1
cd ../webkit
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_webkit refs/changes/90/14590/1
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_webkit refs/changes/91/14591/1
cd ../../frameworks/base
git pull http://review.cyanogenmod.com/CyanogenMod/android_frameworks_base refs/changes/92/14592/1
git pull http://review.cyanogenmod.com/CyanogenMod/android_frameworks_base refs/changes/80/17380/2
cd ../../external/freetype
git pull http://review.cyanogenmod.com/CyanogenMod/android_external_freetype refs/changes/54/12654/2
cd ../../build
git pull http://review.cyanogenmod.com/CyanogenMod/android_build refs/changes/58/17358/4
Follow the instructions here to replace your libjpeg with libjpeg-turbo.
Open the file ~/cm9/frameworks/base/core/java/android/widget/AbsListView.java in your favorite text editor. Go to line 753 and change it to read "setScrollingCacheEnabled(false);".
Open the file ~/cm9/bionic/libc/arch-arm/bionic/libgcc_compat.c in your favorite text editor. Go to line 114 and insert two new lines reading "XX(__aeabi_llsl) \" and "XX(__aeabi_llsr) \" below it.
Open the file ~/cm9/build/core/config.mk in your favorite text editor. Go to line 91 and change it to read "COMMON_GLOBAL_CFLAGS:= -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Wno-error=strict-aliasing -Wno-error=enum-compare". Go to line 312 and change it to read "TARGET_GLOBAL_CFLAGS += $(COMMON_GLOBAL_CFLAGS) -march=armv7-a -mcpu=cortex-a8 -mtune=cortex-a8". Go to line 315 and change it to read "TARGET_GLOBAL_CPPFLAGS += $(COMMON_GLOBAL_CPPFLAGS) -march=armv7-a -mcpu=cortex-a8 -mtune=cortex-a8".
Open the file ~/cm9/build/core/combo/TARGET_linux-arm.mk in your favorite text editor. Go to line 47 and change it to read "prebuilt/$(HOST_PREBUILT_TAG)/toolchain/linaro-4.7.1/bin/arm-linux-androideabi-". Go to line 149 and change it to read "TARGET_GLOBAL_CPPFLAGS += -fvisibility-inlines-hidden".
Download this file and unzip it to ~/cm9/prebuilt/linux-x86/toolchain/linaro-4.7.1
You are finally ready to build! Open a terminal to the ~/cm9 directory, then run ". build/envsetup.sh" and "brunch inc". This will take a long time.
Great, going to try this out. Maybe the keyboard works better, I've shut down pop up and prediction.
Still lags horribly.
Edit: Is gapps included or do I need to flash them?
Edit: Wow.. Maybe some won't notice it, but I've seen an increase of speed and snapiness. Keyboard lag seems to have stopped somewhat.. its still there but its along better.
Sent from my ADR6300 using Tapatalk 2
withbloodskies said:
Great, going to try this out. Maybe the keyboard works better, I've shut down pop up and prediction.
Still lags horribly.
Edit: Is gapps included or do I need to flash them?
Edit: Wow.. Maybe some won't notice it, but I've seen an increase of speed and snapiness. Keyboard lag seems to have stopped somewhat.. its still there but its along better.
Sent from my ADR6300 using Tapatalk 2
Click to expand...
Click to collapse
You still need to flash Gapps. It would be illegal for me to include them.
The best workaround I have found for keyboard lag is to disable spellchecking. You still get autocorrect like in GB; it just doesn't put a red squiggly under misspelled words.
Good work, I'll have to try it out. Any chance you putting this up on goo.im and/or ROM Manager, to expedite the update process?
Very nice work,Thanks for your contribution .
PonsAsinorem said:
Good work, I'll have to try it out. Any chance you putting this up on goo.im and/or ROM Manager, to expedite the update process?
Click to expand...
Click to collapse
I will look at putting it on goo.im.
One last suggestion (for now) before I'm off to flash it: thought of changing the ROM and zip name just slightly so it's not confused with invisiblek? Maybe throw a linaro in there somewhere or something? Right now, they have the same names (and dates, too, shortly) with just the compile times and machines being different. Now off to flash.
PonsAsinorem said:
One last suggestion (for now) before I'm off to flash it: thought of changing the ROM and zip name just slightly so it's not confused with invisiblek? Maybe throw a linaro in there somewhere or something? Right now, they have the same names (and dates, too, shortly) with just the compile times and machines being different. Now off to flash.
Click to expand...
Click to collapse
I'm not quite sure how to do that. Can you tell me?
mamarley said:
I'm not quite sure how to do that. Can you tell me?
Click to expand...
Click to collapse
You'll have to do some tweaking to the bottom of this file. Hard to explain on the phone. As part of my compile script I wrote for my kangs, it sed/replaced the necessary lines with pons (I'd use linaro for yours). Experiment with it till it looks how you want it to. Any questions, let me know.
https://github.com/CyanogenMod/android_vendor_cm
mamarley said:
You still need to flash Gapps. It would be illegal for me to include them.
The best workaround I have found for keyboard lag is to disable spellchecking. You still get autocorrect like in GB; it just doesn't put a red squiggly under misspelled words.
Click to expand...
Click to collapse
I wanted to point out that I got keyboard lag on ICS even on my gnex. There's not much that can be done. I never did try disabling spell checker. Liquid 1.5 helped with its linaro optimizations but what helped more to me was the interactive governor I was using had input boost which boosts frequency upon using the touchscreen to minimize lag rather than wait for it to ramp up. The other part nay have been the go_high setting of 50% load. I'm not using all the technical terms but to high-speed frequency is user configurable and its the speed it will jump to at a specified load. It may exist in our current interactive governor.
I do know that there is no keyboard lag in jelly bean that I can tell.
Sent from my Galaxy Nexus using Tapatalk 2
tiny4579 said:
I do know that there is no keyboard lag in jelly bean that I can tell.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Its all that butter
Anyway I used DPI and it works but it makes alot of apps force close. I was on 175, the same thing happens on Evervolv's Roms too.
Sent from my ADR6300 using Tapatalk 2
Can i flash this over invisiblek's Cm9 nightlies?
Or do i have to do a full wipe?
I have all my apps and everything just the way i want it.. I really dont wanna wipe.
Gorilla* said:
Can i flash this over invisiblek's Cm9 nightlies?
Or do i have to do a full wipe?
I have all my apps and everything just the way i want it.. I really dont wanna wipe.
Click to expand...
Click to collapse
You can flash over.
I have been flashing over since the CM7 days and have never had any problems. I even flashed the CM9 ROM right on top of the CM7 ROM and only had to clear the data for 2 apps to get everything working again.
Marley, Im booting up now, I flashed it, flashed your Lite Kernel, and USB fast charge zip.
Heres to hoping for some sexy Linaro Goodness!
Ill report back to how this runs.
Gorilla* said:
Marley, Im booting up now, I flashed it, flashed your Lite Kernel, and USB fast charge zip.
Heres to hoping for some sexy Linaro Goodness!
Ill report back to how this runs.
Click to expand...
Click to collapse
Same here. Just booted up. This is legit. Snappier than the CM9 nightlies so far. I didn't flash the USB zip- what will that give me?
statusqu0 said:
Same here. Just booted up. This is legit. Snappier than the CM9 nightlies so far. I didn't flash the USB zip- what will that give me?
Click to expand...
Click to collapse
That enables USB Fast Charge. It will make your phone charge much faster when it is plugged into a PC or some third-party wall/car chargers.
mamarley said:
That enables USB Fast Charge. It will make your phone charge much faster when it is plugged into a PC or some third-party wall/car chargers.
Click to expand...
Click to collapse
Forgive my noob-ness, but will that damage the battery in any way?
statusqu0 said:
Forgive my noob-ness, but will that damage the battery in any way?
Click to expand...
Click to collapse
No, it just makes it charge in the same way it would if you plugged it into the stock wall charger.
seems good so far. a couple slow-downs at first but seem to have gone away.
Yea, seems snappier than the other cm9 rom..
Im just hoping i dont get phantom touchscreen issues.. like the screen typing for me,.

[HOWTO] Building from sources [Kernel only for now]

Hello everyone.
This guide will help you in building a kernel from source for your Nexus 4
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.
Nexus 4 : https://android.googlesource.com/kernel/msm
Github Mirror: https://github.com/android/kernel_msm
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 4, we get the msm kernel sources.
Code:
git clone [url]https://android.googlesource.com/kernel/msm[/url]
Next, we change our directory to the newly fetched source.
Type
Code:
cd msm
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
Next, type the below in the kernel tree
Code:
git checkout <commit>
The commit of the version running of the current review units is 7a47627, which is same as branch android-msm-mako-3.4-jb-mr1-fr .
Compiling:
Name of defconfig: mako_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.
1) what is the branch "android-msm-mako-3.4-jb-mr1-fr" for?
2) what does mr1 mean? sounds like milestone/alpha/beta. Maybe it's not final? Last commit is 2 weeks ago.
3) great guide
m11kkaa said:
1) what is the branch "android-msm-mako-3.4-jb-mr1-fr" for?
2) what does mr1 mean? sounds like milestone/alpha/beta. Maybe it's not final? Last commit is 2 weeks ago.
3) great guide
Click to expand...
Click to collapse
mr1 could stand for "Milestone Release 1", it might not be final.
That being said, you should never checkout a branch directly for compiling a kernel, but the commit directly.
cdesai said:
...You need a toolchain to build the kernel. The preferred one is Google’s toolchain, the same they use to build AOSP.
Click to expand...
Click to collapse
Could you also use linaro to compile the kernel? I believe it's a toolchain anyway, but I'm not too sure on it's benefits or compatibility...
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
randomblame said:
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
Click to expand...
Click to collapse
Are you planning on developing for the N4?
Loved your work on the DHD
espionage724 said:
Could you also use linaro to compile the kernel? I believe it's a toolchain anyway, but I'm not too sure on it's benefits or compatibility...
Click to expand...
Click to collapse
Linaro isn't a toolchain, but they do make toolchains.
Yes, you can use it to compile the kernel, though it may not compile at all with it, or not work well - your mileage may vary.
randomblame said:
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
Click to expand...
Click to collapse
Nope, LZO compression is enabled by default
cdesai said:
Linaro isn't a toolchain, but they do make toolchains.
Yes, you can use it to compile the kernel, though it may not compile at all with it, or not work well - your mileage may vary.
Click to expand...
Click to collapse
Linaro has proven to increase android performance up 30 - 100% not sure if that is with -O3 optimizations or not. That is all I use on my kernels
Sucks this phone is not coming to Sprint, might be time to change carriers...
randomblame said:
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
Click to expand...
Click to collapse
-mvectorize-with-neon-quad ---> I use this in my makefile for cflags and drops the zImage size from 5.0mb to 4.4mb.
cdesai said:
Linaro isn't a toolchain, but they do make toolchains.
Yes, you can use it to compile the kernel, though it may not compile at all with it, or not work well - your mileage may vary.
Nope, LZO compression is enabled by default
Click to expand...
Click to collapse
ah I didn't see it - 6+mb still pretty big from what I'm used to at least
I'm going through the mind numbing process of bringing in mainline patches and squashing them all together. I'm up to 3.4.1 ... woot where's the hang me emoticon lol
*finally got smart and cloned mainline and reset the head back to each sublevel and merged into my local n4 source
got it all the way up to date with mainline 3.4.18
Thanks cdesai. I didn't think anything was out yet!!
randomblame said:
ah I didn't see it - 6+mb still pretty big from what I'm used to at least
I'm going through the mind numbing process of bringing in mainline patches and squashing them all together. I'm up to 3.4.1 ... woot where's the hang me emoticon lol
*finally got smart and cloned mainline and reset the head back to each sublevel and merged into my local n4 source
got it all the way up to date with mainline 3.4.18
Click to expand...
Click to collapse
Yea, it's big, but partitions on new devices are big as well.
y u no use git to merge
Just add korg as a remote, fetch, merge.
Each version is tagged, so you can do that incrementally too.
Also, kernel.org hosts patches as well, if you prefer that way.
snowman77 said:
Thanks cdesai. I didn't think anything was out yet!!
Click to expand...
Click to collapse
Google <3
I got it straightened out so it's up to date with mainline and I think I've got overclocking up to 1.89ghz ready lots of more fun to be had but damn I'm just teasing myself till tuesday/whenever the thing comes in the mail. hard to test anything without hardware.
I may need a tip. I have followed your guide - which I find great and simple - but I'm having a problem with the arm binaries when I launch the make command after checking out the remotes/origin/android-msm-mako-3.4-jb-mr1-fr and executed make mako_defconfig:
Code:
/bin/sh: 1: arm-linux-androideabi-ld: not found
I have cloned the toolchain and msm repos, and added to the PATH environment var the location of the bin directory. I can reach arm-linux-androideabi-ld from the command line, but no luck executing it:
Code:
[email protected]:~/android/kernel/msm$ /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
bash: /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld: No such file or directory
And it is there with execution rights:
Code:
[email protected]:~/android/kernel/msm$ ll /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
-rwxrwxr-x 1 echedey echedey 3145332 Nov 10 16:32 /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld*
My repos are in these paths:
Code:
/home/echedey/android/arm-linux-androideabi-4.6
/home/echedey/android/kernel
And my $PATH is:
Code:
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/echedey/android/arm-linux-androideabi-4.6/bi
Am I missing anything?
josjator said:
I may need a tip. I have followed your guide - which I find great and simple - but I'm having a problem with the arm binaries when I launch the make command after checking out the remotes/origin/android-msm-mako-3.4-jb-mr1-fr and executed make mako_defconfig:
Code:
/bin/sh: 1: arm-linux-androideabi-ld: not found
I have cloned the toolchain and msm repos, and added to the PATH environment var the location of the bin directory. I can reach arm-linux-androideabi-ld from the command line, but no luck executing it:
Code:
[email protected]:~/android/kernel/msm$ /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
bash: /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld: No such file or directory
And it is there with execution rights:
Code:
[email protected]:~/android/kernel/msm$ ll /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
-rwxrwxr-x 1 echedey echedey 3145332 Nov 10 16:32 /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld*
My repos are in these paths:
Code:
/home/echedey/android/arm-linux-androideabi-4.6
/home/echedey/android/kernel
And my $PATH is:
Code:
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/echedey/android/arm-linux-androideabi-4.6/bi
Am I missing anything?
Click to expand...
Click to collapse
You path has a "n" missing from bin at the end.
You could type arm- and try to use tab-completion to see if it's accessible, then the same thing with full path (~/android/arm-linux-androideabi-4.6)
cdesai said:
You path has a "n" missing from bin at the end.
You could type arm- and try to use tab-completion to see if it's accessible, then the same thing with full path (~/android/arm-linux-androideabi-4.6)
Click to expand...
Click to collapse
Sorry, the missing 'n' came from the c&p. I can actually see the file by tabing it from any path but after the auto completing it tells this weird thing:
Code:
[email protected]:~$ arm-linux-androideabi-ld
bash: /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld: No such file or directory
I'm a experienced *nix user but I don't get this. The repos are correctly cloned and all files under bin has exec rights. I'm running ubuntu 12.10. Maybe a problem with the shell? I should try any other environment, but that would be like killing flies with missiles. Thanks for your help.
Do you definitely have the appropriate executable at
'/home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld'?
Can you do an ls -lF of that directory?
Perhaps the arm-linux-androideabi-ld file there is actually just a symlink which has lost its target.
@josjator Yeah, seems I have the same problem as you. I'm also using Ubuntu 12.10 with a bash shell. I think it may be a recursive make/shell issue thing (sorry, I'm not too hot on make files). Will keep plugging away to see if I can resolve the problem.
The device trees have hit AOSP
https://android.googlesource.com/device/lge/mako/
dsana123 said:
@josjator Yeah, seems I have the same problem as you. I'm also using Ubuntu 12.10 with a bash shell. I think it may be a recursive make/shell issue thing (sorry, I'm not too hot on make files). Will keep plugging away to see if I can resolve the problem.
Click to expand...
Click to collapse
@josjator: Using the 4.7 toolchain sorted me out (at least it's building now and past the initial problem).
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7
Click to expand...
Click to collapse
The objdump and ld binaries are much happier now.
BTW, I did download the 4.6 toolchain again (just in case there was some problem in the initial git clone), but I still encountered objdump and ld problems.
Works like a champ on Ubuntu 12.10 exactly as outlined in the OP. Thanks!
Code:
[email protected]:~/Documents/AOSP/kernel/msm$ ls -l arch/arm/boot/zImage
-rwxrwxr-x 1 android android 6314888 Nov 16 23:45 arch/arm/boot/zImage
[email protected]:~/Documents/AOSP/kernel/msm$ uname -a
Linux ubuntu 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[email protected]:~/Documents/AOSP/kernel/msm$ arm-linux-androideabi-gcc -v
[...]
gcc version 4.6.x-google 20120106 (prerelease) (GCC)

[development]-kernel 3.4-freexperia

hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J
Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1
ETA
depending on problems and developers that will join
from 6 months to NEVER
This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus
I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.
All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!​
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?
CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.
Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse
FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page
diff is 5mb on proper tag
pushed on github
nice to see so many developers trying to help
FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes

Building cm or aosp for chagalllte

Hi,
I get an increasing amount of pms asking me how to build for chagalllte. If I would answer all that questinons en detail I could stop developing, and just answer emails. So I decided to publish some of the most basic and detailed answers I gave here in this forum.
I also hope, that people trying to build for chagalllte can find each other and build up a team for the task of getting cm to chagalllte. TEAM: together everybody achieves more...
Hope, this helps:
Hello,
Devices are said to be equal... As t700 and t800 are being equal but screen size. That's NOT true. They differ verry subtile. (t700 vs. t800 i.e. differ in sound and touchscreen drivers...).
That being said I would start like this:
learn git - not github, but git on the command line
get both: most current sammy rom for t800 and t805 and put them both untared side by side to you disc
compare them thoroughly - learn the differences
from opensource.samsung.com get kernel sources for both devices: again - learn the differences
start from my gits (device, vendor, kernel) - fork them on github, clone locally
put the differences to the three gits: step by step - commit every change with long comments (wil save your as)
before flashing your first build take a look at /system/etc/wifi of running device with sammy rom, take a look at updater-script of flashable sammy-rom zip, take a look at my git repackrom.sh and use it on your flashable zip.
don't be frutrated, iron out my errors, sammy errors and your errors - build next time...
Good morning,
to get this straight: driver refers to kernel code (statically build in or build as module), blobs (or prorietary binaries) refers to already build binaries from sammy rom: these are libs (i.e. libGLES_mali.so), compiled executables (i.e. gpsd, sswap), loadable firmware for hardware (i.e. /system/etc/wifi/*), some ascii files (some keymaps if I remember right) and all that I forgot...
Of course the mali drive (kernel) interacts ditectly and closly with some of the blobs (in this case libGLES_mali.so, and some people refer to leb_GLES_mail.so as mali driver. This doesn't matter for most people - for you IT DOES MATTER to know of which part I'm speaking...
I recommend usimg the kernel sour8ce from opensource.samsung.com fot T805, but cherry-pick at least the commits from my git or crpalmers picassowifi to make it build inline cm (so if you haven't learned git you are lost here the first time).
For the versions: yeah, you make with sammy's 4.4.2 blobs a cm-11.0 (aka 4.4.4) build. We have to take what we we get - we have no 4.4.4 blobs and propably nver wil get... Sorry.
For cm-12.0 I build at the moment with a mix of sammy 4.4.2, widevine 5.0 (taken from manta) and a hexedit patched libGLRS_mali.so from picassowifi - thats fun, mage. But relax, for cm-11.0 you will come along with the blobs from sammy 4.4.2 rom. You have to find out which blobs you need in addition to the ones I have taken from 800 rom to get modem running.
For the build environment: there are several setup guides for cm. Use google. I use gentoo amd64 build from scratch - but I think you won't want that... *lol*
Add this
Code:
[alias]
lg1 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(bold white) %an%C(reset)%C(bold yellow)%d%C(reset)' --abbrev-commit --date=relative
lg2 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(bold white) %an%C(reset)' --abbrev-commit
lg = !"git lg1"
to the end of /etc/gitconfig, clone my three gits, cd to them (one after the other) and type each time "git lg1"... "git show [hash]" will show you a single commit. I know it must be boring and anoying for you, but: learn git.
May the source be with you, Nvertigo
thanks so much for posting this, i just hope someone with skills can pick this up
TheLoverMan said:
thanks so much for posting this, i just hope someone with skills can pick this up
Click to expand...
Click to collapse
Just did a quick count: got 27 pms from 8 different people regarding this subject. So if we calculate that only half of this are really interested in giving up their sparetime, partnerships and all other activities, there could be a team of 4 people...
Code long and prosper, Nvertigo
Im also going to try cm forums see if anyone has come up with something
I will try to build and see if i can use your help, if needed. Thanks for the tutorial though.
I would be so grateful for CM12 on LTE model. I don't have knowledge myself, but I thouht maybe we all users of T805 could donate for NVertigo to collect money for him to buy LTE variant? What do you guys think?

Categories

Resources